This week’s newsletter describes a proposed update to BIP322 generic message signing and links to a specification for LN trampoline routing. Also included are our regular sections with announcements of releases, release candidates, and notable changes to popular Bitcoin infrastructure software.

News

  • ● Proposed updates to generic signmessage: Andrew Poelstra posted a partial rewrite of the BIP322 generic message signing proposal. The rewrite mainly clarifies the signing and verification procedures, but it now also allows wallets that don’t implement a complete set of checks to return an “inconclusive” state for signatures that use scripts they don’t understand. For example, a developer who wants to quickly implement generic signmessage may choose to only implement signature verification for P2PKH, P2WPKH, and P2SH-P2WPKH scripts, which covers a large percentage of all current and historic outputs. For anything else, the wallet can return “inconclusive” and maybe direct the user to a more comprehensive verification tool.

  • ● Trampoline routing: Bastien Teinturier posted to the Lightning-Dev mailing list a new specification for trampoline routing that allows a spender to pay a receiver without calculating a route between their nodes. Instead, the spender routes their money to a nearby trampoline node that calculates the next part of the route—getting the money either to the receiver or to the next trampoline node. This is useful for spenders with lightweight LN clients that are often offline or otherwise unable to keep track of network gossip in order to calculate routes themselves.

    Teinturier notes that ACINQ has been running a single-bounce trampoline node for users of their Phoenix wallet. This provides the route-finding benefit but, as described in a blog post, it means ACINQ can see the destination of all its users’ payments. The solution to this problem is allowing routing nodes to advertise the ability to accept onion-wrapped trampoline routes where spender Alice sends her money first to one trampoline (e.g. ACINQ’s node), then possibly to other trampolines, and finally to the receiver node. This prevents any individual trampoline from learning the node identifier for both the spender and receiver. The proposed specification would provide a standardized way to achieve this.

    It’s Teinturier opinion that “the code changes are very reasonable as it reuses a lot of components that are already part of every lightning implementation and doesn’t introduce new assumptions.”

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.

  • ● Eclair 0.5.0 is a new major version that adds support for a scalable cluster mode (see Newsletter #128), block chain watchdogs (Newsletter #123), and additional plugin hooks, among many other features and bug fixes.

  • ● Bitcoin Core 0.21.0rc5 is a release candidate for the next major version of this full node implementation and its associated wallet and other software. This latest RC has not yet been uploaded as of this writing, but we hope it will be available shortly after publication.

  • ● LND 0.12.0-beta.rc3 is the latest release candidate for the next major version of this LN node. It makes anchor outputs the default for commitment transactions and adds support for them in its watchtower implementation, reducing costs and increasing safety. The release also adds generic support for creating and signing PSBTs and includes several bug fixes.

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, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • ● Bitcoin Core #19137 adds dump and createfromdump commands to wallet-tool, allowing users to write wallet records to a dump file and subsequently restore a wallet from that dump file. These commands are useful not only for testing but as part of the migration away from legacy wallets.

  • ● Bitcoin Core #20365 updates the bitcoin-wallet tool’s create command with a -descriptors flag for creating sqlite-backed descriptor wallets, similar to the daemon’s createwallet RPC.

  • ● Bitcoin Core #20599 updates the message handling code to process sendheaders and sendcmpct messages received before the peer has sent its verack message. The BIPs for sendheaders (BIP130) and sendcmpct (BIP152) do not specify that those messages must be sent after the verack message, and the original implementations (Bitcoin Core #7129 and Bitcoin Core #8068) allowed the messages to be received and processed before the verack message. A later PR (Bitcoin Core #9720) prevented Bitcoin Core from processing those messages if they were received before the verack. This PR restores the original behavior.

  • ● Bitcoin Core #18772 updates the getblock RPC when used with the verbosity=2 parameter to return a new fee field containing the total fee for each transaction in the block. This depends on additional block undo data that nodes store in order to handle block chain reorganizations. Undo data is stored separately from other block transaction data and nodes with pruning enabled may delete undo data before deleting other data, so it’s possible for pruned nodes to sometimes return results without a fee field.

  • ● Bitcoin Core GUI #162 adds a new sortable Network column to the GUI Peers window and a new Network row to the peer details area. In both, the GUI displays to the user the type of network the peer is connected through: IPv4, IPv6, or Onion, with the ability to display two potential future additions, I2P and CJDNS. The PR also renames the NodeId and Node/Service column headers to Peer Id and Address.

  • ● C-Lightning #4207 adds extensive new documentation about backing up your node data.

  • ● Eclair #1639 enables BOLT3 option_static_remotekey by default, allowing Eclair to honor the request from a channel peer to always send payments to the same public key. This makes it easy for the remote peer to locate and spend those payments onchain even if it loses some channel state. The PR description indicates Eclair developers are enabling this option now because the 0.12.0-beta release of LND will make it mandatory.

  • ● Rust Bitcoin #499 adds support for two global PSBT fields specified after BIP174’s original publication:

    1. The extended public key field which enables change detection for signing wallets (see Newsletter #55)

    2. The version number field which helps identify backwards-incompatible changes to the PSBT spec (see Newsletter #72)

    This is one of the last changes in a larger effort detailed in #473 to bring Rust Bitcoin’s PSBT implementation up-to-date with current specifications.