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.
None this week.
● 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_ANYPREVOUTso 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
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.
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
- 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
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.
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
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.datfile 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
addrv2is 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.
addrv2would 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
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
Will we need another upgrade, aka
addrv3, in the near future?
Not for some time. The only
addrv2constraint 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
- ● 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
● Bitcoin Core #18991 changes the way that Bitcoin Core responds to
getaddrrequests 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
getaddrmessage. 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
message, and only responds to a single
getaddrmessage 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
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
provide the same response to all peers who request addresses in a 24-hour
● 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.
● Eclair #1499 adds new
verifymessagecommands 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.