Bitcoin Optech #142: Lightning Network Path Selection And Bitcoin Stack Exchange

The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s newsletter describes a paper and a short discussion about probabilistic path selection for LN and includes our regular sections with summaries of popular questions and answers from the Bitcoin StackExchange, release and release candidates, and notable changes to Bitcoin infrastructure software.

Action items

• Upgrade BTCPay Server to 1.0.7.1: this release fixes “one critical and several low-impact vulnerabilities that affected BTCPay Server versions 1.0.7.0 and older”, according to the project’s release notes.

News

• Paper on probabilistic path selection: René Pickhardt posted to the Lightning-Dev mailing list a paper he co-authored with Sergei Tikhomirov, Alex Biryukov, and Mariusz Nowostawski. The paper models a network of channels having a uniform distribution of balances within their respective channel capacity. E.g., for a channel with the capacity of 100 million satoshis between Alice and Bob, the paper assumes all of the following states are equally as likely for that channel, and that the same holds true for every other channel on the network:

• Making this assumption allows the authors to draw conclusions about the probability that a payment will succeed based on its amount and how many hops (channels) it needs to traverse. This allows the authors to prove the benefit of several known heuristics—such as keeping paths short and using multipath payments to break larger payments into smaller payments (under certain other assumptions). They also use the model to evaluate new proposals, such as allowing Just-In-Time (JIT) rebalancing via bolts #780.The paper uses its conclusions to provide a routing algorithm that it claims can reduce payment retry attempts by 20% compared to their simplification of existing routing algorithms. The new algorithm prefers routes with a higher computed probability of success, whereas existing algorithms use a heuristic approach. Combined with JIT rebalancing, they estimate a 48% improvement. Given that each retry usually requires several seconds, and could take much longer in some cases, this could provide an improved user experience. The algorithm was tested against several example networks, including one drawn from a snapshot of almost 1,000 live channels.The paper deliberately does not take routing fees into consideration, and most responses on the mailing list focused on how to use the results while still ensuring users don’t pay an excessive amount of fees.

• Updated article about payment batching: Optech has published an article about payment batching, updated from our original announcement of it in Newsletter #37. Payment batching is a technique that can help spenders save up to 80% on transaction fees.

Selected Q&A from Bitcoin StackExchange

Bitcoin StackExchange 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.

• How hard is it for an exchange to adopt native segwit? Bitcoin developer instagibbs lists a few considerations for exchanges implementing native segwit including address generation, ensuring spendability, support and business considerations, and compatibility of signing infrastructure like Hardware Security Modules (HSMs).

• How do you calculate when 98% of Bitcoin will be mined? While Murch provides an estimate of 2030-2031 for when 98% of all bitcoins will be mined, he also links to a reward schedule Google Sheet with additional metrics.

• How can I use Bitcoin Core with the anonymous network protocol I2P? With the merge of Bitcoin Core #20685, Bitcoin supports the I2P network. Michael Folkson summarizes Jon Atack’s original thread on how to configure Bitcoin Core to use I2P.

• Will nodes with a larger-than-default mempool retransmit transactions that have been dropped from smaller mempools? Pieter Wuille notes that transaction rebroadcasting is currently a wallet responsibility, that perhaps nodes should also rebroadcast unconfirmed transactions, and points to Bitcoin Core #21061 as working toward that goal.

• Should block height or MTP or a mixture of both be used in a soft fork activation mechanism? David A. Harding outlines the advantages and disadvantages of both Median Time Past (MTP) and block heights as timing mechanisms within Bitcoin. MTP roughly corresponds to clock time but can be manipulated by miners to skip a signaling period. Block heights are not consistent but are also not miner-gameable in the same way as MTP. User chytrik provides different examples to illustrate the and why avoiding round payment amounts can be better for privacy.

• Why is it recommended to “not send round number amounts when making payments” for increased privacy? User chytrik provides different examples to illustrate the round number heuristic and why avoiding round payment amounts can be better for privacy.

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.

• BTCPay Server 1.0.7.1 fixes several security vulnerabilities. It also includes a number of improvements and non-security bug fixes. is a bugfix release that addresses minor issues with Trezor T passphrase entry and keyboard shortcuts in the hwi-qt user interface.

• HWI 2.0.1 is a bugfix release that addresses minor issues with Trezor T passphrase entry and keyboard shortcuts in the hwi-qt user interface.

• C-Lightning 0.10.0-rc2 is a release candidate for the next major version of this LN node software.

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 #17227 adds a new make apk target to the build system which packages bitcoin-qt for the Android operating system. This continues previous work which added support for packaging the Android NDK. Also included are documentation for building Bitcoin Core for Android and a continuous integration job to test the Android build system.

• Rust-Lightning #849 makes a channel’s cltv_expiry_delta configurable and reduces the default value from 72 blocks to 36 blocks. This parameter sets the deadline by which a node must settle a payment attempt with its upstream peer after learning from its downstream peer whether that payment succeeded; it must be long enough to confirm a transaction onchain if necessary but should be short enough that it’s competitive with other nodes that are trying to minimize possible delays. See also Newsletter #40 where LND reduced its value to 40 blocks.

• C-Lightning #4427 makes it possible to experiment with dual funded payment channels by using the configuration option –experimental-dual-fund. Dual funding allows funds for the initial channel balance to be contributed by both the node initiating the channel and the node accepting the channel, which can be useful for merchants and other users who want to begin receiving payments as soon as the channel finishes opening.

• Eclair #1738 updates the penalty enforcement mechanism for revoked HTLCs when anchor outputs are being used. A change unrelated to anchor outputs, but introduced at the same time they were added to the protocol, created the possibility to combine multiple SIGHASH_SINGLE|SIGHASH_ANYONECANPAY HTLC outputs into a single transaction (see Newsletter #128. This PR ensures that all outputs that are spendable with the revocation key are claimed in the same transaction instead of claiming only one per transaction.

• BIPs #1080 updates BIP8 with a minimum_activation_height parameter that delays the time nodes begin enforcing a locked-in soft fork until after the specified height. This makes BIP8 compatible with the Speedy Trial proposal (see Newsletter #139) that would allow miners to activate taproot but would not begin enforcing taproot’s rules until roughly six months after the release of software implementing Speedy Trial.

Find the original post here.

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.

Bitcoin Optech: Bitcoin Technical Updates Newsletter #139

The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s newsletter summarizes continued discussion about proposed methods for activating taproot and links to an effort to document existing software building on top of taproot. Also included are our regular sections with the summary of a Bitcoin Core PR Review Club meeting, announcements of releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure projects.

News

• Taproot activation discussion: the previous weeks’ discussions about activation saw different groups of people opposing either BIP8LockinOnTimeout=true (LOT=true) or LOT=false, so most discussion on the mailing list this week focused on alternative activation mechanisms. Some proposals included:

  • User Activated Soft Fork (UASF): a plan being discussed to implement BIP8 LOT=true in a software fork of Bitcoin Core that mandates miners signal for activation of taproot by July 2022 (as widely proposed), but which also allows miners to activate it earlier.

  • Flag day: several proposals (1, 2) to program into nodes a specific block height or time roughly 18 months from now (as proposed) where taproot activates. Miner signaling is not required to cause activation and cannot cause earlier activation. Anthony Towns wrote a draft implementation.

  • Decreasing threshold: several proposals (1, 2) to gradually decrease over time the number of blocks that must signal readiness for miners to enforce taproot before the new consensus rules lock in. See also Anthony Town’s proposal from last year described in Newsletter #107.

  • A configurable LOT: in addition to previously-discussed proposals to make BIP8’s LOT value a configuration option (see Newsletter #137), rough code was posted showing how LOT=true could be enforced via an external script calling RPC commands. Additional code was created showing how LOT=true could also be opposed by node operators who were worried about it creating block chain instability.

  • A short-duration attempt at miner activation: an updated proposal to give miners approximately three months to lock in taproot, starting from soon after the release of a full node implementing the activation logic. If the attempt failed, the community would be encouraged to move on to a different activation method. If the attempt succeeded, there would still be a several month delay before taproot activated to allow most of the economy to upgrade their nodes. A draft implementation for this proposal based on Bitcoin Core’s existing BIP9 implementation was also written by Anthony Towns. Andrew Chow created an alternative draft implementation based on the previously proposed BIP8 implementation.

  It seemed unlikely any of the proposals would ever become almost everyone’s first choice, but it appeared that a large number of people were willing to accept the short-duration attempt under the name Speedy Trial. There were still a few concerns with it, including:

  • Could be co-opted for mandatory activation: even though the proposal explicitly encourages making other activation attempts if miners don’t quickly signal sufficient support for taproot, a concern was expressed that it could be co-opted by a group of users seeking fast mandatory activation, although it was noted that no group has previously expressed the desire to attempt mandatory activation on such a dangerously short timeline.

  • Using time-based or height-based parameters: the proposal describes the tradeoffs between setting its start, timeout, and minimum_activation parameters using either times (based on the median of the previous 11 blocks) or block heights. Using times would result in the smallest and easiest to review patch to Bitcoin Core. Using heights would provide a bit more predictability, especially for miners, and would be compatible with other attempts using BIP8.

  • Myopic: there was concern that the proposal is too focused on the short term: “Speedy Trial fully prepares for the (likely) case where miners activate taproot, but it does nothing to codify lessons learned from Segwit’s failure to activate in a timely manner. We have an opportunity with the activation of taproot to create a template for future activations that will clearly define the roles and responsibilities for developers, miners, merchants, investors, and end users in all the ways an activation can progress, not just the best-case outcomes; in particular enabling and enshrining the final arbiter role held by Bitcoin’s economic users. Defining this will only get more difficult in the future, both because we’ll only do so when we’re already in crisis, and because Bitcoin’s growth means future agreement will need to be done at greater scale and so with greater difficulty.”

  • Speed: the proposal, based on initial discussion from the ##taproot-activation IRC channel, proposes giving miners about three months to lock in taproot and waiting a fixed six months from the start of signal measuring before activation (if lock in is achieved). Some people have sought either slightly shorter or slightly longer timelines.

  We’ll continue tracking the discussion around the various proposals and will summarize any significant progress in future newsletters.

• Documenting the intention to use and build upon taproot: In discussion about activation methods, Chris Belcher noted that a large list of software was compiled whose developers stated their intention to implement segwit during the debate around activating that soft fork. He suggested that a similar list could be created to document for posterity the amount of support taproot has. That way it could be clear that taproot was desired by a large segment of the economy no matter how it ends up being activated.Jeremy Rubin posted to the Bitcoin-Dev mailing list a link to a somewhat related wiki page where developers can post links to projects they’re building on top of taproot’s new proposed features. This can provide assurance that taproot provides solutions people actually want and is designed in such a way that its features will get used.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Erlay: bandwidth-efficient transaction relay protocol is a PR (#18261) by Gleb Naumenko that proposes to implement BIP330 in Bitcoin Core.

The review club discussion focused on the tradeoffs, implementation and potential new attack vectors involved with Erlay. In subsequent meetings, the review club discussed Minisketch, a library implementing the PinSketch set reconciliation algorithm that is the basis for the efficient relay protocol in Erlay.

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 0.5.1 is the latest release of this LN node, containing improvements to startup speed, reduced bandwidth consumption when syncing the network graph, and a series of small improvements in preparation for supporting anchor oututs.

• HWI 2.0.0RC2 is a release candidate for the next major version of HWI.

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 #20685 Adds I2P support by using the I2P SAM protocol. This feature has long been requested and was only recently made possible by the addition of addr v2 Though documentation for node operators hoping to run I2P is still being created, a Bitcoin StackExchange Q&A provides hints on getting started.

• C-Lightning #4407 updates the listpeers RPC with new fields that provide information about each channel’s current unilateral close transaction, including its fee (both in total fee terms and as a feerate).

• Rust-Lightning #646 adds the ability to find multiple paths for a payment so that it will be possible to add multipath payment support.

• BOLTs #839 adds funding transaction timeout recommendations to save funding fees when there’s a failure to confirm funding transactions, providing stronger guarantees for the channel funder and fundee. The new recommendations suggest that the funder commits to ensuring the funding transaction confirms in 2016 blocks and recommends that the fundee forget the pending channel if the funding transaction not confirm within those 2016 blocks.

• BTCPay Server #2181 uppercases bech32 addresses when presenting BIP21 URIs as QR codes. This results in less dense QR codes as uppercase substrings can be encoded more efficiently. The change was preceded by an extensive compatibility survey of wallets with the BIP21 URI scheme.