Bitcoin Optech #152: Lightning Node Payments And More

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’re republishing the latest issue 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 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.

News

• Receiving LN payments with a mostly offline private key: in 2019, developer ZmnSCPxj proposed an alternative way to encapsulate pending LN payments (HTLCs) 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:

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 onchain fees would need to be paid if the channel was unilaterally closed.

The receiving node would lose privacy—its 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’t route payments, this may already be obvious.

• Within those limitations, the idea seems workable and variations of it received discussion 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 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.

Bitcoin Core PR Review Club

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

Prune g_chainman usage in auxiliary modules is a refactoring PR (#21767) 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.

The review club discussion began with the following general questions before diving deeper into the code changes:

• This PR is a refactoring and should not change any functional behaviour. What are some ways we can verify that?Reviewing the code carefully, running the tests, adding test coverage, inserting asserts or custom logging, building with –enable-debug, running bitcoind with the changes, and stepping 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 benefits of doing that?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.

• 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 an in-memory indexed chain of blocks. 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 locate the most-work chain tip.

• What is cs_main?cs_main is a mutex that protects validation-specific data (as well as, for now, many other things). 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 used to be in one 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 block chain and associated UTXO set. It also includes an interface to submit 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 helping to test release candidates.

• LND 0.13.0-beta.rc5 is a release candidate that adds support for using 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 code and documentation changes

Notable changes this week in 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 outputs into the Bitcoin Core wallet. This PR allows wallet users to receive funds to taproot outputs and is the prerequisite for an open PR that implements full support for users to receive to and spend from taproot outputs.

• Bitcoin Core #22050 drops support for version 2 Tor onion services (hidden services). Version 2 services are already deprecated and the Tor project has announced that they’ll become inaccessible in September. Bitcoin Core already supports version 3 onion services (see Newsletter #132).

• Bitcoin Core #22095 adds a test to check how Bitcoin Core derives BIP32 private keys. Although Bitcoin Core has always derived these keys correctly, it was recently discovered 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’t 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 added to BIP32 to help future wallet authors avoid this issue.

• C-Lightning #4532 adds experimental support for upgrading a channel—rebuilding the latest commitment transaction so that it can incorporate new features or structural changes, e.g. converting to using taproot. 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 Newsletter #108 and the author of this PR wants the feature in part to work on the “simplified HTLC negotiation” described in Newsletter #109. This particular PR allows upgrading old channels to support option_static_remotekey, which C-Lightning first added support for in 2019, see Newsletter #64.

• LND #5336 adds the ability for users to reuse AMP 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.

• BTCPay Server #2474 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.

Find the original post here.

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

Bitcoin Optech #148: A Security Disclosure Affecting Protocols

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’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s newsletter describes a security disclosure affecting protocols depending on a certain BIP125 opt-in replace by fee behavior and includes 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.

News

• CVE-2021-31876 discrepancy between BIP125 and Bitcoin Core implementation: the BIP125 specification of opt-in Replace By Fee (RBF) says that an unconfirmed parent transaction that signals replaceability makes any child transactions that spend the parent’s outputs also replaceable through inferred inheritance. This week, Antoine Riard posted to the Bitcoin-Dev mailing list the full disclosure of his previously privately reported finding that Bitcoin Core does not implement this behavior. It is still possible for child transactions to be replaced if they explicitly signal replaceability or for them to be evicted from the mempool if their parent transaction is replaced.Riard analyzed how the inability to use inherited replaceability might affect various current and proposed protocols. Only LN appears to be affected and only in the sense that an existing attack (see Newsletter #95) that uses pinning becomes cheaper. The ongoing deployment of anchor outputs by various LN implementations will eliminate the ability to perform that pinning.As of this writing, there has not been any substantial discussion of the issue on the mailing list.

• Call for Brink grant applications: Bitcoin Optech encourages any engineer contributing to open source Bitcoin or Lightning projects to apply for a Brink grant before the application deadline on May 17th. Initial grants are one year long and allow developers to work full time on open source projects from anywhere in the world.

Bitcoin Core PR Review Club

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

Introduce node rebroadcast module is a PR (#21061) by Amiti Uttarwar that continues work on the rebroadcast project (see Newsletters #64, #96, #129 and #142), previously discussed in review clubs #16698 and #18038, whose goal is to make node rebroadcast behavior for wallet transactions indistinguishable from that of other peers’ transactions.

The review club discussion focused on current transaction behavior and the proposed changes:

• Why might we want to rebroadcast a transaction? When our transaction didn’t propagate (perhaps our node was offline) or appears to have been dropped by other nodes’ mempools in the network.

• Why does a node drop a transaction from its mempool? Apart from being included in a block, a transaction can expire after 14 days, be squeezed out of a node’s limited mempool size (default size 300 MiB) by higher-fee transactions, be replaced via BIP125 opt-in Replace-By-Fee (RBF), be removed if a conflicting transaction is included in a block, or be included in a block that is later reorged out (in which case the node will try to re-add it while updating the mempool to be consistent again after the reorg).

• What could be an issue with the current behavior of each wallet being responsible for rebroadcasting its own transactions? This can be a privacy leak that allows linking the IP address to the wallet address, as under the current rebroadcasting behavior, a node that broadcasts a transaction more than once is essentially announcing that the transaction is from its wallet.

• When might a miner exclude a transaction that is in our mempool? When the miner deprioritized it for having a low fee, didn’t see it yet, removed it from its mempool by RBF, censored it, or mined an empty block.

• When might a miner include a transaction that is not in our mempool? When the miner manually prioritized the transaction (e.g. as a commercial service), received it before our node, or the transaction conflicted with another one in our mempool but not in theirs.

• How would the proposal under review decide which transactions to rebroadcast?Once per new block, it proposes to rebroadcast transactions above an estimated feerate that are at least 30 minutes old, have been rebroadcast no more than 6 times and not more recently than 4 hours ago, with up to 3/4 of the transactions that fit the block.

• Why might we want to keep a transaction in our rebroadcast attempt tracker even after it has been removed from our mempool? After a consensus rule change, there can be non-updated nodes on the network rebroadcasting transactions that don’t meet the new consensus rules. Keeping transactions in the rebroadcast attempt tracker would avoid these nodes rebroadcasting them too many times (a maximum of 6 times over 90 days) and allow the transactions to expire.

• When would we remove a transaction from our rebroadcast attempt tracker? When the transaction is confirmed, RBFed, or conflicts with another transaction included in a block.

• How would the estimated minimum feerate for rebroadcast be calculated? Why not use the lowest feerate in the last mined block? The rebroadcast feerate floor would be estimated once a minute by assembling a block from the mempool to simulate inclusion in the next mined block. This approach is better than using the lowest feerate of the last mined block because it calculates fees based on the immediate future in a changing environment instead of based on the past.

Releases and release candidates

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

• Rust-Lightning 0.0.14 is a new release that makes Rust Lightning more compatible with getting data from Electrum-style servers, adds additional configuration options, and improves compliance with the LN specification, among other bug fixes and improvements.

Notable code and documentation changes

Notable changes this week in 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 #20867 increases the number of keys that can be included in multisig descriptors and used in the addmultisigaddress and createmultisig RPCs from 16 to 20. The increased limit can only be used in P2WSH outputs. P2SH outputs are limited to 520 byte scripts which are only large enough to hold 15 compressed public keys.

• Bitcoin Core GUI #125 enables users to adjust the autoprune block space size from the default in the intro dialog. It also adds an improved description for how the pruned storage works, clarifying that the entire blockchain must be downloaded and processed but will be discarded in the future to keep disk usage low.

• C-Lightning #4489 adds a funder plugin for configuring dual-funding contribution behavior in response to incoming channel open requests. Users will be able to specify a general contribution policy (percent match, percent available funds, or fixed contribution), a wallet reserve amount under which no dual-funding contributions will happen, a maximum contribution amount for any single channel open request, and more.This PR represents the last step in enabling experimental dual-funding support between C-Lightning nodes. The interactive transaction construction and channel establishment v2 protocols arising out of this work is still being standardized in the open BOLTs #851 PR.

• C-Lightning #4496 adds the ability for plugins to register topics about which they plan to publish notifications. Other plugins can subscribe to those topics to receive notifications. C-Lightning already had several built-in topics, but this merged PR allows plugin authors to create and consume notifications for any new topic category they’d like to use.

• Rust Bitcoin #589 starts the process of implementing support for taproot with schnorr signatures. The existing ECDSA support is moved to a new module but continues to be exported under existing names to preserve API compatibility. A new util::schnorr module adds support for BIP340 schnorr key encodings. Issue #588 is being used to track the complete implementation of taproot compatibility.

Find the original post here.

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