This week’s newsletter summarizes a discussion about extending BOLT11 invoices to request two payments. Also included is another entry in our limited weekly series about mempool policy, plus our regular sections describing updates to clients and services, new releases and release candidates, and changes to popular Bitcoin infrastructure software.

News

• ● Proposal to extend BOLT11 invoices to request two payments: Thomas Voegtlin posted to the Lightning-Dev mailing list to suggest BOLT11 invoices be extended to optionally allow a receiver to request two separate payments from a spender, with each payment having a separate secret and amount. Voegtlin explains how that could be useful in for both submarine swaps and JIT channels:

  • ● Submarine swaps, where paying an offchain LN invoice results in receiving funds onchain (submarine swaps can also work the other way, from onchain to offchain, but that is not being discussed here). The onchain receiver chooses a secret and the offchain spender pays an HTLC to the hash of that secret, which is routed over LN to a submarine swap service provider. The service provider receives an offchain HTLC for that secret and creates an onchain transaction paying to that HTLC. When the user is satisfied that the onchain transaction is secure, they disclose the secret to settle the onchain HTLC, allowing the service provider to settle the offchain HTLC (and any forwarded payments on LN that also depend on the same secret).

    However, if the receiver doesn’t disclose their secret, then the service provider won’t receive any compensation and will need to spend the onchain output they just created, incurring costs for no gain. To prevent this abuse, existing submarine swap services require the spender to pay a fee using LN before the service will create an onchain transaction (the service may optionally refund part or all of this fee if the onchain HTLC is settled). The upfront fee and the submarine swap are for different amounts and need to be settled at different times, so they need to use different secrets. A current BOLT11 invoice can only contain one commitment to a secret and one amount, so any wallet making submarine swaps at present needs to either be programmed to handle the interaction with the server or needs both the spender and the receiver to complete a multi-step workflow.

  • ● Just-in-Time (JIT) channels, where a user with no channels (or none with liquidity) creates a virtual channel with a service provider; when the first payment to that virtual channel arrives, the service provider creates an onchain transaction that both funds the channel and contains that payment. Like any LN HTLC, the offchain payment is made to a secret only the receiver (the user) knows. If the user is convinced the JIT channel funding transaction is secure, they disclose the secret to claim the payment.

    However, again, if the user doesn’t disclose their secret, then the service provider won’t receive any compensation and will incur onchain costs for no gain. Voegtlin believes existing JIT channel service providers avoid this problem by requiring the user to disclose their secret before the funding transaction is secure, which he says may create legal problems and prevents non-custodial wallets from offering a similar service.

  Voegtlin suggests that allowing a BOLT11 invoice to contain two separate commitments to secrets, each for a different amount, will allow using one secret and amount for an upfront fee to pay the onchain transaction costs and the other secret and amount for the actual submarine swap or JIT channel funding. The proposal received several comments, a few of which we’ll summarize:

  • ● Dedicated logic required for submarine swaps: Olaoluwa Osuntokun notes that the receiver of a submarine swap needs to create a secret, distribute it, and then settle a payment to it onchain. The cheapest way to settle it is by interacting with the swap service provider. If the spender and receiver are going to interact with the service provider anyway, as is often the case with some existing implementations where the spender and receiver are the same entity, they don’t need to communicate extra information using an invoice. Voegtlin replied that a dedicated piece of software can handle the interaction, eliminating the need for additional logic in the offchain wallet that pays out the funds and the onchain wallet that receives the funds—but this is only possible if the LN wallet can pay two separate secrets and amounts in the same invoice.

  • ● BOLT11 ossified: Matt Corallo replied that it hasn’t yet been possible to get all LN implementations to update their BOLT11 support to support invoices that don’t contain an amount (for allowing spontaneous payments), so he doesn’t think adding an additional field is a practical approach at this time. Bastien Teinturier makes a similar comment, suggesting adding support to offers instead. Voegtlin disagrees and thinks adding support is practical.

  • ● Splice-out alternative: Corallo also inquires about why the protocol should be modified to support submarine swaps if splice outs become available. It wasn’t mentioned in the thread, but both submarine swaps and splice outs allow moving offchain funds into an onchain output—however splice outs can be more efficient onchain and aren’t vulnerable to uncompensated fee problems. Voegtlin answers that submarine swaps allow an LN user to increase their capacity for receiving new LN payments, which splicing does not.

  The discussion appeared to be ongoing at the time of writing.

Waiting for confirmation #6: Policy Consistency

A limited weekly series about transaction relay, mempool inclusion, and mining transaction selection—including why Bitcoin Core has a more restrictive policy than allowed by consensus and how wallets can use that policy most effectively.

Last week’s post introduced policy, a set of transaction validation rules applied in addition to consensus rules. These rules are not applied to transactions in blocks, so a node can still stay in consensus even if its policy differs from that of its peers. Just like a node operator may decide to not participate in transaction relay, they are also free to choose any policy, up to none at all (exposing their node to the DoS risk). This means we cannot assume complete homogeneity of mempool policies across the network. However, in order for a user’s transaction to be received by a miner, it must travel through a path of nodes that all accept it into their mempool – dissimilarity of policy between nodes directly affects transaction relay functionality.

As an extreme example of policy differences between nodes, imagine a situation in which each node operator chose a random nVersion and only accepted transactions with that nVersion. As most peer-to-peer relationships would have incompatible policies, transactions would not propagate to miners.

On the other end of the spectrum, identical policies across the network help converge mempool contents. A network with matching mempools relays transactions the most smoothly, and is also ideal for fee estimation and compact block relay as mentioned in previous posts.

Given the complexity of mempool validation and the difficulties that arise from policy disparities, Bitcoin Core has historically been conservative with the configurability of policies. While users are able to easily tweak the way sigops are counted (bytespersigop) and limit the amount of data embedded in OP_RETURN outputs (datacarriersize and datacarrier), they cannot opt out of the 400,000 weight-unit maximum standard weight or apply a different set of fee-related RBF rules without changing the source code.

Some of Bitcoin Core’s policy configuration options exist to accommodate the difference in node operating environments and purposes for running a node. For example, a miner’s hardware resources and purpose for keeping a mempool differ from a day-to-day user running a lightweight node on their laptop or Raspberry Pi. A miner may opt to increase their mempool capacity (maxmempool) or expiration timeline (mempoolexpiry) to store low feerate transactions during peak traffic, and then mine them later when traffic dies down. Websites providing visualizations, archives, and network statistics may run multiple nodes to collect as much data as possible and also display default mempool behavior.

On an individual node, the choice of mempool capacity affects the availability of fee-bumping tools. When the mempool minimum feerates rise due to transaction submissions exceeding the default mempool size, transactions purged from the “bottom” of the mempool and new ones that are below this feerate can no longer be fee-bumped using CPFP.

On the other hand, since the inputs used by the purged transactions are no longer spent by any transactions in the mempool, it may be possible to fee-bump via RBF when it wasn’t before. The new transaction isn’t actually replacing anything in the node’s mempool, so it doesn’t need to consider the usual RBF rules. However, nodes that haven’t evicted the original transaction (because they have a larger mempool capacity) treat the new transaction as a proposed replacement and require it to abide by the RBF rules. If the purged transaction was not signaling BIP125 replaceability, or the new transaction’s fee does not meet RBF requirements despite being high feerate, the miner may not accept their new transaction. Wallets must handle purged transactions carefully: the transaction’s outputs cannot be considered available for spending, but the inputs are similarly unavailable to reuse.

At quick glance, it may seem that a node with larger mempool capacity makes CPFP more useful and RBF less useful. However, transaction relay is subject to emergent network behavior and there might not be a path of nodes accepting the CPFP from the user to the miner. Nodes typically only forward transactions once upon accepting it to their mempool and ignore announcements of transactions that already exist in their mempools—nodes that store more transactions act as blackholes when those transactions are rebroadcast to them. Unless the entire network increases their mempool capacities – which would be a sign to change the default value – users should expect little benefit from increasing the capacity of their own mempools. The mempool minimum feerate set by default mempools limits the utility of using CPFP during high-traffic times. A user who managed to submit a CPFP transaction to their own increased-size mempool might fail to notice that the transaction did not propagate to anyone else.

The transaction relay network is composed of individual nodes which dynamically join and leave the network, each of whom must protect themselves against exploitation. As such, transaction relay can only be a best-effort and we cannot guarantee that every node learns about every unconfirmed transaction. At the same time, the Bitcoin network performs best if nodes converge on one set of transaction relay policies that makes mempools as homogeneous as possible. The next post will explore what policies have been adopted in order to fit the network’s interests as a whole.

Changes to services and client software

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

• ● Greenlight libraries open sourced: Non-custodial CLN node service provider Greenlight has announced a repository of client libraries and language bindings as well a testing framework guide.

• ● Tapscript debugger Tapsim: Tapsim is a script execution debugging (see Newsletter #254) and visualization tool for tapscript using btcd.

• ● Bitcoin Keeper 1.0.4 announced: Bitcoin Keeper is a mobile wallet that supports multisig, hardware signers, BIP85, and with the latest release, coinjoin support using the Whirlpool protocol.

• ● Lightning wallet EttaWallet announced: The mobile EttaWallet was recently announced with Lightning features enabled by LDK and a strong usability focus inspired by the daily spending wallet reference design from the Bitcoin Design Community.

• ● zkSNARK-based block header sync PoC announced: BTC Warp is a light client sync proof-of-concept using zkSNARKs to prove and verify a chain of Bitcoin block headers. A blog post provides details on the approaches taken.

• ● lnprototest v0.0.4 released: The lnprototest project is a test suite for LN including “a set of test helpers written in Python3, designed to make it easy to write new tests when you propose changes to the lightning network protocol, as well as test existing implementations”.

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.

• ● Eclair v0.9.0 is a new release of this LN implementation that “contains a lot of preparatory work for important (and complex) lightning features: dual-funding, splicing and BOLT12 offers.” The features are experimental for now. The release also “makes plugins more powerful, introduces mitigations against various types of DoS, and improves performance in many areas of the codebase.”

Notable code and documentation changes

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

• ● LDK #2294 adds support for replying to onion messages and brings LDK closer to full support for offers.

• ● LDK #2156 adds support for keysend payments that use simplified multipath payments. LDK previously supported both of those technologies, but only when they were used separately. Multipath payments must use payment secrets but LDK previously rejected keysend payments with payment secrets, so descriptive errors, a configuration option, and a warning about downgrading are added to mitigate any potential problems.