Multiple ways to do bitcoin covenants [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2022-05-01T23:02:55+00:00


Summary:

The author of the context has been analyzing various covenant proposals with a focus on wallet vaults. Among the options discussed, CTV (Covenant Transaction Verification) is considered as the minimal covenant opcode that addresses malleability issues. Other proposed opcodes have potential undesirable effects when interacting with existing systems. Another option, TXHASH+CSFS, offers similar capabilities to CTV but is more complex due to additional features. APO wallet vaults are deemed hacky, inefficient, and limited in their functionality. TLUV + IN_OUT_AMOUNT allows for infinitely recursive covenants, but it has limitations with multi-input transactions. OP_CHECKOUTPUTVERIFY is an interesting opcode that enables recursive covenants but shares similar limitations as TLUV + IN_OUT_AMOUNT with multi-input transactions, and it also incurs high costs beyond simple covenants. While some of these covenant opcodes have been specified and analyzed to some extent, none except CTV (potentially TXHASH+CSFS) seem to be of sufficient quality to be implemented in Bitcoin in their current state. The author favors CTV due to its simplicity, efficiency in block space usage, and the ability to be utilized even without taproot.However, it is acknowledged that different developers may have preferences for alternative methods of implementing Bitcoin covenants for various reasons. Recent discussions and explorations have centered around CTV and other covenant proposals. One question raised was whether Bitcoin already has opcodes with overlapping features, and the answer is affirmative. It is indeed possible to have multiple ways to achieve Bitcoin covenants with some tradeoffs.The author also questions the tradeoffs between CTV, APO, TLUV, and TXHASH+CSFS. While the first question received answers from Jeremy and sheshek in the CTV chat, there is no clear consensus regarding the second question.When comparing the different options, the author reiterates their preference for CTV due to its simplicity, block space efficiency, and ability to be used independently of taproot. It is important to consider bare script to expose a public key in the case of an EC (Elliptic Curve) break, as relying solely on vaults can lead to potential vulnerabilities. Additionally, with the growing prevalence of quantum computing, it is unsustainable to force everyone into a quantum-unsafe position.However, it is acknowledged that other developers may have different preferences for implementing Bitcoin covenants. For example, Russel O'Connor favors the general OP_TXHASH design.


Updated on: 2023-08-02T06:18:07.113596+00:00