Return-Path: 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 Date: Wed, 7 Jul 2021 18:00:20 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin development mailing list , lightning-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 ::musigkey(Au,Bu) CHECKSIG ENDIF ``` To satisfy this clause, a signature `::S` would be required. When validating the signature S, the APO digest would have to include the value . 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 --00000000000089496b05c6922ebe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I made a comment on=C2=A0= https://github.com/bitcoin/bips/pull/943#issuecomment-876034559 but it= occurred=C2=A0to me it is more ML appropriate.

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

```
IF
=C2=A0 =C2=A0 10 CSV DROP
= =C2=A0 =C2=A0 1::musigkey(As,Bs) CHECKSIG
ELSE
=C2=A0 =C2=A0 <S+1&= gt; CLTV DROP
=C2=A0 =C2=A01::musigkey(Au,Bu) CHECKSIG
ENDIF
```
This means that you're overloading the CLTV clause, which means i= t'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 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.

Si= nce Eltoo is the primary motivation for ANYPREVOUT, it's worth making s= ure we have all the parts we'd need bundled together to see it be succe= ssful.

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

1) Define a new CSV type (e.g. defi= ne (1<<31 && 1<<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's only 1 CSV per input, this techniqu= e 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
=C2=A0 =C2=A0 10 CSV DROP
=C2=A0 =C2=A0 1::musigkey(As,Bs) CHECK= SIG
ELSE
=C2=A0 =C2=A0 DUP musigkey(Aseq, BSeq) CSFSV <S+1> GTE= VERIFY
=C2=A0 =C2=A01::musigkey(Au,Bu) CHECKSIG
ENDIF
```
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.
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
=C2=A0 =C2=A0 10 = CSV DROP
=C2=A0 =C2=A0 1::musigkey(As,Bs) CHECKSIG
ELSE
=C2=A0 =C2= =A0<N>::musigkey(Au,Bu) CHECKSIG
ENDIF
```
To satisfy this c= lause, 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 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.
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's unclear that this is an appropriate use fo= r it.
5) Do Nothing :)


Overall I'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.

--00000000000089496b05c6922ebe--