Published on: 2022-01-22T00:19:07+00:00
The conversation between Billy Tetrud and an unknown recipient revolves around the concept of a 'parent' in Bitcoin transactions and the optimization of the UXTO model. The recipient expresses concern about transactions becoming invalid due to limitations on how far they can point back, which could cause problems during reorgs. The discussion also touches on the use of capabilities validation tricks and optional mappings of inputs to outputs.The author questions the need to verify the secure hash chain from parent to child in Bitcoin transactions, suggesting that transactions should be defined as invalid unless they match the covenant in the parent. However, this can lead to transactions becoming invalid and create issues during reorgs. There is limited information available on why valid transactions becoming invalid is seen as a problem. Peter Todd points out that allowing references to old blocks could bring in old block data into the UTXO set and cause issues.In another discussion, Bram Cohen raises concerns about a proposal that would require nodes to keep the entire blockchain, potentially causing scalability issues. He mentions that Monero's UTXO set is already the whole blockchain, resulting in problems for pruned nodes. Allowing references to old blocks could lead to similar issues for Bitcoin. It is important to carefully consider proposals before implementation to avoid unintended consequences.Billy Tetrud and an anonymous party discuss the concept of covenants in Bitcoin and the ability to specify spending rules for UTXOs. They mention the lack of a strong single concept for a 'parent' in Bitcoin transactions and the ability for a coin to check its own ID and verify the secure hash chain from parent to child. They also discuss the potential for scalability issues if references to old blocks are allowed.Bram Cohen and Billy Tetrud discuss the implementation of covenants in Bitcoin and suggest adding programmatic capabilities to the language. They mention the complexity of Bitcoin transactions and the need for special-purpose opcodes to make coherent statements. They discuss the potential for deduplicating common script snippets to save bandwidth. They highlight the importance of ensuring recipients fully understand the covenant attached to a payment and the potential scalability issues with allowing references to old blocks.In a recent post on the bitcoin-dev mailing list, Bram Cohen discusses adding covenants and capabilities to the UTXO model. He suggests adding programmatic capabilities to the language and special-purpose opcodes for coherent statements about transactions. He emphasizes the need for recipients to fully understand payment covenants and discusses potential issues with implementing complex functionality. He proposes ways to compress or deduplicate code snippets for better scalability. Cohen's suggestions aim to add covenants and capabilities while making minimal compromises to Bitcoin's current practices.The UTXO model can be modified to include covenants and capabilities by adding programmatic capabilities to the language and using programmatic tricks. However, a clear concept of a single parent in Bitcoin transactions is missing. Implementing complex functionality can be expensive, and deduplicating code snippets is necessary for optimization. The controversy lies in whether covenants and capabilities should be opt-in or opt-out. Recipients must fully understand the implications of covenants, and retroactive veto or clawback actions are unacceptable. Concerns have been raised about potential attacks on the underlying chain if colored coins' value exceeds the tokenized chain. Backwards pointing covenants can be used for more complex functionality. The chialisp.com website offers a detailed implementation of these ideas in a slightly different model.
Updated on: 2023-08-02T05:16:41.582819+00:00