path: root/a1/5b896b8352a304b1ac5db434e000a5f42130db

Return-Path: <alex.schoof@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3403BC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 23:32:45 +0000 (UTC)
Received: by mail-il1-x136.google.com with SMTP id d3so2463141ilr.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <alex.schoof@gmail.com>
Date: Wed, 11 May 2022 19:32:34 -0400
Message-ID: <CA+2b5C0nJFThN_JV4usx2KQqTbAYwPq_u6RJn+1k5PuLwT1wPA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 Rusty Russell <rusty@rustcorp.com.au>
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 <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: 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

<div dir=3D"auto">Hi Rusty,</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">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</div><div=
 dir=3D"auto">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><div dir=3D"auto"><br></div><=
div dir=3D"auto">Being able to make a very targeted change like that to ena=
ble experimentation is super cool. Thanks for sharing!</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">Alex</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">On Tue, May 10, 2022 at 6:37 AM Rusty Russell via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt; wrote:<br></div><div><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-col=
or:rgb(204,204,204)">Hi all,<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TL;DR: a v1 tapscript opcode for generic covena=
nts, but<br>
OP_SUCCESS unless it&#39;s used a-la OP_CHECKTEMPLATEVERIFY.=C2=A0 This giv=
es an<br>
obvious use case, with clean future expansion.=C2=A0 OP_NOP4 can be<br>
repurposed in future as a shortcut, if experience shows that to be a<br>
useful optimization.<br>
<br>
(This proposal builds on Russell O&#39;Connor&#39;s TXHASH[1], with Anthony=
<br>
Towns&#39; modification via extending the opcode[2]; I also notice on<br>
re-reading that James Lu had a similar restriction idea[3]).<br>
<br>
Details<br>
-------<br>
<br>
OP_TX, when inside v1 tapscript, is followed by 4 bytes of flags.<br>
Unknown flag patterns are OP_SUCCESS, though for thoroughness some future<b=
r>
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<br>
BIP-342 resource limits and fail.<br>
<br>
Defined bits<br>
------------<br>
<br>
(Only those marked with * have to be defined for this soft fork; the<br>
=C2=A0others can have semantics later).<br>
<br>
OPTX_SEPARATELY: treat fields separately (vs concatenating)<br>
OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push)<br=
>
<br>
- The first nicely sidesteps the lack of OP_CAT, and the latter allows<br>
=C2=A0 OP_TXHASH semantics (and avoid stack element limits).<br>
<br>
OPTX_SELECT_VERSION*: version<br>
OPTX_SELECT_LOCKTIME*: nLocktime<br>
OPTX_SELECT_INPUTNUM*: current input number<br>
OPTX_SELECT_INPUTCOUNT*: number of inputs<br>
OPTX_SELECT_OUTPUTCOUNT*: number of outputs<br>
<br>
OPTX_INPUT_SINGLE: if set, pop input number off stack to apply to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_INPUT_*=
, otherwise iterate through all.<br>
OPTX_SELECT_INPUT_TXID: txid<br>
OPTX_SELECT_INPUT_OUTNUM: txout index<br>
OPTX_SELECT_INPUT_NSEQUENCE*: sequence number<br>
OPTX_SELECT_INPUT_AMOUNT32x2: sats in, as a high-low u31 pair<br>
OPTX_SELECT_INPUT_SCRIPT*: input scriptsig<br>
OPTX_SELECT_INPUT_TAPBRANCH: ?<br>
OPTX_SELECT_INPUT_TAPLEAF: ?<br>
<br>
OPTX_OUTPUT_SINGLE: if set, pop input number off stack to apply to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_OUTPUT_=
*, otherwise iterate through all.<br>
OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair<br>
OPTX_SELECT_OUTPUT_SCRIPTPUBKEY*: output scriptpubkey<br>
<br>
OPTX_SELECT_19...OPTX_SELECT_31: future expansion.<br>
<br>
OP_CHECKTEMPLATEVERIFY is approximated by the following flags:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_VERSION<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_LOCKTIME<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_INPUTCOUNT<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_INPUT_SCRIPT<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_INPUT_NSEQUENCE<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_OUTPUTCOUNT<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_OUTPUT_AMOUNT32x2<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_OUTPUT_SCRIPTPUBKEY<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPTX_SELECT_INPUTNUM<br>
<br>
All other flag combinations result in OP_SUCCESS.<br>
<br>
Discussion<br>
----------<br>
<br>
By enumerating exactly what can be committed to, it&#39;s absolutely clear<=
br>
what is and isn&#39;t committed (and what you need to think about!).<br>
<br>
The bits which separate concatenation and hashing provide a simple<br>
mechanism for template-style (i.e. CTV-style) commitments, or for<br>
programatic treatment of individual elements (e.g. amounts, though the<br>
two s31 style is awkward: a 64-bit push flag could be added in future).<br>
<br>
The lack of double-hashing of scriptsigs and other fields means we<br>
cannot simply re-use hashing done for SIGHASH_ALL.<br>
<br>
The OP_SUCCESS semantic is only valid in tapscript v1, so this does not<br>
allow covenants for v0 segwit or pre-segwit inputs.=C2=A0 If covenants prov=
e<br>
useful, dedicated opcodes can be provided for those cases (a-la<br>
OP_CHECKTEMPLATEVERIFY).<br>
<br>
Cheers,<br>
Rusty.<br>
<br>
[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-January/019813.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html</a><br>
[2] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-January/019819.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-January/019819.html</a><br>
[3] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022=
-January/019816.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2022-January/019816.html</a><br>
_______________________________________________<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></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature"><br><br>Alex Schoof</div>

--000000000000b717d405dec4db12--