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.
● 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
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
xequivalent paths, the base fee would be
xtimes 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.
● Why does Bitcoin Core support a transaction index but not an address index? Andrew Chow explains the historical significance of Bitcoin Core’s transaction index in validating transactions (since replaced by the UTXO database) and outlines objections to adding an address index feature to Bitcoin Core including maintenance overhead, lack of compelling use cases, and concerns that such an index is outside of Bitcoin Core’s project scope.
● Is the
mempoolP2P message reliable? Claris and Pieter Wuille explain the history of the
mempoolP2P message. After being introduced in BIP35 to expose a node’s mempool contents to SPV peers, the message was then moved to be accessible with BIP37’s bloom filters which are now disabled by default. Support for
mempoolrequests can be configured for individual peers using the
● What is SIGHASH_ANYPREVOUTANYSCRIPT? Michael Folkson summarizes Christian Decker’s comparison of BIP118’s proposed signature hashes (sighashes). The
SIGHASH_ANYPREVOUTsighash commits to a
scriptPubKeybut drops the commitment to a specific UTXO. The
SIGHASH_ANYPREVOUTANYSCRIPTsighash drops the commitment to the input’s amount as well as a specific
scriptPubKey, the later of which is necessary to support eltoo.
● Will LN liquidity advertisements and dual funding allow for third-party purchased liquidity (“sidecar channels”)? David A. Harding notes that while not currently supported, third-party purchased liquidity using liquidity advertisements and dual funded channels is possible. He summarizes Lisa Neigut’s ideas for an onchain PSBT workflow and an offchain workflow.
● Are there risks to using the same private key for both ECDSA and Schnorr signatures? Pieter Wuille notes that while there are no known key reuse attacks across schnorr and ECDSA, that “To stay within the realm of provably security it’s advisable to make sure ECDSA key and Schnorr keys use distinct hardened derivation steps.”
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.
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:
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.
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
restorewalletRPC command which can be used to load a wallet backup.
restorewalletcomplements the existing
backupwalletcommand which exports a copy of the currently loaded wallet. Note that
restorewalletare alternatives to the older
importwalletRPCs 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.
● 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_secretfeature 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.