Go to Start -> Run (or press WinKey+R) and run this:

I keep the Bitcoin data directory unencrypted, but symlink wallet.dat into a Truecrypt volume so I can keep the volume small. (Windows does support symlinks.)

1GB would be reasonable if you want to keep the entire data directory encrypted.

Maybe "selling" and "buying" should just be renamed to "want BTC" and "have BTC" or something.

Does Bitcoin actually die, or does it just hang?

Did you change Bitcoin versions?

Does debug.log say anything about it?

No. There's nothing you can do.

IP detection is broken for some reason. It's seeing everyone as being from the same IP. I removed the restriction for now.

It's queued, but low priority. There is no fee. See:
http://bitcoincharts.com/bitcoin/

The hash is:
CTransaction(hash=91d1df25b4, ver=1, vin.size=5, vout.size=1, nLockTime=0)

There actually are inputs ("CTxIn"). I'm not sure why they're not listed separately under "Inputs". Maybe inputs are only listed there when you're sending a transaction.

Only a handful of trusted people need to come to an agreement about the block chain contents unless there is any significant disagreement about it. If there is disagreement, it might take a few days to reach consensus. Speed doesn't seem that critical to me, since it will still take some time for everyone to upgrade once an agreement is reached.


I can't think of any fairer way.


I was thinking just one hash for the entire thing. Maybe the "previous block" field in the version genesis block will be a hash of all the hashes, or the root of a Merkle tree.


I'd like transactions to support specifying the hash type used. That would allow people to choose their own security. Slower algorithms might require higher fees.


Bitcoin will already detect the case where new block/tx versions have the majority of the network. It will say:
RPC is also shut off, so all Bitcoin sites will stop working.

We'll have a discussion here and on IRC. Whoever controls bitcoin.org makes the final decision about what is listed there, and if other people disagree, they will advocate different versions on their sites.


We'll come to some agreement about it at the time. I'd advocate removing all blocks where it is likely that most transactions are illegitimate. Most legitimate transactions can be reversed without doing too much damage, since honest senders will make new transactions.


At least all block contents should be hashed. Maybe later a hash of a "balance sheet" of only unspent transactions could be created for the sake of efficiency. These would be version 1 blocks, and later blocks would be version 2 (likewise for transactions). Perhaps the first version 2 block would refer to this hash instead of the previous block hash.


If SHA-256 or RIPEMD-160 is broken, the key isn't necessary. Miners memorize the contents of unspent transactions, indexed by the new secure hash. People who want to spend a transaction refer to the new secure hash instead of the insecure hash.

If signing becomes totally broken, Bitcoin would probably have to restart. If the attack does not allow recovery of the private keys, maybe the same keypairs could be used with a more secure algorithm.


Yes.


An alert will be issued.


Most likely.


Creating a complete plan and testing would be good.

Post the tx dump.

Restored. The rules state:
There is no trading in this thread. This is the basis on which Silk Road threads were also allowed.

We'll come to an agreement as to the content of the blocks, hash them all with a secure hash, and hard-code that into Bitcoin.

Did you delete all other files in the data directory before restoring wallet.dat? Maybe those files are corrupted.

As I've said before in other threads, I believe Namecoin will inevitably fail because its economic model is broken. So I won't support it.


I don't want to make my code public now. Maybe later.

Those are valid. Check that you're not copying any spaces or other invisible characters. If not, the sites are broken.

That'd be great!

Automatic updates make things way too centralized, IMO.

Gavin should have an alert key, though, and an alert should be issued for every new version.

You can't prune unspent 0-value outputs because they can be redeemed, even though this would be useless. You can't necessary prune unspent known-to-be-data outputs because the script can both contain data and be redeemable.

Detecting data transactions based on entropy would be error-prone, since true randomness has a chance of being apparently low-entropy.

Deleting redeemable outputs is dangerous, since you could end up in a situation where you need the output to verify a block, but none of your peers has it. No matter what you do with the block, you might end up on a separate chain.

If we really got stuck that badly, a new version of Bitcoin would be released that changed the difficulty rules. I doubt it will ever be necessary, since an attacker would need a ton of computational power, and the build-up of transaction fees would incentivize increased mining.