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 up to date with Bitcoin, we’re republishing the latest edition of this newsletter below. Remember to subscribe to receive this content straight 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 the Bitcoin Core PR Review Club meeting summary, announcements of new software releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software
- Receiving LN Payments with a Private Key Mostly Offline: In 2019, developer ZmnSCPxj Suggestion An alternative way to encapsulate pending LN payments (HTLCs) would reduce the amount of network bandwidth and response time 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 downsides:
- The node will still need its private keys to send a penal transaction if necessary.
- The more payments a node receives without using its private key, the more onchain fees will have to be paid if the channel is closed unilaterally.
- The receiving node will lose privacy – its direct counterpart will be able to determine if it is the final recipient of the push and not just a routing hop. However, for some end user nodes that do not route payments, this may already be evident.
- Within these constraints, the idea seems viable and various forms have been received from it Discussion On the mailing list this week, with a clear ZmnSCPxj setup Show. Fournier later I suggested Idea improvements.
Implementing the idea would require several significant changes to the LN protocol, so it seems unlikely that it will be something users will be able to access in the short or medium term. However, anyone looking to reduce the need for LN receiving nodes to keep their keys online is encouraged to investigate the idea.
Bitcoin Core Review Club PR
In this monthly section, we summarize another Bitcoin Core Review Club PR Meeting, highlighting some important questions and answers. Click on a question below to see a summary of the answer from the meeting.
Trim g_chainman usage in auxiliary modules is a public relations debt rebuilding (# 21767) by Carl Dong and is part of a project to deglobalize g_chainman as a first step toward forming a consensus engine. This will separate the components and enable more focused testing. The long-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 we delved into the code changes:
- This PR is a debt rebuilding and should not change any job behaviour. What are some ways we can verify this?
Carefully review the code, run tests, add test coverage, enter assertions or custom logging, build with –enable-debug, run bitcoind with changes, and navigate through code with debuggers like GDB or LLDB.
- This PR is part of a larger project to unify and decouple the Bitcoin Core consensus engine. What are some of the benefits of doing this?
This can make the code easier to think about, maintain, configure, and test. It can expose a minimal API for security and maintainability, with configuration options to pass non-global data. We can create components with variable parameters, providing more control over testing those objects with different configurations.
- What is the responsibility of the ChainstateManager?
The chinastatemanager class provides an interface for creating and interacting with one or two chain states: an initial block download (IBD) and an optional snapshot.
- What does CCainState do?
The CCainState class stores the currently best string and provides an API to update our local knowledge of its state.
- What is a CCain class?
The CCchain class is a block chain that is indexed in memory. contains a file vector block indices.
- What is responsible for BlockManager?
The BlockManager The class maintains a tree of blocks stored in m_block_index that are referenced to determine which end of the working thread is the most.
- What is cs_main?
cs_main is the mutex that protects the data for validation (as well as many other things at the moment). The name means major critical section, because it protects the data in main.cpp, and the code is now in validation.cpp and net_processing.cpp It used to be in one file called main.cpp).
- Conceptually, when we refer to the “verification” part of the code base, what does that include?
Validation stores and maintains our best view of the block chain and its associated UTXO set. It also includes an interface for sending unconfirmed transactions to mempool.
Releases and releases candidates
New Releases and Candidate Releases for Popular Bitcoin Infrastructure Projects. Please consider upgrading to new releases or help test release candidates.
- LND 0.13.0 beta. rc5 It is a release filter that adds support for using a full-trimmed Bitcoin node, and allows receiving and sending payments using Atomic MultiPath (AMP), and more than PSBT capabilities, among other improvements and bug fixes.
Notable changes to code and documentation
Notable changes this week in Bitcoin CoreAnd the C- lightningAnd the EclairAnd the LNDAnd the rust and lightningAnd the libsecp256k1And the Hardware Wallet Interface (HWI)And the rust bitcoinAnd the BTCPay serverAnd the Bitcoin Improvement Proposals (BIPs), And the lightning bolt.
- Bitcoin Core #22051 Adds support for import Descriptors to root Outputs in a Bitcoin Core wallet. This PR allows wallet users to receive funds for the output of the main root and is a prerequisite for open public relations Which implements full support for users to receive and spend from the main root output.
- Bitcoin Core #22050 Support for version 2 of the Tor onion services (hidden services) drops. Version 2 services have already been discontinued and the Tor Project announced that they would be inaccessible in September. Bitcoin Core already supports version 3 of the Onion Services (see Newsletter No. 132).
- Bitcoin Core #22095 Adds a test to check how Bitcoin Core is derived BIP32 private keys. Although Bitcoin Core has always correctly derived these keys, it was only recently Discover that some other wallets were improperly deriving a little more than 1 out of 128 keys by failing at the extended private keypad (xprivs) of less than 32 bytes in length. This does not directly lead to a loss of funds or reduced security, but creates problems for users who create HD wallets in one wallet and import into another or who create wallets with multiple signatures. The test vector applied in this PR is also implemented added to BIP32 to help future wallet authors avoid this problem.
- Sea-lightning #4532 Adds experimental support for channel upgrade—Rebuild the latest commit transaction so that it can incorporate new features or structural changes, such as converting to use root. The protocol begins with a request calm, an agreement that neither party will send any new status updates until the dormancy period is complete. During this period, the contract negotiates and implements the changes you want to make. Finally, the channel has been restored to full operation. C-Lightning currently performs this during reconnection when the channel is already in a period of forced inactivity. Various proposals to upgrade the channel are discussed in Newsletter #108 The author of this PR wants the feature to work in part on the “Simplified HTLC Negotiations” described in Newsletter No. 109. This private PR allows for upgrading legacy channels to support option_static_remotekey, which C-Lightning first added support in 2019, see Newsletter No. 64.
- LND #5336 Adds users’ ability to reuse AMP Invoicing non-interactively by selecting a new payment secret. The default invoice expiration for AMP invoices generated by LND is also overridden to 30 days to facilitate the above reuse mechanism.
- BTCPay server #2474 Adds the ability to test webhooks by sending dummy events containing all normal fields but dummy data. These mirror-testing features are available on centrally hosted Bitcoin payment processors such as Stripe and Coinbase Commerce.
Excuse me Subscribe to the Bitcoin Optech Newsletter Direct to receive this content straight to your inbox every month.