0

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?

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 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.

I finally guessed what a no-malice version might look like and I found this: Scenario: disaster splits the Internet into dozens unconnected fragments Basically, bad things happen if the largest connected network is << 50%.

|improve this question
  • @Jestin: Turns out my assumption was correct. Lowering the difficulty gets caught. – Joshua Jul 22 '16 at 17:02
  • 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 Jul 22 '16 at 20:32
  • 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 Jul 22 '16 at 21:57
  • 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 Jul 23 '16 at 17:58
  • @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♦ Jul 25 '16 at 6:11
1

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.

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.

|improve this answer
  • 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 Jul 25 '16 at 18:28
  • 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♦ Jul 25 '16 at 18:43
  • 1
    @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 Jul 25 '16 at 18:50
0

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.

|improve this answer
  • 1
    Actually, up to the last checkpoint, which is block 295,000. If that was your question, it really wasn't clear… Your title was "…100 blocks ahead tried to merge back?". – Murch♦ Jul 26 '16 at 17:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.