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. 
Topic: Bitcoin URL scheme: have any proposals been adapted? - page 2. (Read 2900 times)
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 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.
Quote
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.Quote
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.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.
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!
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!
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
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.
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
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
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.
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.
bump...
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.
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.
Jump to: