Quote from: ranochigo on November 18, 2017, 08:02:54 AM

So you're just solving the storage problem?

Maybe it could be configurable, like pruned mode. Those who want to fully download and verify all blocks since the beginning can do so, others can rely on just the block headers.

Quote

Block headers doesn't show if a block is valid.

But if you trust them to be a linked list of the REAL chain, you also trust their hashes. And since you would fully validate some statistical percentage of the blocks, it would be hard to fake just some blocks in the middle which you didn't validate. Also, you could potentially validate some of these blocks later. For example, maybe the client could download each hour 1 random block it didn't validate as part of its 10% download.

Quote

With your implementation, only one peer can provide the specific portion of blocks, making it a bottleneck.

Why one peer? If it's 10%, 10% of the nodes can provide it. That's still hundreds or thousands.
I don't think currently you're connecting to 100% of the nodes to download the whole chain.

Quote

What does the full node being not in sync relate to the problem?

It just means that already the client doesn't assume each full node holds the whole chain, and can query and seek another node if needed. It could be the basis to build upon for the split chain protocol.

Quote

Nodes cannot see the entire network and no one can connect to all of them.

Sure, but you can connect to a large enough portion of it to find what you need, like it already does. There are other examples of decentralized networks which work with far fewer nodes holding data, sometimes just a single one, like Kad and BitTorrent's DHT.

Quote

might as well as just have a pruned node instead of going through the trouble.

That's one option, but: it just solves storage, it can't help serving blocks as a "split full node", and in the long term also the initial download can be a problem. In a way, bootstrapping a client from scratch already takes too long.