Published on: 2022-05-03T16:40:22+00:00
The email thread discusses the debate within the Bitcoin developer community regarding the use of SIGHASH_ANYPREVOUT (APO) as an alternative to CTV's proposed covenant design. The author retracts their previous statement in favor of OP_CTV, realizing that both APOAS and CTV face a trade-off between flexibility and safety. They question the need for less restrictive templates and provide reasons why such templates may be necessary. They argue that disallowing RBF can make it difficult for attackers to create malicious alternatives, certain covenant-based applications may not be critical enough to require strict restrictions, and flexible signature messages can be used safely in trusted multi-party contexts.The author suggests that APOAS covenants, when combined with other SIGHASH modes and the ability to re-bind transactions, offer more flexibility than CTV covenants. They express their uncertainty about the safety of BIP-118 but believe that the recent debate is part of the maturation process and are glad for it.The discussion also focuses on the potential use of APO instead of CTV. Some argue that APO gets dangerously close to fully recursive covenants and suggest using smaller independent steps, like adding CTV and gradually introducing more flags and ergonomic Opcodes for covenants. Others believe that BIP118 could be a soft fork candidate that benefits more Bitcoin users, considering the interest in simple covenants and better off-chain protocols. There is also concern about the long-term storage of bitcoins in non-quantum-computer vulnerable-bare-CTV-covenants and the potential impact of a large-scale theft of bitcoins on the overall value of the cryptocurrency.In a conversation between Antoine and Jacob, they discuss the comparison between CTV and APO covenants. Antoine clarifies that both commit to the same template and that more powerful covenants could enable more interesting applications where CTV would be an optimization. However, in the short term, some request activating CTV to start playing with covenants before settling on a more useful covenant. Jacob argues that APOAS-based covenants tie the signature message algorithm to both the covenant commitment and transaction validation, introducing a trade-off between safety and flexibility. Antoine suggests separating the covenant commitment from the signatures to validate transactions, bypassing this trade-off.The email thread also discusses the use of BIP118 and its potential as a soft fork candidate. It is suggested that committing to the number of inputs instead of sha_sequences ensures txid stability for single input transactions. There is also discussion about whether APO-AS part of BIP118 may face opposition similar to BIP119.In another discussion on the Bitcoin-dev mailing list, the use cases of APOAS|SINGLE are explored. It is noted that APOAS|SINGLE is useful for vaults or spacechains but not for batch channels or congestion control. The debate revolves around the commitment to amount and its implications. The suggestions put forward include doing a tweaked version of BIP118 in place of or before BIP119 and making the commitment to amount optional behind a flag.The author acknowledges the benefits of using APOAS instead of CTV in the short-term, as it enables Eltoo. However, they argue that there is a point in favor of CTV in the long-term. They suggest separating the covenant commitment from the signatures to validate transactions, providing additional flexibility for new templates and enabling more utility for covenant-based applications.The author of a post on the Bitcoin-dev mailing list proposes using a tweaked version of BIP118 as an alternative to CTV. They argue that SIGHASH_ANYPREVOUTANYSCRIPT can emulate CTV if its "ANYONECANPAY" behavior is made optional. The author suggests that APO-AS covenants could cover the flagship use case of vaults and that potential use cases for APO should be explored. They propose that BIP118 could benefit more Bitcoin users and ask if people would oppose the APO-AS part of BIP118 for the same reasons they might oppose BIP119.Another member of the mailing list expresses doubts about the necessity and sufficiency of CTV, suggesting that pre-signed transactions could be used instead. They argue that APO-AS covenants can cover the same use cases as CTV and propose that CTV could be considered an optimization of APO. The member suggests that if onchain usage proves them wrong, CTV could still be rolled out as an optimization.In addition, there is discussion about the activation of CTV and SIGHASH_ANYPREVOUT, with concerns about scarce reviewer time. The fields covered by the CTV hash are similar to what the ANYPREVOUT_ANYSCRIPT's signature hash covers, but APO_AS does not commit to the number of inputs and the hash of the inputs' sequences.
Updated on: 2023-08-02T06:12:38.421815+00:00