This week’s newsletter describes a distributed key generation protocol for the FROST scriptless threshold signature scheme and links to a comprehensive introduction to cluster linearization. Also included are our regular sections describing recent changes to clients, services, and popular Bitcoin infrastructure projects.

News

  • ● Distributed key generation protocol for FROST: Tim Ruffing and Jonas Nick posted to the Bitcoin-Dev mailing list a BIP draft with a reference implementation of ChillDKG, a protocol for securely generating keys to be used with FROST-style scriptless threshold signatures that are compatible with Bitcoin’s schnorr signatures.

    Scriptless threshold signatures are compatible with the creation of n keys, any t of which can be used cooperatively to create a valid signature. For example, a 2-of-3 scheme creates three keys, any two of which can produce a valid signature. Being scriptless, the scheme relies entirely on operations external to consensus and the blockchain, unlike Bitcoin’s built-in scripted threshold signature operations (e.g., using OP_CHECKMULTISIG).

    Similar to generating a regular Bitcoin private key, each person creating a key for scriptless threshold signatures must generate a large random-like number without disclosing that number to anyone else. However, each person must also distribute derived shares of that number across the other users so that a threshold number of them can create a signature if that key is unavailable. Each user must verify that the information they received from every other user was generated correctly. Several key generation protocols for performing these steps exist, but they assume the key-generating users have access to a communication channel that is encrypted and authenticated between individual pairs of users and that also allows uncensorable authenticated broadcast from each user to all other users. The ChillDKG protocol combines a well-known key generation algorithm for FROST with additional modern cryptographic primitives and simple algorithms to provide the necessary secure, authenticated, and provably uncensored communication.

    Encryption and authentication between participants starts with an elliptic curve diffie-hellman (ECDH) exchange. Proof of non-censorship is created by each participant using their base key to sign a transcript of the session from its start until the scriptless threshold public key is produced (which is the end of the session). Before accepting the threshold public key as correct, each participant verifies every other participant’s signed session transcript.

    The goal is to provide a fully generalized protocol that is usable in all cases where people want to generate keys for FROST-based scriptless threshold signatures. Additionally, the protocol helps keep backups simple: all a user needs is their private seed and some recovery data that is not security sensitive (but does have privacy implications). In a follow-up message, Jonas Nick mentioned that they’re considering extending the protocol to encrypt the recovery data by a key derived from the seed so that the only data the user needs to keep private is their seed.

  • ● Introduction to cluster linearization: Pieter Wuille posted to Delving Bitcoin a detailed description of all the major parts of cluster linearization, the basis for cluster mempool. Previous Optech newsletters have attempted to introduce the subject as its key concepts were being developed and published, but this overview is much more comprehensive. It takes readers in order from fundamental concepts to the specific algorithms being implemented. It ends with links to several Bitcoin Core pull requests that implement parts of cluster mempool.

Changes to services and client software

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

  • ● ZEUS adds BOLT12 offers and BIP353 support: The v0.8.5 release leverages the TwelveCash service to support offers and BIP353 (see Newsletter #307).

  • ● Phoenix adds BOLT12 offers and BIP353 support: The Phoenix 2.3.1 release added offers support and Phoenix 2.3.3 added BIP353 support.

  • ● Stack Wallet adds RBF and CPFP support: Stack Wallet’s v2.1.1 release added support for fee bumping using RBF and CPFP as well as Tor support.

  • ● BlueWallet adds silent payment send support: In the v6.6.7 release, BlueWallet added the ability to send to silent payment addresses.

  • ● BOLT12 Playground announced: Strike announced a testing environment for BOLT12 offers. The project uses Docker to initiate and automate wallets, channels, and payments across different LN implementations.

  • ● Moosig testing repository announced: Ledger has published a Python-based testing repository for using MuSig2 and BIP388 wallet policies for descriptor wallets.

  • ● Real-time Stratum visualization tool released: The stratum.work website, based on previous research, displays real-time Stratum messages from a variety of Bitcoin mining pools, with source code available.

  • ● BMM 100 Mini Miner announced: The mining hardware from Braiins comes with a subset of Stratum V2 features enabled by default.

  • ● Coldcard publishes URL-based transaction broadcast specification: The protocol enables broadcasting of a Bitcoin transaction using an HTTP GET request and can be used by NFC-based hardware signing devices, among other use cases.

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 #26596 uses the new read-only legacy database for migrating legacy wallets to descriptor wallets. This change does not deprecate legacy wallets or the legacy BerkeleyDatabase. A new LegacyDataSPKM class has been created that contains only the essential data and functions needed to load a legacy wallet for migration. See Newsletter #305 for an introduction to the BerkeleyRODatabase.

  • ● Core Lightning #7455 enhances connectd’s onion message handling by implementing forwarding via both short_channel_id (SCID) and node_id (see Newsletter #307 for discussion about a similar change to LDK). Onion messages are now always enabled, and incoming messages are rate limited to 4 per second.

  • ● Eclair #2878 makes the route blinding and channel quiescence features optional, since they’re now fully implemented and part of the BOLT specification (see Newsletters #245 and #309). An Eclair node advertises support for these features to its peers, but has route_blinding disabled by default because it will not forward blinded payments that do not use trampoline routing.

  • ● Rust Bitcoin #2646 introduces new inspectors for script and witness structures such as redeem_script to ensure compliance with BIP16; rules regarding P2SH spending, taproot_control_block, and taproot_annex to ensure compliance with BIP341 rules; and witness_script to ensure P2WSH witness scripts comply with BIP141 rules. See Newsletter #309.

  • ● BDK #1489 updates bdk_electrum to use merkle proofs for simplified payment verification (SPV). It fetches merkle proofs and block headers alongside transactions, validates that transactions are in confirmed blocks before inserting anchors, and removes reorg handling from full_scan. The PR also introduces ConfirmationBlockTime as a new anchor type, replacing previous types.

  • ● BIPs #1599 adds BIP46 for a derivation scheme for HD wallets that create timelocked addresses used for fidelity bonds as used for JoinMarket-style coinjoin market matching. Fidelity bonds improve the sybil resistance of the protocol by creating a reputation system where makers prove their intentional sacrifice of the time value of money by timelocking bitcoin.

  • ● BOLTs #1173 makes the channel_update field optional in failure onion messages. Nodes now ignore this field outside the current payment to prevent fingerprinting of HTLC senders. The change aims to discourage payment delays due to outdated channel parameters while still allowing nodes with stale gossip data to benefit from updates when needed.

  • ● BLIPs #25 adds BLIP25 describing how to allow forwarding HTLCs that underpay the encoded onion value. For example, Alice provides a lightning invoice to Bob but she has no payment channels, so when Bob pays, Carol (Alice’s LSP) creates a channel on the fly. To allow Carol to take a fee from Alice to cover the cost of the initial onchain fee that creates a JIT channel, this protocol is used, and Alice is forwarded an HTLC that underpays the encoded onion value. For previous discussion about an implementation of this in LDK, see Newsletter #257.