This week’s newsletter summarizes a proposal to implement breaking changes in the DLC specification, examines options for allowing recovery of closed LN channels using just a BIP32 seed, and describes an idea to generate stateless LN invoices. Also included are our regular sections with popular questions and answers from the Bitcoin Stack Exchange, ideas for preparing for taproot’s activation, and descriptions of notable changes to popular Bitcoin infrastructure software.

News

  • ● Discussion about DLC specification breaking changes: Nadav Kohen posted to the DLC-dev mailing list about updating the DLC specification with several changes that could break compatibility with existing applications. He presented two options: updating the specification as needed and letting applications advertise what version they implement, or batching together several breaking changes in order to minimize the number of disruptions. Feedback was requested from developers working on DLC software.

  • ● Challenges recovering LN close transactions using only a seed: Electrum Wallet developer ghost43 posted to the Lightning-Dev mailing list about some of the challenges of scanning the block chain for a wallet’s channel close transactions. A specific problem is dealing with the new anchor outputs protocol when recovering a wallet using only BIP32-style HD key generation. Several possible schemes were analyzed by ghost43 and a scheme currently used by Eclair is recommended as the best currently possible. A further improvement is suggested if implementations are willing to slightly modify the channel opening protocol.

  • ● Stateless LN invoice generation: Joost Jager posted to the Lightning-Dev mailing list about a possible denial of service attack against applications generating LN invoices for unauthenticated users. Specifically, an attacker could request an unbounded number of invoices, which the generating service would need to store until they expired. Jager suggested instead that, for small invoices not requiring much data, the service could generate the invoice and immediately forget about it, instead giving the requesting user the invoice parameters. Those parameters would be submitted with the payment, allowing the service to reconstruct the invoice, accept the payment, and fulfill the order.

    Although some respondents expressed concern that the idea was unnecessary—it’s possible to flood apps with requests in other ways, and any solution to those problems should also fix invoice request flooding—others thought the idea was useful. The idea does not seem to require any protocol changes, just software changes (or plugins) to create and manage the invoice generation and reconstruction.

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.

Preparing for taproot #15: signmessage protocol still needed

A weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.

Since the activation of segwit over four years ago, there’s been no widely accepted way to create signed text messages for bech32 or bech32m addresses. Arguably, that means we can now assume that widespread message signing support must not be very important to users or developers, otherwise more work would’ve been dedicated to it. But it still feels like Bitcoin wallet software has regressed since the days when everyone used legacy addresses and could easily trade signed messages.

The generic signmessage solution we wrote about two years ago in our bech32 spending support series has floundered, not even being adopted by Bitcoin Core despite occasional updates of its protocol documentation, BIP322 (see Newsletters #118 and #130). Despite that, we’re unaware of any better alternative, and so BIP322 should still be the preferred choice of any developer who wants to add signmessage support to their P2TR wallet.

If implemented, generic signmessage will allow signing messages for P2TR outputs that are truly single-sig, which use multisignatures, or which use any tapscript. It will also provide backwards compatibility with all legacy and bech32 addresses as well as forward compatibility with the types of changes currently envisioned for the near future (some of which we’ll preview in a future preparing for taproot column). Applications with access to the full UTXO set (e.g. via a full node) can also use BIP322 to generate and validate reserve proofs, providing evidence that the signer controlled a certain amount of bitcoin at a certain time.

It should be very easy to implement support for creating generic signed messages. BIP322 uses a technique called virtual transactions. A first virtual transaction is created to be deliberately invalid by attempting to spend from a non-existent previous transaction (one whose txid is all zeroes). This first transaction pays the address (script) the user wants to sign for and contains a hash commitment to the desired message. A second transaction spends the output of the first transaction—if the signatures and other data for that spend could be a valid transaction, then the message is considered signed (although the second virtual transaction still can’t be included onchain because it spends from an invalid previous transaction).

Verifying generic signed messages is harder for many wallets. To be able to fully verify any BIP322 message requires implementing essentially all of Bitcoin’s consensus rules. Most wallets don’t do that, so BIP322 allows them to return an “inconclusive” state when they can’t fully verify a script. In practice, and especially with taproot’s encouragement of keypath spends, that may be rare. Any wallet that implements just a few of the most popular script types will be able to verify signed messages for over 99% of all UTXOs.

Generic signmessage support would be a useful addition to Bitcoin. Although we can’t ignore the lack of attention paid to it in the past several years, we do encourage wallet developers reading this to consider adding experimental support for it to your programs. It’s an easy way to give users back a feature they’ve been missing for several years now. If you are either a developer working on BIP322 or related reserve proof implementation or a service provider that would find such features useful, feel free to reach out to info@bitcoinops.org to coordinate efforts.

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 0.21.2 is a release for a maintenance version of Bitcoin Core. It contains several bug fixes and small improvements.

Notable code and documentation changes

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

  • ● Bitcoin Core #12677 adds ancestorcount, ancestorsize and ancestorfees fields to the transaction outputs returned by the wallet’s listunspent RPC method. If the transaction creating the transaction output is unconfirmed, those fields will indicate the total count, size and fees of the transaction and all its unconfirmed ancestors in the mempool. Miners select transactions for inclusion in a block based on their ancestor feerate, so knowing the ancestor size and fees are useful for users estimating the confirmation time for the transaction or attempting to bump the transaction’s fee using CPFP or RBF.

  • ● Eclair #1942 enables the path finding algorithm to be configured such that routes are evaluated partially based on their capacity. This configuration can be applied as an experimental parameter set to potentially improve routing success rates. [Edit: this item was corrected after publication; we thank Thomas Huet for reporting the inaccuracy.]

  • ● LND #5101 adds a middleware interceptor which receives each RPC request on its way to the server and can make modifications. This allows implementing logic outside of LND that can track or affect a large variety of user and automated actions. For security, only RPCs that explicitly use authentication tokens (macaroons) that opt-in to interception can be intercepted.