Published on: 2022-02-03T06:17:14+00:00
In a recent discussion on the bitcoin-dev mailing list, the topic of enabling covenants in Bitcoin Script was explored. One suggestion involved using the "2 2 CHECKMULTISIG" multisig approach to enforce KYC by requiring funds to be deposited and signed with a government key. The idea of using recursive covenants to create non-terminating computations was also discussed. This concept was originally mentioned in a tweet by Ethan Heilman and later elaborated on in a post by Andrew Poelstra.The discussion also delved into the question of whether Turing completeness should be banned in Bitcoin Script. ZmnSCPxj argued for allowing total Turing-completeness but banning partial Turing-completeness. However, it was acknowledged that banning non-terminating computation for cross-transaction computations would be infeasible. Recursive covenants were identified as a way to write universal computations, and banning source code manipulation would essentially mean banning the manipulation of strings of bytes, which is fundamental to Bitcoin Script.ZmnSCPxj further explained the concept of substructural recursion rules and copattern matching in total functional languages, which ensure termination of recursion. They compared recursive covenants in Bitcoin to codata types in total functional languages, emphasizing the need for Bitcoin SCRIPT to be provably terminating.Jeremy Rubin raised concerns about the potential dangers of evil multisig covenants and the possibility of mining centralization leading to censorship. The discussion also touched on the usefulness of the CSFS opcode and the relationship between OP_CAT and covenants. It was suggested that more direct approaches like OP_TWEAK or UPDATETAPLEAF could be better for implementing covenants.The conversation also addressed the need for separate programs to operate ants and the encoding of state in other parts of the transaction. The idea of adding OP_TWEAK and convenience opcodes for building Taproot Merkle trees was proposed.The discussion on enabling covenants highlighted concerns about transaction and block validation for nodes, ensuring bounded resource requirements and clear evaluation costs. It was noted that while enabling covenants could allow for complex machines that manipulate funds on the blockchain, simple Script programs can be validated and scrutinized to mitigate potential risks. The addition of OP_CHECKSIGFROMSTACK opcode and upper bounds on recursions were suggested as possible solutions.Overall, the discussion emphasized the need for careful consideration of enabling covenants, balancing functionality with validation costs and ensuring the safety and integrity of the Bitcoin network.The ongoing discussion on enabling covenants in Bitcoin has seen arguments against them losing weight as more research is conducted. Multisig wallets alone can enable recursive covenants, such as when a government requires funds to be deposited into a multisig that can only be spent if certain conditions are met. This approach is already being used in permissioned systems like Liquid. While there are ways to escape from recursive covenants, they are not fundamentally different from consensus-enforced covenants. Therefore, multisig-based covenants should be considered in the ongoing discussions about enabling covenants in Bitcoin.Recent research has reduced the weight of arguments against covenants, as AJ's point has further weakened anti-covenant arguments. Multisig alone can enable recursive covenants, as a government can deposit funds into a multisig wallet that requires certain conditions to be met for spending. This process is more efficient than explicit covenants and is already being used in systems like Liquid. The difference between escaping from recursive covenants and consensus-enforced covenants seems to be in procedure and difficulty rather than a fundamental difference.The discussion around enabling covenants is centered on whether OP_CAT should be allowed or not. Multisig wallets can enable recursive covenants, as a government can require funds to be deposited into a multisig that follows certain rules. This approach is already used by Liquid and BTC-on-Ethereum tokens. Escaping from this type of recursive covenant would require a change in signing policy. However, escaping any consensus-enforced covenant would require a hard fork. This difference seems to be more procedural and difficulty-based.Russell O'Connor raised concerns about recursive covenants and the implications of enabling OP_CAT. He initially suggested that such worries should be left for OP_TWEAK, but later acknowledged that recursive covenants could still be created by sneaking state into UTXO amounts or sibling outputs accessed via txid. This highlights the importance of avoiding giving too much power. However, altcoins already exist and some are worse, making full EVM support possible.In an email thread, Russell O'Connor discussed the topic of enabling covenants, specifically recursive covenants that require OP_TWEAK.
Updated on: 2023-08-02T04:21:03.192868+00:00