Except that loans really do make money out of thin air.

Create a new wallet with entirely new keys.  Transfer your entire balance to one or more of the new keys.

The reason it can't be pegged is because no one can create more of either one at will.  This is also the reason that both are better than cash.

Your anti-gold rant is laughable, mostly because of the missed commonalities and false differences.  Let me illustrate.

We already have a global system for moving arbitrary data over various media.  Even pigeons.

Oh, and the problem isn't so much in the downloading of the blocks as it is in the processing of them.  Each node must process each block.

I haven't seen anything browsable, but they do happen, and they are generally resolved within 1 or 2 blocks.

Nonsense.

At this point, I don't think that any one person has looked at all of the code.  But, for any given section, several people have looked at it.

And there are quite a few people that inspect each and every change that gets pulled into the main branch.  An actual attack would need to be very subtle to get in.

Use the flex proxy.

I use the flex mining proxy, plus a custom reboot system.

Not straightforward at all.  The USD to BTC ratio and the difficulty most likely form a complex system.

Pretty much.  Over several weeks, BTC Guild has paid me pretty much exactly what I expected based on my hashing rate/return calculations.

I don't think he's selling them.  You'd need to learn VHDL and negotiate with a foundry yourself.

It would make more sense to fix the miners to accept whatever difficulty the pool requests rather than the other way around.

I'll bet you 1 BTC that the change does not happen during that second.   

Ha!  You missed a couple of key steps in the security shorting process.

First is the shorting pool at the clearing house.  Say you want to short a stock.  Your broker borrows them from a pool and gives them to you.  You then sell them to someone.  That buyer has no idea that they just received borrowed stocks, and they think they own them.  So, the buyer's broker holds them, and makes them available to the pool so that the next guy can borrow them again.  (Side note: shares include voting rights, and now at least two people think they are allowed to vote, and all but one of them is wrong.)

Second is that the pool is totally unnecessary, since a broker can just fail to deliver (FTD) the shares.  They are supposed to settle all trades by day T+10, but for most brokerages, there is no rush, because:

Third is that there is almost never a downside for letting a transaction go into FTD status.  No jail time.  No fines.  Rarely a sternly worded letter.

Divide the current block number by 2016.  Subtract the remainder from 2016.  Your answer is the number of blocks between now and the next retarget.

Why do you want 64 bit binaries?

What if we just made it harder to swap in a new branch of the chain the deeper the branch goes?

The criteria for deciding which of two chains is correct is that the one with the highest difficulty is the real chain.

Say we kept that criteria, only when the number of blocks we would have to replace (call it Y) is a small number, like 4 or 5 (call it X).  Also call the current difficulty D.  But, if Y is greater than X, we require the difference in difficulty between the two branches to be (2 ^ (Y-X) )*D.

Honest block races would still be resolved normally, as long as X was chosen appropriately.
The difficulty of retroactively forking the chain would grow exponentially the further back the fork needed to be to meet the attacker's objectives.

The only downside is that this would introduce a very tiny chance of a network split causing a fork that could not be repaired using ordinary means.  Note that the network split capable of causing this fork would be very, very unlikely, since it would need to be complete, nearly evenly split in terms of hashing power connected to each side of the split, and somewhat long lasting.

The syntax is different.  Try this (lifted straight out of db-postgresql.c):