This week’s newsletter links to a discussion of updates to BIP322’s generic signed message format and describes an idea to use TCP hole punching to help Bitcoin nodes behind NATs accept inbound connections. Also included are our regular sections describing recent changes to services and client software and summarizing notable changes to popular Bitcoin infrastructure software.

News

  • ● Significant updates to BIP322: Generic Signed Message Format: Oliver Gugger posted to the Bitcoin-Dev mailing list about his ideas on how to round out BIP322. As Gugger had been implementing support in btcd, he had noticed several open questions and gaps in the proposal. He proposed three major amendments to the proposal:

    • Human-readable prefixes to distinguish the three signature variants.

    • Inclusion of UTXO information in the “Proof of Funds” variant.

    • Support for PSBT-based message signing.

    After some discussion and incorporating feedback on the PSBT construction, the update to BIP322 was published (see Newsletter #405). Gugger advanced BIP322 to Complete, indicating the specification is now considered stable and ready for implementation. Since the update, it resurfaced that Coldcard had shipped support for BIP322 in March.

    Projects that previously implemented support for earlier versions of BIP322 should review their compatibility with the updated specification, which introduced breaking changes including a new human-readable prefix and a revised proof of funds signature format.

  • ● TCP hole punching for Bitcoin nodes behind NATs: 0xB10C posted to Delving Bitcoin about an idea to make more nodes behind a home router NAT accept inbound connections. The initial concept comes from the observation that setting -natpmp=1 by default starting from Bitcoin Core v30.0 did not increase the number of reachable nodes in residential ISPs as expected.

    The idea leverages hole punching, a technique that allows two hosts behind certain types of NATs to connect directly, without relaying traffic through a server. The process works like this: two unreachable hosts, Alice and Bob, exchange their public endpoints (i.e. IP address and port) through a third party and simultaneously initiate a connection to each other. This creates a mapping in the NATs, allowing the hosts to complete the handshake and establish a connection. Since the proposed technique works on TCP, which requires precise synchronization between nodes, it produces higher failure rates compared to a similar technique using UDP.

    0xB10C mentioned multiple approaches for an implementation using Bitcoin’s P2P protocol. A first set requires a bridge, referred to as a rendezvous server, to allow Alice and Bob to exchange endpoint information. The server could either provide a matchmaking service, to allow unreachable hosts to offer their connection slots, or it could decide to hand off one of its existing connections to another peer instead of evicting it due to a lack of free inbound slots. He also described a way to perform hole punching directly under Tor/I2P, bypassing the need for a third-party server to establish the connection. In this approach, Alice would start listening on a dedicated Tor/I2P endpoint, to which Bob would connect and start the hole-punching process.

    The proposal has not been formalized yet, and many questions remain unanswered. 0xB10C asked for community feedback and invited discussion to address many open points, such as how to classify hole-punch connections, reliability of TCP hole punching, possible attacks, and implementation efforts.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

  • ● Ibis Wallet announced: Ibis Wallet is an Android wallet built on BDK supporting coin control, RBF and CPFP fee management, multisig, hardware signing device integration using QR codes, silent payments, and Tor integration. It also supports optional second layers, including Spark, Liquid, and, in the future, Ark.

  • ● LDK Server announced: Spiral announced LDK Server, an API-first Lightning node daemon built on LDK Node for payment processors and wallet providers. It provides a gRPC interface, an embedded BDK-based wallet, and a Model Context Protocol (MCP) server for AI-agent interactions with the node.

  • ● Mempool.space v3.3.0 released: Mempool v3.3.0 adds taproot script tree visualizations, updated PSBT previews, improvements to fee estimation, ephemeral dust support, stale block comparisons, sighash icons, and a merkle-proof API, among other features.

  • ● peer-observer P2P monitoring tooling: 0xB10C outlined some open-source components used by his peer-observer platform, including infrastructure for extracting events from Bitcoin Core nodes using IPC, logs, P2P, and RPC sources. He also describes ongoing development around archiving, anomaly detection, and alerting tools.

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 #29136 adds an addhdkey RPC that imports a specified BIP32 extended private key, or generates one if none is specified, without using it to produce any output scripts. This allows a wallet to store a signing key for future use (e.g. for a multisig script), without immediately generating addresses from it. The PR also adds a new unused(KEY) descriptor type, which is returned by listdescriptors, so the stored key can be included in wallet backups.

  • ● Bitcoin Core #34893 updates the combinepsbt RPC to preserve BIP174 proprietary fields (see Newsletters #72 and #181) when combining PSBTs. Previously, combinepsbt would silently drop the proprietary fields, resulting in the loss of application-specific PSBT metadata. The decodepsbt RPC already parses, serializes, and displays those fields properly.

  • ● Bitcoin Core #34860 removes the include_dummy_extranonce option from the CreateNewBlock() method (see Newsletter #392). Bitcoin Core now always appends dummy padding to the internal coinbase scriptSig when creating blocks at heights 0 through 16, where the BIP34 height encoding alone is too short to satisfy the consensus minimum scriptSig length. However, the padding is not included in the scriptSigPrefix field of the CoinbaseTx struct exposed to Stratum V2 clients connected through the Mining IPC interface (see Newsletter #310 and #388).

  • ● Bitcoin Core #31298 updates the combinerawtransaction RPC to reject unrelated transactions, instead of silently returning the first one and not reporting that they could not be merged. Bitcoin Core now strips input scriptSigs and witnesses from each transaction, compares the resulting unsigned transaction hashes, and returns an error if they do not match.

  • ● Bitcoin Core #28802 adds support for command-specific options to ArgsManager, Bitcoin Core’s CLI argument parser. Commands can now declare which options apply to them, allowing ArgsManager to list those options under the relevant command’s help output and automatically reject invalid command-option combinations. The PR applies this to bitcoin-wallet’s (see Newsletter #32) -dumpfile option, which is now registered only for the dump and createfromdump commands.

  • ● Eclair #3298 updates its internal RBF logic to follow the new BOLT2 feerate bump rule, which is designed to ensure compliance with BIP125’s replacement rules at low feerates. Instead of only applying the previous 25/24 feerate multiplier, Eclair now uses whichever is larger: that multiplier or an additional 25 sat/kw. This matches the LDK behavior covered in Newsletter #400 and the BOLT specification update covered in Newsletter #404.

  • ● LDK #4575 adds a splice_in_inputs API that allows users to manually select UTXOs when splicing funds into a channel. The selected UTXOs are fully consumed, with their value minus fees added to the channel, and no change output is created. This complements the existing amount-based splice-in flow, in which the caller specifies the amount to be added and the wallet selects the inputs. However, the two input selection flows cannot be mixed in the same funding contribution.

  • ● LND #10814 removes the deprecated SendPayment, SendPaymentSync, SendToRoute, SendToRouteSync, and TrackPayment endpoints, which were scheduled for removal in version 0.21 (see Newsletter #340). Callers should use the V2 replacements: SendPaymentV2, SendToRouteV2, and TrackPaymentV2. The PR also removes the deprecated single-channel outgoing_chan_id field, requiring callers to use the multi-channel outgoing_chan_ids field (see Newsletter #33).

  • ● Rust Bitcoin #6191 adds support for encoding and decoding the sendtxrcncl P2P message used for Erlay transaction reconciliation. Bitcoin Core added support for this message as an early part of Erlay support (see Newsletter #223). However, full Erlay transaction reconciliation is not yet implemented.

  • ● BLIPs #42 adds BLIP42, a specification for BOLT12 contacts. Since BOLT12 offers can be reused as static Lightning payment instructions, wallets can store offers as contacts. The BLIP defines optional invoice_request fields that payers can include when making outgoing payments to a contact, such as a contact secret, their own offer, or a BIP353 name. This allows recipients to recognize payments from known contacts, add new contacts, and send funds back to the payer without additional interaction.

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 May 26. The discussion is also recorded and will be available from our podcasts page.