Oh you absolutely cannot just send 300MB, your peers could just lie to you and it would be greatly in their short term financial interest to do so (because they could make you accept inflation or spends of non-existing coins). But you can produce this trusted state for yourself and you don't need to store anything else. ECDSA is cheap, with libsecp256k1 my i7 desktop here validates at almost 6000x the maximum realtime rate for the Bitcoin network.
Thanks for your very helpful replies. There are two issues we are discussing:
1) Cost of downloading & validating full chain
2) Cost of "keeping up" a full node
I guess your machine is 6000x more than adequate enough for task number two
My original concern is with number 1.
For #1 you don't "need" anything more than the UXTO plus set of pruned merkle trees. The same optimizations which improve the efficiency of #2 can be used to improve the efficiency of #1 as well.
Great, so how do we ensure that I am getting a legit UXTO/tree set?
Where are we now with this stuff? I.e., can I start up a full honest node to help support the network in an hour or less?
I imagine there are some problems that could develop should the number of full nodes continue to drop.
It is a work in progress (like most things related to Bitcoin). The first step was getting nodes to store locally a pruned version of the blockchain. The messages used by for inter-node communication will need to be extended to support requesting and sending pruned blocks. If you have a full block it is relatively simple to compute a pruned version of the block and replace the transactions with placeholders. However it probably makes more sense to first extend the block messages to support compact representation of the block which replaces the full transactions with just the transaction hashes (txid). This would also speed up block propagation of new blocks as most nodes already have the set of transactions contained in the block. Later the compact block message could be compacted further by using placeholders for the transactions which are pruned out of the merkle tree.
One correction to my prior response, all nodes need the genesis block (hardcoded to the client) and blockheaders, to perform basic validation. This includes SPV clients as well. The good news is the headers are small (~5MB per block year). The headers prior to the last checkpoint could even be included in the client to speed up bootstrapping.
As for how long would it take to bootstrap a new node from genesis block to fully validated UXTO? Well that depends on the size of the UXTO. The good news is the UXTO grows much slower than the full blockchain. The bad news is that prior to the "dust" rules a lot of outputs were created which likely will never be spent because their value is so much smaller than the cost of spending them. They end up bloating the UXTO. This is why the dust rules are so important (despite the poutrage from a vocal minority). Someday it may make sense to allow limited spending with no fee of "old dust" by adding an exception to the high priority rules. There are also a lot of optimizations that are possible. In the future boostrapping nodes may take advantage of larger numbers of peers and multithreaded verification engine to receive, verify, and store pruned blocks much faster than they do now.
