From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 91DFBC0001 for ; 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 ; 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 ; 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 ; Wed, 12 May 2021 13:12:03 +0000 (UTC) Received: by mail-wm1-x330.google.com with SMTP id j3-20020a05600c4843b02901484662c4ebso3006711wmo.0 for ; 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: In-Reply-To: From: Antoine Riard Date: Wed, 12 May 2021 09:11:50 -0400 Message-ID: To: Ruben Somsen Content-Type: multipart/alternative; boundary="0000000000009c43d905c221c1ae" X-Mailman-Approved-At: Wed, 12 May 2021 13:30:25 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
Hi Ruben,

Thanks for raising awareness about spacec= hains/BMM, I didn't have knowledge it was relying on a fee-based Englis= h auction to mine side-blocks. IIUC, it's another type of dynamic membe= rship
multi-party signature where parties are block-signing with a fee p= roposal instead of a PoW ? Though you still assume mainchain miners aren= 9;t colluding and blindly applying the RBF policy

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
gain with a modified client, mass-connecting an= d not enforcing inventory broadcast interval timers.

> As it stan= ds, this bug gets in the way of being able to deploy spacechains.

No= ted, yet another good-point to transition towards full-rbf!

Cheers,<= br>Antoine

Le=C2=A0mar. 11 mai 2021 =C3=A0=C2=A017:16, Ruben Somsen &l= t;rsomsen@gmail.com> a =C3=A9cr= it=C2=A0:
Hi Antoine,

Thanks for bringing this up.

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's a brief description:

TX0:

input 0

output 1a*
outp= ut 1b

TX1:

input 1a*

output 2a**
output 2b

TX2:

input 2a**

o= utput 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 coven= ant), resulting in a continuous chain of transactions. The other output (&q= uot;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 h= ighest CPFP fee to "win the RBF auction" and attach their TX to t= he 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 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.

You can also find a diagram = in this spacechains presentation (timestamped link):=C2=A0https://youtu.be/N2ow4Q3= 4Jeg?t=3D2555

As it stands, this bug gets in t= he way of being able to deploy spacechains.

-- Rub= en Somsen



[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




On Sun, = May 9, 2021 at 10:41 AM darosior via bitcoin-dev <bitcoin-dev@lists.linu= xfoundation.org> wrote:
Hi Antoine,


Thank you for the d= isclosure.



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


For what it's worth, Revault isn'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't matured yet).



Thanks,

Antoine (the other on= e)_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000009c43d905c221c1ae--