From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3403BC002D for ; Wed, 11 May 2022 23:32:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 1ABFA4058C for ; Wed, 11 May 2022 23:32:47 +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: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NIdYyMEBF4zG for ; Wed, 11 May 2022 23:32:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) by smtp2.osuosl.org (Postfix) with ESMTPS id C9339400B8 for ; Wed, 11 May 2022 23:32:45 +0000 (UTC) Received: by mail-il1-x136.google.com with SMTP id d3so2463141ilr.10 for ; Wed, 11 May 2022 16:32:45 -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=FklFiYgOZZYr7PKqNbnVzrs6zX3auh+Lf0x+AICIRKg=; b=O3dcu+64zgnaX478kdfQpR+lhw2mdT9xRQuJyqszXc3V+H7+6EnDygWOpQapPYof32 nj9jcS+TcmmvotrBYWkmdLklRlML+/cuMhGfXUUGLGno50uVYy6cltubVRwsvDA/FZGz V9WDepu3REQ9mfmiVJHvGY/Pk3rl1f/7/y2KMbZKKsDs7el2cf/JjC2V9L8uNodiNWe6 YbSFa7wG81pqFG33Z5kAL/i0A2ypySnwgKqvVyRVH1AgQbu92SPm2AnEFDzS0ZYhrNfo alX7xvlCcnnf2PeXbLi/IpFJ1zwHr7WB7qe6k3JtVi4Nc7NVhrBaplkoGvroh18Mt74d E3aw== 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=FklFiYgOZZYr7PKqNbnVzrs6zX3auh+Lf0x+AICIRKg=; b=hDcu3BzkaUWDMvtyQZnaIUjfK27sc/cX+l+Q8Dcm0DoYVjVa31UXlINxxiTEOJq3Kh 4aA45hLl+yHqcpl4nUVI0uyBMsFvkGecMuT/7MRHF4duuipPHwlzjskhv4V44NtYjC8w WQzcy9lV/OFv9xDjbWQIj7lH2gOtxEmVMq14WJ6328K3qMr/OuvmtXDLxVukMCMnxmp6 ujD+R+IvkQ67wa3Fr4Z3r37PSk5dRidncCqWbfPhZSlH+IKGe5nOE0qbRHXVq7eUx0d3 R3SnkglbkiPLgR64qmL5xpQkH3GUuWJSr/ctQYbpqhZ5CQQNULgV998zStBQYXm6uw61 h5tA== X-Gm-Message-State: AOAM533txSC6eSoVheF1iyo1+Y4i4fD/+TH8xe6m1cw1Gfh3Uu33wbsz U4ZCy24AXYZF+2rl+TBordFgq0cUvnKJNekLrzrnvvYL X-Google-Smtp-Source: ABdhPJwTJtAXLQha/N7LDEeKSIhSqDNUW18EygTZTL1GL2snL8Af7hdEpTaf/dOKraUvzs/pbQ0h2eibcofHpicow7s= X-Received: by 2002:a05:6e02:f52:b0:2ca:95e4:f4b5 with SMTP id y18-20020a056e020f5200b002ca95e4f4b5mr12472790ilj.240.1652311964717; Wed, 11 May 2022 16:32:44 -0700 (PDT) MIME-Version: 1.0 References: <87h75xoet1.fsf@rustcorp.com.au> In-Reply-To: <87h75xoet1.fsf@rustcorp.com.au> From: Alex Schoof Date: Wed, 11 May 2022 19:32:34 -0400 Message-ID: To: Bitcoin Protocol Discussion , Rusty Russell Content-Type: multipart/alternative; boundary="000000000000b717d405dec4db12" X-Mailman-Approved-At: Thu, 12 May 2022 07:57:52 +0000 Subject: Re: [bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY 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: Wed, 11 May 2022 23:32:47 -0000 --000000000000b717d405dec4db12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rusty, One of the common sentiments thats been expressed over the last few months is that more people want to see experimentation with different applications using covenants. I really like this proposal because in addition to offering a cleaner upgrade/extension path than adding =E2=80=9CCTV++=E2=80= =9D as a new opcode in a few years, it also seems like it would make it very easy to create prototype applications to game out new ideas: If the =E2=80=9Conly this combination of fields are valid, otherwise OP_SUC= CESS=E2=80=9D check is just comparing with a list of bitmasks for permissible field combinations (which right now is a list of length 1), it seems like it would be *very* easy for people who want to play with other covenant field sets to just add the relevant bitmasks and then go spin up a signet to build applications. Being able to make a very targeted change like that to enable experimentation is super cool. Thanks for sharing! Alex On Tue, May 10, 2022 at 6:37 AM Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi all, > > TL;DR: a v1 tapscript opcode for generic covenants, but > OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY. This gives an > obvious use case, with clean future expansion. OP_NOP4 can be > repurposed in future as a shortcut, if experience shows that to be a > useful optimization. > > (This proposal builds on Russell O'Connor's TXHASH[1], with Anthony > Towns' modification via extending the opcode[2]; I also notice on > re-reading that James Lu had a similar restriction idea[3]). > > Details > ------- > > OP_TX, when inside v1 tapscript, is followed by 4 bytes of flags. > Unknown flag patterns are OP_SUCCESS, though for thoroughness some future > potential uses are documented here. Note that pushing more than 1000 > elements on the stack or an element more than 512 bytes will hit the > BIP-342 resource limits and fail. > > Defined bits > ------------ > > (Only those marked with * have to be defined for this soft fork; the > others can have semantics later). > > OPTX_SEPARATELY: treat fields separately (vs concatenating) > OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push) > > - The first nicely sidesteps the lack of OP_CAT, and the latter allows > OP_TXHASH semantics (and avoid stack element limits). > > OPTX_SELECT_VERSION*: version > OPTX_SELECT_LOCKTIME*: nLocktime > OPTX_SELECT_INPUTNUM*: current input number > OPTX_SELECT_INPUTCOUNT*: number of inputs > OPTX_SELECT_OUTPUTCOUNT*: number of outputs > > OPTX_INPUT_SINGLE: if set, pop input number off stack to apply to > OPTX_SELECT_INPUT_*, otherwise iterate through all. > OPTX_SELECT_INPUT_TXID: txid > OPTX_SELECT_INPUT_OUTNUM: txout index > OPTX_SELECT_INPUT_NSEQUENCE*: sequence number > OPTX_SELECT_INPUT_AMOUNT32x2: sats in, as a high-low u31 pair > OPTX_SELECT_INPUT_SCRIPT*: input scriptsig > OPTX_SELECT_INPUT_TAPBRANCH: ? > OPTX_SELECT_INPUT_TAPLEAF: ? > > OPTX_OUTPUT_SINGLE: if set, pop input number off stack to apply to > OPTX_SELECT_OUTPUT_*, otherwise iterate through all. > OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair > OPTX_SELECT_OUTPUT_SCRIPTPUBKEY*: output scriptpubkey > > OPTX_SELECT_19...OPTX_SELECT_31: future expansion. > > OP_CHECKTEMPLATEVERIFY is approximated by the following flags: > OPTX_SELECT_VERSION > OPTX_SELECT_LOCKTIME > OPTX_SELECT_INPUTCOUNT > OPTX_SELECT_INPUT_SCRIPT > OPTX_SELECT_INPUT_NSEQUENCE > OPTX_SELECT_OUTPUTCOUNT > OPTX_SELECT_OUTPUT_AMOUNT32x2 > OPTX_SELECT_OUTPUT_SCRIPTPUBKEY > OPTX_SELECT_INPUTNUM > > All other flag combinations result in OP_SUCCESS. > > Discussion > ---------- > > By enumerating exactly what can be committed to, it's absolutely clear > what is and isn't committed (and what you need to think about!). > > The bits which separate concatenation and hashing provide a simple > mechanism for template-style (i.e. CTV-style) commitments, or for > programatic treatment of individual elements (e.g. amounts, though the > two s31 style is awkward: a 64-bit push flag could be added in future). > > The lack of double-hashing of scriptsigs and other fields means we > cannot simply re-use hashing done for SIGHASH_ALL. > > The OP_SUCCESS semantic is only valid in tapscript v1, so this does not > allow covenants for v0 segwit or pre-segwit inputs. If covenants prove > useful, dedicated opcodes can be provided for those cases (a-la > OP_CHECKTEMPLATEVERIFY). > > Cheers, > Rusty. > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/0198= 13.html > [2] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/0198= 19.html > [3] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/0198= 16.html > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --=20 Alex Schoof --000000000000b717d405dec4db12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rusty,

One of the common sentiments thats been expressed over the last few mon= ths is that more people want to see experimentation with different applicat= ions using covenants. I really like this proposal because in addition to of= fering a cleaner upgrade/extension path than adding =E2=80=9CCTV++=E2=80=9D= as a new opcode in a few years, it also seems like it would make it very e= asy to create prototype applications to game out new ideas:=C2=A0
If the =E2=80=9Conly this combination of fields are valid, ot= herwise OP_SUCCESS=E2=80=9D check is just comparing with a list of bitmasks= for permissible field combinations (which right now is a list of length 1)= , it seems like it would be *very* easy for people who want to play with ot= her covenant field sets to just add the relevant bitmasks and then go spin = up a signet to build applications.=C2=A0

<= div dir=3D"auto">Being able to make a very targeted change like that to ena= ble experimentation is super cool. Thanks for sharing!

Alex

On Tue, May 10, 2022 at 6:37 AM Rusty Russell via bitcoin-dev &= lt;bitcoin-dev@lis= ts.linuxfoundation.org> wrote:
Hi all,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 TL;DR: a v1 tapscript opcode for generic covena= nts, but
OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY.=C2=A0 This giv= es an
obvious use case, with clean future expansion.=C2=A0 OP_NOP4 can be
repurposed in future as a shortcut, if experience shows that to be a
useful optimization.

(This proposal builds on Russell O'Connor's TXHASH[1], with Anthony=
Towns' modification via extending the opcode[2]; I also notice on
re-reading that James Lu had a similar restriction idea[3]).

Details
-------

OP_TX, when inside v1 tapscript, is followed by 4 bytes of flags.
Unknown flag patterns are OP_SUCCESS, though for thoroughness some future potential uses are documented here.=C2=A0 Note that pushing more than 1000<= br> elements on the stack or an element more than 512 bytes will hit the
BIP-342 resource limits and fail.

Defined bits
------------

(Only those marked with * have to be defined for this soft fork; the
=C2=A0others can have semantics later).

OPTX_SEPARATELY: treat fields separately (vs concatenating)
OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push)
- The first nicely sidesteps the lack of OP_CAT, and the latter allows
=C2=A0 OP_TXHASH semantics (and avoid stack element limits).

OPTX_SELECT_VERSION*: version
OPTX_SELECT_LOCKTIME*: nLocktime
OPTX_SELECT_INPUTNUM*: current input number
OPTX_SELECT_INPUTCOUNT*: number of inputs
OPTX_SELECT_OUTPUTCOUNT*: number of outputs

OPTX_INPUT_SINGLE: if set, pop input number off stack to apply to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_INPUT_*= , otherwise iterate through all.
OPTX_SELECT_INPUT_TXID: txid
OPTX_SELECT_INPUT_OUTNUM: txout index
OPTX_SELECT_INPUT_NSEQUENCE*: sequence number
OPTX_SELECT_INPUT_AMOUNT32x2: sats in, as a high-low u31 pair
OPTX_SELECT_INPUT_SCRIPT*: input scriptsig
OPTX_SELECT_INPUT_TAPBRANCH: ?
OPTX_SELECT_INPUT_TAPLEAF: ?

OPTX_OUTPUT_SINGLE: if set, pop input number off stack to apply to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_OUTPUT_= *, otherwise iterate through all.
OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair
OPTX_SELECT_OUTPUT_SCRIPTPUBKEY*: output scriptpubkey

OPTX_SELECT_19...OPTX_SELECT_31: future expansion.

OP_CHECKTEMPLATEVERIFY is approximated by the following flags:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_VERSION
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_LOCKTIME
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_INPUTCOUNT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_INPUT_SCRIPT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_INPUT_NSEQUENCE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_OUTPUTCOUNT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_OUTPUT_AMOUNT32x2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_OUTPUT_SCRIPTPUBKEY
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_INPUTNUM

All other flag combinations result in OP_SUCCESS.

Discussion
----------

By enumerating exactly what can be committed to, it's absolutely clear<= br> what is and isn't committed (and what you need to think about!).

The bits which separate concatenation and hashing provide a simple
mechanism for template-style (i.e. CTV-style) commitments, or for
programatic treatment of individual elements (e.g. amounts, though the
two s31 style is awkward: a 64-bit push flag could be added in future).

The lack of double-hashing of scriptsigs and other fields means we
cannot simply re-use hashing done for SIGHASH_ALL.

The OP_SUCCESS semantic is only valid in tapscript v1, so this does not
allow covenants for v0 segwit or pre-segwit inputs.=C2=A0 If covenants prov= e
useful, dedicated opcodes can be provided for those cases (a-la
OP_CHECKTEMPLATEVERIFY).

Cheers,
Rusty.

[1] https://lists.li= nuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
[2] https://lists.li= nuxfoundation.org/pipermail/bitcoin-dev/2022-January/019819.html
[3] https://lists.li= nuxfoundation.org/pipermail/bitcoin-dev/2022-January/019816.html
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--


Alex Schoof
--000000000000b717d405dec4db12--