1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1RsILm-00031O-9K
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 18:22:38 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bluematt.me
designates 173.246.101.161 as permitted sender)
client-ip=173.246.101.161;
envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me;
Received: from vps.bluematt.me ([173.246.101.161] helo=mail.bluematt.me)
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1RsILg-0006TR-JJ for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 18:22:38 +0000
Received: from [152.23.43.212] (MainCampusMid00971.1Xwireless.unc.edu
[152.23.43.212])
by mail.bluematt.me (Postfix) with ESMTPSA id A53C13F8
for <bitcoin-development@lists.sourceforge.net>;
Tue, 31 Jan 2012 19:13:46 +0100 (CET)
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
In-Reply-To: <1328025899.2832.5.camel@BMThinkPad.lan.bluematt.me>
References: <1328020046.70720.YahooMailNeo@web121002.mail.ne1.yahoo.com>
<1328025899.2832.5.camel@BMThinkPad.lan.bluematt.me>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 31 Jan 2012 13:22:25 -0500
Message-ID: <1328034145.2832.11.camel@BMThinkPad.lan.bluematt.me>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.4 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RsILg-0006TR-JJ
Subject: Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 31 Jan 2012 18:22:38 -0000
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
|
