Quote from: work2heat on November 01, 2014, 11:40:40 PM

pow is a form of validity.

It isn't. See the discussion about fraud proofs and probabilistic testing. Please also note that the tone you've taken here is irritating and is likely to cause experienced people to ignore your messages in the future if you continue with it.

Quote

Quote

Great now I create a simulated history which that sets a bogus 'checkpoint' back early in the chain, but any _new_ nodes that attach to me I give this simulated history to before they know there is a better chain elsewhere and they start enforcing that rule and they are now forked off onto this bogus alternative chain;

this argument applies to any blockchain. If I can get the node to think the chain I give it is the right one before it even sees any other, I win. But here, there is still a PoW element, so as soon as the node sees a chain with higher total diff it will know the one I sent was bogus.

Thats not correct. If you give a bitcoin node a chain and then someone else gives it a mutually exclusive longer one, your chain will simply be unwound and replaced, so giving it that extra data is harmless, once the honest network is observed its like the node never saw the forgery. When you start talking about "check-pointing" based on that chain the situation changes and you get the attack. (and not just that attack, there are several others, e.g. announcing two competing equally valid forks concurrently and leaving the network in a never-resolving perpetual consensus split).

Quote

So you can start your fork wherever you want, but so long as I haven't been partitioned off the internet completely, this isn't a problem (and if I have been, it's a problem for bitcoin proper too).

Every node begins its life partitioned, our security model also allows temporary partitioning. Assuming you will never be partitioned requires resolving the sybil problem in a strong sense at a minimum and isn't generally compatible with the reality of computer networks today (they're just sometimes partitioned).

Quote

Quote

The result is that you give miners a new power, instead of just being able to reorder the history, they could also create arbitrary inflation just by adding new utxo to their updates. (which, if course, would be in all of their short-term interests to do)

They can already do this by arbitrarily augmenting the coinbase reward. But they don't, because they know other nodes will drop the block and their efforts will go to waste.

Uh. You're pointing out precisely why they cannot. An invalid mined block is invalid, no less than if it didn't meet the target.

Quote

Similarly here. My proposal involved X of Y consecutive blocks to include the same checkpoint for it to be valid. Set that to 70 and 80 say. So for a checkpoint to be valid, 70 of 80 blocks in a row must include it. It is very unlikely a single entity will control all that.

I can mine 80 blocks in a row at height 100,000 trivially in a few seconds myself (there are many thousand in a row mined by me in testnet, for example). I could also mine 80 blocks in a row forking from the current heights at considerable cost given a few months. A bitcoin node doesn't have an absolute synchronous ordered view of the world, it only learns what it learns from its peers... and it can't tell if a simulated blockchain took 6 months of computation or one day, it can't tell if it was created recently or long in the past. etc. If we could tell these things we wouldn't need a blockchain.