path: root/61/acbbd434bfe3e4ae712faa1a5eac66949a17b5

Return-Path: <rsomsen@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 44168C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 21:16:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 2356F40E72
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 21:16:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Doe_Sdcz6EnZ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 21:16:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
 [IPv6:2a00:1450:4864:20::529])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 6FBC640E70
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 21:16:32 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id n25so24562934edr.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 14:16:32 -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=NHfRYCANiibD6lgDHDPqbS/Xo6jLajCqr+WM7KQhRAg=;
 b=kS+u5CsK1EH8TwfgjcIjmDf56xhTCd4vqNF0S3mjkPREJgz7FlT6cPXHN7O5YZDMOX
 +5G5nR31h1H+mM1qaaTF1E4eIv5q+a8zrXa8RZaYTHY37c0U2GolXoix8VE/ilwbvRh7
 lskqOiYF2ON1Cg+FujNEF0lYYhjyDcRMo5kLc+ekl2QwHMgI2VoAsKUaTv/qnBJvAmHi
 jWvu+rXWT/7JHvkp9b2ZO09EY+46nFWMw8BORe95BuyR+a/sjqMPFC9Ey69Rcct5LsEC
 ZiR4bcZLyrqi++g2T6f5QgNVfZKk4GRX3Bg1NTX/rK4pHdlLiTSQm0K1U3OlmRYFyP5z
 xt8Q==
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=NHfRYCANiibD6lgDHDPqbS/Xo6jLajCqr+WM7KQhRAg=;
 b=diOvWL3wUyRPqM9MR/hso2Msa8rswu7vXxBr7HFhgeZmoJpuerS/7dr4+wWODE2zox
 JDn0prNR2SMtwy8vVmEaUMCATBZzkHZdADcmfcqTonvKTgATLE/yQQulJuK/AllvCYts
 x9tIz2+I0kVu2yrY2MpuIscHXQhU7zAFgvU/IVvaBvgaouKcAbYfSqkZYW95F9pip4u5
 sOLuOO/XrIRHkwztlky0ylngR9AW+bkCLTQjNRJx2oTCmrrG3d02aRsUgBsXfu3sVyf6
 fr+u9YpiOJp/6duDxV7hpAZ8GbEBvJnOrljQGbvb1+rVXfnsTymMlg6omiNi5NtQz0Eu
 g4oQ==
X-Gm-Message-State: AOAM533Qg0KzKHKEgfcIJMulAT0gqA1z4B1x8iJReGn+WzzPj09HxVD1
 k2JBu0mTAyxQuuLcvKVJqvXAqEb7YIDOmhYgZu8=
X-Google-Smtp-Source: ABdhPJxFDEWCkGTs0oQLPbhl04IJradsP+DX1t1zoZLikZ/vPHZP1R/kcBi/jyYiohEdtCrvSBUEnAnoMbZWvXDtuF4=
X-Received: by 2002:a05:6402:4251:: with SMTP id
 g17mr38122663edb.205.1620767790586; 
 Tue, 11 May 2021 14:16:30 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GK4WNBmKim3w9LAd1b69+uAyAsNu5tVniHzN6Ue4KJCw@mail.gmail.com>
 <MT4soB8ro1-wKY5ht6hqY0c2OutPMDgdLrSny8I9-KPn75p6CdatFkwDZCPNI98yYXOqMeKLu9Z1EBwMXXWZQmCE6Nv70gPo6Mv8FjsGnxc=@protonmail.com>
In-Reply-To: <MT4soB8ro1-wKY5ht6hqY0c2OutPMDgdLrSny8I9-KPn75p6CdatFkwDZCPNI98yYXOqMeKLu9Z1EBwMXXWZQmCE6Nv70gPo6Mv8FjsGnxc=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Tue, 11 May 2021 23:16:18 +0200
Message-ID: <CAPv7Tjb5+B5MMrf5QZySbqgoQL2+rTpcHDh5E8pBdcRgc5ZNUw@mail.gmail.com>
To: antoine.riard@gmail.com
Content-Type: multipart/alternative; boundary="0000000000006bdf1505c21468f8"
X-Mailman-Approved-At: Tue, 11 May 2021 21:16:59 +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: Tue, 11 May 2021 21:16:35 -0000

--0000000000006bdf1505c21468f8
Content-Type: text/plain; charset="UTF-8"

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
>

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

<div dir=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 thi=
s. Simply explained, the idea is to allow for fee-bidding Blind Merged Mini=
ng[1] by creating one transaction for each block, to which anyone can attac=
h a block hash. The preferred mechanism utilizes sighash_anyprevout and is =
not affected, but there is also a practical variant that could be used with=
out requiring the anyprevout soft fork, which unfortunately does seem to be=
 impacted. Here&#39;s a brief description:</div><div><br></div><div>TX0:</d=
iv><div><br></div><div>input 0</div><div><br></div><div>output 1a*</div><di=
v>output 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><div><div>TX2:</div><div><br></div><div>input 2a**</div><div><br></div>=
<div>output 3a***</div><div>output 3b</div></div><div><br></div><div>Etc.</=
div><div><br></div><div>Every TX has two outputs, one of which (&quot;a&quo=
t;) 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 outp=
ut (&quot;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 highest CPFP fee to &quot;win the RBF auction&quot; and attach their T=
X to the output, containing the winning spacechain block hash.</div><div><b=
r></div><div>With inherited signalling, this works because each pre-signed =
TX is RBF enabled, so each CPFP transaction inherits RBF as well. But if in=
herited signalling does not function, the first person who makes a CPFP tra=
nsaction can simply disable RBF and win the auction, thus breaking the inte=
nded fee-bidding mechanism.</div><div><br></div><div>You can also find a di=
agram in this spacechains presentation (timestamped link):=C2=A0<a href=3D"=
https://youtu.be/N2ow4Q34Jeg?t=3D2555">https://youtu.be/N2ow4Q34Jeg?t=3D255=
5</a></div><div><br></div><div>As it stands, this bug gets in the way of be=
ing able to deploy spacechains.</div><div><br></div><div>-- Ruben Somsen</d=
iv><div><br></div><div><br></div><div><br></div><div>[0]=C2=A0<a href=3D"ht=
tps://medium.com/@RubenSomsen/21-million-bitcoins-to-rule-all-sidechains-th=
e-perpetual-one-way-peg-96cb2f8ac302">https://medium.com/@RubenSomsen/21-mi=
llion-bitcoins-to-rule-all-sidechains-the-perpetual-one-way-peg-96cb2f8ac30=
2</a></div><div><br></div><div>[1]=C2=A0<a href=3D"https://gist.github.com/=
RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5">https://gist.github.com/Ruben=
Somsen/5e4be6d18e5fa526b17d8b34906b16a5</a></div><div><br></div><div><br></=
div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Sun, May 9, 2021 at 10:41 AM darosior via bitcoin-dev=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">Hi Antoine,<div><br></div><div><br></div>Thank you =
for the disclosure.<div><br></div><div><br></div><div><br></div>&gt; * Onch=
ain DLC/Coinswap/Vault : Those contract protocols have also multiple stages=
 of execution with time-sensitive transactions opening the way to pinning a=
ttacks. Those protocols being non-deployed or in early phase, I would recom=
mend that any in-protocol competing transactions explicitly signal RBF.<div=
><br></div><div><br></div>For what it&#39;s worth, Revault isn&#39;t vulner=
able as all transactions signal RBF and there is no way to sneak a non-sign=
aling competing transaction (as long as the CSV isn&#39;t matured yet).<div=
><br></div><div><br></div><div><br></div>Thanks,<div><br></div>Antoine (the=
 other one)_______________________________________________<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>

--0000000000006bdf1505c21468f8--