📅 Original date posted:2023-03-01
🗒️ Summary of this message: A proposal to decouple the functionalities of `OP_VAULT` and `OP_UNVAULT` into their constituent functions with names, to improve legibility and remove recursive evaluation functionality. The proposal aims to be a drop-in replacement for the existing opcodes.
📝 Original message:Hello James,
First off, thank you for crafting an interesting idea like this that is
aimed at solving a serious problem. I see a lot of excitement about the use
cases, and I think it's worth iterating on.
Attempting to keep the idealized functionality constant, I'd like to
explore a design detour. I'm attempting to decouple the 3 functionalities
of `OP_VAULT` and `OP_UNVAULT` into their constituent functions with names
I just made up.
The goals of this e-mail:
1) Removing variable number of arguments based on values of arguments for
the opcodes.
To me as a spec reader, I find it very difficult to parse what's precisely
happening when. I think the only/last opcode to support this behavior was
OP_CHECKMULTISIG(could be wrong), and now I know another reason why OP_CSA
construct is nicer going forward with taproot.
2) Remove the recursive evaluation functionality used for authentication,
without reducing the efficacy of the targeted solution. Recursive
evaluation has a fraught history in Bitcoin script, makes composing
functionality with tooling likely more difficult, and has a lot of
templated behavior. If we can rely on regular old tapscript to get us where
we need to go, I'd prefer that.
3) Increase legibility of the spec. There's a ton going on, breaking things
up and naming them based on the method rather than the goal may help here.
4) Not (greatly) increase the expressiveness of the proposal. It's a
targeted proposal, and I'd like to respect that. These covenant opcodes are
intended to be drop-in replacements for the OP_(UN)VAULT opcodes.
To recap, there are three things happen in idealized OP_VAULT scenario:
1) Money comes out, then has to wait (trigger transaction)
2) Money waits long enough, then withdrawals to dynamic set of outputs that
are declared at trigger time (withdrawal transaction)
3) Money to single specified output script picked up front, with no wait
(recovery)
Below is a sketch of a replacement for the two opcodes. Ignore my
inconsistency on VERIFY/non-VERIFY behavior, seeing if people agree with
this general direction:
`OP_TRIGGER_FORWARD`: Takes exactly three arguments:
1) output index to match against (provided at spend time normally)
2) target-outputs-hash: 32 byte hash to be forwarded to output given at (1)
(provided at spend time normally)
3) spend-delay: value to be forwarded to output given at (1)
Fails script immediately if there aren't enough inputs or they're the wrong
format.
These last two arguments are "forwarded" to output at index declared in
first argument, resulting in:
`EXPR_WITHDRAW: <spend-delay> OP_CHECKSEQUENCEVERIFY OP_DROP
<target-outputs-hash> OP_FORWARD_OUTPUTS`
As the derived tapscript, embedded in a output scriptpubkey of the form:
`tr(NUMS,{...,EXPR_WITHDRAW})`, meaning we literally take the control block
from the spending input, swap the inner pubkey for `NUMS`, use
`EXPR_WITHDRAW` as the tapleaf, reconstruct the merkle root. If the output
scriptpubkey doesnt match, fail.
This TLUV-ish script/inner pubkey replacement is meant to allow arbitrary
other conditions, which is where the "recovery" path comes in for typical
usage.
If output at the target output index doesn't match the constructed script,
the evaluation fails.
`OP_FORWARD_DESTINATION`: Takes exactly two arguments:
1) `dest-vout-idx`: index of output that contains the so-called "recovery"
path
2) <recovery sPK tagged hash (32 bytes)>: the hash of the script destination
Fails immediately if the reconstructed output script doesn't match.
`OP_FORWARD_OUTPUTS` takes exactly one argument:
1) target-outputs-hash: commits to all outputs' scripts and values
Fails immediately if transaction's outputs(including value) hash doesn't
match.
**Typical usage**:
```
DEPOSITING TO VAULT SCRIPT:
EXPR_RECOVERY: <recovery> <auth> <stuff> <recovery sPK tagged hash (32
bytes)> OP_FORWARD_DESTINATION
EXPR_TRIGGER: <trigger> <auth> <stuff> <spend-delay> OP_TRIGGER_FORWARD
tr(KEY, {EXPR_RECOVERY, EXPR_TRIGGER})
```
```
EXPR_WITHDRAW: <spend-delay> OP_CHECKSEQUENCEVERIFY OP_DROP
<target-outputs-hash> OP_FORWARD_OUTPUTS
```
```
TRIGGERING WITHDRAWAL TIMER SCRIPT:
tr(NUMS, {EXPR_RECOVERY,EXPR_WITHDRAW}) <--- note EXPR_RECOVERY is forced
by the OP_TRIGGER_FORWARD TLUV action
```
Could save 2 WU having OP_FORWARD_OUTPUTS take the <spend-delay> directly
as an argument, or keep it more general as I did.
Would love to know what you and others think about this direction. I
apologies for any misunderstandings I have about the current OP_VAULT BIP!
Cheers,
Greg
On Mon, Feb 13, 2023 at 4:09 PM James O'Beirne via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Since the last related correspondence on this list [0], a number of
> improvements have been made to the OP_VAULT draft [1]:
>
> * There is no longer a hard dependence on package relay/ephemeral
> anchors for fee management. When using "authorized recovery," all
> vault-related transactions can be bundled with unrelated inputs and
> outputs, facilitating fee management that is self contained to the
> transaction. Consequently, the contents of this proposal are in theory
> usable today.
>
> * Specific output locations are no longer hardcoded in any of the
> transaction validation algorithms. This means that the proposal is now
> compatible with future changes like SIGHASH_GROUP, and
> transaction shapes for vault operations are more flexible.
>
> ---
>
> I've written a BIP that fully describes the proposal here:
>
>
> https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki
>
> The corresponding PR is here:
>
> https://github.com/bitcoin/bips/pull/1421
>
> My next steps will be to try for a merge to the inquisition repo.
>
> Thanks to everyone who has participated so far, but especially to AJ and
> Greg for all the advice.
>
> James
>
> [0]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html
> [1]: https://github.com/bitcoin/bitcoin/pull/26857
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230301/067e5b0d/attachment.html>;
Greg Sanders [ARCHIVE] /
npub1jd…3gh0m
2023-06-07 23:19:55
in reply to nevent1q…eype
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-06-07 23:19:55Event JSON
{
"id": "46234e6c944c5b7e8e5147029df2f313025e24cd7e9ce7500a0ba29b231c15fe",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1686179995,
"kind": 1,
"tags": [
[
"e",
"647fc7db9ce6599535c0921f7a07494f1213a0b3b646951b297e97e004c8718e",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2023-03-01\n🗒️ Summary of this message: A proposal to decouple the functionalities of `OP_VAULT` and `OP_UNVAULT` into their constituent functions with names, to improve legibility and remove recursive evaluation functionality. The proposal aims to be a drop-in replacement for the existing opcodes.\n📝 Original message:Hello James,\n\nFirst off, thank you for crafting an interesting idea like this that is\naimed at solving a serious problem. I see a lot of excitement about the use\ncases, and I think it's worth iterating on.\n\nAttempting to keep the idealized functionality constant, I'd like to\nexplore a design detour. I'm attempting to decouple the 3 functionalities\nof `OP_VAULT` and `OP_UNVAULT` into their constituent functions with names\nI just made up.\n\nThe goals of this e-mail:\n\n1) Removing variable number of arguments based on values of arguments for\nthe opcodes.\nTo me as a spec reader, I find it very difficult to parse what's precisely\nhappening when. I think the only/last opcode to support this behavior was\nOP_CHECKMULTISIG(could be wrong), and now I know another reason why OP_CSA\nconstruct is nicer going forward with taproot.\n\n2) Remove the recursive evaluation functionality used for authentication,\nwithout reducing the efficacy of the targeted solution. Recursive\nevaluation has a fraught history in Bitcoin script, makes composing\nfunctionality with tooling likely more difficult, and has a lot of\ntemplated behavior. If we can rely on regular old tapscript to get us where\nwe need to go, I'd prefer that.\n\n3) Increase legibility of the spec. There's a ton going on, breaking things\nup and naming them based on the method rather than the goal may help here.\n\n4) Not (greatly) increase the expressiveness of the proposal. It's a\ntargeted proposal, and I'd like to respect that. These covenant opcodes are\nintended to be drop-in replacements for the OP_(UN)VAULT opcodes.\n\nTo recap, there are three things happen in idealized OP_VAULT scenario:\n1) Money comes out, then has to wait (trigger transaction)\n2) Money waits long enough, then withdrawals to dynamic set of outputs that\nare declared at trigger time (withdrawal transaction)\n3) Money to single specified output script picked up front, with no wait\n(recovery)\n\nBelow is a sketch of a replacement for the two opcodes. Ignore my\ninconsistency on VERIFY/non-VERIFY behavior, seeing if people agree with\nthis general direction:\n\n`OP_TRIGGER_FORWARD`: Takes exactly three arguments:\n1) output index to match against (provided at spend time normally)\n2) target-outputs-hash: 32 byte hash to be forwarded to output given at (1)\n(provided at spend time normally)\n3) spend-delay: value to be forwarded to output given at (1)\n\nFails script immediately if there aren't enough inputs or they're the wrong\nformat.\n\nThese last two arguments are \"forwarded\" to output at index declared in\nfirst argument, resulting in:\n\n`EXPR_WITHDRAW: \u003cspend-delay\u003e OP_CHECKSEQUENCEVERIFY OP_DROP\n\u003ctarget-outputs-hash\u003e OP_FORWARD_OUTPUTS`\n\nAs the derived tapscript, embedded in a output scriptpubkey of the form:\n`tr(NUMS,{...,EXPR_WITHDRAW})`, meaning we literally take the control block\nfrom the spending input, swap the inner pubkey for `NUMS`, use\n`EXPR_WITHDRAW` as the tapleaf, reconstruct the merkle root. If the output\nscriptpubkey doesnt match, fail.\n\nThis TLUV-ish script/inner pubkey replacement is meant to allow arbitrary\nother conditions, which is where the \"recovery\" path comes in for typical\nusage.\n\nIf output at the target output index doesn't match the constructed script,\nthe evaluation fails.\n\n`OP_FORWARD_DESTINATION`: Takes exactly two arguments:\n1) `dest-vout-idx`: index of output that contains the so-called \"recovery\"\npath\n2) \u003crecovery sPK tagged hash (32 bytes)\u003e: the hash of the script destination\n\nFails immediately if the reconstructed output script doesn't match.\n\n`OP_FORWARD_OUTPUTS` takes exactly one argument:\n1) target-outputs-hash: commits to all outputs' scripts and values\n\nFails immediately if transaction's outputs(including value) hash doesn't\nmatch.\n\n**Typical usage**:\n```\nDEPOSITING TO VAULT SCRIPT:\n\nEXPR_RECOVERY: \u003crecovery\u003e \u003cauth\u003e \u003cstuff\u003e \u003crecovery sPK tagged hash (32\nbytes)\u003e OP_FORWARD_DESTINATION\nEXPR_TRIGGER: \u003ctrigger\u003e \u003cauth\u003e \u003cstuff\u003e \u003cspend-delay\u003e OP_TRIGGER_FORWARD\n\ntr(KEY, {EXPR_RECOVERY, EXPR_TRIGGER})\n```\n\n```\nEXPR_WITHDRAW: \u003cspend-delay\u003e OP_CHECKSEQUENCEVERIFY OP_DROP\n\u003ctarget-outputs-hash\u003e OP_FORWARD_OUTPUTS\n```\n\n```\nTRIGGERING WITHDRAWAL TIMER SCRIPT:\n\ntr(NUMS, {EXPR_RECOVERY,EXPR_WITHDRAW}) \u003c--- note EXPR_RECOVERY is forced\nby the OP_TRIGGER_FORWARD TLUV action\n```\n\nCould save 2 WU having OP_FORWARD_OUTPUTS take the \u003cspend-delay\u003e directly\nas an argument, or keep it more general as I did.\n\nWould love to know what you and others think about this direction. I\napologies for any misunderstandings I have about the current OP_VAULT BIP!\n\nCheers,\nGreg\n\nOn Mon, Feb 13, 2023 at 4:09 PM James O'Beirne via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Since the last related correspondence on this list [0], a number of\n\u003e improvements have been made to the OP_VAULT draft [1]:\n\u003e\n\u003e * There is no longer a hard dependence on package relay/ephemeral\n\u003e anchors for fee management. When using \"authorized recovery,\" all\n\u003e vault-related transactions can be bundled with unrelated inputs and\n\u003e outputs, facilitating fee management that is self contained to the\n\u003e transaction. Consequently, the contents of this proposal are in theory\n\u003e usable today.\n\u003e\n\u003e * Specific output locations are no longer hardcoded in any of the\n\u003e transaction validation algorithms. This means that the proposal is now\n\u003e compatible with future changes like SIGHASH_GROUP, and\n\u003e transaction shapes for vault operations are more flexible.\n\u003e\n\u003e ---\n\u003e\n\u003e I've written a BIP that fully describes the proposal here:\n\u003e\n\u003e\n\u003e https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki\n\u003e\n\u003e The corresponding PR is here:\n\u003e\n\u003e https://github.com/bitcoin/bips/pull/1421\n\u003e\n\u003e My next steps will be to try for a merge to the inquisition repo.\n\u003e\n\u003e Thanks to everyone who has participated so far, but especially to AJ and\n\u003e Greg for all the advice.\n\u003e\n\u003e James\n\u003e\n\u003e [0]:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html\n\u003e [1]: https://github.com/bitcoin/bitcoin/pull/26857\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230301/067e5b0d/attachment.html\u003e",
"sig": "58636b6611cd8a47129f3f5b210350a1be9e4211427b9ca0e41808fadb618eb78ee45b661fa00d99517784d189fff1391805bd94508007dd0350b4096690b7e7"
}