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@gmail.com> wrote:
On Wed, May 27, 2015 at 7:47 AM, Peter Todd <pete@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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development