{"id":17224,"date":"2021-03-31T15:46:33","date_gmt":"2021-03-31T15:46:33","guid":{"rendered":"http:\/\/ci027f748320002558"},"modified":"2025-10-02T15:05:03","modified_gmt":"2025-10-02T20:05:03","slug":"bitcoin-optech-142-lightning-network-path-selection-and-bitcoin-stackexchange","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-optech-142-lightning-network-path-selection-and-bitcoin-stackexchange","title":{"rendered":"Bitcoin Optech #142: Lightning Network Path Selection And Bitcoin Stack Exchange"},"content":{"rendered":"<div id=\"bsf_rt_marker\"><\/div><p><em>The <\/em><a href=\"https:\/\/bitcoinops.org\/\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Optech <\/em><\/a><em>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&#8217;re republishing the latest issue of this newsletter below. Remember <\/em><a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/\" target=\"_blank\" rel=\"noopener\"><em>to subscribe<\/em><\/a><em> to receive this content straight to your inbox.<\/em><\/p>\n<p>This week\u2019s 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.<\/p>\n<h2>Action items<\/h2>\n<ul>\n<li>Upgrade BTCPay Server to 1.0.7.1: this <a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/releases\/tag\/v1.0.7.1\" target=\"_blank\" rel=\"noopener\">release<\/a> fixes \u201cone critical and several low-impact vulnerabilities that affected BTCPay Server versions 1.0.7.0 and older\u201d, according to the project\u2019s release notes.<\/li>\n<\/ul>\n<h2>News<\/h2>\n<ul>\n<li>Paper on probabilistic path selection: Ren\u00e9 Pickhardt <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/lightning-dev\/2021-March\/002984.html\" target=\"_blank\" rel=\"noopener\">posted<\/a> to the Lightning-Dev mailing list a <a href=\"https:\/\/arxiv.org\/abs\/2103.08576\" target=\"_blank\" rel=\"noopener\">paper<\/a> 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:<\/li>\n<\/ul>\n<figure><img decoding=\"async\" src=\"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/screenshot-2021-03-31-at-075557.png\" title=\"\"><\/figure>\n<ul>\n<li>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\u2014such as keeping paths short and using <a href=\"https:\/\/bitcoinops.org\/en\/topics\/multipath-payments\/\" target=\"_blank\" rel=\"noopener\">multipath payments<\/a> to break larger payments into smaller payments (under certain other assumptions). They also use the model to evaluate new proposals, such as allowing <a href=\"https:\/\/bitcoinops.org\/en\/topics\/jit-routing\/\" target=\"_blank\" rel=\"noopener\">Just-In-Time (JIT) rebalancing<\/a> via bolts #780.<br \/>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.<br \/>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\u2019t pay an excessive amount of fees.<\/li>\n<li>Updated article about payment batching: Optech has published an <a href=\"https:\/\/bitcoinops.org\/en\/payment-batching\/\" target=\"_blank\" rel=\"noopener\">article about payment batching<\/a>, updated from our original announcement of it in <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/03\/12\/#optech-publishes-book-chapter-about-payment-batching\" target=\"_blank\" rel=\"noopener\">Newsletter #37<\/a>. Payment batching is a technique that can help spenders save up to 80% on transaction fees.<\/li>\n<\/ul>\n<h2>Selected Q&amp;A from Bitcoin StackExchange<\/h2>\n<p><a href=\"https:\/\/bitcoin.stackexchange.com\/\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin StackExchange<\/em><\/a><em> is one of the first places Optech contributors look for answers to their questions\u2014or 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.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/bitcoin.stackexchange.com\/a\/103674\" target=\"_blank\" rel=\"noopener\">How hard is it for an exchange to adopt native segwit?<\/a> 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).<\/li>\n<li><a href=\"https:\/\/bitcoin.stackexchange.com\/a\/103159\" target=\"_blank\" rel=\"noopener\">How do you calculate when 98% of Bitcoin will be mined?<\/a> While Murch provides an estimate of 2030-2031 for when 98% of all bitcoins will be mined, he also links to a <a href=\"https:\/\/docs.google.com\/spreadsheets\/d\/12tR_9WrY0Hj4AQLoJYj9EDBzfA38XIVLQSOOOVePNm0\/edit#gid=0\" target=\"_blank\" rel=\"noopener\">reward schedule Google Sheet<\/a> with additional metrics.<\/li>\n<li><a href=\"https:\/\/bitcoin.stackexchange.com\/a\/103402\" target=\"_blank\" rel=\"noopener\">How can I use Bitcoin Core with the anonymous network protocol I2P?<\/a> With the merge of <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/03\/10\/#bitcoin-core-20685\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #20685<\/a>, Bitcoin supports the I2P network. Michael Folkson summarizes <a href=\"https:\/\/twitter.com\/jonatack\/status\/1366764964896075776?s=20\" target=\"_blank\" rel=\"noopener\">Jon Atack\u2019s original thread<\/a> on how to configure Bitcoin Core to use I2P.<\/li>\n<li><a href=\"https:\/\/bitcoin.stackexchange.com\/a\/103104\" target=\"_blank\" rel=\"noopener\">Will nodes with a larger-than-default mempool retransmit transactions that have been dropped from smaller mempools?<\/a> Pieter Wuille notes that transaction rebroadcasting is currently a <a href=\"https:\/\/bitcoin.stackexchange.com\/questions\/103261\/does-my-node-rebroadcast-its-mempool-transactions-on-startup\/103262#103262\" target=\"_blank\" rel=\"noopener\">wallet responsibility<\/a>, that perhaps nodes should also rebroadcast unconfirmed transactions, and points to <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21061\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #21061<\/a> as working toward that goal.<\/li>\n<li><a href=\"https:\/\/bitcoin.stackexchange.com\/a\/103854\" target=\"_blank\" rel=\"noopener\">Should block height or MTP or a mixture of both be used in a soft fork activation mechanism?<\/a> 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.<\/li>\n<li><a href=\"https:\/\/bitcoin.stackexchange.com\/a\/103260\" target=\"_blank\" rel=\"noopener\">Why is it recommended to \u201cnot send round number amounts when making payments\u201d for increased privacy?<\/a> User chytrik provides different examples to illustrate the <a href=\"https:\/\/en.bitcoin.it\/wiki\/Privacy#Round_numbers\" target=\"_blank\" rel=\"noopener\">round number heuristic<\/a> and why avoiding round payment amounts can be better for privacy.<\/li>\n<\/ul>\n<h2>Releases and release candidates<\/h2>\n<p><em>New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/releases\/tag\/v1.0.7.1\" target=\"_blank\" rel=\"noopener\">BTCPay Server 1.0.7.1<\/a> 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.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin-core\/HWI\/releases\/tag\/2.0.1\" target=\"_blank\" rel=\"noopener\">HWI 2.0.1<\/a> is a bugfix release that addresses minor issues with Trezor T passphrase entry and keyboard shortcuts in the hwi-qt user interface.<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/releases\/tag\/v0.10.0rc2\" target=\"_blank\" rel=\"noopener\">C-Lightning 0.10.0-rc2<\/a> is a release candidate for the next major version of this LN node software.<\/li>\n<\/ul>\n<h2>Notable code and documentation changes<\/h2>\n<p><em>Notable changes this week in <\/em><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Core<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/ElementsProject\/lightning\" target=\"_blank\" rel=\"noopener\"><em>C-Lightning<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/ACINQ\/eclair\" target=\"_blank\" rel=\"noopener\"><em>Eclair<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/\" target=\"_blank\" rel=\"noopener\"><em>LND<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-lightning\" target=\"_blank\" rel=\"noopener\"><em>Rust-Lightning<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/bitcoin-core\/secp256k1\" target=\"_blank\" rel=\"noopener\"><em>libsecp256k1<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/bitcoin-core\/HWI\" target=\"_blank\" rel=\"noopener\"><em>Hardware Wallet Interface (HWI)<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/rust-bitcoin\/rust-bitcoin\" target=\"_blank\" rel=\"noopener\"><em>Rust Bitcoin<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/\" target=\"_blank\" rel=\"noopener\"><em>BTCPay Server<\/em><\/a><em>, <\/em><a href=\"https:\/\/github.com\/bitcoin\/bips\/\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Improvement Proposals (BIPs)<\/em><\/a><em>, and <\/em><a href=\"https:\/\/github.com\/lightningnetwork\/lightning-rfc\/\" target=\"_blank\" rel=\"noopener\"><em>Lightning BOLTs<\/em><\/a><em>.<\/em><\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/17227\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #17227<\/a> adds a new make apk target to the build system which packages bitcoin-qt for the Android operating system. This continues <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/11\/13\/#bitcoin-core-16110\" target=\"_blank\" rel=\"noopener\">previous work<\/a> which added support for packaging the Android NDK. Also included are <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/blob\/11840509\/doc\/build-android.md\" target=\"_blank\" rel=\"noopener\">documentation<\/a> for building Bitcoin Core for Android and a <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/blob\/11840509\/.cirrus.yml#L184-L192\" target=\"_blank\" rel=\"noopener\">continuous integration job<\/a> to test the Android build system.<\/li>\n<li>Rust-Lightning #849 makes a channel\u2019s 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\u2019s competitive with other nodes that are trying to minimize possible delays. See also <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/04\/02\/#lnd-2759\" target=\"_blank\" rel=\"noopener\">Newsletter #40<\/a> where LND reduced its value to 40 blocks.<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4427\" target=\"_blank\" rel=\"noopener\">C-Lightning #4427<\/a> makes it possible to experiment with <a href=\"https:\/\/bitcoinops.org\/en\/topics\/dual-funding\/\" target=\"_blank\" rel=\"noopener\">dual funded<\/a> payment channels by using the configuration option &#8211;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.<\/li>\n<li><a href=\"https:\/\/github.com\/ACINQ\/eclair\/issues\/1738\" target=\"_blank\" rel=\"noopener\">Eclair #1738<\/a> updates the penalty enforcement mechanism for revoked <a href=\"https:\/\/bitcoinops.org\/en\/topics\/htlc\/\" target=\"_blank\" rel=\"noopener\">HTLCs<\/a> when <a href=\"https:\/\/bitcoinops.org\/en\/topics\/anchor-outputs\/\" target=\"_blank\" rel=\"noopener\">anchor outputs<\/a> 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 <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/12\/16\/#bolts-803\" target=\"_blank\" rel=\"noopener\">Newsletter #128<\/a>. 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.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bips\/issues\/1080\" target=\"_blank\" rel=\"noopener\">BIPs #1080<\/a> updates <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0008.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP8<\/a> 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 <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/03\/10\/#a-short-duration-attempt-at-miner-activation\" target=\"_blank\" rel=\"noopener\">Newsletter #139<\/a>) that would allow miners to activate <a href=\"https:\/\/bitcoinops.org\/en\/topics\/taproot\/\" target=\"_blank\" rel=\"noopener\">taproot<\/a> but would not begin enforcing taproot\u2019s rules until roughly six months after the release of software implementing Speedy Trial.<\/li>\n<\/ul>\n<p>Find the <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/\" target=\"_blank\" rel=\"noopener\">original post here<\/a><a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/03\/03\/\" target=\"_blank\" rel=\"noopener\">.<\/a> <\/p>\n<p>Please <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/\" target=\"_blank\" rel=\"noopener\">subscribe to the Bitcoin Optech newsletter<\/a> directly to receive this content straight to your inbox every month.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This week\u2019s Bitcoin Optech newsletter discusses the Lightning Network, Q&#038;A from Bitcoin Stack Exchange and other notable updates.<\/p>\n","protected":false},"author":3246,"featured_media":10773,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[2887,508],"class_list":{"0":"post-17224","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-bitcoin-optech","9":"tag-lighting-network"},"author_data":{"id":3246,"name":"Bitcoin Optech","nicename":"bitcoin-optech","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/optech-notext-96x96.png"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/percentage-of-coinjoin-bitcoin-transactions-triples-over-past-year.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/17224","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/3246"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=17224"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/17224\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/10773"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=17224"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=17224"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=17224"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}