This week’s newsletter describes an idea for allowing mobile wallets to settle LN channels without extra UTXOs and summarizes continued discussion about adding a quality-of-service flag for LN pathfinding. Also included are our regular sections describing recent changes to clients, services, and popular Bitcoin infrastructure software.

News

  • ● Allowing mobile wallets to settle channels without extra UTXOs: Bastien Teinturier posted to Delving Bitcoin about an opt-in variation of v3 commitments for LN channels that would allow mobile wallets to settle channels using the funds within the channel for all cases where theft is possible. They wouldn’t need to keep an onchain UTXO in reserve to pay closing fees.

    Teinturier starts by outlining the four cases that require a mobile wallet to broadcast a transaction:

    1. Their peer broadcasts a revoked commitment transaction, e.g. the peer is attempting to steal funds. In this case, the mobile wallet immediately gains the ability to spend all of the channel’s funds, allowing it to use those funds to pay for fees.

    2. The mobile wallet has sent a payment that hasn’t been settled yet. Theft is impossible in this case, as their remote peer can only claim the payment by providing the HTLC preimage (i.e., proof that the ultimate recipient was paid). Since theft isn’t possible, the mobile wallet can take its time finding a UTXO to pay for closing fees.

    3. There are no pending payments but the remote peer is unresponsive. Again, theft isn’t possible here, so the mobile wallet can take its time closing.

    4. The mobile wallet is receiving an HTLC. In this case, the remote peer can accept the HTLC preimage (allowing it to claim funds from its upstream peers) but not update the settled channel balance and revoke the HTLC. In this case, the mobile wallet must force-close the channel within a relatively small number of blocks. This is the case addressed in the rest of the post.

    Teinturier proposes having the remote peer sign two different versions of each HTLC paying the mobile wallet: a zero-fee version according to the default policy for zero-fee commitments and a fee-paying version at feerate that will currently confirm quickly. The fees are deducted from the HTLC value paid to the mobile wallet, so it doesn’t cost the remote peer anything to offer this option and the mobile wallet has an incentive to only use it if really necessary. Teinturier does note that there are some safety considerations for the remote peer paying too much to fees, but he expects those to be easy to address.

  • ● Continued discussion about an LN quality of service flag: Joost Jager posted to Delving Bitcoin to continue discussion about adding a quality of service (QoS) flag to the LN protocol to allow nodes to signal that one of their channels was highly available (HA)—able to forward payments up to a specified amount with 100% reliability (see Newsletter #239). If a spender chooses an HA channel and the payment fails at that channel, then the spender will penalize the operator by never using that channel again. Since previous discussion, Jager has proposed node-level signaling (perhaps by simply appending “HA” to the node’s text alias), noted that the protocol’s current error messages don’t guarantee detection of the channel where a payment failed, and suggested that this isn’t something that can be both signaled and used on an entirely opt-in basis—so not requiring widespread agreement—so it should be specified for compatibility even if very few spending and forwarding nodes end up using it.

    Matt Corallo replied that LN pathfinding currently works well and linked to a detailed document describing LDK’s approach to pathfinding, which extends the approach originally described by René Pickhardt and Stefan Richter (see Newsletter #163 and two items in Newsletter #270). However, he’s concerned that a QoS flag will encourage future software to implement less reliable pathfinding and to simply prefer only using HA channels. In that case, large nodes can sign agreements with their large peers to temporarily use trust-based liquidity when a channel is depleted, but smaller nodes dependent on trustless channels will have to use expensive JIT rebalancing that will make their channels less profitable (if they absorb the cost) or less desirable (if they pass the cost on to spenders).

    Jager and Corallo continued discussing without coming to a clear resolution.

Changes to services and client software

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

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 #27432 introduces a Python script that converts the compact serialized UTXO set generated by the dumptxoutset RPC command (designed specifically for AssumeUTXO snapshots) into a SQLite3 database. While extending the dumptxoutset RPC itself to output a SQLite3 database was considered, it was ultimately rejected due to the increased maintenance burden. The script adds no additional dependencies and the resulting database is about twice the size of the compact serialized UTXO set.

  • ● Bitcoin Core #30529 fixes the handling of negated options such as noseednode, nobind, nowhitebind, norpcbind, norpcallowip, norpcwhitelist, notest, noasmap, norpcwallet, noonlynet, and noexternalip to behave as expected. Previously, negating these options caused confusing and undocumented side effects, but now it simply clears the specified settings to restore the default behaviour.

  • ● Bitcoin Core #31384 resolves an issue where the 4,000 weight units (WU) reserved for the block header, transaction count and coinbase transaction were inadvertently applied twice, reducing the maximum block template size by an unnecessary 4,000 WU to 3,992,000 WU (see Newsletter #336). This fix consolidates the reserved weight into a single instance and introduces a new -blockreservedweight startup option to allow users to customize the reserved weight. Safety checks are added to ensure that the reserved weight is set to a value between 2,000 WU and 4,000,000 WU, otherwise Bitcoin Core will fail to start.

  • ● Core Lightning #8059 implements suppression of multipath payments (MPP) on the xpay plugin (see Newsletter #330) when paying a BOLT11 invoice that doesn’t support this feature. The same logic will be extended to BOLT12 invoices, but will have to wait until the next release, as this PR also enables advertising BOLT12 features to plugins, explicitly allowing BOLT12 invoices to be paid with MPP.

  • ● Core Lightning #7985 adds support for paying BOLT12 invoices in the renepay plugin (see Newsletter #263) by enabling routing through blinded paths and replacing renepay’s internal usage of the sendpay RPC command with sendonion.

  • ● Core Lightning #7887 adds support for handling the new BIP353 fields for Human Readable Name (HRN) resolution to conform with the latest BOLTs updates (see Newsletter #290 and #333). The PR also adds the invreq_bip_353_name field to invoices, enforces restrictions on incoming BIP353 name fields, and allows users to specify BIP353 names on the fetchinvoice RPC, as well as wording changes.

  • ● Eclair #2967 adds support for the option_simple_close protocol as specified in BOLTs #1205. This simplified variant of the mutual close protocol is a prerequisite for simple taproot channels, as it enables nodes to safely exchange nonces during the shutdown, closing_complete and closing_sig phases, which is required to spend a MuSig2 channel output.

  • ● Eclair #2979 adds a verification step to confirm that a node supports wake up notifications (see Newsletter #319) before initiating the wake up flow to relay a trampoline payment. For standard channel payments, this check is unnecessary because the BOLT11 or BOLT12 invoice already indicates support for wake-up notifications.

  • ● Eclair #3002 introduces a secondary mechanism to process blocks and their confirmed transactions to trigger watches, for added security. This is particularly useful when a channel is spent but the spending transaction hasn’t been detected in the mempool. While the ZMQ rawtx topic handles this, it can be unreliable and may silently drop events when using remote bitcoind instances. Whenever a new block is found, the secondary system fetches the last N blocks (6 by default) and reprocesses their transactions.

  • ● LDK #3575 implements the peer storage protocol as a feature that allows nodes to distribute and store backups for channel peers. It introduces two new message types, PeerStorageMessage and PeerStorageRetrievalMessage, along with their respective handlers, to enable the exchange of these backups between nodes. Peer data is stored persistently within PeerState in the ChannelManager.

  • ● LDK #3562 introduces a new scorer (see Newsletter #308) that merges scoring benchmarks based on frequent probing of actual payment paths from an external source. This allows light nodes, which typically have a limited view of the network, to improve payment success rates by incorporating external data such as scores provided by a Lightning Service Provider (LSP). The external score can either be combined with or override the local score.

  • ● BOLTs #1205 merges the option_simple_close protocol, which is a simplified variant of the mutual close protocol required for simple taproot channels. Changes are made to BOLT2 and BOLT3.

Want more?

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