This week’s newsletter links to an educational implementation of elliptic curve cryptography for Bitcoin’s secp256k1 curve. Also included are our regular sections with descriptions of discussions about changing consensus, announcements of new releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software.

News

• ● Educational and experimental-based secp256k1 implementation: Sebastian Falbesoner, Jonas Nick, and Tim Ruffing posted to the Bitcoin-Dev mailing list to announce a Python implementation of various functions related to the cryptography used in Bitcoin. They warn that the implementation is “INSECURE” (caps in original) and “intended for prototyping, experimentation, and education.”

  They also note that reference and test code for several BIPs (340, 324, 327, and 352) already includes “custom and sometimes subtly diverging implementations of secp256k1.” They hope to improve this situation going forward, perhaps starting with an upcoming BIP for ChillDKG (see Newsletter #312).

Changing consensus

A monthly section summarizing proposals and discussion about changing Bitcoin’s consensus rules.

• ● Multiple discussions about quantum computer theft and resistance: several conversations examined how Bitcoiners could respond to quantum computers becoming powerful enough to allow stealing bitcoins.

  • ● Should vulnerable bitcoins be destroyed? Jameson Lopp posted to the Bitcoin-Dev mailing list several arguments for the destruction of bitcoins vulnerable to quantum theft after an upgrade path to quantum resistance has been adopted and users have had time to adopt the solution. Some arguments include:

    • ● Argument from common preference: he believes most people would prefer that their funds be destroyed rather than stolen by someone with a fast quantum computer. Especially, he argues, since the thief will be among “the few privileged folks who gain early access to quantum computers”.

    • ● Argument from common harm: many of the stolen bitcoins will be either lost coins or those that were planned to be held long-term. By contrast, the thieves might quickly spend their stolen bitcoins, which reduces the purchasing power of other bitcoins (similar to money supply inflation). He notes that lower purchasing power of bitcoins reduces miner income, reducing network security, and (in his observation) results in lower merchant acceptance of bitcoins.

    • ● Argument from minimal benefit: although allowing theft could be used to fund the development of quantum computing, stealing coins does not provide any direct benefit to honest participants in the Bitcoin protocol.

    • ● Argument from clear deadlines: nobody can know far in advance the date at which someone with a quantum computer can begin stealing bitcoins, but a specific date at which quantum-vulnerable coins will be destroyed can be announced far in advance with perfect precision. That clear deadline will provide more incentive for users to re-secure their bitcoins in time, ensuring fewer total coins are lost.

    • ● Argument from miner incentives: as noted above, quantum theft would likely reduce miner income. A persistent majority of hashrate can censor spending of quantum-vulnerable bitcoins, which they might do even if the rest of Bitcoiners prefer a different outcome.

    Lopp also provides several arguments against the destruction of vulnerable bitcoins, but he concludes in favor of destruction.

    Nagaev Boris asks whether UTXOs that are timelocked beyond the upgrade deadline should also be destroyed. Lopp notes existing pitfalls of long timelocks and says he personally gets “a bit nervous locking funds for more than a year or two.”

  • ● Securely proving UTXO ownership by revealing a SHA256 preimage: Martin Habovštiak posted to the Bitcoin-Dev mailing list an idea that could allow someone to prove they controlled a UTXO even if ECDSA and schnorr signatures were insecure (e.g., after fast quantum computers existed). If the UTXO contained a SHA256 commitment (or other quantum-resistant commitment) to a preimage that had never previously been revealed, then a multistep protocol for revealing that preimage could be combined with a consensus change to prevent quantum theft. This is fundamentally the same as a previous proposal by Tim Ruffing (see Newsletter #141), which he learned is generally known as the Guy Fawkes signature scheme. It’s also a variant of a scheme Adam Back invented in 2013 to improve resistance against miner censorship. In short, the protocol could work like this:

    1. Alice receives funds to an output that, in some way, makes a SHA256 commitment. This can be a directly hashed output, such as P2PKH, P2SH, P2WPKH, or P2WSH—or it can be P2TR output with a script path.

    2. If Alice receives multiple payments to the same output script, she must either not spend any of them until she’s ready to spend all of them (definitely required for P2PKH and P2WPKH; probably also practically required for P2SH and P2WSH), or she’s very careful to ensure at least one preimage remains unrevealed by her spending (easily possible with P2TR keypath versus scriptpath spends).

    3. When Alice is ready to spend, she privately creates her spending transaction normally but does not broadcast it. She also obtains some bitcoin secured by a quantum-secure signature algorithm so that she can pay transaction fees.

    4. In a transaction spending some of the quantum-secure bitcoins, she commits to the quantum-insecure bitcoins she wants to spend and also commits to the private spending transaction (without revealing it). She waits for this transaction to be deeply confirmed.

    5. After she’s sure her previous transaction can’t practically be reorged, she reveals her previously private preimage and quantum-insecure spend.

    6. Nodes on the network search the blockchain to find the first transaction that commits to the preimage. If that transaction commits to Alice’s quantum-insecure spend, then they execute her spend. Otherwise, they do nothing.

    This ensures that Alice doesn’t have to reveal quantum-vulnerable information until after she’s already ensured her version of the spending transaction will take precedence over any attempted spend by the operator of a quantum computer. For a more precise description of the protocol, please see Ruffing’s 2018 post. Although not discussed in the thread, we believe the above protocol could be deployed as a soft fork.

    Habovštiak argues that bitcoins that can be securely spent using this protocol (e.g., their preimage hasn’t already been revealed) should not be destroyed even if the community decides it wants to destroy quantum-vulnerable bitcoins in general. He also argues that the ability to safely spend some bitcoins in case of emergency reduces the urgency of deploying a quantum-resistant scheme in the short term.

    Lloyd Fournier says, “if this approach gains acceptance I think the main immediate action users can take is to move to a taproot wallet” because of its ability to allow keypath spending under the current consensus rules, including in the case of address reuse, but also resistance to quantum theft if keypath spending is later disabled.

    In a separate thread (see next item), Pieter Wuille notes that UTXOs vulnerable to quantum theft also include keys that have not been used publicly but which are known to multiple parties, such as in various forms of multisig (including LN, DLCs, and escrow services).

  • ● Draft BIP for destroying quantum-insecure bitcoins: Agustin Cruz posted to the Bitcoin-Dev mailing a draft BIP that describes several options for a general process of destroying bitcoins that are vulnerable to quantum theft (if that becomes an expected risk). Cruz argues, “enforcing a deadline for migration, we provide rightful owners with a clear, non-negotiable opportunity to secure their funds […] a forced migration, with sufficient notice and robust safeguards, is both realistic and necessary to protect the long-term security of Bitcoin.”

    Very little of the discussion on the thread focused on the draft BIP. Most of it focused on whether or not destroying quantum-vulnerable bitcoins was a good idea, similar to the thread later started by Jameson Lopp (described in a previous sub-item).

• ● Multiple discussions about a CTV+CSFS soft fork: several conversations examined various aspects of soft forking in the OP_CHECKTEMPLATEVERIFY (CTV) and OP_CHECKSIGFROMSTACK (CSFS) opcodes.

  • ● Criticism of CTV motivation: Anthony Towns posted a criticism of BIP119’s described motivation for CTV, a motivation which he argued would be undermined by adding both CTV and CSFS to Bitcoin. Several days after the discussion started, BIP119 was updated by its author to remove most (and possibly all) of the controversial language; see Newsletter #347 for our summary of the change and the older version of BIP119 for reference. Some of the topics discussed included:

    • ● CTV+CSFS allows the creation of a perpetual covenant: CTV’s motivation said, “Covenants have historically been widely considered to be unfit for Bitcoin because they are too complex to implement and risk reducing the fungibility of coins bound by them. This BIP introduces a simple covenant called a template which enables a limited set of highly valuable use cases without significant risk. BIP119 templates allow for non-recursive fully-enumerated covenants with no dynamic state” (emphasis in original).

      Towns describes a script using both CTV and CSFS, and links to a transaction using it on the MutinyNet signet, that can only be spent by sending the same amount of funds back to the script itself. Although there was some debate about definitions, the author of CTV has previously described a functionally identical construction as a recursive covenant and Optech followed that convention in its summary of that conversation (see Newsletter #190).

      Olaoluwa Osuntokun defended CTV’s motivation related to scripts using it remaining “fully-enumerated” and “with no dynamic state”. This appears to be similar to an argument the author of CTV (Jeremy Rubin) made in 2022, where he called the type of pay-to-self covenant Towns designed “recursive but fully enumerated”. Towns countered that adding CSFS undermines the claimed benefit of full enumeration. He asked for either the CTV or CSFS BIPs to be updated to describe any “use cases that are somehow both scary and still prevented by the combination of CTV and CSFS”. This may have been done in the recent update to BIP119, which describes a “self-reproducing automata (colloquially called SpookChains)” that would be possible using SIGHASH_ANYPREVOUT but which is not possible using CTV+CSFS.

    • ● Tooling for CTV and CSFS: Towns noted that he found it difficult to use existing tools to develop his recursive script described above, indicating a lack of readiness for deployment. Osuntokun said the tooling he uses is “pretty straight forward”. Neither Towns nor Osuntokun mentioned what tools they used. Nadav Ivgi provided an example using his Minsc language and said that he’s “been working on improving Minsc to make these kind of things easier. It supports Taproot, CTV, PSBT, Descriptors, Miniscript, raw Script, BIP32, and more.” Although he admits “much of it is still undocumented”.

    • ● Alternatives: Towns compares CTV+CSFS to both his Basic Bitcoin Lisp Language (bll) and Simplicity, which would provide an alternative scripting language. Antoine Poinsot suggests that an alternative language that’s easy to reason about may be less risky than a small change to the current system, which is hard to reason about. Developer Moonsettler argues that incrementally introducing new features to Bitcoin script makes it safer to add more features later, as each increase in expressivity makes it less likely that we’ll encounter a surprise.

      Both Osuntokun and James O’Beirne criticize the readiness of bll and Simplicity in comparison to CTV and CSFS.

  • ● CTV+CSFS benefits: Steven Roose posted to Delving Bitcoin to suggest adding CTV and CSFS to Bitcoin as a first step to other changes that would increase expressivity further. Most of the discussion focused on qualifying the possible benefits or CTV, CSFS, or both of them together. This included:

    • ● DLCs: both CTV and CSFS individually can reduce the number of signatures needed to create DLCs, especially DLCs for signing large numbers of variants of a contract (e.g., a BTC-USD price contract denominated in increments of one dollar). Antoine Poinsot linked to a recent announcement of a DLC service provider shutting down as evidence that Bitcoin users don’t seem too interested in DLCs and linked to a post a few months ago from Jonas Nick that said, “DLCs have not achieved meaningful adoption on Bitcoin, and their limited use doesn’t appear to stem from performance limitations.” Replies linked to other still-functional DLC service providers, including one that claims to have raised “$30M in financing”.

    • ● Vaults: CTV simplifies the implementation of vaults that are possible today on Bitcoin using presigned transactions and (optionally) private key deletion. Anthony Towns argues that this type of vault isn’t very interesting. James O’Beirne counters that CTV, or something similar, is a prerequisite for building more advanced types of vaults, such as his BIP345 OP_VAULT vaults.

    • ● Accountable computing contracts: CSFS can eliminate many steps in accountable computing contracts such as BitVM by replacing their current need to perform Script-based lamport signatures. CTV may be able to reduce some additional signature operations. Poinsot again asks about whether there’s significant demand for BitVM. Gregory Sanders replies that he would find it interesting for bidirectional bridging of tokens as part of Shielded client-side validation (see Newsletter #322). However, he also notes that neither CTV nor CSFS significantly improve the trust model of BitVM, whereas other changes might be able to reduce trust or reduce the number of expensive operations in other ways.

    • ● Improvement in Liquid timelock script: James O’Beirne relayed comments from two Blockstream engineers that CTV would, in his words, “drastically improve the [Blockstream] Liquid timelock-fallback script that requires coins to be [moved] on a periodic basis.” After requests for clarification, former Blockstream engineer Sanket Kanjalkar explained that the benefit could be a significant savings in onchain transaction fees. O’Beirne also shared additional details from Andrew Poelstra, Blockstream’s Director of Research.

    • ● LN-Symmetry: CTV and CSFS together can be used to implement a form of LN-Symmetry, which eliminates some of the downsides of LN-Penalty channels currently used in LN and may allow the creation of channels with more than two parties, which might improve liquidity management and onchain efficiency. Gregory Sanders, who implemented an experimental version of LN-Symmetry (see Newsletter #284) using SIGHASH_ANYPREVOUT (APO), notes that the CTV+CSFS version of LN-Symmetry isn’t as featureful as the APO version and requires making tradeoffs. Anthony Towns adds that nobody is known to have updated Sanders’s experimental code for APO to run on modern software and use recently introduced relay features such as TRUC and ephemeral anchors, much less has anyone ported the code to use CTV+CSFS, limiting our ability to evaluate that combination for LN-Symmetry.

      Poinsot asks whether implementing LN-Symmetry would be a priority for LN developers if a soft fork made it possible. Quotes from two Core Lightning developers (also co-authors of the paper introducing what we now call LN-Symmetry) indicated that it was a priority for them. By comparison, LDK lead developer Matt Corallo previously said, “I don’t find [LN-Symmetry] all that interesting in terms of ‘we need to get this done’”.

    • ● Ark: Roose is the CEO of a business building an Ark implementation. He says, “CTV is a game-changer for Ark […] the benefits of CTV to the user experience are undeniable, and it is without doubt that both [Ark] implementations will utilize CTV as soon as it is available.” Towns noted that nobody has implemented Ark with either APO or CTV for testing; Roose wrote code doing that shortly thereafter, calling it “remarkably straightforward” and saying that it passed the existing implementation’s integration tests. He quantified some of the improvements: if they switched to CTV, “we could net remove about 900 lines of code […] and reduce our own round protocol to [two] instead of three, [plus] the bandwidth improvement for not having to pass around signing nonces and partial signatures.”

      Roose would later start a separate thread to discuss the benefits of CTV for users of Ark (see our summary below).

  • ● Benefit of CTV to Ark users: Steven Roose posted to Delving Bitcoin a short description of the Ark protocol currently deployed to signet, called covenantless Ark (clArk), and how the availability of the OP_CHECKTEMPLATEVERIFY (CTV) opcode could make a covenant-using version of the protocol more appealing to users when it’s eventually deployed to mainnet.

    One design goal for Ark is to allow async payments: payments made when the receiver is offline. In clArk, this is achieved by the spender plus an Ark server extending the spender’s existing chain of presigned transactions, allowing the receiver to ultimately accept exclusive control over the funds. The payment is called an Ark out-of-round payment (arkoor). When the receiver comes online, they can choose what they want to do:

    • ● Exit, after a delay: broadcast the entire chain of presigned transactions, exiting the joinpool (called an Ark). This requires waiting for the expiry of a timelock agreed to by the spender. When the presigned transactions are confirmed to a suitable depth, the receiver can be certain they have trustless control over the funds. However, they lose the benefits of being part of a joinpool, such as rapid settlement and lower fees deriving from UTXO sharing. They may also need to pay transaction fees to confirm the chain of transactions.

    • ● Nothing: in the normal case, a presigned transaction in the chain of transactions will eventually expire and allow the server to claim the funds. This is not theft—it’s an expected part of the protocol—and the server may choose to return some or all of the claimed funds to the user in some way. Until the expiry approaches, the receiver can just wait.

      In the pathological case, the server and spender can (at any time) collude to sign an alternative chain of transactions to steal the funds sent to the receiver. Note: Bitcoin’s privacy properties allow both the server and the spender to be the same person, so collusion might not even be required. However, if the receiver keeps a copy of the chain of transactions cosigned by the server, they can prove that the server stole funds, which might be sufficient to deter other people from using that server.

    • ● Refresh: with server cooperation, the receiver can atomically transfer ownership over the funds in the spender-cosigned transaction for another presigned transaction with the receiver as a cosigner. This extends the expiration date and eliminates the ability for the server and previous spender to collude to steal the previously sent funds. However, refreshing requires that the server hold on to the refreshed funds until they expire, reducing the server’s liquidity, so the server charges the receiver an interest rate until expiration (paid upfront since the expiration time is fixed).

    Another design goal for Ark is to allow participants to receive LN payments. In his original post and a reply, Roose describes that existing participants who already have funds inside the joinpool can be penalized up to the cost of an onchain transaction if they fail to perform the interactivity required for receiving an LN payment. However, those who don’t already have funds in the joinpool can’t be penalized, so they can refuse to perform the interactive steps and costlessly create problems for honest participants. This appears to effectively prevent Ark users from receiving LN payments unless they already have a moderate amount of funds on deposit with the Ark server they want to use.

    Roose then describes how the availability of CTV would allow the protocol to be improved. The main change is how Ark rounds are created. An Ark round consists of a small onchain transaction that commits to a tree of offchain transactions. These are presigned transactions in the case of clArk, requiring all of the spenders in that round to be available for signing. If CTV was available, each branch in the tree of transactions can commit to its descendants using CTV with no signing required. This allows the creation of transactions even for participants who aren’t available at the time the round is created, with the following benefits:

    • ● In-round non-interactive payments: instead of Ark out-of-round (arkoor) payments, a spender who is willing to wait for the next round can pay the receiver in-round. For the receiver, this has a major advantage: as soon as the round confirms to a suitable depth, they receive trustless control over their received funds (until expiration approaches, at which time they can either exit or cheaply refresh). Instead of waiting for several confirmations, the receiver can choose to immediately trust the incentives created by the Ark protocol for the server to operate honestly (see Newsletter #253). In a separate point, Roose notes that these non-interactive payments can also be batched to pay multiple receivers at once.

    • ● In-round acceptance of LN payments: a user could request an LN payment (HTLC) be sent to an Ark server, the server would then hold the payment until its next round, and it would use CTV to include an HTLC-locked payment to the user in the round—after which the user could disclose the HTLC preimage to claim the payment. However, Roose noted that this would still require the use of “various anti-abuse measures” (we believe that this is because of the risk of the receiver failing to disclose the preimage, leading to the server’s funds remaining locked until the end of the Ark round, which might extend for two or more months).

      David Harding replied to Roose asking for additional details and comparing the situation to LN JIT channels, which have a similar problem with non-revelation of HTLC preimages creating problems for Lightning Service Providers (LSPs). LSPs currently address that problem through the introduction of trust-based mechanisms (see Newsletter #256). If the same solutions were planned to be used with CTV-Ark, those solutions would also seem to safely allow in-round acceptance of LN payments in clArk.

    • ● Fewer rounds, fewer signatures, and less storage: clArk uses MuSig2, and each party needs to participate in multiple rounds, generate multiple partial signatures, and store completed signatures. With CTV, less data would need to be generated and stored and less interaction would be required.

• ● OP_CHECKCONTRACTVERIFY semantics: Salvatore Ingala posted to Delving Bitcoin to describe the semantics of the proposed OP_CHECKCONTRACTVERIFY (CCV) opcode, link to a first draft BIP, and link to an implementation draft for Bitcoin Core. His description starts with an overview of CCV’s behavior: it allows checking that a public key commits to an arbitrary piece of data. It can check both the public key of the taproot output being spent or the public key of a taproot output being created. This can be used to ensure that data from the output being spent is carried over to the output being created. In taproot, a tweak of the output can commit to tapleaves such tapscripts. If the tweak commits to one or more tapscripts, it places an encumbrance (spending condition) on the output, allowing conditions placed on the output being spent to be transferred to the output being created—commonly (but controversially) called a covenant in Bitcoin jargon. The covenant may allow satisfaction or modification of the encumbrance, which would (respectively) terminate the covenant or modify its terms for future iterations. Ingala describes some of the benefits and drawbacks of this approach:

  • ● Benefits: taproot native, doesn’t increase the size of taproot entries in the UTXO set, and spending paths that don’t require the extra data don’t need to include it in their witness stack (so there’s no extra cost in that case).

  • ● Drawbacks: only works with taproot and checking tweaks requires elliptic curve operations that are more expensive than (say) SHA256 operations.

  Only transferring the spending conditions from the output being spent to an output being created can be useful, but many covenants will want to ensure some or all of the bitcoins in the output being spent are passed through to the output being created. Ingala describes CCV’s three options for handling values.

  • ● Ignore: don’t check amounts.

  • ● Deduct: the amount of an output being created at a particular index (e.g., the third output) is deducted from the amount of the output being spent at the same index and the residual value is tracked. For example, if the output being spent at index three is worth 100 BTC and the output being created at index three is worth 70 BTC, then the code keeps track of the residual 30 BTC. The transaction is marked as invalid if the output being created is greater than the output being spent (as that would reduce the residual value, perhaps below zero).

  • ● Default: mark the transaction invalid unless the amount of output being created at a particular index is greater than the amount of the output being spent plus the sum of any previous residuals that haven’t been used with a default check yet.

  A transaction is valid if any output is checked more than once with deduct or if both deduct and default are used on the same output.

  Ingala provides several visual examples of combinations of the above operations. Here’s our textual description of his “send partial amount” example, which might be useful for a vault: a transaction has one input (spending one output) worth 100 BTC and two outputs, one for 70 BTC and the other for 30 BTC. CCV is run twice during transaction validation:

  1. CCV with deduct operates index 0 for 100 BTC spent to 70 BTC created, giving a residual of 30. In a BIP345-style vault, CCV would be returning that 70 BTC back to the same script it was previously secured by.

  2. The second time, it uses default on index 1. Although there’s an output being created at index 1 in this transaction, there’s no corresponding output being spent at index 1, so the implicit amount 0 is used. To that zero is added the residual 30 BTC from the deduct call on index 0, requiring this output being created equal 30 BTC or greater. In a BIP345-style vault, CCV would tweak the output script to allow spending this value to an arbitrary address after a timelock expires or returning it to the user’s main vault address at any time.

  Several alternative approaches that Ingala considered and discarded are discussed both in his post and the replies. He writes, “I think the two amount behaviors (default and deduct) are very ergonomic, and cover the vast majority of the desirable amount checks in practice.”

  He also notes that he “implemented fully featured vaults using OP_CCV plus OP_CTV that are roughly equivalent to […BIP345…] Moreover, a reduced-functionality version using just OP_CCV is implemented as a functional test in the Bitcoin Core implementation of OP_CCV.”

• ● Draft BIP published for consensus cleanup: Antoine Poinsot posted to the Bitcoin-Dev mailing list a link to a draft BIP he’s written for the consensus cleanup soft fork proposal. It includes several fixes:

  • ● Fixes for two different time warp attacks that could be used by a majority of hashrate to produce blocks at an accelerated rate.

  • A signature operations (sigops) execution limit on legacy transactions to prevent the creation of excessively slow-to-validate blocks.

  • ● A fix for BIP34 coinbase transaction uniqueness that should fully prevent duplicate transactions.

  • Invalidation of future 64-byte transactions (calculated using stripped size) to prevent a type of merkle tree vulnerability.

  Technical replies were favorable for all but two parts of the proposal. The first objection, made in several replies, was to the invalidation of 64-byte transactions. The replies restated previous criticism (see Newsletter #319). An alternative method for addressing merkle tree vulnerabilities exists. That method is relatively easy for lightweight (SPV) wallets to use but might present challenges to SPV validation in smart contracts, such as bridges between Bitcoin and other systems. Sjors Provoost suggested someone implementing an onchain-enforceable bridge provide code illustrating the difference between being able to assume 64-byte transactions don’t exist and having to use the alternative method for preventing merkle tree vulnerabilities.

  The second objection was about a late change to the ideas included in the BIP, which was described in a post on Delving Bitcoin by Poinsot. The change requires blocks made after activation of consensus cleanup to set the flag that makes their coinbase transaction locktime enforceable. As previously proposed, coinbase transactions in post-activation blocks will set their locktime to their block height (minus 1). This change means no miner can produce an alternative early Bitcoin block that uses both post-activation locktime and sets the enforcement flag (because, if they did, their coinbase transaction wouldn’t be valid in the block that included it due to its use of a far-future locktime). The inability to use exactly the same values in a past coinbase transaction as will be used in a future coinbase transaction prevents the duplicate transactions vulnerability. The objection to this proposal was that it wasn’t clear whether all miners are capable of setting the locktime enforcement flag.

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 wallet 1.2.0 adds flexibility for sending payments to custom scripts, fixes an edge case related to coinbase transactions, and includes several other features and bug fixes.

• ● LDK v0.1.2 is a release of this library for building LN-enabled applications. It contains several performance improvements and bug fixes.

• ● Bitcoin Core 29.0rc3 is a release candidate for the next major version of the network’s predominate full node. Please see the version 29 testing guide.

• ● LND 0.19.0-beta.rc1 is a release candidate for this popular LN node. One of the major improvements that could probably use testing is the new RBF-based fee bumping for cooperative closes.

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.

• ● Bitcoin Core #31363 introduces the TxGraph class (see Newsletter #341), a lightweight in-memory model of mempool transactions that tracks only feerates and dependencies between transactions. It includes mutation functions such as AddTransaction, RemoveTransaction, and AddDependency, and inspection functions such as GetAncestors, GetCluster, and CountDistinctClusters. TxGraph also supports staging of changes with commit and abort functionality. This is part of the cluster mempool project, and prepares for future improvements to mempool eviction, reorganization handling, and cluster-aware mining logic.

• ● Bitcoin Core #31278 deprecates the settxfee RPC command and the -paytxfee startup option, which allow users to set a static fee rate for all transactions. Users should instead rely on fee estimation or set a per-transaction fee rate. They are marked for removal in Bitcoin Core 31.0.

• ● Eclair #3050 updates how BOLT12 payment failures are relayed when the recipient is a directly connected node, to always forward the failure message instead of overriding it with an unreadable invalidOnionBlinding failure. If the failure includes a channel_update, Eclair overrides it with TemporaryNodeFailure to avoid revealing details about unannounced channels. For blinded routes involving other nodes, Eclair continues to override failures with invalidOnionBlinding. All failure messages are encrypted using the wallet’s blinded_node_id.

• ● Eclair #2963 implements one-parent-one-child (1p1c) package relay by calling Bitcoin Core’s submitpackage RPC command during channel force closures to broadcast both the commitment transaction and its anchor together. This allows commitment transactions to propagate even if their feerate is below the mempool minimum, but requires connecting to peers running Bitcoin Core 28.0 or later. This change removes the need to dynamically set the feerate of commitment transactions, and ensures that force closures don’t get stuck when nodes disagree on the current feerate.

• ● Eclair #3045 makes the payment_secret field in the outer onion payload optional for single-part trampoline payments. Previously, every trampoline payment included a payment_secret, even if a multipath payment (MPP) wasn’t used. Since payment secrets may be required when handling modern BOLT11 invoices, Eclair inserts a dummy one on decryption if one isn’t provided.

• ● LDK #3670 adds support for handling and receiving trampoline payments, but does not yet implement providing a trampoline routing service. This is a prerequisite for a type of async payment that LDK plans to deploy.

• ● LND #9620 adds testnet4 support by adding the necessary parameters and blockchain constants such as its genesis hash.