[POLL 1/3] Bitcoin: URI refactor? Low-level vs high-level

[BitterTea]

xf2_org == jgarzik?

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:

<a href=http://bitcoin:1J86yuX5qTZwAzx7EC5ik7bYYDEtyrCenM?label=BitterTea&message=test_do_not_use&amount=5,005>Click this link in my sig to donate!</a>

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.

[1715389039]

1715389039

[1715389039]

1715389039

[1715389039]

1715389039

[Matt Corallo]

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

[weavejester]

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.

[marcus_of_augustus]

I love it ... nothing better than a good stoush over units .... carry on.

My money is on satoshi.

[xf2_org]

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.

[Gavin Andresen]

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.

+1

Y'all have heard of the KISS principle, right?

[Stephen Gornick]

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.

[Luke-Jr]

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.

[marcus_of_augustus]

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.

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

[weavejester]

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.

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.

[Ian Maxwell]

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.