Author: Antoine Riard 2021-09-12 23:37:56
Published on: 2021-09-12T23:37:56+00:00
The conversation started with a suggestion to use maths operators to verify that funds are being appropriately retained in the updated scriptPubKey. The IN_OUT_AMOUNT opcode lets you do maths on the values, so you can specify "hot wallets can withdraw up to X" rather than "hot wallets must withdraw exactly X". However, one user suggests that if you want to tweak all the scripts, you should be using the key path. Another way to do something like that without changing the scripts is to have the timelock on most of the scripts be something like "[3 months] CSV", and have a "delay" script that doesn't require a CSV.The conversation then moves on to discuss how utxos can "interact," which is interesting for automated market makers but may only be relevant for chains aiming to support multiple asset types, not bitcoin directly. One user suggests combining it with CTV might solve this problem, particularly if the hash passed to CTV is constructed via script/CAT/etc. Another user suggests that SIGHASH_GROUP might be more interesting as you could generate transaction "puzzles." There is also a discussion about a constant product market maker without a profit margin, which is used to imply a price where traders will rebalance anytime that price is out of whack with the rest of the market.The conversation revolves around the development of a new script primitive called MERKLESUB, which is still a work in progress. The semantic of this script primitive involves interpreting the top stack item as an output position and the second top stack item as a 32-byte x-only pubkey to be negated and added to the spent internal pubkey, if the input spent is a SegWit v1 Taproot output and the script path spending is used. The spent tapscript is then removed from the merkle tree of tapscripts, and a new merkle root is recomputed with the first node element of the spending control block as the tapleaf hash. This new merkle root is then added as the taproot tweak to the updated internal pubkey, while correcting for parity.One concern raised was that anyone who could do a valid spend of the tx could violate the covenant by spending to an unencumbered witness v2 output and steal the funds. One solution proposed was to extend the signature digest algorithm to encompass the segwit version of the spending transaction outputs. An "contract" aggregated-key would then be added in every tapscript where a TLUV/MERKLESUB covenant is present, and the off-chain contract participant can exchange signatures at initial setup committing to the segwit version.Another suggestion was to use the output position parameter to merge/split a vault/pool, though it was noted that it might be more efficient to do so via the key path. There was also discussion about introducing a separate OP_MERKLEADD to add a point to the internal pubkey group signer, but it was argued that saving one byte of witness data at the cost of specifying additional opcodes may not be the most optimal solution.Finally, the conversation explored the idea of introducing a new tapscript version (`TAPROOT_INTERNAL_TAPSCRIPT`) to signal that VerifyTaprootCommitment must compute the TapTweak with a new TapTweak=(internal_pubkey || merkle_root || parity_bit), though it was pointed out that different scripts in the same merkle tree can have different script versions, which would indicate different parities for the same internal pub key. The discussion also touched on the development of an opcode to build a merkle root from tagged hashes directly.
Updated on: 2023-06-15T01:41:07.435427+00:00