This week’s newsletter describes a proposal for Bitcoin-related MIME types and summarizes a paper about a design for a new decentralized mining pool. Also included are our regular sections with the summary of a Bitcoin Core PR Review Club meeting, how to prepare for taproot, new releases and release candidates, and notable changes to popular Bitcoin infrastructure projects.

News

  • ● Braidpool, a P2Pool alternative: P2Pool is a system used for decentralized pool-based Bitcoin mining since 2011. A new paper that was posted to the Bitcoin-Dev mailing list describes several perceived flaws and an alternative decentralized pool design with two notable improvements: a more efficient use of block space for payouts by using payment channels with minimal trust in a third party, and more tolerance for higher latency connections between pool members.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Use legacy relaying to download blocks in blocks-only mode is a PR by Niklas Gögge to make nodes setting the -blocksonly configuration option always use legacy block relay for downloading blocks. The review club compared legacy block download with BIP152-style compact block download and discussed why blocksonly nodes don’t benefit from the latter.

  • What sequence of messages is used in legacy block relaying?

    Nodes running v0.10 and newer use headers-first synchronization: a node first receives a headers message from its peer containing the block header. After validating the header, it then requests the full block by sending a getdata(MSG_BLOCK, blockhash) message to the peer that announced it, and the peer responds with a block message containing the full block. ➚

  • What sequence of messages is used in BIP152 low bandwidth compact block relaying?

    Peers indicate that they want to use compact block relay by sending sendcmpct at the start of the connection. Low bandwidth compact block relay is very similar to legacy block relay: after processing a block header, the node requests a compact block from its peer using getdata(MSG_CMPCT_BLOCK, blockhash), and receives a cmpctblock in response. The node can use the compact block shortids to look for the block transactions in its mempool and cache of extra transactions. If any transactions are still unknown, it can request them from a peer using getblocktxn and receive blocktxn messages in response. ➚

  • What sequence of messages is used in BIP152 high bandwidth compact block relaying?

    A node can request high bandwidth compact blocks from a peer when first establishing the connection by sending sendcmpct with hb_mode set to 1 at the start of the connection. This means the peer can send a cmpctblock immediately, without sending headers first or waiting for a getdata request for the block. If needed, the node can request and download any unknown block transactions using getblocktxn and blocktxn, identically to low bandwidth compact block relay. ➚

  • Why does compact block relay waste bandwidth for blocksonly nodes during block download? How much bandwidth is wasted?

    Compact block relay reduces bandwidth usage for nodes that have a mempool because they don’t need to re-download the majority of block transactions. However, nodes in blocksonly mode don’t participate in transaction relay and typically have empty mempools, which means they need to download all of the transactions anyway. The shortids, getblocktxn and blocktxn overhead add up to approximately 38kB per block of wasted bandwidth, and the extra round trip for getblocktxn and blocktxn messages also increases the time it takes to download the block. ➚

  • Does a node in blocksonly mode keep a mempool?

    While blocksonly nodes don’t participate in transaction relay, they still have a mempool and it may contain transactions for a few different reasons. For example, if the node was in normal mode, then restarted in blocksonly mode, the mempool is persisted across the restart. Also, any transactions submitted through the wallet and client interfaces are validated and relayed using the mempool. ➚

  • What is the difference between blocksonly and block-relay-only? Should these changes be applied for block-relay-only connections as well?

    Blocksonly mode is a node setting, while block-relay-only is an attribute of a peer connection. When a node is started in blocksonly mode, the node sends fRelay=false in the version handshake with all peers and disconnects peers that send any transaction-related messages. Whether or not in blocksonly mode, a node may have block-relay-only connections on which they ignore incoming transaction and addr messages. As such, the existence of block-relay-only connections has no relation to a node’s mempool contents and ability to reconstruct blocks from compact block messages, so these changes shouldn’t be applied to block-relay-only connections. ➚

Preparing for taproot #12: Vaults with taproot

A weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.

By Antoine Poinsot, Revault developer

Bitcoin vaults are a type of contract that require two sequential transactions for a user to spend money from their wallet. Numerous such protocols have been proposed (single or multi-party, with or without covenants) so we’ll focus on what they have in common.

Contrary to batched payments that execute multiple payments with a single onchain transaction, vaults use multiple transactions to execute a single payment. The first transaction, the unvault, pays to either:

  1. a set of pubkeys after a relative timelock, or
  2. a single pubkey without any timelocks.

The first spending path is the mainline case, expected to be used with “hotter” key(s). The second spending path allows for a cancel transaction (sometimes called the clawback, recovery or re-vaulting transaction).

As such, Bitcoin vaults are contrary to the insight of taproot that most contracts have a happy path where all participants collaborate with a signature (and the dispute path usually contains timelocks). Rather the opposite. The spend transaction must use the taproot script sending path, since it is encumbered by the relative timelock1 while the cancel transaction could in theory use the key spending path.

Since multi-party vaults already require a lot of interactivity in practice, they could theoretically benefit from interactive multisignature and threshold signature schemes made possible by BIP340, such as Musig2. However, these schemes come with new safety challenges. Since vault protocols are intended to be used for cold storage, the design choices are more conservative and vaults would probably be the last to use these new technologies.

By switching to taproot, vaults would also benefit from a slight privacy and efficiency improvement due to the use of merkle branches and shorter BIP340 signatures (especially for multi-party ones). For instance, the unvault output script in a multi-party setup with 6 “cold” keys and 3 “active” keys (with a threshold of 2) could be represented as a Taproot of depth 2 with leaves:

  • <X> CSV DROP <active key 1> CHECKSIG <active key 2> CHECKSIGADD 2 EQUAL
  • <X> CSV DROP <active key 2> CHECKSIG <active key 3> CHECKSIGADD 2 EQUAL
  • <X> CSV DROP <active key 3> CHECKSIG <active key 1> CHECKSIGADD 2 EQUAL
  • <cold key 1> CHECKSIG <cold key 2> CHECKSIGADD <cold key 3> CHECKSIGADD <cold key 4> CHECKSIGADD <cold key 5> CHECKSIGADD <cold key 6> CHECKSIGADD 6 EQUAL

In taproot, only the leaf being used to spend the output needs to be revealed, so the transaction weight is considerably smaller than for the equivalent P2WSH script:

IF
  6 <cold key 1> <cold key 2> <cold key 3> <cold key 4> <cold key 5> <cold key 6> 6 CHECKMULTISIG
ELSE
  <X> CSV DROP
  2 <active key 1> <active key 2> <active key 3> 3 CHECKMULTISIG
ENDIF

Although the revocation branch can be hidden in case of a successful spending (and if using a multisig threshold, its existence and the number of participants obfuscated), the privacy gains are minimal as the vault usage pattern would be trivially identifiable onchain.

Finally, vault protocols, like most pre-signed transactions protocols, would largely benefit from further proposed Bitcoin upgrades based on taproot such as BIP118’s SIGHASH_ANYPREVOUT. Although requiring further caution and protocol tweaks, ANYPREVOUT and ANYPREVOUTANYSCRIPT would enable rebindable cancel signatures, which could largely reduce interactivity and allow 0(1) signature storage. This is particularly interesting for the emergency signature in the Revault protocol, as it would largely reduce the DoS attack surface. By having an ANYPREVOUTANYSCRIPT signature in an output, you are effectively creating a covenant by restricting how the transaction spending this coin can create its outputs. Even more customizable future signature hashes would permit more flexible restrictions.

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.

  • ● Bitcoin Core 22.0rc3 is a release candidate for the next major version of this full node implementation and its associated wallet and other software. Major changes in this new version include support for I2P connections, removal of support for version 2 Tor connections, and enhanced support for hardware wallets.

  • ● Bitcoin Core 0.21.2rc2 is a release candidate for a maintenance version of Bitcoin Core. It contains several bug fixes and small improvements.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • ● Bitcoin Core #22009 updates the wallet to always run both the Branch and Bound (BnB) and knapsack algorithms for coin selection, and then choose the best result using a new waste score heuristic to compare the cost effectiveness of the results. Previously, the changeless BnB result was always preferred if one was found.

    The waste score heuristic assumes that every input must eventually be spent at a feerate of 10 sat/vB, and that change outputs are avoidable. Inputs are scored as the difference between their cost at the current feerate and the baseline feerate, resulting in a waste score deduction for spending inputs at lower feerates and a waste score increase at higher feerates. Change outputs always increase the waste score by the cost of the change output creation as well as the future cost of spending the change output.

    In a wallet spending at various feerates, this approach will shift some input consumption to lower feerates, reducing the overall wallet operation cost. The baseline feerate separating consolidatory and thrifty coin selection behavior can be configured with the new option -consolidatefeerate. The subsequent PR Bitcoin Core #17526 proposes to add a third coin selection algorithm based on a Single Random Draw.

  • ● Eclair #1907 updates how it uses block chain watchdogs to prevent eclipse attacks (see Newsletter #123). When Tor is available, Eclair now uses it to contact the watchdogs (using native onion endpoints when possible). This should make it more difficult for an upstream attacker to selectively censor just the watchdog providers.

  • ● Eclair #1910 updates how it uses Bitcoin Core’s ZMQ messaging interface to improve the reliability of learning about new blocks. Anyone else using ZMQ for block discovery may wish to investigate the changes.

  • ● BIPs #1143 introduces BIPs 380-386 specifying output script descriptors. Output script descriptors are a simple language that contains all the information necessary to allow a wallet or other program to track payments made to or spent from a particular script or set of related scripts. BIP380 describes the philosophy, general structure, shared expressions, and checksum. The rest of the BIPs specify each descriptor function itself, categorized by: non-segwit (BIP381), segwit (BIP382), multisig (BIP383), combination output (BIP384), raw script and address (BIP385), and tree (BIP386) descriptors.

  • ● BOLTs #847 allows two channel peers to negotiate what fee should be paid in a mutual close transaction. Previously, only a single fee was sent, and the other party had to either accept or reject that precise fee. [Edit: see next week’s newsletter for a more accurate description.]

  • ● BOLTs #880 adds a channel_type field to the openchannel and acceptchannel messages, allowing the sending node to explicitly request channel features different from ones implied by the nodes’ advertised feature bits. This backwards compatible change has been implemented in Eclair #1867, LND #5669, and is pending merge as part of C-Lightning #4616.

  • ● BOLTs #824 adds a slight variation on the anchor outputs channel state commitment protocol. In the earlier protocol, presigned spends of HTLCs could include fees, but this opened the fee-stealing attack vector described in Newsletter #115. In this alternative protocol, all presigned HTLC spends use zero fee, so no fees can be stolen.

Footnotes

  1. If known in advance you could pre-sign the spend transaction with a specific nSequence, but then you don’t need an alternative spending path with “active” keys at all. Also, you don’t usually know how you are going to spend your coins at the time you receive them. ↩