This week’s newsletter shares the announcement of a new legal defense fund for Bitcoin developers and summarizes some recent discussion about the proposed OP_CHECKTEMPLATEVERIFY soft fork. Also included are our regular sections with descriptions of some recent changes to services and client software, plus summaries of notable changes to popular Bitcoin infrastructure software.

News

  • ● OP_CHECKTEMPLATEVERIFY discussion: the proposed soft fork to add an OP_CHECKTEMPLATEVERIFY (CTV) opcode to Bitcoin was discussed this week both on the Bitcoin-Dev mailing list and in an IRC meeting.

    • ● Mailing list discussion: Peter Todd posted several concerns with the proposal, including that it doesn’t benefit nearly all Bitcoin users (as he claims previous feature-adding soft forks have done), that it may create new denial-of-service vectors, and that many of the proposed usecases for CTV are underspecified and (perhaps) too complicated to actually see widespread deployment.

      CTV author Jeremy Rubin referenced updated code and improved documentation that may address the concerns about DoS attacks. He also pointed to at least two wallets, one of them widely used, which plan to use at least one of the features CTV will provide. As of this writing, it’s unclear whether Rubin’s reply has substantially satisfied Peter Todd’s concerns.

    • ● IRC meeting: as announced in Newsletter #181, Rubin also hosted the first of a series of meetings to discuss CTV. The meeting log is available as is a summary provided by Rubin. Several participants in the meeting were clearly in favor of the proposal, but some others expressed technical skepticism at least partly along the same lines as Peter Todd’s earlier email. The next meeting is proposed to look closer at some applications for CTV, which may help investigate whether it does indeed provide a compelling usecase that will benefit a large number of Bitcoin users.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

  • ● Cash App adds Lightning support: Cash App has added support for sending payments using the Lightning Network.

  • ● LNP Node opens first mainnet channel: New Lightning Network node software LNP Node opened its first LN channel. LNP Node is written in Rust and supports LN as well as extensions to LN collectively named “Bifrost” that enable future LN upgrades and additional protocols on top of LN.

  • ● Samourai adds taproot support: Samourai v0.99.98 and Samourai Dojo v1.13.0 (via the bitcoinjs-lib library) support bech32m addresses for P2TR.

  • ● Block explorer Mempool v2.3.0 released: Mempool v2.3.0, and the mempool.space website added version and locktime data, a hex transaction broadcast feature, and a “tag for transactions that spend Taproot outputs” among other improvements.

Notable code and documentation changes

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

  • ● Eclair #2063 adds support for the new option_payment_metadata invoice field added to the LN protocol in BOLTs #912 (see Newsletter #182), allowing invoices created by Eclair to now include encrypted payment metadata. Spenders who understand the new field will include its payload in the payments they route through the network, allowing Eclair to decrypt the data and use it to reconstruct all the information necessary to accept the payment. In a future where all spenders support this feature, this will make it possible to use stateless invoices and run Eclair without storing any essential invoice details in its database until a payment is received, eliminating wasted storage and preventing invoice-creation denial-of-service attacks.

  • ● LDK #1013 adds support for creating and handling warning messages introduced in BOLTs #950 (see Newsletter #182).

  • ● LND #6006 drops the need for LND to be connected to a full node or a Neutrino lightweight client when all the user wants to do is sign transactions. This allows the signing part of LND to be effectively run on a computer that isn’t directly connected to the Internet.

  • ● Rust Bitcoin #590 makes an API-breaking change that simplifies using the same HD key material with both ECDSA signatures and schnorr signatures (note: applications should use different HD keypaths with different signature algorithms, see Newsletter #157). Rust Bitcoin #591 continues the work with non-breaking changes.

  • ● Rust Bitcoin #669 extends its PSBT code to add a data type for holding information about a partial signature (a signature that’s needed to make a transaction valid but which is not sufficient by itself). Previously, signatures were stored as just raw bytes, but the new data facilitates performing additional operations on the partial signature. The PR discussion includes some interesting comments about whether signers who don’t want to sign should put an empty byte vector (“nulldummy”) in the PSBT.