Or you could flip the definition of your activation bit. That would avoid the inversion and put relative locktimes outside the realm of both the MAX_INT and MAX_INT - 1 values. It would also allow an explicit relative locktime of 0, which would help applications avoid accidentally finalizing the whole transaction when they only meant to not impose a relative locktime on one input. On 7/5/2015 10:07 AM, Mark Friedenbach wrote: > Note that you can put 0 in the sequence number field and it would work > just as expected under the old rules. I will perhaps suggest instead > that Bitcoin Core post-0.11 switch to doing this instead for that case. > > On Sun, Jul 5, 2015 at 8:00 AM, Tom Harding > wrote: > > BIP 68 uses nSequence to specify relative locktime, but nSequence also > continues to condition the transaction-level locktime. > > This dual effect will prevent a transaction from having an effective > nLocktime without also requiring at least one of its inputs to be > mined > at least one block (or one second) ahead of its parent. > > The fix is to shift the semantics so that nSequence = MAX_INT - 1 > specifies 0 relative locktime, rather than 1. This change will also > preserve the semantics of transactions that have already been created > with the specific nSequence value MAX_INT - 1 (for example all > transactions created by the bitcoin core wallet starting in 0.11). > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >