This week’s newsletter announces a fixed vulnerability affecting older versions of Bitcoin Core, provides an update on hybrid channel jamming mitigation, summarizes a paper about more efficient and private client-side validation, and announces a proposal to update the BIP process. Also included are our regular sections summarizing top questions and answers from the Bitcoin Stack Exchange, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

  • ● Disclosure of vulnerability affecting Bitcoin Core versions before 24.0.1: Antoine Poinsot posted to the Bitcoin-Dev mailing list a link to the announcement of a vulnerability affecting versions of Bitcoin Core that have been past their end of life since at least December 2023. This follows previous disclosures of older vulnerabilities (see Newsletters #310 and #314).

    The new disclosure discusses a long-known method for crashing Bitcoin Core full nodes: sending them long chains of block headers that will be stored in memory. Each block header is 80 bytes and, if there were no protections, could be created at the protocol minimum difficulty—allowing an attacker with modern ASIC mining to produce millions per second. Bitcoin Core has had protection for many years as a side effect of the checkpoints added in an early version: these prevented an attacker from being able to create the initial blocks in a chain of headers at minimum difficulty, forcing them to perform significant proof of work that they could instead be paid for if they created valid blocks.

    However, the last checkpoint was added over 10 years ago and Bitcoin Core developers have been reluctant to add new checkpoints, as doing so gives the mistaken impression that transaction finality is ultimately dependent on developers creating checkpoints. As mining equipment has improved and the amount of network hashrate increased, the cost to create a fake chain of headers has decreased. As the cost decreased, researchers David Jaenson and Braydon Fuller independently responsibly disclosed the attack to Bitcoin Core developers. Developers replied that the issue was known to them and encouraged Fuller to publicly post his paper about it in 2019.

    In 2022, the cost of the attack having decreased further, a group of developers began working on a solution that did not use checkpoints. Bitcoin Core PR #25717 (see Newsletter #216) was the result of that work. Later, Niklas Gögge discovered a bug in #25717’s logic and opened PR #26355 to fix it. Both PRs were merged and Bitcoin Core 24.0.1 was released with the fix.

  • ● Hybrid jamming mitigation testing and changes: Carla Kirk-Cohen posted to Delving Bitcoin details about various attempts to defeat an implementation of the mitigation for channel jamming attacks originally proposed by Clara Shikhelman and Sergei Tikhomirov. Hybrid jamming mitigation involves a combination of HTLC endorsement and a small upfront fee that is paid unconditionally whether a payment succeeds or fails.

    Several developers were invited to attempt to jam a channel for an hour, with Kirk-Cohen and Shikhelman expanding on any attacks that seemed promising. Most of the attacks were failures: either the attacker spent more to use the attack than another known attack, or the target node earned more in income during the attack than it would’ve earned through normal forwarding traffic on the simulated network.

    One attack was successful: a sink attack that “aims to decrease the reputation of a targeted node’s peers by creating shorter/cheaper paths in the network, and sabotaging payments forwarded through its channels to decrease the reputation of all the nodes preceding it in the route.” To address the attack, Kirk-Cohen and Shikhelman introduced bidirectional reputation to the way HTLC endorsement is considered. When Bob receives a payment from Alice to be forwarded to Carol, e.g. A -> B -> C, Bob considers both whether Alice tends to forward HTLCs that are quickly settled (as with HTLC endorsement previously) and whether Carol tends to accept HTLCs that are quickly settled (this is new). Now when Bob receives an endorsed HTLC from Alice:

    • If Bob thinks both Alice and Carol are reliable, he’ll forward and endorse the HTLC from Alice to Carol.

    • If Bob thinks only Alice is reliable, he won’t forward an endorsed HTLC from Alice. He’ll immediately reject it, allowing the failure to propagate back to the original spender, who can quickly resend using a different route.

    • If Bob thinks only Carol is reliable, he’ll accept an endorsed HTLC from Alice when he has extra capacity, but he won’t endorse it when forwarding it to Carol.

    Given the change to the proposal, Kirk-Cohen and Shikhelman are planning additional experiments to ensure it works as expected. They also additionally link to a mailing list post by Jim Posen from May 2018 that describes a bidirectional reputation system to prevent jamming attacks (then called loop attacks), an example of earlier parallel thinking about solving this problem.

  • ● Shielded client-side validation (CSV): Jonas Nick, Liam Eagen, and Robin Linus posted to the Bitcoin-Dev mailing list a paper about a new client-side validation protocol. Client-side validation allows the transfer of tokens to be protected by Bitcoin’s proof-of-work without publicly revealing any information about those tokens or transfers. Client-side validation is a key component of protocols such as RGB and Taproot Assets.

    One downside of existing protocols is that the amount of data that needs to be validated by a client when receiving a token is, in the worst case, as large as the history of every transfer of that token and every related token. In other words, for a set of tokens as frequently exchanged as bitcoins, a client would need to validate a history roughly as large as the entire Bitcoin blockchain. In addition to the bandwidth cost of transferring that data and the CPU cost of validating it, transferring the full history weakens the privacy of previous receivers of the token. By comparison, Shielded CSV uses zero-knowledge proofs to allow verification with a fixed amount of resources and without revealing previous transfers.

    Another downside of existing protocols is that each transfer of a token requires including data in a Bitcoin transaction. Shielded CSV allows multiple transfers to be combined together into the same 64-byte update. This can allow thousands of token transfers to be confirmed each time a new Bitcoin block is found by confirming only a single Bitcoin transaction with an extra 64-byte data push.

    The paper goes into details. We found particularly interesting the idea of trustlessly bridging bitcoin from the main blockchain to a Shielded CSV (and back) without consensus changes by using BitVM, the use of accounts (section 2), the discussion about the effect of blockchain reorganization on accounts and transfers (also section 2), the related discussion about depending on unconfirmed transactions (section 5.2), and the list of possible extensions (appendix A).

  • ● Draft of updated BIP process: Mark “Murch” Erhardt posted to the Bitcoin-Dev mailing list to announce the availability of a pull request for a draft BIP that describes an updated process for the BIP repository. Anyone interested is encouraged to review the draft and leave comments. If the community finds the final version of the draft acceptable, it will become the process used by the BIP editors.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

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.

  • ● BDK 1.0.0-beta.4 is a release candidate of this library for building wallets and other Bitcoin-enabled applications. The original bdk Rust crate has been renamed to bdk_wallet, and lower layer modules have been extracted into their own crates, including bdk_chain, bdk_electrum, bdk_esplora, and bdk_bitcoind_rpc. The bdk_wallet crate “is the first version to offer a stable 1.0.0 API.”

  • ● Bitcoin Core 28.0rc2 is a release candidate for the next major version of the predominant full node implementation. A testing guide is available.

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.

  • ● Eclair #2909 adds a privateChannelIds parameter to the createinvoice RPC command to add private channel pathfinding hints to BOLT11 invoices. This fixes a bug that prevented nodes with only private channels from receiving payments. To avoid leaking the channel outpoint, scid_alias should be used.

  • ● LND #9095 and LND #9072 introduce changes to the invoice HTLC modifier, auxiliary channel funding and closing, and integrate custom data into the RPC/CLI as part of the custom channels initiative to enhance LND’s support for taproot assets. This PR allows custom asset-specific data to be included in RPC commands and supports auxiliary channel management via the command line interface.

  • ● LND #8044 adds new message types announcement_signatures_2, channel_announcement_2 and channel_update_2 for the new v1.75 gossip protocol (see Newsletter #261) that allows nodes to announce and verify taproot channels. In addition, some modifications are made to existing messages such as channel_ready and gossip_timestamp_range to improve the efficiency and security of gossiping with taproot channels.