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"
Subject: Re: [bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced
	to OP_CHECKTEMPLATEVERIFY
Precedence: list

--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--