This week’s newsletter describes a proposal to limit public participation in Bitcoin Core repositories, announces a significant improvements to BitVM-style contracts, and summarizes research into LN channel rebalancing. Also included are our regular sections summarizing recent changes to clients and services, announcing new releases and release candidates, and describing recent changes to popular Bitcoin infrastructure software.

News

  • ● Proposal to restrict access to Bitcoin Core Project discussion: Bryan Bishop posted to the Bitcoin-Dev mailing list to suggest that the Bitcoin Core Project limit the public’s ability to participate in project discussions in order to reduce the amount of disruption caused by non-contributors. He called this “privatizing Bitcoin Core”, points to examples of this privatization already happening on an ad hoc basis in private offices with multiple Bitcoin Core contributors, and warns that in-person privatization leaves out remote contributors.

    Bishop’s post suggests a method for online privatization, but Antoine Poinsot questioned whether that method would achieve the goal. Poinsot also suggested that many private office discussions might occur not out of fear of public reproach but because of “the natural advantages of in-person discussions”.

    Several replies suggested that making major changes is probably not warranted at this time but that stronger moderation of comments on the repository might alleviate the most significant type of disruption. However, other replies noted several challenges with stronger moderation.

    Poinsot, Sebastian “The Charlatan” Kung, and Russell Yanofsky—the only highly active Bitcoin Core contributors to reply to the thread as of the time of writing—indicated either that they don’t think a major change is necessary or that any changes should be made incrementally over time.

  • ● Improvements to BitVM-style contracts: Robin Linus posted to Delving Bitcoin to announce a significant reduction in the amount of onchain space required by BitVM-style contracts. Based on an idea by Jeremy Rubin that builds on new cryptographic primitives, the new approach “reduces the onchain cost of a dispute by over 1,000 times compared to the previous design”, with disprove transactions being “just 200 bytes”.

    However, Linus’s paper notes the tradeoff for this approach: it “requires a multi-terabyte offchain data setup”. The paper gives an example of a SNARK verifier circuit with about 5 billion gates and reasonable security parameters requiring a 5 TB offchain setup, 56 kB onchain transaction to assert the result, and minimal onchain transaction (~200 B) in the case that a party needs to prove the assertion was invalid.

  • ● Channel rebalancing research: Rene Pickhardt posted to Delving Bitcoin thoughts about rebalancing channels to maximize the rate of successful payments across the whole network. His ideas can be compared to approaches that look at smaller groups of channels, such as friend-of-a-friend rebalancing (see Newsletter #54).

    Pickhardt notes that there are several challenges to a global approach and asks interested parties to answer a few questions, such as whether this approach is worth pursuing and how to address certain implementation details.

Changes to services and client software

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

  • ● Cove v1.0.0 released: Recent Cove releases include coin control support and additional BIP329 wallet label features.

  • ● Liana v11.0 released: Recent releases of Liana include features for multiple wallets, additional coin control features, and more hardware signing device support, among other features.

  • ● Stratum v2 STARK proof demo: StarkWare demonstrated a modified Stratum v2 mining client using a STARK proof to prove that a block’s fees belongs to a valid block template without revealing the transactions in the block.

  • ● Breez SDK adds BOLT12 and BIP353: Breez SDK Nodeless 0.9.0 adds support for receiving using BOLT12 and BIP353.

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.

  • ● Core Lightning 25.05 is a release of the next major version of this popular LN node implementation. It reduces the latency of relaying and resolving payments, improves fee management, provides splicing support compatible with Eclair, and enables peer storage by default. Note: its release documentation contains a warning for users of the --experimental-splicing configuration option.

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.

  • ● Eclair #3110 raises the delay for marking a channel as closed after its funding output is spent from 12 (see Newsletter #337) to 72 blocks as specified in BOLTs #1270, to allow for the propagation of a splice update. It was increased because some implementations default to 8 confirmations before sending splice_locked and allow node operators to raise that threshold, so 12 blocks proved too short. The delay is now configurable for testing purposes and to allow node operators to wait longer.

  • ● Eclair #3101 introduces the parseoffer RPC, which decodes BOLT12 offer fields into a human-readable format, allowing users to view the amount before passing it to the payoffer RPC. The latter is extended to accept an amount specified in a fiat currency.

  • ● LDK #3817 rolls back support for attributable failures (see Newsletter #349) by placing it under a test-only flag. This disables the peer penalization logic and removes the feature TLV from failure onion messages. Nodes that hadn’t upgraded yet were wrongly penalized, showing that broader network adoption is necessary for it to work properly.

  • ● LDK #3623 extends peer storage (see Newsletter #342) to provide automatic, encrypted peer backups. Each block, ChainMonitor packages the data from a versioned, timestamped, and serialized ChannelMonitor structure into an OurPeerStorage blob. Then, it encrypts the data and raises a SendPeerStorage event to relay the blob as a peer_storage message to every channel peer. Additionally, ChannelManager is updated to handle peer_storage_retrieval requests by triggering a new blob send.

  • ● BTCPay Server #6755 enhances the coin control user interface with new minimum and maximum amount filters, before and after creation date filters, a help section for the filters, a “select all” UTXO checkbox, and large page size options (100, 200 or 500 UTXOs).

  • ● Rust libsecp256k1 #798 completes the MuSig2 implementation in the library, giving downstream projects access to a robust scriptless multisignature protocol.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 16:30 UTC on June 24. The discussion is also recorded and will be available from our podcasts page.