From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; Tue, 31 Jan 2012 19:13:46 +0100 (CET) From: Matt Corallo 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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