path: root/6d/e61b32394716ed1f1ceca412e782918006aa5c

Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 91DFBC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 May 2021 13:12:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 6B1E883D5E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 May 2021 13:12:05 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.602
X-Spam-Level: 
X-Spam-Status: No, score=0.602 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 scgYE3EfFwii
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 May 2021 13:12:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com
 [IPv6:2a00:1450:4864:20::330])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 46D0983D56
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 May 2021 13:12:03 +0000 (UTC)
Received: by mail-wm1-x330.google.com with SMTP id
 j3-20020a05600c4843b02901484662c4ebso3006711wmo.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 12 May 2021 06:12:03 -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
 :cc; bh=pKuo17M3eD63ul/wk3oQQDap6pASVlD2+Vr7iMqooAw=;
 b=pJs1t+Y1TtgvhuUBP9TpEwajmbQqLdfxIVVFxxlNALSQDOiKiBsa/jgJnsz8UzSe/h
 y+uVHePhQwZxKz9tzV4T+08a9TPT2zmrDUNkN4nu8aWJTOy52UAtnxjmJlXSSE2GFp1d
 O2+6d1bxhy12pkV4m1p0KFWY4eVxkJR4+/tqfAX5jyfOL7xNQWgzm7XlD7TPCuUzDteK
 H+EzuJl5p7U5ETd/JganiZalPmGQUCfbiVQsIjPkHOoa7ohBCAkrJUN5mDrNzCC+d6En
 qUmB9JXxvpQxFqLTMtU8mAtJKlA+9yuw/8ux5p91diABwXBt9ogiQzmsiTtpYUXt9HSZ
 QOqg==
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:cc;
 bh=pKuo17M3eD63ul/wk3oQQDap6pASVlD2+Vr7iMqooAw=;
 b=XeaKDFbUtHV27rLWmWHkmMmk40T/Q9Xbz0znOdf/SXfksM2aKYlHTujiNGME7jI0oK
 sSx/op5/t/dH2CzKG06rLjUr8uvtwNDAHiI1fYXUvonu3hwwIBXxmzD5rVxEH5PwRJ0i
 6UV28jEAVVWq+ubEN05dyyleaz+xImiYlBOsmjIMjCdvE77Hc8rCSrYwgfPJpFqYdBmt
 2dO0tYV/KgL8eH7WehISnMWEF807StXarbWIHYKpmqOM2YaaFUWc+Od6yJiSH7XQjPOj
 qM1TcaQxe5Q9xKTwzpx61CsgwGXq5mqjHDsFDDsMQkZsovvnTjZor0+7JgW41cdbPUaM
 z9eQ==
X-Gm-Message-State: AOAM530vfvGd3SfOhjPxTv2ZouHx8hpgWjs3fQzaK0AYvrFVSSlPRXYB
 MLCdbphhh+ki2mSxT7epVtQtvYI/wv8cKFQMTLo=
X-Google-Smtp-Source: ABdhPJyiMfiH3vI5Jnql1HJ5nmCSCE6D6M/fL/yzzevhcTyT4+o/GR1rixlj4uKFnMRAtP7raCR4xPUb1vCwxzWtxuc=
X-Received: by 2002:a7b:c196:: with SMTP id y22mr39017181wmi.1.1620825121505; 
 Wed, 12 May 2021 06:12:01 -0700 (PDT)
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"
X-Mailman-Approved-At: Wed, 12 May 2021 13:30:25 +0000
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
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: Wed, 12 May 2021 13:12:05 -0000

--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--