📅 Original date posted:2022-05-10
📝 Original message:Hi Rusty,
Thanks for this. Seems like a productive direction to explore.
To me, one of the biggest limitations of CTV is that the script is
specific to the amount of the input being spent. OP_TX makes it
possible, although clumsy, to emulate OP_IN_OUT_AMOUNT, which could be
combined with CTV emulation less OPTX_SELECT_OUTPUT_AMOUNT32x2 to allow
a single script to be reused. Given that potential, I wonder if
OPTX_SELECT_IN_OUT_AMOUNT32x2 would be worth adding to the initial set
of flags.
With that addition, a small script can be constructed for a relocatable,
batchable construction (eg. as a building block for vaults):
OPTX_SEPARATELY|OPTX_UNHASHED|OPTX_INPUTNUM OP_TX OP_DUP
OPTX_SELECT_VERSION|
OPTX_SELECT_LOCKTIME|
OPTX_SELECT_INPUT_SINGLE|
OPTX_SELECT_INPUT_SCRIPT|
OPTX_SELECT_INPUT_NSEQUENCE|
OPTX_SELECT_OUTPUT_SINGLE|
OPTX_SELECT_OUTPUT_SCRIPTPUBKEY|
OPTX_SELECT_IN_OUT_AMOUNT32x2 OP_TX <expectedhash> OP_EQUAL
* Additional inputs and change outputs can be added
* Could commit to 0 fee and still be useful
* Arbitrary amounts can be sent to the same script
* There is no txid predictability (unlike CTV)
* Anyone could rearrange such input/output pairs after broadcast
* Not suitable for some uses
* Potentially helpful for others
Best,
--Brandon
On 2022-05-10 (Tue) at 20:05:54 +0930, Rusty Russell via bitcoin-dev 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
--Brandon
Brandon Black [ARCHIVE] /
npub1tx…grmss
2023-06-07 23:09:30
in reply to nevent1q…fkyk
Author Public Key
npub1txgfckk6qxy5yh6c7sag0m4sjycag8fn9xx7jj5efpf05s7ztt7s5grmssPublished at
2023-06-07 23:09:30Event JSON
{
"id": "9b4f7d3074f154f48e79692f80d10e410851879ef7c1156f0563a266a4d48b42",
"pubkey": "59909c5ada0189425f58f43a87eeb09131d41d33298de94a994852fa43c25afd",
"created_at": 1686179370,
"kind": 1,
"tags": [
[
"e",
"e0e6f622353d1c9392041bfc5f849e80f7646fd3d4cf097d7f0ccc707556ab8c",
"",
"root"
],
[
"e",
"3af29e6a60f088520d6630721685f5c67752e1153ed2fb1af67368226d6f7760",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2022-05-10\n📝 Original message:Hi Rusty,\n\nThanks for this. Seems like a productive direction to explore.\n\nTo me, one of the biggest limitations of CTV is that the script is\nspecific to the amount of the input being spent. OP_TX makes it\npossible, although clumsy, to emulate OP_IN_OUT_AMOUNT, which could be\ncombined with CTV emulation less OPTX_SELECT_OUTPUT_AMOUNT32x2 to allow\na single script to be reused. Given that potential, I wonder if\nOPTX_SELECT_IN_OUT_AMOUNT32x2 would be worth adding to the initial set\nof flags.\n\nWith that addition, a small script can be constructed for a relocatable,\nbatchable construction (eg. as a building block for vaults):\n\nOPTX_SEPARATELY|OPTX_UNHASHED|OPTX_INPUTNUM OP_TX OP_DUP\n\nOPTX_SELECT_VERSION|\nOPTX_SELECT_LOCKTIME|\nOPTX_SELECT_INPUT_SINGLE|\nOPTX_SELECT_INPUT_SCRIPT|\nOPTX_SELECT_INPUT_NSEQUENCE|\nOPTX_SELECT_OUTPUT_SINGLE|\nOPTX_SELECT_OUTPUT_SCRIPTPUBKEY|\nOPTX_SELECT_IN_OUT_AMOUNT32x2 OP_TX \u003cexpectedhash\u003e OP_EQUAL\n\n* Additional inputs and change outputs can be added\n * Could commit to 0 fee and still be useful\n* Arbitrary amounts can be sent to the same script\n* There is no txid predictability (unlike CTV)\n * Anyone could rearrange such input/output pairs after broadcast\n\t* Not suitable for some uses\n\t* Potentially helpful for others\n\nBest,\n\n--Brandon\n\nOn 2022-05-10 (Tue) at 20:05:54 +0930, Rusty Russell via bitcoin-dev wrote:\n\u003e Hi all,\n\u003e \n\u003e \tTL;DR: a v1 tapscript opcode for generic covenants, but\n\u003e OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY. This gives an\n\u003e obvious use case, with clean future expansion. OP_NOP4 can be\n\u003e repurposed in future as a shortcut, if experience shows that to be a\n\u003e useful optimization.\n\u003e \n\u003e (This proposal builds on Russell O'Connor's TXHASH[1], with Anthony\n\u003e Towns' modification via extending the opcode[2]; I also notice on\n\u003e re-reading that James Lu had a similar restriction idea[3]).\n\u003e \n\u003e Details\n\u003e -------\n\u003e \n\u003e OP_TX, when inside v1 tapscript, is followed by 4 bytes of flags.\n\u003e Unknown flag patterns are OP_SUCCESS, though for thoroughness some future\n\u003e potential uses are documented here. Note that pushing more than 1000\n\u003e elements on the stack or an element more than 512 bytes will hit the\n\u003e BIP-342 resource limits and fail.\n\u003e \n\u003e Defined bits\n\u003e ------------\n\u003e \n\u003e (Only those marked with * have to be defined for this soft fork; the\n\u003e others can have semantics later).\n\u003e \n\u003e OPTX_SEPARATELY: treat fields separately (vs concatenating)\n\u003e OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push)\n\u003e \n\u003e - The first nicely sidesteps the lack of OP_CAT, and the latter allows\n\u003e OP_TXHASH semantics (and avoid stack element limits).\n\u003e \n\u003e OPTX_SELECT_VERSION*: version\n\u003e OPTX_SELECT_LOCKTIME*: nLocktime\n\u003e OPTX_SELECT_INPUTNUM*: current input number\n\u003e OPTX_SELECT_INPUTCOUNT*: number of inputs\n\u003e OPTX_SELECT_OUTPUTCOUNT*: number of outputs\n\u003e \n\u003e OPTX_INPUT_SINGLE: if set, pop input number off stack to apply to\n\u003e \t\tOPTX_SELECT_INPUT_*, otherwise iterate through all.\n\u003e OPTX_SELECT_INPUT_TXID: txid\n\u003e OPTX_SELECT_INPUT_OUTNUM: txout index\n\u003e OPTX_SELECT_INPUT_NSEQUENCE*: sequence number\n\u003e OPTX_SELECT_INPUT_AMOUNT32x2: sats in, as a high-low u31 pair\n\u003e OPTX_SELECT_INPUT_SCRIPT*: input scriptsig\n\u003e OPTX_SELECT_INPUT_TAPBRANCH: ?\n\u003e OPTX_SELECT_INPUT_TAPLEAF: ?\n\u003e \n\u003e OPTX_OUTPUT_SINGLE: if set, pop input number off stack to apply to\n\u003e \t\tOPTX_SELECT_OUTPUT_*, otherwise iterate through all.\n\u003e OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair\n\u003e OPTX_SELECT_OUTPUT_SCRIPTPUBKEY*: output scriptpubkey\n\u003e \n\u003e OPTX_SELECT_19...OPTX_SELECT_31: future expansion.\n\u003e \n\u003e OP_CHECKTEMPLATEVERIFY is approximated by the following flags:\n\u003e \tOPTX_SELECT_VERSION\n\u003e \tOPTX_SELECT_LOCKTIME\n\u003e \tOPTX_SELECT_INPUTCOUNT\n\u003e \tOPTX_SELECT_INPUT_SCRIPT\n\u003e \tOPTX_SELECT_INPUT_NSEQUENCE\n\u003e \tOPTX_SELECT_OUTPUTCOUNT\n\u003e \tOPTX_SELECT_OUTPUT_AMOUNT32x2\n\u003e \tOPTX_SELECT_OUTPUT_SCRIPTPUBKEY\n\u003e \tOPTX_SELECT_INPUTNUM\n\u003e \n\u003e All other flag combinations result in OP_SUCCESS.\n\u003e \n\u003e Discussion\n\u003e ----------\n\u003e \n\u003e By enumerating exactly what can be committed to, it's absolutely clear\n\u003e what is and isn't committed (and what you need to think about!).\n\u003e \n\u003e The bits which separate concatenation and hashing provide a simple\n\u003e mechanism for template-style (i.e. CTV-style) commitments, or for\n\u003e programatic treatment of individual elements (e.g. amounts, though the\n\u003e two s31 style is awkward: a 64-bit push flag could be added in future).\n\u003e \n\u003e The lack of double-hashing of scriptsigs and other fields means we\n\u003e cannot simply re-use hashing done for SIGHASH_ALL.\n\u003e \n\u003e The OP_SUCCESS semantic is only valid in tapscript v1, so this does not\n\u003e allow covenants for v0 segwit or pre-segwit inputs. If covenants prove\n\u003e useful, dedicated opcodes can be provided for those cases (a-la\n\u003e OP_CHECKTEMPLATEVERIFY).\n\u003e \n\u003e Cheers,\n\u003e Rusty.\n\u003e \n\u003e [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html\n\u003e [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019819.html\n\u003e [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019816.html\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-- \n--Brandon",
"sig": "d7ffcd2be97510fabf3da36a8cc2c08cebfcf4773b93ee604acb7229fa5fd54f7867d815086c57b848144df3c509b00707c4c828237abe95d8c50c222117e3cf"
}