This week’s newsletter describes a potential change to Bitcoin Core affecting miners, summarizes discussion about creating contract-level relative timelocks, and discusses a proposal for an LN-Symmetry variant with optional penalties. Also included are our regular sections announcing new releases and release candidates and summarizing notable changes to popular Bitcoin infrastructure software.

News

• ● Investigating mining pool behavior before fixing a Bitcoin Core bug: Abubakar Sadiq Ismail posted to Delving Bitcoin about a bug discovered in 2021 by Antoine Riard that results in nodes reserving 2,000 vbytes in block templates for coinbase transactions rather than the intended 1,000 vbytes. Each template could include approximately five additional small transactions if the double reservation was eliminated. However, that could lead to miners who depended on the double reservation producing invalid blocks, resulting in a large loss of income. Ismail analyzed past blocks to determine which mining pools might be at risk. He noted Ocean.xyz, F2Pool, and an unknown miner are apparently using non-default settings, although none of these appear to be at risk of losing money if the bug is fixed.

  However, to minimize the risk, it’s currently proposed to introduce a new startup option that defaults to reserving 2,000 vbytes for the coinbase. Miners who don’t need backwards compatibility can easily reduce the reservation to 1,000 vbytes (or less, if they need less).

  Jay Beddict relayed the message to the Mining-Dev mailing list.

• ● Contract-level relative timelocks: Gregory Sanders posted to Delving Bitcoin about finding a solution for a complication he discovered about a year ago (see Newsletter #284) when creating a proof-of-concept implementation of LN-Symmetry. In that protocol, each channel state can be confirmed onchain, but only the last state confirmed before a deadline can distribute the channel funds. Usually, the parties to a channel would attempt to confirm only the latest state; however, if Alice initiates a new state update by partially signing a transaction and sending it to Bob, only Bob can complete that transaction. If Bob stalls at that point, Alice can only close a channel in its penultimate state. If Bob waits until Alice’s penultimate state has almost reached its deadline and then confirms the last state, it will take approximately twice as long as the deadline for the channel to resolve, called the 2x delay problem. That means timelocks for HTLCs in LN-Symmetry must be up to twice as long, which makes it easier for attackers to prevent forwarding nodes from earning income on their capital (through channel jamming attacks and other problems).

  Sanders suggests solving the problem with a relative timelock that would apply to all transactions required to settle a contract. If LN-Symmetry had such a feature and Alice confirmed the penultimate state, Bob would need to confirm the last state before the deadline of the penultimate state. In a later post, Sanders links to a channel protocol by John Law (see Newsletter #244) that uses two transaction-level relative timelocks to provide a contract-level relative timelock without consensus changes. However, that doesn’t work for LN-Symmetry which allows each state to spend from any previous state.

  Sanders sketches a solution, but notes that it has downsides. He also notes how the problem could be solved using Chia’s coinid feature, which appears to be similar to John Law’s 2021 idea for Inherited Identifiers (IIDs). Jeremy Rubin replied with a link to his proposal last year for muon outputs that must be spent in the same block as the transaction that created them, showing how they could contribute to a solution. Sanders mentions, and Anthony Towns expands on, the coinid feature from the Chia blockchain, showing how it could reduce the data required to a constant amount. Salvatore Ingala posted about a similar mechanism using OP_CAT that he learned about from developer Rijndael, who later provided details. Brandon Black described an alternative type of solution—a penalty-based variant of LN-Symmetry—and cited work by Daniel Roberts about it (see next news item).

• ● Multiparty LN-Symmetry variant with penalties for limiting published updates: Daniel Roberts posted to Delving Bitcoin about preventing a malicious channel counterparty (Mallory) from being able to delay channel settlement by deliberately broadcasting old states at a higher feerate than an honest counterparty (Bob) is paying for confirmation of the final state. In theory, Bob can rebind his final state to Mallory’s old state and both transactions might confirm in the same block, causing her to lose money on fees and Bob to confirm the final state for the same fee cost he was already willing to pay. However, if Mallory can repeatedly prevent Bob from learning about her broadcasts of old states before they are confirmed, she can prevent him from responding until HTLCs in the channel expire and Mallory is able to steal funds.

  Roberts proposed a scheme that allows a channel participant to confirm only a single state. If a later state is confirmed, the participant who submitted the final state and any participant who didn’t submit any states can take the money of any participants who submitted outdated states.

  Unfortunately, after publishing the scheme, Roberts discovered and self-disclosed a critical flaw in it: similar to the 2x delay problem described in the previous news item, the last party to sign can complete a state that no other party can complete, giving the final signer exclusive access to the current final state. If any other party tries to close in the previous state, they will lose money if the final signer uses the final state.

  Roberts is investigating alternative approaches, but the topic spurred interesting discussion about whether or not adding a penalty mechanism to LN-Symmetry is useful. Gregory Sanders, whose previous proof-of-concept implementation of LN-Symmetry led him to believe that a penalty mechanism is unnecessary (see Newsletter #284), noted that the repeated-old-state attack is similar to a replacement cycling attack. He finds “this attack pretty weak, since the attack[er] can be driven to negative EV [expected value] pretty easily” even if the defender has modest resources and no insight into what transactions miners are attempting to confirm.

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.

• ● Bitcoin Core 28.1 is a release of a maintenance version of the predominant full-node implementation.

• ● BDK 0.30.1 is a maintenance release for the previous release series containing bug fixes. Projects are encouraged to upgrade to BDK wallet 1.0.0, as announced in last week’s newsletter, for which the a migration guide has been provided.

• ● LDK v0.1.0-beta1 is a release candidate of this library for building LN-enabled wallets and applications.

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, Lightning BLIPs, Bitcoin Inquisition, and BINANAs.

• ● Bitcoin Core #28121 adds a new reject-details field to the response of the testmempoolaccept RPC command, which is only included if the transaction would be rejected from the mempool due to consensus or policy violations. The error message is identical to the one returned by sendrawtransaction if the transaction is rejected there as well.

• ● BDK #1592 introduces Architectural Decision Records (ADRs) to document significant changes, outlining the problem addressed, decision drivers, alternatives considered, pros and cons, and the final decision. This allows newcomers to familiarize themselves with the repository’s history. This PR adds an ADR template and the first two ADRs: one to remove the persist module from bdk_chain and another to introduce a new PersistedWallet type that wraps a BDKWallet.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 15:30 UTC on January 14. The discussion is also recorded and will be available from our podcasts page.