This week’s newsletter briefly mentions a recent security disclosure affecting LN users, describes a paper about making payments contingent on the result of running arbitrary programs, and announces a proposed BIP to add fields to PSBTs for MuSig2. Also included are our regular sections that summarize improvements to clients and services, announce new releases and release candidates, and describe notable changes to popular Bitcoin infrastructure software.

News

  • ● Security disclosure of issue affecting LN: Antoine Riard posted to the Bitcoin-Dev and Lightning-Dev mailing lists the full disclosure of an issue he had previously responsibly disclosed to developers working on the Bitcoin protocol and various popular LN implementations. The most recent versions of Core Lightning, Eclair, LDK, and LND all contain mitigations that make the attack less practical, although they do not eliminate the underlying concern.

    The disclosure was made after Optech’s usual news deadline, so we are only able to provide the above link in this week’s newsletter. We will provide a regular summary in next week’s newsletter.

  • ● Payments contingent on arbitrary computation: Robin Linus posted to the Bitcoin-Dev mailing list a paper he’s written about BitVM, a combination of methods that allows bitcoins to be paid to someone who successfully proves that an arbitrary program executed successfully. Notably, this is possible on Bitcoin today—no consensus change is required.

    To provide context, a well-known feature of Bitcoin is to require someone to satisfy a programming expression (called a script) in order to spend bitcoins associated with that script. For example, a script containing a public key that can only be satisfied if the corresponding private key creates a signature committing to a spending transaction. Scripts must be written in Bitcoin’s language (called Script) in order to be enforced by consensus, but Script is deliberately limited in its flexibility.

    Linus’s paper gets around some of those limits. If Alice trusts Bob to take action if a program was run incorrectly, but does not want to trust him with anything else, she can pay funds to a taproot tree that will allow Bob to claim the funds if he demonstrates that Alice failed to run an arbitrary program correctly. If Alice does run the program correctly, then she can spend the funds even if Bob attempts to stop her.

    To use an arbitrary program, it must be broken down into a very basic primitive (a NAND gate) and a commitment must be made for each gate. This requires the offchain exchange of a very large amount of data, potentially multiple gigabytes for even a fairly basic arbitrary program—but Alice and Bob only need a single onchain transaction in the case that Bob agrees that Alice ran the program correctly. In the case that Bob disagrees, he should be able to demonstrate Alice’s failure within a relatively small number of onchain transactions. If the setup was performed in a payment channel between Alice and Bob, multiple programs could be run both in parallel and in sequence with no onchain footprint except channel setup and either a mutual close or a force close where Bob attempts to demonstrate that Alice failed to follow the arbitrary program logic correctly.

    BitVM can be applied trustlessly in cases where Alice and Bob are natural adversaries, such as where they pay funds to an output that will be paid to whichever one of them wins in a game of chess. They can then use two (almost identical) arbitrary programs, each of which takes the same arbitrary set of chess moves. One program will return true if Alice won and one will return true if Bob won. One party will then publish onchain the transaction that claims their program evaluates to true (that they won); the other party will either accept that claim (conceding the loss of funds) or will demonstrate the fraud (receiving the funds if successful). In cases where Alice and Bob would not naturally be adversaries, Alice may be able to incentivize him to verify correct computation, such by offering her funds to Bob if he can prove she failed to compute correctly.

    The idea received a significant amount of discussion on the mailing list as well as on Twitter and various Bitcoin-focused podcasts. We expect continued discussion in the coming weeks and months.

  • ● Proposed BIP for MuSig2 fields in PSBTs: Andrew Chow posted to the Bitcoin-Dev mailing list with a draft BIP, partly based on prior work by Sanket Kanjalkar, for adding several fields to all versions of PSBTs for the “keys, public nonces, and partial signatures produced with MuSig2.”

    Anthony Towns asked whether the proposed BIP would also include fields for adaptor signatures, but continued discussion indicated that would likely need to be defined in a separate BIP.

Changes to services and client software

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

  • ● BIP-329 Python library released: The BIP-329 Python Library is a set of tools that can read, write, encrypt, and decrypt BIP329-compliant wallet label files.

  • ● LN testing tool Doppler announced: Recently announced, Doppler supports defining Bitcoin and Lightning node topologies and onchain/offchain payment activity using a Domain-Specific Language (DSL) to test LND, CLN, and Eclair implementations together.

  • ● Coldcard Mk4 v5.2.0 released: The firmware updates include BIP370 support for version 2 PSBTs, additional BIP39 support, and multiple seed capabilities.

  • ● Tapleaf circuits: a BitVM demo: Tapleaf circuits is a proof-of-concept implementation of Bristol circuits using the BitVM approach outlined earlier in the newsletter.

  • ● Samourai Wallet 0.99.98i released: The 0.99.98i release includes additional PSBT, UTXO labeling, and batch-sending features.

  • ● Krux: signing device firmware: Krux is an open-source firmware project for building hardware signing devices using commodity hardware.

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 changes this week 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.

  • ● Bitcoin Core #27255 ports miniscript to tapscript. This code change makes miniscript an option for P2TR output descriptors, adding support for both watching and signing “TapMiniscript descriptors”. Previously, miniscript was available only for P2WSH output descriptors. The author notes that a new multi_a fragment is introduced exclusively for P2TR descriptors that matches the semantics of multi in P2WSH descriptors. The discussion on the PR notes that a majority of the work went towards proper tracking of the changed resource limits for tapscript.

  • ● Eclair #2703 discourages spenders from forwarding payments through the local node when the node’s balance is low and it would probably need to reject those payments. This is accomplished by the node advertising that its maximum HTLC amount has been lowered. Preventing rejected payments improves the experience for spenders and helps avoid the local node being penalized by pathfinding systems that discount nodes that have failed to forward a payment in the recent past.

  • ● LND #7267 makes it possible to create routes to blinded paths, bringing LND much closer to full support for making blinded payments.

  • ● BDK #1041 adds a module for getting data about the block chain from Bitcoin Core using that program’s RPC interface.