<div dir="ltr">Ok I think I've got a good understanding of where we're at now. I can promise that the next person to waste your time in 30 days will not be me. I'm pleasantly surprised to see a community that doesn't kickban newcomers and takes the time to explain (re-explain) concepts. <div>
<br></div><div>Hoping to add *beneficial* thoughts in the future!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 10, 2014 at 12:59 PM, Pieter Wuille <span dir="ltr"><<a href="mailto:pieter.wuille@gmail.com" target="_blank">pieter.wuille@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Apr 10, 2014 at 6:47 PM, Brian Hoffman <<a href="mailto:brianchoffman@gmail.com">brianchoffman@gmail.com</a>> wrote:<br>
> Looks like only about ~30% disk space savings so I see your point. Is there<br>
> a critical reason why blocks couldn't be formed into "superblocks" that are<br>
> chained together and nodes could serve a specific superblock, which could be<br>
> pieced together from different nodes to get the full blockchain? This would<br>
> allow participants with limited resources to serve full portions of the<br>
> blockchain rather than limited pieces of the entire blockchain.<br>
<br>
As this is a suggestion that I think I've seen come up once a month<br>
for the past 3 years, let's try to answer it thoroughly.<br>
<br>
The actual "state" of the blockchain is the UTXO set (stored in<br>
chainstate/ by the reference client). It's the set of all unspent<br>
transaction outputs at the currently active point in the block chain.<br>
It is all you need for validating future blocks.<br>
<br>
The problem is, you can't just give someone the UTXO set and expect<br>
them to trust it, as there is no way to prove that it was the result<br>
of processing the actual blocks.<br>
<br>
As Bitcoin's full node uses a "zero trust" model, where (apart from<br>
one detail: the order of otherwise valid transactions) it never<br>
assumes any data received from the outside it valid, it HAS to see the<br>
previous blocks in order to establish the validity of the current UTXO<br>
set. This is what initial block syncing does. Nothing but the actual<br>
blocks can provide this data, and it is why the actual blocks need to<br>
be available. It does not require everyone to have all blocks, though<br>
- they just need to have seen them during processing.<br>
<br>
A related, but not identical evolution is merkle UTXO commitments.<br>
This means that we shape the UTXO set as a merkle tree, compute its<br>
root after every block, and require that the block commits to this<br>
root hash (by putting it in the coinbase, for example). This means a<br>
full node can copy the chain state from someone else, and check that<br>
its hash matches what the block chain commits to. It's important to<br>
note that this is a strict reduction in security: we're now trusting<br>
that the longest chain (with most proof of work) commits to a valid<br>
UTXO set (at some point in the past).<br>
<br>
In essence, combining both ideas means you get "superblocks" (the UTXO<br>
set is essentially the summary of the result of all past blocks), in a<br>
way that is less-than-currently-but-perhaps-still-acceptably-validated.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Pieter<br>
</font></span></blockquote></div><br></div>