Bitcoin URL scheme: have any proposals been adapted?

[wumpus]

For my GUI I'd like to support drag and dropping or pasting bitcoin payment links, to make it possible to automatically fill in destination address, recipient label and amount.

Has any "standard" for these been defined yet? I found various topics in my search, but I'd like to know if any proposals are in active use.

[1713998387]

1713998387

[1713998387]

1713998387

[1713998387]

1713998387

[wumpus]

bump...

[kjj]

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.

[wumpus]

Thanks! The beginning of that page sounds sensible.

Except for the last part, why all the crazy stuff with exponents at all? Why not simply a BTC amount in pre-defined fashion "1.23" for "1.23 bitcoins". One way to represent one thing.

What does it matter what unit it is represented in in a URL? And why amountdecimal, amounthex...  eek

[kjj]

Thanks! The beginning of that page sounds sensible.

Except for the last part, why all the crazy stuff with exponents at all? Why not simply a BTC amount in pre-defined fashion "1.23" for "1.23 bitcoins". One way to represent one thing.

What does it matter what unit it is represented in in a URL? And why amountdecimal, amounthex...  eek

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.

[wumpus]

Then again -- the client will ask for confirmation for the whole amount, so you don't really need to read the URL.

If you do want to, you need to go to the trouble of parsing it in your head anyway.

Not that I'm against using exponents, but I'd say use one kind of representation and settle at that. Not amount=x34X and things like that.

One representation simplifies testing, which means people get it right the first time. Don't make it more complicated than it needs to be... Computers don't care but programmers (and users of buggy software) do!

[jav]

Not that I'm against using exponents, but I'd say use one kind of representation and settle at that. Not amount=x34X and things like that.

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.

[wumpus]

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.

The problem I see with that is that the Satoshi is just a current implementation detail. Later on, we might decide we want to divide up a Bitcoin even more. This shouldn't invalidate all the URLs.

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 .

That looks like the sanest approach. Easy to parse and easy to read. I think I will adapt that one as well.

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.

...agreed. The base idea of Bitcoin is already alien enough to the casual observer, this is not a place to introduce any more weird conventions.

[kjj]

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.

[wumpus]

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.

Do those few bytes (up to 7) really matter? If you'd really want to squish out every last byte, you'd also want to give the parameters shorter names.

[kjj]

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.

Do those few bytes (up to 7) really matter? If you'd really want to squish out every last byte, you'd also want to give the parameters shorter names.

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.

[Andreas Schildbach]

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.

Yes, and I implemented it this way because of the sentence "If exponent is omitted, implementations SHOULD assume X8 for decimal numbers, ..." on https://en.bitcoin.it/wiki/URI_Scheme

I planned to skip implementing the exponent extension (X), but I got various error reports from users that they could not use generated QR codes (Bit-Pay uses this syntax).

I will try to avoid implementing the hex extension (x). Hex fractional numbers just feel completely awkward, I've never used them anywhere in my computing life.

IMHO: Keep the URI format as human readable as possible. If we want to invent a compressed syntax that squeezes every bit, I'd tackle this more fundamentally by skipping the parameter based syntax completely and compressing amounts by base64-encoding their binary representation.

[kjj]

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:

Code:

([0-9]|[0-9]+\.?[0-9]*|[0-9]?\.[0-9]+)E-?[0-9]+

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

[wumpus]

And second the base unit, 1E-8 BTC is an accident of history.

Yep... we're always stuck with an offset of 8 now. So 1e-10 bitcoin would be 1X-2  :p It's all possible, but it's a pity that the "standard" was not designed with simplicity in mind.

So we have different interpretations now;
jav's client interprets amount=1.23 as 1.23 BTC
Bit-Pay would interpret that as 1.23e-8 BTC  as there is no exponent

great

[bitplane]

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.

[kjj]

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.

RFCs are written (or at least should be written) after a sizable body of working code exists.

I would feel free to ignore a spec on a wiki page, but try to avoid gratuitous incompatibilities.  In this case, adding E notation in addition to the existing X notation won't be ambiguous for many years, hopefully plenty of time for the X notation to vanish.  And as much as I hate to admit it, accepting hex values for compatibility is pretty easy, however silly it is to generate them.

[bitplane]

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

[wumpus]

I implemented drag&drop support for the simple Bitcoin URLs in my UI.

Simply make a link on the webpage <a href="bitcoin:address?label=bla&amount=1.23">Drag this to the Bitcoin client to pay</a>, and you can drag it to the client to switch to payment mode and add it to the recipients list.

Alas, dispatching based on clicking the URL would need to be implemented on a per-browser basis So don't expect this any soon.

[Gavin Andresen]

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?)

[drawoc]

Is x-btc widely used yet? If not, maybe we could modify that to everyone's liking, and make that the standard, so we don't need to worry about backward compatibility.