The Bitcoin Optech newsletter provides readers with a high-level summary of the most important technical news happening in Bitcoin, along with resources to help them learn more. To help our readers stay current on Bitcoin, we are republishing the latest issue of this newsletter below. Remember to subscribe to receive this content directly to your inbox.
This week’s 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 a 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.
- Receive LN Payments With Private Key Mostly Offline – In 2019 Developer ZmnSCPxj proposed an alternative way to encapsulate pending LN payments (HTLC) that would reduce the amount of network bandwidth and latency required to accept a payment. More recently, Lloyd Fournier suggested that the idea could also be used to allow a node to accept multiple incoming payments from LN without keeping its private keys online. The idea has some downsides:
- The node would still need its private keys to send a penalty transaction if necessary.
- The more payments the node received without using its private key, the more fees on the chain would have to be paid if the channel were unilaterally closed.
- The receiving node would lose privacy – its immediate peer could determine that it is the final recipient of a payment and not just a routing hop. However, for some end-user nodes that do not route payments, this may be obvious.
- Within these limitations, the idea seems viable and variations of it received discussion on the mailing list this week, with ZmnSCPxj preparing a clear presentation. Fournier later He suggested improvements to the idea.
Implementing the idea would require several significant changes to the LN protocol, so it seems unlikely that it will be something that users will have access to in the short to medium term. However, anyone looking to minimize the need for LN receiving nodes to keep their keys online is encouraged to research the idea.
Bitcoin Core PR Review Club
In this monthly section, we summarize a Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on one of the questions below to view a summary of the meeting response.
Eliminate the use of g_chainman 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 modularizing the consensus engine. This would decouple components and allow for more focused testing. A longer term goal is to completely separate the consensus engine from the non-consensus code.
The review club discussion began with the following general questions before delving into the code changes:
- This RP is a refactoring and should not change any functional behavior. What are some ways we can verify that?
Review the code carefully, run the tests, add test coverage, insert assertions or custom registers, compile with –enable-debug, run bitcoind with the changes, and walk through the code with debuggers like GDB or LLDB.
- This RP is part of a larger project to modularize and separate the consensus engine from Bitcoin Core. What are some of the benefits of doing that?
This could make it easier to reason, maintain, configure, and test your code. You could expose a minimal API for security and maintenance, with configuration options to pass non-global data. We could build components with variable parameters, providing more control over testing those objects with different settings.
- What is the ChainstateManager responsible for?
The ChainstateManager The class provides an interface to create and interact with one or two states of the chain: initial block download (IBD) and an optional snapshot.
- What does CChainState do?
The CChainState class stores the current best string and provides an API to update our local knowledge of its state.
- What is the CChain class?
The CChain class is a blockchain indexed in memory. Contains a block index pointers vector.
- What is BlockManager responsible for?
The BlockManager The class maintains a tree of blocks stored in m_block_index that is queried to locate the tip of the chain with the greatest work.
- What is cs_main?
cs_main is a mutex that protects specific validation data (as well as many other things for now). The name means main critical section, since you protected the data in main.cpp, and the code that is now in validation.cpp and net_processing.cpp it used to be in a file called main.cpp).
- Conceptually, when we refer to the “validation” part of the codebase, what does that include?
Validation stores and maintains 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 launches and launch candidates for popular Bitcoin infrastructure projects. Consider upgrading to new versions or helping to test the candidate versions.
- LND 0.13.0-beta.rc5 is a release candidate that adds support for the use of a pruned Bitcoin full node, allows receiving and sending payments using Atomic MultiPath (AMP), and increases its PSBT capabilities, among other improvements and bug fixes.
Notable changes to code and documentation
Notable changes this week in Bitcoin Core, C-Ray, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Bitcoin rust, BTCPay server, Bitcoin Improvement Proposals (BIP), Y Lightning bolts.
- Bitcoin Core # 22051 adds import support descriptors for main root outputs in the Bitcoin Core wallet. This PR allows wallet users to receive funds to generate results and is the prerequisite for a open public relations which implements full support for users to receive and spend from the results of the main root.
- Bitcoin Core # 22050 removes support for onion Tor version 2 services (hidden services). Version 2 services are already obsolete and the Tor project has announced that they will be inaccessible in September. Bitcoin Core now supports version 3 onion services (see Bulletin No. 132).
- Bitcoin Core # 22095 add a test to check how Bitcoin Core is derived BIP32 private keys. Although Bitcoin Core has always derived these keys correctly, it was recently discovered that some other wallets incorrectly derived slightly more than 1 of the 128 keys by not padding extended private keys (xprivs) that were less than 32 bytes in length. This does not directly result in loss of funds or reduced security, but creates problems for users creating HD wallet seed in one wallet and importing it to another wallet or creating multi-signature wallets. The test vector implemented in this RP is also being additional to BIP32 to help future wallet authors avoid this problem.
- C-Ray # 4532 adds experimental support for update a channel—Rebuild the last commit transaction so that you can incorporate new features or structural changes, for example, convert to use main root. The protocol begins with a request for stillness, an agreement that neither party will send new state updates until the inactivity period is complete. 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 forced idle period. Various proposals for channel updates were discussed at Bulletin # 108 and the author of this PR wants the function to work in part in the “simplified HTLC negotiation” described in Bulletin # 109. This particular PR allows updating old channels to support option_static_remotekey, for which C-Lightning first added support in 2019, see Bulletin No. 64.
- LND # 5336 adds the ability for users to reuse AMP invoices non-interactively by specifying a new payment secret. The default invoice due date for AMP invoices created by LND is also extended to 30 days to facilitate the aforementioned reuse mechanism.
- BTCPay Server # 2474 adds the ability to test webhooks by sending fake events that contain all your normal fields but dummy data. This reflects the testing features available in centrally hosted Bitcoin payment processors such as Stripe and Coinbase Commerce.
Find the original post here.
Please subscribe to the Bitcoin Optech newsletter directly to receive this content directly to your inbox every month.