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

Tier Nolan tier.nolan at gmail.com
Thu May 28 10:30:18 UTC 2015

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).

On Thu, May 28, 2015 at 10:56 AM, Mark Friedenbach <mark at friedenbach.org>

> I have no problem with modifying the proposal to have the most significant
> bit signal use of the nSequence field as a relative lock-time. That leaves
> a full 31 bits for experimentation when relative lock-time is not in use. I
> have adjusted the code appropriately:
> https://github.com/maaku/bitcoin/tree/sequencenumbers
> On Wed, May 27, 2015 at 10:39 AM, Mike Hearn <mike at plan99.net> wrote:
>> Mike, this proposal was purposefully constructed to maintain as well as
>>> possible the semantics of Satoshi's original construction. Higher sequence
>>> numbers -- chronologically later transactions -- are able to hit the chain
>>> earlier, and therefore it can be reasonably argued will be selected by
>>> miners before the later transactions mature. Did I fail in some way to
>>> capture that original intent?
>> Right, but the original protocol allowed for e.g. millions of revisions
>> of the transaction, hence for high frequency trading (that's actually how
>> Satoshi originally explained it to me - as a way to do HFT - back then the
>> channel concept didn't exist).
>> As you point out, with a careful construction of channels you should only
>> need to bump the sequence number when the channel reverses direction. If
>> your app only needs to do that rarely, it's a fine approach.And your
>> proposal does sounds better than sequence numbers being useless like at the
>> moment. I'm just wondering if we can get back to the original somehow or at
>> least leave a path open to it, as it seems to be a superset of all other
>> proposals, features-wise.
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/e03cd831/attachment.html>

More information about the bitcoin-dev mailing list