URI-scheme for bitcoin
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. Cheesy
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.
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. Grin
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
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:
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:
- http://infomesh.net/2001/09/urischemes
- http://www.search.com/reference/Magnet:_URI_scheme
- http://magnet-uri.sourceforge.net/
- http://magnet-uri.sourceforge.net/magnet-draft-overview.txt
- http://www.w3.org/Addressing/schemes
- http://www.w3.org/Addressing/schemes#Registration
Any ideas/comments/feedback is/are welcome. Wink Steve
This just in:…
It seems there is, as it just so happens, an existing protocol precisely for interacting with stored data files on freenet Grin <YAY!> Grin
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. Wink
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
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.
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 thing so 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.
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.
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:
- https://www.myonlineshop.com/purchaseDetails/123456
- http://pastie.org/942292
- freenet://[a ressource on freenet]/
- http://kpvz7ki2v5agwt35.onion/wiki/index.php/PurchaseDetailsHere
- magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C
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.
Quote from: Karmicads on May 01, 2010, 06:06:53 AM
A freenet URI is like this:
There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=
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.
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=;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]topic 158]
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=
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: topic 63
and if that’s true, then what about that example freenet link that had 127.0.0.1 in it?
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: topic 63
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.
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.
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.
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.
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.