This week’s newsletter summarizes a proposed BIP for BIP32-based path templates and includes our regular sections with the summary of a Bitcoin Core PR Review Club meeting, releases and release candidates, and notable changes to popular Bitcoin infrastructure software.

Action items

None this week.

News

  • ● Proposed BIP for BIP32 path templates: Dmitry Petukhov posted a proposed BIP to the Bitcoin-Dev mailing list, suggesting a standardized format for describing what BIP32 key derivation paths a wallet should support. Many wallets today limit their users to certain paths, such as those described by BIP44 and related BIPs, refusing to allow the use of alternative paths or making such use difficult. This limitation has the advantage that the user can just reinstall a software wallet or buy a compatible hardware wallet, enter their seed or seed phrase, and recover any funds using the wallet’s default path. But hardcoding particular paths also constrains wallets to only the use cases envisioned by their own developers, rather than allowing the wallets to be used for other purposes or protocols. Path templates provide a compact way for the user to describe to the wallet what paths they want to use. The compactness of path templates makes it easy to back up the template along with the seed, helping prevent users from losing funds. An additional feature of the proposed path templates is the ability to describe derivation limits (e.g. that a wallet should derive no more than 50,000 keys in a particular path), which can make it practical for a recovery procedure to scan for bitcoins received to all possible wallet keys, eliminating concerns about gap limits in HD wallets (see Newsletter #52).

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Cache responses to getaddr to prevent topology leaks is a PR by Gleb Naumenko that aims to make it more difficult for spy nodes to infer the P2P network topology using addr message gossiping.

The discussion began by covering the basic concepts of address gossiping, and later focused on what privacy leaks are currently possible and what the PR intends to change.

  • What is the importance of addr relay and specifically the getaddr/addr protocol?

    addr relay is used for nodes to find new potential peers on the P2P network. ➚

  • Which properties of addr relay are important?

    Nodes need to learn about a diverse set of peers with good uptime that were online recently. ➚

  • How can a spy use addr messages to infer network topology?

    There are potentially multiple ways to infer topology from addr messages, but the most-discussed method was scraping nodes’ address managers (addrman) to determine how an address record is spread across the network and whether any nodes have a unique timestamp for that address record (indicating that they’re probably directly connected to that address). This is the method that was used in the Coinscope paper. ➚

  • What could a malicious actor do if they were able to map the entire P2P topology?

    Knowing the entire P2P network topology makes it easier to carry out attacks such as network partitions or eclipse attacks. ➚

  • Is it a problem if nodes cache responses to getaddr messages and serve records that are old?

    Opinions differ. Some people think there isn’t much churn on the P2P network, so old records are usually still valid; others aren’t sure. 

  • Does this PR prevent the unique-timestamp topology inference?

    No. This PR makes it more difficult to scrape a node’s address manager (addrman) but does not change the timestamps on relayed address records. A future PR could make additional changes to address the unique-timestamp inference. ➚

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.4.1 this new release adds support for option_static_remotekey (though disabled by default), which can simplify backups (see Newsletter #67). The release also enables sending multipath payments (MPP) by default, uses a new MPP splitting algorithm, offers beta support for using the PostgreSQL database, and better manages feerate mismatches between your node and your peers—all changes described in more detail below in the Notable Changes section of this newsletter.

  • ● LND 0.10.2-beta.rc4: this LND maintenance release is now available. It includes several bug fixes, including an important fix related to the creation of backups.

  • ● LND 0.10.3-beta.rc1: this release, separate from the 0.10.2 release, includes a package refactoring in addition to the bug fixes provided in 0.10.2. For details, see a mailing list post by LND developer Olaoluwa Osuntokun.

Notable code and documentation changes

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

  • ● Bitcoin Core #19204 eliminates a source of wasted bandwidth during Initial Block Download (IBD). When Bitcoin Core is in IBD, it often doesn’t have the necessary information to validate currently unconfirmed transactions, so it ignores relayed transaction announcements. However, those announcements still consume the bandwidth of the receiving IBD node and its sending peers. This PR uses the BIP133 feefilter P2P message to tell peers that the node doesn’t want to receive announcements of any transactions that pay less than 21 million BTC in fees per 1,000 vbytes, which should prevent it from receiving any legitimate transaction announcements. When the node finishes catching up to the tip of the best block chain, it sends another feefilter message with its actual minimum relay feerate so that it can start to receive newly-announced transactions.

  • ● Bitcoin Core #19215 creates PSBTs containing each previous transaction that created one of the UTXOs being spent in the current transaction—even for segwit v0 UTXOs. Before this change, previous transactions were only included for legacy (non-segwit) UTXOs. This change is a response to some hardware wallets now requiring or recommending access to previous transactions for segwit UTXOs in order to mitigate the fee overpayment attack. If segwit v1 (taproot) is adopted, transactions spending all taproot inputs should not need this extra data by default.

  • ● C-Lightning #3775 adds four RPC methods for PSBT lifecycle management backed by C-Lightning’s internal wallet. The reserveinputs RPC method creates a PSBT by choosing UTXOs from the internal wallet as inputs to satisfy the user-specified list of outputs, marking chosen UTXOs as reserved. The resulting PSBT may either be supplied to the unreserveinputs RPC method to manually release the reserved UTXOs, or to the signpsbt RPC method to add signatures from the internal wallet. Finally, the sendpsbt RPC method will convert a fully signed PSBT into a ready-to-broadcast transaction and then broadcast it to the network. Users should note that restarting C-Lightning effectively un-reserves all previously reserved UTXOs, requiring a new PSBT be created with reserveinputs before signpsbt will accept it.

  • ● Eclair #1427 and #1439 add support to Eclair for effective sending of multipath payments—payments which are split into several parts, with each part routed using a different path. These PRs split payments into up to six parts by default, initially allocating 0.00015 BTC to each part but increasing the value of each part by a semi-random amount until the full payment amount has been allocated. Once the amounts have all been selected, all of the payments parts are sent. This is not only efficient but also uses the opportunistic value-increasing function to help prevent any nodes that see a subset of the payments from guessing the full payment amount, improving privacy. If you’re interested in details, both Eclair’s and C-Lightning’s splitting algorithms were discussed by their authors this week.

  • ● Eclair #1249 adds optional support for using PostgreSQL as the database backend instead of the default SQLite. For details, see Eclair’s new PostgreSQL documentation. See also the report for Optech about using Eclair in a production environment with PostgreSQL, written by Roman Taranchenko—who is also the author of this PR.

  • ● Eclair #1473 updates Eclair’s code for handling a mismatch between the onchain feerate selected by a remote channel peer and the feerate the local node thinks is appropriate. After this change, if the remote peer selects a feerate that seems to be too high, the local node won’t close the channel unless it’s more than ten times the rate the local node thinks is appropriate. This is acceptable since the remote peer pays the fee and high fees should ensure the channel is quickly settled to the advantage of both peers. However, if the feerate is set to less than 50% the value the local node expects, it will close the channel immediately to ensure any pending payments (HTLCs) can be settled before feerates rise further. The PR also ensures channels aren’t closed due to fee issues when there aren’t any payments that need to be resolved.

  • ● LND #4167 allows spontaneous payments made using keysend (see Newsletter #94) to be inspected before they are settled or canceled—basically, this PR implements hold invoices for spontaneous payments. The PR description notes a possible use for this feature: “a keysend payment with an embedded order comes in. The payment is held and an external application checks that the paid amount is sufficient for the ordered goods. If not, the payment is canceled without the need to refund anything. If the amount is sufficient, the payment is settled and the order processed.”

  • ● HWI #351 upgrades the version of the btchip-python library it uses to interact with a Ledger hardware wallet. This new library version works around a bug in the latest version of the Bitcoin app for Ledger devices that produced incorrect signatures for transactions with multiple segwit inputs. Electrum has also updated its library dependency to fix the same issue. Both upgrades are part of the response to the fee overpayment attack.