This week’s newsletter describes possible solutions to node fingerprinting and links to discussion of using public fraud proofs to improve incentives around just-in-time channels. Also included are our regular sections describing notable changes to popular Bitcoin infrastructure software.

News

  • ● Possible solutions to node fingerprinting: Naiyoma posted to Delving Bitcoin about possible solutions to the node fingerprinting issue that uses the addr message timestamp to identify the same node on multiple networks (see Newsletter #360).

    Since the last update, researchers were able to gather more insights on the problem and identify new factors to consider. One of the key insights was related to the AddrMan, the code structure managing the addresses. AddrMan considers addresses as stale in case their timestamp is older than 30 days, usually due to a peer being offline. Thus, there are two important factors that a possible mitigation needs to take into account: refreshing old timestamps to newer ones may cause old addresses to be continuously gossiped and making them older may cause them to stop being gossiped prematurely. These considerations led to discarding some previously considered solutions and provide new ones:

    1. Simple fuzzing: Apply random distortion to the address timestamp in a range of [-5, +5] days. However, the distortion may average out over time.

    2. Fixed timestamps across networks: When responding to a request, the real timestamp is preserved for the specific network, while on the others the timestamps are set to a randomized value in the past. However, old addresses might remain in circulation longer than necessary.

    3. Fuzzing - Addresses only older: Make addresses only older, never newer, by applying a random distortion in the range [1, 10] days. However, addresses may reach the 30-days threshold too quickly.

    4. Fuzzing - Aging-biased timestamp noise: Apply a random distortion in the range [-1, +5] days, so as to make addresses mainly older, with only a small chance of becoming newer. However, old addresses might remain in circulation longer than necessary.

    5. Hybrid approach: The final option is to combine two of the previous approaches together.

    Naiyoma asked for feedback on her work to other developers interested, and shared her PR in which she is testing solution 2.

  • ● Public fraud proof for just-in-time channels: Thomas Voegtlin posted to Delving Bitcoin about a new proposal for improving the game theory behind just-in-time (JIT) channels by using public fraud proofs to demonstrate that an LSP is misbehaving.

    Alice negotiates a JIT channel opening with an LSP, Bob. When Alice needs to receive sats from Carol, she creates a preimage. Carol sends an HTLC to Bob. Alice discloses the preimage to Bob, expecting the LSP to broadcast the channel funding transaction. What happens if Bob claims the HTLC without opening the channel with Alice?

    Voegtlin proposes to use the chain as a public arbitration layer. Alice should publish the preimage using an OP_RETURN, so that disclosure can be verified by anyone and dated to a certain block height. On his side, Bob creates a UTXO commitment valid up to a number of blocks n. If he spends the same UTXOs in a transaction different from the one he committed to, does not broadcast the funding transaction, or tries to double-spend it, he would create a fraud proof, damaging his reputation as an LSP without requiring other clients to trust Alice.

    Voegtlin provided the full paper containing the in-depth explanation, and invited other developers to provide feedback on the proposal.

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 #33796 adds btck_check_transaction() to the libbitcoinkernel C API (see Newsletter #380) for running context-free, consensus-level checks on a transaction’s structure. This includes rejecting empty input or output lists, invalid coinbase scriptSig lengths, duplicate inputs, null prevouts in non-coinbase transactions, and output values outside the valid money range, without requiring chainstate, the UTXO set, or script verification.

  • ● Bitcoin Core #21283 implements BIP370 PSBTv2 support, while maintaining backwards compatibility with PSBTv0. PSBTv2 stores transaction construction data, such as version, locktime, inputs, outputs, and transaction modifiability, directly in PSBT fields, instead of requiring a complete unsigned transaction.

  • ● BIPs #2150 adds BIP451, a specification for a Dust UTXO Disposal Protocol, which defines a standard for wallets to safely dispose of unwanted dust UTXOs by spending them to a single zero-value OP_RETURN output, with the entire input value paid as transaction fees. The protocol includes privacy-preserving construction rules, such as per-address disposal of confirmed dust UTXOs, and ALL|ANYONECANPAY signatures that allow unrelated dust-disposal transactions found in the mempool to be batched through RBF.

  • ● Eclair #3144 updates simple taproot channels to use the official feature bit and enables them by default, without support yet for announcing those channels. Test vectors are added to align with the BOLTs specification and LND’s implementation (see Newsletter #401).

  • ● Eclair #2887 adds support for the official splicing protocol merged into the BOLTs specification (see Newsletter #398), while maintaining backwards compatibility with Eclair’s earlier experimental splicing implementation.

  • ● LDK #4592 starts checking if a node has sufficient reserves before opening new zero-fee commitment (0FC) channels by counting them as anchor channels. Previously, LDK’s reserve check only counted channels that used the older anchors_zero_fee_htlc_tx feature, allowing a node to open more 0FC channels than its wallet could safely fee bump during simultaneous force closes.

  • ● LND #9153 adds a source_pub_key field to the Route proto message to construct and deserialize routes from the perspective of a node other than the local node. If no source is provided, LND continues to use the local node as before.

  • ● Rust Bitcoin #5835 adds a constructor for V1MessageHeader that computes the four-byte payload checksum used in Bitcoin’s P2P message header. This simplifies constructing network messages by allowing callers to build the header for a serialized payload and command before sending the message over the network.

  • ● BOLTs #995 adds an extension BOLT for simple taproot channels, assigning feature bits 80/81. The specification defines a minimal taproot-based channel type that uses a P2TR funding output with MuSig2 key aggregation, taproot commitment and HTLC scripts, and new TLV fields for exchanging MuSig2 partial signatures and nonces during channel opening, commitment updates, cooperative closes, and reconnection. The nonce fields in revoke_and_ack and channel_reestablish are keyed by funding txid to support multiple active commitment transactions, such as during splicing. The extension intentionally excludes gossip changes, so announced taproot channels remain future work.

  • ● BOLTs #1228 specifies zero-fee commitment (0FC) channels and assigns feature bits 40/41. For this channel type, feerate_per_kw is set to 0, commitment and HTLC transactions use v3 transaction relay (TRUC), and mining fees are provided by child transactions using CPFP. Commitment transactions include a shared pay-to-anchor (P2A) output funded from trimmed outputs and rounded-down millisatoshis, capped at 240 sats, allowing the parent commitment transaction to pay no direct fee in most cases. The specification also limits the maximum number of HTLCs to 114 for this channel type due to TRUC’s 10 kvB transaction size limit.

  • ● BOLTs #1327 updates the RBF feerate bump rule to ensure compliance with BIP125 replacement rules at low feerates. Instead of applying only the existing 25/24 feerate multiplier, the specification now requires the replacement feerate to increase by the larger of two values: the multiplier or an additional 25 sat/kw. This matches the behavior of LDK covered in Newsletter #400.

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