From: Matt Corallo <bitcoin-list@bluematt•me>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N
Date: Tue, 31 Jan 2012 13:22:25 -0500 [thread overview]
Message-ID: <1328034145.2832.11.camel@BMThinkPad.lan.bluematt.me> (raw)
In-Reply-To: <1328025899.2832.5.camel@BMThinkPad.lan.bluematt.me>
OK, so I just did some heavy changes to the methods for forward
compatibility in BIP 21. Instead of a version number, now new variables
will be added either as-is or with a mustimplement: prefix. If a
clients does not know what the variable is that is after mustimplement:,
it should consider the entire URI invalid and either notify the user or
just drop it silently. That way things like expiretime can be added
without worrying about old clients ignoring the field.
All that said, I dont think its an ideal solution, depending on the
names of variables to provide information is ugly. If anyone has a
better idea on how to do backward compatibility, please suggest it.
In terms of the expiretime field being implemented now, I dont think its
appropriate. Because some clients already have an old implementation,
the possibility of it getting ignored is too large. The BIP now states
that "It is recommended that additional variables prefixed with
mustimplement: not be used in a mission-critical way until a grace
period of 6 months from the finalization of this BIP has passed in order
to allow client developers to release new versions, and users of old
clients to upgrade." Mostly, however, I want to keep the list of
changes from the Bitcoin-Qt implementation to this BIP very, very
minimal this late the 0.6 release cycle (I want to get this BIP
finalized and implemented for 0.6, so that at least Bitcoin-Qt will have
no version which support OS URI opening with a broken implementation).
Matt
On Tue, 2012-01-31 at 11:04 -0500, Matt Corallo wrote:
> 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
next prev parent reply other threads:[~2012-01-31 18:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-31 14:27 Amir Taaki
2012-01-31 14:33 ` slush
2012-01-31 14:52 ` Amir Taaki
[not found] ` <CAKm8k+1cHagzj3T27S=h0PueH8EgcCkEajZGgAw7HcQ=N-46ow@mail.gmail.com>
2012-01-31 14:53 ` Gary Rowe
2012-01-31 15:02 ` Gregory Maxwell
2012-01-31 15:04 ` Gary Rowe
2012-01-31 14:59 ` Gregory Maxwell
2012-01-31 16:04 ` Matt Corallo
2012-01-31 18:22 ` Matt Corallo [this message]
2012-01-31 19:02 ` Wladimir
2012-01-31 21:42 ` Matt Corallo
2012-01-31 22:14 ` Andreas Schildbach
2012-01-31 22:37 ` Gary Rowe
2012-01-31 22:47 ` Matt Corallo
2012-02-04 14:03 ` thomasV1
2012-02-04 16:03 ` Gary Rowe
2012-02-04 17:15 ` Matt Corallo
2012-01-31 16:07 ` Luke-Jr
2012-02-02 17:07 Gary Rowe
2012-02-02 17:39 ` Matt Corallo
2012-02-02 17:46 ` Gary Rowe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1328034145.2832.11.camel@BMThinkPad.lan.bluematt.me \
--to=bitcoin-list@bluematt$(echo .)me \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox