This week’s newsletter looks at an analysis of how block propagation times may affect miner revenue and describes a new approach for resolving protocols where multiple parties share funds. Also included are our regular sections describing recent changes to services and client software and summarizing recent merges to popular Bitcoin infrastructure software.

News

• ● Modeling stale rates by propagation delay and mining centralization: Antoine Poinsot posted to Delving Bitcoin about modeling stale block rates and how block propagation time affects a miner’s revenue as a function of its hashrate. He set up a base-case scenario in which all miners act realistically (with a default Bitcoin Core node): if they receive a new block, they would immediately start mining on top of it and publish it. This would lead to revenue proportional to their share of the hashrate given propagation time is zero.

  In his model with uniform block propagation, he outlined two situations in which a block goes stale.

  1. Another miner found a block before this miner did. All other miners received the competing miner’s block first and started mining on top of it. Any of these miners can then find a second block based on the received block.

  2. Another miner finds a block after this miner did. It immediately starts mining on top of it. The following block is also found by the same miner.

  Poinsot points out that, between these situations, it is more likely for a block to become stale in the first situation. This suggests that miners may care more about hearing others’ blocks faster than they care about publishing their own. He also suggests that the probability of situation 2 increases significantly with miner centralization. While in both situations the probability increases as miner hashrate increases, Poinsot wanted to compute by how much.

  To do this, he created the following two models.

  Where h is the share of network hashrate, s is the number of seconds the rest of the network found a competing block before it did, H is the set of hashrates on the network representing its distribution.

  Model for situation 1:

  Model for situation 2:

  He went on to show graphs of probabilities that a miner’s block goes stale as a function of propagation times, given the set distribution of hashrate. The graphs show how larger miners gain significantly more the longer the propagation time is.

  For example a mining operation with 5EH/s can expect a revenue of $91M and if blocks took 10 seconds to propogate the revenue would be increased by $100k. Keep in mind that the $91M is revenue and not profit so the increased revenue of $100k would contribute to a larger factor in terms of miner’s net profit.

  Below the charts, he provides the methodology for generating the charts and a link to his simulation which corroborates the results of the model used to generate the graphs.

• ● Private key handover for collaborative closure: ZmnSCPxj posted to Delving Bitcoin about private key handover, an optimization that protocols can implement when funds, previously owned by two parties, need to be refunded to a single entity. This enhancement requires taproot and MuSig2 support to work in the most efficient way.

  An example of such a protocol would be an HTLC, where one party pays the other if the preimage is revealed, creating a refunding transaction that needs to be signed by both parties. Private key handover would allow an entity to simply handover an ephemeral private key to the other after the preimage has been revealed, thus giving the receiver complete and unilateral access to the funds.

  The steps to achieve a private key handover are:

  • When setting up an HTLC, Alice and Bob each exchange an ephemeral and a permanent public key.

  • The keypath spend branch of the HTLC taproot output is computed as the MuSig2 of Alice and Bob’s ephemeral public keys.

  • At the end of the protocol operations, Bob provides the preimage to Alice, who in turn hands him over the ephemeral private key.

  • Bob can now derive the combined private key for the MuSig2 sum, gaining full control over the funds.

  This optimization brings some particular benefits. First of all, in case of a sudden spike in onchain fees, Bob would be able to RBF the transaction without the other party’s collaboration. This feature is particularly useful for protocol developers, since they would not need to implement RBF in a simple proof of concept. Second, the receiver would be able to batch the transaction claiming the funds with any other operation.

  Private key handover is limited to protocols that require the remaining funds to be transferred entirely to a single beneficiary. Thus, splicing or cooperative closure of Lightning channels would not benefit from this.

Changes to services and client software

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

• ● Arkade launches: Arkade is an Ark protocol implementation which also includes multiple programming language SDKs, a wallet, a BTCPayServer plugin, and other features.

• ● Mempool monitoring mobile application: The Mempal Android application provides various metrics and alerts about the Bitcoin network, sourcing data from a self-hosted mempool server.

• ● Web-based policy and miniscript IDE: Miniscript Studio provides an interface for interacting with miniscript and the policy language. A blog post describes the features and the source is available.

• ● Phoenix Wallet adds taproot channels: Phoenix Wallet added support for taproot channels, a migration workflow for existing channels, and multi-wallet features.

• ● Nunchuk 2.0 launches: Nunchuk 2.0 supports wallet configurations using multisig, timelocks, and miniscript. It also includes degrading multisig features.

• ● LN gossip traffic analysis tool announced: Gossip Observer collects Lightning Network gossip messages from multiple nodes and provides summary metrics. The results may inform a minisketch-like set reconciliation protocol for Lightning. A Delving Bitcoin topic includes discussion about the approach.

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 #33745 ensures that blocks submitted by an external StratumV2 client via the new mining inter-process communication (IPC) submitSolution() interface (see Newsletter #325) have their witness commitment revalidated. Previously, Bitcoin Core only checked for this during the original template construction, which allowed a block with an invalid or missing witness commitment to be accepted as the best chain tip.

• ● Core Lightning #8537 sets the maxparts limit (see Newsletter #379) on xpay to six when first trying to pay a non-publicly reachable node using MPP. This conforms to the reception limit of six HTLCs on Phoenix-based nodes for on-the-fly funding (see Newsletter #323), a type of JIT channel. If routing fails under that cap, xpay removes the limit and retries.

• ● Core Lightning #8608 introduces node-level biases to askrene (see Newsletter #316), alongside existing channel biases. A new askrene-bias-node RPC command is added to favor or disfavor all outgoing or incoming channels of a specified node. A timestamp field is added to biases so that they expire after a certain period.

• ● Core Lightning #8646 updates the reconnection logic for spliced channels, aligning it with the proposed specification changes in BOLTs #1160 and BOLTs #1289. Specifically, it enhances the channel_reestablish TLVs so that peers can reliably synchronize splice state and communicate what needs to be retransmitted. This update is a breaking change for spliced channels, so both sides must upgrade simultaneously to avoid disruptions. See Newsletter #374 for a similar change in LDK.

• ● Core Lightning #8569 adds experimental support for JIT channels, as specified by BLIP52 (LSPS2), in the lsp-trusts-client mode and without MPP support. This feature is gated behind the experimental-lsps-client and experimental-lsps2-service options and it represents the first step toward providing full support for JIT channels.

• ● Core Lightning #8558 adds a listnetworkevents RPC command, which displays the history of peer connections, disconnections, failures, and ping latencies. It also introduces an autoclean-networkevents-age config option (default 30 days) to control how long network event logs are kept.

• ● LDK #4126 introduces ReceiveAuthKey-based authentication verification on blinded payment paths, replacing the older per-hop HMAC/nonce scheme (see Newsletter #335). This builds on LDK #3917, which added ReceiveAuthKey for blinded message paths. Reducing the per-hop data shrinks the payload and paves the way for dummy payment hops in a future PR, similar to the dummy message hops (see Newsletter #370).

• ● LDK #4208 updates its weight estimation to consistently assume 72-byte DER-encoded signatures, instead of using 72 in some places and 73 in others. 73-byte signatures are non-standard and LDK never produces them. See Newsletter #379 for a related change in Eclair.

• ● LND #9432 adds a new global upfront-shutdown-address configuration option, which specifies a default Bitcoin address for cooperative channel closures, unless overridden when opening or accepting a specific channel. This builds on the upfront shutdown feature specified in BOLT2. See Newsletter #76 for previous coverage on LND’s implementation.

• ● BOLTs #1284 updates BOLT11 to clarify that when an n field is present in an invoice, the signature must be in normalized lower-S form, and when it is absent, public key recovery may accept either high-S and low-S signatures. See Newsletters #371 and #373 for recent LDK and Eclair changes that implement this behavior.

• ● BOLTs #1044 specifies the optional attributable failures feature, which adds attribution data to failure messages so that hops commit to the messages they send. If a node corrupts a failure message, the sender can identify and penalize the node later. For more details on the mechanism and the LDK and Eclair implementations, see Newsletters #224, #349 and #356.