MIME-Version: 1.0
References: <CALZpt+GK4WNBmKim3w9LAd1b69+uAyAsNu5tVniHzN6Ue4KJCw@mail.gmail.com>
 <MT4soB8ro1-wKY5ht6hqY0c2OutPMDgdLrSny8I9-KPn75p6CdatFkwDZCPNI98yYXOqMeKLu9Z1EBwMXXWZQmCE6Nv70gPo6Mv8FjsGnxc=@protonmail.com>
 <CAPv7Tjb5+B5MMrf5QZySbqgoQL2+rTpcHDh5E8pBdcRgc5ZNUw@mail.gmail.com>
In-Reply-To: <CAPv7Tjb5+B5MMrf5QZySbqgoQL2+rTpcHDh5E8pBdcRgc5ZNUw@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 12 May 2021 09:11:50 -0400
Message-ID: <CALZpt+GxNF_PPN2-fSWXT3RNHTdOb1emwuXvK+iw23+XsCBaxA@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000009c43d905c221c1ae"
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

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

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 =C3=A0 17:16, Ruben Somsen <rsomsen@gmail.com> a =C3=A9=
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 th=
e
> 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 transacti=
on
> 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=3D2555
>
> As it stands, this bug gets in the way of being able to deploy spacechain=
s.
>
> -- Ruben Somsen
>
>
>
> [0]
> https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechain=
s-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 th=
e
>> 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
>>
>

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

<div dir=3D"ltr">Hi Ruben,<br><br>Thanks for raising awareness about spacec=
hains/BMM, I didn&#39;t have knowledge it was relying on a fee-based Englis=
h auction to mine side-blocks. IIUC, it&#39;s another type of dynamic membe=
rship<br>multi-party signature where parties are block-signing with a fee p=
roposal instead of a PoW ? Though you still assume mainchain miners aren&#3=
9;t colluding and blindly applying the RBF policy<br><br>Effectively, if yo=
u 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 ad=
vantage is quite easy to<br>gain with a modified client, mass-connecting an=
d not enforcing inventory broadcast interval timers.<br><br>&gt; As it stan=
ds, this bug gets in the way of being able to deploy spacechains.<br><br>No=
ted, yet another good-point to transition towards full-rbf!<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:16, Ruben Somsen &l=
t;<a href=3D"mailto:rsomsen@gmail.com">rsomsen@gmail.com</a>&gt; a =C3=A9cr=
it=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr">Hi Antoine,<div><br></div><div>Thanks for bringing this up.</div=
><div><br></div><div>It seems spacechains[0]=C2=A0are impacted by this. Sim=
ply 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 bl=
ock hash. The preferred mechanism utilizes sighash_anyprevout and is not af=
fected, but there is also a practical variant that could be used without re=
quiring the anyprevout soft fork, which unfortunately does seem to be impac=
ted. Here&#39;s a brief description:</div><div><br></div><div>TX0:</div><di=
v><br></div><div>input 0</div><div><br></div><div>output 1a*</div><div>outp=
ut 1b</div><div><br></div><div>TX1:</div><div><br></div><div>input 1a*</div=
><div><br></div><div>output 2a**</div><div>output 2b</div><div><br></div><d=
iv><div>TX2:</div><div><br></div><div>input 2a**</div><div><br></div><div>o=
utput 3a***</div><div>output 3b</div></div><div><br></div><div>Etc.</div><d=
iv><br></div><div>Every TX has two outputs, one of which (&quot;a&quot;) is=
 used as the input for the next TX (these are pre-signed and act as a coven=
ant), resulting in a continuous chain of transactions. The other output (&q=
uot;b&quot;) 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 h=
ighest CPFP fee to &quot;win the RBF auction&quot; and attach their TX to t=
he output, containing the winning spacechain block hash.</div><div><br></di=
v><div>With inherited signalling, this works because each pre-signed TX is =
RBF enabled, so each CPFP transaction inherits RBF as well. But if inherite=
d signalling does not function, the first person who makes a CPFP transacti=
on can simply disable RBF and win the auction, thus breaking the intended f=
ee-bidding mechanism.</div><div><br></div><div>You can also find a diagram =
in this spacechains presentation (timestamped link):=C2=A0<a href=3D"https:=
//youtu.be/N2ow4Q34Jeg?t=3D2555" target=3D"_blank">https://youtu.be/N2ow4Q3=
4Jeg?t=3D2555</a></div><div><br></div><div>As it stands, this bug gets in t=
he way of being able to deploy spacechains.</div><div><br></div><div>-- Rub=
en Somsen</div><div><br></div><div><br></div><div><br></div><div>[0]=C2=A0<=
a href=3D"https://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-s=
idechains-the-perpetual-one-way-peg-96cb2f8ac302" target=3D"_blank">https:/=
/medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-the-per=
petual-one-way-peg-96cb2f8ac302</a></div><div><br></div><div>[1]=C2=A0<a hr=
ef=3D"https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5"=
 target=3D"_blank">https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d=
8b34906b16a5</a></div><div><br></div><div><br></div><div><br></div></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, =
May 9, 2021 at 10:41 AM darosior via bitcoin-dev &lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">Hi Antoine,<div><br></div><div><br></div>Thank you for the d=
isclosure.<div><br></div><div><br></div><div><br></div>&gt; * Onchain DLC/C=
oinswap/Vault : Those contract protocols have also multiple stages of execu=
tion with time-sensitive transactions opening the way to pinning attacks. T=
hose protocols being non-deployed or in early phase, I would recommend that=
 any in-protocol competing transactions explicitly signal RBF.<div><br></di=
v><div><br></div>For what it&#39;s worth, Revault isn&#39;t vulnerable as a=
ll transactions signal RBF and there is no way to sneak a non-signaling com=
peting transaction (as long as the CSV isn&#39;t matured yet).<div><br></di=
v><div><br></div><div><br></div>Thanks,<div><br></div>Antoine (the other on=
e)_______________________________________________<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>
</blockquote></div>

--0000000000009c43d905c221c1ae--