URI-scheme for bitcoin
2010 Feb 16
See all posts
URI-scheme for bitcoin @ Satoshi Nakamoto
- Author
-
Satoshi Nakamoto
- Email
-
satoshinakamotonetwork@proton.me
- Site
-
https://satoshinakamoto.network
ec
URI-scheme for bitcoin
February 16, 2010, 08:51:42 PM
Hi, intrigued by the bitcoin-system, I have an idea:
The bitcoin addresses could be improved by implementing an URI-scheme like
e.g. torrent magnet
links.
So instead of 1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ, we could
more unambiguous say bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ,
and even configure browsers to redirect clicks on such links to a
bitcoin client. This would allow one to implement "donate buttons" on
homepages, "pay buttons" on webshops etc.
If an IP should be included, URIs allow this as bitcoin://HOST_OR_IP:PORT?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ.
If wanted an amount could be specified as bitcoin:?amount=42.00;addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ (of
course for the user to verify in the secure bitcoin-client).
Just my 0.02 ฿ (return them to bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ if you
don't like them 
)
ec
February 16, 2010, 09:09:40 PM
An URI-scheme could also be of use for implementing a mobile wallet
with QR-codes, so
that your buddy who wants to pay you X bitcoins don't have to enter your
bitcoin-address manually, but only need to photograph the screen of your
mobile phone.
The Madhatter
February 24, 2010, 02:37:55 AM
Yeah, I had totally thought of that too. A magnet link scheme would
be awesome. 
Satoshi Nakamoto
February 24, 2010, 05:57:43 AM
That would be nice at point-of-sale. The cash register displays a
QR-code encoding a bitcoin address and amount on a screen and you photo
it with your mobile.
The Madhatter
February 24, 2010, 06:39:16 AM
That would be so awesome... 
Karmicads
May 01, 2010, 06:06:53 AM
I'm wondering if anybody is doing anything about this idea, as I have
been researching the possibility of implementing some Internet browser
functionality, as per this thread and
the wonderful developments described
here. It seems that it may be easier first steps, (I'm learning as I
go) to try this out and include it with whatever other features the
Firefox add-on evolves.
Before this can happen there needs to be a consensus about what form
the URI would take. I have done some quick research on the URI schemes
and most approaches are frowned upon without W3C approval, there is one
category whereby the W3C approves a tentative URI scheme and holds it in
reserve, with no guarantees (like a provisional patent), but by far the
most suitable scheme, seems to be the magnet URI, which was designed to
find a resource by the hash being a product of its content uniqueness,
rather than by specific address. Magnet was intended for use by
applications on peer to peer networks and has reserved parameters for
reference to application specific data. Basically, you simply preface
the application specific parameter with an x as in xbitcoin1:?
Maybe it is good, not to try implementing a new top level URI scheme,
as it is regarded as an ad lib maneuverer, if it is not recognized
universally. Adopting the magnet system would avoid this, but in itself
magnet is an informal, unregistered scheme. The beauty of magnet is that
it can be shared and is open in that sense.
Now, that might all seem very good, because bitcoin is after all a
P2P application and it's network does operate on similar principals, but
what if the person clicking on the link is not a bitcoin user? What if
you want to incorporate some information that is not carried in the
existing network, such as the article being sold, shipping information
and various other issues. My understanding is that bitcoin only handles
the transaction itself, so the user is left to make all other
arrangements, contracts and communications independent of bitcoin.
Here's where the anonymity is compromised, because here, we are inclined
to resort to conventional 'hierarchical hardwired, or non-anonymous
technologies. That's not a criticism of bitcoin by any stretch, because
bitcoin is a fantastic way to transact, no question about it. But the
transaction is only one side of the coin, if you'll pardon that cheesy
pun. 
In the process of investigating URI's I was reminded of freenet and
the magnet like system they use, and I ended up back there checking it
out. Given that freenet is a user/identity-space intended for
information storage, couldn't it also be used as a repository of human
readable data files, particular and unique to each user, and
incorporating any format of data you wish to use, for embellishing your
transaction? Couldn't this be used for hooking the URI into a rich
database of application specific data, that has been designed for the
publishers own website functionality or business system? While your
bitcoin node takes care of the actual transaction, the freenet node
takes care of the individual data presented.
This should keep everything under the same kind of cryptographic P2P
infrastructure, and allow infinite diversity of application specific
context. I suppose a unique URI hash key, could be borne out of the
combination of your freenet+bitcoin hashes and the file encrypted with
your freenet key found by decrypting with your bitcoin key, while your
bitcoin node can be addressed the other way around. Does that sound
right? Of course, if you use your real identity on one, then I guess
then, you real identity would be divulged on the other.
Anyhow, I'm sure there's some way to do it. Again, freenet also uses
an unregistered URI scheme, but if a variant of magnet is adopted, that
will not be a problem. The question remains, if people have hopes of
bitcoin becoming a formal recognized currency and a very legitimate
deal, then the strict adherence to all other internet protocols might be
advisable. I have noted so far nothing in particular that would prevent
the registration of a magnet/freenet like URI scheme. I haven't searched
them all but one may even exist. Otherwise why not register one?
So the URI scheme needs to be agreed upon as to the classification
(i.e. what kind magnet etc, as well do we go legit/formal or not) and
format, such as how it is to be laid out:
Components Of A URI
(image not available)
This speaks to the conventions that Mozilla will account for in
parsing a URI.
A typical magnet URI, looks like this
magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
A freenet URI is like this:
http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf
To be recognized at all, the freenet program needs to be installed
and this includes a Java powered web server that recognizes the resource
as an item in identity space of the localhost. i.e. my browser sees the
whole of freenet as being on my machine. I don't know if this identity
space could be addressable without the user having to run a web-server,
but I suspect the server is only for the ability to serve web pages as
well as recognition of the localhost as the requisite top level domain.
The ‘http:' indicates that the freenet URI, is nothing special in
itself, but the IP address (localhost) certainly is. I suspect a program
can address the freenet user space, without incorporating a web server,
and the universal links can be made as magnet URIs. As for those who
don't have bitcoin installed, I don't know how the URI could be made to
have a default fall back, to redirect visitors of that link. to the
Sourceforge download for bitcoin. That may need to implemented in code
and cookie or environ variable set to record the presence of
bitcoin.
Other relevant sites I have visited in the course of this research
include:
Any ideas/comments/feedback is/are welcome.
Steve
D҉ataWraith
May 01, 2010, 01:40:37 PM
Quote from: Karmicads on May 01, 2010, 06:06:53 AM
Before this can happen there needs to be a consensus about what form
the URI would take. [snip] ...the most suitable scheme, seems to be the
magnet URI, which was designed to find a resource by the hash being a
product of its content uniqueness, rather than by specific address.
[snip]The beauty of magnet is that it can be shared and is open in that
sense.
I think that using magnet-links just because they are already
somewhat popular does not outweigh the disadvantages. Magnet links were
designed to reference a file or set of files on peer-to-peer networks,
and as such all well-known parameters refer to files (file name, size,
etc.). Bitcoin would have to rely on application-specific
xBitcoin-parameter(s), and since we probably don't want to mix files
with bitcoin transactions in a single link, there's no really compelling
reason not to use our own, seperate format, especially since
magnet-links aren't officially recognized either.
In the process of investigating URI's I was reminded of freenet and
the magnet like system they use, and I ended up back there checking it
out. [snip] Couldn't this be used for hooking the URI into a rich
database of application specific data, that has been designed for the
publishers own website functionality or business system? While your
bitcoin node takes care of the actual transaction, the freenet node
takes care of the individual data presented.
Woah! Going from a lightweight URL-handler that brings up the Bitcoin
client to requiring Freenet is a bit of a leap. This really should be
optional.
However, it really would be very nice to add additional information
to a transaction. Building on ec's initial post, and the need for
further details, I think we should have the following url parameters (or
shorter versions of them):
address: An address to send bitcoins to. Since one can
hand out different addresses to different people, this can also define
the sender.amount (optional): The amount to send.message (optional): A short message that describes the
transaction (same as the field in the Bitcoin client)details (optional): An encoded URL with further details
of the transaction. For a purchase in an online shop, this could link to
the details of the purchase for example. Since this would be a
full-featured URL in itself, you could also link to freenet, i2p and tor
to keep things anonymous.
Karmicads
May 02, 2010, 02:15:51 AM
This just in:...
It seems there is, as it just so happens, an existing protocol
precisely for interacting with stored data files on freenet <YAY!>
Sorry, I'm not assuming that we must agree on the freenet URI
functionality I suggested, just that It is exciting that it can be so
readily incorporated, even for experimental purposes. Simply addressing
a preconfigured freenet server should do the trick, but perhaps even the
existing code can be slightly modified to directly address freenet
(without the implicit web server included in the proper freenet
install), but by including this FCP code, in the browser add-on, just
the addressing and communicating functionality may be incorporated
without the overhead of a full blown freenet http server. I assume at
this point, the freenet web server, is only needed by the client for
browsing freenet, not to service a node. As Bitcoin already addresses a
similar P2P network, how hard would it be to make the bitcoin server do
freenet inquiries? Could such trickery be included in the JSON
intreface?
From: http://new-wiki.freenetproject.org/FCPv2
Purpose
The Freenet Client Protocol is a simple, text-based protocol designed
to allow third-party applications to interact with Freenet. Supported
functionality includes:
* Inserting of data into Freenet
* Retrieval of data from Freenet
* Querying the status of Freenet
* Managing the other Freenet nodes that are connected to your own
node.
So, it seems you can pull data out of and post data into freenet at
will.
Veeeeery interesting indeed.
Aside from that, in the course of looking for proxies or workarounds
for freenet URI integration, I believe I solved an unrelated problem to
do with my ISP blocking VoIP/SIP (as it's the local telco as well - and
yes, I am changing providers very soon). I want VoIP, but my bastard
anti-competitive ISP has crippled my modems firmware (which has an
inbuilt 2 port analogue telephone adapter), and I hope this work around
(Tor) gets past it (I'm not holding my breath) but Link2VoIP, if you
are reading this, I'm looking in your direction.
Karmicads
May 02, 2010, 07:07:54 AM
Hi DataWraith
I think that using magnet-links just because they are already
somewhat popular does not outweigh the disadvantages.
I hope I didn't give the impression that I either intend to use
magnet links without more consideration of/ agreement with others, nor
that my provisional support for them is based on their existing
popularity. I'm honestly not into superficial popularity if I can help
it. The reason to consider a magnet URI IMHO is owing to the Actual
stated purpose and draft specifications
MAGNET is a work-in-progress URI specification, and collection of
standard practices/implementing code to allow a website to seamlessly
integrate with features made available by local utility programs. In one
way, it could be thought of as a vendor- and project-neutral
generalization of the "freenet:" and "ed2k:" URI-schemes used by the
Freenet and EDonkey2000 peer-to-peer networks, respectively.
It's stated purpose is specifically to allow websites to seamlessly
integrate with features of local utility programs. It is intended to be
vendor neutral and avoid having to reinvent the wheel and avoid further
conflicts with other URI schemes. It also follows strong compliance with
W3C standards and any scheme using the magnet convention would inherit
that rigor.
NOTES ABOUT THE URI FORMAT:
- Yes, it looks a little strange to have the "?" right after
the ":", but by my reading of the relevant URL/URI RFCs,
that fits the recommended common URI syntax well. (It also
meshes nicely with the way the parameters are passed on to
individual local apps.)
- FYI, EDonkey URIs violate many provisos of RFCs 1738 and
2396, including the use of "//" at the front of a non-
hierarchical namespace and the use of illegal/disfavored
(when not escaped) characters
- Parameter names and values should officially be www-
formencoded, just like HTTP web form GET submissions in the
query-string, though in practice some characters that a
strict reading of HTML-specs/RFC1738 would suggest should be
encoded (like ‘.' and ‘:') seem not to be encoded.
- The prefix ‘x.' is reserved for application-specific new
parameter experimentation. Any parameters not beginning ‘x.'
are only to be defined by official MAGNET specifications.
- Other potential parameters might include a "fallback-
location" for content that can't be found via P2P, P2P-
system-specific identifiers (ed2k, sig2dat, freenet), other
topic qualifiers ("length"), etc. These remain to be
designed; comments wanted.
Magnet links were designed to reference a file or set of files on
peer-to-peer networks, and as such all well-known parameters refer to
files (file name, size, etc.).
Sorry DataWraith, but with all due respect, I have to disagree. The
first issue is that files on a hard drive are mapped to a hierarchical
namespace of nested locations, i.e. domains and directories. The
fundamental difference, in approach of the many P2P networks is that the
namespace is not hierarchal and the data it supports is referenced not
by address but by the uniqueness of it's content. Whether the target is
a file or anything else it's not referenced by a specific fixed address,
but by the identity of it's unique contents. Identical files, are
essentially the same identity and the P2P application can use multiple
instances as multiple feeds to the same item. The parameters of magnet
are well suited to any P2P application.
MAGNET URIS, ILLUSTRATED BY EXAMPLE:
magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
meaning: show me options pertaining to the "exact topic" (xt)
given by the supplied URI (specifically, an URN)
magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&dn=Great+Speeches+-+Martin+Luther+King+Jr.+-+I+Have+A+Dream.mp3
meaning: show me options about this exact topic, but use
the included (unverified) "display name" for user convenience
magnet:?kt=martin+luther+king+mp3
meaning: show me options about the "keyword topic" (kt)
given by the string
magnet:?xt.1=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&xt.2=urn:sha1:TXGCZQTH26NL6OUQAJJPFALHG2LTGBC7
meaning: show me options about the two exact topics given
magnet:?mt=http://weblog.foo/all-my-favorites.rss
meaning: show me the options for the "manifest topic" (mt)
fetchable via the given URI. This could also be an URN.
Manifest topics include lists of other items.
Woah! Going from a lightweight URL-handler that brings up the Bitcoin
client to requiring Freenet is a bit of a leap. This really should be
optional.
Well actually it's a URN handler and I didn't specify any limit to
the ‘weight' as you put it. I would be more concerned with robustness
and not being painted into a corner myself. The effort to implement
backward compatibility and forward extensibility, having been considered
from the outset, is a small price IMHO. In any case I am only
contemplating this, in the hope it can be done without installing
freenet, at least the chunk of code needed to read and write to and from
freenet should be much smaller if (as I suspect) the whole freenet web
server is not needed. Also the URI should of course include this freenet
functionality, as an optional parameter. So if not specified, the
information to do the basic transaction would still be legitimate. It
would not then be compulsory to use in publishing the URI, but the
handler should still be able to take the parameter if it is used,
otherwise the optional choice you are proposing is between two different
incompatible URI schemes. Measure twice, cut once.
However, it really would be very nice to add additional information
to a transaction. Building on ec's initial post, and the need for
further details, I think we should have the following url parameters (or
shorter versions of them):
* address: An address to send bitcoins to. Since one can hand out
different addresses to different people, this can also define the
sender.
* amount (optional): The amount to send.
* message (optional): A short message that describes the transaction
(same as the field in the Bitcoin client)
* details (optional): An encoded URL with further details of the
transaction. For a purchase in an online shop, this could link to the
details of the purchase for example. Since this would be a full-featured
URL in itself, you could also link to freenet, i2p and tor to keep
things anonymous.
Not sure what you mean by address, other than the ‘address' that is
provided by your bitcoin signature (which is more like a name than a
place). I cant see how you can hand out different addresses to different
people, unless you already have some aliases defined. So you are
suggesting an added naming system to encode and translate aliases for a
bitcoin node, is that what you mean? That could be done without too much
hassle I suppose.
The amount: Yup goes without saying.
Message: This is where URI data becomes unwieldy. A message is
implicitly a useful amount of human communication, which was never
intended to be delivered in the URI itself. The need to reference a
supplementary document begins here. The payer can send their message in
the software interface (either the standalone program or the Firefox
add-on), The link, at a minimum, identifies the recipient and the
amount, that must be passed to the software. If the receiving party
wants to communicate some text, then they can do so in the document they
are publishing (IE. where they are publishing the link). The text for
the sending party, can use the normal route, as the link invokes the
bitcoin interface and that provides the field to include a note. What
message needs to be passed by the receiver (payee) that is not possible
in the document in which they are publishing the link? What message
needs to be passed by the payer, that is not possible in the interface,
but is possible by clicking on the link? That would imply that the link
invokes methods like post or get, that are exclusively http/s
functionality, that is defeating the purpose of having a purpose made
URI scheme. Post and Get functions need to be addressed within the
hierarchical namespace of TCP/IP and/or physical file path names.
Details: I advocated from the outset, the desirability of the URI
scheme, being able to reference a document with a richer data structure,
that can be used to embellish upon the basic essential information
passed by the obligatory parameters. I also suggested a proposed
repository for those documents which lead to some accessibility issues,
but if solved would enhance the anonymity of the bitcoin node and
circumvent the reliance on non-P2P or hierarchical namespace. The
possibility of taking a beautiful network addressing protocol and
remapping it with (or kludging it onto) a regressive, inferior, butt
ugly one, which requires all entities to adopt the analogy of a fixed
location, and loose all hard wired associations if they are shifted,
seems to me as tactful as giving a beautiful stone building a coat of
cheap plastic paint; bright green paint. A URL for a parameter, Is
precisely the kind of butchery I would rather avoid, because a URL is
not a URN and the namespace it addresses, is hierarchical and must
ultimately reside at a fixed IP.
As far as this "you could also link to freenet, i2p and tor to
keep things anonymous." is concerned, you clearly haven't given it
much thought. If I could just link to freenet, then I could just as
easily incorporate freenet as the actual repository referenced in the
URI to begin with. That's the problem. You can't just store files on
freenet, and expect anybody to be able to retrieve them with a URL or a
URN, on a regular website, unless the visitor has the client software to
handle the link, the reference it gives will be useless. If I can make
the URI handler address the freenet namespace, then I suggest it would
much better to store the files there in the first place. Because http/s
operates on a hierarchical namespace and P2P clients operate on
non-hierarchical namespace, the one parameter can't be used to
interdependently address both. It's a bit late for you to decide to
become anonymous after you have fixed your identity to a physical
locus.
If I have misunderstood you I apologize DataWraith, but you don't
seem to appreciate the difference between the two namespace models, nor
their relative advantages and liabilities. I am sill quite willing to
consider any other system of schema. I am not rejecting your criticism
out of hand, nor insisting my own preferences should be the default. I
would prefer to simply make the best URI scheme possible regardless.
Thanks for your consideration all the same.
EDIT:
Re my comment "The amount: Yup goes without saying." I take
that back. I was thinking in terms of links only as instigators of
payment events, but of course, if the amount and other parameters are
left blank, it should then default to acting as an identifier link to
instigate a payment at the behest of the payer. A simple donate button
would only need one parameter and zero
redirections/login/confirmation/calculate and change currency before you
can finally send, to not see your transaction eating the dust of
snailmail on horseback, in the event that you don't have a credit card.
(Suck on that that PlayPal). That, along with the naming alias idea
suggested by DataWraith AKA (having an address), if that;s what you
meant DataWraith, is certainly worth implementing for my bitcoin.
D҉ataWraith
May 02, 2010, 11:13:09 AM
Karmicaids, thanks for taking the time for such a detailed reply.
Quote from: Karmicads on May 02, 2010, 02:15:51 AM
It seems there is, as it just so happens, an existing protocol
precisely for interacting with stored data files on freenet <YAY!>
Oh, I thought you meant that when you spoke of using freenet. The
user runs freenet and Bitcoin would communicate with it using its
control protocol. However, running Freenet requires considerable
computer resources, especially bandwidth, and personally, I do not want
to run a freenet node for that reason alone. That's why I wanted this to
be optional.
I hope I didn't give the impression that I either intend to use
magnet links without more consideration of/ agreement with others, nor
that my provisional support for them is based on their existing
popularity.
I had the impression that you did not want to re-invent the wheel,
and that's why popularity played a part – that the existing acceptance
of magnet links in other software was a plus.
Magnet links were designed to reference a file or set of files on
peer-to-peer networks, and as such all well-known parameters refer to
files (file name, size, etc.).
Sorry DataWraith, but with all due respect, I have to disagree. The
first issue is that files on a hard drive are mapped to a hierarchical
namespace of nested locations, i.e. domains and directories. The
fundamental difference, in approach of the many P2P networks is that the
namespace is not hierarchal and the data it supports is referenced not
by address but by the uniqueness of it's content. Whether the target is
a file or anything else it's not referenced by a specific fixed address,
but by the identity of it's unique contents. Identical files, are
essentially the same identity and the P2P application can use multiple
instances as multiple feeds to the same item. The parameters of magnet
are well suited to any P2P application.
Okay, sorry, seems I haven't made entirely clear what I mean here.
I'm aware of how magnet links refer to content, rather than a location
in a hierachical namespace.
Perhaps it's just a difference of mental models: For me, a bitcoin
transaction is, for lack of better words, not a thingso much as
a process. In my mind, magnet links refer to things (usually a file –
whether by content hash or by location), and trying to use them to refer
to a process strikes me as a little awkward. Magnet links identify
things you then have to go fetch, while a bitcoin transaction is
completely described by the link itself (although you still have to say
"Yes, send the coins." once you click the link).
To me it seems that using magnet links would be to (ab)use them for
something they were not meant to describe, as they orignated as a
replacement for ed2k://, freenet://, et al., describing how to get a
file.
A bitcoin-link should be more like mailto: than magnet: IMHO.
Well actually it's a URN handler and I didn't specify any limit to
the ‘weight' as you put it.
Yeah, my mistake, sorry.
In any case I am only contemplating this, in the hope it can be done
without installing freenet, at least the chunk of code needed to read
and write to and from freenet should be much smaller if (as I suspect)
the whole freenet web server is not needed.
IIRC the web server is pretty much integrated into Freenet itself.
You can use the simpler FCP protocol to talk to a Freenet instance, but
because of the type of content on Freenet, not many people are willing
to host a publicly accessible instance, so you would have to run your
own. I don't begrudge that you want to be able to do this, I'm just not
willing to do it myself. I'd much rather host a TOR hidden service –
that's why I suggested to use a general, full-featured URL as the
details parameter, instead of making it freenet specific.
- address: An address to send bitcoins to. Since one can hand out
different addresses to different people, this can also define the
sender.
- amount (optional): The amount to send.
- message (optional): A short message that describes the transaction
(same as the field in the Bitcoin client)
- details (optional): An encoded URL with further details of the
transaction. For a purchase in an online shop, this could link to the
details of the purchase for example. Since this would be a full-featured
URL in itself, you could also link to freenet, i2p and tor to keep
things anonymous.
Not sure what you mean by address, other than the ‘address' that is
provided by your bitcoin signature (which is more like a name than a
place). I cant see how you can hand out different addresses to different
people, unless you already have some aliases defined. So you are
suggesting an added naming system to encode and translate aliases for a
bitcoin node, is that what you mean? That could be done without too much
hassle I suppose.
Well, yeah, I meant the bitcoin signature. I called it address,
because that's what it says in the bitcoin client (i.e. "Change your
address"). I indeed thought that one should use different aliases, just
like the exchange sites currently do: You get an address (or signature,
or whatever) to send coins to, and because that address was only given
to you, the recipient knows the payment is from you.
A system to translate aliases would of course be nice, but I think
that's better handled with an address book or mybitcoin.com or something.
Message: This is where URI data becomes unwieldy. A message is
implicitly a useful amount of human communication, which was never
intended to be delivered in the URI itself. If the receiving party wants
to communicate some text, then they can do so in the document they are
publishing (IE. where they are publishing the link). The text for the
sending party, can use the normal route, as the link invokes the bitcoin
interface and that provides the field to include a note. What message
needs to be passed by the receiver (payee) that is not possible in the
document in which they are publishing the link?
Yes, exactly! The text for the sending party can use the normal
route. But what if I want to pre-specify the text that should be
sent?
This has an analogue in mailto:-links: If you want someone to send
you an email, you can also specify a subject he/she should use:
mailto:alice@example.org?subject=Test. So if I am selling something on,
say, ebay, I can give the buyer a bitcoin link that includes the message
"Payment for Ebay auction #12345", so he/she does not have to enter it
themselves, possibly making a mistake if the code is more cryptic than
#12345.
Details: I advocated from the outset, the desirability of the URI
scheme, being able to reference a document with a richer data structure,
that can be used to embellish upon the basic essential information
passed by the obligatory parameters. I also suggested a proposed
repository for those documents which lead to some accessibility issues,
but if solved would enhance the anonymity of the bitcoin node and
circumvent the reliance on non-P2P or hierarchical namespace. The
possibility of taking a beautiful network addressing protocol and
remapping it with (or kludging it onto) a regressive, inferior, butt
ugly one, which requires all entities to adopt the analogy of a fixed
location, and loose all hard wired associations if they are shifted,
seems to me as tactful as giving a beautiful stone building a coat of
cheap plastic paint; bright green paint. A URL for a parameter, Is
precisely the kind of butchery I would rather avoid, because a URL is
not a URN and the namespace it addresses, is hierarchical and must
ultimately reside at a fixed IP.
Sorry, I mistakenly tend to use the terms URI, URL, etc.
interchangeably because you enter it into the address bar %). Again,
sorry if this lead to confusion.
What I wanted here was to make this additional information general.
Some examples might clarify this:
The creator of the link chooses where to put the additional details,
and the recipient decides whether he needs the supplemental information
badly enough to install Freenet/Tor/I2P. That's one of the reasons for
including a short message in the link itself: the additional information
should not be critical to the transaction.
As far as this "you could also link to freenet, i2p and
tor to keep things anonymous." is concerned, you clearly
haven't given it much thought. If I could just link to freenet, then I
could just as easily incorporate freenet as the actual repository
referenced in the URI to begin with.
But wouldn't that make the use of Freenet mandatory? I would like
this to stay more flexible.
Also, if I were to run an online shop, I'd rather have people look
the details up on my own website rather than them having to install
freenet. That might also link my shop's reputation with Freenet, which
given Freenet's reputation, might be undesirable.
That's the problem. You can't just store files on freenet, and expect
anybody to be able to retrieve them with a URL or a URN, on a regular
website, unless the visitor has the client software to handle the link,
the reference it gives will be useless.
Yup. That's another reason for wanting to also allow normal HTTP(S)
URLs. If I have not misunderstood, you seem to want to make the use of
Freenet for transactions mandatory, which is something I strongly
disagree with.
Because http/s operates on a hierarchical namespace and P2P clients
operate on non-hierarchical namespace, the one parameter can't be used
to interdependently address both. It's a bit late for you to decide to
become anonymous after you have fixed your identity to a physical
locus.
Not every single transaction needs bulletproof anonymity. Think Open
Source projects receiving donations, or online shops. If you (a) need
more details than the short message parameter provides, and (b) you want
to be totally anonymous, you can just specify a freenet or Tor or
I2P-URL (or URN? – this is confusing :-/ ). If you don't need the added
anonymity, you don't have to make the effort to run
Freenet/Tor/I2P/whatever.
If I have misunderstood you I apologize DataWraith, but you don't
seem to appreciate the difference between the two namespace models, nor
their relative advantages and liabilities. I am sill quite willing to
consider any other system of schema. I am not rejecting your criticism
out of hand, nor insisting my own preferences should be the default. I
would prefer to simply make the best URI scheme possible regardless.
Thanks for your consideration all the same.
Well, we're all together in this. I just hope to arrive at the best
possible system. :-)
Thank you for your thorough explanation, and patience with my
suggestions.
Satoshi Nakamoto
May 16, 2010, 10:37:21 PM
Quote from: Karmicads on May 01, 2010, 06:06:53 AM
A freenet URI is like this:
http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf
There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=(bitcoinaddress);amount=(amount)
Bitcoin can answer port 8330 on local loopback just as it does for
JSON-RPC on 8332. It would give an HTTP answer.
Quote from: DataWraith on May 02, 2010, 11:13:09 AM
A bitcoin-link should be more like mailto: than magnet: IMHO.
I think we can do that.
Although it would be possible for Bitcoin to take care of business in
the HTTP response by presenting HTML UI to the user, as a user I would
wonder if some website is trying to trick me or if I'm really talking to
my own Bitcoin server.
The HTTP response could simply be HTML with the JavaScript equivalent
of the back button, sending it back to the page. Bitcoin then pops up
the Send Bitcoins dialog with the destination bitcoin address and amount
already filled in. It would work just like a mailto: link that pops up
a new email with the address filled in.
127.0.0.1 loopback is accessible by any user on the machine, it
doesn't have per-user separation, but it's OK because it would only
serve the convenience function of pre-filling the fields in a dialog.
You'd still have to press Send. We'd have to make sure the Send button
is not selected so it couldn't jump into the foreground while you're
typing a space or enter.
lachesis
June 11, 2010, 02:51:56 PM
Quote from: satoshi on May 16, 2010, 10:37:21 PM
There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=(bitcoinaddress);amount=(amount)
That's a very pragmatic answer. I like it.
However, how would that work with the combined IP / Bitcoin Address
URI (URN? URL?) scheme described here?
link
I know it's been nearly a month, sorry.
Satoshi Nakamoto
June 16, 2010, 12:15:47 AM
http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345
or
http://127.0.0.1:8330/?to=(bitcoinaddress)(separatorchar)1.2.3.4&amount=200.00
But as long as the link is already doing the typing for you, I don't
see much benefit in using a domain address instead of bitcoin address.
With a bitcoin address, the user can't send an unidentified payment.
They can't send payment until they've been given a correct bitcoin
address to send to.
What would be nice about sending by domain is you could visually
verify who it's going to.
A more crucial issue is what if the browser isn't allowed to connect
to 127.0.0.1:
https://bitcointalk.org/index.php?topic=63.msg1589#msg1589
and if that's true, then what about that example freenet link that
had 127.0.0.1 in it?
lachesis
June 16, 2010, 06:14:05 AM
Quote from: satoshi on June 16, 2010, 12:15:47 AM
But as long as the link is already doing the typing for you, I don't
see much benefit in using a domain address instead of bitcoin address.
With a bitcoin address, the user can't send an unidentified payment.
They can't send payment until they've been given a correct bitcoin
address to send to.
What would be nice about sending by domain is you could visually
verify who it's going to.
I think that hiding the complexity of Bitcoin addresses from the
casual user is a good thing. Barring that, it should be possible to
embed an observable but unalterable message with address transactions.
Is there some reason this is technically infeasible?
Quote from: satoshi on June 16, 2010, 12:15:47 AM
A more crucial issue is what if the browser isn't allowed to connect
to 127.0.0.1:
https://bitcointalk.org/index.php?topic=63.msg1589#msg1589
and if that's true, then what about that example freenet link that
had 127.0.0.1 in it?
I think you're misunderstanding the issue. My browser will always be
able to go to 127.0.0.1 (barring some strange IE settings or a virus).
If I type the address into the URL bar or click a link, it will work
fine. However, it isn't possible to use Javascript to complete POST
requests between domains (or ports on the same domain).
Try clicking this link:
http://127.0.0.1/
You probably don't see anything (unless you're running a web server on
your system), but the browser happily tries to take you there.
XMLHTTPRequest is
what we were discussing in that other thread.
sirius
June 16, 2010, 08:26:14 AM
Yeah, I meant to say that cross-domain javascript calls are
forbidden, so you can't call 127.0.0.1 from a javascript that doesn't
reside in 127.0.0.1. Come to think of it, it would be quite funny if
browsers allowed malicious cross-domain javascript to change people's
Facebook pages etc.
bencoder
June 16, 2010, 12:59:40 PM
Quote from: sirius-m on June 16, 2010, 08:26:14 AM
Yeah, I meant to say that cross-domain javascript calls are
forbidden, so you can't call 127.0.0.1 from a javascript that doesn't
reside in 127.0.0.1. Come to think of it, it would be quite funny if
browsers allowed malicious cross-domain javascript to change people's
Facebook pages etc.
You could do an iframe that pointed to something like http://127.0.0.1:8330?pay=domain.com&amount=x&return=<wheretoreturn.php>
and then that iframe would contain a little bitcoin interface stating
how much & who you're paying and a button to confirm or cancel the
payment. If you confirm the payment then it sends the coins to the
domain and then redirects to the return value in the query string.
bitcoin could add a ?paid=true or ?paid=false to the return location as
well so the return script on the domain could then check if it received
the payment correctly, or cancel the order.
Edit: the bitcoin interface should also have a password before you
can confirm the payment. Otherwise you could scan for port 8330 being
open on anybody and then automatically have it send payments.
lachesis
June 16, 2010, 07:38:32 PM
Quote from: bencoder on June 16, 2010, 12:59:40 PM
Edit: the bitcoin interface should also have a password before you
can confirm the payment. Otherwise you could scan for port 8330 being
open on anybody and then automatically have it send payments.
That's not exactly true. At the moment, Bitcoin only binds RPC to the
loopback interface, 127.0.0.1. I would assume that this web interface
would be the same. However, there SHOULD be a password to prevent
trojans from trivially sending your wallet away. Wallet encryption needs
to happen, too.
Satoshi Nakamoto
July 18, 2010, 04:06:16 PM
Quote from: lachesis on June 16, 2010, 06:14:05 AM
I think you're misunderstanding the issue. My browser will always be
able to go to 127.0.0.1 (barring some strange IE settings or a virus).
If I type the address into the URL bar or click a link, it will work
fine. However, it isn't possible to use Javascript to complete POST
requests between domains (or ports on the same domain).
That's what I thought too.
Quote from: sirius-m on June 16, 2010, 08:26:14 AM
Yeah, I meant to say that cross-domain javascript calls are
forbidden, so you can't call 127.0.0.1 from a javascript that doesn't
reside in 127.0.0.1. Come to think of it, it would be quite funny if
browsers allowed malicious cross-domain javascript to change people's
Facebook pages etc.
Now I'm hearing a report that it IS possible for javascript to do a
cross-domain POST request to 127.0.0.1. Not other domains, but just
specifically to that one. Great...
If this is the case, then do not use the -server switch or bitcoind
on a system where you do web browsing.
I'll get started on adding the password field.
URI-scheme for bitcoin
2010 Feb 16 See all postsSatoshi Nakamoto
satoshinakamotonetwork@proton.me
https://satoshinakamoto.network
Hi, intrigued by the bitcoin-system, I have an idea:
The bitcoin addresses could be improved by implementing an URI-scheme like e.g. torrent magnet links.
So instead of 1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ, we could more unambiguous say bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ, and even configure browsers to redirect clicks on such links to a bitcoin client. This would allow one to implement "donate buttons" on homepages, "pay buttons" on webshops etc.
If an IP should be included, URIs allow this as bitcoin://HOST_OR_IP:PORT?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ. If wanted an amount could be specified as bitcoin:?amount=42.00;addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ (of course for the user to verify in the secure bitcoin-client).
Just my 0.02 ฿ (return them to bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ if you don't like them
)
An URI-scheme could also be of use for implementing a mobile wallet with QR-codes, so that your buddy who wants to pay you X bitcoins don't have to enter your bitcoin-address manually, but only need to photograph the screen of your mobile phone.
Yeah, I had totally thought of that too. A magnet link scheme would be awesome.
That would be nice at point-of-sale. The cash register displays a QR-code encoding a bitcoin address and amount on a screen and you photo it with your mobile.
That would be so awesome...
I'm wondering if anybody is doing anything about this idea, as I have been researching the possibility of implementing some Internet browser functionality, as per this thread and the wonderful developments described here. It seems that it may be easier first steps, (I'm learning as I go) to try this out and include it with whatever other features the Firefox add-on evolves.
Before this can happen there needs to be a consensus about what form the URI would take. I have done some quick research on the URI schemes and most approaches are frowned upon without W3C approval, there is one category whereby the W3C approves a tentative URI scheme and holds it in reserve, with no guarantees (like a provisional patent), but by far the most suitable scheme, seems to be the magnet URI, which was designed to find a resource by the hash being a product of its content uniqueness, rather than by specific address. Magnet was intended for use by applications on peer to peer networks and has reserved parameters for reference to application specific data. Basically, you simply preface the application specific parameter with an x as in xbitcoin1:?
Maybe it is good, not to try implementing a new top level URI scheme, as it is regarded as an ad lib maneuverer, if it is not recognized universally. Adopting the magnet system would avoid this, but in itself magnet is an informal, unregistered scheme. The beauty of magnet is that it can be shared and is open in that sense.
Now, that might all seem very good, because bitcoin is after all a P2P application and it's network does operate on similar principals, but what if the person clicking on the link is not a bitcoin user? What if you want to incorporate some information that is not carried in the existing network, such as the article being sold, shipping information and various other issues. My understanding is that bitcoin only handles the transaction itself, so the user is left to make all other arrangements, contracts and communications independent of bitcoin. Here's where the anonymity is compromised, because here, we are inclined to resort to conventional 'hierarchical hardwired, or non-anonymous technologies. That's not a criticism of bitcoin by any stretch, because bitcoin is a fantastic way to transact, no question about it. But the transaction is only one side of the coin, if you'll pardon that cheesy pun.
In the process of investigating URI's I was reminded of freenet and the magnet like system they use, and I ended up back there checking it out. Given that freenet is a user/identity-space intended for information storage, couldn't it also be used as a repository of human readable data files, particular and unique to each user, and incorporating any format of data you wish to use, for embellishing your transaction? Couldn't this be used for hooking the URI into a rich database of application specific data, that has been designed for the publishers own website functionality or business system? While your bitcoin node takes care of the actual transaction, the freenet node takes care of the individual data presented.
This should keep everything under the same kind of cryptographic P2P infrastructure, and allow infinite diversity of application specific context. I suppose a unique URI hash key, could be borne out of the combination of your freenet+bitcoin hashes and the file encrypted with your freenet key found by decrypting with your bitcoin key, while your bitcoin node can be addressed the other way around. Does that sound right? Of course, if you use your real identity on one, then I guess then, you real identity would be divulged on the other.
Anyhow, I'm sure there's some way to do it. Again, freenet also uses an unregistered URI scheme, but if a variant of magnet is adopted, that will not be a problem. The question remains, if people have hopes of bitcoin becoming a formal recognized currency and a very legitimate deal, then the strict adherence to all other internet protocols might be advisable. I have noted so far nothing in particular that would prevent the registration of a magnet/freenet like URI scheme. I haven't searched them all but one may even exist. Otherwise why not register one?
So the URI scheme needs to be agreed upon as to the classification (i.e. what kind magnet etc, as well do we go legit/formal or not) and format, such as how it is to be laid out:
Components Of A URI
(image not available)
This speaks to the conventions that Mozilla will account for in parsing a URI.
A typical magnet URI, looks like this
magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
A freenet URI is like this:
http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf
To be recognized at all, the freenet program needs to be installed and this includes a Java powered web server that recognizes the resource as an item in identity space of the localhost. i.e. my browser sees the whole of freenet as being on my machine. I don't know if this identity space could be addressable without the user having to run a web-server, but I suspect the server is only for the ability to serve web pages as well as recognition of the localhost as the requisite top level domain. The ‘http:' indicates that the freenet URI, is nothing special in itself, but the IP address (localhost) certainly is. I suspect a program can address the freenet user space, without incorporating a web server, and the universal links can be made as magnet URIs. As for those who don't have bitcoin installed, I don't know how the URI could be made to have a default fall back, to redirect visitors of that link. to the Sourceforge download for bitcoin. That may need to implemented in code and cookie or environ variable set to record the presence of bitcoin.
Other relevant sites I have visited in the course of this research include:
Any ideas/comments/feedback is/are welcome.
Steve
I think that using magnet-links just because they are already somewhat popular does not outweigh the disadvantages. Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.). Bitcoin would have to rely on application-specific xBitcoin-parameter(s), and since we probably don't want to mix files with bitcoin transactions in a single link, there's no really compelling reason not to use our own, seperate format, especially since magnet-links aren't officially recognized either.
Woah! Going from a lightweight URL-handler that brings up the Bitcoin client to requiring Freenet is a bit of a leap. This really should be optional.
However, it really would be very nice to add additional information to a transaction. Building on ec's initial post, and the need for further details, I think we should have the following url parameters (or shorter versions of them):
address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.amount(optional): The amount to send.message(optional): A short message that describes the transaction (same as the field in the Bitcoin client)details(optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous.This just in:...
It seems there is, as it just so happens, an existing protocol precisely for interacting with stored data files on freenet
<YAY!> 
Sorry, I'm not assuming that we must agree on the freenet URI functionality I suggested, just that It is exciting that it can be so readily incorporated, even for experimental purposes. Simply addressing a preconfigured freenet server should do the trick, but perhaps even the existing code can be slightly modified to directly address freenet (without the implicit web server included in the proper freenet install), but by including this FCP code, in the browser add-on, just the addressing and communicating functionality may be incorporated without the overhead of a full blown freenet http server. I assume at this point, the freenet web server, is only needed by the client for browsing freenet, not to service a node. As Bitcoin already addresses a similar P2P network, how hard would it be to make the bitcoin server do freenet inquiries? Could such trickery be included in the JSON intreface?
From: http://new-wiki.freenetproject.org/FCPv2
So, it seems you can pull data out of and post data into freenet at will.
Veeeeery interesting indeed.
Aside from that, in the course of looking for proxies or workarounds for freenet URI integration, I believe I solved an unrelated problem to do with my ISP blocking VoIP/SIP (as it's the local telco as well - and yes, I am changing providers very soon). I want VoIP, but my bastard anti-competitive ISP has crippled my modems firmware (which has an inbuilt 2 port analogue telephone adapter), and I hope this work around (Tor) gets past it (I'm not holding my breath) but Link2VoIP, if you are reading this, I'm looking in your direction.
Hi DataWraith
I hope I didn't give the impression that I either intend to use magnet links without more consideration of/ agreement with others, nor that my provisional support for them is based on their existing popularity. I'm honestly not into superficial popularity if I can help it. The reason to consider a magnet URI IMHO is owing to the Actual stated purpose and draft specifications
It's stated purpose is specifically to allow websites to seamlessly integrate with features of local utility programs. It is intended to be vendor neutral and avoid having to reinvent the wheel and avoid further conflicts with other URI schemes. It also follows strong compliance with W3C standards and any scheme using the magnet convention would inherit that rigor.
Sorry DataWraith, but with all due respect, I have to disagree. The first issue is that files on a hard drive are mapped to a hierarchical namespace of nested locations, i.e. domains and directories. The fundamental difference, in approach of the many P2P networks is that the namespace is not hierarchal and the data it supports is referenced not by address but by the uniqueness of it's content. Whether the target is a file or anything else it's not referenced by a specific fixed address, but by the identity of it's unique contents. Identical files, are essentially the same identity and the P2P application can use multiple instances as multiple feeds to the same item. The parameters of magnet are well suited to any P2P application.
Well actually it's a URN handler and I didn't specify any limit to the ‘weight' as you put it. I would be more concerned with robustness and not being painted into a corner myself. The effort to implement backward compatibility and forward extensibility, having been considered from the outset, is a small price IMHO. In any case I am only contemplating this, in the hope it can be done without installing freenet, at least the chunk of code needed to read and write to and from freenet should be much smaller if (as I suspect) the whole freenet web server is not needed. Also the URI should of course include this freenet functionality, as an optional parameter. So if not specified, the information to do the basic transaction would still be legitimate. It would not then be compulsory to use in publishing the URI, but the handler should still be able to take the parameter if it is used, otherwise the optional choice you are proposing is between two different incompatible URI schemes. Measure twice, cut once.
Not sure what you mean by address, other than the ‘address' that is provided by your bitcoin signature (which is more like a name than a place). I cant see how you can hand out different addresses to different people, unless you already have some aliases defined. So you are suggesting an added naming system to encode and translate aliases for a bitcoin node, is that what you mean? That could be done without too much hassle I suppose.
The amount: Yup goes without saying.
Message: This is where URI data becomes unwieldy. A message is implicitly a useful amount of human communication, which was never intended to be delivered in the URI itself. The need to reference a supplementary document begins here. The payer can send their message in the software interface (either the standalone program or the Firefox add-on), The link, at a minimum, identifies the recipient and the amount, that must be passed to the software. If the receiving party wants to communicate some text, then they can do so in the document they are publishing (IE. where they are publishing the link). The text for the sending party, can use the normal route, as the link invokes the bitcoin interface and that provides the field to include a note. What message needs to be passed by the receiver (payee) that is not possible in the document in which they are publishing the link? What message needs to be passed by the payer, that is not possible in the interface, but is possible by clicking on the link? That would imply that the link invokes methods like post or get, that are exclusively http/s functionality, that is defeating the purpose of having a purpose made URI scheme. Post and Get functions need to be addressed within the hierarchical namespace of TCP/IP and/or physical file path names.
Details: I advocated from the outset, the desirability of the URI scheme, being able to reference a document with a richer data structure, that can be used to embellish upon the basic essential information passed by the obligatory parameters. I also suggested a proposed repository for those documents which lead to some accessibility issues, but if solved would enhance the anonymity of the bitcoin node and circumvent the reliance on non-P2P or hierarchical namespace. The possibility of taking a beautiful network addressing protocol and remapping it with (or kludging it onto) a regressive, inferior, butt ugly one, which requires all entities to adopt the analogy of a fixed location, and loose all hard wired associations if they are shifted, seems to me as tactful as giving a beautiful stone building a coat of cheap plastic paint; bright green paint. A URL for a parameter, Is precisely the kind of butchery I would rather avoid, because a URL is not a URN and the namespace it addresses, is hierarchical and must ultimately reside at a fixed IP.
As far as this "you could also link to freenet, i2p and tor to keep things anonymous." is concerned, you clearly haven't given it much thought. If I could just link to freenet, then I could just as easily incorporate freenet as the actual repository referenced in the URI to begin with. That's the problem. You can't just store files on freenet, and expect anybody to be able to retrieve them with a URL or a URN, on a regular website, unless the visitor has the client software to handle the link, the reference it gives will be useless. If I can make the URI handler address the freenet namespace, then I suggest it would much better to store the files there in the first place. Because http/s operates on a hierarchical namespace and P2P clients operate on non-hierarchical namespace, the one parameter can't be used to interdependently address both. It's a bit late for you to decide to become anonymous after you have fixed your identity to a physical locus.
If I have misunderstood you I apologize DataWraith, but you don't seem to appreciate the difference between the two namespace models, nor their relative advantages and liabilities. I am sill quite willing to consider any other system of schema. I am not rejecting your criticism out of hand, nor insisting my own preferences should be the default. I would prefer to simply make the best URI scheme possible regardless. Thanks for your consideration all the same.
EDIT:
Re my comment "The amount: Yup goes without saying." I take that back. I was thinking in terms of links only as instigators of payment events, but of course, if the amount and other parameters are left blank, it should then default to acting as an identifier link to instigate a payment at the behest of the payer. A simple donate button would only need one parameter and zero redirections/login/confirmation/calculate and change currency before you can finally send, to not see your transaction eating the dust of snailmail on horseback, in the event that you don't have a credit card. (Suck on that that PlayPal). That, along with the naming alias idea suggested by DataWraith AKA (having an address), if that;s what you meant DataWraith, is certainly worth implementing for my bitcoin.
Karmicaids, thanks for taking the time for such a detailed reply.
Oh, I thought you meant that when you spoke of using freenet. The user runs freenet and Bitcoin would communicate with it using its control protocol. However, running Freenet requires considerable computer resources, especially bandwidth, and personally, I do not want to run a freenet node for that reason alone. That's why I wanted this to be optional.
I had the impression that you did not want to re-invent the wheel, and that's why popularity played a part – that the existing acceptance of magnet links in other software was a plus.
Okay, sorry, seems I haven't made entirely clear what I mean here. I'm aware of how magnet links refer to content, rather than a location in a hierachical namespace.
Perhaps it's just a difference of mental models: For me, a bitcoin transaction is, for lack of better words, not a thingso much as a process. In my mind, magnet links refer to things (usually a file – whether by content hash or by location), and trying to use them to refer to a process strikes me as a little awkward. Magnet links identify things you then have to go fetch, while a bitcoin transaction is completely described by the link itself (although you still have to say "Yes, send the coins." once you click the link).
To me it seems that using magnet links would be to (ab)use them for something they were not meant to describe, as they orignated as a replacement for ed2k://, freenet://, et al., describing how to get a file.
A bitcoin-link should be more like mailto: than magnet: IMHO.
Yeah, my mistake, sorry.
IIRC the web server is pretty much integrated into Freenet itself. You can use the simpler FCP protocol to talk to a Freenet instance, but because of the type of content on Freenet, not many people are willing to host a publicly accessible instance, so you would have to run your own. I don't begrudge that you want to be able to do this, I'm just not willing to do it myself. I'd much rather host a TOR hidden service – that's why I suggested to use a general, full-featured URL as the details parameter, instead of making it freenet specific.
Well, yeah, I meant the bitcoin signature. I called it address, because that's what it says in the bitcoin client (i.e. "Change your address"). I indeed thought that one should use different aliases, just like the exchange sites currently do: You get an address (or signature, or whatever) to send coins to, and because that address was only given to you, the recipient knows the payment is from you.
A system to translate aliases would of course be nice, but I think that's better handled with an address book or mybitcoin.com or something.
Yes, exactly! The text for the sending party can use the normal route. But what if I want to pre-specify the text that should be sent?
This has an analogue in mailto:-links: If you want someone to send you an email, you can also specify a subject he/she should use: mailto:alice@example.org?subject=Test. So if I am selling something on, say, ebay, I can give the buyer a bitcoin link that includes the message "Payment for Ebay auction #12345", so he/she does not have to enter it themselves, possibly making a mistake if the code is more cryptic than #12345.
Sorry, I mistakenly tend to use the terms URI, URL, etc. interchangeably because you enter it into the address bar %). Again, sorry if this lead to confusion.
What I wanted here was to make this additional information general. Some examples might clarify this:
The creator of the link chooses where to put the additional details, and the recipient decides whether he needs the supplemental information badly enough to install Freenet/Tor/I2P. That's one of the reasons for including a short message in the link itself: the additional information should not be critical to the transaction.
But wouldn't that make the use of Freenet mandatory? I would like this to stay more flexible.
Also, if I were to run an online shop, I'd rather have people look the details up on my own website rather than them having to install freenet. That might also link my shop's reputation with Freenet, which given Freenet's reputation, might be undesirable.
Yup. That's another reason for wanting to also allow normal HTTP(S) URLs. If I have not misunderstood, you seem to want to make the use of Freenet for transactions mandatory, which is something I strongly disagree with.
Not every single transaction needs bulletproof anonymity. Think Open Source projects receiving donations, or online shops. If you (a) need more details than the short message parameter provides, and (b) you want to be totally anonymous, you can just specify a freenet or Tor or I2P-URL (or URN? – this is confusing :-/ ). If you don't need the added anonymity, you don't have to make the effort to run Freenet/Tor/I2P/whatever.
Well, we're all together in this. I just hope to arrive at the best possible system. :-)
Thank you for your thorough explanation, and patience with my suggestions.
There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=(bitcoinaddress);amount=(amount)
Bitcoin can answer port 8330 on local loopback just as it does for JSON-RPC on 8332. It would give an HTTP answer.
I think we can do that.
Although it would be possible for Bitcoin to take care of business in the HTTP response by presenting HTML UI to the user, as a user I would wonder if some website is trying to trick me or if I'm really talking to my own Bitcoin server.
The HTTP response could simply be HTML with the JavaScript equivalent of the back button, sending it back to the page. Bitcoin then pops up the Send Bitcoins dialog with the destination bitcoin address and amount already filled in. It would work just like a mailto: link that pops up a new email with the address filled in.
127.0.0.1 loopback is accessible by any user on the machine, it doesn't have per-user separation, but it's OK because it would only serve the convenience function of pre-filling the fields in a dialog. You'd still have to press Send. We'd have to make sure the Send button is not selected so it couldn't jump into the foreground while you're typing a space or enter.
That's a very pragmatic answer. I like it.
However, how would that work with the combined IP / Bitcoin Address URI (URN? URL?) scheme described here?
link
I know it's been nearly a month, sorry.
http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345
or
http://127.0.0.1:8330/?to=(bitcoinaddress)(separatorchar)1.2.3.4&amount=200.00
But as long as the link is already doing the typing for you, I don't see much benefit in using a domain address instead of bitcoin address. With a bitcoin address, the user can't send an unidentified payment. They can't send payment until they've been given a correct bitcoin address to send to.
What would be nice about sending by domain is you could visually verify who it's going to.
A more crucial issue is what if the browser isn't allowed to connect to 127.0.0.1:
https://bitcointalk.org/index.php?topic=63.msg1589#msg1589
and if that's true, then what about that example freenet link that had 127.0.0.1 in it?
I think that hiding the complexity of Bitcoin addresses from the casual user is a good thing. Barring that, it should be possible to embed an observable but unalterable message with address transactions. Is there some reason this is technically infeasible?
I think you're misunderstanding the issue. My browser will always be able to go to 127.0.0.1 (barring some strange IE settings or a virus). If I type the address into the URL bar or click a link, it will work fine. However, it isn't possible to use Javascript to complete POST requests between domains (or ports on the same domain).
Try clicking this link:
http://127.0.0.1/
You probably don't see anything (unless you're running a web server on your system), but the browser happily tries to take you there.
XMLHTTPRequest is what we were discussing in that other thread.
Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.
You could do an iframe that pointed to something like http://127.0.0.1:8330?pay=domain.com&amount=x&return=<wheretoreturn.php> and then that iframe would contain a little bitcoin interface stating how much & who you're paying and a button to confirm or cancel the payment. If you confirm the payment then it sends the coins to the domain and then redirects to the return value in the query string. bitcoin could add a ?paid=true or ?paid=false to the return location as well so the return script on the domain could then check if it received the payment correctly, or cancel the order.
Edit: the bitcoin interface should also have a password before you can confirm the payment. Otherwise you could scan for port 8330 being open on anybody and then automatically have it send payments.
That's not exactly true. At the moment, Bitcoin only binds RPC to the loopback interface, 127.0.0.1. I would assume that this web interface would be the same. However, there SHOULD be a password to prevent trojans from trivially sending your wallet away. Wallet encryption needs to happen, too.
That's what I thought too.
Now I'm hearing a report that it IS possible for javascript to do a cross-domain POST request to 127.0.0.1. Not other domains, but just specifically to that one. Great...
If this is the case, then do not use the -server switch or bitcoind on a system where you do web browsing.
I'll get started on adding the password field.