There is a wiki page, but I've never seen it used.  Haven't exactly been looking, but still.

It seems pretty straightforward, at least for address, amount and label, so I think you should be pretty safe implementing it if you want.  If nothing else, someone has to go first.  But if you do, please, please, please use E for the exponent instead of X.

Although URIs are not intended to be human-readable, in practice, we do it all the time.  For all the computers care, we could represent the amount as the product of a string of complex numbers (as long as the final multiplicand conjugates the rest of the sequence).  So, because the computers don't care, we should make it as human friendly as possible.  10E-9 is far more readable than 0.00000001.  SI prefix abbreviations should be pretty readable too, so in the previous example 10n.

I definitely agree. I would have been in favor of specifying the amount in Satoshis, but it is my impression that things start to move to interpret the amount as BTC directly. For example the Android Bitcoin client does that. I'm generating Bitcoin URIs for a project myself, so that is what I will go with as well. Which means to have things that look like this: bitcoin:14Z1mazY4HfysZyMaKudFr63EwHqQT2njz?amount=1.23&label=optional .

You'll have to ignore all that exponent stuff on the wiki. It annoys me a lot that it floats around there, but I haven't been bothered enough to get into an edit war with the guy who pushes this sort of stuff together with his tonal agenda.

There is one argument in favor of using E notation for the amounts.  People embed (or want to be able to embed) these URIs into QR code labels, and then scan them with cheap readers, meaning cell phones with cheap cameras.  More bits means higher resolution, which makes them less suitable for one popular intended use.

I don't know if they matter or not.  Like most things they are probably unimportant most of the time, but absolutely critical in a few cases.  Stripping the field names down to a for amount and l for label is probably a good idea in the same way.

Since you are working on the receiving end, you could always rig your client to accept short versions and long versions, plus absolute values and E notation.

By making a working implementation, and getting it out there in the wild, you are essentially defining the standard in a way that carries a lot more weight than just tossing some ideas on the wiki.

Good to know that there are at least two other projects actually using the thing.

That said, I'm going to just say this publicly.  The X notation is stupid.  First, there was already a widely known and used notation for powers of 10.  And second the base unit, 1E-8 BTC is an accident of history.  The foolishness of basing the notation on this value will become obvious just as soon as the first 128 bit client extensions show up.

The only good thing about it is that it lets people use E notation, and do it in a way that makes sense.  So, I propose the following:

Amounts that match this regex:


should be interpreted using standard E notation, based around 1 BTC.  In E notation, xEy is shorthand for x * (10 ^ y).

I agree that it seems sensible apart from the hex digits and non-standard exponent, the only virtue of the exponent is that it would discourage people from storing the values in IEEE floats, which are susceptible to rounding error. The hex thing is just plain unforgivable and should rightly be as ignored as hex floats are.

edit: the semicolon thing should also be ignored IMO. Everyone is used to ampersands whether Tim Berners-Lee likes it or not, we're used to parsing them by now.

I can see two ways around the incompatibilities, either label this as version 1.0 of the standard and rename the amount parameter to something else (send?), or have someone rewrite the entire thing, debate it, then actually submit it as an RFC to be forever set in stone.

There are also other things aside from the URI scheme that are worth defining if they haven't been already, for example an XHTML microformat for sharing addresses inline in HTML, plus a way to embed addresses in a vCard or address book.

Yeah, you make good points. I guess what's needed is for the devs of the different apps to get together and simplify the standard. Since I'm not actually doing any hacking on these projects I guess my opinion holds no weight, but it's nice to rant about them anyway

The wiki page is luke-jr's baby. Several of us are tired of having wiki-editing wars so we just ignore it.

Suggestions for a better "RFC process" are welcome; which open source project should we emulate?  (e.g. bittorrent has BEPs, python has PEPs, are there other models to follow?)