Standardization is not intended to make public parameters implicit... it is intended to make its format compatible between different implementations.

I think you misunderstood me. Internally, the scheme uses 512-bits keys (so its master is this large), but as secp256k1 (the elliptic curve used by bitcoin) has only (a bit more than) 128-bit security anyway, there is no need to use (much) more entropy for generating the master. One possibility is using master=SHA512(seed), where seed is a randomly generated 128 to 256 bit value. This seed could be converted to (or generated from) a human-readable string, if a nice standard for such a conversion can be agreed upon.

Recent versions verify all wallet keys for consistency at load time, and fail rather than silently ignore it. You probably have one or a few inconsistent keys in your wallet file, which went undetected for a longer time.

I have a not-very-well-tested patch for bitcoind/bitcoin-qt that tries to reconstruct inconsistent keys, or otherwise ignores errors. It will not fix the wallet file, but it may be enough to access it.

Let me know if you're interested.

I've been working on a specification for deterministic wallets, to be included in the reference client (and Armory might adopt it as well). It is a bit more complex as it (optionally) supports multiple independent keypair chains, for different accounts and for public and non-public addresses.

It uses a 512-bit master key, but could very well be generated from a seed of only 128 or 256 bits of entropy (this is not yet specified). My preference would be having this part be generated randomly, to prevent weak user passwords resulting in entire wallets being exposed.If a nice standard can be agreed upon for converting such an amount of entropy to a human-readable (and hopefully rememberable) string, it could function as a very nice brainwallet.

The current draft can be found here.

I misread - I thought you wanted to include it as secondary inputs to the coinbase transaction. Still, the coinbase is limited to 100 bytes. It will be very hard to put two full transactions plus an extra output in there...

This is not correct. Old nodes will not accept a block whose coinbase has more than one, or non-empty inputs.

difficulty * 2^48 / 65535, actually

I have a patch scheduled for 0.7.0 that allows you to import a blk0001.dat file directly, as if downloaded from network. If the file contains blocks besides those in the main chain, those will be imported as well. (what is called orphan blocks in the client is something else: that are blocks are were never connectable to the known chain, and are only kept in memory).

There's no way to access data that is not in the main chain through the p2p protocol, though.

I really doubt the problem was a lack of connections here. There have been problems with the blockchain getting stuck, and there may still be such bugs.

If bitcoin becomes larger (including more non-relaying light clients, more people behind firewalls and NATs, ...), the solution is encouraging people to be reachable (UPnP, opening ports, ...), so that enough "connections slots" (number of reachable nodes * number of connections they accept) exist in the network for everyone to connect to. Increasing the number of outgoing connections will have the opposite effect.

Yes, you can backup blk0001.dat and blkindex.dat from the same direcotry, and restore them there before running bitcoin again.

This should prevent you from needing to download the chain again.

Make sure Bitcoin is not running while making the backup.

Use getblockhash <height> to get the hash of the <height>th number in the main chain.

I guarantee you, nothing changed in the fee policy since 0.3.23. Whether a fee is required or not depends on the size and age of the input coins you're using.

Fees have always been voluntary, except in case of sending very small outputs, or using too recent/too small inputs, as a means for spam protection on the network. The details of this policy have not been changed since 0.3.23.

You can see it as an implementation error/feature, but the protocol was (and still is, largely) defined by how the reference client behaves.

The only way to change it is if *all* users of Bitcoin agree - not just 51% and not just miners. Imagine we pushed a new version of the client with a spendable genesis block. Assume 70% of miners upgrade, and suddenly Satoshi reappears and spends the genesis block. Those 70% would start building a chain with the spend included, but older miners and nodes would not accept this chain, to them it would be invalid. The result would be a permanent fork, with 30% of mining power behind it. People using old clients would notice a decreased block speed (and some other security measures would get triggered), but apart from that, they keep living in their own little world. Such a permanently splitted blochchain is a recipe for disaster: every old coin that existed before the split can be spent once on each side of the fork...

When a new node starts up, it initializes its block database with the genesis block, and then start synchronizing. However, it does not add the coinbase transaction from the genesis block to the transaction database. Hence, no client has that transaction in its database, and no node will consider spending it valid.

This may have been intentional by Satoshi, or a bug, but we certainly can't change it now.

It may have huge historical value, but note that the coinbase from the genesis block can actually not be spent.

We were still deciding on what the next version would be, and what its goals would be.

Next version will probably be 0.6.1, and include mainly cleanups, bug fixes and other small improvements.

This is certainly not true. Miners do not have absolute authority over bitcoin's rules. In fact, they exist only for one reason, and that is the only thing they can decide: they ordering of transactions. They decide over bitcoin's history in the global ledger, but can only accept otherwise valid transactions into it. They have the power to postpone transactions, possibly indefinitely, but cannot change the rules that make a transaction or a block valid.

There are some rules that are fixed. Obviously, they could be changed if 100% of users and miners alike agreed to, and every single one would upgrade. But that doesn't surprise anyone, I hope. Among the things that cannot be changed is the maximum allowed miner subsidy (which is current 50 BTC per block, and halves every 210000 blocks), or the structure of transactions.

Firstbits is essentially a scheme for registering a short name for a static bitcoin address. So far so good, but it uses the blockchain to store the registrations. This encourages spamming the blockchain to be the first to use a particular prefix, and is not compatible with pruning (consuming the outputs of the first transaction that used a particular address, may change the firstbits mapping). This problem can be avoided by keeping a separate database of each prefix along forever, but at that point it has no advantages over a third party registration system for address aliases anymore.

Furthermore, it enforces the notion that a single static address should be tied to an identity, instead of using a new address for each transaction. Almost by definition, since a firstbits mapping is intended to last forever.

For these reasons, I would not accept such a patch for the reference client.

No, it just uses whatever node is the first that tells you about a new block. That is almost always the first node you connect to.