From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XlkO9-0004Sq-Mc for bitcoin-development@lists.sourceforge.net; Tue, 04 Nov 2014 20:07:37 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.101 as permitted sender) client-ip=62.13.149.101; envelope-from=pete@petertodd.org; helo=outmail149101.authsmtp.com; Received: from outmail149101.authsmtp.com ([62.13.149.101]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XlkO8-0007O2-EF for bitcoin-development@lists.sourceforge.net; Tue, 04 Nov 2014 20:07:37 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sA4K7Tdx095814; Tue, 4 Nov 2014 20:07:29 GMT Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sA4K7Nn8065000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 4 Nov 2014 20:07:26 GMT Date: Tue, 4 Nov 2014 15:07:44 -0500 From: Peter Todd To: Pieter Wuille Message-ID: <20141104200744.GA16945@savin.petertodd.org> References: <20141104191313.GA5493@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 32ac03b9-645e-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgYUFloCAgsB AmIbWVReUFp7W2U7 bA9PbARUfEhLXhtr VklWR1pVCwQmQm0F fRlgDBFycQBGeH4+ ZENkVngVX0YrJkZ+ EEdJE2kDMHphaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNB8E GUpKFDMjVUMYWzgp IlQ9IUQdBFpZL109 K1ItVElw X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1XlkO8-0007O2-EF 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: Tue, 04 Nov 2014 20:07:37 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=3D=3D3 - 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. >=20 > 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=3D=3D2 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. --=20 'peter'[:-1]@petertodd.org 0000000000000000036655c955dd94ba7f9856814f3cb87f003e311566921807 --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJUWTIMXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwMzY2NTVjOTU1ZGQ5NGJhN2Y5ODU2ODE0ZjNjYjg3ZjAw M2UzMTE1NjY5MjE4MDcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuICwgAvuEfpenuD9sBC+/+RTXb/8tm B3RCU6ioiLcTqXXGW+3eqh/ZT0igtLXKOeRl2LPEccmXR3vj9BHS/hLlsHsbXa4v oW1/O97yHovdsaR5tPeDdHK+YBeaz1/OmKfvAnpthuYjo+D0und6PgAqYxYixebI nhm4XUaoZD1JZojFSaJgfbKPlLRbF1+JUTrUuGANeKeLqb+2q8e1MiNtHDZ7C/pb qoAyweCJK1Ypcy8xdasrXblNmTHd/y5U2oaWS9k491I7nD9l7i5mQ3Dzjtz+YBU8 Hkzej6vdcLzEJwl9Dtr8xmOxlNp+iz/YG6Es47dgi8yURiTsy2ehtk3NswLg0Q== =gyna -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd--