Author: Antoine Riard 2021-09-18 14:11:10
Published on: 2021-09-18T14:11:10+00:00
The conversation revolves around optimizing Taproot, a proposed upgrade to Bitcoin's scripting language. The debate is focused on tapscripts - a type of script used in Taproot that enables more complex smart contracts. One suggestion is to introduce a new opcode called IN_OUT_AMOUNT which lets you do maths on the values and specify "hot wallets can withdraw up to X" rather than "hot wallets must withdraw exactly X. "Another suggestion discussed is tweaking the merkle tree so that the one-time path is removed from it after it has been played out. This behavior can be achieved by starting off with the funds in scriptPubKey S1, then spending using D to get to S2, then spending using W to get to S3, and finally spending using N at some point. The conversation also discusses the MERKLESUB opcode, which is similar to the TLUV proposal but lacks the ability to add branches and preserve the current script. However, it gains the ability to refer to non-corresponding outputs. Combining scope-minimal opcodes like MERKLESUB with sighash malleability is also explored as a way to update a subset of off-chain contract transactions fields after funding phase, with a lower level of cooperation than required by the key path.The idea of conserving contract pre-negotiated economic equilibrium in the case of emergency without relying on post-fork cooperation of the counterparty is also discussed. However, achieving this reliably without using the key path is difficult. Finally, the conversation concludes that merkle trees aren't the most straightforward way to encode arbitrary subsets of the pool's contract policy. Overall, the discussion focuses on various ways to optimize Taproot's smart contract capabilities while maintaining security and reliability.
Updated on: 2023-06-15T01:39:06.610308+00:00