Enjoy your purity. I'll enjoy my $48.60 in leftover money.
Every man has his price. Now we know yours.
And when the government comes for the undesirable neighbors (currently the poor "drug abusing" minorities and people of middle-eastern descent), no one will be able to see the police brutality and rights violations! Everyone wins!
I honestly can't think of any detriment to having neighbors with spy drones. They send spy drones onto my property? I'll send my own drones to track theirs and watch them watching me. If it's amusing enough I'll probably document the whole thing on a public website. Privacy is *dead*. Privacy was not one of the features of our ancestral environments. Tolerance and acceptance are the way to deal with each other, not hiding.
I actually worked on the effect of plane crashes on a nuclear power station. The answer is that the effect is not a lot safety-wise other than the "conventional" killing of people standing around. There is a massive amount of concrete around a reactor, and indeed the spent fuel ponds. If you are going to crash a plane you can cause far more deaths by randomly crashing into a city - an easier target ot hit too. Perhaps I should not be saying this though.
Or, like Fukushima, the plane might sufficiently damage the surrounding infrastructure so that cooling fails for a significant amount of time.
Long story short, if you share the set of unspent transaction outputs in a DHT you have to trust every other computer in the network to actually return the DHT data when requested, or you suddenly you can't validate a block. This opens Bitcoin up to dangerous DoS attacks against miners, as well as network forks and other problems.
First, there have been fairly successful experiments preserving a DHT on a set of unreliable nodes using (n,m) error correcting codes to store multiple fragments of blocks on different nodes so that the DHT itself can survive a ratio of up to n-m out of n nodes leaving the network. Most likely the bitcoin block chain is too large and too fragile to do that effectively without choosing n so large that calculating the error correction codes would be too burdensome or m so low that you get nearly O(N^2) behavior anyway. Leaving the storage of transactions up to the nodes that care about them makes sense in this case.
Second, it's not necessary to keep the entire merkle hash chain in the DHT and in fact only the path from the current root down the branch to the original leaf is necessary to validate the entire tree with a proof of work at each level and can be stored by each node. It's just as easy to DoS miners by preventing them from receiving the latest blocks and pending transactions. Nodes that want to complete transactions have to do the work of getting their pending transactions to miners in the current protocol. It shouldn't be too much of a burden on those nodes to also provide their own transaction history to the miners.
Something I didn't think about long enough was the ability to prevent double spending; it's necessary to build an index of the most recent withdrawal from a given address (at least, although an index to the most recent transaction would work too) and each transaction must include the hash of the immediately prior transaction so that no transaction can be dropped from the hash tree. This can be accomplished by keeping a b-tree index of the hash blocks pointing to the most recent transaction ordered by address and only storing the newly required blocks of the b-tree in the hash block chain. Each b-tree block will be hashed into the merkle tree block chain to validate it. Addresses which don't appear in the index are assumed to have a zero balance. The b-tree index should take roughly O(n log n) in the number of addresses ever used, and lookups should be O(log n), and again the node that cares about an address will have an incentive to store the necessary index blocks or else risk having a zero-balance address. Because an address owner relies on the entire branch from the root of the index to its last-transaction pointer all nodes will care about and keep the root index entry, most will care about the second level, etc.
The dollar has one significant difference: the government requires that you use it to pay taxes. This forces nearly everybody to value the new dollar, which forces everybody to move to it.
If the world economy switched to Euros or Yen or Canadian Dollars tomorrow there would be U.S. Dollars littering the streets that one could use to pay taxes with. Of course, there might be a bit of a question of the exchange rate that should apply for taxation of other currencies if no U.S. dollar was ever spent again, but presumably it would work for the current accounting year. There is an actual, real demand in the World market for U.S. dollars, and not just to pay taxes.
Never mind that Bitcoin is inherently an unscalable O(n^2) network - every transaction has to be broadcast to every node
It may be possible to store the block chain as a distributed hash tree such that each node is responsible for maintaining its own transactions and a portion of the block chain. This would reduce the storage requirement to O(n*m) where n is the total number of transactions and m is the average number of addresses that appear in a transaction. Communication would also be reduced to O(n*m) because only nodes responsible for the addresses in a transaction would be responsible for checking and approving the transaction. The block chain itself would just be a merkle-tree of hashes of nodes' own block chains. Double-spending would be prevented by transactions incorporating the last hash of each responsible node's block chain so that an individual block chain exhibiting double spending would not be signed into the merkle tree. It would be possible for the history of particular coins to be lost but the overall hash tree would guarantee that at the time of a transaction all balances (including historically lost ones) were valid. Still, not being able to validate the entire economy could be a fairly large weakness. There wouldn't be a hard requirement that nodes could only store certain addresses, so it's entirely possible that some nodes would still try to collect and maintain the entire history. That would only add O(n*p) communication and storage where p is the number of full "archive" nodes. Of course then it wouldn't really be bitcoin anymore, but it might be possible to rebuild the existing block chain into such a structure while retaining the current mining payouts and total number of coins.
I really wonder if my Bitcoins will be worth anything in a few years.
Something, because there will always be some core of crazy people running miners and keeping the difficulty just high enough that it's not worth it to mine as many bitcoins as you want in the original chain. That value will probably be the cost of the electricity to run whatever the last ASIC miner produced is, at least before general purpose GPUs become more powerful than ASICs.