In the first place, there is no rationale to store 7 years of history for synced nodes. But how a new node could get into network if all the fullnodes have thrown away all the blocks(except last few ones to handle possible rollbacks)? Bitcoin has no answer for that.
I've developed a proposal to fix the issue and solve some important questions towards better scalability. The paper is just uploaded http://arxiv.org/abs/1603.07926 . I would be happy to get feedback.
I've developed a proposal to fix the issue and solve some important questions towards better scalability. The paper is just uploaded http://arxiv.org/abs/1603.07926 . I would be happy to get feedback.
This paper is a bit of a disappointment, sad to say. First-- it makes a number of false claims about the capabilities of the existing Bitcoin system, e.g.
"To be rational it is needed to switch to an implementation of the Bitcoin protocol which does not hold the unnecessary data (such an implementation of a full node does not exist to the best of our knowledge)."
The whole reason that Bitcoin has state snapshots, as described in the paper, was because they were introduced to enable strong pruning (a more limited version is described in section 7 of the Bitcoin whitepaper). Bitcoin has supported operating in a pruned fashion for _years_.
The primary suggestion the paper is making is to bootstrap nodes from state snapshots. The paper describes this as "trustless" but it is _not_, rather it makes the same strong assumption of hashpower honesty that SPV (lite wallet nodes do), implicitly trusting the history of the longest chain to be faithful.
This is not a new idea, its expression spans at least back to 2011:
https://bitcointalksearch.org/topic/merkle-tree-of-open-transactions-for-lite-mode-21995
and
https://en.bitcoin.it/wiki/User:DiThi/MTUT
(as is using random tests for data in the mining process,-- though the scheme you suggest is fully delegatable, so long as the miner doesn't mind giving temporary custody of his income to the centralized party holding the world's only copy of the blockchain.
)The state commitment proposals face a couple challenges, one is that if you are willing to strongly trust the hashpower-- then why not use the vastly more efficient SPV mode? The other is that the initial efforts to implement continual state commitments found that the overhead (primarily IO) of maintaining them multiplied the full node operating costs at runtime by several fold. The costs have made what would otherwise be another option for client security less attractive, supporting a more niche security model would be fine if it were inexpensive.
Alternative designs like mimblewimble try to make bootstrapping more efficient without adding a new form of strong trust towards miners.
Dear Greg, it seems you've missed a part of the protocol. Let me provide a quick description of Rollerchain, more precisely, modifications from the Bitcoin.
1. We authenticate the state and include root value into a blockheader. It is an old idea yes, and already implemented in Ethereum (and some other coins) as mentioned in the paper.
2. We then modify a Proof-of-Work function. A miner chooses "k" state snapshot versions out of last "n" a (sufficiently large) network stores collectively. In order to generate a block miner needs to provide proofs of possession for the state snapshots. On a new block arrival a miner updates k+1 states, not one, so full blocks (since minimal value in "k") are also needed.
Thus miners store a distributed database of last "n" full blocks AND state snapshots getting rewards for that activity. A new node could download not just a last snapshot, but from "n" blocks ago (or from somewhere in between). So it is not needed to "strongly trust the hashpower", but "hashpower" and also up to "n" last full blocks("n" considered to be >> than a deepest fork possible, say, 5000-10000 for Bitcoin) . And this is not about SPV, but about getting fullnode-going-from-genesis security(with probability of divergence going down exponentially with "n", see Theorem 2). Full blocks not needed in order to mine could be removed by all the nodes.
If you have concerns about this scheme please let me know, and I will try to formalize/address them.
Authenticated state root in a block header could be useful anyway for better SPVs. On efficient implementation, we're now working on that along with benchmarking. Let's see how it goes.
P.S. However, as PoW function modification is needed it is unlikely Bitcoin can go this way(miners will not throw away their ASICs).
