This week’s newsletter describes a post about fee-bumping research and contains our regular sections with the summary of a Bitcoin Core PR Review Club meeting, the latest releases and release candidates for Bitcoin software, and notable changes to popular infrastructure projects.

News

  • ● Fee bumping research: Antoine Poinsot posted to the Bitcoin-Dev mailing list a detailed description of several concerns developers need to consider when choosing how to fee-bump presigned transactions used in vaults and contract protocols such as LN. In particular, Poinsot looked at schemes for multiparty protocols with more than two participants, for which the current CPFP carve out transaction relay policy doesn’t work, requiring them to use transaction replacement mechanisms that may be vulnerable to transaction pinning. Also included in his post is the result of research into some of the ideas described earlier.

    Ensuring that fee bumping works reliably is a requirement for the safety of most contract protocols, and it remains a problem without any comprehensive solution yet. It is encouraging to see continuing research into the problem.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Treat taproot as always active is a PR by Marco Falke to make transactions spending taproot outputs standard, regardless of taproot deployment status.

  • What mempool validation function checks if a transaction spends a taproot input? How does this PR change the function?

    The function is AreInputsStandard(). The PR removes the last argument, bool taproot_active, from the signature and returns true for v1 segwit (taproot) spends regardless of taproot activation status. Previously, the function would return false if it found a taproot output but taproot_active was false, e.g. if the node were still in Initial Block Download and syncing blocks before taproot activation. ➚

  • Are there any theoretical issues with the change? For wallet users, is it possible to lose money?

    With this change, the wallet allows importing taproot descriptors at any time, i.e., even when taproot is not active and v1 segwit outputs can be spent by anyone. This means it’s possible to receive bitcoin to a taproot output without taproot being active yet; if the chain also reorgs to a block prior to 709,632, miners (or someone who can get a nonstandard transaction confirmed) can steal those UTXOs. ➚

  • Theoretically, is it possible for a mainnet chain that has taproot never-active or active at a different block height to exist?

    Both are possible. If a very large reorg happened (forking off prior to taproot lock-in), the deployment process would be repeated. In this new chain, if the number of taproot-signaling blocks never met the threshold, the (still valid) chain would never activate taproot. If the threshold were reached after the min activation height but before the timeout, taproot could also activate at a later height. ➚

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 0.14.0 is the latest release of this library for wallet developers. It simplifies adding an OP_RETURN output to a transaction and contains improvements for sending payments to bech32m addresses for taproot.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • ● Bitcoin Core #23155 extends the dumptxoutset RPC with the hash of the chainstate snapshot (UTXO set) along with the number of transactions in the entire chain up until that point. This information can be published alongside the chainstate so that others can verify it using the gettxoutsetinfo RPC, allowing it to be used with the proposed assumeUTXO node bootstrapping.

  • ● Bitcoin Core #22513 allows walletprocesspsbt to sign without finalizing the PSBT workflow. This is useful for complex scripts, for example, in a tapscript with two paths: a fallback script path that requires only signer Alice, plus a normal path with multiple signers including Alice. When Alice signs, it is best to delay finalizing the PSBT with the fallback script path and instead construct a PSBT containing both of Alice’s signatures, pass the PSBT to the other signers, and wait for them to sign. In this scenario, the ultimate path is determined after all signatures are produced.

  • ● C-Lightning #4921 updates the implementation of onion messages to match the latest updates to the draft specifications for route blinding and onion messages.

  • ● C-Lightning #4829 adds experimental support for the proposed LN protocol change in BOLTs #911 that will allow nodes to advertise their DNS address rather than their IP address or Tor onion service address.

  • ● Eclair #2061 adds initial support for onion messages. Users can enable the option_onion_messages feature to relay onion messages and send onion messages with the sendonionmessage RPC. Handling incoming onion messages and route blinding are not yet implemented.

  • ● Eclair #2073 adds support for the optional channel type negotiation feature bit as specified in draft BOLTs #906. This corresponds to LND’s implementation of the same draft feature last week.

  • ● Rust-Lightning #1163 allows the remote party to set their channel reserve below the dust limit, even all the way down to zero. In the worst case, this allows the local node to costlessly attempt to steal funds from a fully-spent channel—although such a theft attempt will still fail if the remote party is monitoring their channels. By default, most remote nodes discourage such attempts by setting a reasonable channel reserve, but some Lightning Service Providers (LSPs) use low or zero channel reserves order to provide users with a better experience—allowing them to spend 100% of the funds in the channel. Since only the remote node is taking any risk, there’s no problem allowing the local node to accept such channels.