From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id C1ACEC000D for ; Thu, 9 Sep 2021 00:03:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id AA6C283486 for ; Thu, 9 Sep 2021 00:03:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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 FJChz-3LgJ-1 for ; Thu, 9 Sep 2021 00:02:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by smtp1.osuosl.org (Postfix) with ESMTPS id 4625A83438 for ; Thu, 9 Sep 2021 00:02:59 +0000 (UTC) Received: by mail-wr1-x42b.google.com with SMTP id b6so5709371wrh.10 for ; Wed, 08 Sep 2021 17:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FL0+L408Uo6Rr7VZq1wmVJJoLi0tpFUWPdM6Q/sBFUY=; b=hTdTpIGsqLd7K8kBd2zxHEqi7Cp7wspmQAvljs3OPE1NXBDLsMFO5oYf/Se9vJ3OEC MaF1OcdL6hscGNaqurQSTHskcwTMq9PqOODM6I2odTS3oymsoAkSaYY/icFXoDcpJ3li 1JXwVFlpL3Gl1d8NsnoxmkAjJUBYzElnsTdTuaIfuY4oDyliezwJgQvusnouN3CSDzlY i3c43Qqha712GknmqVi6UF8FooYpcvIgOZlFr6abuPcsd02UguKL4ShnHFoPozaDW2m4 7NcdawH7E8mFthbqC4Jhedzk7YDt3x8UFqw+N98HamsJte1FfJ6H3o0HUPVgZfshJu5D D/yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FL0+L408Uo6Rr7VZq1wmVJJoLi0tpFUWPdM6Q/sBFUY=; b=o+psLyN2fHuncO8fHyxCoaD/N30ZDDo5f6MhxlXvh3ARSfb3rY4oUCJJc7D/iD+rJe ZgQ8KF26qwwEOCwxnW8h8LQXBFjSFJE+C7TtR28eZpg8d0xNMMqkBty1vLsDmfm+4EsE FPUZWu6VaVCu9Nveyq6IUyTpOJr5HaT+0cTERWjvwl7JfMUGL+IO4mUqXXs2mx5eOftY nwnDSmKIVfB1aqMMdsJ5vGjOgddjZ+ya7M09Z1nxNJdtUeT+wTsEAuPao9M6myoy64cZ cBhiwAXj7db5oDhDtBjnIbpYS9ZSQPHObpf8tg5qJql0lXl8a/E1lJ4mO4fABdh3lWUF HxPA== X-Gm-Message-State: AOAM531N3UPznnCbMs6mvLA5rqPNPaYErG8lQkqyHfOGdsFum4sAojXI 39rTXdCtFY2m0S7ZCM/hmkG4jzDAs2ENAhIBOSLdI3pqJMA= X-Google-Smtp-Source: ABdhPJxKrxjuirz5XQwKACnUyrm12qUlI8xB05d/wN2UR5v3u6abyNGNt5/wu+QXZHPv5t3qY3bWkbc/bjTBj2cIOiU= X-Received: by 2002:adf:c510:: with SMTP id q16mr219358wrf.203.1631145777232; Wed, 08 Sep 2021 17:02:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Wed, 8 Sep 2021 20:02:45 -0400 Message-ID: To: Jeremy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a1042f05cb84b826" X-Mailman-Approved-At: Thu, 09 Sep 2021 07:55:00 +0000 Subject: Re: [bitcoin-dev] Note on Sequence Lock Upgrades Defect 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: Thu, 09 Sep 2021 00:03:00 -0000 --000000000000a1042f05cb84b826 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeremy, Answering here from #22871 discussions. I agree on the general principle to not blur mempool policies signaling in committed transaction data. Beyond preserving upgradeability, another good argument is to let L2 nodes update the mempool policies signaling their pre-signed transactions non-interactively. If one of the transaction fields is assigned mempool semantics, in case of tightening policy changes, you will need to re-sign or bear the risks of having non-propagating transactions which opens the door for exploitation by a malicious counterparty. I think this point is kinda relevant if we have future cross-layer coordinated safety fixes to deal with a la CVE-2021-31876. Even further, a set of L2 counterparties would like to pick up divergent tx-relay/mempool policies, having the signaling fields as part of the signature force them to come to consensus. I think we can take the opportunity of p2p packages to introduce a new field to signal policy. Of course, a malicious tx-relay peer could modify its content to jam your transaction's propagation but in that case it is easier to just drop it. One issue with taking back the `nSequence` field for consensus-semantic sounds is depriving the application-layer from a discrete, zero-cost payload (e.g the LN obfuscated commitment number watermark). This might be controversial as we'll increase the price of such applications if they're still willingly to relay application specific data through the p2p network (e.g force them to use a costly OP_RETURN output or payer/payee interactions to setup a pay-to-contract) W.r.t flag day activation to smooth policy deployment, I think that's something we might rely on in the future though we could distinguish few types of policy deployments : 1) loosening changes (e.g full-rbf/dust threshold removal), a transaction which was relaying under the former policy should relay under the new one 2) tightening changes (e.g #22871), a transaction which was relaying under the former policy might not relay under the new one 3) new feature introduced (e.g packages), a transaction is offered a new mode of relay I think 1) doesn't need that level of ecosystem coordination as applications/second-layers should always benefit from such changes. Maybe with the exception of full-rbf, where we have historical 0-conf softwares, with (broken) security assumptions made on the opt-out RBF mechanism. Same with 3), better to have new features deployed gradually, a flag day activation day in this case won't mean that all higher stacks will jump to use package-relay ? Where a flag day might make sense would be for 2) ? It would create a higher level of commitment by the base layer software instead of a pure communication on the ML/GH, which might not be concretized in the announced release due to slow review process/feature freeze/rebase conflicts... Reversing the process and asking for Bitcoin applications/higher layers to update first might get us in the trap of never doing the change, as someone might have a small use-case in the corner relying on a given policy behavior. That said, w.r.t to the proposed policy change in #22871, I think it's better to deploy full-rbf first, then give a time buffer to higher applications to free up the `nSequence` field and finally start to discourage the usage. Otherwise, by introducing new discouragement waivers, e.g not rejecting the usage of the top 8 bits, I think we're moving away from the policy design principle we're trying to establish (separation of mempool policies signaling from consensus data) Le ven. 3 sept. 2021 =C3=A0 23:32, Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > Hi Bitcoin Devs, > > I recently noticed a flaw in the Sequence lock implementation with respec= t > to upgradability. It might be the case that this is protected against by > some transaction level policy (didn't see any in policy.cpp, but if not, > I've put up a blogpost explaining the defect and patching it > https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/ > > I've proposed patching it here > https://github.com/bitcoin/bitcoin/pull/22871, it is proper to widely > survey the community before patching to ensure no one is depending on the > current semantics in any live application lest this tightening of > standardness rules engender a confiscatory effect. > > Best, > > Jeremy > > -- > @JeremyRubin > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000a1042f05cb84b826 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeremy,

Answering here from #22871 discussions.<= br>
I agree on the general principle to not blur mempool policies signal= ing in committed transaction data. Beyond preserving upgradeability, anothe= r good argument is to let L2 nodes update the mempool policies signaling th= eir pre-signed transactions non-interactively. If one of the transaction fi= elds is assigned mempool semantics, in case of tightening policy changes, y= ou will need to re-sign or bear the risks of having non-propagating transac= tions which opens the door for exploitation by a malicious counterparty. I = think this point is kinda relevant if we have future cross-layer coordinate= d safety fixes to deal with a la CVE-2021-31876.

Even further, a set= of L2 counterparties would like to pick up divergent tx-relay/mempool poli= cies, having the signaling fields as part of the signature force them to co= me to consensus.

I think we can take the opportunity of p2p packages= to introduce a new field to signal policy. Of course, a malicious tx-relay= peer could modify its content to jam your transaction's propagation bu= t in that case it is easier to just drop it.

One issue with taking b= ack the `nSequence` field for consensus-semantic sounds is depriving the ap= plication-layer from a discrete, zero-cost payload (e.g the LN obfuscated c= ommitment number watermark). This might be controversial as we'll incre= ase the price of such applications if they're still willingly to relay = application specific data through the p2p network (e.g force them to use a = costly OP_RETURN output or payer/payee interactions to setup a pay-to-contr= act)

W.r.t flag day activation to smooth policy deployment, I think = that's something we might rely on in the future though we could disting= uish few types of policy deployments :
1) loosening changes (e.g full-rb= f/dust threshold removal), a transaction which was relaying under
the fo= rmer policy should relay under the new one
2) tightening changes (e.g #2= 2871), a transaction which was relaying under the former policy
might no= t relay under the new one
3) new feature introduced (e.g packages), a tr= ansaction is offered a new mode of relay

I think 1) doesn't need= that level of ecosystem coordination as applications/second-layers should = always benefit from such changes. Maybe with the exception of full-rbf, whe= re we have historical 0-conf softwares, with (broken) security assumptions = made on the opt-out RBF mechanism. Same with 3), better to have new feature= s deployed gradually, a flag day activation day in this case won't mean= that all higher stacks will jump to use package-relay ?

Where a fla= g day might make sense would be for 2) ? It would create a higher level of = commitment by the base layer software instead of a pure communication on th= e ML/GH, which might not be concretized in the announced release due to slo= w review process/feature freeze/rebase conflicts... Reversing the process a= nd asking for Bitcoin applications/higher layers to update first might get = us in the trap of never doing the change, as someone might have a small use= -case in the corner relying on a given policy behavior.

That said, w= .r.t to the proposed policy change in #22871, I think it's better to de= ploy full-rbf first, then give a time buffer to higher applications to free= up the `nSequence` field and finally start to discourage the usage. Otherw= ise, by introducing new discouragement waivers, e.g not rejecting the usage= of the top 8 bits, I think we're moving away from the policy design pr= inciple we're trying to establish (separation of mempool policies signa= ling from consensus data)

Le=C2=A0ven. 3 sept. 2021 =C3=A0=C2=A023:32, = Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit=C2=A0:<= br>
Hi Bitcoin Devs,

I recentl= y noticed a flaw in the Sequence lock implementation with respect to upgrad= ability. It might be the case that this is protected against by some transa= ction level policy (didn't see any in policy.cpp, but if not, I've = put up a blogpost=C2=A0explaining the defect and patching it=C2=A0https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/

I've proposed patching it here=C2=A0https://github.com/bitcoin/bi= tcoin/pull/22871, it is proper to widely survey the community before pa= tching to ensure no one is depending on the current semantics in any live a= pplication lest this tightening of standardness rules engender a confiscato= ry effect.

Best,

<= /div>
Jeremy

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000a1042f05cb84b826--