path: root/7b/225dcbecf8b64dc2fcc6b7bf8e5281daa3ca63

Return-Path: <jlrubin@mit.edu>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A6021C000E;
 Thu,  8 Jul 2021 01:00:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 95254400FA;
 Thu,  8 Jul 2021 01:00:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id sEvHq5wkYW42; Thu,  8 Jul 2021 01:00:34 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
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 smtp2.osuosl.org (Postfix) with ESMTPS id 31B70401C0;
 Thu,  8 Jul 2021 01:00:33 +0000 (UTC)
Received: from mail-io1-f45.google.com (mail-io1-f45.google.com
 [209.85.166.45]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16810Wmi002833
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT);
 Wed, 7 Jul 2021 21:00:32 -0400
Received: by mail-io1-f45.google.com with SMTP id k16so6071662ios.10;
 Wed, 07 Jul 2021 18:00:32 -0700 (PDT)
X-Gm-Message-State: AOAM53376k0T6hLJF0C64b4nb0aZ4YkCmM1KnVel38giJrnmDeTcfdYv
 5Lk8gLLEQLzmM7seFVFBnA5YtfSniXxG+kdT8zE=
X-Google-Smtp-Source: ABdhPJyUy7Ki1rA8IqjTQsRAolLMdvtHATMFwD3K02jP8hltXjw0L68LO37UTy7vdzjkhTfYidTmFjOK2wKpgZT6Xhg=
X-Received: by 2002:a6b:f91a:: with SMTP id j26mr13513295iog.97.1625706031825; 
 Wed, 07 Jul 2021 18:00:31 -0700 (PDT)
MIME-Version: 1.0
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 7 Jul 2021 18:00:20 -0700
X-Gmail-Original-Message-ID: <CAD5xwhgO5p2Ldy1P1rUuqDHcJ0opSe7Tg_mX_rb+ZpLOxa47cA@mail.gmail.com>
Message-ID: <CAD5xwhgO5p2Ldy1P1rUuqDHcJ0opSe7Tg_mX_rb+ZpLOxa47cA@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>, 
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000089496b05c6922ebe"
Subject: [bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences
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, 08 Jul 2021 01:00:35 -0000

--00000000000089496b05c6922ebe
Content-Type: text/plain; charset="UTF-8"

I made a comment on
https://github.com/bitcoin/bips/pull/943#issuecomment-876034559 but it
occurred to me it is more ML appropriate.

In general, one thing that strikes me is that when anyprevout is used for
eltoo you're generally doing a script like:

```
IF
    10 CSV DROP
    1::musigkey(As,Bs) CHECKSIG
ELSE
    <S+1> CLTV DROP
   1::musigkey(Au,Bu) CHECKSIG
ENDIF
```

This means that you're overloading the CLTV clause, which means it's
impossible to use Eltoo and use a absolute lock time, it also means you
have to use fewer than a billion sequences, and if you pick a random # to
mask how many payments you've done / pick random gaps let's say that
reduces your numbers in half. That may be enough, but is still relatively
limited. There is also the issue that multiple inputs cannot be combined
into a transaction if they have signed on different locktimes.

Since Eltoo is the primary motivation for ANYPREVOUT, it's worth making
sure we have all the parts we'd need bundled together to see it be
successful.

A few options come to mind that might be desirable in order to better serve
the eltoo usecase

1) Define a new CSV type (e.g. define (1<<31 && 1<<30) as being dedicated
to eltoo sequences). This has the benefit of giving a per input sequence,
but the drawback of using a CSV bit. Because there's only 1 CSV per input,
this technique cannot be used with a sequence tag.
2) CSFS -- it would be possible to take a signature from stack for an
arbitrary higher number, e.g.:
```
IF
    10 CSV DROP
    1::musigkey(As,Bs) CHECKSIG
ELSE
    DUP musigkey(Aseq, BSeq) CSFSV <S+1> GTE VERIFY
   1::musigkey(Au,Bu) CHECKSIG
ENDIF
```
Then, posession of a higher signed sequence would allow for the use of the
update path. However, the downside is that there would be no guarantee that
the new state provided for update would be higher than the past one without
a more advanced covenant.
3) Sequenced Signature: It could be set up such that ANYPREVOUT keys are
tagged with a N byte sequence (instead of 1), and a part of the process of
signature verification includes hashing a sequence on the signature itself.

E.g.

```
IF
    10 CSV DROP
    1::musigkey(As,Bs) CHECKSIG
ELSE
   <N>::musigkey(Au,Bu) CHECKSIG
ENDIF
```
To satisfy this clause, a signature `<N+1>::S` would be required. When
validating the signature S, the APO digest would have to include the value
<N+1>. It is non cryptographically checked that N+1 > N.
5) Similar to 3, but look at more values off the stack. This is also OK,
but violates the principle of not making opcodes take variable numbers of
things off the stack. Verify semantics on the extra data fields could
ameliorate this concern, and it might make sense to do it that way.
4) Something in the Annex: It would also be possible to define a new
generic place for lock times in the annex (to permit dual height/time
relative/absolute, all per input. The pro of this approach is that it would
be solving an outstanding problem for script that we want to solve anyways,
the downside is that the Annex is totally undefined presently so it's
unclear that this is an appropriate use for it.
5) Do Nothing :)


Overall I'm somewhat partial to option 3 as it seems to be closest to
making ANYPREVOUT more precisely designed to support Eltoo. It would also
be possible to make it such that if the tag N=1, then the behavior is
identical to the proposal currently.

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

--00000000000089496b05c6922ebe
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">I made a comment on=C2=A0=
<a href=3D"https://github.com/bitcoin/bips/pull/943#issuecomment-876034559"=
>https://github.com/bitcoin/bips/pull/943#issuecomment-876034559</a> but it=
 occurred=C2=A0to me it is more ML appropriate.</div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000">In general, one thing=
 that strikes me is that when anyprevout is used for eltoo you&#39;re gener=
ally doing a script like:<br><br>```<br>IF<br>=C2=A0 =C2=A0 10 CSV DROP<br>=
=C2=A0 =C2=A0 1::musigkey(As,Bs) CHECKSIG<br>ELSE<br>=C2=A0 =C2=A0 &lt;S+1&=
gt; CLTV DROP<br>=C2=A0 =C2=A01::musigkey(Au,Bu) CHECKSIG<br>ENDIF<br>```<b=
r><br>This means that you&#39;re overloading the CLTV clause, which means i=
t&#39;s impossible to use Eltoo and use a absolute lock time, it also means=
 you have to use fewer than a billion sequences, and if you pick a random #=
 to mask how many payments you&#39;ve done / pick random gaps let&#39;s say=
 that reduces your numbers in half. That may be enough, but is still relati=
vely limited. There is also the issue that multiple inputs cannot be combin=
ed into a transaction if they have signed on different locktimes.<br><br>Si=
nce Eltoo is the primary motivation for ANYPREVOUT, it&#39;s worth making s=
ure we have all the parts we&#39;d need bundled together to see it be succe=
ssful.<br><br>A few options come to mind that might be desirable in order t=
o better serve the eltoo usecase<br><br>1) Define a new CSV type (e.g. defi=
ne (1&lt;&lt;31 &amp;&amp; 1&lt;&lt;30) as being dedicated to eltoo sequenc=
es). This has the benefit of giving a per input sequence, but the drawback =
of using a CSV bit. Because there&#39;s only 1 CSV per input, this techniqu=
e cannot be used with a sequence tag.<br>2) CSFS -- it would be possible to=
 take a signature from stack for an arbitrary higher number, e.g.:<br>```<b=
r>IF<br>=C2=A0 =C2=A0 10 CSV DROP<br>=C2=A0 =C2=A0 1::musigkey(As,Bs) CHECK=
SIG<br>ELSE<br>=C2=A0 =C2=A0 DUP musigkey(Aseq, BSeq) CSFSV &lt;S+1&gt; GTE=
 VERIFY<br>=C2=A0 =C2=A01::musigkey(Au,Bu) CHECKSIG<br>ENDIF<br>```<br>Then=
, posession of a higher signed sequence would allow for the use of the upda=
te path. However, the downside is that there would be no guarantee that the=
 new state provided for update would be higher than the past one without a =
more advanced covenant.<br>3) Sequenced Signature: It could be set up such =
that ANYPREVOUT keys are tagged with a N byte sequence (instead of 1), and =
a part of the process of signature verification includes hashing a sequence=
 on the signature itself.<br><br>E.g.<br><br>```<br>IF<br>=C2=A0 =C2=A0 10 =
CSV DROP<br>=C2=A0 =C2=A0 1::musigkey(As,Bs) CHECKSIG<br>ELSE<br>=C2=A0 =C2=
=A0&lt;N&gt;::musigkey(Au,Bu) CHECKSIG<br>ENDIF<br>```<br>To satisfy this c=
lause, a signature `&lt;N+1&gt;::S` would be required. When validating the =
signature S, the APO digest would have to include the value &lt;N+1&gt;. It=
 is non cryptographically checked that N+1 &gt; N. <br>5) Similar to 3, but=
 look at more values off the stack. This is also OK, but violates the princ=
iple of not making opcodes take variable numbers of things off the stack. V=
erify semantics on the extra data fields could ameliorate this concern, and=
 it might make sense to do it that way.<br>4) Something in the Annex: It wo=
uld also be possible to define a new generic place for lock times in the an=
nex (to permit dual height/time relative/absolute, all per input. The pro o=
f this approach is that it would be solving an outstanding problem for scri=
pt that we want to solve anyways, the downside is that the Annex is totally=
 undefined presently so it&#39;s unclear that this is an appropriate use fo=
r it.<br>5) Do Nothing :)<br><br><br>Overall I&#39;m somewhat partial to op=
tion 3 as it seems to be closest to making ANYPREVOUT more precisely design=
ed to support Eltoo. It would also be possible to make it such that if the =
tag N=3D1, then the behavior is identical to the proposal currently.<br></d=
iv><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_signature" data-s=
martmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twit=
ter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://t=
witter.com/JeremyRubin" target=3D"_blank"></a></div></div></div></div>

--00000000000089496b05c6922ebe--