This week’s newsletter announces a fixed consensus failure in older versions of btcd, describes proposed changes to LN for v3 transaction relay and ephemeral anchors, and announces a new repository for Bitcoin-related specifications. Also included are our regular sections describing updates to services and client software, announcing new releases and release candidates, and summarizing notable changes to popular Bitcoin infrastructure software.

News

  • ● Disclosure of fixed consensus failure in btcd: Niklas Gögge used Delving Bitcoin to announce a consensus failure in older versions of btcd that he had previously responsibly disclosed. Relative timelocks were added to Bitcoin in a soft fork by adding consensus-enforced meaning to transaction input sequence numbers. To ensure any presigned transactions created before the fork would not be made invalid, the relative time locks only apply to transactions with version numbers 2 and higher, allowing transactions with the original default of version 1 to remain valid with any inputs. However, in the original Bitcoin software, version numbers are signed integers, meaning negative versions are possible. The reference implementation section of BIP68 notes that “version 2 and higher” is meant to apply to the version number cast from a signed integer into an unsigned integer, ensuring that the rules apply to any transaction that isn’t version 0 or 1.

    Gögge discovered that btcd did not implement this conversion from signed to unsigned integers, so it was possible to construct a transaction with a negative version number which Bitcoin Core would require to follow the BIP68 rules but btcd would not. In that case, one node could reject the transaction (and any block that contained it) and the other node could accept it (and its block), leading to a chain split. An attacker could use this to trick the operator of a btcd node (or software connected to a btcd node) into accepting invalid bitcoins.

    The bug was privately disclosed to the btcd maintainers who fixed it in the recent v0.24.0 release. Anyone using btcd for consensus enforcement is strongly urged to upgrade. Additionally, Chris Stewart replied to the Delving Bitcoin thread with a patch for the same failure in the bitcoin-s library. Authors of any code that might be used to validate BIP68 relative locktimes are urged to check the code for the same flaw.

  • ● Proposed changes to LN for v3 relay and ephemeral anchors: Bastien Teinturier posted to Delving Bitcoin to describe the changes he thinks should be made to the LN specification to make effective use of v3 transaction relay and ephemeral anchors. The changes appear simple:

    • ● Anchor swap: the commitment transaction’s two current anchor outputs used to guarantee the ability to CPFP fee bump under the CPFP carve out policy are removed and one ephemeral anchor is added in their place.

    • ● Reducing delays: the extra 1-block delays on the commitment transaction are removed. They were added to ensure that CPFP carve out would always work but are not necessary under the v3 relay policy.

    • ● Trimming redirect: instead of spending the value of all trimmed HTLCs to fees in the commitment transaction, the combined value is added to the value of the anchor output, ensuring the extra fees are used to guarantee confirmation of both the commitment and the ephemeral anchor (see last week’s newsletter for discussion).

    • ● Other changes: some other minor changes and simplifications are made.

    The subsequent discussion examined several interesting consequences of the proposed changes, including:

    • ● Reduced UTXO requirements: ensuring the correct channel state goes onchain becomes easier thanks to the removal of the extra 1-block delay. If a faulty party broadcasts a revoked commitment transaction, the other party can use their main output from that commitment to CPFP fee bump that revoked commitment. They don’t need to keep a separate confirmed UTXO for that purpose. For this to be safe, the party must keep a sufficient reserve balance, as the 1% minimum specified in BOLT2 may not be enough to cover fees. For a non-forwarding node that keeps a sufficient reserve, the only time they need a separate UTXO for security reasons is when they want to accept an incoming payment.

    • ● Imbued v3 logic: In response to concerns voiced in the LN spec meeting that it may take a long time for LN to design, implement, and deploy these changes, Gregory Sanders proposed an intermediate stage with temporary special treatment of transactions that look like current anchors-style LN commitment transactions, allowing Bitcoin Core to deploy cluster mempool without being blocked by LN development. When they’ve been widely deployed and all LN implementations have upgraded to using v3, the temporary special rules can be dropped.

    • ● Request for max child size: the draft proposal for v3 relay sets the size of an unconfirmed transaction’s child to 1,000 vbytes. The larger this size, the more an honest user will need to pay to overcome a transaction pin (see Newsletter #283). The smaller the size, the fewer inputs an honest user can use to contribute fees.

  • ● New documentation repository: Anthony Towns posted to the Bitcoin-Dev mailing list to announce a new repository for protocol specifications, Bitcoin Inquisition Numbers And Names Authority (BINANA). Four specifications are available in the repository at the time of writing:

    • ● BIN24-1 OP_CAT by Ethan Heilman and Armin Sabouri. See the description of their soft fork proposal in Newsletter #274.

    • ● BIN24-2 Heretical Deployments by Anthony Towns, describing the use of Bitcoin Inquisition for proposed soft forks and other changes on the default signet. See the extended description in Newsletter #232.

    • ● BIN24-3 OP_CHECKSIGFROMSTACK by Brandon Black, specifying this long-proposed idea. See last week’s newsletter for Black’s proposal to include this opcode as part of the LNHANCE soft fork bundle.

    • ● BIN24-4 OP_INTERNALKEY by Brandon Black, specifying an opcode for retrieving the taproot internal key from the script interpreter. This was also described in last week’s newsletter as part of the LNHANCE soft fork bundle.

    Bitcoin Optech has added the BINANA repository to the list of documentation sources we monitor for updates, which also includes BIPs, BOLTs, and BLIPs. Future updates may be found in the section for notable code and documentation changes.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

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.120 is a security release of this library for building LN-enabled applications. It “fixes a denial-of-service vulnerability which is reachable from untrusted input from peers if the UserConfig::manually_accept_inbound_channels option is enabled.” Several other bug fixes and minor improvements are also included.

  • ● HWI 2.4.0-rc1 is a release candidate for the next version of this package providing a common interface to multiple different hardware signing devices.

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.