Topic: [POLL 1/3] Bitcoin: URI refactor? Low-level vs high-level (Read 3908 times)
High-level, definitely (though I'm also partial to the idea that 0.00000001 BTC should have been 1 BTC in the first place, it's too late for that now). People will accidentally enter transactions for 1/100,000,000 of their intended amount otherwise.
This hasn't been a problem for paypal or other payment APIs already deployed in the field.
Anything else violates the Principle of Least Surprise.
Anything else violates the Principle of Least Surprise.
Hmm. You have a point...
Perhaps I should just shut up until I'm sure which side of the fence I'm on. I have a feeling I'm falling for Parkinson's Law of Triviality; I should care this much about URI syntax.
Wouldn't a decent way to handle this be to add an optional units parameter?
Especially if the need for mBTC could be not too far off?
e.g., instead of
bitcoin:address?amount=0.010
a
bitcoin:address?amount=10&units=mbtc
If units= is not specified, then the default of units=btc would be assumed.
Especially if the need for mBTC could be not too far off?
e.g., instead of
bitcoin:address?amount=0.010
a
bitcoin:address?amount=10&units=mbtc
If units= is not specified, then the default of units=btc would be assumed.
.... it is how science got around the mess it found itself in in the early 1800's before Faraday sorted it out, implied/inferred unit conventions are a recipe for disaster, regardless of the context.
Specify the units and be done with it.
Edit: actually there is another incentive to explicitly specify units, a future use for the protocol maybe to send currencies other than BTC to a bitcoin account, e.g. dollars, euros, Goldau, could be possible future unit options ... (would have to be a nifty app. to do the conversion, interface with intermediary, etc, but you never know).
Wouldn't a decent way to handle this be to add an optional units parameter?
Not really, that assumes we know all possible units in advance, as it can't easily be added onto later. It also means software would need to hard-code every possible unit.
Wouldn't a decent way to handle this be to add an optional units parameter?
Especially if the need for mBTC could be not too far off?
e.g., instead of
bitcoin:address?amount=0.010
a
bitcoin:address?amount=10&units=mbtc
If units= is not specified, then the default of units=btc would be assumed.
Especially if the need for mBTC could be not too far off?
e.g., instead of
bitcoin:address?amount=0.010
a
bitcoin:address?amount=10&units=mbtc
If units= is not specified, then the default of units=btc would be assumed.
This hasn't been a problem for paypal or other payment APIs already deployed in the field.
Anything else violates the Principle of Least Surprise.
Anything else violates the Principle of Least Surprise.
+1
Y'all have heard of the KISS principle, right?
The problem with a "high-level" human readable is that you'd either have to localize it (e.g. 10,00 vs 10.00), or agree on a single format.
This hasn't been a problem for paypal or other payment APIs already deployed in the field.
Anything else violates the Principle of Least Surprise.
I love it ... nothing better than a good stoush over units .... carry on.
My money is on satoshi.
After some thought, I'm going for low-level, because I don't think "high-level" is possible without the potential for major user mistakes.
The problem with a "high-level" human readable is that you'd either have to localize it (e.g. 10,00 vs 10.00), or agree on a single format.
If you're going to localize it, you need to embed the user's locale in the URI scheme, otherwise "10.000" could either mean "10" or "10000". Adding a locale in seems over complex and prone to mistakes. And it's ugly.
If we decide to agree on a single format, such as using a period to denote the decimal place, then it ceases to become "human readable", and instead becomes "readable for people who live in these countries". This is also bad, because it means that anyone from countries with a different number system might send the wrong amount by mistake.
So in my view you cannot have a human-readable "high-level" syntax, because different countries have different ideas of what that means. One of the options of this poll simply isn't possible to have unless we want people to accidentally send 10,000 bitcoins to a person who only wanted 10.000.
Therefore the only option is to use the "low-level" approach of using nano-bitcoins.
The problem with a "high-level" human readable is that you'd either have to localize it (e.g. 10,00 vs 10.00), or agree on a single format.
If you're going to localize it, you need to embed the user's locale in the URI scheme, otherwise "10.000" could either mean "10" or "10000". Adding a locale in seems over complex and prone to mistakes. And it's ugly.
If we decide to agree on a single format, such as using a period to denote the decimal place, then it ceases to become "human readable", and instead becomes "readable for people who live in these countries". This is also bad, because it means that anyone from countries with a different number system might send the wrong amount by mistake.
So in my view you cannot have a human-readable "high-level" syntax, because different countries have different ideas of what that means. One of the options of this poll simply isn't possible to have unless we want people to accidentally send 10,000 bitcoins to a person who only wanted 10.000.
Therefore the only option is to use the "low-level" approach of using nano-bitcoins.
xf2_org == jgarzik?
Yes, its his new site, so he's pimping it.Why does this need to be human readable?
People need to be able to create them very easily and preferably read them as well. Though reading isnt strictly necessary. I like to be able to hover over my links and see what they are before clicking them.Now, how would you interpret 5,005? Is that five thousand and five bitcoins, or five and one two hundreths of a bitcoin? It depends on the locality of the user who created the link.
5 BTC + 0.005 BTC. You should not have and ,s or .s in a number that is not the decimal point. Not just in this case, in all cases where you care at all about internationalization (ie anywhere on the internet). 
xf2_org == jgarzik?
Why does this need to be human readable?
Click this link in my sig to donate!
Now, how would you interpret 5,005? Is that five thousand and five bitcoins, or five and one two hundreths of a bitcoin? It depends on the locality of the user who created the link.
Completely disagree. It is easy for a program to read a human readable number (there is already a function in util.cpp). But its a URL, many, many people will be writing them in Forum sigs, websites, etc.
Why does this need to be human readable?
Click this link in my sig to donate!
Code:
Now, how would you interpret 5,005? Is that five thousand and five bitcoins, or five and one two hundreths of a bitcoin? It depends on the locality of the user who created the link.
When did Jgarzik say this? It seems to me that he just does not like Luke pushing tonal.
On IRC, plus here:I strongly urge the adoption of human-friendly conventions of which everyone is already familiar: 50.00 BTC, 0.01 BTC, etc. These are already in wide use on websites and in software, both bitcoin and non-bitcoin (such as paypal's API).
You're not understanding that the URI being human readable has little purpose, but it definitely has to be computer readable. How else do you propose that Bitcoin (or whatever software) parse it?
Completely disagree. It is easy for a program to read a human readable number (there is already a function in util.cpp). But its a URL, many, many people will be writing them in Forum sigs, websites, etc. I'm with Jgarzik on this one. Make it human readable. Not computer readable, not tonal geek readable, human readable
When did Jgarzik say this? It seems to me that he just does not like Luke pushing tonal.
You're not understanding that the URI being human readable has little purpose, but it definitely has to be computer readable. How else do you propose that Bitcoin (or whatever software) parse it?
I'm with Jgarzik on this one. Make it human readable. Not computer readable, not tonal geek readable, human readable and even human writeable. Take a hint from ed2k URI's.
And one question... why would you want variable names in URI when there are like two variables?
http://subdomain=www&domain=example&tld=com/ this is what you are proposing.
bitcoin://0.01/1zdsffssdfsfsdfsfdsdf - that's how should it look like
The problem with that is you can specify any of the variables but don't have to specify and standard set. I might not want to specify amount, but want to specify my name, or maybe the other way around. Plus it makes them more human readable. And one question... why would you want variable names in URI when there are like two variables?
http://subdomain=www&domain=example&tld=com/ this is what you are proposing.
bitcoin://0.01/1zdsffssdfsfsdfsfdsdf - that's how should it look like
That has been handled by so many programs fairly well over the years, I don't think that is a problem any more.
C#, en-US localization...
decimal.Parse("1,2")
-> 12
That has been handled by so many programs fairly well over the years, I don't think that is a problem any more.
C#, en-US localization...
decimal.Parse("1,2")
-> 12
Well, if we're defaulting to decimal, will this be a problem?
User in Europe creates a bitcoin: link for two and a half BTC. They may enter this as "bitcoin:...?amount=2,5".
User in USA clicks this link. Depending on their regional settings and the programming language of the parsing application, "2,5" may not be the same as "two and a half".
That has been handled by so many programs fairly well over the years, I don't think that is a problem any more. User in Europe creates a bitcoin: link for two and a half BTC. They may enter this as "bitcoin:...?amount=2,5".
User in USA clicks this link. Depending on their regional settings and the programming language of the parsing application, "2,5" may not be the same as "two and a half".
Well, if we're defaulting to decimal, will this be a problem?
User in Europe creates a bitcoin: link for two and a half BTC. They may enter this as "bitcoin:...?amount=2,5".
User in USA clicks this link. Depending on their regional settings and the programming language of the parsing application, "2,5" may not be the same as "two and a half".
User in Europe creates a bitcoin: link for two and a half BTC. They may enter this as "bitcoin:...?amount=2,5".
User in USA clicks this link. Depending on their regional settings and the programming language of the parsing application, "2,5" may not be the same as "two and a half".
What do you think about these example? 
bitcoin:address?type=low&amount=1
bitcoin:address?type=high&amount=x1
Simple: it's possible to put the type of URI.
It can also be chose to use "low" by "default".
If nothing is specified, then it's low
So everyone is happy.
This will help also to understand which one will be used more on next months/years.
I think that far overcomplicates it.bitcoin:address?type=low&amount=1
bitcoin:address?type=high&amount=x1
Simple: it's possible to put the type of URI.
It can also be chose to use "low" by "default".
If nothing is specified, then it's low
So everyone is happy.
This will help also to understand which one will be used more on next months/years.
In general, high level is better for numbers intended for human use, whereas I think low level is better for numbers intended for computer use. A URI is kind of a mix between the two, as a human creates the link, a human clicks on it, but a computer parses the data.
So true. However, I think we should fall back on human. Its just as easy for the computer to do either (even if one is ideal), but its not as easy for a human to convert to base units. 
What do you think about these example?
bitcoin:address?type=low&amount=1
bitcoin:address?type=high&amount=x1
Simple: it's possible to put the type of URI.
It can also be chose to use "low" by "default".
If nothing is specified, then it's low
So everyone is happy.
This will help also to understand which one will be used more on next months/years.
bitcoin:address?type=low&amount=1
bitcoin:address?type=high&amount=x1
Simple: it's possible to put the type of URI.
It can also be chose to use "low" by "default".
If nothing is specified, then it's low
So everyone is happy.
This will help also to understand which one will be used more on next months/years.
Jump to: