The dangerously shifted incentives of SegWit

Although I have been generally enthusiastic about the SegWit2X compromise, Peter Rizun has pointed out a flaw in SegWit (earlier discussed by Peter Todd) that makes it unacceptably dangerous. As I fear the extent of the problem is not yet completely understood by the community, allow me to explain from a different angle.

Why do miners verify signatures?

Miners verify signatures to remove the risk of building their block on top of an invalid block.

We must realize that this risk is incredibly small. Creating an invalid block is a waste of money, so invalid blocks are generally rare. Order of magnitude, 0.001%.

Fortunately for Bitcoin, the cost of verifying signatures is also incredibly small. With libsecp256k, this takes only a few microseconds per signature on modern hardware.

The reason that the cost of verifying signatures is so small, is that they need to download them anyway. This is because before they have downloaded all signatures, they have no way to verify which transactions were included, and therefore cannot know which transactions they can safely include in the next block. They can only mine an empty block without fees.

The effect of this can be seen in the optimal mining strategy called header-first mining, or SPY mining. Miners mine an empty block whenever a header comes in (via stratum polling), and only start including transactions from the mempool when every byte of the block is downloaded.

What does SegWit change?

With SegWit transactions, the signatures are committed indirectly via the coinbase. This means that miners do not need to download the signatures in order to verify which transactions are included in the block.

This changes the balance of the incentive to verify signatures:

It should be clarified that this picture is not accurate. We can not so easily quantify costs and risks, and there is no reason to assume that SegWit directly causes a flippening of the balance for every miner. In fact there are several softening factors to consider

  • The cost of mining on an invalid block is not just the direct cost in loss of rewards, but also the indirect cost in damaging bitcoin and the miner's investment.
  • Signatures are still needed for mempool transactions, so the gains from not downloading signatures is limited to the set of transactions disjoint from the mempool.
  • For many cases, total bandwidth is less limited than peak bandwidth; miners could employ a 3-stage strategy where they start empty (header-first), then when the transactions are in, start collecting the fees, and then continue to download the signatures in the background.

Nevertheless, the incentives are undeniably shifted, and worse, they can be expected to shift more in time.

This is because the cost of downloading signatures increases as blocks grow bigger, while the risk of an invalid block decreases as the price increases.

Why is this dangerous?

Let us say that somewhere in the future the "flippening" occurs for some N>0 percent of the miners: They benefit from not downloading the signatues.

This result will be that SegWit transactions will be less secure than non-SegWit transactions. A non-SegWit transaction is secure under the assumption that no attacker controls 51% of the mining power, whereas a SegWit transaction is secure under the assumption that no attacker controls (51-N)% of the mining power.

So if the flippening occurs for the 20% smallest (e.g. most bandwidth restricted) miners, a 31% miner could start stealing SegWit transactions!

The problem is much bigger than the attack itself. We cannot easily estimate N, so even before N grows too big and an attack occurs, we can expect that the safety of a transaction spending a SegWit output will be estimated less than the safety of spending a non-SegWit output, and therefore will be less valuable. Even if only a few businesses were to stop accepting SegWit transactions for this reason, this would destroy one of Bitcoin's most important properties: fungibility.

We cannot mess with the delicate incentive structures that hold Bitcoin together.

What about fixing malleability?

The flaw is not caused by fixing malleability.

It is not caused by fixing malleability as a softfork.

it is not caused by using the anyone-can-spend standard update mechanism.

For example, Christian Decker's BIP 140 softfork malleability fix does not have the same flaw, and neither does a simple hardfork malleability fix

It is a simple yet disastrous side effect caused by SegWit fixing malleability in an incorrect manner.

It is entirely avoidable.

2017-07-03 Tomas van der Wansem