ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-08 📝 Original message:Good morning Salvatore, ...
📅 Original date posted:2022-11-08
📝 Original message:Good morning Salvatore,
Interesting idea.
The idea to embed the current state is similar to something I have been musing about recently.
> ### Game theory (or why the chain will not see any of this)
>
> With the right economic incentives, protocol designers can guarantee that playing a losing game always loses money compared to cooperating. Therefore, the challenge game is never expected to be played on-chain. The size of the bonds need to be appropriate to disincentivize griefing attacks.
Modulo bugs, operator error, misconfigurations, and other irrationalities of humans.
> - OP_CHECKOUTPUTCOVENANTVERIFY: given a number out_i and three 32-byte hash elements x, d and taptree on top of the stack, verifies that the out_i-th output is a P2TR output with internal key computed as above, and tweaked with taptree. This is the actual covenant opcode.
Rather than get taptree from the stack, just use the same taptree as in the revelation of the P2TR.
This removes the need to include quining and similar techniques: just do the quining in the SCRIPT interpreter.
The entire SCRIPT that controls the covenant can be defined as a taptree with various possible branches as tapleaves.
If the contract is intended to terminate at some point it can have one of the tapleaves use `OP_CHECKINPUTCOVENANTVERIFY` and then determine what the output "should" be using e.g. `OP_CHECKTEMPLATEVERIFY`.
> - Is it worth adding other introspection opcodes, for example OP_INSPECTVERSION, OP_INSPECTLOCKTIME? See Liquid's Tapscript Opcodes [6].
`OP_CHECKTEMPLATEVERIFY` and some kind of sha256 concatenated hashing should be sufficient I think.
> - Is there any malleability issue? Can covenants “run” without signatures, or is a signature always to be expected when using spending conditions with the covenant encumbrance? That might be useful in contracts where no signature is required to proceed with the protocol (for example, any party could feed valid data to the bisection protocol above).
Hmm protocol designer beware?
Regards,
ZmnSCPxj
📝 Original message:Good morning Salvatore,
Interesting idea.
The idea to embed the current state is similar to something I have been musing about recently.
> ### Game theory (or why the chain will not see any of this)
>
> With the right economic incentives, protocol designers can guarantee that playing a losing game always loses money compared to cooperating. Therefore, the challenge game is never expected to be played on-chain. The size of the bonds need to be appropriate to disincentivize griefing attacks.
Modulo bugs, operator error, misconfigurations, and other irrationalities of humans.
> - OP_CHECKOUTPUTCOVENANTVERIFY: given a number out_i and three 32-byte hash elements x, d and taptree on top of the stack, verifies that the out_i-th output is a P2TR output with internal key computed as above, and tweaked with taptree. This is the actual covenant opcode.
Rather than get taptree from the stack, just use the same taptree as in the revelation of the P2TR.
This removes the need to include quining and similar techniques: just do the quining in the SCRIPT interpreter.
The entire SCRIPT that controls the covenant can be defined as a taptree with various possible branches as tapleaves.
If the contract is intended to terminate at some point it can have one of the tapleaves use `OP_CHECKINPUTCOVENANTVERIFY` and then determine what the output "should" be using e.g. `OP_CHECKTEMPLATEVERIFY`.
> - Is it worth adding other introspection opcodes, for example OP_INSPECTVERSION, OP_INSPECTLOCKTIME? See Liquid's Tapscript Opcodes [6].
`OP_CHECKTEMPLATEVERIFY` and some kind of sha256 concatenated hashing should be sufficient I think.
> - Is there any malleability issue? Can covenants “run” without signatures, or is a signature always to be expected when using spending conditions with the covenant encumbrance? That might be useful in contracts where no signature is required to proceed with the protocol (for example, any party could feed valid data to the bisection protocol above).
Hmm protocol designer beware?
Regards,
ZmnSCPxj