This week’s newsletter describes a proposal to allow multiple derivation paths in a single output script descriptor and includes our regular section with summaries of notable changes to popular Bitcoin infrastructure projects.

News

  • ● Multiple derivation path descriptors: Andrew Chow posted a proposed BIP to the Bitcoin-Dev mailing list for allowing a single descriptor to specify two related BIP32 paths for HD key generation. The first path would be for generating addresses to which incoming payments could be received. The second address would be for internal payments within the wallet, namely returning change back to the wallet after spending a UTXO.

    As specified in BIP32, most wallets use separate paths for generating external versus internal addresses in order to enhance privacy. An external path used for receiving payments might be shared with less-trusted devices, e.g. uploading it to a webserver to receive payments. The internal path used only for change might only be needed at times when the private key is also needed, so it could receive the same security. If the example webserver were compromised and the external addresses were leaked, the attacker would learn about each time the user received money, how much they received, and when they initially spent the money—but they wouldn’t necessarily learn how much money was sent in the initial spend, and they also might not learn about any spends that entirely consisted of spending change.

    Replies from Pavol Rusnak and Craig Raw indicated that Trezor Wallet and Sparrow Wallet already supported the scheme Chow proposed. Rusnak also asked whether a single descriptor should be able to describe more than two related paths. Dmitry Petukhov noted that only internal and external paths are widely used today and that any additional paths wouldn’t have a clear meaning to existing wallets. That could create interoperability issues. He suggested limiting the BIP to just two paths and waiting for anyone needing additional paths to write their own BIP.

Notable code and documentation changes

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

  • ● Core Lightning #5441 updates hsmtool to make it easier to check a BIP39 passphrase against the HD seed used by CLN’s internal wallet.

  • ● Eclair #2253 adds support for relaying blinded payments as specified in BOLTs #765 (see Newsletter #187).

  • ● LDK #1519 always includes the htlc_maximum_msat field in channel_update messages as will be required if BOLTs #996 is merged into the LN specification. The reason given in the pull request for the change is to simplify message parsing.

  • ● Rust Bitcoin #994 adds a LockTime type that can be used with nLockTime and BIP65 OP_CHECKLOCKTIME fields. Locktime fields in Bitcoin can contain either a block height or a Unix epoch time value.

  • ● Rust Bitcoin #1088 adds the structures needed for compact blocks as specified in BIP152, as well as a method for creating a compact block from a regular block. Compact blocks allow a node to tell its peers which transactions a block contains without sending complete copies of those transactions. If a peer has previously received and stored those transactions from when they were unconfirmed, it doesn’t need to download them again, saving bandwidth and speeding up the relay of new blocks.