path: root/e7/fa8a8caa53d7dd528c1521f3e55f28ff7ad218

Return-Path: <jlrubin@mit.edu>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E6EA6C000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Sep 2021 01:05:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id D68A1605E6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Sep 2021 01:05:09 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id XOm26uPUF6en
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Sep 2021 01:05:08 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 214BA605BC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  9 Sep 2021 01:05:07 +0000 (UTC)
Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com
 [209.85.167.43]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 189155iL029796
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 8 Sep 2021 21:05:06 -0400
Received: by mail-lf1-f43.google.com with SMTP id x27so207630lfu.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 08 Sep 2021 18:05:06 -0700 (PDT)
X-Gm-Message-State: AOAM533WIfu9bZiRY77/h8/vFZsHWIod/g6jvKDl/t+OzV11+n4bAWtQ
 9GrTE7v0JPrggk8mnCrmI9hdFUwOMctbPTZk+0U=
X-Google-Smtp-Source: ABdhPJw0KM1H1W0BpXbwmDCWjVizQwHo8wqPgxrQ+LImMVeT08Ow3bmTPMZjyXXYkk6bcYBPXHPJnGMeSyh5UxTDLIQ=
X-Received: by 2002:a19:c7c3:: with SMTP id x186mr335857lff.175.1631149504670; 
 Wed, 08 Sep 2021 18:05:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhiKU1fuhqmKsx28f1nuw9CmvbyrS=BtM4X-L+WPgWY3Wg@mail.gmail.com>
 <CALZpt+Fk=_3=Hb_u4OptAwHKaG6R=+6igDeLQESQ_u_QbBQePg@mail.gmail.com>
In-Reply-To: <CALZpt+Fk=_3=Hb_u4OptAwHKaG6R=+6igDeLQESQ_u_QbBQePg@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 8 Sep 2021 18:04:53 -0700
X-Gmail-Original-Message-ID: <CAD5xwhj3N7aK-Of1+-DykH_XRbKBs32E4=uu81XmJhTx5yYZ7A@mail.gmail.com>
Message-ID: <CAD5xwhj3N7aK-Of1+-DykH_XRbKBs32E4=uu81XmJhTx5yYZ7A@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000cd305c05cb85967f"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 01:05:10 -0000

--000000000000cd305c05cb85967f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

See the current patchset proposed:
https://github.com/bitcoin/bitcoin/pull/22871/commits

Two things are happening that are separate:

1) Fixing the semantics of arg in <arg> OP_CHECKSEQUENCEVERIFY
2) Fixing the semantics on nSequence in each tx input

There is no sense in conditioning part 1 on RBF or anything else, since
it's only loosely related to 2. I think it should be a class-2 rollout as
you describe above since it's a rule tightening.

For part 2, I think the way the patches handle it currently (which is
defining 1 byte type prefix followed by 3 bytes application data) is
sufficient for immediate deployment.

I agree with you that a class-2 rollout might be appropriate for it, but
that can be followed by removing the SEQUENCE_ROOT_TYPE::SPECIAL field
later as a class-1 rollout. However, so long as it's not being used for any
particular constants, there is no need to deallocate
SEQUENCE_ROOT_TYPE::SPECIAL tag as long as no new use case must overlap
it's range.

With respect to the SEQUENCE_ROOT_TYPE::UNCHECKED_METADATA, it is in fact
*not* mempool data, but is a special type of metadata which is required for
the counterparty to efficiently respond to a unilateral channel closure (se=
e
bolt-3 This obscures the number of commitments made on the channel in the
case of unilateral close, yet still provides a useful index for both nodes
(who know the payment_basepoints) to quickly find a revoked commitment
transaction.)

I understand wanting to remove full-rbf, but I think that fixing the
upgradability of sequences is much less controversial among the
userbase and worth doing expediently. That part 1 is doable now -- albeit
as a class 2 -- means that it would not be unreasonable to bundle parts 1
and 2 so that we don't double burden the community with an upgrade effort.
Further, RBF can be disabled on a purely ad-hoc node-by-node policy layer,
whereas this restriction requires more community coordination/awareness.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Wed, Sep 8, 2021 at 5:03 PM Antoine Riard <antoine.riard@gmail.com>
wrote:

> Hi Jeremy,
>
> Answering here from #22871 discussions.
>
> I agree on the general principle to not blur mempool policies signaling i=
n
> committed transaction data. Beyond preserving upgradeability, another goo=
d
> argument is to let L2 nodes update the mempool policies signaling their
> pre-signed transactions non-interactively. If one of the transaction fiel=
ds
> 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 b=
e
> controversial as we'll increase the price of such applications if they're
> still willingly to relay application specific data through the p2p networ=
k
> (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 unde=
r
> 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. Sam=
e
> 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 t=
o
> 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 announc=
ed
> release due to slow review process/feature freeze/rebase conflicts...
> Reversing the process and asking for Bitcoin applications/higher layers t=
o
> update first might get us in the trap of never doing the change, as someo=
ne
> 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 waiver=
s,
> 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
>> respect 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 th=
e
>> 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
>>
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">See the current patchset =
proposed:=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/22871/com=
mits">https://github.com/bitcoin/bitcoin/pull/22871/commits</a></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Two t=
hings are happening=C2=A0that are separate:</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">1) Fixing the semantics=
=C2=A0of arg in &lt;arg&gt; OP_CHECKSEQUENCEVERIFY</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:#000000">2) Fixing the semantics on nSequence in each tx input</div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">T=
here is no sense in conditioning part 1 on RBF or anything else, since it&#=
39;s only loosely related to 2. I think it should be a class-2 rollout as y=
ou describe above since it&#39;s a rule tightening.</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000">For part 2, I thi=
nk the way the patches handle it currently (which is defining 1 byte type p=
refix followed by 3 bytes application data) is sufficient for immediate dep=
loyment.</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000">I agree with you that a class-2 rollout might be appropriate=
 for it, but that can be followed by removing the SEQUENCE_ROOT_TYPE::SPECI=
AL field later as a class-1 rollout. However, so long as it&#39;s not being=
 used for any particular constants, there is no need to deallocate SEQUENCE=
_ROOT_TYPE::SPECIAL tag as long as no new use case must overlap it&#39;s ra=
nge.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_de=
fault"><font color=3D"#000000" face=3D"arial, helvetica, sans-serif">With r=
espect to the SEQUENCE_ROOT_TYPE::UNCHECKED_METADATA, it is in fact *not* m=
empool </font>data<font color=3D"#000000" face=3D"arial, helvetica, sans-se=
rif">, but is a special type of metadata which is required for the counterp=
arty to efficiently respond to a unilateral channel closure=C2=A0</font>(se=
e bolt-3 This obscures the number of commitments made on the channel in the=
 case of unilateral close, yet still provides a useful index for both nodes=
 (who know the payment_basepoints) to quickly find a revoked commitment tra=
nsaction.)</div><div class=3D"gmail_default"><br></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">I understand wanting to remove full-rbf, but I think that fixi=
ng the upgradability of sequences is much less controversial among the user=
base=C2=A0and worth doing expediently. That part 1 is doable now -- albeit =
as a class 2 -- means that it would not be unreasonable to bundle parts 1 a=
nd 2 so that we don&#39;t double burden the community with an upgrade effor=
t. Further, RBF can be disabled on a purely ad-hoc node-by-node policy laye=
r, whereas this restriction requires more community coordination/awareness.=
</div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gma=
il_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyR=
ubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/Jere=
myRubin" target=3D"_blank"></a></div></div></div><br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Sep 8, 2021 =
at 5:03 PM Antoine Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com">ant=
oine.riard@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-sty=
le:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr">Hi Jeremy,<br><br>Answering here from #22871 discussions.<br><br>I agre=
e on the general principle to not blur mempool policies signaling in commit=
ted transaction data. Beyond preserving upgradeability, another good argume=
nt is to let L2 nodes update the mempool policies signaling their pre-signe=
d transactions non-interactively. If one of the transaction fields is assig=
ned mempool semantics, in case of tightening policy changes, you will need =
to re-sign or bear the risks of having non-propagating transactions which o=
pens the door for exploitation by a malicious counterparty. I think this po=
int is kinda relevant if we have future cross-layer coordinated safety fixe=
s to deal with a la CVE-2021-31876.<br><br>Even further, a set of L2 counte=
rparties would like to pick up divergent tx-relay/mempool policies, having =
the signaling fields as part of the signature force them to come to consens=
us.<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 m=
odify its content to jam your transaction&#39;s propagation but in that cas=
e it is easier to just drop it.<br><br>One issue with taking back the `nSeq=
uence` field for consensus-semantic sounds is depriving the application-lay=
er from a discrete, zero-cost payload (e.g the LN obfuscated commitment num=
ber watermark). This might be controversial as we&#39;ll increase the price=
 of such applications if they&#39;re still willingly to relay application s=
pecific data through the p2p network (e.g force them to use a costly OP_RET=
URN output or payer/payee interactions to setup a pay-to-contract)<br><br>W=
.r.t flag day activation to smooth policy deployment, I think that&#39;s so=
mething we might rely on in the future though we could distinguish few type=
s of policy deployments :<br>1) loosening changes (e.g full-rbf/dust thresh=
old removal), a transaction which was relaying under<br>the former policy s=
hould relay under the new one<br>2) tightening changes (e.g #22871), a tran=
saction which was relaying under the former policy<br>might not relay under=
 the new one<br>3) new feature introduced (e.g packages), a transaction is =
offered a new mode of relay<br><br>I think 1) doesn&#39;t need that level o=
f ecosystem coordination as applications/second-layers should always benefi=
t from such changes. Maybe with the exception of full-rbf, where we have hi=
storical 0-conf softwares, with (broken) security assumptions made on the o=
pt-out RBF mechanism. Same with 3), better to have new features deployed gr=
adually, a flag day activation day in this case won&#39;t mean that all hig=
her stacks will jump to use package-relay ?<br><br>Where a flag day might m=
ake 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, whic=
h might not be concretized in the announced release due to slow review proc=
ess/feature freeze/rebase conflicts... Reversing the process and asking for=
 Bitcoin applications/higher layers to update first might get us in the tra=
p 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 p=
roposed policy change in #22871, I think it&#39;s better to deploy full-rbf=
 first, then give a time buffer to higher applications to free up the `nSeq=
uence` field and finally start to discourage the usage. Otherwise, by intro=
ducing 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 principle we&#3=
9;re trying to establish (separation of mempool policies signaling from con=
sensus 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 bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">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.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)">Hi Bitcoin Devs,</div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)">I recently noticed a flaw in the Sequ=
ence lock implementation with respect to upgradability. It might be the cas=
e that this is protected against by some transaction level policy (didn&#39=
;t see any in policy.cpp, but if not, I&#39;ve put up a blogpost=C2=A0expla=
ining the defect and patching it=C2=A0<a href=3D"https://rubin.io/bitcoin/2=
021/09/03/upgradable-nops-flaw/" target=3D"_blank">https://rubin.io/bitcoin=
/2021/09/03/upgradable-nops-flaw/</a></div><div class=3D"gmail_default" sty=
le=3D"font-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,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)">I&#39;ve proposed patchin=
g it here=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/22871" ta=
rget=3D"_blank">https://github.com/bitcoin/bitcoin/pull/22871</a>, it is pr=
oper to widely survey the community before patching to ensure no one is dep=
ending on the current semantics in any live application lest this tightenin=
g of standardness rules engender a confiscatory effect.</div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;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)">Best,</=
div><div 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_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(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/JeremyRubin" target=3D"_blank">@J=
eremyRubin</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>
</blockquote></div>

--000000000000cd305c05cb85967f--