MIME-Version: 1.0
References: <CALZpt+GK4WNBmKim3w9LAd1b69+uAyAsNu5tVniHzN6Ue4KJCw@mail.gmail.com>
 <202105112150.51410.luke@dashjr.org>
In-Reply-To: <202105112150.51410.luke@dashjr.org>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 12 May 2021 09:19:37 -0400
Message-ID: <CALZpt+FNGtXQuVF9JmtK-OQTxEu89ks42Y7j1NWqHSxc79uiWg@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary="0000000000007ef2e605c221dd3f"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Full Disclosure: CVE-2021-31876 Defect in Bitcoin
 Core's bip125 logic
Precedence: list

--0000000000007ef2e605c221dd3f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =C3=A0 17:51, Luke Dashjr <luke@dashjr.org> a =C3=A9cri=
t :

> 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 (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 transaction=
s)
> > 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 =3D 0xff_ff_ff_ff spend=
ing
> an
> > unconfirmed parent with nSequence <=3D 0xff_ff_ff_fd should be replacea=
ble
> 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 attempt=
s
> 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 abov=
e
> > 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-pinning=
s
> >
> > 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 participa=
nt
> > 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 D=
oS
> > 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<=3D0xff_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 cod=
e
> > 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 mempo=
ol
> > 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 o=
n
> > 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 tha=
t
> > currently in deployment anchor outputs protocol upgrade was mitigating
> > against this defect though old channels will stay vulnerable. To the be=
st
> > 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 a=
nd
> > development teams.
> >
> > IMO, it underlies few interesting points:
> > * the lack of an established policy for coordinated security disclosure=
s
> > 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, ln=
d,
> > 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/0026=
39
> >.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/00276=
3
> .
> >html
>
>

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

<div dir=3D"ltr">Hi Luke,<br><br>&gt; Is there a list of software impacted =
by this CVE, and the versions it is fixed <br>in?<br><br>Speaking only for =
LN clients, as I think they&#39;re the only ones deployed with real funds a=
t stake. Defect is mitigated by new &quot;anchor&quot; channel type, forcin=
g RBF-signaling on all transactions.<br>* lnd v0.12 &quot;anchor&quot; acti=
vated by default, lnd v0.10 &quot;anchor&quot; activated by user flag<br>* =
c-lightning, no release yet with &quot;anchor&quot; support<br>* eclair, no=
 release yet with &quot;anchor&quot; support<br>* rust-lightning, no releas=
e yet with &quot;anchor&quot; support<br><br>&gt; (Note this isn&#39;t a vu=
lnerability in Bitcoin Core; BIP125 is strictly a policy <br>matter, not pa=
rt of the consensus rules and never safe to rely on in any <br>case...)<br>=
<br>Answering two-folds. <br><br>First I somehow agree it&#39;s not a &quot=
;vulnerability&quot; in Bitcoin Core but at least a clear lack of complianc=
e to a heavily relied-on bitcoin standard through the ecosystem. Even if BI=
Ps are descriptive documentation and not prescriptive, I don&#39;t think we=
 have guidelines for now on how to proceed with identified flaws with secur=
ity implications for downstream projects.<br><br>Should the Bitcoin Core pr=
oject adopt a security bulletin or advisories for security-related info per=
tinent for downstream ?<br><br>Secondly, opinions were divergent on the sec=
urity list on how to report on this. On one side, tx-relay and mempool acce=
ptance rules aren&#39;t considered as reliable or strongly normative and pu=
rely a matter of node&#39;s policy. <br><br>On the other side, we have more=
 and more deployed Bitcoin applications/protocols (e.g LN, vaults, ...) dir=
ectly making security assumptions on them. Even if we consider such beliefs=
 misplaced or ingenious, we&#39;re laying on top of a permissionless system=
 and can&#39;t really prevent developers and users from deploying such soft=
wares.<br><br>Should we stay on this statu quo and invite such Bitcoin user=
s to deploy their own overlay network for transaction propagation satisfyin=
g their advanced requirements, at the price of far-less censorship-resistan=
ce and a more opaque fee market for everyone ?<br><br>Or instead qualify a =
new, third set of rules between consensus and pure &quot;policy&quot;, espe=
cially crafted to support Bitcoin applications requiring transparency and s=
tability of tx-relay and mempool acceptance rules, at the price of ossifyin=
g some part of full-nodes ? Of course, the degree of normativity we could g=
uarantee for those rules is making them compatible with economic incentives=
 of everyone. Hopefully fostering their wide dissemination across full-node=
 implementations and miner mempools.<br><br>You have good arguments and tra=
de-offs on both sides. <br><br>Overall, I agree that describing tx-relay/me=
mpool rules as non-normative, non-reliable is the most understood mental mo=
del among developers *today*. That said, I would like to underscore that th=
is model might not be adequate in light of recent ecosystem evolutions and =
reveal itself a bit crippling the future...<br><br>Cheers,<br>Antoine<br></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=
=C2=A0mar. 11 mai 2021 =C3=A0=C2=A017:51, Luke Dashjr &lt;<a href=3D"mailto=
:luke@dashjr.org">luke@dashjr.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">Is there a list of software i=
mpacted by this CVE, and the versions it is fixed <br>
in?<br>
<br>
(Note this isn&#39;t a vulnerability in Bitcoin Core; BIP125 is strictly a =
policy <br>
matter, not part of the consensus rules and never safe to rely on in any <b=
r>
case...)<br>
<br>
<br>
On Thursday 06 May 2021 13:55:53 Antoine Riard via bitcoin-dev wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I&#39;m writing to report a defect in Bitcoin Core bip125 logic with m=
inor<br>
&gt; security and operational implications for downstream projects. Though =
this<br>
&gt; defect grieves Bitcoin Core nodes 0.12.0 and above, base layer safety =
isn&#39;t<br>
&gt; impacted.<br>
&gt;<br>
&gt; # Problem<br>
&gt;<br>
&gt; Bip 125 specification describes the following signalling mechanism :<b=
r>
&gt;<br>
&gt; &quot;<br>
&gt; This policy specifies two ways a transaction can signal that it is<br>
&gt; replaceable.<br>
&gt;<br>
&gt; * Explicit signaling: A transaction is considered to have opted in to<=
br>
&gt; allowing replacement of itself if any of its inputs have an nSequence<=
br>
&gt; number less than (0xffffffff - 1).<br>
&gt;<br>
&gt; * Inherited signaling: Transactions that don&#39;t explicitly signal<b=
r>
&gt; replaceability are replaceable under this policy for as long as any on=
e of<br>
&gt; their ancestors signals replaceability and remains unconfirmed.<br>
&gt;<br>
&gt; One or more transactions currently in the mempool (original transactio=
ns)<br>
&gt; will be replaced by a new transaction (replacement transaction) that s=
pends<br>
&gt; one or more of the same inputs if,<br>
&gt;<br>
&gt; # The original transactions signal replaceability explicitly or throug=
h<br>
&gt; inheritance as described in the above Summary section.<br>
&gt; &quot;<br>
&gt;<br>
&gt; An unconfirmed child transaction with nSequence =3D 0xff_ff_ff_ff spen=
ding an<br>
&gt; unconfirmed parent with nSequence &lt;=3D 0xff_ff_ff_fd should be repl=
aceable as<br>
&gt; the child transaction signals &quot;through inheritance&quot;. However=
, the<br>
&gt; replacement code as implemented in Core&#39;s `PreChecks()` shows that=
 this<br>
&gt; behavior isn&#39;t=C2=A0 enforced and Core&#39;s mempool rejects repla=
cement attempts of<br>
&gt; an unconfirmed child transaction.<br>
&gt;<br>
&gt; Branch asserting the behavior is here :<br>
&gt; <a href=3D"https://github.com/ariard/bitcoin/commits/2021-03-test-rbf"=
 rel=3D"noreferrer" target=3D"_blank">https://github.com/ariard/bitcoin/com=
mits/2021-03-test-rbf</a><br>
&gt;<br>
&gt; # Solution<br>
&gt;<br>
&gt; The defect has not been patched.<br>
&gt;<br>
&gt; # Downstream Projects Affected<br>
&gt;<br>
&gt; * LN : State-of-the-art pinning attacks against second-stage HTLCs<br>
&gt; transactions were thought to be only possible by exploiting RBF rule 3=
 on<br>
&gt; the necessity of a higher absolute fee [0]. However, this replacement<=
br>
&gt; defect opens the way for an attacker to only pin with an opt-out child=
<br>
&gt; without a higher fee than the honest competing transaction. This lower=
s the<br>
&gt; cost of attack as the malicious pinning transaction only has to be abo=
ve<br>
&gt; mempools&#39;min feerate. This also increases odds of attack success f=
or a<br>
&gt; reduced feerate diminishes odds of confirmation ending the pinning.<br=
>
&gt;<br>
&gt; A functional test demo illustrating cases is available on this branch:=
<br>
&gt; <a href=3D"https://github.com/ariard/bitcoin/commits/2021-05-htlc-prei=
mage-pinnings" rel=3D"noreferrer" target=3D"_blank">https://github.com/aria=
rd/bitcoin/commits/2021-05-htlc-preimage-pinnings</a><br>
&gt;<br>
&gt; LN nodes operators concerned by this defect might favor anchor outputs=
<br>
&gt; channels, fully mitigating this specific pinning vector.<br>
&gt;<br>
&gt; * Onchain DLC/Coinswap/Vault : Those contract protocols have also mult=
iple<br>
&gt; stages of execution with time-sensitive transactions opening the way t=
o<br>
&gt; pinning attacks. Those protocols being non-deployed or in early phase,=
 I<br>
&gt; would recommend that any in-protocol competing transactions explicitly=
<br>
&gt; signal RBF.<br>
&gt;<br>
&gt; * Coinjoin/Cut-Through : if CPFP is employed as a fee-bumping strategy=
, if<br>
&gt; the coinjoin transaction is still laying in network mempools, if a<br>
&gt; fee-bumping output is spendable by any protocol participant, this<br>
&gt; fee-bumping mechanism might be halted by a malicious protocol particip=
ant<br>
&gt; broadcasting an low-feerate opt-out child. According to bip125, if the=
<br>
&gt; coinjoin parent tx signals replaceability, the child transaction shoul=
d be<br>
&gt; replaceable, whatever its signaling. However Core doesn&#39;t apply th=
is<br>
&gt; policy. RBF of the coinjoin transaction itself should be used as a<br>
&gt; fallback. I&#39;m not aware of any deployed coinjoin using such<br>
&gt; &quot;anyone-can-bump&quot; fee-bumping strategy.<br>
&gt;<br>
&gt; * Simple wallets : RBF engines&#39; behaviors might be altered in ways=
 not<br>
&gt; matching the intent of their developers. I invite RBF engines dev to v=
erify<br>
&gt; what those components are doing in the light of disclosed information.=
<br>
&gt;<br>
&gt; # Discovery<br>
&gt;<br>
&gt; While reviewing the LN dual-funding flow, I inquired on potential new =
DoS<br>
&gt; vectors introduced by relying on counterparty utxos in this following<=
br>
&gt; analysis [1]. The second DoS issue &quot;RBF opt-out by a Counterparty=
<br>
&gt; Double-Spend&quot; is relying on a malicious chain of transactions whe=
re the<br>
&gt; parent is signaling RBF opt-in through nSequence&lt;=3D0xff_ff_ff_ff-1=
 but the<br>
&gt; child, servicing as a pinning transaction, opt-out from the RBF policy=
.<br>
&gt; This pinning trick conception was matching my understanding of Core co=
de<br>
&gt; but while reading again the specification, I observed that it was<br>
&gt; inconsistent from the inherited signaling mechanism as described in th=
e<br>
&gt; bip&#39;s &quot;Summary&quot; section.<br>
&gt;<br>
&gt; After exercising the logic, I did submit the defect to Dave Harding, a=
sking<br>
&gt; confirmation of divergence between Bitcoin Core and BIP 125. Soon afte=
r, he<br>
&gt; did confirm it and pointed that the defect has been there since the 20=
15&#39;s<br>
&gt; PR introducing the opt-in RBF, advicing to to consider security<br>
&gt; implications for deployed second-layer protocols. After noticing the m=
inor<br>
&gt; implications for pinning attacks on second-stage LN transactions while=
<br>
&gt; talking with Matt Corallo, I did disclose to the Bitcoin Core security=
<br>
&gt; list.<br>
&gt;<br>
&gt; My initial report was recommending avoiding a covert patch in the memp=
ool<br>
&gt; as risks of introducing DoS in this part of the codebase seemed to out=
weigh<br>
&gt; security of deployed LN channels. This direction was agreed by the opi=
nions<br>
&gt; expressed on the security list. Beyond, there was a lack of agreement =
on<br>
&gt; how to proceed with the disclosure as so far in the history project,<b=
r>
&gt; transaction relay policy have not been considered as strongly reliable=
.<br>
&gt; Though from now on, L2 protocols like Lightning are making assumptions=
 on<br>
&gt; subset of this policy for their safety, such as the highlighted RBF on=
e.<br>
&gt;<br>
&gt; Defect was disclosed to the LN projects maintainers, informing them th=
at<br>
&gt; currently in deployment anchor outputs protocol upgrade was mitigating=
<br>
&gt; against this defect though old channels will stay vulnerable. To the b=
est<br>
&gt; of my knowledge, I didn&#39;t identify other deployed protocols of whi=
ch coins<br>
&gt; safety are impacted by this defect.<br>
&gt;<br>
&gt; # Ecosystem Observations<br>
&gt;<br>
&gt; This long-standing defect with benign security implications provided a=
n<br>
&gt; opportunity to exercise coordinated security disclosure across layers =
and<br>
&gt; development teams.<br>
&gt;<br>
&gt; IMO, it underlies few interesting points:<br>
&gt; * the lack of an established policy for coordinated security disclosur=
es<br>
&gt; between a base layer implementation and its downstream projects<br>
&gt; * the lack of a clear methodology to identify downstream projects affe=
cted<br>
&gt; by a transaction relay policy wreckage<br>
&gt; * the lack of minimally-disruptive, emergency upgrade mechanisms<br>
&gt; implemented by downstream projects [2]<br>
&gt;<br>
&gt; Finally, security implications for downstream projects provoked by bas=
e<br>
&gt; layer issues shouldn&#39;t be minimized as they do have a risk of wind=
blow on<br>
&gt; base layer operations. I believe we should minimize risks of disaster<=
br>
&gt; scenarios such as thousands of LN channels manually closed by worried<=
br>
&gt; operators due to a non-concerted security disclosure, provoking mempoo=
l<br>
&gt; cloaks and disrupting regular transactions for a while.<br>
&gt;<br>
&gt; # Timeline<br>
&gt;<br>
&gt; 2021-03-18 : Defect discovered, report to Dave Harding original author=
 of<br>
&gt; bip125, confirmation of the defect<br>
&gt; 2021-03-19 : Disclosure to the Bitcoin Core security list, Dave Hardin=
g,<br>
&gt; Matt Corallo, acknowledgment of the issue<br>
&gt; 2021-04-05 : Disclosure to the LN projects maintainers (c-lightning, l=
nd,<br>
&gt; eclair, electrum, rust-lightning)<br>
&gt; 2021-04-28 : CVE-2021-31876 assigned<br>
&gt; 2021-05-06 : Full disclosure to the bitcoin-dev mailing list<br>
&gt;<br>
&gt; I believe the information reported is correct and reflects the best of=
 my<br>
&gt; knowledge, please point any shortcoming.<br>
&gt;<br>
&gt; Cheers,<br>
&gt; Antoine<br>
&gt;<br>
&gt; [0]<br>
&gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2=
020-April/002639" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxf=
oundation.org/pipermail/lightning-dev/2020-April/002639</a><br>
&gt;.html [1] See &quot;On Mempool Funny Games against Multi-Party Funded<b=
r>
&gt; Transactions&quot;, published 2021-05-06<br>
&gt; [2] Such as<br>
&gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2=
020-July/002763" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfo=
undation.org/pipermail/lightning-dev/2020-July/002763</a>.<br>
&gt;html<br>
<br>
</blockquote></div>

--0000000000007ef2e605c221dd3f--