Bitcoin Forum

.

I posted a similar plan just recently, and in reply someone told me that details of a URI scheme are already on the official wiki... sorry I don't have the link.

Edit: Here it is... https://en.bitcoin.it/wiki/URI_Scheme

I see what you're saying, however a URL is a Uniform Resource Locator... i.e. It's for locating a resource (retrieving data). That's why I don't think the URL-look is appropriate for actions, like making payments.

Edit: Also, in your example, how would you launch the payment window with a blank amount? (eg. A link to Luke-jr's bitcoin address, with his name pre-filled, but with an amount to be chosen by the person clicking the link).

I dont see any reason to reinvent a standard which already works for such a small addition.  If a user clicks a bitcoin: link, the bitcoin client should ensure the user knows how much and to who the bitcoins will be transferred, making the url/i human-readable isn't a huge deal.  Also, several programs already use the existing standard, why change it now?  Lastly, in your standard, how does a client differentiate between a user's name and a transaction comment (the order it is specified in is not very useful especially if someone wants to only specify one of the two).  The same applies for the amount for a donation, I dont want to specify how much you have to donate but the user should chose.

This syntax is really awful... and the amount format... no comment.
We don't need such a complicated one... I only see it as an ego valorization for the creators.

Adding variable names in uri : why not, if we need to extend the rfc later (for example, if comments are not included in the blockchain but manageable by a bitcoin plugin, we would need a way to say it to the bitcoin client. We may need to add a server name too), it will be needed.

bitcoin:// or bitcoin:
- bitcoin:// : more readable by humain (better separation)
- bitcoin: : used for mailto:, more standard

So, should we prefer a more readable syntax or a more standard one ? (excepting for the amount, i insist...)

The hex notation is optional, you can use decimal amounts too.

bitcoin: or bitcoin:// why not both, just remove the ? and it should work fine (maybe add the ? to after the address?).  Plus again bitcoin: is already used so why not stick with it?

The only real problem I have with the current version is the use of X8 after numbers to indicate 10^8.  However, if you read the documentation closely and look at the current implementations, using 10.8 is valid just not recommended.  That said, there is an important reason for specifying X8, what if someone wants to change the decimal place in the future?  Do we need to change all url/is just to support that?

I thought something quite opposite... I thought the reason for using bitcoin: was that it's more psychologically acceptable for a layman due to similarity to mailto:

I disagree, I think the best way to approach this is to examine the current URI scheme which is already implemented in several programs and to simply use that, why change what isn't broken?

Here are the 2 proposed URI scheme :
- https://en.bitcoin.it/wiki/URI_Scheme
- https://en.bitcoin.it/wiki/X-btc

The second one proposes more actions than just "pay" :
- store an address in the address book,
- add a public/private key pair (and rescan blockchain),
- add a transaction (full data or just tx id ?)

Do we need some are all of this ?

All this endless talking about the Perfect URI Scheme is very nice.

So is anybody, you know, actually working on IMPLEMENTING something?

You'll need to know how to write browser plugins for Firefox/Safari/Chrome/IE and figure out how to pass arguments to a running bitcoin/bitcoind and know how the bitcoin/bitcoind will prompt the user to confirm the transaction.  Oh, and figure out how to get the browser plugin(s) installed when bitcoin is installed.

Deciding on whether it is bitcoin:address or bitcoin://amount/address is the easy part, and I think whoever actually does the work of making this happen should define the standard.

I've got a working implementation of a bitcoin: URI handler in WalletBuddy. I assume that users won't be running Bitcoin all the time, so when such a link is clicked, it is sent to the payment queue. Any number of payments can be released from the payment queue to Bitcoin whenever Bitcoin is running.

I'm still working on some changes and fixes, but I hope to release an update with this functionality as well as some better documentation soon (hopefully this week).

There is also a chrome extension which implements bitcoin: URI properly using RPC.  Again, I dont think URI's need to be/are ever human readable.  Its up to the client to make the tx human readable before it sends any BTC.  How many links on the internet are readable by any average person and how many people actually read their links before clicking them?

Spesmilo also supports bitcoin: URIs

Any updates on this? I'd like to offer a 50BTC bounty for implementing bitcoin: URIs in the main client.

About implementation - I thought that implementing URI handlers is not a job for browser extensions, but the application itself registers the protocol in users operating system. So it's only a matter of implementing the protocol registration mechanism in Bitcoin client and we're done.

Registering is not even half the problem. Once it registers with the OS, it must actually handle such links as well.

This issue is of some interest to me, so I'll try putting together a branch with a minimal implementation of URI handling. I'll initially support the "bitcoin:<address>" syntax, but without the additional parameters, which can be added later. URI handling will require RPC turned on, and I'm not going to attempt OS protocol registration for now.

Does this satisfy your bounty (will MIT-license if so)?
http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/commitdiff/d88d78aa8ad6f085360e77294b2b0d7081ad4710
http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/commitdiff/7eb88f0cb6af6dd106fbec818f81af9b13318380

To test:

• git checkout -b temporary_test_branch
• git pull git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git bitcoinuri

Note this does NOT support the "label" and "message" parameters, as I didn't see a place for those in the send dialog. It also makes no attempt to register bitcoinuri with browsers (which all work differently in this regard).

To donate or pay bounty: bitcoin:19ut7h2sp9jKf5dpnK36FCPGu8L1cHnPSE (MIT licensing will commence when this reaches 50 BTC)

P.S. Please fix forum to accept bitcoin URIs in links ;)

Looks like I was beaten to the punch :)

Final and MIT licensed version:
http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/commitdiff/d32bebafd41fac885055274ebf6142b960d1345e

I put a lot of work into doing this perfectly, at way below cost from what I would usually charge for programming, so I would like to request it only be merged as-is, with any pre-merge changes made by me. Specifically, I have concerns about jgarzik and tcatm trying to break the entire URI specification 3 months after it's been implemented in every* client except their own. Obviously, my request still leaves them room to do so post-merge, but at least this way people who have problems can be pointed to a specific breaking revision to revert to fix it.

And to clear up any FUD in advance: the URI spec and implementation herein do not in any way constitute "Tonal support". The changes to the spec irrationally demanded by the trolls involves making it absurdly more difficult for Tonal users (at no gain to Decimal users), and also makes it more difficult/annoying for Decimal users in the future when everyone is using milli- or micro-bitcoins. At the same time, their change is effectively attempting to repeat one of the known (and agreed by a general consensus, in numerous other forum threads) design flaws in the JSON-RPC protocol.

Thanks for quick completion, Luke!

You can test the URIs on Firefox (3.5 and above):

• Type about:config into the Location Bar (address bar) and press Enter.
• Right-click -> New -> Boolean -> Name: network.protocol-handler.expose.bitcoin -> Value -> false
• Create an html page with a bitcoin-link: <a href="bitcoin:bitcoinaddress">payment link</a>
• Click the link and you will be asked which application to open it with. Open with the bitcoinuri binary.

Working on some slight modifications to make it pull-able and will send in a pull request when I'm done.  (mostly removing tonal/hex stuff which jgarzik specifically objected to and adding support for Windows and OSX)

We've already got ParseMoney in util.cpp, this patch adds parseNumber/uriParseAmount.  Having more than one way to convert strings into bitcoin amounts is not a good idea, in my humble opinion.

Also, instead of having a separate executable it would be more 'wxbitcoin-like' to have one executable that acts as either client or server depending on what command-line arguments are given.  The problem with two executables is you'll have clueless users double-clicking on bitcoinuri.exe and then wondering why it doesn't do anything.

I do like the use of boost message queues to communicate.

Problem is that the URI Spec uses a different method for encoding values (for future compatibility) specifically using exponents to allow uBTC to be specified as 1X2 or other similar situations.  IMHO this is needless and is overcomplicated for no reason, but it is already the way it is done and I don't see anyone complaining too much here so unless you highly disagree, I don't see anything wrong with it.

Working on changing that :)

This is exactly what I object to.
I agree, except that ParseMoney does not comply with the spec, and is not suitable to URIs.The problem with a single executable, is that the OS will load and link everything for every URI click.

Oh, there are complaints aplenty about the URI spec.

Google for #bitcoin-dev IRC logs...

I don't see the problem of allowing the URI to support multiple amount formats. You are free to only use decimal if you like.


What are the specific complaints? Spending a few minutes Googling yielded chat logs, but nothing that I can connect to this discussion.

Please read the ones from tonight.

http://veritas.maximilianeum.ch/bitcoin/irc/logs/2011/04/20

Here's how it appears to me...

Jgarzik doesn't realize that the "tonal support" in this patch is merely allowing conversion of tonal specified units in the URI to Satoshis for internal use. It's not adding anything to do with displaying or computing tonal numbers into the actual client. I think having flexibility in the URI is a great thing. Why not allow people who use the URI on their sites to specify the amount in whatever format they choose? It will still display a decimal amount in the client.

5.0 == 5X8 == 500000000X0 == x1DCD6500X0 == x1DCBX4 == x1DCB

I normally dislike Luke's evangelising of tonal, but in this case I don't see any ulterior motive on his part.

Maybe it's just me, but I didn't understand that 5X8 meant 500,000,000 until I read the specification in more detail. On the other hand, I would have instantly understood 5e8, because it's a standard convention. So at least in my case, there is a disadvantage to using this syntax, as it's less discoverable. I'd also point out that the difference in character height makes it easier to distinguish the exponent and multiplier in 5e8, whereas 5X8 is a little harder to read.

Perhaps I'm incorrect, but my guess is that the number of people who are familiar with the 5e8 convention is considerably greater than the amount of people who prefer using hexadecimal notation for monetary values. It's my opinion that using a syntax that disadvantages the majority, even if only slightly, is not worth the cost if only a very few people benefit.

If we really must have hexadecimal notation, can't we use a different exponent marker for hexadecimal values? e.g. 500e8 for decimals, and 0xf00x8 for hexadecimal.

Actually, I agree with this. Perhaps "e" or "X" could be used to denote the exponential unit.

Treating 'e' like this only for decimal values would not break backward compatibility. No objection from me.

Quote from the wiki talk page:

Which is why 'e' would work for decimal, as Luke said.

But now that I think about it, 'e' isn't in the tonal alphabet, right?

Correct, but the URI scheme doesn't support tonal.

Vladimirs scheme looks straightforwards and useful to me. Though I would add an action param to make this clear it was a "Send". (SEND/RECV)
The scheme needs actions, a way to do more than just send. I don't worry too much about the human readable part, but it is nice when all human legible parts are clustered together. Also, To you guys, the bitcoin address probably jumps out as such, but to most, it looks like scrambled eggs. So I would probably put the amount after the address. It does seem good to have some sort of version number in there, essentially making clear what url format is in use.  Easy to move forwards by revving the version, easy to handle old requests as they come in tagged.

See x-btc, which has actions and other useful features:
https://en.bitcoin.it/wiki/X-btc

I find Valdimirs URI scheme RFC very straight-forward and easy to understand,
thus very powerful.

I strongly recommend to implement this RFC asap in the client, since
this makes web payments / donations really easy and bitcoin very interesting
to merchants.

URI spec is rfc3986 from 2005, supersedes rfc2396 from 1998.

Double-slashes aren't right. By convention they mean 'next part describes a hierarchical-authority-root affecting the rest of the interpretation'. In 'http', a host is the 'authority'. For a suggested bitcoin transaction, neither the amount nor destination address is really the 'authority'. For a completed transaction, maybe the originator is the 'authority'.. but people seem to want these URIs as triggers for next-actions not back-references to past-actions, though a back-reference format to point to blocks, transactions, keys maybe useful too.

Slashes to separate fields by hard ordering are fragile and contrary to other URI precedents.

Better to avoid slashes unless there's a real nested hierarchy. The proposal on the wiki has the right idea.

People adopt simple things, period.

And that's why we all reached this site via the AOL keyword 'bitcoin'.

However the solution will look like. Either with ? or / or : or @.

It's a critical feature request for the whole bitcoin economy, especially for merchants.

So please implement it ASAP :)

great!

Sections 3 and 3.2 of rfc3986 strongly suggest '//' be reserved for introducing an Authority "so that governance of the name space defined by the remainder of the URI is delegated to that authority" and even says "When authority is not present, the path cannot begin with two slash characters ("//")." Applied to your proposal, that makes the amount or the receiver the Authority.

Putting the important things first is good, it just needs different separators. Also, maybe 'bitcoin:' should just be an address indicator.

To trigger a full transaction, we could also think bigger. Why not a 'payto:' URI that works first and best for bitcoin transactions because they're so easy to represent online but could also subsume other currencies and destinations? For example..

payto:0.02btc|bitcoin:19bF4Xq2bJwVKzGmbq5pxmkgYkE1KnXngp#bitcoin+RFC+donation+to+vladimir

payto:24.99usd|https://paypal.com/user/exampleman#payment+for+1btc

This seems to be inferior to the already specified bitcoin: URI.

bitcoin:19bF4Xq2bJwVKzGmbq5pxmkgYkE1KnXngp?amount=0.02&message=bitcoin+RFC+donation+to+vladimir

How is it any more readable to have fields separated by random symbols as opposed to specified in name/value pairs?

Not to mention that links aren't/don't have to be readable by a human, just a computer. Most of the time links would be done like this anyway:

Click to Donate! (http://19bF4Xq2bJwVKzGmbq5pxmkgYkE1KnXngp?amount=0.02&message=bitcoin+RFC+donation+to+vladimir)