<p>I finally found an answer (very old): <a href="https://bitcointalk.org/index.php?topic=823.msg9668#msg9668" rel="nofollow">https://bitcointalk.org/index.php?topic=823.msg9668#msg9668</a></p>

<p>knightmb: "The old clients should accept it all the way back to the last snapshot of release"</p>

<p>If it's still true this in fact answers my question.</p>

CC BY-SA 3.0
2016-07-26T17:32:04.133Z
Actually, up to the last checkpoint, which is [block 295,000](https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/chainparams.cpp#L152). If that was your question, it really wasn't clear… Your title was "…100 blocks ahead tried to merge back?".
Murch
CC BY-SA 3.0
2016-07-25T22:51:25.723Z
2016-07-25T22:51:25.723Z
Joshua
<blockquote>
  <p>One possibility, as hinted by Murch, would be to pre-build a long chain, then using an attack on the hash take a few hours to construct a block with exactly a given hash. This may require waiting until an exceptionally vulnerable block appears but that doesn't really matter.</p>
</blockquote>

<p>I don't see where I hinted that, but that would definitely not work. </p>

<blockquote>
  <p>few hours to construct a block with exactly a given hash.</p>
</blockquote>

<p>Block hashes are SHA-256d hashes. The space of 2^256 is too large to brute force for the foreseeable future. Definitely its impossible to do in "a few hours".</p>

<blockquote>
  <p>exceptionally vulnerable block</p>
</blockquote>

<p>What's that supposed to be? Blocks are not more or less vulnerable.</p>

<blockquote>
  <p>pre-build a long chain</p>
</blockquote>

<p>The whole chain would become invalid if you changed the first element. Each block builds on the block hash of its predecessor. Therefore, two blockchains cannot be arbitrarily appended to each other.</p>

<p>And as already described in the comments above: </p>

<blockquote>
  <p>high number of lower difficulty blocks</p>
</blockquote>

<p>It's not the count of blocks that counts but the total "weight" measured in summed difficulty.</p>

CC BY-SA 3.0
2016-07-25T18:28:55.223Z
I am extrapolating what early attacks might appear first in SHA-256 based on what order they appeared in MD5. And with MD5 it did happen where certain MD5 hashes were far easier to construct vectors for than others.
Joshua
CC BY-SA 3.0
2016-07-25T18:43:25.253Z
MD5 was broken to prefix collision attacks. What we'd need here are pre-image attacks. Even MD5 remains safe to pre-image attacks. In fact, mining is basically an attempt to brute force a pre-image attack. All of that is further encumbered by you needing to use a valid block header as input. It seems rather unlikely that SHA-256d pre-image resistance will be broken anytime soon, but knock yourself out.
Murch
CC BY-SA 3.0
2016-07-25T18:50:36.287Z
@Joshua, perhaps this is a separate question.  It feels like you are asking more about potential cryptographic attacks than you are block reorginzations.  Your clarifications don't really seem to have much to do with the original question.  I'm not saying that it's a bad line of inquiry, but perhaps it should be its own question.
Jestin
CC BY-SA 3.0
2016-07-25T16:34:16.423Z
2016-07-25T16:34:16.423Z
Murch
<p>Suppose mining pool has been off the main network for a long time so that they are 100 or so blocks behind, but managed to mine 200 blocks in the period (say, some combination of had 33% before, deliberately selecting easy blocks to extend, and ...).</p>

<p>Obviously, this can happen by choking down the difficulty, but I'd assume there are protections against such an obvious attack as that one. Update: assumption verified; reducing the difficulty doesn't work here as expected.</p>

<p>I found two roughly similar questions, but neither seems right:</p>

<p><a href="https://bitcoin.stackexchange.com/questions/24584/can-a-double-spend-attack-be-obfuscated-by-mimicking-the-transactions-seen-befor">Can a double spend attack be obfuscated by mimicking the transactions seen before the fork?</a></p>

<p><a href="https://bitcoin.stackexchange.com/questions/12207/countrywide-internet-isolation-inevitable-fork">Countrywide Internet isolation, inevitable fork</a></p>

<p>The obvious answer, if it contained only mined transactions, would be to manually discard it, but I don't think that assumption would prove valid.</p>

<p>I am bothered by the belief that this is a duplicate of longest chain vs. highest difficulty. Marking this as duplicate pre-supposes an entire class of cryptographic attacks on hashes does not exist, and many other things as well.</p>

<p>One possibility, as hinted by Murch, would be to pre-build a long chain, then using an attack on the hash take a few hours to construct a block with exactly a given hash. This may require waiting until an exceptionally vulnerable block appears but that doesn't really matter.</p>

<p>I finally guessed what a no-malice version might look like and I found this: <a href="https://bitcoin.stackexchange.com/questions/8554/scenario-disaster-splits-the-internet-into-dozens-unconnected-fragments">Scenario: disaster splits the Internet into dozens unconnected fragments</a> Basically, bad things happen if the largest connected network is &lt;&lt; 50%.</p>

CC BY-SA 3.0
2016-07-22T17:02:05.633Z
@Jestin: Turns out my assumption was correct. Lowering the difficulty gets caught.
Joshua
CC BY-SA 3.0
2016-07-22T20:32:39.683Z
If they are a 33% percent miner, then they won't be able to mine those 200 blocks in time to overtake the rest of the network. The miner can of course try adjusting the difficulty down (if some those 200 blocks are within a difficulty transition), but then the "heaviest chain" rule would ensure his fork gets dropped.
Alin Tomescu
CC BY-SA 3.0
2016-07-22T21:57:10.583Z
I'm imagining something like a chosen block attack on the hash itself where the difficulty meter is false if you can constrain the block contents sufficiently.
Joshua
CC BY-SA 3.0
2016-07-23T17:58:23.023Z
I'm not sure what you mean by a "chosen block attack" but note that you _can't fake_ the difficulty of a block, nor the difficulty of a chain. In a difficulty readjustment period of 2016 blocks you can make it seem like you have found those blocks really really fast by lying about their timestamp, but that will increase your difficulty in the next period, making it very slow for you to mine the next 2016 blocks. Not sure if this addresses your attack or not.
Alin Tomescu
CC BY-SA 3.0
2016-07-25T06:11:54.907Z
@Joshua: Sorry, we must have misunderstood your scenario. So, they created a longer chain, but **didn't lower** the difficulty. Could you please elaborate how they managed that? What properties does the longer chain have? A longer chain of valid blocks would cause a reorganization, I believe up to 100 blocks. If they however cheated with some form of invalid blocks, they'd just be ignored by the network. So, please clarify the scenario. Especially, what do you mean with "if it contained only mined transactions"? What is "it" and what do you mean with "mined"?
Murch
CC BY-SA 3.0
2016-07-25T17:36:51.757Z
@Joshua, I get the feeling that you are misunderstanding something fundamental, although I'm not sure what.  The cryptography that Bitcoin is based on is indeed presupposed to be secure against certain cryptographic attacks.  If there were known vulnerabilities in the cryptography used, then there would be a fork to change to a more secure algorithm.  If you feel that you can break the existing crypto, then there is a $10B bounty to do so.  So far, it hasn't been claimed.
Jestin
CC BY-SA 3.0
2016-07-25T18:48:35.643Z
@Jestin: The misunderstanding is based on assuming feasability of pre-image attacks. However, that would also completely nullify mining as the proof-of-work would cease to be that. Bitcoin would have to switch to another pow algorithm at that point, but probably it would be just dead.
Murch
<blockchain-fork><chain-reorganization>
What would happen if a private fork several hundred blocks ahead tried to merge back?
Joshua
# What would happen if a private fork several hundred blocks ahead tried to merge back?

(Asked by: username_0 on 2016-07-22)

Suppose mining pool has been off the main network for a long time so that they are 100 or so blocks behind, but managed to mine 200 blocks in the period (say, some combination of had 33% before, deliberately selecting easy blocks to extend, and ...).

Obviously, this can happen by choking down the difficulty, but I'd assume there are protections against such an obvious attack as that one. Update: assumption verified; reducing the difficulty doesn't work here as expected.

I found two roughly similar questions, but neither seems right:

[Can a double spend attack be obfuscated by mimicking the transactions seen before the fork?](https://bitcoin.stackexchange.com/questions/24584/can-a-double-spend-attack-be-obfuscated-by-mimicking-the-transactions-seen-befor)

[Countrywide Internet isolation, inevitable fork](https://bitcoin.stackexchange.com/questions/12207/countrywide-internet-isolation-inevitable-fork)

The obvious answer, if it contained only mined transactions, would be to manually discard it, but I don't think that assumption would prove valid.

I am bothered by the belief that this is a duplicate of longest chain vs. highest difficulty. Marking this as duplicate pre-supposes an entire class of cryptographic attacks on hashes does not exist, and many other things as well.

One possibility, as hinted by username_2, would be to pre-build a long chain, then using an attack on the hash take a few hours to construct a block with exactly a given hash. This may require waiting until an exceptionally vulnerable block appears but that doesn't really matter.

I finally guessed what a no-malice version might look like and I found this: [Scenario: disaster splits the Internet into dozens unconnected fragments](https://bitcoin.stackexchange.com/questions/8554/scenario-disaster-splits-the-internet-into-dozens-unconnected-fragments) Basically, bad things happen if the largest connected network is << 50%.

**Tags:** blockchain-fork, chain-reorganization

> **Comments:**
> **username_0**: @username_3: Turns out my assumption was correct. Lowering the difficulty gets caught.  
> **username_1**: If they are a 33% percent miner, then they won't be able to mine those 200 blocks in time to overtake the rest of the network. The miner can of course try adjusting the difficulty down (if some those 200 blocks are within a difficulty transition), but then the "heaviest chain" rule would ensure his fork gets dropped.  
> **username_0**: I'm imagining something like a chosen block attack on the hash itself where the difficulty meter is false if you can constrain the block contents sufficiently.  
> **username_1**: I'm not sure what you mean by a "chosen block attack" but note that you _can't fake_ the difficulty of a block, nor the difficulty of a chain. In a difficulty readjustment period of 2016 blocks you can make it seem like you have found those blocks really really fast by lying about their timestamp, but that will increase your difficulty in the next period, making it very slow for you to mine the next 2016 blocks. Not sure if this addresses your attack or not.  
> **username_2**: @username_0: Sorry, we must have misunderstood your scenario. So, they created a longer chain, but **didn't lower** the difficulty. Could you please elaborate how they managed that? What properties does the longer chain have? A longer chain of valid blocks would cause a reorganization, I believe up to 100 blocks. If they however cheated with some form of invalid blocks, they'd just be ignored by the network. So, please clarify the scenario. Especially, what do you mean with "if it contained only mined transactions"? What is "it" and what do you mean with "mined"?  
> **username_3**: @username_0, I get the feeling that you are misunderstanding something fundamental, although I'm not sure what.  The cryptography that Bitcoin is based on is indeed presupposed to be secure against certain cryptographic attacks.  If there were known vulnerabilities in the cryptography used, then there would be a fork to change to a more secure algorithm.  If you feel that you can break the existing crypto, then there is a $10B bounty to do so.  So far, it hasn't been claimed.  
> **username_2**: @username_3: The misunderstanding is based on assuming feasability of pre-image attacks. However, that would also completely nullify mining as the proof-of-work would cease to be that. Bitcoin would have to switch to another pow algorithm at that point, but probably it would be just dead.  

---

## 2 answers

### Answer by username_0 on 2016-07-25. Score: 0 | Accepted answer

I finally found an answer (very old): <https://bitcointalk.org/index.php?topic=823.msg9668#msg9668>

knightmb: "The old clients should accept it all the way back to the last snapshot of release"

If it's still true this in fact answers my question.

> **Comments:**
> **username_2**: Actually, up to the last checkpoint, which is [block 295,000](https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/chainparams.cpp#L152). If that was your question, it really wasn't clear… Your title was "…100 blocks ahead tried to merge back?".  

---

### Answer by username_2 on 2016-07-25. Score: 1

> One possibility, as hinted by username_2, would be to pre-build a long chain, then using an attack on the hash take a few hours to construct a block with exactly a given hash. This may require waiting until an exceptionally vulnerable block appears but that doesn't really matter.

I don't see where I hinted that, but that would definitely not work.

> few hours to construct a block with exactly a given hash.

Block hashes are SHA-256d hashes. The space of 2^256 is too large to brute force for the foreseeable future. Definitely its impossible to do in "a few hours".

> exceptionally vulnerable block

What's that supposed to be? Blocks are not more or less vulnerable.

> pre-build a long chain

The whole chain would become invalid if you changed the first element. Each block builds on the block hash of its predecessor. Therefore, two blockchains cannot be arbitrarily appended to each other.

And as already described in the comments above:

> high number of lower difficulty blocks

It's not the count of blocks that counts but the total "weight" measured in summed difficulty.

> **Comments:**
> **username_0**: I am extrapolating what early attacks might appear first in SHA-256 based on what order they appeared in MD5. And with MD5 it did happen where certain MD5 hashes were far easier to construct vectors for than others.  
> **username_2**: MD5 was broken to prefix collision attacks. What we'd need here are pre-image attacks. Even MD5 remains safe to pre-image attacks. In fact, mining is basically an attempt to brute force a pre-image attack. All of that is further encumbered by you needing to use a valid block header as input. It seems rather unlikely that SHA-256d pre-image resistance will be broken anytime soon, but knock yourself out.  
> **username_3**: @username_0, perhaps this is a separate question.  It feels like you are asking more about potential cryptographic attacks than you are block reorginzations.  Your clarifications don't really seem to have much to do with the original question.  I'm not saying that it's a bad line of inquiry, but perhaps it should be its own question.  

---

