You don't see a problem with that? Currently a 51% attack "only" alloww the attacker to
* stop the network
* double spend his own coins (reverse txs he created)
If network is reduced to a flat ledger a 51% attack would allow the attacker to change balances of accounts he doesn't own which massively increases the economic value of 51% attack. Even the potential is damaging.
Obviously you didn't read very far. Ledgers would be validated in the same way as blocks, via hashing power with periodic ledger hashes. They could additionally be verified with proof of stake, and you could reduce the maximum reorg down to 24h of blocks, or possibly even less with additional measures.
Then again 75MB + 50MB per week (say 4 weeks of history retained) = 275 MB which last time I checked > 50MB claimed. Also that was a back of the napkin estimate. Someone actually did create a ledger and the size was 10% of full blockchain. So that would be more like 200MB + 200MB for 4 weeks of history = 400 MB.
The cost estimate for a pruned blockchain is ~500MB vs 2GB raw so you are saving very little. Pruned block chain provides most of the space reduction with no loss of security.
If you had read more than one post, you'd know that he got it down to 7% of the total blockchain size, not 10%. 50MB per week suggests a 5GB blockchain by the end of 2012. Either the blockchain is more than doubling in size every year now, which is in excess of moore's law, or you're full of crap on that figure.
AFAIK pruned merkle trees can only be used to verify your own balance, and not anyone else's. That is, you can't mine using only that, and you if you can't mine then you also can't verify a tx someone has sent to you.
Not correct but at least this time you correctly indicated it it your belief not fact.
Pruned merkle tree allows verification of blocks, verification of your tx, verification of other users tx, and mining new blocks. There is no functionality that is lost with the exception of tracing coin history beyond the oldest unspent output.
To verify tx (yours or anyone elses) you simply need to verify the prior outputs of the inputs in the tx to be verified. By definition those would be included in a pruned blockchain. Mining doesn't require anything beyond verifying txs other than access to prior blocks block header, the block height, and the ability to verifying work created by peers.
It might be a good idea to actually read the white paper.
You know I put off reading the whitepaper primarily because I assumed it would be a full dissertation. I was disappointed.
However now I understand the way merkle trees work for the most part. Here's a comparison:
-When you prune merkle trees, you still have to keep the block header, all of the merkle tree hashes, and the full tx of any tx that have any unspent txOuts, including all of the txIns, all of the scripts for the txIns, all of the txOuts (including spent txOuts) plus all of the scripts for the txOuts. Verifying tx still requires either a full pruned blockchain or that you trust centralized nodes to provide you with the correct merkle tree entries that you request.
-For the linked ledger system, you throw away all but the unspent txOuts plus the scripts for the unspent txOuts. All block headers older than a certain time can be discarded along with all of the merkle hashes and tx, and each client only needs to keep 4-5 weeks of blockchain and 3 ledgers (1 for an old seeding period, 1 backup, 1 current), of which 2 weeks of blockchain and 2 ledgers can be compressed since they're seldom if ever needed.
-If all unspent txOuts which have the same address are added together and condensed, that would reduce the size of a ledger by ~50% or more. This would also require using the full value of an acct as txIn, but that also reduces the size of txIns on the blockchain as a result.
2000MB * .035 = 70MB Per ledger
70MB * 2 = 140MB of ledgers that can be compressed
33MB (est weekly block size with reduced txIns) * 3 = 99MB uncompressed blockchain (maximum, varies)
66MB compressible blockchain (2wks historical for seeding)
70 + 99 = 169MB uncompressed
140 + 66 = 206MB compressible
I think your 500MB estimate for pruned merkle trees is overly optimistic. I'll believe it when I see it. Assuming you can compress data to 66% of original using zip or similar, with ledgers you'd only keep a maximum of about 305MB, and only 215MB for a lite client.
That's assuming that 6 months of total blockchain are retained over the mining network for seeding so that clients can do a "full verification" on first start, and is still ~1/2 to 1/3 the size of a fully pruned complete blockchain, and ~10% of an unpruned one, even with backups.