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
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
