This week’s newsletter summarizes research about fingerprinting full nodes using P2P protocol messages and seeks feedback about possibly removing support for H in BIP32 paths in the BIP380 specification of descriptors. Also included are our regular sections summarizing top questions and answers on the Bitcoin Stack Exchange, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

  • ● Fingerprinting nodes using addr messages: Daniela Brozzoni posted to Delving Bitcoin about research she conducted with developer Naiyoma into identifying the same node on multiple networks using the addr messages it sends. Nodes send P2P protocol addr (address) messages to their peers to advertise other potential nodes, allowing peers to find each other using a decentralized gossip system. However, Brozzoni and Naiyoma were able to fingerprint individual nodes using details from their specific address messages, allowing them to identify the same node running on multiple networks (such as IPv4 and Tor).

    The researchers suggest two possible mitigations: removing timestamps from address messages or, if the timestamps are kept, randomizing them slightly to make them less specific to particular nodes.

  • ● Does any software use H in descriptors? Ava Chow posted to the Bitcoin-Dev mailing list to ask whether any software generates descriptors using uppercase-H to indicate a hardened BIP32 key derivation step. If not, the BIP380 specification of output script descriptors may be modified to only allow lowercase-h and ' to be used to indicate hardening. Chow notes that, although BIP32 allows uppercase-H, the BIP380 specification previously included a test that forbids using uppercase-H and that Bitcoin Core currently does not accept uppercase-H.

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.

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 28.2 is a maintenance release for the previous release series of the predominant full node implementation. It contains multiple bug fixes.

Notable code and documentation changes

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

  • ● Bitcoin Core #31981 adds a checkBlock method to the inter-process communication (IPC) Mining interface (see Newsletter #310) that performs the same validity checks as the getblocktemplate RPC in proposal mode. This enables mining pools using Stratum v2 to validate block templates provided by miners via the faster IPC interface, rather than serialising up to 4 MB of JSON through RPC. The proof-of-work and merkle root checks can be disabled in the options.

  • ● Eclair #3109 extends its attributable failures support (see Newsletter #356) to trampoline payments. A trampoline node now decrypts and stores the part of the attribution payload intended for it and prepares the remaining blob for the next trampoline hop. This PR does not implement the relay of the attribution data for trampoline nodes, which is expected in a follow-up PR.

  • ● LND #9950 adds a new include_auth_proof flag to the DescribeGraph, GetNodeInfo and GetChanInfo RPCs and to their corresponding lncli commands. Including this flag returns the channel announcement signatures, allowing validation of channel details by third-party software.

  • ● LDK #3868 reduces the precision of the HTLC hold time for attributable failure (see Newsletter #349) payloads from 1-millisecond to 100-millisecond units, to mitigate timing-fingerprint leaks. This aligns LDK with the latest updates to the BOLTs #1044 draft.

  • ● LDK #3873 raises the delay for forgetting a Short Channel Identifier (SCID) after its funding output is spent from 12 to 144 blocks to allow for the propagation of a splice update. This is double the 72-block delay introduced in BOLTs #1270 that was implemented by Eclair (see Newsletter #359). This PR also implements additional changes to the splice_locked message exchange process.

  • ● Libsecp256k1 #1678 adds a secp256k1_objs CMake interface library that exposes all the library’s object files to allow parent projects, such as Bitcoin Core’s planned libbitcoinkernel, to link those objects directly into their own static libraries. This solves the problem of CMake lacking a native mechanism to link static libraries into another and spares downstream users from providing their own libsecp256k1 binary.

  • ● BIPs #1803 clarifies BIP380’s descriptor grammar by allowing all common hardened-path markers, while #1871, #1867, and #1866 refine BIP390’s MuSig2 descriptors by tightening key path rules, permitting repeated participant keys, and explicitly restricting multipath child derivations.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 16:30 UTC on July 1. The discussion is also recorded and will be available from our podcasts page.