This week’s newsletter summarizes a thread about paying frequently-offline LN nodes, describes a set of proposals for lowering the cost of LN payment path probing in order to make certain attacks more expensive, and links to instructions useful for creating taproot transactions on signet and testnet. Also included are our regular sections describing recent changes to clients and services, new releases and release candidates, and notable changes to popular Bitcoin infrastructure software.

News

  • ● Paying offline LN nodes: Matt Corallo started a thread on the Lightning-Dev mailing list for brainstorming how frequently-offline LN nodes (such as those on mobile devices) can receive payments without requiring a custodial solution or locking up channel liquidity for prolonged periods of time. Corallo believes there’s a reasonably good solution involving an untrusted third party once LN is upgraded to support PTLCs, but he’s also seeking suggestions for any alternative solutions that could be deployed even before PTLC support is added.

  • ● Lowering the cost of probing to make attacks more expensive: a few weeks apart, developers ZmnSCPxj and Joost Jager each made substantially similar proposals for eliminating the requirement to lock up capital in order to probe a payment path. Both proposals suggest this as a first step towards adding upfront routing fees to the network—fees that would cost the spender money even if a payment attempt failed. Upfront fees are one of the suggested mitigations for channel jamming attacks.

    Currently, LN nodes can send guaranteed-to-fail payments in order to probe a payment path. For example, Alice generates an HTLC that pays a preimage nobody knows. She routes the payment through Bob and Charlie to Zed. Since Zed doesn’t know the payment preimage, he’s forced to reject the payment even though it indicates he’s supposed to be the ultimate receiver. If Alice receives the reject message from Zed’s node, she knows that Bob and Charlie had enough funds in their channels to allow paying Zed, and so she can immediately react to Zed’s rejection by sending an actual payment that has a high probability of succeeding (the only liquidity-related reason for failing would be if Bob’s or Charlie’s balances had changed in the meantime). The advantage to Alice of starting with a guaranteed-to-fail probe is that she can probe multiple paths in parallel and use whichever one succeeds first, reducing the overall payment time. The primary disadvantage is that each payment probe temporarily locks up funds belonging to Alice and to intermediate nodes like Bob and Charlie; if Alice is probing several long paths in parallel, she could easily be locking up 100x or more of her payment amount. A secondary disadvantage is that this type of payment path probing can sometimes result in unnecessary unilateral channel closures and their resulting onchain fees.

    ZmnSCPxj and Jager propose to allow sending a special probe message that doesn’t require using an HTLC, temporarily locking up bitcoins, or risking channel failure. The message would be essentially free to send, although ZmnSCPxj’s proposal does suggest some mitigations to avoid denial of service flood attacks.

    If free probing does actually allow spending nodes to find paths that are reliable a high percentage of the time, ZmnSCPxj and Jager argue that developers and users should be less resistant to paying upfront fees that will cost users on the rare occasions when payments fail. That small occasional cost to honest users would become a large guaranteed cost to dishonest nodes executing extensive jamming attacks, reducing the risk that such attacks will occur (and compensating routing node operators for deploying extra capital to improve the network if a sustained attack did occur).

    The idea received a modest level of discussion as of this writing.

  • ● Testing taproot: in response to a request on the Bitcoin-Dev mailing list, Anthony Towns provided step-by-step instructions for creating a bech32m address for testing in Bitcoin Core on signet or testnet. These instructions may be easier to use for developers testing taproot than those previously provided by Optech.

Changes to services and client software

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

Preparing for taproot #18: trivia

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

  • ● What is a taproot? Wikipedia says, “A taproot is a large, central, and dominant root from which other roots sprout laterally. Typically a taproot is somewhat straight and very thick, is tapering in shape, and grows directly downward. In some plants, such as the carrot, the taproot is a storage organ so well developed that it has been cultivated as a vegetable.”

    How does this apply to Bitcoin?

    • “I always assumed the origin of the name was ‘taps into the Merkle root’, but I don’t actually know what Gregory Maxwell’s thinking was.” —Pieter Wuille (source)

    • “I originally had to look the word up; but I took it as the key path being the ‘taproot’ because that’s the tasty one that you make carrot soup out of, and the merklized scripts would be the other lesser roots that you hope to ignore.” —Anthony Towns (source)

    • “The name originated in a visualization of a tree with a thick central truck like a dandelion taproot—the technique is mostly useful because of the assumption that there is one high probability path and the rest is fuzzy stragglers, and I thought it was a good one because of the punny fact that it verifies script-path spends by tapping into the hidden commitment in the root.

      […] Alas, calling the hash tree with the sorted interior nodes a ‘myrtle tree’ didn’t catch on. (Myrtle tree because the set of policies with an equal hash root are ones whos ordering differs by a permutation which can be defined by a t-function, and Myrtle is the family which includes melaleuca, the tea-tree, and it sounds like ‘merkle’. :p )” —Gregory Maxwell (source)

  • ● Schnorr signatures predate ECDSA: we talk about schnorr signatures as an upgrade on Bitcoin’s original ECDSA signatures because they make it easier to implement various cryptographic tricks, but the schnorr signature algorithm predates the DSA algorithm that ECDSA is based upon. Indeed, DSA was created in part to circumvent Claus Peter Schnorr’s patent on schnorr signatures but Schnorr still claimed “[my] patents apply to various implementations of discrete log signatures of that sorts and hence covers the use of Nyberg-Rueppel and DSA signatures in these instances.” No court is known to have supported Schnorr’s claim and his patent expired by 2011.

  • ● Unsure what name to use: although it didn’t work out, there was a suggestion early in the development of adapting schnorr signatures for Bitcoin that Claus Peter Schnorr’s name shouldn’t be used in association with them because his patent on them prevented the widespread use of a valuable cryptographic technique for over 20 years. Pieter Wuille writes, “we did consider calling BIP340 ‘DLS’ for ‘Discrete Logarithm Signatures’, but I think we eventually didn’t go through with that because the name Schnorr was already so much talked about.”

  • ● Schnorr signatures for twisted Edwards curves: an application of schnorr signatures using elliptic curves was published in 2011. The scheme, EdDSA, is now the basis of several standards. Although not used in Bitcoin consensus, references to it in the context of other systems can be found in many of the Bitcoin repositories tracked by Optech.

  • ● Pay to contract: Ilja Gerhardt and Timo Hanke created a protocol, presented by Hanke at the 2013 San Jose Bitcoin conference, for allowing a payment to commit to the hash of its contract. Anyone with a copy of the contract, and the nonce used to avoid certain attacks, can verify the commitment—but to anyone else the payment looks like any other Bitcoin payment.

    A slight improvement to this pay-to-contract (P2C) protocol was included in the 2014 paper about sidechains, where the commitment also includes the original public key to pay. Taproot uses this same construction but, instead of committing to the terms of an offchain contract, the output creator commits to consensus-enforced terms chosen by the receiver for how they can spend the received bitcoins onchain.

  • ● A Good Morning: the idea to use P2C so that payments to scripts can look identical onchain to paying public keys was invented in Los Altos, California, at the diner “A Good Morning” on 22 January 2018. Pieter Wuille writes that the idea was developed by Andrew Poelstra and Gregory Maxwell “while I briefly left the table… !$%@” [sic].

  • ● 2.5 years in 1.5 days: choosing the optimal constant for bech32m required about 2.5 years of CPU time, which was performed in just 1.5 days mostly using a CPU cluster belonging to Gregory Maxwell.

We thank Anthony Towns, Gregory Maxwell, Jonas Nick, Pieter Wuille, and Tim Ruffing for enjoyable conversations related to this column. Any errors are the author’s.

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.

  • ● BDK 0.12.0 is a release that adds the ability to store data using Sqlite, among other 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, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • ● Bitcoin Core #22863 documents a decision to use the same minimum output amount (“dust amount”) of 294 sat for P2TR outputs as for P2WPKH outputs. This is done even though it costs less to spend a P2TR output than a P2WPKH output because some developers were opposed to lowering the dust limit at this time.

  • ● Bitcoin Core #23093 adds a newkeypool RPC method that will mark all pre-generated addresses in the wallet as used so that a new set of addresses is generated. Most users should never need this, but the behavior is used in the background if a user upgrades from an older non-BIP32 wallet to using HD key generation.

  • ● Bitcoin Core #22539 considers replacement transactions seen by the local node when generating fee estimates. Replacement transactions were previously not considered when they rarely occurred, but currently about 20% of all transactions send the BIP125 signal for opting in to replacement and several thousand replacements occur in a typical day.

  • ● Eclair #1985 adds a new max-exposure-satoshis configuration setting that allows the user to set the maximum amount of money they’ll donate to miners if the channel is forced closed with unresolved uneconomical payments. See the description of CVE-2021-41591 in last week’s newsletter for more information.

  • ● Rust-Lightning #1124 extends the get_route API with the ability to pass an additional parameter that can be used to avoid reusing previously failed routes. Additional planned changes will make it easier to use previous routing successes and failures to improve the quality of later results.

  • ● BOLTs #894 adds suggested checks to the specification. Implementations can implement these to prevent donating excess bitcoins to miner fees when routing payments that are uneconomical onchain. See last week’s newsletter for details about problems possible when these checks are not present.