[Cryptography] Yet another way to create Blockchain misery

[Christian Huitema]

On 1/5/2022 9:59 AM, Phillip Hallam-Baker wrote:

> Any party that has a majority of the active mining capacity can play a
> range of games to maintain their control. They can mine a hundred blocks
> ahead and only release blocks to trump claims by rival miners. If your
> objective is to stall the chain, the optimum strategy is to wait until a
> rival faction has made a claim and then release as many blocks as you need
> from your stash to erase them. You time the release of blocks so as to
> manipulate the work factor in your favor so that the only way a rival can
> seize control is to also mine multiple blocks ahead and stash them. But you
> join the other mining co-ops...

OK, so I see what the bitcoin documentation says  about the "target": 
"For reasons of stability and low latency in transactions, the network 
tries to produce one block every 10 minutes. Every 2016 blocks (which 
should take two weeks if this goal is kept perfectly), every Bitcoin 
client compares the actual time it took to generate these blocks with 
the two week goal and modifies the target by the percentage difference. 
This makes the proof-of-work problem more or less difficult. A single 
retarget never changes the target by more than a factor of 4 either way 
to prevent large changes in difficulty."

The attack that you describe requires playing with that algorithm, for 
example storing a large number of hashes and releasing them at once, so 
the Bitcoin clients would be induced to increase the difficulty. That 
will create a temporary blip. But then the attacker will have to keep 
doing that for a long time, because otherwise the clients will 
automatically lower the target. That seems to require a lot of computing 
capacity.

-- Christian Huitema