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

[Tier Nolan]

This could cause legacy transactions to become unspendable.


A new transaction version number should be used to indicate the change of
the field from sequence number to relative lock time.

Legacy transactions should not have the rule applied to them.

On Wed, May 27, 2015 at 9:18 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Wed, May 27, 2015 at 7:47 AM, Peter Todd <pete at petertodd.org> wrote:
> > Equally this proposal is no more "consensus enforcement" than simply
> > increasing the fee (and possibly decreasing the absolute nLockTime) for
>
> You've misunderstood it, I think-- Functionally nlocktime but relative
> to each txin's height.
>
> But the construction gives the sequence numbers a rational meaning,
> they count down the earliest position a transaction can be included.
> (e.g. the highest possible sequence number can be included any time
> the inputs are included) the next lower sequence number can only be
> included one block later than the input its assigned to is included,
> the next lower one block beyond that. All consensus enforced.   A
> miner could opt to not include the higher sequence number (which is
> the only one of the set which it _can_ include) it the hopes of
> collecting more fees later on the next block, similar to how someone
> could ignore an eligible locked transaction in the hopes that a future
> double spend will be more profitable (and that it'll enjoy that
> profit) but in both cases it must take nothing at all this block, and
> risk being cut off by someone else (and, of course, nothing requires
> users use sequence numbers only one apart...).
>
> It makes sequence numbers work exactly like you'd expect-- within the
> bounds of whats possible in a decentralized system.  At the same time,
> all it is ... is relative nlocktime.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150527/e68c2a37/attachment.html>