Bitcoin Optech # 152: Lightning Node Funds and Extra


The Bitcoin Optech newsletter provides readers with a summary of the most important technical news about Bitcoin, as well as resources to help them learn more. To help our readers stay up to date on Bitcoin, we are posting the latest edition of this newsletter below. Remember to subscribe to get this content straight to your inbox.

This week’s newsletter describes a proposal that would allow LN nodes to receive payments without keeping their private keys online all the time. Also included are our regular sections summarizing 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.


  • Receiving LN payments with a mostly offline private key: In 2019, developer ZmnSCPxj proposed an alternative way to encapsulate outstanding LN payments (HTLCs) that would reduce the network bandwidth and latency required to accept a payment. Recently, Lloyd Fournier suggested that the idea could also be used to allow a node to accept multiple incoming LN payments without keeping its private keys online. The idea has some drawbacks:
    • The node would still need its private keys to send a criminal transaction if necessary.
    • The more payments the node has received without using its private key, the more onchain fees would have to be paid if the channel were unilaterally closed.
    • The receiving node would lose privacy – its immediate peer could find out that it was the ultimate recipient of a payment, not just a routing hop. However, this may already be evident for some end-user nodes that are not forwarding payments.
  • Within these limits, the idea seems workable and variations of it were discussed on the mailing list this week, with ZmnSCPxj preparing a clear presentation. Fournier later suggested improvements to the idea.
    Implementing the idea would require several significant changes to the LN protocol, making it unlikely that users will have access in the short or medium term. However, anyone who wishes to minimize the need for LN receiving nodes to keep their keys online is encouraged to investigate the idea.

Bitcoin Core PR Review Club

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

Prune g_chainman used in auxiliary modules is a refactoring PR (# 21767) by Carl Dong, which is part of a project to de-globalize g_chainman as a first step towards the modularization of the consensus engine. This would decouple components and allow more focused testing. A longer term goal is to completely separate the consensus engine from non-consensus code.

The review club discussion started with the following general questions before delving deeper into the code changes:

  • This PR is a refactoring and should not change any functional behavior. How can we check that?
    Carefully review the code, run the tests, add test coverage, insert asserts or custom logging, create with –enable-debug, run Bitcoind with the changes, and step through the code with debuggers like GDB or LLDB.
  • This PR is part of a larger project to modularize and separate the Bitcoin core consensus engine. What are some of the advantages of this?
    This could make it easier to think about, maintain, configure, and test the code. It could provide a minimal API for security and maintainability, with configuration options to pass non-global data. We could design components with variable parameters that would give more control over testing these objects with different configurations.
  • What is the ChainstateManager responsible for?
    The ChainstateManager class provides an interface for creating and interacting with one or two chainstates: initial block download (IBD) and an optional snapshot.
  • What does CChainState do?
    The CChainState class stores the current best chain and provides an API to update our local knowledge of its state.
  • What is the CChain class?
    The CChain class is a chain of blocks indexed in memory. It contains a vector of block index pointers.
  • What is the BlockManager responsible for?
    The BlockManager class maintains a tree of blocks, stored in m_block_index, that is consulted to find the top of the chain with the most work.
  • What is cs_main?
    cs_main is a mutex that protects validation-specific data (as well as many other things for the time being). The name means critical section main as it protected data in main.cpp, and the code that is now in Validation.cpp and net_processing.cpp was previously in a file called main.cpp).
  • Conceptually, what does this entail when we refer to the “validation” part of the code base?
    The validation stores and keeps our best view of the blockchain and the associated UTXO set. It also includes an interface to send unconfirmed transactions to the mempool.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or help test release candidates.

  • LND 0.13.0-beta.rc5 is a release candidate that supports the use of a pruned Bitcoin full node, enables receiving and sending of payments with Atomic MultiPath (AMP) and, among other improvements and bug fixes, improves its PSBT capabilities.

Notable code and documentation changes

Notable changes this week to 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 # 22051 adds support for importing descriptors for taproot spending into the Bitcoin Core wallet. This PR enables wallet users to receive funds on Taproot issues and is a prerequisite for an open PR that provides full support for users who can receive and spend on Taproot issues.
  • Bitcoin Core # 22050 is discontinuing support for version 2 Tor onion services (hidden services). Version 2 services are already out of date and the Tor project has announced that they will no longer be accessible in September. Bitcoin Core already supports version 3 onion services (see newsletter no.132).
  • Bitcoin Core # 22095 adds a test to check how Bitcoin Core derives BIP32 private keys. Although Bitcoin Core always derived these keys correctly, it was recently discovered that some other wallets incorrectly derived slightly more than 1 in 128 keys by not padding extended private keys (xprivs) less than 32 bytes in length. This does not directly result in a loss of money or a reduction in security, but it does create problems for users who seed an HD wallet in one wallet and import it into another wallet, or create multi-signature wallets. The test vector implemented in this PR will also be added to BIP32 to help future wallet authors avoid this problem.
  • C-Lightning # 4532 adds experimental support for updating a channel – rebuilding the last commitment transaction so it can incorporate new features or structural changes, such as: B. the switch to the use of Taproot. The log begins with a shutdown request, an agreement that neither party will send new status updates until the shutdown period is complete. During this time, the nodes negotiate the desired changes and implement them. Eventually the channel is put back into full operation. C-Lightning currently implements this during reconnection if the channel has already been in a period of forced inactivity. Various suggestions for channel upgrades were discussed in Newsletter No. 108 and the author of this PR would like the feature to work in part on the “simplified HTLC negotiation” described in Newsletter No. 109. This special PR makes it possible to update old channels to support option_static_remotekey, for which C-Lightning added support for the first time in 2019, see newsletter # 64.
  • LND # 5336 allows users to non-interactively reuse AMP invoices by specifying a new payment secret. The default invoicing flow for AMP invoices generated by LND will also be increased to 30 days to facilitate the above reuse mechanism.
  • BTCPay Server # 2474 adds the ability to test webhooks by sending fake events that contain all of their normal fields but dummy data. This reflects the testing capabilities available on centrally hosted Bitcoin payment processors such as Stripe and Coinbase Commerce.

You can find the original article here.

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

Leave A Reply

Your email address will not be published.