From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XlvOw-0001T2-Vn for bitcoin-development@lists.sourceforge.net; Wed, 05 Nov 2014 07:53:11 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.180 as permitted sender) client-ip=209.85.223.180; envelope-from=pieter.wuille@gmail.com; helo=mail-ie0-f180.google.com; Received: from mail-ie0-f180.google.com ([209.85.223.180]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XlvOv-0000Mg-6j for bitcoin-development@lists.sourceforge.net; Wed, 05 Nov 2014 07:53:10 +0000 Received: by mail-ie0-f180.google.com with SMTP id y20so191738ier.11 for ; Tue, 04 Nov 2014 23:53:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.33.132 with SMTP id h126mr119203ioh.92.1415173983852; Tue, 04 Nov 2014 23:53:03 -0800 (PST) Received: by 10.50.98.40 with HTTP; Tue, 4 Nov 2014 23:53:03 -0800 (PST) In-Reply-To: <20141104200744.GA16945@savin.petertodd.org> References: <20141104191313.GA5493@savin.petertodd.org> <20141104200744.GA16945@savin.petertodd.org> Date: Tue, 4 Nov 2014 23:53:03 -0800 Message-ID: From: Pieter Wuille To: Peter Todd Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.6 (-) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XlvOv-0000Mg-6j Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP62 and future script upgrades 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: Wed, 05 Nov 2014 07:53:11 -0000 Ok, addressed these (and a few other things) in https://github.com/bitcoin/bips/pull/117: * Better names for the rules. * Clarify interaction of BIP62 with P2SH. * Clarify that known hashtypes are required, despite not being part of DER. * Use v2 transactions instead of v3 transactions. * Apply the optional rules only to strict v2, and not higher or lower. On Tue, Nov 4, 2014 at 12:07 PM, Peter Todd wrote: > On Tue, Nov 04, 2014 at 12:00:43PM -0800, Pieter Wuille wrote: >> On Tue, Nov 4, 2014 at 11:56 AM, Jeff Garzik wrote: >> > On Tue, Nov 4, 2014 at 8:13 PM, Peter Todd wrote: >> >> On another topic, I'm skeptical of the choice of nVersion==3 - we'll >> >> likely end up doing more block.nVersion increases in the future, and >> >> there's no reason to think they'll have anything to do with >> >> transactions. No sense creating a rule that'll be so quickly broken. >> > >> > Moderately agreed. >> > >> > Earlier in BIP 62 lifetime, I had commented on ambiguity that arose >> > from bumping tx version simply because we were bumping block version. >> > The ambiguity was corrected, but IMO remains symptomatic of potential >> > problems and confusion down the road. >> > >> > Though I ACK'd the change, my general preference remains to disconnect >> > TX and block version. >> >> I prefer to see consensus rules as one set of rules (especially >> because they only really apply to blocks - the part for lone >> transactions is just policy), and thus have a single numbering. Still, >> I have no strong opinion about it and have now heard 3 'moderately >> against' comments. I'm fine with using nVersion==2 for transactions. > > Keep in mind that we may even have a circumstance where we need to > introduce *two* different new tx version numbers in a single soft-fork, > say because we find an exploit that has two different fixes, each of > which breaks something. > > I don't think we have any certainty how new features will be added in > the future - just look at how we only recently realised new opcodes > won't be associated with tx version number bumps - so I'm loath to setup > expectations. > > Besides, transactions can certainly be verified for correctness in a > stand-alone fashion outside a block; CHECKLOCKTIMEVERIFY was > specifically designed so that verifying scripts containing it could be > done in a self-contained manner only referencing the transaction the > script was within. > > -- > 'peter'[:-1]@petertodd.org > 0000000000000000036655c955dd94ba7f9856814f3cb87f003e311566921807