.

[Luke-Jr]

Final and MIT licensed version:
http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/commitdiff/d32bebafd41fac885055274ebf6142b960d1345e

I put a lot of work into doing this perfectly, at way below cost from what I would usually charge for programming, so I would like to request it only be merged as-is, with any pre-merge changes made by me. Specifically, I have concerns about jgarzik and tcatm trying to break the entire URI specification 3 months after it's been implemented in every* client except their own. Obviously, my request still leaves them room to do so post-merge, but at least this way people who have problems can be pointed to a specific breaking revision to revert to fix it.

And to clear up any FUD in advance: the URI spec and implementation herein do not in any way constitute "Tonal support". The changes to the spec irrationally demanded by the trolls involves making it absurdly more difficult for Tonal users (at no gain to Decimal users), and also makes it more difficult/annoying for Decimal users in the future when everyone is using milli- or micro-bitcoins. At the same time, their change is effectively attempting to repeat one of the known (and agreed by a general consensus, in numerous other forum threads) design flaws in the JSON-RPC protocol.

[1714108630]

1714108630

[1714108630]

1714108630

[1714108630]

1714108630

[sirius]

Thanks for quick completion, Luke!

You can test the URIs on Firefox (3.5 and above):

• Type about:config into the Location Bar (address bar) and press Enter.
• Right-click -> New -> Boolean -> Name: network.protocol-handler.expose.bitcoin -> Value -> false
• Create an html page with a bitcoin-link: <a href="bitcoin:bitcoinaddress">payment link</a>
• Click the link and you will be asked which application to open it with. Open with the bitcoinuri binary.

[Matt Corallo]

Working on some slight modifications to make it pull-able and will send in a pull request when I'm done.  (mostly removing tonal/hex stuff which jgarzik specifically objected to and adding support for Windows and OSX)

[Gavin Andresen]

We've already got ParseMoney in util.cpp, this patch adds parseNumber/uriParseAmount.  Having more than one way to convert strings into bitcoin amounts is not a good idea, in my humble opinion.

Also, instead of having a separate executable it would be more 'wxbitcoin-like' to have one executable that acts as either client or server depending on what command-line arguments are given.  The problem with two executables is you'll have clueless users double-clicking on bitcoinuri.exe and then wondering why it doesn't do anything.

I do like the use of boost message queues to communicate.

[Matt Corallo]

We've already got ParseMoney in util.cpp, this patch adds parseNumber/uriParseAmount.  Having more than one way to convert strings into bitcoin amounts is not a good idea, in my humble opinion.

Problem is that the URI Spec uses a different method for encoding values (for future compatibility) specifically using exponents to allow uBTC to be specified as 1X2 or other similar situations.  IMHO this is needless and is overcomplicated for no reason, but it is already the way it is done and I don't see anyone complaining too much here so unless you highly disagree, I don't see anything wrong with it.

Also, instead of having a separate executable it would be more 'wxbitcoin-like' to have one executable that acts as either client or server depending on what command-line arguments are given.  The problem with two executables is you'll have clueless users double-clicking on bitcoinuri.exe and then wondering why it doesn't do anything.

Working on changing that

[Luke-Jr]

Working on some slight modifications to make it pull-able and will send in a pull request when I'm done.  (mostly removing tonal/hex stuff which jgarzik specifically objected to and adding support for Windows and OSX)

This is exactly what I object to.

We've already got ParseMoney in util.cpp, this patch adds parseNumber/uriParseAmount.  Having more than one way to convert strings into bitcoin amounts is not a good idea, in my humble opinion.

I agree, except that ParseMoney does not comply with the spec, and is not suitable to URIs.

Also, instead of having a separate executable it would be more 'wxbitcoin-like' to have one executable that acts as either client or server depending on what command-line arguments are given.  The problem with two executables is you'll have clueless users double-clicking on bitcoinuri.exe and then wondering why it doesn't do anything.

The problem with a single executable, is that the OS will load and link everything for every URI click.

[xf2_org]

Oh, there are complaints aplenty about the URI spec.

Google for #bitcoin-dev IRC logs...

[BitterTea]

I don't see the problem of allowing the URI to support multiple amount formats. You are free to only use decimal if you like.

Oh, there are complaints aplenty about the URI spec.

Google for #bitcoin-dev IRC logs...

What are the specific complaints? Spending a few minutes Googling yielded chat logs, but nothing that I can connect to this discussion.

[Matt Corallo]

I don't see the problem of allowing the URI to support multiple amount formats. You are free to only use decimal if you like.

Oh, there are complaints aplenty about the URI spec.

Google for #bitcoin-dev IRC logs...

What are the specific complaints? Spending a few minutes Googling yielded chat logs, but nothing that I can connect to this discussion.

Please read the ones from tonight.

[BitterTea]

Please read the ones from tonight.

http://veritas.maximilianeum.ch/bitcoin/irc/logs/2011/04/20

Here's how it appears to me...

Jgarzik doesn't realize that the "tonal support" in this patch is merely allowing conversion of tonal specified units in the URI to Satoshis for internal use. It's not adding anything to do with displaying or computing tonal numbers into the actual client. I think having flexibility in the URI is a great thing. Why not allow people who use the URI on their sites to specify the amount in whatever format they choose? It will still display a decimal amount in the client.

5.0 == 5X8 == 500000000X0 == x1DCD6500X0 == x1DCBX4 == x1DCB

I normally dislike Luke's evangelising of tonal, but in this case I don't see any ulterior motive on his part.

[weavejester]

The changes to the spec irrationally demanded by the trolls involves making it absurdly more difficult for Tonal users (at no gain to Decimal users)

Maybe it's just me, but I didn't understand that 5X8 meant 500,000,000 until I read the specification in more detail. On the other hand, I would have instantly understood 5e8, because it's a standard convention. So at least in my case, there is a disadvantage to using this syntax, as it's less discoverable. I'd also point out that the difference in character height makes it easier to distinguish the exponent and multiplier in 5e8, whereas 5X8 is a little harder to read.

Perhaps I'm incorrect, but my guess is that the number of people who are familiar with the 5e8 convention is considerably greater than the amount of people who prefer using hexadecimal notation for monetary values. It's my opinion that using a syntax that disadvantages the majority, even if only slightly, is not worth the cost if only a very few people benefit.

If we really must have hexadecimal notation, can't we use a different exponent marker for hexadecimal values? e.g. 500e8 for decimals, and 0xf00x8 for hexadecimal.

[BitterTea]

Maybe it's just me, but I didn't understand that 5X8 meant 500,000,000 until I read the specification in more detail. On the other hand, I would have instantly understood 5e8, because it's a standard convention. So at least in my case, there is a disadvantage to using this syntax, as it's less discoverable. I'd also point out that the difference in character height makes it easier to distinguish the exponent and multiplier in 5e8, whereas 5X8 is a little harder to read.

Perhaps I'm incorrect, but my guess is that the number of people who are familiar with the 5e8 convention is considerably greater than the amount of people who prefer using hexadecimal notation for monetary values. It's my opinion that using a syntax that disadvantages the majority, even if only slightly, is not worth the cost if only a very few people benefit.

If we really must have hexadecimal notation, can't we use a different exponent marker for hexadecimal values? e.g. 500e8 for decimals, and 0xf00x8 for hexadecimal.

Actually, I agree with this. Perhaps "e" or "X" could be used to denote the exponential unit.

[Luke-Jr]

If we really must have hexadecimal notation, can't we use a different exponent marker for hexadecimal values? e.g. 500e8 for decimals, and 0xf00x8 for hexadecimal.

Treating 'e' like this only for decimal values would not break backward compatibility. No objection from me.

[Matt Corallo]

If we really must have hexadecimal notation, can't we use a different exponent marker for hexadecimal values? e.g. 500e8 for decimals, and 0xf00x8 for hexadecimal.

Treating 'e' like this only for decimal values would not break backward compatibility. No objection from me.

Quote from the wiki talk page:

Wouldn't it be better if we used the more standard "e" to represent the exponent? e.g. 5e8 = 500,000,000. Weavejester 11:18 PM, 18 April 2011 (GMT)
An older draft used this, but when implementing, it was quickly noted to conflict with the 'e' hexadecimal digit. --Luke-jr 16:04, 19 April 2011 (GMT)

[BitterTea]

Which is why 'e' would work for decimal, as Luke said.

But now that I think about it, 'e' isn't in the tonal alphabet, right?

[Luke-Jr]

Which is why 'e' would work for decimal, as Luke said.

But now that I think about it, 'e' isn't in the tonal alphabet, right?

Correct, but the URI scheme doesn't support tonal.

[rand0mmm]

Vladimirs scheme looks straightforwards and useful to me. Though I would add an action param to make this clear it was a "Send". (SEND/RECV)
The scheme needs actions, a way to do more than just send. I don't worry too much about the human readable part, but it is nice when all human legible parts are clustered together. Also, To you guys, the bitcoin address probably jumps out as such, but to most, it looks like scrambled eggs. So I would probably put the amount after the address. It does seem good to have some sort of version number in there, essentially making clear what url format is in use.  Easy to move forwards by revving the version, easy to handle old requests as they come in tagged.

[theymos]

The scheme needs actions, a way to do more than just send. I don't worry too much about the human readable part, but it is nice when all human legible parts are clustered together. Also, To you guys, the bitcoin address probably jumps out as such, but to most, it looks like scrambled eggs. So I would probably put the amount after the address. It does seem good to have some sort of version number in there, essentially making clear what url format is in use.  Easy to move forwards by revving the version, easy to handle old requests as they come in tagged.

See x-btc, which has actions and other useful features:
https://en.bitcoin.it/wiki/X-btc

[ISA]

I find Valdimirs URI scheme RFC very straight-forward and easy to understand,
thus very powerful.

I strongly recommend to implement this RFC asap in the client, since
this makes web payments / donations really easy and bitcoin very interesting
to merchants.

[HanSolo]

URI spec is rfc3986 from 2005, supersedes rfc2396 from 1998.

Double-slashes aren't right. By convention they mean 'next part describes a hierarchical-authority-root affecting the rest of the interpretation'. In 'http', a host is the 'authority'. For a suggested bitcoin transaction, neither the amount nor destination address is really the 'authority'. For a completed transaction, maybe the originator is the 'authority'.. but people seem to want these URIs as triggers for next-actions not back-references to past-actions, though a back-reference format to point to blocks, transactions, keys maybe useful too.

Slashes to separate fields by hard ordering are fragile and contrary to other URI precedents.

Better to avoid slashes unless there's a real nested hierarchy. The proposal on the wiki has the right idea.