This week’s newsletter announces a new mailing list to discuss Bitcoin mining. Also included are our regular sections summarizing popular questions and answers from the Bitcoin Stack Exchange, announcements of new releases and release candidates, and descriptions of recent changes to popular Bitcoin infrastructure software.

News

• ● New Bitcoin Mining Development mailing list: Jay Beddict announced a new mailing list to “discuss emerging Bitcoin mining technology updates as well as the impacts of Bitcoin-related software or protocol changes on mining.”

  Mark “Murch” Erhardt posted to the list to ask whether the time warp fix deployed on testnet4 could lead to miners creating invalid blocks if the same fix was deployed to mainnet (such as part of a cleanup soft fork). Mike Schmidt referred list readers to a thread on the Bitcoin-Dev mailing list about oblivious shares (see Newsletter #315).

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.

• ● Can a BIP152 compact block be sent before validation by a node that doesn’t know all transactions? Antoine Poinsot points out that forwarding compact blocks before validating all of the included transactions are committed to by the block header would be a denial-of-service vector.

• ● Did Segwit (BIP141) eliminate all txid malleability issues listed in BIP62? Vojtěch Strnad explains a variety of ways txids can be malleated, how segwit addressed malleability, what non-intentional malleability is, and a policy-related pull request.

• ● Why are the checkpoints still in the codebase in 2024? Lightlike notes that with the addition of “Headers Presync”, the Bitcoin Core codebase has no known requirements for checkpoints, but emphasizes there may be unknown attack vectors that the checkpoints are protecting against.

• ● Bulletproof++ as generic ZKP ala SNARKs? Liam Eagen details the type of succinct non-interactive argument of knowledge (SNARKs) currently in use and how bulletproofs, BitVM, and OP_CAT might be used to verify such proofs in Bitcoin Script.

• ● How can OP_CAT be used to implement additional covenants? Brandon - Rearden describes how the proposed OP_CAT opcode could provide covenant functionality to Bitcoin scripts.

• ● Why do some bech32 bitcoin addresses contain a large number of ‘q’s? Vojtěch Strnad reveals that the OLGA protocol encodes arbitrary data into P2WSH outputs with part of the scheme requiring 0-padding (0 is encoded as ‘q’ in bech32).

• ● How does a 0-conf signature bond work? Matt Black outlines how funds locked in an OP_CAT-based covenant could provide incentives for spenders to not RBF fee bump their transactions, potentially increasing acceptance of zero-confirmation transactions.

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.

• ● Core Lightning 24.08rc2 is a release candidate for the next major version of this popular LN node implementation.

• ● LND v0.18.3-beta.rc1 is a release candidate for a minor bug fix release of this popular LN node implementation.

• ● BDK 1.0.0-beta.2 is a release candidate for 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.0rc1 is a release candidate for the next major version of the predominant full node implementation. A testing guide is being prepared.

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.

• ● LDK #3263 simplifies how it handles onion messages responses by removing the message type parameter from the ResponseInstruction struct, and introducing a new MessageSendInstructions enum based on the updated ResponseInstruction, that can handle both blinded and non-blinded reply paths. The send_onion_message method now uses MessageSendInstructions, allowing users to specify reply paths without needing to figure out the pathfinding themselves. A new option, MessageSendInstructions::ForReply, lets message handlers send responses later without creating circular dependencies in the code. See Newsletter #303.

• ● LDK #3247 deprecates the AvailableBalances::balance_msat method in favor of the ChannelMonitor::get_claimable_balances method, which provides a more straightforward and accurate approach to obtaining a channel’s balance. The deprecated method’s logic is now outdated as it was originally designed to handle potential underflow issues when balances included pending HTLCs (those that could later be reversed).

• ● BDK #1569 adds the bdk_core crate and moves to it some types from bdk_chain: BlockId, ConfirmationBlockTime, CheckPoint, CheckPointIter, tx_graph::Update and spk_client. The bdk_esplora, bdk_electrum and bdk_bitcoind_rpc chain sources have been changed to depend only on bdk_core. These changes were made to allow faster refactoring on bdk_chain.