Hi Jeremy,
I think it would be nice to have and suggested something similar (enforce
minimality) in the context of
Miniscript a few months ago [0].
However your code:
const bool seq_is_reserved = (txin.nSequence < CTxIn::SEQUENCE_FINAL-2) && (
// when sequence is set to disabled, it is reserved for future use
((txin.nSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLE_FLAG) != 0) ||
// when sequence has bits set outside of the type flag and locktime mask,
// it is reserved for future use.
((~(CTxIn::SEQUENCE_LOCKTIME_TYPE_FLAG | CTxIn::SEQUENCE_LOCKTIME_MASK) &
txin.nSequence) != 0)
);
Would effectively prevent Lightning Network commitment transactions from
relaying. The protocol uses
a hack encoding the commitment transaction numbering in the part of nSequence
(and nLockTime)
without consensus meaning. This both sets the LOCKTIME_DISABLE_FLAG and uses
bits outside of
the mask.
[0] https://github.com/rust-bitcoin/rust-miniscript/pull/246#issue-671512626
[1]
https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#commitment-transaction
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Le lundi 6 septembre 2021 à 5:17 AM, Jeremy via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> a écrit :
> BIP 68 says >= 2:This specification defines the meaning of sequence numbers
> for transactions with an nVersion greater than or equal to 2 for which the
> rest of this specification relies on.
> BIP-112 says not < 2
> // Fail if the transaction's version number is not set high
> // enough to trigger BIP 68 rules.
> if (static_cast<uint32_t>(txTo->nVersion) < 2) return false;
>
> A further proof that this needs fix: the flawed upgradable semantic exists in
> script as well as in the transaction nSeqeunce. we can't really control the
> transaction version an output will be spent with in the future, so it would
> be weird/bad to change the semantic in transaction version 3.
>
> --
> [@JeremyRubin](https://twitter.com/JeremyRubin)https://twitter.com/JeremyRubin
>
> On Sun, Sep 5, 2021 at 7:36 PM David A. Harding <d...@dtrt.org> wrote:
>
>> On Fri, Sep 03, 2021 at 08:32:19PM -0700, Jeremy via bitcoin-dev wrote:
>>> Hi Bitcoin Devs,
>>>
>>> I recently noticed a flaw in the Sequence lock implementation with respect
>>> to upgradability. It might be the case that this is protected against by
>>> some transaction level policy (didn't see any in policy.cpp, but if not,
>>> I've put up a blogpost explaining the defect and patching it
>>> https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/
>>
>> Isn't this why BIP68 requires using tx.version=2? Wouldn't we just
>> deploy any new nSequence rules with tx.version>2?
>>
>> -Dave
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
