This week’s newsletter summarizes a CTV-like proposal that uses commitments embedded in public keys, examines the analysis of a contract protocol with Alloy, announces the arrests of Bitcoin developers, and links to summaries of a CoreDev.tech developer meetup. Also included are our regular sections announcing new releases and release candidates and summarizing notable changes to popular Bitcoin infrastructure software.

News

  • ● CTV-like exploding keys proposal: Tadge Dryja posted to Delving Bitcoin a proposal for a slightly more efficient version of the core idea of OP_CHECKTEMPLATEVERIFY (CTV). With CTV, Alice can pay to an output like:

    OP_CTV <hash>

    The preimage for the hash digest is a commitment to the key parts of a transaction, most especially the amount of each output and the script to pay for each output. For example:

    hash(
  2 BTC to KeyB,
  3 BTC to KeyC,
  4 BTC to KeyD
)

    The OP_CTV opcode will succeed if it’s executed in a transaction that exactly matches those parameters. That means Alice’s output in one transaction can be spent in a second transaction without requiring an additional signature or any other data, as long as that second transaction matches what Alice expected.

    Dryja suggests an alternative method. Alice pays to a public key (similar to a taproot output but with a different segwit version). The public key is constructed from a MuSig2 aggregation of one or more actual public keys plus a tweak for each key that securely commits to an amount. For example (adapted from Dryja’s post):

    musig2(
  KeyB + hash(2 BTC, KeyB)*G,
  KeyC + hash(3 BTC, KeyC)*G,
  KeyD + hash(4 BTC, KeyD)*G
)

    A transaction will be valid if it pays the underlying public keys in exactly the amounts specified. No signature is required in that case. This saves some space when compared to CTV in taproot, a minimum of about 16 vbytes. It seems to use about the same amount of space when compared to CTV in a bare script (i.e., directly placed in an output script).

    When CTV is used in taproot, a keypath spend mutually agreed upon by all involved can be provided as an alternative to executing the CTV, allowing the parties to change where the funds go. Exploding keys allows the same thing by the people who control KeyB, KeyC, KeyD. The efficiency is the same either way.

    Dryja writes that exploding keys “gives the basic functionality of OP_CTV, while saving a few bytes of witness data. On its own it’s maybe not all that compelling, but I wanted to put it out there as maybe it could be a useful primitive as part of a more complex covenant construction.”

  • ● Analyzing a contract protocol with Alloy: Dmitry Petukhov posted to Delving Bitcoin a specification he had created using the Alloy specification language for the simple OP_CAT-based vault described in Newsletter #291. Petukhov used Alloy to find several useful modifications and to highlight important constraints that any potential implementors should observe. We recommend anyone interested in formal modeling of contract protocols read his post and his extensively documented specification.

  • ● Arrests of Bitcoin developers: as widely reported elsewhere, two developers of the Samourai privacy-enhanced Bitcoin wallet were arrested last week in relation to their software, based on charges by U.S. law enforcement. Subsequently, two other companies have announced their intention to stop serving U.S. customers due to the legal risks.

    Optech’s specialty is writing about Bitcoin technology, so we plan to leave reporting about this legal situation to other publications—but we urge anyone interested in the success of Bitcoin, especially those in the U.S. or with ties to its people, to stay informed and to consider offering support when opportunities arise.

  • ● CoreDev.tech Berlin event: many Bitcoin Core contributors met in person for a periodic CoreDev.tech event last month in Berlin. Transcripts for some of the sessions from the event have been provided by attendees. Presentations, code reviews, working groups, or other sessions covered, among other topics:

    • ASMap research findings
    • assumeUTXO Mainnet Readiness
    • BTC Lisp
    • CMake
    • cluster mempool
    • coin selection
    • cross-input signature aggregation
    • current network spam
    • fee estimation
    • general BIP discussion
    • great consensus cleanup
    • GUI discussions
    • legacy wallet removal
    • libbitcoinkernel
    • MuSig2
    • P2P monitoring
    • package relay review
    • private transaction broadcasting
    • review of current GitHub Issues
    • review of current GitHub PRs
    • signet/testnet4
    • silent payments
    • Stratum v2 template provider
    • warnet
    • weak blocks

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, Bitcoin Inquisition, and BINANAs.

  • ● Bitcoin Core #27679 allows notifications sent using the ZMQ dispatcher to be published to a Unix domain socket. This was previously supported (possibly unintentionally) by passing a configuration option in a way that wasn’t documented. Bitcoin Core #22087 made configuration option parsing more strict, breaking the undocumented support in Bitcoin Core 27.0, which affected LND and possibly other programs. This PR makes the option officially supported and slightly changes its semantics to make it consistent with other options for Unix sockets in Bitcoin Core, such as the change described in Newsletter #294.

  • ● Core Lightning #7240 adds support for retrieving required blocks from the Bitcoin P2P network if the local Bitcoin node has pruned them. If the CLN node needs a block that has been pruned by its local bitcoind, it will call the Bitcoin Core RPC getblockfrompeer to request it from a peer. If the block is successfully retrieved, Bitcoin Core authenticates it by connecting it to the header it keeps (even for pruned blocks) and saves it locally, where it can be retrieved using standard block-retrieval RPCs.

  • ● Eclair #2851 begins depending on Bitcoin Core 26.1 or greater and removes code for ancestor-aware funding. Instead, the upgrade allows it to use Bitcoin Core’s new native code that is designed to compensate for any fee deficit (see Newsletter #269).

  • ● LND #8147, #8422, #8423, #8148, #8667, and #8674 replace LND’s old sweeper with a new implementation, allowing the broadcast of settlement transactions and any transactions needed to effectively fee bump them. Both the old and new implementations mostly accept the same parameters, such as the deadline by which the transaction must be confirmed and the starting feerate to use, with the new implementation also adding a budget that is the maximum amount to pay in fees. The new implementation provides more configurability, makes writing tests easier, makes use of both CPFP and RBF fee bumping (each when appropriate), does a better job of batching fee bumps to save on fees, and only updates feerates each block rather than every 30 seconds.

  • ● LND #8627 now defaults to rejecting user-requested changes to channel settings that require above-zero inbound forwarding fees. For example, imagine Alice wants to forward a payment through Bob to Carol. By default, Bob can no longer use the newly-added LND feature for inbound forwarding fees (see Newsletter #297) to require that Alice pay extra. This new default ensures that Bob’s node remains compatible with nodes that don’t support inbound forwarding fees (which is currently almost all LN nodes). Bob can choose to be backwards incompatible by overriding the default with the accept-positive-inbound-fees LND configuration setting, or he can possibly achieve the desired result while remaining backwards compatible by raising his outbound forwarding fee to Carol and then using negative inbound forwarding fees to offer discounts on payments that don’t originate from Alice.

  • ● Libsecp256k1 #1058 changes the algorithm used for generating public keys and signatures. Both the old algorithm and the new algorithm run in constant time to avoid creating timing side-channel vulnerabilities. Benchmarks with the new algorithm show it to be about 12% faster. A short blog post by one of the PR reviewers describes how the new algorithm works.

  • ● BIPs #1382 assigns BIP331 to the proposal for ancestor package relay.

  • ● BIPs #1068 swaps two parameters in BIP47 version 1 reusable payment codes to match an implementation in Samourai wallet. Details about where to find information for later versions of reusable payment codes is also added to the BIP. Note that Samourai’s initial implementation of BIP47 occurred years ago and that this PR was open for over three years before its merge this past week.