This week’s newsletter announces an upcoming disclosure of vulnerabilities affecting older versions of Bitcoin Core, describes a draft BIP for a new version of testnet, summarizes a proposal for covenants based on functional encryption, examines an update to the proposal for performing 64-bit arithmetic in Bitcoin Script, links to a script for validating proof-of-work on signet with the OP_CAT opcode, and looks at a proposed update to the BIP21 specification of bitcoin: URIs. Also included are our regular sections announcing new releases and release candidates, plus summaries of notable changes to popular Bitcoin infrastructure software.

News

  • ● Upcoming disclosure of vulnerabilities affecting old versions of Bitcoin Core: several members of the Bitcoin Core project discussed on IRC a proposed policy for disclosing vulnerabilities that affected older versions of Bitcoin Core. For low-severity vulnerabilities, the details will be disclosed about two weeks after the first release of a version of Bitcoin Core that eliminates (or satisfactorily mitigates) the vulnerability. For most other vulnerabilities, the details will be disclosed after the last version of Bitcoin Core affected by the vulnerability reaches end-of-life (which is about a year and a half after it was released). For rare critical vulnerabilities, members of the Bitcoin Core security team will privately discuss the most appropriate disclosure timeline to use.

    After this policy has a chance to be further discussed, it is the intention of the project to begin disclosing vulnerabilities affecting Bitcoin Core 24.x and below. It is strongly recommended that all users and administrators upgrade to Bitcoin Core 25.0 or above within the next two weeks. It is always ideal to use the latest version when possible, either the absolute latest version (27.0 as of writing) or the latest version in a particular release series (e.g. 25.2 for the 25.x release series or 26.1 for the 26.x release series).

    As has always been our policy, Optech will provide summaries of all significant security disclosures affecting any of the infrastructure projects we monitor (which includes Bitcoin Core).

  • ● BIP and experimental implementation of testnet4: Fabian Jahr posted to the Bitcoin-Dev mailing list to announce a draft BIP for testnet4, a new version of testnet designed to eliminate some problems with the existing testnet3 (see Newsletter #297). Jahr also links to a Bitcoin Core pull request with a proposed implementation. Testnet4 has two notable differences from testnet3:

    • ● Fewer reversions to difficulty-1: it was easy (accidentally or deliberately) to reduce an entire period of 2,016 blocks to the minimum difficulty (difficulty-1) by mining the ultimate block in a period with a timestamp more than 20 minutes after the penultimate block. Now period difficulty can only adjust downward in the normal way used on mainnet—although it is still possible to mine all individual blocks, except the first block in a new period, at difficulty-1 if they have a timestamp more than 20 minutes after the previous block.1

    • ● Time warp fixed: it was possible on testnet3 (and also mainnet) to produce blocks significantly faster than once every 10 minutes without raising difficulty by exploiting the time warp attack. Testnet4 now implements the solution for time warp that was proposed as part of the consensus cleanup soft fork for mainnet.

    The draft BIP also mentions some additional and alternative ideas for testnet4 that were discussed but not used.

  • ● Functional encryption covenants: Jeremy Rubin posted to Delving Bitcoin his paper about theoretically using functional encryption to add a full range of covenant behavior to Bitcoin with no required consensus changes. Fundamentally, this would require users of the covenants to trust a third party, although that trust could be distributed across multiple parties where only one of them would need to have acted honestly at a particular time.

    In essence, functional encryption would allow the creation of a public key that would correspond to a particular program. A party who could satisfy the program would be able to create a signature that corresponded to the public key (without ever learning a corresponding private key).

    Rubin notes that this has an advantage over existing covenant proposals in that all operations (except verifying the resultant signature) occurs offchain and no data (except the public key and signature) needs to be published onchain. This is always more private and will often save space. Multiple covenant programs can be used in the same script by performing multiple signature checks.

    Besides the need for trusted setup, Rubin describes the other major downside of functional encryption as “under-developed cryptography that makes it impractical to use presently”.

  • ● Updates to proposed soft fork for 64-bit arithmetic: Chris Stewart posted to Delving Bitcoin to announce an update to his earlier proposal to add the ability to work with 64-bit numbers in Bitcoin Script (see Newsletters #285 and #290). The main changes are:

    • ● Updating existing opcodes: instead of adding new opcodes such as OP_ADD64, the existing opcodes (e.g. OP_ADD) are updated to operate on 64-bit numbers. Because the encoding for large numbers is different than currently used for small numbers, script fragments that are upgraded to use large numbers may need to be revised; Stewart gives the example of OP_CHECKLOCKTIMEVERIFY now needing to take an 8-byte parameter rather than a 5-byte parameter.

    • ● Result includes a bool: a successful operation not only places the result on the stack but also places a bool on the stack that indicates that the operation was successful. One common reason an operation might fail is because the result is larger than 64 bits, overflowing the field size. Code can use OP_VERIFY to ensure the operation completed successfully.

    Anthony Towns replied arguing for an alternative approach where the default opcodes fail if an overflow occurs, rather than requiring scripts additionally verify that operations were successful. For cases where it could be useful to test whether an operation would result in an overflow, new opcodes such as ADD_OF would be made available.

  • ● OP_CAT script to validate proof of work: Anthony Towns posted to Delving Bitcoin about a script for signet that uses OP_CAT to allow anyone to spend coins sent to the script using proof of work (PoW). This can be used as a decentralized signet-bitcoin faucet: when a miner or a user obtains excess signet bitcoins, they send them to the script. When a user wants more signet bitcoins, they search the UTXO set for payments to the script, generate PoW, and create a transaction that uses their PoW to claim the coins.

    Towns’s post describes the script and the motivation for several design choices.

  • ● Proposed update to BIP21: Matt Corallo posted to the Bitcoin-Dev mailing list about updating the BIP21 specification for the bitcoin: URI. As previously discussed (see Newsletter #292), almost all Bitcoin wallets are using the URI scheme differently than specified, and additional changes to invoice protocols will likely lead to additional changes in the use of BIP21. The major changes in the proposal include:

    • ● More than base58check: BIP21 expects every Bitcoin address to use base58check encoding, but that is only used for legacy addresses for P2PKH and P2SH outputs. Modern outputs use bech32 and bech32m. Future payments will be received to silent payment addresses and the LN offers protocol, which will almost certainly be used as BIP21 payloads.

    • ● Empty body: BIP21 currently requires a Bitcoin address to be provided in the body part of the payload, with query parameters providing additional information (such as an amount to pay). Previous new payment protocols, such as the BIP70 payment protocol, specified new query parameters to use (see BIP72), but clients that didn’t understand the parameter would fall back to using the address in the body. In some cases, receivers may not want to fall back to one of the base address types (base58check, bech32, or bech32m), such as privacy-minded users of silent payments. The proposed update allows the body field to be empty.

    • ● New query parameters: the update describes three new keys: lightning for BOLT11 invoices (currently in use), lno for LN offers (proposed), and sp for silent payments (proposed). It also describes how the keys for future parameters should be named.

    Corallo notes in his post that the changes are safe for all known deployed software as wallets will ignore or reject any bitcoin: URIs that they cannot successfully parse.

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.

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.

  • ● Core Lightning #7252 changes the behavior of lightningd to ignore the ignore_fee_limits setting during a cooperative channel closure. This fixes an issue where a Core Lightning (CLN) channel opener node overpays fees when the counterparty is an LDK node. In this scenario, when the LDK non-opener node (Alice) initiates a cooperative channel closure and begins fee negotiation, the CLN opener node (Bob) responds that the fee can be anything between min_sats and max_channel_size due to the ignore_fee_limits setting. LDK will “always select the highest allowed amount” (contrary to the BOLTs specification), so Bob picks the upper bound, and Alice accepts, resulting in Alice broadcasting a transaction with considerably overpaid fees.

  • ● LDK #2931 enhances the logging during pathfinding to include additional data about direct channels such as whether they’re missing, their minimum HTLC amount, and their maximum HTLC amount. The added logging aims to better troubleshoot routing issues by providing visibility into the available liquidity and limitations on each channel.

  • ● Rust Bitcoin #2644 adds HKDF (HMAC (Hash-based Message Authentication Code) Extract-and-Expand Key Derivation Function) to the bitcoin_hashes component to implement BIP324 in Rust Bitcoin. HKDF is used to derive cryptographic keys from a source of keying material in a secure and standardized way. BIP324 (also known as v2 P2P transport) is a method for allowing Bitcoin nodes to communicate with each other over encrypted connections (enabled by default in Bitcoin Core).

  • ● BIPs #1541 adds BIP431 with a specification of Topologically Restricted Until Confirmation (TRUC) transactions (v3 transactions) which are a subset of standard transactions with additional rules designed to allow transaction replacement while minimizing the cost of overcoming transaction-pinning attacks.

  • ● BIPs #1556 adds BIP337 with a specification of compressed transactions, a serialization protocol to compress bitcoin transactions to reduce their size by up to 50%. They are practical for low-bandwidth transmission such as by satellite, HAM radio, or through steganography. Two RPC commands are proposed: compressrawtransaction and decompressrawtransaction. See Newsletter #267 for a more detailed explanation of BIP337.

  • ● BLIPs #32 adds BLIP32 describing how proposed DNS-based human-readable Bitcoin payment instructions (see Newsletter #290) can be used with onion messages to allow payments to be sent to an address like bob@example.com. For example, Alice instructs her LN client to pay Bob. Her client may not be able to securely resolve DNS addresses directly, but it can use an onion message to contact one of its peers that advertises a DNS resolution service. The peer retrieves the DNS TXT record for the bob entry at example.com and places the results along with a DNSSEC signature into an onion message reply to Alice. Alice verifies the information and uses it to request an invoice from Bob using the offers protocol.

Footnotes

  1. This paragraph was edited after publication. We thank Mark “Murch” Erhardt for the correction. ↩