This week’s newsletter summarizes discussion about activating OP_CHECKTEMPLATEVERIFY and includes our regular sections highlighting top questions and answers on the Bitcoin Stack Exchange, new software releases and release candidates, and recent changes to popular Bitcoin infrastructure software.

News

  • ● Discussion about activating CTV: Jeremy Rubin posted to the Bitcoin-Dev mailing list his plan to release software that will allow miners to begin signaling whether they intend to enforce the BIP119 rules for the proposed OP_CHECKTEMPLATEVERIFY (CTV) opcode. If 90% of blocks signal positively during any of the next several 2,016-block (two-week) retarget periods, anyone using Rubin’s software will themselves begin enforcing CTV’s rules starting around early November.

    Rubin described in detail multiple reasons for believing Bitcoin users may wish to activate CTV now, such as:

    • ● Consistency: CTV has a stable specification and implementation

    • ● Popularity: a number of people and organizations who are well known to the Bitcoin community support CTV

    • ● Viability: there do not appear to be any objections claiming that CTV violates any highly desired properties of Bitcoin

    • ● Desirability: CTV provides features users want, such as covenant-based vaults

    Over a dozen people replied on the mailing list, either directly to Rubin’s email or in other threads. We’re unable to summarize all the noteworthy replies, but some of the comments we found particularly interesting included:

    • ● Anthony Towns analyzed transactions on the CTV signet. Almost all looked like they may have been constructed with the same software (Sapio), possibly indicating a lack of public exploration of CTV. He further noted that changing the consensus rules to add a new feature creates risks for all Bitcoin users—even for people who don’t plan to use the new feature—so it’s important to provide the non-adopters with public evidence that the feature will be “valuable enough to others [to justify] the risk”. Subsequent to this post, additional experimentation was performed on the CTV signet.

    • ● Matt Corallo also argued that changing consensus creates significant costs for everyone, so we should only attempt soft forks when we’re sure a proposal provides the maximum value available from a change. In the case of covenants, Corallo wants to see “the most flexible and useful and hopefully private” design. He later said, “from what I have seen it’s not been clear that CTV is really a good option”.

    • ● Russell O’Connor noted on #bitcoin-wizards IRC that one of the proposed ways of using CTV could not be communicated in an existing Bitcoin address format such as base58check, bech32, or bech32m. That method of using CTV via bare script (a script that appears directly in a scriptPubKey) would require wallet developers only use bare CTV with their own internal transactions or write special tools to communicate the information usually contained in an address. Alternatively, wallets wanting to use CTV for some applications (such as vaults) could receive payments to a P2TR address which committed to later using bare CTV.

      O’Connor’s discussion about the address limitation was mentioned on the list by Towns. O’Connor replied with additional details and also noted that, if support for bare CTV wasn’t part of the BIP119 specification of CTV, he’d advocate for a different design that would be simpler and more composable (easier to combine with other opcodes to produce useful scripts)—although, beyond that, he’d prefer the more general OP_TXHASH design (see Newsletter #185). Rubin replied with several counterpoints.

    • ● David Harding relayed a concern that CTV might not receive much long-term use, either because uses for it wouldn’t manifest or because other covenant constructions would better serve popular uses. This would leave future consensus code developers with the perpetual burden of maintaining CTV code and analyzing its potential interactions with later proposed consensus changes. Harding suggested temporarily adding CTV to Bitcoin for five years, gathering data during that time about how people used it, and then automatically disabling it unless Bitcoin users five years from now decided it was worth keeping. No respondents were in favor of this approach, with most of them arguing either that the costs of this approach were too high or the benefits too low. It was also noted that anyone in the future who wanted to fully validate the blocks created while CTV was active would still need the CTV validation code, so the CTV code might need to be maintained in perpetuity even if the opcode was disabled after five years.

    • ● Antoine “Darosior” Poinsot requested feedback about activating a slightly modified version of BIP118 SIGHASH_ANYPREVOUT (APO) instead of CTV, or at least prior to CTV activation. The modification to APO would allow it to emulate the capabilities of CTV, although at a higher cost for some applications. Activating APO would also make it available for its originally envisioned use of enabling the proposed Eltoo layer for LN, allowing for more efficient and arguably safer LN channel state updates.

    • ● James O’Beirne suggested that his CTV-based simple vault design could be used as a benchmark for evaluating different covenant designs because of its simplicity and its ability, in his estimation, to significantly enhance the security of many Bitcoin users if it was usable in production. Darosior was the first to accept the challenge, porting the simple vault code from CTV to an implementation of SIGHASH_ANYPREVOUT.

    Discussion remained very active on the mailing list at the time this summary was being written. Several interesting conversations about CTV and covenant technology also appeared on Twitter, IRC, Telegram chats, and elsewhere. We encourage participants in those conversations to share any important insights with the Bitcoin-Dev mailing list.

    Subsequent to the discussions summarized above, Jeremy Rubin announced that he will not be immediately releasing binary builds of the software for allowing activation of CTV. He will instead be evaluating the feedback received and working with other CTV supporters to possibly propose a revised activation plan. Optech will provide updates on the subject in future newsletters.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

  • ● Bitcoin Core 23.0 is the next major version of this predominant full node software. The release notes list multiple improvements, including descriptor wallets by default for new wallets and descriptor wallets now easily support receiving to bech32m addresses using taproot.

  • ● Core Lightning 0.11.0 is a release of the next major version of this popular LN node software. Among other features and bug fixes, the new version supports multiple active channels to the same peer and paying stateless invoices.

  • ● Rust-Bitcoin 0.28 is the latest release of this Bitcoin library. The most significant change is adding support for taproot and improving related APIs, such as those for PSBTs. Other improvements and bug fixes are described in their release notes.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • ● LND #5157 adds an --addpeer startup option which opens a peer connection with the provided node.

  • ● LND #6414 begins advertising support for keysend spontaneous payments when enabled. LND has supported keysend since 2019 but it was initially deployed with no way for nodes to advertise they supported it. Implementations of keysend in other LN node software announced support in their node advertisements and this merged PR for LND replicates that.