Published on: 2022-01-21T17:36:13+00:00
In a recent discussion about the activation method for Bitcoin Improvement Proposal (BIP) 8 and BIP 9/ST, there was disagreement over how these proposals should be characterized. The main point of contention was whether activation required majority hash power support or not. BIP9/ST requires this support, while BIP8 does not. Billy Tetrud pointed out factual errors in LukeJr's statements about BIP8 and agreed with Michael that the discussion should be kept separate from the BIPs themselves. Tetrud suggested that BIPs should only mention what types of activation methods are possible, without advocating for any specific method.Billy Tetrud thanked Eric Lombrozo for correcting the factual errors regarding BIP8 and ST activation methods in an email exchange. While characterizing BIP8 and ST as BIP9-based or not is subjective, the central issue remains whether activation requires majority hash power support or not. The conversation on activation methods should be separate from advocating for specific methods in BIPs to reduce noise in conversations.The Bitcoin-dev mailing list had a discussion about the legal definition of covenant, which led to Jeremy expressing annoyance. In response, aj proposed a more useful definition of covenant within the context of Bitcoin. According to aj, a covenant is when the scriptPubKey of an unspent transaction output (utxo) restricts the scriptPubKey in the outputs of a transaction that spends that utxo. aj clarified that CTV and TLUV have this type of restriction, while CSV and CLTV do not. They also mentioned that "checksig" could potentially be considered a covenant if the signature used in checksig is in the scriptPubKey. The discussion also covered several topics related to BIPs and their implementation, including the burden placed on full BIP implementation, the use of Eltoo-like protocols, implementing OP_CAT or OP_SHA256STREAM in Bitcoin, language cleanups, and the review of CTV BIP.In an email thread regarding the review of CTV BIP, Michael Folkson requested Eric and Luke to refrain from discussing activation methods for future soft forks on a thread for CTV BIP review. He explained that the discussion for Taproot activation was kept separate until there was overwhelming community consensus. Eric and Luke disagreed with Michael's statements about backward compatibility of unenforced soft forks and chain splits. They argued that soft forks do not produce a chain split themselves but can disrupt if miners cause a split. However, Michael maintained that without majority hash power enforcement, soft forks are not backward compatible. There was also a disagreement between Eric and Luke about the definition of backward compatibility and the use of BIP8 for Taproot activation.In another discussion on the Bitcoin-dev mailing list, Jeremy Rubin expressed skepticism about using BIPs for specific use cases for CTV. Alex suggested having explicit application notes to provide details on how CTV can be used in specific applications while making it clear that they are not part of CTV itself. Luke Dashjr provided a detailed review of the CTV BIP, expressing concerns about its readiness and suggesting alternative approaches for certain use cases.Jeremy Rubin thanked Luke Dashjr for his review of CTV and mentioned plans for language cleanups. While he agreed with the need for BIPs for specific use cases, he was skeptical about the overall approach and suggested reviewing application-focused posts and creating a BIP describing how to build something similar to Sapio to help users think through compiling to CTV contracts. Luke Dashjr disagreed with Rubin's viewpoint, stating that CTV is not yet ready and that BIP 9 has known flaws. He questioned why congestion-controlled transactions had not been considered and suggested using Speedy Trial instead of BIP 9 for future deployments. He also discussed limitations of CHECKTEMPLATEVERIFY and proposed alternatives.Luke Dashjr and Eric Voskuil had a discussion about the compatibility of soft forks with the Bitcoin consensus protocol. Dashjr argued that soft forks are not backward compatible without hash power enforcement, while Voskuil disagreed, stating that enforcement is by users, not miners. There was a disagreement about BIP8 achieving consensus for Taproot activation, with Michael Folkson calling it a misleading statement and accusing Eric of deception.The email thread discussed the review of CTV, focusing on technical aspects. The author emphasized that personal or legal attacks on developers would not sway their opinion. They agreed with some nitpicks mentioned in the email and expressed a desire to see fully implemented BIPs before activation. They strongly opposed using BIP9, believing it to be flawed and representing an attempt to impose developer will over community consensus. The author suggested directing other technical comments to Jeremy or someone else as their research was ongoing. The email ended with the author's contact information.Eric at voskuil.org stated that the only significant difference between BIP9 and BIP8 is whether activation requires majority hash power support or not.
Updated on: 2023-08-02T05:24:26.222299+00:00