This week’s newsletter summarizes discussion about an anti-exfiltration protocol that only requires one round trip of communication between a wallet and a signing device. Also included are our regular sections describing updates to clients and services, announcing new releases and release candidates, and summarizing recent changes to popular Bitcoin infrastructure software.

News

  • ● Simple (but imperfect) anti-exfiltration protocol: developer Moonsettler posted to Delving Bitcoin to describe an anti-exfiltration protocol. The same protocol has been described before (see Newsletters #87 and #88), with Pieter Wuille citing the earliest known description of the technique for anti-exfil being a 2014 post by Gregory Maxwell.

    The protocol uses the sign-to-contract protocol to allow a software wallet to contribute entropy to the nonce selected by a hardware signing device in a way that allows the software wallet to later verify the entropy was used. Sign-to-contract is a variation on pay-to-contract: in pay-to-contract, the receiver’s public key is tweaked; in sign-to-contract, the spender’s signature nonce is tweaked.

    The advantage of this protocol, compared to the protocol implemented for BitBox02 and Jade hardware signing devices (see Newsletter #136), is that it only requires one round trip of communication between the software wallet and the hardware signing device. That one round trip can be combined with the other steps necessary to sign for a single-sig or scripted multisig transaction, meaning the technique doesn’t affect user workflows. The currently deployed technique, which is also based on sign-to-contract, requires two round trips; that’s more than required for most users today, although multiple round trips may be required for users who upgrade to using scriptless multisignatures and scriptless threshold signatures. For users who connect their signing devices directly to their computers or who use an interactive wireless communication protocol like Bluetooth, the number of round trips doesn’t matter. But, for users who prefer to keep their devices airgapped, each roundtrip requires two manual interventions—which can quickly add up to an annoying amount of work when signing frequently or using multiple devices for scripted multisignatures.

    The disadvantage of this protocol was mentioned by Maxwell in his original description, it “leaves open a side-channel that has exponential cost per additional bit, via grinding […] but it eliminates the obvious and very powerful attacks where everything is leaked in a single signature. This is clearly less good, but it’s only a two-move protocol, so many places that wouldn’t consider using a countermeasure could pick this up for free just as an element of a protocol spec.”

    This protocol is a clear upgrade over not using anti-exfiltration at all and Pieter Wuille notes that it is probably the best possible anti-exfiltration with single-round signing. However, Wuille advocates for the deployed two-round anti-exfiltration protocol to prevent even grinding-based exfiltration.

    Discussion was ongoing at the time of writing.

Changes to services and client software

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

  • ● Proton Wallet announced: Proton announced their open-source Proton Wallet with support for multiple wallets, bech32, batch sending, BIP39 mnemonics, and integration with their email service.

  • ● CPUNet testnet announced: A contributor from the braidpool mining pool project announced test network CPUNet. CPUNet uses a modified proof-of-work algorithm to exclude ASIC miners with the intent of achieving more consistent block rates than is typical of testnet.

  • ● Lightning.Pub launches: Lightning.Pub provides node management features for LND that allow for shared access and coordinating channel liquidity, using nostr for encrypted communications and key-based account identities.

  • ● Taproot Assets v0.4.0-alpha released: The v0.4.0-alpha release supports the Taproot Assets protocol on mainnet for onchain asset issuance and atomic swaps using PSBTs and routing assets through the Lightning Network.

  • ● Stratum v2 benchmarking tool released: The initial 0.1.0 release supports testing, reporting, and comparing the performance of Stratum v1 and Stratum v2 protocols in different mining scenarios.

  • ● STARK verification PoC on signet: StarkWare announced a STARK verifier verifying a zero-knowledge proof on the signet test network using the OP_CAT opcode (see Newsletter #304).

  • ● SeedSigner 0.8.0 released: Bitcoin hardware signing device project SeedSigner added signing features for P2PKH and P2SH multisig, additional PSBT support, and enabled taproot support by default in the 0.8.0 release.

  • ● Floresta 0.6.0 released: In 0.6.0, Floresta adds support for compact block filters, fraud proofs on signet, and florestad, a daemon for integration by existing wallets or client applications.

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

  • ● Bitcoin Core #28553 adds assumeUTXO snapshot parameters for mainnet block 840,000: its block hash, the number of transactions up to that block, and the SHA256 hash of the serialized UTXO set up to that block. This follows tests by multiple contributors that they can reproduce the same snapshot file with the expected SHA256 checksum, and that the snapshot works well when loaded.

  • ● Bitcoin Core #30246 introduces a diff_addrs subcommand to the asmap-tool utility to allow users to compare two maps of Autonomous Systems (ASMaps) and compute statistics on how many node network addresses have been reassigned to a different Autonomous System Number (ASN). This functionality quantifies the degradation of an ASMap over time, which is an important step towards eventually shipping precomputed ASMaps in Bitcoin Core releases, and further increase Bitcoin Core’s resistance to eclipse attacks. See Newsletter #290.

  • ● Bitcoin Core GUI #824 changes the Migrate Wallet menu item from a single action to a menu list, allowing users to migrate any legacy wallet in the wallet directory, including unloadable wallets. This change prepares for a possible future where legacy wallets may no longer be loadable in Bitcoin Core, with descriptor wallets becoming the default. When selecting a wallet to migrate, the GUI will prompt the user to enter the wallet’s passphrase, if it has one.

  • ● Core Lightning #7540 improves the formula that calculates the probability of a successful routing through a channel in the renepay plugin (see Newsletter #263) by adding a constant multiplier that represents the probability that a randomly chosen channel in the network is able to forward at least 1 msat. The default value is set to 0.98, but this may be changed in the future after further testing.

  • ● Core Lightning #7403 adds a channel filtering payment modifier to the renepay plugin which disables channels with a very low max_htlc. This can be extended in the future to filter out channels that are undesirable for other reasons: high base fee, low capacity, and high latency. In addition, a new exclude command line option has been added to manually disable nodes or channels.

  • ● LND #8943 introduces Alloy models to the codebase, starting with an initial Alloy model for the Linear Fee Function fee bumping mechanism, inspired by a bugfix LND #8751. Alloy provides a lightweight formal method for verifying the correctness of system components to make it easier to find bugs during the initial implementation. Rather than trying to prove that a model is always correct, as full-blown formal methods do, Alloy instead operates on an input of a set of bounded parameters and iterations and tries to find counterexamples to a given assertion, accompanied by a nice visualizer. Models can also be used to specify protocols in P2P systems, so it’s particularly well suited to the Lightning Network.

  • ● BDK #1478 makes several changes to the FullScanRequest and SyncRequest request structures of the bdk_chain crate: use a builder pattern that separates request construction and consumption, make the chain_tip parameter optional to allow users to opt out of LocalChain updates (useful for those using bdk_esplora without a LocalChain), and improve the ergonomics of checking synchronization progress. In addition, the bdk_esplora crate is optimized by always adding previous transaction outputs to the TxGraph update and reducing the number of API calls by using the /tx/:txid endpoint.

  • ● BDK #1533 enables support for single descriptor wallets by adding the Wallet::create_single method, reverting a previous update that had made the Wallet structure require an internal (change) descriptor. The reason for the previous change was to protect the privacy of users’ change addresses when relying on public Electrum or Esplora servers, but this is being reverted to be inclusive of all use cases.

  • ● BOLTs #1182 improves the clarity and completeness of the route blinding and onion messages sections of the BOLT4 specification with the following changes: moves the route blinding section up one level to emphasize its applicability to payments (and not just onion messages), provides more concrete details on the blinded_path type and its requirements, expands the description of the writer’s responsibilities, splits the reader section into separate parts for the blinded_path and encrypted_recipient_data, improves the explanation of the blinded_path concept, adds a recommendation to use a dummy hop, renames onionmsg_hop to blinded_path_hop, and makes other clarifying changes.

  • ● BLIPs #39 adds BLIP39 for an optional field b in BOLT11 invoices to communicate a blinded path for paying the receiver’s node. This is implemented in LND (see Newsletter #315) and is intended to be used until the offers protocol is widely deployed in the network.