Author: Billy Tetrud 2022-01-20 15:23:09
Published on: 2022-01-20T15:23:09+00:00
The discussion in the Bitcoin-dev mailing list revolves around several topics related to BIPs and their implementation. The first topic is about the burden placed on a BIP for its full implementation, which is considered more than necessary. The second topic is about the use of an Eltoo-like protocol, which may be a problem unless it's an eltoo-like protocol. The third topic discusses the possibility of implementing OP_CAT or OP_SHA256STREAM in Bitcoin and how that would affect the use of CTV to create covenant chains with a finite number of steps. The fourth topic is about the language cleanups and the legal definition of covenant. It is suggested that child covenants or inherited covenants should be specified, as opposed to legal or dictionary definitions, since this is a unique context within Bitcoin.The fifth topic is about the discussion of activation methods for future soft forks and how it should be kept separate from the review of CTV BIP. It is suggested that BIPs should not advocate for any particular activation method but only mention what types of activation methods are possible. This separation of concerns would help reduce noise in conversations. Michael Folkson requests Eric and Luke not to discuss activation methods for soft forks on a thread for CTV BIP review because standalone OP_CTV is not the only current soft fork proposal, and there will likely be more. The discussion on activation methods for Taproot was deliberately kept separate from the review of Taproot BIPs and implementation until there was overwhelming community consensus for the soft fork to be activated.Finally, there is a discussion about the use of BIP8 for Taproot activation. It is pointed out that BIP8 achieved consensus for Taproot activation despite not gaining sufficient support. However, it is also noted that ST was some technical tweaks to BIP9 and not a full implementation of BIP8. There is a disagreement between Eric Voskuil and Luke Dashjr on the definition of backward compatibility and whether soft forks produce a chain split. Eric argues that without "hash power enforcement", soft forks are not backward compatible, and they result in chain splits. Michael suggests that discussing activation methods for soft forks on a thread for CTV BIP review might give the mistaken impression that OP_CTV is the next soft fork to be activated, which is mere speculation at this point.
Updated on: 2023-06-15T15:19:22.217635+00:00