[Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

Peter Todd pete at petertodd.org
Thu May 28 12:04:34 UTC 2015


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.
> 
> You could even decode version 3 transactions like that.
> 
> Version 3 transactions have a sequence number of 0xFFFFFFFF and the
> sequence number field is re-purposed for relative lock time.
> 
> 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.

-- 
'peter'[:-1]@petertodd.org
000000000000000008464a6a19387029fa99edace15996d06a6343a8345d6167
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/b3fb4c20/attachment.sig>


More information about the bitcoin-dev mailing list