TAPLEAF_UPDATE_VERIFY covenant opcode

Summary:

In this email conversation, the sender thanks AJ for helping with a paper on the CoinPool protocol and provides some early feedback on the proposal. The email discusses a proposal for OP_MERKLESUB opcode and how it can be used to create a new taproot address based on the input being spent by updating the internal public key, trimming the merkle path, removing the script currently executing, or adding a new step to the end of the merkle path. The email also suggests the introduction of a separate OP_MERKLEADD opcode to add a point to the internal pubkey group signer.The email further discusses the need for committing the parity of the internal pubkey as part of the spent utxo and proposes a solution by introducing a new tapscript version, TAPROOT_INTERNAL_TAPSCRIPT signaling that VerifyTaprootCommitment must compute the TapTweak with a new TapTweak=(internal_pubkey || merkle_root || parity_bit). The email also discusses SIGHASH_GROUP design and proposes a scheme allowing for a utxo to represent a group's pooled funds. It mentions pre-signed withdraw transactions sending to {to_withdraw,to_pool} outputs, which force the point subtraction.Furthermore, the email discusses how blockchain validation semantic extension is vaudoo-magic if we want to enable smart corporation/scalable multi-event contracts. It suggests that bitcoin ledger would fit perfectly well to host international commerce law style of contracts. Lastly, the email discusses some limitations of the proposed scheme, such as not being able to tweak scripts in areas of the merkle tree that it can't see and providing no way for utxos to "interact. "The email discusses a new opcode called TAPLEAF_UPDATE_VERIFY (TLUV), which is used to update a UTXO by changing the Taproot tree. The TLUV takes three inputs, one that specifies how to update the internal public key, another that specifies a new step for the merkle path, and a third that specifies whether to remove the current script and/or how many merkle path steps to remove. The opcode calculates the scriptPubKey that matches the updated UTXO and verifies that the output corresponding to the current input spends to that scriptPubKey.Two examples of how this functionality can be used are provided. The first example is a basic vault where funds are protected by a cold wallet key and a hot wallet key. A taproot output is constructed with COLD as the internal public key and a script that limits the hot wallet to withdrawing at most L satoshis every D blocks. The second example is allowing for a UTXO to represent a group's pooled funds. Each participant has their own script path that allows them to unilaterally withdraw their balance from the pool. If everyone decides to exit, whoever is last can spend the remaining balance directly via the key path.The bitcoin-dev mailing list has discussed the use of recursive covenants for funding joint ventures. This involves multiple members of a pool sending funds to multiple destinations with a single signature, but requires everyone in the pool to be online in order to sign via the key path. While no transfer is final without an updated state being committed on chain, one benefit compared to lightning is that if one member unilaterally exits, it doesn't reveal the state of anyone remaining in the pool. A limitation of this method is that it can't tweak scripts in areas of the merkle tree that it can't see, and it doesn't provide a way for utxos to interact. However, combining it with CTV may solve the latter issue. The use of dedicated opcodes would make the feature easy to use correctly and cheap and efficient to use in wallets and nodes. The idea behind an automated market maker involves setting up a script that links the change in value to the BTC utxo and the change in value to the USDT utxo. While TLUV doesn't provide a way to do that linkage, specifying a covenant that does would support this use case.

Updated on: 2023-06-15T01:42:35.676613+00:00