Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.81 as permitted sender)
	client-ip=62.13.149.81; envelope-from=pete@petertodd.org;
	helo=outmail149081.authsmtp.net; 
Date: Thu, 28 May 2015 08:04:34 -0400
From: Peter Todd <pete@petertodd.org>
To: Tier Nolan <tier.nolan@gmail.com>
Message-ID: <20150528120434.GA31349@savin.petertodd.org>
References: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
	<CANEZrP0QMHp9PwBr=ekkujtA+=LXbgiL4xkXRSmcOGqaLJEp0g@mail.gmail.com>
	<CAOG=w-s7JkB6SyEE0=KwmrasyH22aB2Zf3jBdKcXvrGoNhN_Nw@mail.gmail.com>
	<CANEZrP0zKe7hK0KjiXN9M6CHnJxKZfW9myez3G+GWpr3fugBCg@mail.gmail.com>
	<CAOG=w-vusO30sBZfsuP94wbkUUfHupmhQtScGsJ2463sO=EpzA@mail.gmail.com>
	<CAE-z3OUG5p_hAOFvaE10kTT7sa=2GrzvZpis5FzATSEcNwZpyw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY"
Content-Disposition: inline
In-Reply-To: <CAE-z3OUG5p_hAOFvaE10kTT7sa=2GrzvZpis5FzATSEcNwZpyw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Consensus-enforced transaction
 replacement via sequence numbers
Precedence: list


--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 28, 2015 at 11:30:18AM +0100, Tier Nolan wrote:
> Can you update it so that it only applies to transactions with version
> number 3 and higher.  Changing the meaning of a field is exactly what the
> version numbers are for.
>=20
> You could even decode version 3 transactions like that.
>=20
> Version 3 transactions have a sequence number of 0xFFFFFFFF and the
> sequence number field is re-purposed for relative lock time.
>=20
> This means that legacy transactions that have already been signed but have
> a locktime in the future will still be able to enter the blockchain
> (without having to wait significantly longer than expected).

For that matter, we probably don't want to treat this as a *version*
change, but rather a *feature* flag. For instance, nSequence is
potentially useful for co-ordinating multiple signatures to ensure they
can only be used in certain combinations, a use-case not neccesarily
compatible with this idea of a relative lock. Similarly it's potentially
useful for dealing with malleability.

nSequence is currently the *only* thing in CTxIn's that the signature
signs that can be freely changed; I won't be surprised if we find other
uses for it.

Of course, all of the above is assuming this proposal is useful; that's
not clear to me yet and won't be without fleshed out examples.

--=20
'peter'[:-1]@petertodd.org
000000000000000008464a6a19387029fa99edace15996d06a6343a8345d6167

--4Ckj6UjgE2iN1+kY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVZwROXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwODQ2NGE2YTE5Mzg3MDI5ZmE5OWVkYWNlMTU5OTZkMDZh
NjM0M2E4MzQ1ZDYxNjcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsVlwgAj2NRv7mGiE0bPvfUQmCgG+GN
oFPT6cYugxnYxPfEY1dVQwDvbGKbs1UEkSft6r0CX6TSU4AeFOjdNk57ftPHOIbI
BZQ2S5XvJktSvOYKeu6i7tpJ7q3S1ggjJs8eS5o6AHtvJWob5u/sY+z2+dwjyfJE
tQHTAoScXI9qtJzDAzRbmsO2ATqOfRNc40fsNdDQRRDGTp5kFYNnlWBShwqLTpvt
KkD+Q12/4GglXbnGwtgM33QjsbAAAO6n3ddISff0kJN7UaPMYRxWpTqSuj2AN6wb
RgJ45w7NS7W8+PtFChUGT7E5q8RMGRj0Vq5J30jkTZFrx2Xl42i9QxE1x/pA+w==
=avxm
-----END PGP SIGNATURE-----

--4Ckj6UjgE2iN1+kY--