This week’s newsletter discloses a past vulnerability affecting Core Lightning, announces two new soft fork proposals, provides an overview of the cluster mempool proposal, relays information about an updated specification and implementation of transaction compression, and summarizes a discussion about Miner Extractable Value (MEV) in non-zero ephemeral anchors. Also included are our regular sections with the announcements of new releases and descriptions of notable changes to popular Bitcoin infrastructure software.

News

• ● Disclosure of past vulnerability in Core Lightning: Matt Morehouse used Delving Bitcoin to announce a vulnerability he had previously responsibly disclosed that affected Core Lightning versions 23.02 through 23.05.2. More recent versions of 23.08 or higher are not affected.

  The new vulnerability was discovered by Morehouse’s following up on his prior work on fake funding, which he also responsibly disclosed (see Newsletter #266). When re-testing nodes that had implemented fixes for fake funding, he triggered a race condition that crashed CLN with about 30 seconds of effort. If an LN node is offline, it can’t defend a user against malicious or broken counterparties, which puts the user’s funds at risk. Analysis indicated that CLN had fixed the original fake funding vulnerability but was unable to safely include a test for it before the vulnerability was disclosed, resulting in the subsequent merge of a plugin introducing the exploitable race condition. After Morehouse’s disclosure, a quick patch was merged in CLN to prevent the race condition from crashing the node.

  For more information, we recommend reading Morehouse’s excellent full disclosure blog post.

• ● New LNHANCE combination soft fork proposed: Brandon Black posted to Delving Bitcoin details about a soft fork that combines previous proposals for OP_CHECKTEMPLATEVERIFY (CTV) and OP_CHECKSIGFROMSTACK (CSFS) with a new proposal for an OP_INTERNALKEY that places the taproot internal key on the stack. Authors of scripts must know the internal key before they can pay to an output, so they could directly include an internal key in a script. However, OP_INTERNALKEY is a simplified version of an old suggestion from CTV’s original author, Jeremy Rubin, to save several vbytes and potentially make scripts more reusable by allowing the value of the key to be retrieved from the script interpreter.

  In the thread, Black and others describe some of the protocols that would be enabled by this combination of consensus changes: LN-Symmetry (eltoo), Ark-style joinpools, reduced-signature DLCs, and vaults without presigned transactions, among other described benefits of the underlying proposals, such as CTV-style congestion control and CSFS-style signature delegation.

  As of this writing, technical discussion was limited to the request about what protocols the combination proposal would enable.

• ● Proposal for 64-bit arithmetic soft fork: Chris Stewart posted a draft BIP to Delving Bitcoin for enabling 64-bit arithmetic operations on Bitcoin in a future soft fork. Bitcoin currently only allows 32-bit operations (using signed integers, so numbers over 31 bits can’t be used). Support for 64-bit values would be especially useful in any construction that needs to operate on the number of satoshis paid in an output, as that is specified using a 64-bit integer. For example, joinpool exit protocols would benefit from amount introspection (see Newsletters #166 and #283).

  As of this writing, discussion was focused on details of the proposal, such as how to encode the integer value, what taproot upgrade feature to use, and whether creating a new set of arithmetic opcodes is preferred to upgrading existing ones.

• ● Overview of cluster mempool proposal: Suhas Daftuar posted a summary of the cluster mempool proposal to Delving Bitcoin. Optech attempted to summarize the current state of cluster mempool discussion in Newsletter #280 but we would strongly recommend reading the overview by Daftuar, who is one of the architects of the proposal. One detail we have not previously covered caught our attention:

  • ● CPFP carve out needs to be removed: the CPFP carve out mempool policy added to Bitcoin Core in 2019 attempts to address the CPFP version of transaction pinning where a counterparty attacker uses Bitcoin Core’s limits on the number and size of related transactions to delay consideration of a child transaction belonging to an honest peer. The carve out allows one transaction to slightly exceed the limits. In cluster mempool, related transactions are placed in a cluster and the limits are applied per cluster, not per transaction. Under that policy, there’s no known way to ensure a cluster only contains a maximum of one carve out unless we restrict the relationships allowed between transactions relayed on the network far beyond the current restrictions. A cluster with multiple carve outs could significantly exceed its limits, at which point the protocol would need to be engineered for those much higher limits. That would accommodate users of carve outs but restrict what regular transaction broadcasters can do—an undesirable proposition.

    A proposed solution to the incompatibility between carve out and cluster mempool is v3 transaction relay, which would allow regular users of v1 and v2 transactions to continue using them in all the historically typical ways, but also allow the users of contract protocols like LN to opt in to v3 transactions that enforce a restricted set of relationships between transactions (topology). The restricted topology would mitigate transaction pinning attacks and could be combined with nearly drop-in replacements for carve out transactions such as ephemeral anchors.

  It’s important that a major change to Bitcoin Core’s mempool management algorithms take into account all the ways people use Bitcoin today, or may use it in the near future, so we would encourage developers working on software for mining, wallets, or contract protocols to read Daftuar’s description and ask questions about anything that’s not clear or which might adversely affect how Bitcoin software will interact with cluster mempool.

• ● Updated specification and implementation of Bitcoin transaction compression: Tom Briar posted to the Bitcoin-Dev mailing list an updated draft specification and proposed implementation of compressed Bitcoin transactions. Smaller transactions would be more practical to relay through bandwidth-constrained mediums, such as by satellite or through steganography (e.g., encoding a transaction in a bitmap image). See Newsletter #267 for our description of the original proposal. Briar describes the notable changes: “removing the grinding of the nLocktime in favor of a relative block height, which all of the compressed inputs use, and the use of a second kind of variable integer.”

• ● Discussion of Miner Extractable Value (MEV) in non-zero ephemeral anchors: Gregory Sanders posted to Delving Bitcoin to discuss concerns about ephemeral anchor outputs that contain more than 0 satoshis. An ephemeral anchor pays to a standardized output script that anyone can spend.

  One way to use ephemeral anchors would be for them to have a zero output amount, which is reasonable given that the policy rules for them require that they be accompanied by a child transaction spending the anchor output. However, in the current LN protocol, when a party wants to create an uneconomic HTLC, the payment amount is instead used to overpay the commitment transaction’s onchain fees; this is called a trimmed HTLC. If HTLC trimming is done in a commitment transaction using ephemeral anchors, it could be profitable for a miner to confirm the commitment transaction without a child transaction that spends the ephemeral anchor output. Once a commitment transaction is confirmed, there’s no incentive for anyone to spend a zero-amount ephemeral anchor output, meaning it will consume space in full node UTXO sets forever, an undesirable outcome.

  A proposed alternative is to put the trimmed HTLC amounts into the value of the ephemeral anchor outputs. That way they incentivize confirming both the commitment transaction and a spend of the ephemeral anchor output. In his post, Sanders analyzes this possibility and finds that this can create several security problems. These can be solved by miners analyzing transactions, determining when it would be more profitable for them to spend an ephemeral anchor output themselves, and creating the necessary transaction. This is a type of miner extractable value (MEV). Several alternative solutions were also proposed:

  • ● Only relaying transactions that are fully miner incentive compatible: if anyone attempts to spend an ephemeral anchor in a way that doesn’t maximize revenue for a miner, that transaction would not be relayed by Bitcoin Core.

  • ● Burn trimmed value: instead of turning the amount of trimmed HTLCs into fees, the amount would instead be spent to an OP_RETURN output, destroying those satoshis by making them permanently unspendable. This would only happen if a commitment transaction containing a trimmed HTLC was put onchain; normally trimmed HTLCs are resolved offchain and their value is successfully transferred from one party to the other.

  • ● Ensure MEV transactions propagate easily: instead of having miners run special code that maximizes their value, ensure that transactions maximizing their value propagate easily through the network. That way anyone can run the MEV code and relay the results to miners in a way that ensures all miners and relay nodes can obtain the same set of transactions.

  No clear conclusion has been reached at the time of writing.

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.

• ● LDK 0.0.119 is a new release of this library for building LN-enabled applications. Multiple new features are added, including receiving payments to multi-hop blinded paths, along with multiple bug fixes and other improvements.

Notable code and documentation changes

Notable recent changes in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, and Bitcoin Inquisition.

• ● Bitcoin Core #29058 is a preparation step to activate version 2 P2P transport (BIP324) by default. This patch adds v2transport support for -connect, -addnode, and -seednode configuration arguments if -v2transport is enabled and reconnects with v1 if the peer does not support v2. Additionally, this update adds a column displaying the transport protocol version to the netinfo peer connection bitcoin-cli dashboard.

• ● Bitcoin Core #29200 allows the I2P network support to use connections encrypted using “ECIES-X25519 and ElGamal (types 4 and, 0, respectively). This allows to connect to I2P peers of either type, and the newer, faster ECIES-X25519 will be preferred.”

• ● Bitcoin Core #28890 removes the -rpcserialversion configuration parameter that was previously deprecated (see Newsletter #269). This option was introduced during the transition to v0 segwit to allow older programs to continue to access blocks and transactions in stripped format (without any segwit fields). At this point, all programs should be updated to handle segwit transactions and this option should no longer be needed.

• ● Eclair #2808 updates the open command with a --fundingFeeBudgetSatoshis parameter that defines the maximum amount the node is willing to pay in onchain fees to open a channel, with the default set to 0.1% of the amount paid into the channel. Eclair will try to pay a lower fee if possible, but it will pay up to the budgeted amount if necessary. The rbfopen command is also updated to accept the same parameter which defines the maximum amount to spend on RBF fee bumping.

• ● LND #8188 adds several new RPCs for quickly obtaining debugging information, encrypting it to a public key, and decrypting it given a private key. As the PR explains, “The idea is that we would publish a public key in the GitHub issue template and would ask users to run the lncli encryptdebugpackage command and upload the encrypted output files to the GitHub issue to provide us with the information we normally require to debug user problems.”

• ● LND #8096 adds a “fee spike buffer”. In the current LN protocol, the party who single-funded a channel is responsible for paying any onchain fees directly included in the commitment transaction and the presigned HTLC-Success and HTLC-Timeout transactions (HTLC-X transactions). If the funding party is low on funds in the channel and if feerates rise, the funding party may not be able to accept a new incoming payment because they don’t have enough funds to pay for its fees—this is despite the fact that an incoming payment would increase the funding party’s balance, if the payment settles. To avoid this type of stuck-channel problem, a recommendation in BOLT2 (added several years ago in BOLTs #740) suggests the funder voluntarily keep an extra reserve of funds to ensure an additional payment can be received even if feerates rise. LND now implements this solution, which is also implemented by Core Lightning and Eclair (see Newsletters #85 and #89).

• ● LND #8095 and #8142 add additional logic to parts of LND’s codebase for handling blinded paths. This is part of ongoing work to add full support for blinded paths to LND.