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; 
Date: Tue, 4 Nov 2014 15:07:44 -0500
From: Peter Todd <pete@petertodd.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20141104200744.GA16945@savin.petertodd.org>
References: <CAPg+sBjygohgFf2hE9cGH3ZmV0MaeniZDDNO+hFxOxo-s_d81A@mail.gmail.com>
	<20141104191313.GA5493@savin.petertodd.org>
	<CAJHLa0NiWJtb0aSRddZmBtQRkfMyQ957jnZi=qGfL6eOb76gFg@mail.gmail.com>
	<CAPg+sBh=YDQhwNRWjhOQtWVPMZ0+D0MnprZK+vMjsuC-=RxAQA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd"
Content-Disposition: inline
In-Reply-To: <CAPg+sBh=YDQhwNRWjhOQtWVPMZ0+D0MnprZK+vMjsuC-=RxAQA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP62 and future script upgrades
Precedence: list


--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 <jgarzik@bitpay.com> wrote:
> > On Tue, Nov 4, 2014 at 8:13 PM, Peter Todd <pete@petertodd.org> 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--