<blockquote>
  <p>Then when my chain (which is essentially empty with just my mining address full of Bitcoin) is as long/longer than the current consensus I can broadcast it and nodes/miners should take the longer chain which will be mine.</p>
</blockquote>

<p>It won't.</p>

<p>To compare the "length" of chains for the purpose of determining which of two valid chains is to be accepted, Bitcoin Core (and I hope all other implementations) look at the amount of work that went into them. Roughly speaking, this means the sum of the difficulties of all the blocks in it.</p>

<p>The only way you'll have more work than the existing chain, is by doing more mining than what went into the existing chain, in a short amount of time. In order to not be outrun by the existing network while you're performing your attack, you'll need (significantly) more hashrate than all the rest of the network combined has. So, what you're talking about is a 51% attack.</p>

<p>That said, there is a related, and far less serious attack possible. You could mine thousands of short low-difficulty branches, that are all valid, but won't ever be accepted, and broadcast them. If nodes would accept them, they'd eventually go out of memory from storing all your headers. The solution to this is the client checkpoints that MCCCS talks about in his answer. Note that the scope of checkpoints has been reduced several times, as they used to protect against many types of attacks that are now prevented through measures that don't rely on hardcoded knowledge about the network.</p>

CC BY-SA 3.0
2017-10-08T20:16:58.903Z
2017-10-08T20:16:58.903Z
Pieter Wuille
<p>What you're looking for, is <a href="https://en.bitcoin.it/wiki/Checkpoint_Lockin" rel="nofollow noreferrer">Block Checkpoints</a>. To prevent what you said, client developers hardcode hashes of some blocks in the clients. For example, the latest checkpoint in Core is <a href="https://github.com/bitcoin/bitcoin/blob/c091b99/src/chainparams.cpp#L162" rel="nofollow noreferrer">block 295000</a> at the time of writing this, so if you want to trick Core, you should mine starting from block 295001. Also note that different clients have different block checkpoints.</p>

CC BY-SA 3.0
2017-10-08T09:56:12.407Z
2017-10-08T09:56:12.407Z
MCCCS
<p>I was having a look at the genesis block of Bitcoin earlier and noticed the difficulty was set to 1. I guess this was originally designed so just Satoshi's computer mining at this difficulty would produce 10 minute blocks.</p>

<p>However, if I put my GPU/ASIC to mine at the beginning of the chain at this difficulty I could find blocks incredibly quickly. Even if I could mine each block in 10ms it would take me around 12 hours to reach the current block height. I realise finding blocks this quickly would also ramp up the difficulty after 2160 blocks but I could just fabricate the timestamp on the blocks so it looks like they all came in at 10 minutes. </p>

<p>Then when my chain (which is essentially empty with just my mining address full of Bitcoin) is as long/longer than the current consensus I can broadcast it and nodes/miners should take the longer chain which will be mine.</p>

<p>What in the Bitcoin implementation prevents this?</p>

<attack>
What stops this style of attack on the Bitcoin network?
N B
# What stops this style of attack on the Bitcoin network?

(Asked by: username_0 on 2017-10-08)

I was having a look at the genesis block of Bitcoin earlier and noticed the difficulty was set to 1. I guess this was originally designed so just Satoshi's computer mining at this difficulty would produce 10 minute blocks.

However, if I put my GPU/ASIC to mine at the beginning of the chain at this difficulty I could find blocks incredibly quickly. Even if I could mine each block in 10ms it would take me around 12 hours to reach the current block height. I realise finding blocks this quickly would also ramp up the difficulty after 2160 blocks but I could just fabricate the timestamp on the blocks so it looks like they all came in at 10 minutes.

Then when my chain (which is essentially empty with just my mining address full of Bitcoin) is as long/longer than the current consensus I can broadcast it and nodes/miners should take the longer chain which will be mine.

What in the Bitcoin implementation prevents this?

**Tags:** attack


---

## 2 answers

### Answer by username_1 on 2017-10-08. Score: 2

> Then when my chain (which is essentially empty with just my mining address full of Bitcoin) is as long/longer than the current consensus I can broadcast it and nodes/miners should take the longer chain which will be mine.

It won't.

To compare the "length" of chains for the purpose of determining which of two valid chains is to be accepted, Bitcoin Core (and I hope all other implementations) look at the amount of work that went into them. Roughly speaking, this means the sum of the difficulties of all the blocks in it.

The only way you'll have more work than the existing chain, is by doing more mining than what went into the existing chain, in a short amount of time. In order to not be outrun by the existing network while you're performing your attack, you'll need (significantly) more hashrate than all the rest of the network combined has. So, what you're talking about is a 51% attack.

That said, there is a related, and far less serious attack possible. You could mine thousands of short low-difficulty branches, that are all valid, but won't ever be accepted, and broadcast them. If nodes would accept them, they'd eventually go out of memory from storing all your headers. The solution to this is the client checkpoints that username_2 talks about in his answer. Note that the scope of checkpoints has been reduced several times, as they used to protect against many types of attacks that are now prevented through measures that don't rely on hardcoded knowledge about the network.


---

### Answer by username_2 on 2017-10-08. Score: 0

What you're looking for, is [Block Checkpoints](https://en.bitcoin.it/wiki/Checkpoint_Lockin). To prevent what you said, client developers hardcode hashes of some blocks in the clients. For example, the latest checkpoint in Core is [block 295000](https://github.com/bitcoin/bitcoin/blob/c091b99/src/chainparams.cpp#L162) at the time of writing this, so if you want to trick Core, you should mine starting from block 295001. Also note that different clients have different block checkpoints.


---

