wumpus (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 01, 2011, 05:40:45 PM |
|
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.
|
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
|
|
|
wumpus (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 04, 2011, 03:53:38 AM |
|
bump...
|
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1026
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 04, 2011, 04:46:58 AM |
|
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.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
wumpus (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 04, 2011, 05:12:13 AM |
|
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
|
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1026
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 04, 2011, 05:36:51 AM |
|
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.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
wumpus (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 04, 2011, 05:43:36 AM |
|
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!
|
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
|
|
|
jav
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 04, 2011, 07:56:44 AM |
|
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 (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 04, 2011, 09:58:48 AM |
|
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. 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.
|
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1026
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 04, 2011, 11:18:27 AM |
|
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.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
wumpus (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 04, 2011, 11:28:39 AM |
|
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.
|
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1026
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 04, 2011, 01:04:56 PM |
|
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.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
Andreas Schildbach
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 04, 2011, 01:40:45 PM |
|
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_SchemeI 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
Legendary
Offline
Activity: 1302
Merit: 1026
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 04, 2011, 03:03:54 PM |
|
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: ([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).
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
wumpus (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 04, 2011, 03:18:19 PM |
|
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 ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif)
|
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
|
|
|
bitplane
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 05, 2011, 01:34:46 AM |
|
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
Legendary
Offline
Activity: 1302
Merit: 1026
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 05, 2011, 02:12:09 AM |
|
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.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
bitplane
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 05, 2011, 02:52:36 AM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
wumpus (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 07, 2011, 02:49:43 PM Last edit: August 07, 2011, 03:19:43 PM by John Smith |
|
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 ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) So don't expect this any soon.
|
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
|
|
|
Gavin Andresen
Legendary
Offline
Activity: 1652
Merit: 2300
Chief Scientist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 07, 2011, 03:16:08 PM |
|
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?)
|
How often do you get the chance to work on a potentially world-changing project?
|
|
|
drawoc
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 168
Merit: 100
Firstbits: 175wn
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 07, 2011, 05:23:31 PM |
|
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.
|
Donate: 175WNXmJ1WVhFgVGKUqEhYtAQGRYAvqPA
|
|
|
|