Rebased against master, a few bugs fixed, and split off into separate source file.

TODO: known wrong balance cached when importing keys

Sorry, yes, this is a known bug. It happens for 1 private key in 256. I'll fix it soon.

You cannot, in general, assign balances to addresses. One transaction output can be usable by different private keys, or a combination of a certain number of keys, or by anyone at all.

If there is a transaction output with can be spent by address X and Y, this amount is shown by the clients of the owners of the private keys corresponding to both X and Y. As soon as one of them spends it, it is removed from both balances. This has very interesting - and unexplored - possibilities for escrows, but has a disadvantage that you really shouldn't think as bitcoin keeping balances for all accounts, it's not true and it's not possible. Bitcoin transactions directly refer to other transactions they consume, and that is fine.

No, but the minimum fee required in case it is considered "spam" was decreased to 0.0005 in 0.3.22 and to 0.0001 in 0.3.23.

The reason is a limitation in most currently active nodes on the network, which block (do not even forward) transactions that look "spammy" (too large, using too recent funds, or too small outputs) if they do not carry a minimum fee. We've been decreasing the minimum fee the past few versions, hoping to move to a more flexible scheme somewhere in the future. However, for some transactions now, if they do not carry a fee, there is a chance they will not be relayed at all by the network, effectively placing your coins in limbo. As a protection for the user, the client will not send without a fee in such cases.

first or last 32 bits of the double sha256 checksum of everything before.

Assume 1% lost coins per year. Probably, it was a lot higher initially, but we're talking from now on.

That means it'd take 229 (log(0.1)/log(0.99)) years before we lose one decimal of precision.

How is that different from anyone else making a legal profit of $3000, and using that to speculate on bitcoin trading?

The miner only sees the block header - the client remembers which block contents (=transactions) match with it. Since you need to know which transactions to add to it, you need the bitcoind that gave it to you. Furthermore, the header depends on all transactions in the block, so if you'd add the wrong ones, the header wouldn't be valid anymore.

Short answer: no

I'm not going to argue about what is the right thing to do, but If I add the numbers in that file I get 237457.099 (237k BTC).

The bitcoin block chain is not intended as a payment processor - it is a worldwide scheme for obtaining consensus about the flow of a currency.

You can easily build payment processors on top of this, which either do transactions internally, or provide assurance against non-confirmation and block chain splits, for a cost.

No they just keep a map of all unspent transactions.

Suggestion to improve upon all concerns, making sure each and every crack attempt requires: 1) iterated key strengthening 2) AES decryption 3) EC point multiplication 4) RIPEMD160+SHA256 hashing:

Master keys are stored using a db record:

• KEY = ("mkey", id)
• VAL = (salt, iterations, AES(key+iv=KeyDeriveSHA512(passphrase_id, salt, iterations), data=masterkey))

Wallet keys are stored using a db record:

• KEY = ("ekey", versionByte_n, RIPEMD160(SHA256(pubkey_n)))
• VAL = AES(key=masterkey, iv=RIPEMD160(SHA256(pubkey_n)), data=privkey_n)

Both legitimate access and crack attempts need to (for each mkey entry, until a match is found):

• perform iterated key derivation from the passphase and the mkey's salt, to find key/iv for the masterkey
• Decrypt an ekey's data using it
• Do EC point multiplication on the decrypted privkey to find the pubkey
• Hash the pubkey twice
• Compare this hash with the ekey's KEY

Depending on which encryption algorithm is used, RIPEM160(SHA256(pubkey_n)) may not have enough bits to use as IV, but I'm not sure to what extent that is an issue. Alternatively, a much shorter identifier-based ekey KEY can be used, making it even harder to verify a passphrase is correct (you'd need to go looking for transactions matching the given address and so on... this would be so fuzzy that some checksum-based verification mechanism would need to be put in place, making cracking a bit easier again as well). Another alternative is adding a additional nonce to ekey's VAL, used as IV.

The reason for "versionByte_n + RIPEMD160(SHA256(pubkey_n))" in the ekey's KEY, is that it matches addresses, and could be used in the future when the entire wallet isn't loaded from disk anymore. This is probably not really an issue now.


EDIT: as public keys are stored unhashed in several places in the wallet file anyway (txouts, keypools, ...), an attacker does not need to always do the RIPEMD160(SHA256(pubkey)) operation to verify correctness.

gmaxwell: You are right. With the current proposed system, if you have a large table with (scheduled) AES keys derived from many popular passwords, the work to attempt a crack is a single AES decryption per wallet and per passphrase (as the current serialized privkeys contain a pubkey, only a comparison with the known pubkey must be tried after decrypting).

With Gavin's suggested improvement (only storing the private parameter instead of the entire serialized key), this becomes 1 AES decryption + 1 EC point multiplication. If the ekey's key is modified to have the address instead of the pubkey (as Gavin seems to imply), an addition SHA256 and RIPEMD160 hash are required to verify correctness.

With my suggestion to use a separate masterkey, it becomes 1 AES decryption of the master key, 1 AES key scheduling, 1 AES decryption of an ekey, 1 EC point multiplication.

Neither of these schemes take advantage of the key strengthening performed by EVP, as it can be done in advance (for simple passwords only).

I agree - I've suggested storing only the private parameter before, but didn't realize it would also make bruteforcing harder.

While we're at it, I would like to suggest using a master wallet encryption key, itself encrypted using the passphrase/keyfile, instead of directly using the passphrase-derived key for encrypting the wallet privkeys. This would make changing passwords a lot easier, and you could eg. have more than one valid passphrase. It would also make it harder to corrupt your wallet when doing as, as you could do a (add the new passphrase, commit, remove the old passphrase, commit) sequence, with at each point in time at least one of both passphrases capabable of decoding the entire wallet.

Also things like a "Generate unlock string" wizard in the GUI that creates a new random passphrase, and shows it to you with the suggestion to print it on paper and store it in a safe location, would be possible. Such an idea would probably need some discussion, but with a single key that is tied to a single passphrase, i feel we're limiting our options.

Currently there are rules that require certain transactions (not all, only spammy ones) to carry a minimum fee before it is even relayed through the network. In 0.3.20 and 0.3.21 this minimum is 0.01, in 0.3.22 it is 0.0005, in 0.3.23 it is 0.0001. We're looking for better schemes that do not have such a fixed limit, but for now some spam prevention is necessary. The rules used for creating transactions are an overestimation based on which clients/rules are in use in the network - we don't want transactions that linger forever before being confirmed.

The wallet.dat file is indeed a berkeley database with key/value pairs. It contains private keys, known addresses of others, transactions crediting and debiting you, account information and configuration settings.

If you did a transaction with low fees, the best suggestion is to keep the client open and connected for some hours. As it will occasionally retransmit, it should eventually reach a miner.

If you want to play around with the wallet.dat file yourself, there is Gavin's bitcointools, but I'm not sure what it supports. A possibility for undoing transactions may be added to the client itself somewhere, but not very soon - there are quite serious implications, as it may cause double spends, and wallet situations that are hard to recover from.

If you want to do things manually, there should be a data pair in your wallet.dat where the key is ([hex 02] "tx" [32 bytes containing tx hash]). If you remove this, the transaction should be removed from history.

Nice improvement - I've merged it in my branch.

If you really want to mine on a CPU, please use cpuminer or another specialized program that is efficient, optimized and supports pool mining. The miner left in the default client is only intended as a reference and for testing.

Shares are how pools keep track of how much work every miner did.

The work they send you are valid and real bitcoin data. As defined by the miner algorithm, your system will report back any nonces it finds that make the integer value of the resulting double sha256 hash low enough.

To be a real block, the hash (when written in hexadecimal) must currently be lower than:

  0000000000001321850000000000000000000000000000000000000000000000

When you're mining in a pool, the servers asks you to not only report real blocks (as those are very rare), but also to report almost-blocks, whose hash value is only below:

  0000000100000000000000000000000000000000000000000000000000000000

These almost-blocks are called shares, and are significantly easier to find, but most importantly, they also include the real blocks, which is were pools get there income to distribute from.