This week’s newsletter describes how wallet fingerprinting can damage payjoin privacy and summarizes a proposal for a wallet backup metadata format. Also included are our regular sections summarizing proposals and discussion about changing Bitcoin’s consensus rules, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

  • ● Wallet fingerprinting risks for payjoin privacy: Armin Sabouri posted to Delving Bitcoin about how differences in payjoin implementations make it possible to fingerprint payjoin transactions and can damage payjoin’s privacy.

    Sabouri states that payjoin transactions should appear indistinguishable from standard single-party transactions. However, there can be artifacts of collaborative transactions:

    • Intra-transaction

      • Partition inputs and outputs by owner within a single transaction.

      • Differences in input encoding.

      • Inputs length in bytes.

    • Inter-transaction

      • Backward: Each input was created by a prior transaction that carries its own fingerprint.

      • Forward: Each output may be spent in a future transaction, revealing fingerprints.

    He then reviewed three payjoin implementations: Samourai, the PDK demo, and Cake Wallet (sending to Bull Bitcoin Mobile). In each of these examples, he finds a few discrepancies which make it possible to fingerprint these implementations. This includes but is not limited to:

    • Differences in encoded input signatures.

    • SIGHASH_ALL byte being included in one input but not the other.

    • Output value assignment.

    Sabouri concludes that while some of these wallet fingerprints are trivial to eliminate, others are intrinsic to a particular wallet’s design choice. Wallet developers should be aware of these potential privacy leaks when implementing payjoin into their wallets.

  • ● Draft BIP for a wallet backup metadata format: Pythcoiner posted to the Bitcoin-Dev mailing list about a new proposal for a common structure for wallet backup metadata. The draft BIP, available at BIPs #2130, specifies a standard way to store various type of metadata, such as account descriptors, keys, labels, PSBTs, and more, allowing compatibility between different wallet implementations and a simpler wallet migration and recovery processes. According to Pythcoiner, the ecosystem lacks a common specification and this proposal aims to fill this gap.

    From a technical perspective, the proposed format is a UTF-8 encoded text file containing a single valid JSON object representing the backup structure. The BIP lists all the different fields that could be included in the JSON object, specifies that each is optional, and notes that any wallet implementation should be free to ignore any metadata not deemed useful.

Changing consensus

A monthly section summarizing proposals and discussion about changing Bitcoin’s consensus rules.

  • ● Compact Isogeny PQC can replace HD wallets, key-tweaking, silent payments: Conduition wrote on Delving Bitcoin about his research into the suitability of Isogeny-Based Cryptography (IBC) as a post-quantum cryptosystem for Bitcoin. While the elliptic curve discrete logarithm problem (ECDLP) may be rendered insecure in a post-quantum world, there is nothing fundamentally broken about elliptic curve mathematics in general. Briefly, an Isogeny is a mapping from one elliptic curve to another. The cryptographic assumption of IBC is that it is difficult to compute the Isogeny between one elliptic curve of a specific type and another, while it is easy to produce an Isogeny and the curve it maps to from a base curve. Thus IBC secret keys are Isogenies and the public keys are the mapped curves.

    Like ECDLP secret and public keys, it is possible to compute new secret keys and public keys independently from the same salt (e.g. a BIP32 derivation step) and have the resulting secret keys correctly sign for the resulting public keys. Conduition refers to this as “rerandomization” and it fundamentally enables BIP32, BIP341, and BIP352 (with some additional cryptographic innovation, probably).

    To date, there are no signature aggregation protocols for IBC like there are in MuSig and FROST, and conduition issues a call to action for Bitcoin developers and cryptographers to research what may be possible.

    Keys and signatures in known IBC cryptosystems are about twice the size of keys in ECDLP-dependent cryptosystems. Much smaller than hash-based or lattice-based cryptosystems. Verification is costly even on desktop machines (on the order of 1 millisecond per verification), in the same ballpark as hash-based and lattice-based.

  • ● Varops budget and tapscript leaf 0xc2 (aka “Script Restoration”) are BIPs 440 and 441: Rusty Russell wrote on the Bitcoin-Dev mailing list that the first two BIPs of the Great Script Restoration (or Grand Script Renaissance) have been submitted for BIP numbering. They subsequently received BIP numbers 440 and 441 respectively. BIP440 enables the restoration of previously-disabled Script opcodes by building an accounting system for the cost of each operation that ensures the worst case block-level script validation cost cannot exceed the cost of validating a block containing the worst case number of signature operations. BIP441 describes the validation of a new tapscript version which restores the opcodes disabled by Satoshi in 2010.

  • ● SHRIMPS: 2.5 KB post-quantum signatures across multiple stateful devices: Jonas Nick writes on Delving Bitcoin about a new semi-stateful hash-based signature construction for post-quantum Bitcoin. SHRIMPS takes advantage of the fact that SPHINCS+ signature sizes scale with the maximum number of signatures for a given key which can be produced while retaining a given security level.

    Similar to the SHRINCS design, a SHRIMPS key consists of two keys hashed together. In this case, both keys are stateless SPHINCS+ keys, but with different parameter sets. The first key is only secure for a small number of signatures and intended to be used with first (or first few) signatures from each signing device the key is used with. The second key is secure for a much larger number of signatures (effectively unlimited in a Bitcoin context) and each device falls back to that key after some (potentially user chosen) number of signatures from that device. The result is that in the common Bitcoin use-case where any given key (of which many can be derived from a single seed) only signs a small handful of times, nearly all signatures can be < 2.5 KB while still having no effective limit on the total number of signatures if a key ends up being reused many times, at the cost of the later signatures being ~7.5 KB. SHRIMPS is semi-stateful in that no global state must be retained, but each signing device must record a few bits of state for each SHRIMPS key it signs with (as little as a single bit if only the first signature from each device-key tuple takes advantage of the small signature).

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 31.0rc2 is a release candidate for the next major version of the predominant full node implementation. A testing guide is available.

  • ● Core Lightning 26.04rc2 is the latest release candidate for the next major version of this popular LN node, continuing the splicing updates and bug fixes from earlier candidates.

  • ● BTCPay Server 2.3.7 is a minor release of this self-hosted payment solution that migrates the project to .NET 10, adds subscription and invoice checkout improvements, and several other enhancements and bug fixes. Plugin developers should follow the project’s .NET 10 migration guide when updating.

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 #32297 adds an -ipcconnect option to bitcoin-cli so it can connect to and control a bitcoin-node instance via inter-process communication (IPC) over a Unix socket instead of HTTP when Bitcoin Core is built with ENABLE_IPC and the node is started with -ipcbind (see Newsletters #320 and #369). Even when -ipcconnect is omitted, bitcoin-cli tries IPC first and falls back to HTTP if IPC is unavailable. This is part of the multiprocess separation project.

  • ● Bitcoin Core #34379 fixes a bug where calling the gethdkeys RPC (see Newsletter #297) with private=true failed if the wallet contained any descriptor for which it had some but not all of the private keys. Similar to the fix for listdescriptors (see Newsletter #389), this PR returns the available private keys. Calling gethdkeys private=true on a strictly watch-only wallet still fails.

  • ● Eclair #3269 adds automatic liquidity reclamation from idle channels. When the PeerScorer detects that a channel’s total payment volume in both directions falls below 5% of its capacity, it gradually lowers relay fees toward the configured minimum. If fees have been at the minimum for at least five days and volume still has not picked up, Eclair closes the channel when it is redundant with that peer. Channels are closed only if the node holds at least 25% of the funds and the local balance exceeds the existing localBalanceClosingThreshold setting.

  • ● LDK #4486 merges the rbf_channel endpoint into splice_channel as a single entry point for both new splices and fee bumping an in-flight splice. When a splice is already in progress, the FundingTemplate returned from splice_channel carries PriorContribution so users can RBF the splice without new coin selection. See Newsletter #397 for related splice RBF behavior.

  • ● LDK #4428 adds support for opening and accepting channels with zero channel reserve via a new create_channel_to_trusted_peer_0reserve method for trusted peers. Zero-reserve channels let the counterparty spend their full on-chain balance in the channel. This is enabled for both channels using anchor outputs and zero-fee commitment channels (see Newsletter #371).

  • ● LND #9982, #10650, and #10693 harden MuSig2 nonce handling on the wire for taproot channels: ChannelReestablish gains a LocalNonces field so peers can coordinate multiple nonces for splicing-related updates, lnwire validates MuSig2 public nonces at TLV decode for nonce-carrying messages, and LocalNoncesData decoding validates each nonce entry.

  • ● LND #10063 extends the RBF cooperative close flow to simple taproot channels using MuSig2. Wire messages carry taproot-specific nonce and partial-signature fields, and the closing state machine uses MuSig2 sessions with a just-in-time nonce pattern across shutdown, closing_complete, and closing_sig (see Newsletter #347 for background on the RBF cooperative close flow).

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