This week’s newsletter summarizes a discussion about SIGHASH_ANYPREVOUT and eltoo, includes a field report showing how 57,000 BTC could have been saved in transaction fees using segwit and batching, and provides our regular sections with the summary of a Bitcoin Core PR Review Club meeting, releases and release candidates, and notable changes to popular Bitcoin infrastructure projects.

Action items

None this week.

News

• ● Discussion about eltoo and SIGHASH_ANYPREVOUT: Richard Myers resumed a discussion about SIGHASH_ANYPREVOUT and provided a nice diagram of how its two signature hash (sighash) types would be used within eltoo. He also asked several questions about minimizing the number of network round trips needed to create eltoo state updates. These questions received answers from ZmnSCPxj but also sparked a second discussion about attacks against LN payment atomicity within the context of eltoo.

  The advantage of eltoo over the currently used LN-penalty mechanism is that the publication of old eltoo channel states onchain doesn’t prevent the publication of the ultimate channel state. This is achieved in eltoo by creating signatures using SIGHASH_ANYPREVOUT so that the signature from the ultimate state can spend bitcoins from either the initial state, the penultimate state, or any state in between. However, transactions still need to identify which state (previous output) they are attempting to spend.

  One problem with the eltoo mechanism is that both an attacker and an honest user could both try spending from the same previous state. Miners and relay nodes would only keep one of those transactions in their mempool, and there may be ways the attacker could ensure the version of the transaction everyone kept was an old state. Another problem is that the attacker could possibly trick the honest user into spending from a state that relay nodes hadn’t seen and so relay nodes would possibly reject the unconfirmed transaction because its parent transaction was not available. Although neither of these problems would prevent the ultimate state from eventually being confirmed onchain, they could be used for transaction pinning to prevent one of the honest user’s time-sensitive transactions from confirming in time. These problems are similar to the attack against LN payment atomicity described in Newsletter #95. One proposed mitigation would be to have special nodes (perhaps part of LN routing software) that looked for cases where eltoo was being used and could use their knowledge of that protocol to tell miners which transaction would truly be most profitable to mine.

Field report: How segwit and batching could have saved half a billion dollars in fees

Fee optimization is possible through diverse techniques varying from segregated witness, transaction batching, RBF (Replace By Fee) and fee estimation. Calculating exact transaction fee savings from the last two techniques, RBF and fee estimation, is quite difficult—but segwit and batching gains can be modelled to hypothetical scenarios since their improvements are measurable.

In our report, we wanted to model what full adoption of native segwit (P2WPKH or P2WSH) and transaction batching would look like for the network compared to the partial adoption that we currently see. We wanted to determine the transaction fees that could be saved, how that has changed over time and how it impacts block space and block weight.

Our modelling for transaction batching is based on David A. Harding’s formula for detecting whether a transaction spends coins it received in the same block. If so, those transactions can hypothetically be batched and the transaction weight reduced. After batching all potentially batchable transactions, we combine the size of the hypothetical block and compare it to the real block size. From there, we can calculate the bytes that were saved and the percentage this saving represents. Finally, if we take the size of each block and remove the size of the block header and the miner’s coinbase transaction, we can divide the saved size by this new amount. The percentage we get is an approximation of the fees that would’ve been paid in the case of full adoption. Our code for analysing the data and calculating the potential savings is here.

For segwit, we analysed from block 481,825, which happened on the 24th of August 2017, the day of segwit activation, until block 637,090 on the 30th of June 2020. Our method goes through every input of every transaction and if the input isn’t native segwit, it calculates the weight it would save if it were native segwit, which can then indicate to us the amount of fees it could save. Finally, we collect the block weight and block fee of each block in reality and also collect the potential block weight and potential block fee of our model by summing up the results of each transaction. You can find the repository of our code used here.

Major takeaways

Assuming a bitcoin price of $9,250 (correct at the time the report was published):

• From January 2012 to June 2020 (until block 637,090) 211 thousand BTC were paid in fees to miners. This amounts to a total of around $2 billion USD.
• Total savings during that period amounted to almost 58 thousand BTC representing an amount of about $530 million USD. This represents a percentage of around 27.36% over the grand total of transaction fees paid.
• Over 21 thousand BTC could have been saved by Bitcoin users if they would have all been using transaction batching, a savings of 10% or almost $200 million USD.
• From 24 August 2017 to 30 June 2020, about 37 thousand BTC could have been saved by Bitcoin users if they would have all been using segwit native (bech32), down from over 97 thousand BTC actually paid in fees, which is 38% in savings or about $340 million USD.
• The advantages brought through optimized fee management techniques such as segwit and batching are most impressive and apparent during high transactional activity periods. A large percentage of the possible savings would have been achieved in only a few key months over the span of 8 years and 6 months analysed.

Read our full report here to understand the progression of fee savings over time.

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.

Implement ADDRv2 support (part of BIP155) is a PR (#19031) by Vasil Dimov that proposes an implementation of the BIP155 addrv2 P2P message.

The discussion covered the current addr message in Bitcoin Core, the BIP155 addrv2 message, how to signal support for addrv2 on the P2P network, and the necessity of addrv2 for the Bitcoin network to upgrade to Tor v3. Tor v2 deprecation begins mid-September!

• How does Bitcoin Core handle network addresses?

  Bitcoin Core currently sees all peer addresses as being more or less in a single IPv6-like space. IPv4 and Tor v2 addresses are serialized into 16 bytes encoded as “fake” IPv6 addresses from specific IPv6 networks reserved for them. For instance, Tor v2 addresses are persisted using the “onioncat” IPv6 range. The 16-byte maximum length of IPv6 increasingly limits which endpoints Bitcoin nodes can connect to. ➚

• How are peer addresses stored?

  Addresses are saved in the peers.dat file in a 16-byte format, which corresponds to the length of IPv6 addresses; the smaller-sized IPv4 and Tor v2 addresses are therefore padded to fit. This file can be updated to handle larger addresses with backward compatibility maintained for older versions. ➚

• What is BIP155 and the addrv2 message?

  BIP155 addrv2 is a new P2P message format proposed in early 2019 by Wladimir J. van der Laan to gossip variable-length node addresses larger than 16 bytes, and up to 512 bytes for future extensibility, with separate address spaces for separate networks. addrv2 would enable Bitcoin core to use next-generation Onion Services (Tor v3) and the I2P (Invisible Internet Project), as well as other networks with longer endpoint addresses that don’t fit in the 16 bytes/128 bits of Bitcoin’s current addr message. 

• How is addrv2 support expected to be signaled?

  Most likely with a sendaddrv2 message between peers at handshake or afterwards, rather than with the originally proposed protocol version bump or with a new network service bit. ➚

• Why is Tor v3 important for Bitcoin?

  Tor v2 is planned to be deprecated on Sept 15, 2020 and obsolete on July 15, 2021 (schedule). Tor v3 provides much better security and privacy, since it uses longer, 56-character addresses. Using Tor v3 on the Bitcoin network therefore requires implementation of BIP155 addrv2. ➚

• Will we need another upgrade, aka addrv3, in the near future?

  Not for some time. The only addrv2 constraint is that addresses be stored in not more than 512 bytes. Any future format within that size, including variable-length route descriptions, should be supported. ➚

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.

• ● LND 0.11.0-beta.rc2 is a release candidate for the next major version of this project. It allows accepting large channels (by default, this is off) and contains numerous improvements to its backend features that may be of interest to advanced users (see the release notes).

Notable code and documentation changes

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

• ● Bitcoin Core #18991 changes the way that Bitcoin Core responds to getaddr requests from its peers. Bitcoin nodes learn about potential new peers they can connect to in two different ways. Firstly, each node periodically announces its own network address to its peers. Those peers re-announce the address to some of their own peers, who re-announce to their peers, and so on, propagating the address around the network. Secondly, a node can explicitly request addresses from a peer using a getaddr message. To prevent a peer from learning about all of the addresses in its address manager, Bitcoin Core only provides a subset of those addresses when a peer sends it a getaddr message, and only responds to a single getaddr message from each peer. However, an adversary may still be able to learn all the addresses a peer knows by making multiple connections to that peer and sending getaddr messages on each connection. The adversary could potentially use that information to fingerprint the peer or infer network topology. To prevent that, this PR changes Bitcoin Core’s behavior to cache responses to getaddr requests and provide the same response to all peers who request addresses in a 24-hour rolling window.

• ● Bitcoin Core #19620 prevents Bitcoin Core from re-downloading unconfirmed segwit transactions that attempt to spend non-standard UTXOs. A non-standard UTXO is one that uses a currently discouraged feature, such as using v1 segwit outputs before those have been enabled on the network by a soft fork like taproot. This helps address a concern described in Newsletter #108 about a potential taproot activation: nodes that don’t upgrade for the soft fork won’t accept unconfirmed taproot transactions, so they might end up downloading and rejecting the same unconfirmed taproot transactions over and over again. That won’t happen to any node running this patch, allowing backports of this patch to serve as an alternative to backporting the wtxid relay feature, which would also prevent that wasted bandwidth.

• ● C-Lightning #3909 updates the listpays RPC to now return a new created_at field with a time stamp indicating when the first part of the payment was created.

• ● Eclair #1499 adds new signmessage and verifymessage commands to sign messages using your LN node’s public key and verify messages using known node pubkeys respectively. These new commands are tested to be compatible with existing message signing and verification commands found in LND and C-Lightning, differing only in that Eclair’s signatures are encoded in hex rather than zbase32.