Given that we have had more than two weeks of public discussion, code is
available and reviewed, and several community identified issues resolved, I
would like to formally request a BIP number be assigned for this work. Will
the BIP editor be so kind as to do so to allow the BIP consensus process to
On Mon, Jun 1, 2015 at 6:49 PM, Mark Friedenbach <m...@friedenbach.org>
> I have written a reference implementation and BIP draft for a soft-fork
> change to the consensus-enforced behaviour of sequence numbers for the
> purpose of supporting transaction replacement via per-input relative
> lock-times. This proposal was previously discussed on the mailing list in
> the following thread:
> In short summary, this proposal seeks to enable safe transaction
> replacement by re-purposing the nSequence field of a transaction input to
> be a consensus-enforced relative lock-time.
> The advantages of this approach is that it makes use of the full range of
> the 32-bit sequence number which until now has rarely been used for
> anything other than a boolean control over absolute nLockTime, and it does
> so in a way that is semantically compatible with the originally envisioned
> use of sequence numbers for fast mempool transaction replacement.
> The disadvantages are that external constraints often prevent the full
> range of sequence numbers from being used when interpreted as a relative
> lock-time, and re-purposing nSequence as a relative lock-time precludes its
> use in other contexts. The latter point has been partially addressed by
> having the relative lock-time semantics be enforced only if the
> most-significant bit of nSequence is set. This preserves 31 bits for
> alternative use when relative lock-times are not required.
> The BIP draft can be found at the following gist:
> The reference implementation is available at the following git repository:
> I request that the BIP editor please assign a BIP number for this work.
> Mark Friedenbach
Bitcoin-development mailing list