Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic
Hi Antoine, Excellent work as usual! When this was initially reported, I suspected that btcd wasn't actually affected by this issue (proper RBF inheritance). I wrote a unit test earlier today to confirm this: https://github.com/btcsuite/btcd/pull/1719. I'm particularly fond of btcd's implementation of RBF signalling: https://github.com/btcsuite/btcd/blob/master/mempool/mempool.go#L603. The separation of concerns here makes it (IMO) much easier to follow (as well as uint test) compared to bitcoind's `MemPoolAccept::PreChecks` function. Its recursive nature makes the inherited replaceability explicit. -- Laolu On Thu, May 6, 2021 at 8:49 AM Antoine Riard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi, > > I'm writing to report a defect in Bitcoin Core bip125 logic with minor > security and operational implications for downstream projects. Though this > defect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety isn't > impacted. > > # Problem > > Bip 125 specification describes the following signalling mechanism : > > " > This policy specifies two ways a transaction can signal that it is > replaceable. > > * Explicit signaling: A transaction is considered to have opted in to > allowing replacement of itself if any of its inputs have an nSequence > number less than (0x - 1). > > * Inherited signaling: Transactions that don't explicitly signal > replaceability are replaceable under this policy for as long as any one of > their ancestors signals replaceability and remains unconfirmed. > > One or more transactions currently in the mempool (original transactions) > will be replaced by a new transaction (replacement transaction) that spends > one or more of the same inputs if, > > # The original transactions signal replaceability explicitly or through > inheritance as described in the above Summary section. > " > > An unconfirmed child transaction with nSequence = 0xff_ff_ff_ff spending > an unconfirmed parent with nSequence <= 0xff_ff_ff_fd should be replaceable > as the child transaction signals "through inheritance". However, the > replacement code as implemented in Core's `PreChecks()` shows that this > behavior isn't enforced and Core's mempool rejects replacement attempts of > an unconfirmed child transaction. > > Branch asserting the behavior is here : > https://github.com/ariard/bitcoin/commits/2021-03-test-rbf > > # Solution > > The defect has not been patched. > > # Downstream Projects Affected > > * LN : State-of-the-art pinning attacks against second-stage HTLCs > transactions were thought to be only possible by exploiting RBF rule 3 on > the necessity of a higher absolute fee [0]. However, this replacement > defect opens the way for an attacker to only pin with an opt-out child > without a higher fee than the honest competing transaction. This lowers the > cost of attack as the malicious pinning transaction only has to be above > mempools'min feerate. This also increases odds of attack success for a > reduced feerate diminishes odds of confirmation ending the pinning. > > A functional test demo illustrating cases is available on this branch: > https://github.com/ariard/bitcoin/commits/2021-05-htlc-preimage-pinnings > > LN nodes operators concerned by this defect might favor anchor outputs > channels, fully mitigating this specific pinning vector. > > * Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple > stages of execution with time-sensitive transactions opening the way to > pinning attacks. Those protocols being non-deployed or in early phase, I > would recommend that any in-protocol competing transactions explicitly > signal RBF. > > * Coinjoin/Cut-Through : if CPFP is employed as a fee-bumping strategy, if > the coinjoin transaction is still laying in network mempools, if a > fee-bumping output is spendable by any protocol participant, this > fee-bumping mechanism might be halted by a malicious protocol participant > broadcasting an low-feerate opt-out child. According to bip125, if the > coinjoin parent tx signals replaceability, the child transaction should be > replaceable, whatever its signaling. However Core doesn't apply this > policy. RBF of the coinjoin transaction itself should be used as a > fallback. I'm not aware of any deployed coinjoin using such > "anyone-can-bump" fee-bumping strategy. > > * Simple wallets : RBF engines' behaviors might be altered in ways not > matching the intent of their developers. I invite RBF engines dev to verify > what those components are doing in the light of disclosed information. > > # Discovery > > While reviewing the LN dual-funding flow, I inquired on potential new DoS > vectors introduced by relying on counterparty utxos in this following > analysis [1]. The second DoS issue "RBF opt-out by a Counterparty > Double-Spend" is relying on a malicious chain of transactions where the > parent is signaling RBF opt-in through nSequence<=0xff_ff_ff_ff-1 but the > child, servicing as a
Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic
Hi Luke, > Is there a list of software impacted by this CVE, and the versions it is fixed in? Speaking only for LN clients, as I think they're the only ones deployed with real funds at stake. Defect is mitigated by new "anchor" channel type, forcing RBF-signaling on all transactions. * lnd v0.12 "anchor" activated by default, lnd v0.10 "anchor" activated by user flag * c-lightning, no release yet with "anchor" support * eclair, no release yet with "anchor" support * rust-lightning, no release yet with "anchor" support > (Note this isn't a vulnerability in Bitcoin Core; BIP125 is strictly a policy matter, not part of the consensus rules and never safe to rely on in any case...) Answering two-folds. First I somehow agree it's not a "vulnerability" in Bitcoin Core but at least a clear lack of compliance to a heavily relied-on bitcoin standard through the ecosystem. Even if BIPs are descriptive documentation and not prescriptive, I don't think we have guidelines for now on how to proceed with identified flaws with security implications for downstream projects. Should the Bitcoin Core project adopt a security bulletin or advisories for security-related info pertinent for downstream ? Secondly, opinions were divergent on the security list on how to report on this. On one side, tx-relay and mempool acceptance rules aren't considered as reliable or strongly normative and purely a matter of node's policy. On the other side, we have more and more deployed Bitcoin applications/protocols (e.g LN, vaults, ...) directly making security assumptions on them. Even if we consider such beliefs misplaced or ingenious, we're laying on top of a permissionless system and can't really prevent developers and users from deploying such softwares. Should we stay on this statu quo and invite such Bitcoin users to deploy their own overlay network for transaction propagation satisfying their advanced requirements, at the price of far-less censorship-resistance and a more opaque fee market for everyone ? Or instead qualify a new, third set of rules between consensus and pure "policy", especially crafted to support Bitcoin applications requiring transparency and stability of tx-relay and mempool acceptance rules, at the price of ossifying some part of full-nodes ? Of course, the degree of normativity we could guarantee for those rules is making them compatible with economic incentives of everyone. Hopefully fostering their wide dissemination across full-node implementations and miner mempools. You have good arguments and trade-offs on both sides. Overall, I agree that describing tx-relay/mempool rules as non-normative, non-reliable is the most understood mental model among developers *today*. That said, I would like to underscore that this model might not be adequate in light of recent ecosystem evolutions and reveal itself a bit crippling the future... Cheers, Antoine Le mar. 11 mai 2021 à 17:51, Luke Dashjr a écrit : > Is there a list of software impacted by this CVE, and the versions it is > fixed > in? > > (Note this isn't a vulnerability in Bitcoin Core; BIP125 is strictly a > policy > matter, not part of the consensus rules and never safe to rely on in any > case...) > > > On Thursday 06 May 2021 13:55:53 Antoine Riard via bitcoin-dev wrote: > > Hi, > > > > I'm writing to report a defect in Bitcoin Core bip125 logic with minor > > security and operational implications for downstream projects. Though > this > > defect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety > isn't > > impacted. > > > > # Problem > > > > Bip 125 specification describes the following signalling mechanism : > > > > " > > This policy specifies two ways a transaction can signal that it is > > replaceable. > > > > * Explicit signaling: A transaction is considered to have opted in to > > allowing replacement of itself if any of its inputs have an nSequence > > number less than (0x - 1). > > > > * Inherited signaling: Transactions that don't explicitly signal > > replaceability are replaceable under this policy for as long as any one > of > > their ancestors signals replaceability and remains unconfirmed. > > > > One or more transactions currently in the mempool (original transactions) > > will be replaced by a new transaction (replacement transaction) that > spends > > one or more of the same inputs if, > > > > # The original transactions signal replaceability explicitly or through > > inheritance as described in the above Summary section. > > " > > > > An unconfirmed child transaction with nSequence = 0xff_ff_ff_ff spending > an > > unconfirmed parent with nSequence <= 0xff_ff_ff_fd should be replaceable > as > > the child transaction signals "through inheritance". However, the > > replacement code as implemented in Core's `PreChecks()` shows that this > > behavior isn't enforced and Core's mempool rejects replacement attempts > of > > an unconfirmed child transaction. > > > > Branch asserting the behavior is here : > >
Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic
Hi Ruben,
Thanks for raising awareness about spacechains/BMM, I didn't have knowledge
it was relying on a fee-based English auction to mine side-blocks. IIUC,
it's another type of dynamic membership
multi-party signature where parties are block-signing with a fee proposal
instead of a PoW ? Though you still assume mainchain miners aren't
colluding and blindly applying the RBF policy
Effectively, if you can block RBF by opting-out, parties are not competing
anymore on feerate but on gaining propagation advantage in the tx-relay
topology. And such advantage is quite easy to
gain with a modified client, mass-connecting and not enforcing inventory
broadcast interval timers.
> As it stands, this bug gets in the way of being able to deploy
spacechains.
Noted, yet another good-point to transition towards full-rbf!
Cheers,
Antoine
Le mar. 11 mai 2021 à 17:16, Ruben Somsen a écrit :
> Hi Antoine,
>
> Thanks for bringing this up.
>
> It seems spacechains[0] are impacted by this. Simply explained, the idea
> is to allow for fee-bidding Blind Merged Mining[1] by creating one
> transaction for each block, to which anyone can attach a block hash. The
> preferred mechanism utilizes sighash_anyprevout and is not affected, but
> there is also a practical variant that could be used without requiring the
> anyprevout soft fork, which unfortunately does seem to be impacted. Here's
> a brief description:
>
> TX0:
>
> input 0
>
> output 1a*
> output 1b
>
> TX1:
>
> input 1a*
>
> output 2a**
> output 2b
>
> TX2:
>
> input 2a**
>
> output 3a***
> output 3b
>
> Etc.
>
> Every TX has two outputs, one of which ("a") is used as the input for the
> next TX (these are pre-signed and act as a covenant), resulting in a
> continuous chain of transactions. The other output ("b") can be spent by
> anyone, and is meant to CPFP the parent TX and, importantly, be RBF
> replaceable by anyone. This allows whoever pays the highest CPFP fee to
> "win the RBF auction" and attach their TX to the output, containing the
> winning spacechain block hash.
>
> With inherited signalling, this works because each pre-signed TX is RBF
> enabled, so each CPFP transaction inherits RBF as well. But if inherited
> signalling does not function, the first person who makes a CPFP transaction
> can simply disable RBF and win the auction, thus breaking the intended
> fee-bidding mechanism.
>
> You can also find a diagram in this spacechains presentation (timestamped
> link): https://youtu.be/N2ow4Q34Jeg?t=2555
>
> As it stands, this bug gets in the way of being able to deploy spacechains.
>
> -- Ruben Somsen
>
>
>
> [0]
> https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302
>
> [1] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5
>
>
>
>
> On Sun, May 9, 2021 at 10:41 AM darosior via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Antoine,
>>
>>
>> Thank you for the disclosure.
>>
>>
>>
>> > * Onchain DLC/Coinswap/Vault : Those contract protocols have also
>> multiple stages of execution with time-sensitive transactions opening the
>> way to pinning attacks. Those protocols being non-deployed or in early
>> phase, I would recommend that any in-protocol competing transactions
>> explicitly signal RBF.
>>
>>
>> For what it's worth, Revault isn't vulnerable as all transactions signal
>> RBF and there is no way to sneak a non-signaling competing transaction (as
>> long as the CSV isn't matured yet).
>>
>>
>>
>> Thanks,
>>
>> Antoine (the other one)___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic
Is there a list of software impacted by this CVE, and the versions it is fixed in? (Note this isn't a vulnerability in Bitcoin Core; BIP125 is strictly a policy matter, not part of the consensus rules and never safe to rely on in any case...) On Thursday 06 May 2021 13:55:53 Antoine Riard via bitcoin-dev wrote: > Hi, > > I'm writing to report a defect in Bitcoin Core bip125 logic with minor > security and operational implications for downstream projects. Though this > defect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety isn't > impacted. > > # Problem > > Bip 125 specification describes the following signalling mechanism : > > " > This policy specifies two ways a transaction can signal that it is > replaceable. > > * Explicit signaling: A transaction is considered to have opted in to > allowing replacement of itself if any of its inputs have an nSequence > number less than (0x - 1). > > * Inherited signaling: Transactions that don't explicitly signal > replaceability are replaceable under this policy for as long as any one of > their ancestors signals replaceability and remains unconfirmed. > > One or more transactions currently in the mempool (original transactions) > will be replaced by a new transaction (replacement transaction) that spends > one or more of the same inputs if, > > # The original transactions signal replaceability explicitly or through > inheritance as described in the above Summary section. > " > > An unconfirmed child transaction with nSequence = 0xff_ff_ff_ff spending an > unconfirmed parent with nSequence <= 0xff_ff_ff_fd should be replaceable as > the child transaction signals "through inheritance". However, the > replacement code as implemented in Core's `PreChecks()` shows that this > behavior isn't enforced and Core's mempool rejects replacement attempts of > an unconfirmed child transaction. > > Branch asserting the behavior is here : > https://github.com/ariard/bitcoin/commits/2021-03-test-rbf > > # Solution > > The defect has not been patched. > > # Downstream Projects Affected > > * LN : State-of-the-art pinning attacks against second-stage HTLCs > transactions were thought to be only possible by exploiting RBF rule 3 on > the necessity of a higher absolute fee [0]. However, this replacement > defect opens the way for an attacker to only pin with an opt-out child > without a higher fee than the honest competing transaction. This lowers the > cost of attack as the malicious pinning transaction only has to be above > mempools'min feerate. This also increases odds of attack success for a > reduced feerate diminishes odds of confirmation ending the pinning. > > A functional test demo illustrating cases is available on this branch: > https://github.com/ariard/bitcoin/commits/2021-05-htlc-preimage-pinnings > > LN nodes operators concerned by this defect might favor anchor outputs > channels, fully mitigating this specific pinning vector. > > * Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple > stages of execution with time-sensitive transactions opening the way to > pinning attacks. Those protocols being non-deployed or in early phase, I > would recommend that any in-protocol competing transactions explicitly > signal RBF. > > * Coinjoin/Cut-Through : if CPFP is employed as a fee-bumping strategy, if > the coinjoin transaction is still laying in network mempools, if a > fee-bumping output is spendable by any protocol participant, this > fee-bumping mechanism might be halted by a malicious protocol participant > broadcasting an low-feerate opt-out child. According to bip125, if the > coinjoin parent tx signals replaceability, the child transaction should be > replaceable, whatever its signaling. However Core doesn't apply this > policy. RBF of the coinjoin transaction itself should be used as a > fallback. I'm not aware of any deployed coinjoin using such > "anyone-can-bump" fee-bumping strategy. > > * Simple wallets : RBF engines' behaviors might be altered in ways not > matching the intent of their developers. I invite RBF engines dev to verify > what those components are doing in the light of disclosed information. > > # Discovery > > While reviewing the LN dual-funding flow, I inquired on potential new DoS > vectors introduced by relying on counterparty utxos in this following > analysis [1]. The second DoS issue "RBF opt-out by a Counterparty > Double-Spend" is relying on a malicious chain of transactions where the > parent is signaling RBF opt-in through nSequence<=0xff_ff_ff_ff-1 but the > child, servicing as a pinning transaction, opt-out from the RBF policy. > This pinning trick conception was matching my understanding of Core code > but while reading again the specification, I observed that it was > inconsistent from the inherited signaling mechanism as described in the > bip's "Summary" section. > > After exercising the logic, I did submit the defect to Dave Harding, asking > confirmation of divergence between
Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic
Hi Antoine,
Thanks for bringing this up.
It seems spacechains[0] are impacted by this. Simply explained, the idea is
to allow for fee-bidding Blind Merged Mining[1] by creating one transaction
for each block, to which anyone can attach a block hash. The preferred
mechanism utilizes sighash_anyprevout and is not affected, but there is
also a practical variant that could be used without requiring the
anyprevout soft fork, which unfortunately does seem to be impacted. Here's
a brief description:
TX0:
input 0
output 1a*
output 1b
TX1:
input 1a*
output 2a**
output 2b
TX2:
input 2a**
output 3a***
output 3b
Etc.
Every TX has two outputs, one of which ("a") is used as the input for the
next TX (these are pre-signed and act as a covenant), resulting in a
continuous chain of transactions. The other output ("b") can be spent by
anyone, and is meant to CPFP the parent TX and, importantly, be RBF
replaceable by anyone. This allows whoever pays the highest CPFP fee to
"win the RBF auction" and attach their TX to the output, containing the
winning spacechain block hash.
With inherited signalling, this works because each pre-signed TX is RBF
enabled, so each CPFP transaction inherits RBF as well. But if inherited
signalling does not function, the first person who makes a CPFP transaction
can simply disable RBF and win the auction, thus breaking the intended
fee-bidding mechanism.
You can also find a diagram in this spacechains presentation (timestamped
link): https://youtu.be/N2ow4Q34Jeg?t=2555
As it stands, this bug gets in the way of being able to deploy spacechains.
-- Ruben Somsen
[0]
https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac302
[1] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5
On Sun, May 9, 2021 at 10:41 AM darosior via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Antoine,
>
>
> Thank you for the disclosure.
>
>
>
> > * Onchain DLC/Coinswap/Vault : Those contract protocols have also
> multiple stages of execution with time-sensitive transactions opening the
> way to pinning attacks. Those protocols being non-deployed or in early
> phase, I would recommend that any in-protocol competing transactions
> explicitly signal RBF.
>
>
> For what it's worth, Revault isn't vulnerable as all transactions signal
> RBF and there is no way to sneak a non-signaling competing transaction (as
> long as the CSV isn't matured yet).
>
>
>
> Thanks,
>
> Antoine (the other one)___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic
Hi Antoine, Thank you for the disclosure. > * Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple > stages of execution with time-sensitive transactions opening the way to > pinning attacks. Those protocols being non-deployed or in early phase, I > would recommend that any in-protocol competing transactions explicitly signal > RBF. For what it's worth, Revault isn't vulnerable as all transactions signal RBF and there is no way to sneak a non-signaling competing transaction (as long as the CSV isn't matured yet). Thanks, Antoine (the other one)___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin Core's bip125 logic
Hi, I'm writing to report a defect in Bitcoin Core bip125 logic with minor security and operational implications for downstream projects. Though this defect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety isn't impacted. # Problem Bip 125 specification describes the following signalling mechanism : " This policy specifies two ways a transaction can signal that it is replaceable. * Explicit signaling: A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0x - 1). * Inherited signaling: Transactions that don't explicitly signal replaceability are replaceable under this policy for as long as any one of their ancestors signals replaceability and remains unconfirmed. One or more transactions currently in the mempool (original transactions) will be replaced by a new transaction (replacement transaction) that spends one or more of the same inputs if, # The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section. " An unconfirmed child transaction with nSequence = 0xff_ff_ff_ff spending an unconfirmed parent with nSequence <= 0xff_ff_ff_fd should be replaceable as the child transaction signals "through inheritance". However, the replacement code as implemented in Core's `PreChecks()` shows that this behavior isn't enforced and Core's mempool rejects replacement attempts of an unconfirmed child transaction. Branch asserting the behavior is here : https://github.com/ariard/bitcoin/commits/2021-03-test-rbf # Solution The defect has not been patched. # Downstream Projects Affected * LN : State-of-the-art pinning attacks against second-stage HTLCs transactions were thought to be only possible by exploiting RBF rule 3 on the necessity of a higher absolute fee [0]. However, this replacement defect opens the way for an attacker to only pin with an opt-out child without a higher fee than the honest competing transaction. This lowers the cost of attack as the malicious pinning transaction only has to be above mempools'min feerate. This also increases odds of attack success for a reduced feerate diminishes odds of confirmation ending the pinning. A functional test demo illustrating cases is available on this branch: https://github.com/ariard/bitcoin/commits/2021-05-htlc-preimage-pinnings LN nodes operators concerned by this defect might favor anchor outputs channels, fully mitigating this specific pinning vector. * Onchain DLC/Coinswap/Vault : Those contract protocols have also multiple stages of execution with time-sensitive transactions opening the way to pinning attacks. Those protocols being non-deployed or in early phase, I would recommend that any in-protocol competing transactions explicitly signal RBF. * Coinjoin/Cut-Through : if CPFP is employed as a fee-bumping strategy, if the coinjoin transaction is still laying in network mempools, if a fee-bumping output is spendable by any protocol participant, this fee-bumping mechanism might be halted by a malicious protocol participant broadcasting an low-feerate opt-out child. According to bip125, if the coinjoin parent tx signals replaceability, the child transaction should be replaceable, whatever its signaling. However Core doesn't apply this policy. RBF of the coinjoin transaction itself should be used as a fallback. I'm not aware of any deployed coinjoin using such "anyone-can-bump" fee-bumping strategy. * Simple wallets : RBF engines' behaviors might be altered in ways not matching the intent of their developers. I invite RBF engines dev to verify what those components are doing in the light of disclosed information. # Discovery While reviewing the LN dual-funding flow, I inquired on potential new DoS vectors introduced by relying on counterparty utxos in this following analysis [1]. The second DoS issue "RBF opt-out by a Counterparty Double-Spend" is relying on a malicious chain of transactions where the parent is signaling RBF opt-in through nSequence<=0xff_ff_ff_ff-1 but the child, servicing as a pinning transaction, opt-out from the RBF policy. This pinning trick conception was matching my understanding of Core code but while reading again the specification, I observed that it was inconsistent from the inherited signaling mechanism as described in the bip's "Summary" section. After exercising the logic, I did submit the defect to Dave Harding, asking confirmation of divergence between Bitcoin Core and BIP 125. Soon after, he did confirm it and pointed that the defect has been there since the 2015's PR introducing the opt-in RBF, advicing to to consider security implications for deployed second-layer protocols. After noticing the minor implications for pinning attacks on second-stage LN transactions while talking with Matt Corallo, I did disclose to the Bitcoin Core security list. My initial report was recommending avoiding a covert patch in the mempool as risks of
