Subject: [bitcoin-dev] We need to fix the block withholding attack

From: Peter Todd <[email-masked]>
Date: Sat, 19 Dec 2015 10:42:40 -0800

At the recent Scaling Bitcoin conference in Hong Kong we had a chatham
house rules workshop session attending by representitives of a super
majority of the Bitcoin hashing power.

One of the issues raised by the pools present was block withholding
attacks, which they said are a real issue for them. In particular, pools
are receiving legitimate threats by bad actors threatening to use block
withholding attacks against them. Pools offering their services to the
general public without anti-privacy Know-Your-Customer have little
defense against such attacks, which in turn is a threat to the
decentralization of hashing power: without pools only fairly large
hashing power installations are profitable as variance is a very real
business expense. P2Pool is often brought up as a replacement for pools,
but it itself is still relatively vulnerable to block withholding, and
in any case has many other vulnerabilities and technical issues that has
prevented widespread adoption of P2Pool.

Fixing block withholding is relatively simple, but (so far) requires a
SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should
do this hard-fork in conjunction with any blocksize increase, which will
have the desirable side effect of clearly show consent by the entire
ecosystem, SPV clients included.

Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block
witholding attacks are a good thing, as in their model they can be used
by small pools against larger pools, disincentivising large pools.
However this argument is academic and not applicable to the real world,
as a much simpler defense against block withholding attacks is to use
anti-privacy KYC and the legal system combined with the variety of
withholding detection mechanisms only practical for large pools.
Equally, large hashing power installations - a dangerous thing for
decentralization - have no block withholding attack vulnerabilities.

1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/

-- 
'peter'[:-1]@petertodd.org
00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d