And all together your comment also show that you dont see my perpective, and why the thing you point doesnt matter, and what I meant with checkpoint is that you would only need real pow consencus on this checkpoint to "harden" The chain if you want to enforce a particular order on the tx/block, but that would just be about one packet saying this block height is this block hash, and having a pow once in a while on this checkpoint instead of every block.
I invented that already in collaboration with @jl777 for Komodo in 2016. It is named dPoW (delayed proof-of-work).
CounterParty does something somewhat analogous as well.
And really it isn't a secure and sound solution, but more of a gimick. Because the local consensus still have to decide what to submit for checkpoints because the PoW system isn't validating every thing and can't resolve conflicting double-spending orderings that occurred between checkpoints.
I don't think you understand my discussion with dinofelis.
My main point is more to show that the whole pow scheme make more sense if you take it from the perspective of trading / speculation side, than as a decentralized currency / public ledger.
But in the same time, there are many point of bitcoin that are clumpsy.
Even if dinofelis i think make the same mistake many person do, and i was doing this mistake before too, is too estimate one functionality of bitcoin to make it fit to usual engineering criteria of efficiency for a particular purpose, but without seeing the real purpose of it, and why some aspect my look clumpsy because they are on the low end of the trade off in favor of something else.
And the thing it seem to does well is attracting high speculative value, and high stake of game theory on the pow side. As decentralized currency it has many flaw, especially currently, and is not either extremely efficient as a distributed public ledger.
Only looking at the code it's clear it's very messy.
Actually before i came to forum i already studied in depth code source from 3 core, bitcoin, bitmonero and blackcoin, from where i decided to rewrite my own client from scratch because the code is too messy.
Coming here i though there would be people who really understand the code and the theory and choice behind, but in reality i don't think anyone on this board as a real clue.
Only the fact that nobody can really understand it, or easily extend on it, not even talking about the protocol, but about all the various bugs and clumpsyness, either it's in the wallet, database indexing/managment, threading, and many bugs, or things that could be improved as long as all the mythical wish of the creator with a gran plan for the world is put aside
On the overall i don' think anyone will disagree that the code is poorly designed, regarding all the OO, all the way the thing is made, it's very monolithic, against all good practice you would find in programming school book, and very hard to extend or encapsulate, and the rpc interface can only do that much, and is not that easy to really use from the perspective of making more complex web app/Dapp.
But in the same time, once you integrate all the game theory and math model for speculation and all this, it's easier to see where the code make more sense, and which base variable are actually more carefully designed in their definition and access, and where the care is put on, and it's not especially on the efficiency as a distributed ledger to solve double spend, or having easily distributed application wallet/shops/explorer "out of the box".
That's mainly my point here.
But maybe if i keep focused on this goal, i'm sure i can put up a testnet with experimental blockchain like without pow and reward, based on XThin block / bloom filter kind of things, and blockchain reordering , like in the idea the DAG thing, but without DAG, but real time re computation of block header chain when new valid tx are received, and still consensus on the same one chain, without needing pow or reward to validate blocks, with the idea i explained in the discussion with dinofelis
And in this idea, the checkpoint is mostly optional, but just to sort out the few % of error margin and to solve quicker some consencus problem on the long term.
I'm pretty sure with the script engine stuff like this will be made easily
( and please don't cherry pick one sentence out of context and copy paste it in 3 threads to show how smart you are, it's not very nice
)