Bitcoin Optech Newsletter #110

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.


  • 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
    but also sparked a second
    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

by Gustavo Flores Echaiz, Product Manager at Veriphi

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.

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
  • 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.

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
    (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
, 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.

—Source link—

What do you think?

How to maximize yield farms with Instadapp Bankless

Introducing Yam Finance: Yield Farmers Paradise