I just pushed a new version to github that contains a 'removeprivkey' that requires the *private* key to be removed to be passed.

It is untested for now, so use at your own risk. It should remove the key and irrelevant transactions from the wallet, the address from the address book, and from the key pool. It will not be removed from accounts (yet).

Nice!

It has nothing to do with security. To reverse part of the chain, you always need to do at least as much work on average as was put in the part of the chain you're trying to revert, whether that is 1 block or 1000 blocks.

The 1 block per 10 minutes rule is a compromise between usability and chance for stale blocks because of network delays.

It first tries to find a combination of input coins using only coins with 6 confirmations. If that fails, it tries using coins with at least one confirmations. If that also fails, it tries again not requireing any confirmation from coins created by yourself (i.e. change, or send-to-self).

Within each pass, it tries to minimize the change approximately.

Also, when using sendfrom, all coins in your wallet are always considered, as coins never belong to a specific account.

I chose something similar to addresses because the code was available, it had a checksum against typo's, and 51 characters seemed reasonable enough to bother with implementing something else (base64 being 48 characters with the same level of checksums).

I'm not that sure the codes relies on LE that often. The serialization routines for integers, uint160, uint256, and the fact that pointers to those structures are passed directly to hashing routines, would need to be adapted. That does seem reasonable (though not high priority) to change, unless there is a ton i'm forgetting now.

The block header is 80 bytes, which is padded to 128 bytes. The first 64 bytes of these are processed outside of the nonce-iteration loop. Whether there are 4 or 8 variable bytes in the second 64 bytes makes hardly any difference,  i believe. Maybe a few % on very optimized implementations.

Account balances have *no* relation to which coins are available. Coins are always selected from the total pool your bitcoind knows about, accounts are just an accounting tool.

Your total balance (which is the sum of all available coins) will always be positive, and if the client is able to create a transaction, it will be valid (though it could be a double spend, in which case it won't confirm).

In short: just keep your client open and connected, and a wait a bit; the transaction will confirm. The fact that it is slow has nothing to do with account balances in your own client.

Bitcoin transactions do not have a from address.

There are coins used as input for the transaction, and those coins could have an address they were previously sent to, but that is not even required by the protocol.

If you need a way to know who sent you coins, make sure you give a different address to everyone, and look at which address they transaction was sent to instead of from.

This is a bug - automatically generated addresses aren't added to the address book it seems. Don't worry, they're still added to your wallet and you should receive the funds.

Eh no, not yet...

There is no rule that the best chain is the one with the most blocks. It's the one with the most statistically expected number of hashes to have been performed by it.

The average number of hashes that have been performed for a given block is 2^48/65535*difficulty, or 2^256/target. Whether it is a hash much below the target or very close to it doesn't matter. Each attempt for that block had an independent chance of target/2^256 of being good enough, and good enough is all that counts.

Yes, you could move to another definition where you count 1/hash as value of a block, but the only thing this will cause is much more reorganisations, as a block that the majority had already agreed upon may be reverted.

Now there are two interpretations of your proposal: if you simply count the value of a chain as the sum of (1/hash) for each block in it, you could relatively easily create a block that reverts the past 100 blocks, causing much more reorganisations. The other interpretation is still letting the chain with the highest expected number of hashes win, but look at the 1/hash for the last block only for deciding which to pick. This is much more reasonable, but it doesn't gain you anything: instead of letting the majority of the network decide which side of the split wins, it becomes essentially random.

No, only when you have run the program.

Each hash on itself is as hard as any other. The number of tries you need is proportional to the difficulty you had while hashing.

See https://en.bitcoin.it/wiki/Data_directory

Wallet.dat contains your personal keys and transactions - it is created and maintained by the program, not packaged with it.

wallet.cpp and wallet.h are source files for the program that manage the wallet.

The value of the block's hash is not a good measure for the amount of work that was necessary to produce it. The target is.

The weight of a block comes from its difficulty - namely the hash value it had to beat, not the actual value it had.

Since the difficulty is adjusted only every 2016 blocks, all blocks within a 2016-block section have the same difficulty.

If there is A->B, and someone finds a B', it will almost certainly (except on the 2016 block boundary) have the same difficulty as B, and not force anyone to switch. The switch only happens when a C would be found as successor to B' before a successor to B is found.

The point is simply this: if 95% of the network (measured by computing power) thinks B is the successor to A, B has 95% to be extended first, and thus has 95% chance to become part of the final chain.

This assumes that the address is controlled by the user and not some e-wallet, and that he will keep its corresponding private key for eternity. That's a pretty strong requirement.

There is one rule only really: only send to an address you know the owner wants you to.

Bitcoin transactions do not have a from address. There is only optionally some identifiable address the used coins were last sent to, but you shouldn't rely on that. The client does not show you because it is a fallacy to think that bitcoin transactions have a return address.

The longest chain is defined as the one with the most proof-of-work.

Technically, the "length" of each chain is the sum of (2^256 divided by the block's target) for a given block plus all its ancestors.
This number is the statistically expected number of hashes to have been performed in the chain, and is currently equal to about 4.1e19 (41 billion billion).