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.
● 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
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 #20599 updates the message handling code to process
sendcmpctmessages received before the peer has sent its
verackmessage. The BIPs for
sendcmpct(BIP152) do not specify that those messages must be sent after the
verackmessage, and the original implementations (Bitcoin Core #7129 and Bitcoin Core #8068) allowed the messages to be received and processed before the
verackmessage. 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
getblockRPC when used with the
verbosity=2parameter to return a new
feefield 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
● 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.
● Eclair #1639 enables BOLT3
option_static_remotekeyby 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.
The extended public key field which enables change detection for signing wallets (see Newsletter #55)
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.