path: root/02/eb832a3793b6225c4d9c322b51e04a419db496

Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C1ACEC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Sep 2021 00:02:59 +0000 (UTC)
Received: by mail-wr1-x42b.google.com with SMTP id b6so5709371wrh.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAD5xwhiKU1fuhqmKsx28f1nuw9CmvbyrS=BtM4X-L+WPgWY3Wg@mail.gmail.com>
In-Reply-To: <CAD5xwhiKU1fuhqmKsx28f1nuw9CmvbyrS=BtM4X-L+WPgWY3Wg@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 8 Sep 2021 20:02:45 -0400
Message-ID: <CALZpt+Fk=_3=Hb_u4OptAwHKaG6R=+6igDeLQESQ_u_QbBQePg@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <https://twitter.com/JeremyRubin>
> <https://twitter.com/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

<div dir=3D"ltr">Hi Jeremy,<br><br>Answering here from #22871 discussions.<=
br><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.<br><br>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.<br><br>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&#39;s propagation bu=
t in that case it is easier to just drop it.<br><br>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&#39;ll incre=
ase the price of such applications if they&#39;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)<br><br>W.r.t flag day activation to smooth policy deployment, I think =
that&#39;s something we might rely on in the future though we could disting=
uish few types of policy deployments :<br>1) loosening changes (e.g full-rb=
f/dust threshold removal), a transaction which was relaying under<br>the fo=
rmer policy should relay under the new one<br>2) tightening changes (e.g #2=
2871), a transaction which was relaying under the former policy<br>might no=
t relay under the new one<br>3) new feature introduced (e.g packages), a tr=
ansaction is offered a new mode of relay<br><br>I think 1) doesn&#39;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&#39;t mean=
 that all higher stacks will jump to use package-relay ?<br><br>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.<br><br>That said, w=
.r.t to the proposed policy change in #22871, I think it&#39;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&#39;re moving away from the policy design pr=
inciple we&#39;re trying to establish (separation of mempool policies signa=
ling from consensus data)<br></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 3 sept. 2021 =C3=A0=C2=A023:32, =
Jeremy via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)">Hi Bitcoin Devs,</div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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&#39;t see any in policy.cpp, but if not, I&#39;ve =
put up a blogpost=C2=A0explaining the defect and patching it=C2=A0<a href=
=3D"https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/" target=3D"_b=
lank">https://rubin.io/bitcoin/2021/09/03/upgradable-nops-flaw/</a></div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)">I&#39;ve proposed patching it here=C2=A0<a href=3D"https://github.com/=
bitcoin/bitcoin/pull/22871" target=3D"_blank">https://github.com/bitcoin/bi=
tcoin/pull/22871</a>, 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.</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)">Best,</div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)">Jeremy</div><br clear=3D"all"><div=
><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/Jer=
emyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/=
JeremyRubin" target=3D"_blank"></a></div></div></div></div>
_______________________________________________<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>

--000000000000a1042f05cb84b826--