Author

Topic: Catchup Attack - An Attack on the Bitcoin Blockchain - Is such a thing possible? (Read 2404 times)

legendary
Activity: 2618
Merit: 1007
You could simply lie when setting time stamps, so you could always mine with full power.
Still the attack won't be easy starting from Genesis, as you would need to do additional work to "pay"for the hills in difficulty that happened, on the other hand you would just need to start at the most recent checkpoint as "Genesis" anyways.
The only countermeasure is to release a new client with a new checkpoint and get everyone to switch. However if you are able to catch up with the main chain anyways, you likely have much more hashing power than all mongers combined and could pull off easier attacks too.
legendary
Activity: 1792
Merit: 1111
legendary
Activity: 1078
Merit: 1006
100 satoshis -> ISO code
newbie
Activity: 14
Merit: 0
    5. Each time the blockchain’s mining difficulty is re-calculated the hardware then applies four times as much hashing power to solving the next 2016 blocks. The effect of this will be to generate blocks in a quarter the target time the current blockchain was generated. E.g. the first 2016 blocks will be hashed with a hashrate of 10Khs, as soon as the difficulty re-adjusts the next 2016 blocks are then hashed with a hashrate of 40KHs, then 160KHs at the next difficulty adjustment, and 640KHs at the fourth adjustment.

I think this is the problem.

You have to 4x the difficulty at each readjustment. Since the beginning there have been almost 130 readjustments. By the time you caugh up to the current lenght the network hashrate would be 10Kh * ( 4 ^ 130 ) or 1.85e+71Kh. This is a stupidly large number and no one would have this hashrate available to them.

sr. member
Activity: 462
Merit: 250
Nodes choose the chain with the highest accumulated difficulty, not the longest chain.
what justus pointed out is exactly what makes this hard - you would need to have substantially more total hashing power under your control than the current amount available for BTC or whatever coin you were trying to catch up to. checkpoints would also make this hard since i doubt most nodes would accept the chain if the checkpoints didn't match, meaning the best catch up attack you can pull off is once since the last checkpoint.

With Bitcoin, this would be practically impossible. However with a new coin, it wouldn't be too difficult, if you had enough hashing power, I.E. a BTC pool going at a new coin, like KimCoin, would be very easy.
full member
Activity: 121
Merit: 103
Nodes choose the chain with the highest accumulated difficulty, not the longest chain.
what justus pointed out is exactly what makes this hard - you would need to have substantially more total hashing power under your control than the current amount available for BTC or whatever coin you were trying to catch up to. checkpoints would also make this hard since i doubt most nodes would accept the chain if the checkpoints didn't match, meaning the best catch up attack you can pull off is once since the last checkpoint.
legendary
Activity: 1400
Merit: 1013
Nodes choose the chain with the highest accumulated difficulty work, not the longest chain.
hero member
Activity: 906
Merit: 1034
BTC: the beginning of stake-based public resources
I’ve had a look around and can’t find an answer to this.

Is it possible to attack the current Bitcoin blockchain with a competing blockchain that is longer than it?

For example to attack the current blockchain within the timespan of roughly a quarter of its current lifetime you would:

    1. Work out the length of the current blockchain to be attacked.
    2. Work out the maximum hashing power of the hardware you wish to use to generate the new blockchain.
    3. Recursively divide the hashing power of the hardware by four for each difficulty adjustment the current blockchain has undergone. E.g. if you have a hashrate of  640 KHs and the blockchain has undergone 3 difficulty adjustments you would calculate 640KHs/4^3 = 10KHs.
    4. Start generating the new blockchain from the genesis block, starting with the lowest calculated hashrate. For this example 10KHs.
    5. Each time the blockchain’s mining difficulty is re-calculated the hardware then applies four times as much hashing power to solving the next 2016 blocks. The effect of this will be to generate blocks in a quarter the target time the current blockchain was generated. E.g. the first 2016 blocks will be hashed with a hashrate of 10Khs, as soon as the difficulty re-adjusts the next 2016 blocks are then hashed with a hashrate of 40KHs, then 160KHs at the next difficulty adjustment, and 640KHs at the fourth adjustment.
    6. Once a the new blockchain, longer than the current blockchain has been generated, the attacker can propagate it across the network, replacing the current blockchain.

(For simplicity I have assumed that the current blockchain does not continue to grow whilst the hardware is generating a new block chain in reality you would assume a longer generation time than that of the current blockchain if you wanted to launch an attack).

Assumptions:

    1. Blocks can be mined with an extremely low hashrate.
    2. The Bitcoin network favours the chain of the longest length. (I may be wrong here and it may infact favour the chain of the greatest average difficulty).
    3. Each network difficulty adjustment adjusts the block generation time back to the average target (10 minutes in the case of Bitcoin) and that for each adjustment there are no maximum or minimum levels by which it can be adjusted per readjustment.

Unknowns:

Could a new blockchain be generated in a similar manner to above to attack a Proof of Stake (PoS) blockchain in the following manner:

In the future, where there has been significant improvements in hashing power and assuming the network does judge blockchain preference on average difficulty of the blocks generated, could an attacker generate a new PoS blockchain from the genesis block on separate hardware, then when it exceeds the current PoS blockchain release this to the network to overwrite the current PoS blockchain?

If the PoS blockchain selection were then to rely on transaction volume to try and mitigate this for example it could still be fooled by a basic sybil attack, so a Proof of Work or PoS mechanism could be needed to mitigate this.

Can anyone clarify the above and any assumption I may have made?
Jump to: