Quote from: briguy37 on March 04, 2016, 10:08:55 PM

1) A new miner downloads all unique pruned blockchains visible to them. It is assumed that one of them will be correct because the Bitcoin network is the most powerful network in the world.

That isn't a good assumption to make. Sybil attacks on the bitcoin network are still possible.

Quote from: briguy37 on March 04, 2016, 10:08:55 PM

2) If there are no competing chains, great! If there are competing chains, they must be compared to find out which is the true blockchain and which is/are the counterfeit(s). As you pointed out it is easier to counterfeit back to a Pruning Block than the blockchain because you do not need to generate all blocks back to the genesis block, you just need to lie with the pruning block you start with. Thus, we can take additional precautions:
a) Check the block difficulty level of the blocks. If it is too low throw the blocks out. This will limit the people who could take advantage of this attack to only very powerful miners, as you can't fake the difficulty of a block.

What constitutes a too low difficulty? How would a new node determine that?

Quote from: briguy37 on March 04, 2016, 10:08:55 PM

b) Download back to the last 2 pruning blocks instead of just the last 6 regular blocks. At 1008 blocks between pruning blocks plus 6 confirmations for the pruning block, this means the malicious miner would need to generate at least 1014 near the current difficulty of the actual network instead of 6. This will limit the risk to extremely powerful miners, as even a miner/pool with 10% of the network would take 2.5 months to dochecked

While that could work, a malicious miner could generate blocks with timestamps several months in advance and pregenerate them.

Quote from: briguy37 on March 04, 2016, 10:08:55 PM

c) Check that current transactions are getting through in a timely fashion (e.g. monitor for 6+ blocks for anything fishy). Your node can monitor all published transactions and make sure they are included. If they are not being included in one chain they you know something is fishy with that. This will prevent against pre-generating 2000 blocks and then re-playing the blocks back.

That could work too prevent 2b from happening but what if the miner pregenerates transactions? The transactions in the blocks are pregenerated and broadcasted to the victim node at the appropriate times?

Quote from: briguy37 on March 04, 2016, 10:08:55 PM

d) Validate that times of the blocks make sense. This will prevent re-playing a pre-generated block sequence more than once since the dates/times will not line up.

IIRC bitcoin core already does that check for new blocks anyways. Lookup the timejacking attack.

Quote from: briguy37 on March 04, 2016, 10:08:55 PM

e) As a final fallback for those not willing to take any risk, download the whole chain.

That is always a safe backup.

Quote from: briguy37 on March 04, 2016, 10:08:55 PM

The pruning block doesn't replace the UTXOs, it only contains copies of them. They should not be considered separate transactions.

Well also having those UTXOs will inflate that block size because it has to include all previous UTXOs.

Quote from: briguy37 on March 04, 2016, 10:08:55 PM

True, but the amount of transactions people want to make can grow exponentially. If the limits aren't raised accordingly, exponentially more people will be boxed out, fees will skyrocket, and the Bitcoin adoption rate will decrease.

Yes but there will always be a limit so the blockchain will always grow linearly once the maximum is reached. Also there are other scaling solutions than just the block size limit such as lightning and sidechains.