[bitcoin-dev] We need to fix the block withholding attack
jl2012 at xbt.hk
Sat Dec 19 20:03:28 UTC 2015
After the meeting I find a softfork solution. It is very inefficient and
I am leaving it here just for record.
1. In the first output of the second transaction of a block, mining pool
will commit a random nonce with an OP_RETURN.
2. Mine as normal. When a block is found, the hash is concatenated with
the committed random nonce and hashed.
3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the block
is invalid. That means about 1% of blocks are discarded.
4. For each difficulty retarget, the secondary target is decreased by 2
5. After 546096 blocks or 10 years, the secondary target becomes 2 ^
252. Therefore only 1 in 16 hash returned by hasher is really valid.
This should make the detection of block withholding attack much easier.
All miners have to sacrifice 1% reward for 10 years. Confirmation will
also be 1% slower than it should be.
If a node (full or SPV) is not updated, it becomes more vulnerable as an
attacker could mine a chain much faster without following the new rules.
But this is still a softfork, by definition.
ok, back to topic. Do you mean this?
Peter Todd via bitcoin-dev 於 2015-12-19 13:42 寫到:
> 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,
> 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
> but it itself is still relatively vulnerable to block withholding, and
> in any case has many other vulnerabilities and technical issues that
> 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
> 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/
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
More information about the bitcoin-dev