Published on: 2023-05-30T07:34:09+00:00
In a discussion about taproot internal pubkey and "dynamic key aggregation," Johan proposed a method for efficient use in coin pools. This involved removing data from the merkle tree and storing the pubkeys of members in the embedded data. Salvatore Ingala suggested making OP_CICV and OP_COCV symmetrical to simplify the process and explore a single OP_CHECK_IN_OUT_CONTRACT_VERIFY opcode for greater flexibility. Johan shared his excitement about the implementation of merkleization and suggested making OP_CICV and OP_COCV symmetrical in an email conversation. Salvatore agreed and added that he was exploring a similar method for bringing externally signed data onto the stack. Johan mentioned that fully functioning CoinPools would require functionality similar to OP_MERKLESUB. Salvatore stated that efficient use of the taproot internal pubkey with "dynamic key aggregation" might not be possible with the current semantics.Salvatore Ingala apologized for oversights in his previous email, noting that m_B cannot be committed as-is in the contract's embedded data with the current semantics of OP_COCV. He suggested storing its hash SHA256(m_B) instead. In another email, Salvatore discussed a fun construction on top of the fact that f is committed to in the contract, explaining that one could build a universal state channel where parties can enter any contract among themselves entirely inside the channel.The email conversation on the bitcoin-dev mailing list discussed the generalization of a construct that allows access to embedded data in inputs and outputs, enforcement of output keys and taptrees, and how fraud proofs can extend beyond what Script can do. The conversation then shifted to simulating coin pools using a commitment to the set of pubkeys and amounts owned by participants, along with an output taptree where each participant has their own spending path. The unilateral withdrawal Script can be the same for all participants, with the witness containing the Merkle proof and additional information to identify the leaf in the tree.Salvatore Ingala proposed using rock-paper-scissors as an academic example for the MATT (Miniscript + adaptor signatures + taproot) smart contract. The protocol involves Alice choosing and publishing her move, Bob choosing his move, and the pot being adjudicated per the rules. To prevent Bob from waiting for Alice's move to play accordingly, Alice publishes a commitment to her move and reveals it later. Using CICV/COCV, the game can be played with three transactions, and the possible payout options are fully known when the game starts.Johan asked Salvatore for an example of how a proposal for powerful capabilities with simple opcodes would look on-chain for a simple game like "one player tic-tac-toe" with two tiles. Salvatore explained that the computation step encoded in a leaf needs to be simple enough for Script to verify it. In another email thread, Billy Tetrud mentioned Verkle trees as a useful construction for something like Utreexo, but noted that the cryptography used for Verkle trees isn't quantum-safe. Salvatore also discussed a fun construction on top of the fact that f is committed to in the contract, explaining the possibility of building a universal state channel where parties can enter any contract among themselves entirely inside the channel.In an email exchange, Rijndael and Salvatore discussed the challenge protocol of a fraud-proof system. Rijndael asked if Alice can post a commitment to a different computation that yields a favorable result for her. Salvatore explained that the function f is already hard-coded in the contract itself through the tree of scripts, thus committing to the possible futures. Salvatore suggested dropping op_i from the i-th leaf commitment and embedding the information in the corresponding state's Script. Salvatore further elaborated on the use of a universal Turing machine as a generic function f, allowing for the creation of contracts where the function is not decided when the channel is created.The article delved into the bisection protocol used in smart contracts through MATT covenants. This protocol ensures that both parties provide correct data for a computation step, and if one party provides incorrect information, the other can take all the money. The protocol relies on a collision-free hash function and deterministic computation. The article acknowledged missing aspects of the protocol, such as bonds to incentivize cooperation and additional transitions at every step. However, the code and scripts of the protocol are independent of the actual execution and can be precomputed before the initial covenant is created. Rijndael questioned how to ensure that the execution trace posted by Alice is for the correct computation and not a different one. Salvatore explained that the bisection's Merkle tree is computed only when the parties execute the computation and it never ends up on-chain.
Updated on: 2023-08-02T08:28:28.195475+00:00