public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Alex Schoof <alex.schoof@gmail.com>
To: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	 Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY
Date: Wed, 11 May 2022 19:32:34 -0400	[thread overview]
Message-ID: <CA+2b5C0nJFThN_JV4usx2KQqTbAYwPq_u6RJn+1k5PuLwT1wPA@mail.gmail.com> (raw)
In-Reply-To: <87h75xoet1.fsf@rustcorp.com.au>

[-- Attachment #1: Type: text/plain, Size: 5157 bytes --]

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 “CTV++” 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 “only this combination of fields are valid, otherwise OP_SUCCESS”
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/019813.html
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019819.html
> [3]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019816.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-- 


Alex Schoof

[-- Attachment #2: Type: text/html, Size: 6593 bytes --]

  parent reply	other threads:[~2022-05-11 23:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10 10:35 [bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced to OP_CHECKTEMPLATEVERIFY Rusty Russell
2022-05-10 15:16 ` Brandon Black
2022-05-11 23:32 ` Alex Schoof [this message]
2022-06-24  6:06 ` Anthony Towns
2022-06-24 18:05   ` Jeremy Rubin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+2b5C0nJFThN_JV4usx2KQqTbAYwPq_u6RJn+1k5PuLwT1wPA@mail.gmail.com \
    --to=alex.schoof@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox