[POLL 2/3] Bitcoin: URI refactor? Exponents (poll reset Apr 21 to clarify option

[Luke-Jr]

Assuming they use high-level amounts, should Bitcoin: URIs support only present-day common-use BTC quantities, or should people be able to adapt it over time to different sizes?

Should Bitcoin: URIs use low-level or high-level units?

If you want to request/bill for 10.25 BTC, you (or your shopping cart) would write:

• Only support present-day standard units: bitcoin:youraddress?amount=10.25
• Optionally support specifying exponent: bitcoin:youraddress?amount=10.25 or bitcoin:youraddress?amount=10.25e8
• Require specifying exponent: bitcoin:youraddress?amount=10.25e8

If you want to request/bill for 1.5 mBTC (milli-BTC), you (or your shopping cart) would write:

• Only support present-day standard units: bitcoin:youraddress?amount=0.0015
• Optionally support specifying exponent: bitcoin:youraddress?amount=0.0015 or bitcoin:youraddress?amount=1.5e5
• Require specifying exponent: bitcoin:youraddress?amount=1.5e5

If you want to request/bill for 10.2 TBC (TonalBitcoin), you (or your shopping cart) would write:

• With hex support:
• Only support present-day standard units: bitcoin:youraddress?amount=x10.2
• Optionally support specifying exponent: bitcoin:youraddress?amount=x10.2 or bitcoin:youraddress?amount=x10.2x4
• Require specifying exponent: bitcoin:youraddress?amount=x10.2x4
• Without hex support:
• Only support present-day standard units: bitcoin:youraddress?amount=0.01056768
• Optionally support specifying exponent: bitcoin:youraddress?amount=0.01056768 or bitcoin:youraddress?amount=1056768e0
• Require specifying exponent: bitcoin:youraddress?amount=1056768e0

If you want to request/bill for 1 ᵐTBC (mill-TonalBitcoin), you (or your shopping cart) would write:

• With hex support:
• Only support present-day standard units: bitcoin:youraddress?amount=x1000
• Optionally support specifying exponent: bitcoin:youraddress?amount=x1000 or bitcoin:youraddress?amount=x1x7
• Require specifying exponent: bitcoin:youraddress?amount=x1x7
• Without hex support:
• Only support present-day standard units: bitcoin:youraddress?amount=2.68435456
• Optionally support specifying exponent: bitcoin:youraddress?amount=2.68435456 or bitcoin:youraddress?amount=268435456e0
• Require specifying exponent: bitcoin:youraddress?amount=268435456e0

[1714057951]

1714057951

[1714057951]

1714057951

[1714057951]

1714057951

[theymos]

It should only support current units for now. Support for other units can be added later if they are needed.

[Luke-Jr]

Poll reset to allow revoting now that clarifications have been made.

[[Tycho]]

Optionally support specifying exponent: bitcoin:youraddress?amount=10.25 or bitcoin:youraddress?amount=10.25e8

This is VERY misleading. Some people definitely will think that 10.25e8 is 1025000000 BTC.

[BitterTea]

Optionally support specifying exponent: bitcoin:youraddress?amount=10.25 or bitcoin:youraddress?amount=10.25e8

This is VERY misleading. Some people definitely will think that 10.25e8 is 1025000000 BTC.

The user is not expected to interpret the data in the URI, that is the job of the client software which handles the request. Bitcoin should show the amount in whatever format it shows other amounts.

[ByteCoin]

Optionally support specifying exponent: bitcoin:youraddress?amount=10.25 or bitcoin:youraddress?amount=10.25e8

This is VERY misleading. Some people definitely will think that 10.25e8 is 1025000000 BTC.

It's not? If you're going to make something look like scientific notation by using "e" then 10.25e8 had better be 1025000000 BTC otherwise at least have the decency to choose a different letter like "z" or possibly a non letter.

The user is not expected to interpret the data in the URI, that is the job of the client software which handles the request. Bitcoin should show the amount in whatever format it shows other amounts.

If that's true then why does the URI look like it means something rather than just being gibberish?

The fact that the URI is suggestive of a meaning when viewed by a human creates an obligation that the meaning suggested should not be misleading. If the URI were really only for the consumption of the client software then you should just take the data to be conveyed in binary form and then use an efficient encoding into the supported character set.

ByteCoin

[weavejester]

Optionally support specifying exponent: bitcoin:youraddress?amount=10.25 or bitcoin:youraddress?amount=10.25e8

This is VERY misleading. Some people definitely will think that 10.25e8 is 1025000000 BTC.

But at least it's misleading in the right direction. If someone makes a mistake and writes:

bitcoin:address?amount=10

Then they'll send 10 nBTC, far less than they originally thought. This is annoying, but no additional money has been lost.

But if we use the "human-readable" format, we'll run into problems with people who use a comma to indicate a decimal place. For instance, someone might write:

bitcoin:address?amount=10,00

They'd think they were giving 10, but in fact they're giving someone 1000 BTC instead.

Now we could ensure that commas are not allowed in the amount, but even if the specification explicitly forbids it, we may find that a lazy programmer just uses a standard "parseInt" format and forgets to force the locale to US.

The "human readable" syntax also has the problem of only being human readable for people who use the English number format, which in my view lessens its advantage.

And finally there's the problem of future proofing. If Bitcoins become popular, then everyone will be writing "amount=0.00123", which is no more readable than "amount=1.23e5".

[nphard]

Optionally support specifying exponent: bitcoin:youraddress?amount=10.25 or bitcoin:youraddress?amount=10.25e8

This is VERY misleading. Some people definitely will think that 10.25e8 is 1025000000 BTC.

I strongly agree.  I didn't even realize he was using scientific notation wrong until you pointed it out. I assume this will cause more confusion than desired.  Just throw a negative sign in there.

[xf2_org]

Paypal's API uses decimals as humans might expect, and the world has not ended.

[weavejester]

Paypal's API uses decimals as humans might expect, and the world has not ended.

Perhaps I'm overreacting

But... Paypal's API doesn't allow for irreversible transactions, and isn't as easy to implement as just sticking a URL on a page.

Still, I guess the "Send Coins" dialog would offer confirmation in the user's native number format. Perhaps that's enough?

[Luke-Jr]

I didn't even realize he was using scientific notation wrong until you pointed it out. I assume this will cause more confusion than desired.  Just throw a negative sign in there.

You don't need to understand the URI. Only software does that. The point is for humans to be able to write URIs-- however they feel is convenient. Also, it's not "wrong", nor is it a negative exponent. All real bitcoin amounts are integers.

[error]

In what circumstances are humans going to be writing bitcoin URIs? This is definitely not something I foresee end users doing.

[xf2_org]

In what circumstances are humans going to be writing bitcoin URIs? This is definitely not something I foresee end users doing.

Pasting a donation address into a webpage will be common, or creating simple "send 20 BTC to me" URIs.

[Luke-Jr]

In what circumstances are humans going to be writing bitcoin URIs? This is definitely not something I foresee end users doing.

Have you ever typed a http URL into a browser?

Would you do it if it was something like http://subdomain=www&domain=example&tld=com/ ? What about the same but all symbols in tonal presentation of corresponding hex numbers?

That what proposed bitcoin URI scheme is trying to get us to do.

No, it isn't. It's bitcoin:somestupidlyunreadableaddress?amount=50 if you want decimal, or the same, but x50 if you want hexadecimal. You can do WHICHEVER YOU WANT.

(Also, it would be fairly silly to type a URN into a browser)

[Matt Corallo]

In what circumstances are humans going to be writing bitcoin URIs? This is definitely not something I foresee end users doing.

Have you ever typed a http URL into a browser?

Would you do it if it was something like http://subdomain=www&domain=example&tld=com/ ? What about the same but all symbols in tonal presentation of corresponding hex numbers?

That what proposed bitcoin URI scheme is trying to get us to do.

If the idea is so terrible, please come up with a better solution.  One that supports the OPTION of including a value and/or name and/or comment.  All of them, none of them, or any combination of them. 

[Matt Corallo]

compare:

bitcoin:1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo?amount=20.3X8&label=Luke-Jr

and

bitcoin://20.3/1KczVqwopWXQdFLe5sNQbpCq7yGSmXx2oo/Luke-Jr

why would anyone want named variables in such a simple scheme is incomprehensible to me. Why bother with all the machine only readable representations of decimal number is not clear too.  KISS.

I would actually argue that the first is more readable, except for the whole 20.3X8.  Although that is Luke-jr's bitcoin: proposal, the version that is currently in the pull request (based on Luke-jr's three polls) is just 20.3.  No exponents or tonal/hex thrown in. 
Also, I think the named variables add to the general readability.  Is Luke-Jr the comment on or name of the destination?

Although I don't directly disagree with your proposal, I see no real benefit to it over the current one.  Plus would it be worth rewriting the current, implemented, version for something like this.

P.P.S. maybe even not bitcoin: but btc:

I would argue bitcoin: is better as people who dont know what btc: is can more easily google bitcoin:, but in the end I suppose that doesn't really matter.