path: root/9a/4f78aa00a859b1625d13d5f27e9b815c4f7bda

Return-Path: <laolu32@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D2519C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 13 May 2021 01:06:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id B9B86838C0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 13 May 2021 01:06:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id tYFCRXbCpvWx
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 13 May 2021 01:06:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com
 [IPv6:2607:f8b0:4864:20::b31])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 83C0783834
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 13 May 2021 01:06:33 +0000 (UTC)
Received: by mail-yb1-xb31.google.com with SMTP id m9so33040311ybm.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 May 2021 18:06:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=Qt1gUhl2A0GXxXYPzsaAChiZWaubxe03bpfmS9ySfWI=;
 b=DGIwekCXaaFUjLsfANc5BKCf5G/LqLgfyO0PcZ9Rt+Po29+AFJmsQpkun/MpM2edlB
 JPzG9UlI8B+Dn4AgqqGCE55ipOHi6e9kUhOYZ5pJ+tX0CDEqFsUOq4DudC952WuHUtQu
 /MwXZMlXBxDsdl1p6tgjG2l19NZjZFz/4e/BuztKiQFP9laP8gDpMBxnB56QcrH9P8RC
 gBfS+pYMzdEaviKYm1ncxT8v2RwsiLxRu5HDe5e7lhxfYIkAjf/aJwAB4gmLsviGGylt
 gwPmCAarpPm7c4e7zrWMADFrxM20YbryCeea3Czd4o9uBwXlTg+lnYIB0SXv77tYGudy
 peOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=Qt1gUhl2A0GXxXYPzsaAChiZWaubxe03bpfmS9ySfWI=;
 b=F9Mhc4xkjVkSMJILuHBtBeGVKu8v69bt+RjdD6AmIqV2q/q7E3uqxoOKLB6GizVMEF
 O5eT7TV26JjW9keQRdo5uUZ9w3jEvt4/avAg+vq+Ro3LhGxOZDUuCNxFs+T/hsm24+Py
 KH43dSH9yhLWTNfz4/WKasJlKsbkCEJXZt/SbszPM3RUsP+sscFCBD6jmGNCnuai0Q6s
 xXTakbjlIMCXnBGRwSw4nzqp/M4AtOO10ePCyRNp2HWn4+WCTO6yGj0LcmuDTWbqzOpJ
 2y+/Kcu64xUWeUGUu+Uw4y2ir6ufu86/G4JvdBZl8wKggkO5w5NiNts+qt6V1CNYUtTM
 s/+g==
X-Gm-Message-State: AOAM531Esi6iQCG7Sgq1YutpmZsBtKvPgnO7q01pn9XC/rIhSjE7JV6L
 7+tdc7NxRi4fZ0151WKQVepjl0JxkO57XpR9eXo=
X-Google-Smtp-Source: ABdhPJysObIrWxiwbFc/mmLeobyT7AJiWxLY5jqv9YBZ5MelTjfxaXq8QI2/D5Lc9ioC8V0B/KC3VnqkpJ3k5RvIJw0=
X-Received: by 2002:a25:8442:: with SMTP id r2mr8606960ybm.492.1620867992320; 
 Wed, 12 May 2021 18:06:32 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GK4WNBmKim3w9LAd1b69+uAyAsNu5tVniHzN6Ue4KJCw@mail.gmail.com>
In-Reply-To: <CALZpt+GK4WNBmKim3w9LAd1b69+uAyAsNu5tVniHzN6Ue4KJCw@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Wed, 12 May 2021 18:06:21 -0700
Message-ID: <CAO3Pvs_0iaQDOUuddQHESVYz6V23hWPOu54FT=A9=cCOEjFBAg@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e8fe2905c22bbc41"
Subject: Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin
 Core's bip125 logic
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2021 01:06:35 -0000

--000000000000e8fe2905c22bbc41
Content-Type: text/plain; charset="UTF-8"

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 (0xffffffff - 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 introducing DoS in this part of the codebase seemed to outweigh
> security of deployed LN channels. This direction was agreed by the opinions
> expressed on the security list. Beyond, there was a lack of agreement on
> how to proceed with the disclosure as so far in the history project,
> transaction relay policy have not been considered as strongly reliable.
> Though from now on, L2 protocols like Lightning are making assumptions on
> subset of this policy for their safety, such as the highlighted RBF one.
>
> Defect was disclosed to the LN projects maintainers, informing them that
> currently in deployment anchor outputs protocol upgrade was mitigating
> against this defect though old channels will stay vulnerable. To the best
> of my knowledge, I didn't identify other deployed protocols of which coins
> safety are impacted by this defect.
>
> # Ecosystem Observations
>
> This long-standing defect with benign security implications provided an
> opportunity to exercise coordinated security disclosure across layers and
> development teams.
>
> IMO, it underlies few interesting points:
> * the lack of an established policy for coordinated security disclosures
> between a base layer implementation and its downstream projects
> * the lack of a clear methodology to identify downstream projects affected
> by a transaction relay policy wreckage
> * the lack of minimally-disruptive, emergency upgrade mechanisms
> implemented by downstream projects [2]
>
> Finally, security implications for downstream projects provoked by base
> layer issues shouldn't be minimized as they do have a risk of windblow on
> base layer operations. I believe we should minimize risks of disaster
> scenarios such as thousands of LN channels manually closed by worried
> operators due to a non-concerted security disclosure, provoking mempool
> cloaks and disrupting regular transactions for a while.
>
> # Timeline
>
> 2021-03-18 : Defect discovered, report to Dave Harding original author of
> bip125, confirmation of the defect
> 2021-03-19 : Disclosure to the Bitcoin Core security list, Dave Harding,
> Matt Corallo, acknowledgment of the issue
> 2021-04-05 : Disclosure to the LN projects maintainers (c-lightning, lnd,
> eclair, electrum, rust-lightning)
> 2021-04-28 : CVE-2021-31876 assigned
> 2021-05-06 : Full disclosure to the bitcoin-dev mailing list
>
> I believe the information reported is correct and reflects the best of my
> knowledge, please point any shortcoming.
>
> Cheers,
> Antoine
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html
> [1] See "On Mempool Funny Games against Multi-Party Funded Transactions",
> published 2021-05-06
> [2] Such as
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000e8fe2905c22bbc41
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Antoine, <br><br>Excellent work as usual!<br><br>When t=
his was initially reported, I suspected that btcd wasn&#39;t actually<br>af=
fected by this issue (proper RBF inheritance). I wrote a unit test earlier<=
br>today to confirm this: <a href=3D"https://github.com/btcsuite/btcd/pull/=
1719">https://github.com/btcsuite/btcd/pull/1719</a>. <br><br>I&#39;m parti=
cularly fond of btcd&#39;s implementation of RBF signalling:<br><a href=3D"=
https://github.com/btcsuite/btcd/blob/master/mempool/mempool.go#L603">https=
://github.com/btcsuite/btcd/blob/master/mempool/mempool.go#L603</a>. <br><b=
r>The separation of concerns here makes it (IMO) much easier to follow (as<=
br>well as uint test) compared to bitcoind&#39;s `MemPoolAccept::PreChecks`=
<br>function. Its recursive nature makes the inherited replaceability expli=
cit.<br><br>-- Laolu<br><br></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Thu, May 6, 2021 at 8:49 AM Antoine Riard =
via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi,<br><br>I&#=
39;m writing to report a defect in Bitcoin Core bip125 logic with minor sec=
urity and operational implications for downstream projects. Though this def=
ect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety isn&#39;=
t impacted.<br><br># Problem<br><br>Bip 125 specification describes the fol=
lowing signalling mechanism :<br><br>&quot;<br>This policy specifies two wa=
ys a transaction can signal that it is replaceable.<br><br>* Explicit signa=
ling: A transaction is considered to have opted in to allowing replacement =
of itself if any of its inputs have an nSequence number less than (0xffffff=
ff - 1).<br><br>* Inherited signaling: Transactions that don&#39;t explicit=
ly signal replaceability are replaceable under this policy for as long as a=
ny one of their ancestors signals replaceability and remains unconfirmed.<b=
r><br>One or more transactions currently in the mempool (original transacti=
ons) will be replaced by a new transaction (replacement transaction) that s=
pends one or more of the same inputs if,<br><br># The original transactions=
 signal replaceability explicitly or through inheritance as described in th=
e above Summary section.<br>&quot;<br><br>An unconfirmed child transaction =
with nSequence =3D 0xff_ff_ff_ff spending an unconfirmed parent with nSeque=
nce &lt;=3D 0xff_ff_ff_fd should be replaceable as the child transaction si=
gnals &quot;through inheritance&quot;. However, the replacement code as imp=
lemented in Core&#39;s `PreChecks()` shows that this behavior isn&#39;t=C2=
=A0 enforced and Core&#39;s mempool rejects replacement attempts of an unco=
nfirmed child transaction.<br><br>Branch asserting the behavior is here : <=
a href=3D"https://github.com/ariard/bitcoin/commits/2021-03-test-rbf" targe=
t=3D"_blank">https://github.com/ariard/bitcoin/commits/2021-03-test-rbf</a>=
<br><br># Solution<br><br>The defect has not been patched.<br><br># Downstr=
eam Projects Affected<br><br>* LN : State-of-the-art pinning attacks agains=
t second-stage HTLCs transactions were thought to be only possible by explo=
iting RBF rule 3 on the necessity of a higher absolute fee [0]. However, th=
is 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&#39;min feerate. This also increases odds of attack succ=
ess for a reduced feerate diminishes odds of confirmation ending the pinnin=
g. <br><br>A functional test demo illustrating cases is available on this b=
ranch: <a href=3D"https://github.com/ariard/bitcoin/commits/2021-05-htlc-pr=
eimage-pinnings" target=3D"_blank">https://github.com/ariard/bitcoin/commit=
s/2021-05-htlc-preimage-pinnings</a><br><br>LN nodes operators concerned by=
 this defect might favor anchor outputs channels, fully mitigating this spe=
cific pinning vector.<br><br>* Onchain DLC/Coinswap/Vault : Those contract =
protocols have also multiple stages of execution with time-sensitive transa=
ctions opening the way to pinning attacks. Those protocols being non-deploy=
ed or in early phase, I would recommend that any in-protocol competing tran=
sactions explicitly signal RBF.<br><br>* Coinjoin/Cut-Through : if CPFP is =
employed as a fee-bumping strategy, if the coinjoin transaction is still la=
ying in network mempools, if a fee-bumping output is spendable by any proto=
col participant, this fee-bumping mechanism might be halted by a malicious =
protocol participant broadcasting an low-feerate opt-out child. According t=
o bip125, if the coinjoin parent tx signals replaceability, the child trans=
action should be replaceable, whatever its signaling. However Core doesn&#3=
9;t apply this policy. RBF of the coinjoin transaction itself should be use=
d as a fallback. I&#39;m not aware of any deployed coinjoin using such &quo=
t;anyone-can-bump&quot; fee-bumping strategy.<br><br>* Simple wallets : RBF=
 engines&#39; 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.<br><br># Discovery<br><br=
>While reviewing the LN dual-funding flow, I inquired on potential new DoS =
vectors introduced by relying on counterparty utxos in this following analy=
sis [1]. The second DoS issue &quot;RBF opt-out by a Counterparty Double-Sp=
end&quot; is relying on a malicious chain of transactions where the parent =
is signaling RBF opt-in through nSequence&lt;=3D0xff_ff_ff_ff-1 but the chi=
ld, servicing as a pinning transaction, opt-out from the RBF policy. This p=
inning trick conception was matching my understanding of Core code but whil=
e reading again the specification, I observed that it was inconsistent from=
 the inherited signaling mechanism as described in the bip&#39;s &quot;Summ=
ary&quot; section.<br><br>After exercising the logic, I did submit the defe=
ct 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&#39;s PR introducing the opt-in RBF, advicing to =
to consider security implications for deployed second-layer protocols. Afte=
r noticing the minor implications for pinning attacks on second-stage LN tr=
ansactions while talking with Matt Corallo, I did disclose to the Bitcoin C=
ore security list.<br><br>My initial report was recommending avoiding a cov=
ert patch in the mempool as risks of introducing DoS in this part of the co=
debase seemed to outweigh security of deployed LN channels. This direction =
was agreed by the opinions expressed on the security list. Beyond, there wa=
s a lack of agreement on how to proceed with the disclosure as so far in th=
e history project, transaction relay policy have not been considered as str=
ongly reliable. Though from now on, L2 protocols like Lightning are making =
assumptions on subset of this policy for their safety, such as the highligh=
ted RBF one.<br><br>Defect was disclosed to the LN projects maintainers, in=
forming them that currently in deployment anchor outputs protocol upgrade w=
as mitigating against this defect though old channels will stay vulnerable.=
 To the best of my knowledge, I didn&#39;t identify other deployed protocol=
s of which coins safety are impacted by this defect.<br><br></div># Ecosyst=
em Observations<br><div><div><br>This long-standing defect with benign secu=
rity implications provided an opportunity to exercise coordinated security =
disclosure across layers and development teams. <br><br>IMO, it underlies f=
ew interesting points:<br>* the lack of an established policy for coordinat=
ed security disclosures between a base layer implementation and its downstr=
eam projects<br>* the lack of a clear methodology to identify downstream pr=
ojects affected by a transaction relay policy wreckage<br>* the lack of min=
imally-disruptive, emergency upgrade mechanisms implemented by downstream p=
rojects [2]<br><br>Finally, security implications for downstream projects p=
rovoked by base layer issues shouldn&#39;t be minimized as they do have a r=
isk of windblow on base layer operations. I believe we should minimize risk=
s of disaster scenarios such as thousands of LN channels manually closed by=
 worried operators due to a non-concerted security disclosure, provoking me=
mpool cloaks and disrupting regular transactions for a while.<br><br># Time=
line<br><br>2021-03-18 : Defect discovered, report to Dave Harding original=
 author of bip125, confirmation of the defect<br>2021-03-19 : Disclosure to=
 the Bitcoin Core security list, Dave Harding, Matt Corallo, acknowledgment=
 of the issue<br>2021-04-05 : Disclosure to the LN projects maintainers (c-=
lightning, lnd, eclair, electrum, rust-lightning)<br>2021-04-28 : CVE-2021-=
31876 assigned<br>2021-05-06 : Full disclosure to the bitcoin-dev mailing l=
ist<br><br>I believe the information reported is correct and reflects the b=
est of my knowledge, please point any shortcoming.<br><br>Cheers,<br>Antoin=
e<br><br>[0] <a href=3D"https://lists.linuxfoundation.org/pipermail/lightni=
ng-dev/2020-April/002639.html" target=3D"_blank">https://lists.linuxfoundat=
ion.org/pipermail/lightning-dev/2020-April/002639.html</a><br>[1] See &quot=
;On Mempool Funny Games against Multi-Party Funded Transactions&quot;, publ=
ished 2021-05-06<br>[2] Such as <a href=3D"https://lists.linuxfoundation.or=
g/pipermail/lightning-dev/2020-July/002763.html" target=3D"_blank">https://=
lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html</a>=
<br></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000e8fe2905c22bbc41--