This week’s newsletter summarizes a discussion about setting LN channel base fees to zero and includes our regular sections with popular questions and answers from the Bitcoin Stack Exchange, how you can prepare for taproot, new releases and release candidates, and notable changes to popular Bitcoin infrastructure projects.

News

  • ● Zero base fee LN discussion: in the LN protocol, a spender can choose how much to pay each node that helps successfully route the payment to its final destination. Routing nodes in turn can choose to reject any payment attempt that doesn’t offer them enough fee. For this division of responsibilities to work, routing nodes need to communicate to spenders what fees they expect, so BOLT7 provides routing nodes with the ability to advertise two fee-related parameters, fee_base_msat (base fee) and fee_proportional_millionths (proportional fee).

    A recent paper by René Pickhardt and Stefan Richter proposes a new pathfinding technique that payers will be able to use to minimize their fees and the number of payment attempts they’ll need to successfully send a payment (among other benefits). But deploying the technique on the network today encounters two problems related to the LN base fee and multipath payments:

    • ● More splits, more fees: compare a payment with a single path and a payment for the same amount with two equivalent paths: they would both pay the same amount of total proportional fee (since the overall payment amount is the same) but the two-path payment would pay twice as much total base fee (since it uses twice as many hops). For x equivalent paths, the base fee would be x times as high. This makes using multipath payments more expensive and so penalizes techniques that use them, such as the technique proposed.

    • ● Computational difficulties: as described in section 2.3 of the paper, the proposed pathfinding algorithm can’t easily compute paths and payment splits when there’s a base fee. It may be possible to solve this problem algorithmically in the long term, but the easiest solution for implementers of the algorithm would be to eliminate the base fee.

    In podcasts and on Twitter, the authors suggested the problem could be addressed without any immediate change to the LN protocol if node operators set their base fee to zero. They further suggested operators could begin doing this immediately, even though their work is not yet deployable in production. This led to several discussions between LN developers on Twitter, which Anthony Towns helped migrate to the Lightning-Dev mailing list with a post.

    Towns was in favor of users setting the base fee to zero, noting both its benefits for multipath splitting and that it should be easier for node operators to optimize the single remaining fee parameter, the proportional fee.

    Matt Corallo replied with the concern that the creation of HTLCs for routing payments places several burdens on nodes that are constant regardless of the amount of the payment. The base fee allows a node to require that it be compensated for those costs. But those costs, Towns countered, are essentially the same both for successfully routed payments and unsuccessfully routed payments—yet LN nodes are only paid in the successful case. If nodes are willing to accept those costs without compensation in some cases, why not accept them in all cases? The same, though, could be said of proportional fees, and this led to some brief discussion of upfront fees which could allow nodes to be compensated even for unsuccessful payments.

    Towns also suggested that it is possible for a node to ensure it receives a minimal fee even without a base fee by simply refusing to route payments below a certain size. For example, a node with a current base fee of 1 sat can ensure it receives at least that much with a 0.1% proportional fee and a minimum amount of 1,000 sat. This would stifle micropayments, but LN nodes already handle small payments without using HTLCs, which eliminates some of the fixed costs and may make purely proportional costs more appropriate, though this remained debated.

    Later in the discussion, Olaoluwa Osuntokun emphasized a point made earlier that there’s no clear current need for node operators to change a parameter today for a new pathfinding algorithm that nobody is currently ready to use in production. He and Corallo want to see if further research and development can allow the algorithm (or a similar one based on different principles) to work nearly equally as well even when base fees are non-zero.

    No clear conclusion to the discussion was reached as of this writing.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

Preparing for taproot #10: PTLCs

A weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.

In last week’s column, we looked at signature adaptors and how the activation of taproot with schnorr signatures will make it easier to use adaptors privately and efficiently. There are several ways signature adaptors can be used on Bitcoin but one of the most immediately beneficial will be Point Time Locked Contracts (PTLCs), which can replace the venerable Hash Time Locked Contracts (HTLCs) used for years. This will bring several advantages, but it also comes with some challenges. To understand both, we first start with a simplified example of HTLCs in use; the example below could be offchain LN payments, onchain coinswaps, or a hybrid onchain/offchain system like Lightning Loop—it’s this flexibility that makes HTLCs so widely used.

Alice wants to pay Carol by routing a payment through Bob, who neither Alice nor Carol wants to trust. Carol creates a random preimage and hashes it with the SHA256 algorithm. Carol gives the hash to Alice and keeps the preimage secret. Alice initiates a payment to Bob which he can claim with a signature for his public key plus the preimage; alternatively, Alice can receive a refund after 10 blocks by spending the transaction back to herself with a signature for her public key. Here’s that policy described in the Minsc language:

(pk($bob) && sha256($preimage)) || (pk($alice) && older(10))

Bob can now initiate a payment for the same amount (perhaps minus fees) to Carol with basically the same script, only with the parties updated and a lower refund time out.

(pk($carol) && sha256($preimage)) || (pk($bob) && older(5))

Now Carol can claim her payment from Bob within five blocks by using the preimage, which reveals the preimage to Bob and allows him to claim the payment from Alice, also within five blocks.

Privacy problems with HTLCs

If the scripts above are published onchain, the reuse of the same hash and preimage makes it immediately clear that A paid C via B. This can be a significant problem for same-chain and cross-chain coinswaps. Less obviously, this is also a problem for offchain routing protocols like LN. If we imagine a longer routing path where one person controls multiple hops along the path, they can see the reuse of the same hash and preimage to determine that some nodes are routing nodes, increasing the probability that the remaining nodes are either the spender or the receiver. This is one part of the linkability problem that may be LN’s greatest current privacy weakness.

Illustration of HTLC linkability problem

Although multipath payments partially mitigate other aspects of LN’s linkability problem, e.g. payment amount linkability, it may make worse the hash linkability problem by giving surveillance routing nodes more opportunity to correlate hashes.

An additional problem with HTLCs today is that any scripts which need to go onchain are obviously distinct from normal spender scripts. This makes it easier for surveillants to identify usage patterns and, perhaps, make effective guesses about information specific to individual users.

The PTLC solution

In the previous Minsc-style scripts, we had a function that would only return true if it was passed a particular value chosen in advance (the preimage). A signature adaptor is similar in that it can only be transformed into a valid signature if a function is passed a revealed value (the scalar). If we ignore multisignatures for the moment, this allows us to transform the HTLC scripts from earlier into the following PTLCs:

(pk($bob) && pk($alice_adaptor)) || (pk($alice) && older(10))

(pk($carol) && pk($bob_adaptor)) || (pk($bob) && older(5))

In short, Carol gives Alice the EC point for her hidden scalar, Alice uses that with a public key she chooses and creates a signature adaptor that she gives to Bob; Bob can use the same point with a public key he chooses and creates an adaptor he gives to Carol. Carol reveals the scalar by transforming Bob’s adaptor into a valid signature, claiming Bob’s coins. Bob recovers the scalar from the valid signature, allowing him to transform Alice’s adaptor into its own valid signature, claiming her coins.

This solves the linkability problem against onchain surveillance because all that anyone sees when they look at the block chain are a bunch of valid signatures for distinct public keys. Third parties can’t know that adaptors were used, much less what scalar those adaptors were based upon.

However, the procedure above doesn’t prevent surveillance nodes who participate in the routing from linking together the payments. If all the payments are based on the same scalar, then all the payments are just as linked as if they used a hashlock and preimage. This can be fixed by each routing node choosing their own scalar and then removing its corresponding point as the payment passes through its node. Let’s revise our example:

As before, Carol gives Alice the point for her scalar, but this time Alice also requests a point from Bob. Alice constructs the adaptor she gives Bob using the aggregation of both Carol’s point and Bob’s point. Bob knows his point, so he’s able to subtract that out from the adaptor he receives from Alice. Using the resultant point (which Bob doesn’t know is now just the point Alice originally received from Carol), Bob constructs the adaptor he gives to Carol. Carol knows the scalar for that final point and so converts Bob’s adaptor into a valid signature. As before, Bob recovers Carol’s scalar from her signature and uses it and his own scalar to convert Alice’s adaptor into a valid signature.

In the two hops in this path, Alice→Bob and Bob→Carol, two different EC points and scalars were used, eliminating linkability. We can extend this to the longer path we examined when considering HTLCs and see how this improves privacy:

Illustration of PTLC lack of linkability problem

As mentioned last week, schnorr signatures make it easy to compose adaptor signatures with multisignatures. For the case of generic PTLCs, this allows us to reduce our onchain scripts to:

pk($bob_with_alice_adaptor) || (pk($alice) && older(10))

pk($carol_with_bob_adaptor) || (pk($bob)   && older(5) )

With taproot, the left branch can become a keypath and the right branch can become a tapleaf. If the payment routes successfully, Bob and Carol can settle their parts onchain without further cooperation from their counterparties, making this routed payment indistinguishable from single-sig payments, normal multisignature payments, and cooperatively resolved contracts. It also minimizes the use of block space. If one of the refund conditions needs to be executed, that’s still fairly efficient and fairly private—pk(x) && older(n) is indistinguishable from degrading multisig, enforced hodling, and a variety of other possible scripts.

In next week’s column, a guest post from one of our favorite LN developers will discuss some of the changes necessary for LN to adopt keypath spends, multisignatures, PTLCs, and other features enabled by taproot.

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.

  • ● Rust-Lightning 0.0.100 is a new release that supports sending and receiving keysend payments and makes it easier to track successfully routed payments and record the amount of fee income the node earned from them.

  • ● Bitcoin Core 22.0rc2 is a release candidate for the next major version of this full node implementation and its associated wallet and other software. Major changes in this new version include support for I2P connections, removal of support for version 2 Tor connections, and enhanced support for hardware wallets.

  • ● Bitcoin Core 0.21.2rc1 is a release candidate for a maintenance version of Bitcoin Core. It contains several bug fixes and small improvements.

Notable code and documentation changes

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

  • ● Bitcoin Core #22541 adds a new restorewallet RPC command which can be used to load a wallet backup. restorewallet complements the existing backupwallet command which exports a copy of the currently loaded wallet. Note that backupwallet and restorewallet are alternatives to the older dumpwallet and importwallet RPCs which use a separate file. This work was accompanied by a comprehensive update of the documentation for backing up and restoring wallets in Bitcoin Core #22523.

  • ● LND #5442 allows adding inputs to a PSBT without adding any new outputs, which is useful when creating a CPFP fee bump.

  • ● Rust-Lightning #1011 adds support for not-yet-merged BOLTs #847, which allows two channel peers to negotiate what fee should be paid in a mutual close transaction. In the current protocol, only a single fee is sent, and the other party must either accept or reject that precise fee.

  • ● BOLTs #887 updates BOLT11 to require that spenders specify the payment secret when making a payment regardless of the receiver’s payment_secret feature bit. The receiver should verify the payment secret to prevent probing attacks in simplified multipath payments. This verification has previously been implemented in all four LN implementations we cover.