{"id":16155,"date":"2021-06-09T20:20:15","date_gmt":"2021-06-09T20:20:15","guid":{"rendered":"http:\/\/ci02853dbc4000270d"},"modified":"2025-10-02T10:06:42","modified_gmt":"2025-10-02T15:06:42","slug":"bitcoin-optech-lightning-node-payments","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-optech-lightning-node-payments","title":{"rendered":"Bitcoin Optech #152: Lightning Node Payments And More"},"content":{"rendered":"<div id=\"bsf_rt_marker\"><\/div><p><em>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&#8217;re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.<\/em><\/p>\n<p>This week\u2019s newsletter describes a proposal to allow LN nodes to receive payments without keeping their private keys online all the time. Also included are our regular sections with the summary of a Bitcoin Core PR Review Club meeting, announcements of new software releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.<\/p>\n<h2>News<\/h2>\n<ul>\n<li>Receiving LN payments with a mostly offline private key: in 2019, developer ZmnSCPxj <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/lightning-dev\/2019-April\/001986.html\" target=\"_blank\" rel=\"noopener\">proposed<\/a> an alternative way to encapsulate pending LN payments (<a href=\"https:\/\/bitcoinops.org\/en\/topics\/htlc\/\" target=\"_blank\" rel=\"noopener\">HTLCs<\/a>) that would reduce the amount of network bandwidth and latency required to accept a payment. More recently, Lloyd Fournier suggested the idea could also be used to allow a node to accept multiple incoming LN payments without keeping its private keys online. The idea does have some downsides:<\/li>\n<ul>\n<li>The node would still need its private keys to send a penalty transaction if necessary.<\/li>\n<li>The more payments the node received without using its private key, the more onchain fees would need to be paid if the channel was unilaterally closed.<\/li>\n<li>The receiving node would lose privacy\u2014its immediate peer would be able to determine that it was the ultimate receiver of a payment and not just a routing hop. However, for some end-user nodes that don\u2019t route payments, this may already be obvious.<\/li>\n<\/ul>\n<li>Within those limitations, the idea seems workable and variations of it received <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/lightning-dev\/2021-May\/003038.html\" target=\"_blank\" rel=\"noopener\">discussion<\/a> on the mailing list this week, with ZmnSCPxj preparing a clear <a href=\"https:\/\/zmnscpxj.github.io\/offchain\/2021-06-fast-forwards.odp\" target=\"_blank\" rel=\"noopener\">presentation<\/a>. Fournier later <a href=\"https:\/\/lists.linuxfoundation.org\/pipermail\/lightning-dev\/2021-June\/003045.html\" target=\"_blank\" rel=\"noopener\">suggested<\/a> improvements to the idea.<br \/>Implementing the idea would require several significant LN protocol changes, so it seems unlikely to be something users will have access to in either the short or medium term. However, anyone looking to minimize the need for LN receiving nodes to keep their keys online is encouraged to investigate the idea.<\/li>\n<\/ul>\n<h2>Bitcoin Core PR Review Club<\/h2>\n<p><em>In this monthly section, we summarize a recent <\/em><a href=\"https:\/\/bitcoincore.reviews\/\" target=\"_blank\" rel=\"noopener\"><em>Bitcoin Core PR Review Club<\/em><\/a><em> meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.<\/em><\/p>\n<p><a href=\"https:\/\/bitcoincore.reviews\/21767\" target=\"_blank\" rel=\"noopener\">Prune g_chainman usage in auxiliary modules<\/a> is a refactoring PR (<a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21767\" target=\"_blank\" rel=\"noopener\">#21767<\/a>) by Carl Dong that is part of a project to de-globalize g_chainman as a first step toward modularizing the consensus engine. This would decouple components and enable more focused testing. A longer-term goal is to completely separate the consensus engine from non-consensus code.<\/p>\n<p>The review club discussion began with the following general questions before diving deeper into the code changes:<\/p>\n<ul>\n<li>This PR is a refactoring and should not change any functional behaviour. What are some ways we can verify that?<br \/>Reviewing the code carefully, running the tests, adding test coverage, inserting asserts or custom logging, building with &#8211;enable-debug, running bitcoind with the changes, and stepping through the code with debuggers like GDB or LLDB.\n<\/li>\n<li>This PR is part of a larger project to modularize and separate the Bitcoin Core consensus engine. What are some benefits of doing that?<br \/>This could make it easier to reason about, maintain, configure and test the code. It could expose a minimal API for security and maintainability, with configuration options to pass non-global data. We could construct components with variable parameters, providing more control over testing those objects with different configurations.\n<\/li>\n<li>What is the ChainstateManager responsible for?<br \/>The <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/blob\/7a799c9\/src\/validation.h#L759\" target=\"_blank\" rel=\"noopener\"><em>ChainstateManager<\/em><\/a> class provides an interface for creating and interacting with one or two chainstates: initial block download (IBD) and an optional snapshot.\n<\/li>\n<li>What does CChainState do?<br \/>The <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/blob\/7a799c9\/src\/validation.h#L502\" target=\"_blank\" rel=\"noopener\"><em>CChainState<\/em><\/a> class stores the current best chain and provides an API to update our local knowledge of its state.\n<\/li>\n<li>What is the CChain class?<br \/>The <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/blob\/7a799c9\/src\/chain.h#L391\" target=\"_blank\" rel=\"noopener\"><em>CChain<\/em><\/a> class is an in-memory indexed chain of blocks. It contains a <a href=\"https:\/\/bitcoincore.reviews\/21767#l-196\" target=\"_blank\" rel=\"noopener\"><em>vector of block index pointers<\/em><\/a>.\n<\/li>\n<li>What is the BlockManager responsible for?<br \/>The <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/blob\/7a799c9\/src\/validation.h#L343\" target=\"_blank\" rel=\"noopener\"><em>BlockManager<\/em><\/a> class maintains a tree of blocks stored in m_block_index that is consulted to locate the most-work chain tip.\n<\/li>\n<li>What is cs_main?<br \/>cs_main is a mutex that protects validation-specific data (as well as, for now, many other things). The name means <a href=\"https:\/\/bitcoincore.reviews\/21767#l-216\" target=\"_blank\" rel=\"noopener\"><em>critical section main<\/em><\/a>, as it protected data in main.cpp, and the code that is now in validation.cpp and net_processing.cpp <a href=\"https:\/\/bitcoincore.reviews\/21767#l-213\" target=\"_blank\" rel=\"noopener\"><em>used to be in one file called <\/em><em>main.cpp<\/em><\/a>).\n<\/li>\n<li>Conceptually, when we refer to the \u201cvalidation\u201d part of the codebase, what does that include?<br \/>Validation stores and maintains our best view of the block chain and associated UTXO set. It also includes an interface to submit unconfirmed transactions to the mempool.<\/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\/lightningnetwork\/lnd\/releases\/tag\/v0.13.0-beta.rc5\" target=\"_blank\" rel=\"noopener\">LND 0.13.0-beta.rc5<\/a> is a release candidate that adds support for using a pruned Bitcoin full node, allows receiving and sending payments using Atomic MultiPath (<a href=\"https:\/\/bitcoinops.org\/en\/topics\/multipath-payments\/\" target=\"_blank\" rel=\"noopener\">AMP<\/a>), and increases its <a href=\"https:\/\/bitcoinops.org\/en\/topics\/psbt\/\" target=\"_blank\" rel=\"noopener\">PSBT<\/a> capabilities, among other improvements and bug fixes.<\/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\/22051\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #22051<\/a> adds support for importing <a href=\"https:\/\/bitcoinops.org\/en\/topics\/output-script-descriptors\/\" target=\"_blank\" rel=\"noopener\">descriptors<\/a> for <a href=\"https:\/\/bitcoinops.org\/en\/topics\/taproot\/\" target=\"_blank\" rel=\"noopener\">taproot<\/a> outputs into the Bitcoin Core wallet. This PR allows wallet users to receive funds to taproot outputs and is the prerequisite for an <a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/21365\" target=\"_blank\" rel=\"noopener\">open PR<\/a> that implements full support for users to receive to and spend from taproot outputs.<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/22050\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #22050<\/a> drops support for version 2 Tor onion services (hidden services). Version 2 services are already deprecated and the Tor project has announced that they\u2019ll become inaccessible in September. Bitcoin Core already supports version 3 onion services (see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/01\/20\/#bitcoin-core-0-21-0\" target=\"_blank\" rel=\"noopener\">Newsletter #132<\/a>).<\/li>\n<li><a href=\"https:\/\/github.com\/bitcoin\/bitcoin\/issues\/22095\" target=\"_blank\" rel=\"noopener\">Bitcoin Core #22095<\/a> adds a test to check how Bitcoin Core derives <a href=\"https:\/\/github.com\/bitcoin\/bips\/blob\/master\/bip-0032.mediawiki\" target=\"_blank\" rel=\"noopener\">BIP32<\/a> private keys. Although Bitcoin Core has always derived these keys correctly, it was recently <a href=\"https:\/\/github.com\/btcsuite\/btcutil\/issues\/172\" target=\"_blank\" rel=\"noopener\">discovered<\/a> that some other wallets were incorrectly deriving slightly more than 1 out of 128 keys by failing to pad extended private keys (xprivs) that were less than 32 bytes long. This doesn\u2019t directly result in a loss of funds or a reduction in security, but it does create problems for users who create an HD wallet seed in one wallet and import it into another wallet or who create multisignature wallets. The test vector implemented in this PR is also being <a href=\"https:\/\/github.com\/bitcoin\/bips\/issues\/1030\" target=\"_blank\" rel=\"noopener\">added<\/a> to BIP32 to help future wallet authors avoid this issue.<\/li>\n<li><a href=\"https:\/\/github.com\/ElementsProject\/lightning\/issues\/4532\" target=\"_blank\" rel=\"noopener\">C-Lightning #4532<\/a> adds experimental support for <a href=\"https:\/\/github.com\/lightningnetwork\/lightning-rfc\/issues\/868\" target=\"_blank\" rel=\"noopener\">upgrading a channel<\/a>\u2014rebuilding the latest commitment transaction so that it can incorporate new features or structural changes, e.g. converting to using <a href=\"https:\/\/bitcoinops.org\/en\/topics\/taproot\/\" target=\"_blank\" rel=\"noopener\">taproot<\/a>. The protocol starts with a request for quiescence, an agreement that neither party will send any new state updates until the quiescence period is completed. During this period, the nodes negotiate the changes they want to make and implement them. Finally, the channel is restored to full operation. C-Lightning currently implements this during connection reestablishment when the channel has already been in a period of forced inactivity. Various proposals for channel upgrades were discussed in <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/07\/29\/#upgrading-channel-commitment-formats\" target=\"_blank\" rel=\"noopener\">Newsletter #108<\/a> and the author of this PR wants the feature in part to work on the \u201csimplified HTLC negotiation\u201d described in <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2020\/10\/21\/#simplified-htlc-negotiation\" target=\"_blank\" rel=\"noopener\">Newsletter #109<\/a>. This particular PR allows upgrading old channels to support option_static_remotekey, which C-Lightning first added support for in 2019, see <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2019\/09\/18\/#c-lightning-3010\" target=\"_blank\" rel=\"noopener\">Newsletter #64<\/a>.<\/li>\n<li><a href=\"https:\/\/github.com\/lightningnetwork\/lnd\/issues\/5336\" target=\"_blank\" rel=\"noopener\">LND #5336<\/a> adds the ability for users to reuse <a href=\"https:\/\/bitcoinops.org\/en\/topics\/multipath-payments\/\" target=\"_blank\" rel=\"noopener\">AMP<\/a> invoices non-interactively by specifying a new payment secret. The default invoice expiry for AMP invoices created by LND is also bumped to 30 days in order to facilitate the aforementioned reuse mechanism.<\/li>\n<li><a href=\"https:\/\/github.com\/btcpayserver\/btcpayserver\/issues\/2474\" target=\"_blank\" rel=\"noopener\">BTCPay Server #2474<\/a> adds the ability to test webhooks by sending fake events that contain all their normal fields but dummy data. This mirrors testing features available on centrally hosted Bitcoin payment processors such as Stripe and Coinbase Commerce.<\/li>\n<\/ul>\n<p>Find the <a href=\"https:\/\/bitcoinops.org\/en\/newsletters\/2021\/06\/09\/\" target=\"_blank\" rel=\"noopener\">original post here.<\/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 newsletter describes a LN node payment proposal, Bitcoin Core PR Review Club meeting and more.<\/p>\n","protected":false},"author":3246,"featured_media":10844,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[2887,130,2935],"class_list":{"0":"post-16155","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-bitcoin-optech","9":"tag-lightning","10":"tag-optech"},"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\/cybersecurity-firm-reports-all-fortune-500-companies-exposed-on-the-dark-web.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/16155","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=16155"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/16155\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/10844"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=16155"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=16155"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=16155"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}