This week’s newsletter summarizes a discussion about submitting transactions directly to miners, links to a set of recommended taproot test vectors for wallet implementations, and includes our regular sections about preparing for taproot, new releases and release candidates, and notable changes to popular Bitcoin infrastructure projects.

News

  • ● Submitting transactions directly to miners: Lisa Neigut started a thread on the Bitcoin-Dev mailing list about the possibility of eliminating the P2P transaction relay network and having users submit transactions to miners directly. Proposed benefits of this operating mode included reducing bandwidth requirements, improved privacy, and elimination of the complexity in RBF and CPFP package rules, and better communication about next-block feerates. However, several people disagreed:

    • ● Bandwidth requirements: several responses noted that compact block relay, used since 2016, allows a node that received an unconfirmed transaction to skip receiving it again when it’s included in a block, with minimal bandwidth overhead. Future proposed improvements such as erlay will further minimize the bandwidth overhead from unconfirmed transaction relay.

    • ● Improved privacy: although submitting transactions only to miners hides those transactions from public view prior to confirmation, Pieter Wuille argued that it also gives miners a privileged view of the network. Public transparency seems preferable.

    • ● RBF, CPFP, and package complexity: node operators are indeed more sensitive to resource-wasting attacks than miners, but Gloria Zhao noted that this is mainly a matter of degree. The same attacks executed at a larger scale would affect miners, and so miners still need the same types of defenses that nodes already employ.

    • ● Feerate communication: the current method Bitcoin Core uses for estimating feerates is based on receiving unconfirmed transactions and then seeing how long it takes them to appear in confirmed blocks. This does lag behind real-time feerate information, but Pieter Wuille suggests that could be improved by using other previously-proposed methods such as having miners broadcast weak blocks—blocks that don’t quite have enough proof of work to be added to the chain. Weak blocks occur more often than PoW-valid blocks and so provide more recent information about what transactions miners are currently working on.

    In addition to direct counterpoints, several advantages of the current system were noted:

    • ● Miner anonymity: with 50,000 or more nodes currently all relaying transactions, it’s easy for miners to receive all the information they need by quietly operating one of those nodes. Pseudonymous developer ZmnSCPxj suggested that forcing miners to maintain a persistent identity, even one on an anonymity network like Tor, would make it easier to identify miners and coerce them into censoring some transactions.

    • ● Censorship resistance: anyone today can start a node using basically any computer to receive relayed transactions, connect mining equipment, and begin mining. Pieter Wuille notes that wouldn’t be the case with direct miner submission. New miners would need to advertise their nodes in order to receive transactions, but there’s no highly accessible way to do that which is resistant to both censorship and sybil attacks. In particular, Wuille notes “ideas for a mechanism for miners to publish their [submission URL] on chain don’t help; that [would be] dependent on other miners to not censor the publishing.”

    • ● Centralization resistance: Wuille also notes that “the cost and complexity of an additional submission is independent of [each miner’s] hashrate, but the benefit is directly proportional [to hashrate”. That would make it “far easier for most wallets to just submit [transactions] to the largest few pools”, encouraging centralization.

  • ● Taproot test vectors: Pieter Wuille posted to the Bitcoin-Dev mailing list a set of test vectors he’s proposing to add the BIP341 specification of taproot. They focus on “wallet implementations, covering Merkle root / tweak / scriptPubKey computation from key/scripts, sigmsg/sighash/signature computation for key path spending, and control block computation for script path spending.”

    The test vectors should be especially useful to developers working on implementations which want to be ready to use taproot shortly after activation.

Preparing for taproot #20: what happens at activation?

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

Less than two weeks after the publication of this post, taproot is expected to activate at block 709,632. We know what we expect to happen, and we also know about a few possible failure modes.

The best and most likely outcome is that everything goes fine. Nothing that happens should be visible to normal users. Only those carefully monitoring their nodes or trying to create taproot transactions should notice anything. At block 709,631 nearly all full nodes we’re aware of will be enforcing the same consensus rules. One block later, nodes running Bitcoin Core 0.21.1, 22.0, or related releases will be enforcing the additional taproot rules not enforced by earlier software releases.

This carries a risk that earlier and later versions of node software will accept different blocks. This happened during the activation of the BIP66 soft fork in 2015, resulting in a six-block chain split and several shorter chain splits. Significant engineering effort has been invested in preventing a repeat of that problem. A similar problem should only happen with taproot if a miner either deliberately mines a taproot-invalid block or has disabled safety measures hardcoded into Bitcoin Core and related node software.

Specifically, to create a chain split, a miner would need to create or accept a transaction that spends from a taproot output (segwit v1 output) without following taproot’s rules. If a miner did that, they would lose at least 6.25 BTC (about $400,000 USD at the time of writing) if the economic consensus of Bitcoin node operators rejects the taproot-invalid blocks.

We can’t know for sure without creating an invalid block what those node operators will do—nodes can be run entirely privately—but proxy measures indicate that perhaps more than 50% of node operators are running taproot-enforcing versions of Bitcoin Core. That’s probably more than sufficient to ensure any miner who creates a taproot-invalid block will see it rejected by the network.

Although very unlikely, a temporary chain split is theoretically possible. It should be possible to monitor for it using services such as ForkMonitor.info or using the getchaintips RPC in Bitcoin Core. If it does happen, lightweight clients may receive false confirmations. Although it is theoretically possible to get 6 confirmations, like in the 2015 chain split, that would imply miners had lost almost $2.5 million in value (compared to losses of about $50,000 in 2015). We can hope with values that large at stake, miners will actually enforce the taproot rules they signaled preparedness for six months ago.

In almost any failure circumstance we can imagine, a simple but effective temporary response is to raise your confirmation limit. If you normally wait for 6 confirmations before accepting a payment, you can quickly raise that 30 confirmations for a few hours until the problem has been resolved or it becomes clear that an even higher confirmation limit is required.

For users and services that are convinced the economic consensus of full node operators will enforce taproot’s rules, an even simpler solution is to only get information about which transactions are confirmed from Bitcoin Core 0.21.1 or later (or a compatible alternative node implementation).

Optech expects taproot activation to proceed smoothly, but we do encourage exchanges and anyone accepting large values around block 709,632 to either upgrade their node or be prepared to temporarily raise their confirmation limit if there are any indications of problems.

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 changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • ● Bitcoin Core #23306 enables the Address Manager to support multiple ports per IP address. Historically, Bitcoin Core has used a fixed port, 8333, and strongly preferred addresses with this port when making automatic outbound connections. While it has been suggested that this behavior may help prevent utilization of the Bitcoin nodes to DoS non-Bitcoin services (by gossipping their addresses on the Bitcoin network), it also makes it easy to detect Bitcoin nodes by observing network traffic. Treating each (IP,port) combination as a distinct address allows for future work moving towards a more uniform treatment of addresses.

  • ● C-Lightning #4837 adds a --max-dust-htlc-exposure-msat configuration option limiting the total balance of pending HTLCs whose amounts are below the dust limit. Please see our previous coverage of a similar option in Rust-Lightning for more details.

  • ● Eclair #1982 introduces a new log file collecting important notifications that require the node operator to take action. The accompanying release notes indicate that the notifications.log should be monitored by the node operator.

  • ● LND #5803 allows multiple spontaneous payments to the same Atomic Multipath Payment (AMP) invoice without requiring the spending user perform extra steps for repeat payments. The ability to receive multiple payments to the same invoice is a feature of AMP that’s not possible with existing simplified multipath payment implementations.

  • ● BTCPay Server #2897 adds support for LNURL-Pay as a payment method, also enabling support for Lightning Addresses.