Author: ZmnSCPxj 2022-11-08 12:01:11
Published on: 2022-11-08T12:01:11+00:00
The email is discussing an interesting idea to embed the current state, which is similar to something the author has been thinking about. The email also discusses game theory and how with the right economic incentives, protocol designers can guarantee that playing a losing game always loses money compared to cooperating. This makes it so that the challenge game is never expected to be played on-chain. The size of the bonds needs to be appropriate to disincentivize griefing attacks. There is also a discussion about OP_CHECKOUTPUTCOVENANTVERIFY, which verifies that the out_i-th output is a P2TR output with internal key computed as above, and tweaked with taptree. Instead of getting taptree from the stack, the same taptree as in the revelation of the P2TR can be used, removing the need to include quining and similar techniques. The entire SCRIPT that controls the covenant can be defined as a taptree with various possible branches as tapleaves. Lastly, there is a discussion about introspection opcodes and whether it is worth adding other introspection opcodes, such as OP_INSPECTVERSION or OP_INSPECTLOCKTIME. It is suggested that OP_CHECKTEMPLATEVERIFY and some kind of sha256 concatenated hashing should be sufficient. Additionally, there is a question about whether covenants can "run" without signatures, or if a signature is always to be expected when using spending conditions with the covenant encumbrance. The answer to this question could be useful in contracts where no signature is required to proceed with the protocol.
Updated on: 2023-06-16T03:03:20.693477+00:00