Hi Jeremy,
Answering here from #22871 discussions.
I agree on the general principle to not blur mempool policies signaling in
committed transaction data. Beyond preserving upgradeability, another good
argument is to let L2 nodes update the mempool policies signaling their
pre-signed transactions
See the current patchset proposed:
https://github.com/bitcoin/bitcoin/pull/22871/commits
Two things are happening that are separate:
1) Fixing the semantics of arg in OP_CHECKSEQUENCEVERIFY
2) Fixing the semantics on nSequence in each tx input
There is no sense in conditioning part 1 on RBF or
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
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 6
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 po
In working on resolving this issue, one issue that has come up is what
sequence values get used by wallet implementations?
E.g., in Bitcoin Core a script test says
BIP125_SEQUENCE_NUMBER = 0xfffd # Sequence number that is rbf-opt-in
(BIP 125) and csv-opt-out (BIP 68)
Are any other numbers c
