Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Matt Corallo <bitcoin-list@bluematt.me>]

On Tue, 2012-01-31 at 06:27 -0800, Amir Taaki wrote:
> BIP 20 really has no support among implementations such as Bitcoin-Qt, Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing GUI projects (all with some form of URI Scheme), their opinion carries the most weight. To a lesser degree Bitcoin-Qt has the large majority of users too (although that's a line of reasoning I'd discourage).
> 
> Normally we should probably Reject BIP 21 and re-submit a new standard (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans some sections b) it is still a draft, probably the best thing here is if you all agree on something to run it by BlueMatt and then we'll make it the new BIP 21.
> 
> I can see a consensus forming on most parts. Just the send private key is contentious, and there's the topic of adding a time to expire field for merchants (this is a very good idea IMO).
> 
> Also BIP 20 is problematic because it is incompatible with about every standard on the web. All the HTML, URI and everything uses decimal numbers alone. I see no reason for breaking with tradition. Note that everytime I have to write Color or Vectorize (as a British speaker) in my code, I die a little inside. But it's convention and American English = International English. Also it would be cool if all code used a *real* international language (like Esperanto) but the world ain't perfect! We live in a decimal-counting English-speaking Windows-using God-worshipping world!
> 
> (no offense to decimal-counting English-speaking Windows-using God-worshipping world- I do half those things too :)

The send crap was not in the original spec, is not implemented anywhere,
and should have been removed as part of the BIP 21 copy/paste.  It is
now gone.

As for the expire time, well thats a bit problematic IMHO.  Technically
BIP 21 is still a draft, but it is implemented in all versions of
Bitcoin-Qt for drag and drop and adding a field which restricts the
validity of a URI for new clients, but which old clients will gladly
accept could result in some ugly situations IMO.

Matt