[bitcoin-dev] Soft fork fix for block withholding attacks

[bitcoin-dev] Soft fork fix for block withholding attacks

[gladoscc]

[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]

Here's a method of fixing block withholding attacks with a soft fork:

We require blocks to choose an arbitrary target, e.g. two bytes. We
redefine the block PoW target to be "less than the difficulty, with the
last two bytes being the target".

We require blocks to include a blinded hash of the target plus some junk
(which blinds it) in the coinbase. The miner cannot arbitrarily switch
targets.

The miner can now send the block header to hashers. Hashers do not know the
target, and hence must submit all shares that matches the first PoW
criteria (below difficulty) and delegate secondary verification to the
miner. With two bytes as the target, there are 65335 false positives for
every valid block.

Finally, we require miners to communicate a proof of their target hash (ie,
the junk they generated) in a non-hashed area of the block. This can be a
protocol extension. The target is already included in the hash as the last
two bytes.

This can be deployed as a soft fork with miner opt in, triggering across
many difficulty cycles. Initially, we soft fork to require the last bit of
the block hash to be zero. The next difficulty cycle, we require the last
two bits to be zero. We do this 16 times to get 2 bytes, and then we
actually activate targets.

By then, nominal difficulty would have been cut by 2^16 (65536), but the
block target makes mining each block 65536 times as hard. We do the
progression over 16 difficulty cycles to minimise increases in block
timings. We can be more specific and progress over even more difficulty
cycles through more clever soft fork rules.

For example, Vitalik detailed "timewalking" attacks that allow effective
granular lowering of the nominal difficulty.

Critique welcome.

[-- Attachment #2: Type: text/html, Size: 1913 bytes --]

Re: [bitcoin-dev] Soft fork fix for block withholding attacks

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

On Fri, Feb 12, 2016 at 10:31:56PM +1100, gladoscc via bitcoin-dev wrote:
> Here's a method of fixing block withholding attacks with a soft fork:

So, while you're technique I believe works, it's not a soft-fork, at
least under the definition most of the Bitcoin dev/research community
have been using.

The reason is if it's adopted by a majority of hashing power, less than
a majority of hashing power can create a chain that appears to be the
most-work chain, from the perspective of non-adopting nodes. Those nodes
would then be following a weaker chain.

A better term for what you're proposing might be a "pseudo-soft-fork",
given that you don't quite meet the requirements for a true soft-fork.
Having said that, it may be the case that overall your technique still
reduces risk compared to a simpler hard-fork implementation of the idea;
more analysis is needed there.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
000000000000000006d243cee301d792809a7d4d00c13ac24b43d5e9548625e4

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] Soft fork fix for block withholding attacks

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

If clients were designed to warn their users when a soft fork happens, then
it could be done reasonably safely.  The reference client does this (or is
it just for high POW softforks?), but many SPV clients don't.

If there was a delay between version number changing and the rule
activation, at least nodes would get a warning recommending that they
update.

* At each difficulty interval, if 950 of the last 1000 blocks have the new
version number, reject the old version blocks from then on.

* Start new target at 255, the least significant byte must be less than or
equal to the target

* Update target at each difficulty re-targetting

T = ((T << 3) - T) >> 3

This increases the difficulty by around 12.5% per fortnight.   After 64
weeks, the target would reach 0 and stay there meaning that the difficulty
would be 256 times higher than what is given in the header.

An attacker with 2% of the network power could create 5 blocks for every
block produced by the rest of the network.

[-- Attachment #2: Type: text/html, Size: 1231 bytes --]