Here's another proposal (similar to the first link provided) for a "ledger". I think this guy actually went so far as to implement it, and it seemed to be very well thought out.
https://bitcointalk.org/index.php?topic=52859.0I think a major point that's missed about BTC is that, for all intents and purposes the only thing it's really doing is keeping track of account balances. All of the fluff and noise on top of that makes up the rules of how they are managed, but most of the work being done is extremely superfluous. Granted, some of that is on purpose in order to allow for various kinds of "contracts", but for the average tx all of the extra features just end up bloating the blockchain to a soon-to-be-unacceptable size.
One thing I noticed after digging through the protocol details is that the "balance" on any BTC account you have, rather than being stored as a single, current balance, is instead made up of every tx that was ever sent to that address. So, just as an example, say I have a donation account, and 100 people send me 0.01 BTC each. So, my donation account has a balance of 1.00BTC, but in order to spend it, I have to make a tx with 100x 0.01 tx donations as the input. As fees and blockchain size are directly related to the number of txIns and txOuts, half of my donation fund might end up in fees and then everyone who has a copy of the blockchain now must include a block with 100 txIns for one of the tx, even though the total balance of my account was a single value of 1.00BTC. If standard tx were highly simplified, it would save a whole lot of disk space and a whole lot of trouble.
Another thing that could be done, is that for p2pooling, rather than storing the whole blockchain each miner could store the latest ~4032 blocks (28 days), plus a random 4032 block "period" from the last 13 periods of 28 days (ie 364 days of blockchain total). When the extra period a miner is holding expires, they simply replace it with the latest 28 day period that would otherwise be discarded. Along with the ledger system, that would allow miners to run on less than 1/4 the size of the current/total blockchain, and they could still seed it to any clients requesting it torrent style. Really only a year of blockchain is needed for security reasons. Older sections only have historical value for those wanting to prove that the initial block rewards really are what the wiki says they are. As per the link above, a client would only need to store ~2016 blocks and a ledger, which amounts to even less total size.
As for the "government attack", that can only be avoided by improvements to the protocol itself and tightening of the blockchain validity criteria. For example replacing BTC's highly subjective "network time" with an NTP, perhaps merging with NTPool should allow latency-adjusted network time to be kept accurate to within less than 1 second. With some heuristics to prevent attackers from inventing the current time easily along with block timestamp restrictions of maybe 10 seconds, timejacking and block hoarding attacks would be nearly impossible, and certainly impractical since the window for double spending would be only seconds.
Above and beyond timekeeping,
Meni's Proof of Stake system allows for checkpointing to be done often such that blockchain reorgs have a maximum depth that can be kept to ~24h. It would probably be very difficult to implement from the current protocol, but it would make the whole network very "sticky" to the current most-accepted blockchain, giving even the most effective attacks a very limited ability to do damage. At most the network would be disorganized for the period of the attack, but older historical parts of the blockchain and their associated tx would remain firmly in place.
If some attacker were to spam a fake blockchain, on the other hand, it would only affect new users or machines where the BC had not been downloaded yet. Unless said attacker were prepared to completely blind said user to the internet at large, there would be some noticeable problems for the client in using the BTC network. For example, if the blockchain they downloaded was fake, and then they go to receive coins from a legit part of the network, the blockchain info they had would not match the transaction received to their account, and they would see it as invalid. Obviously, the only way around that sort of attack is to download the blockchain from an alternate source. Given the relative ease of supplying a reliable copy of the blockchain via various methods, and the difficulty of censoring all of them, the payoff vs resources required for such an attack would be mediocre at best regardless of the intent.
