This can also be done from the debug console since Bitcoin-Qt 0.7.

If you want to distinguish separate incoming payments, the advised way is creating a separate receive address for each.

Bitcoin transactions do not really have 'from' addresses. All transactions do is consume coins, merge and split them, and produce new coins, potentially assigned to new address(es). It is indeed possible to retrieve where the input coins for your transaction were previously sent to, but in the general case this is not very useful information, as it only tells you which address previously controlled the coin, which is not necessarily the one who sent it. In the case of e-wallets with shared wallets, for example, it only tells you an address that belongs to the provider's wallet, and sending something to it will not necessary mean it ends up on the account of the one who sent it. If you want to do return payments, ask for a return address.

My faith in humanity would be lost if this helped in the slightest.

All those things require a preimage attack. The only practical attack against MD5 is a collision attack.

Does that matter? Any change to MAX_BLOCK_SIGOPS or MAX_BLOCK_SIZE has hardforking risks - making one dependent on the other does not change that.

i've submitted a pull request with comments for all those constants.

COIN is defined in util.h, apparently. I assume because it's necessary for formatting amounts.

See that "Add recipient" button?

Maximum size of a block in bytes, as specified by network rules.

Maximum size of a block that will be generated.

Maximum number of signature checking operations in a block, as specified by network rules

Maximum number of orphan transactions kept in memory; old ones are deleted when this number is exceeded

Maximum number of entries in an "inv" protocol message

Maximum size of a block file (new in 0.8 )

Size of preallocation chunks in block files (new in 0.8 )

Size of preallocation chunks in undo files (new in 0.8 )

Special height in CCoins to mark origin is mempool (memory only) (new in 0.8 )

Fees below this (in satoshi) are considered zero fee for purposes of block/tx creation

Fees below this (in satoshi) are considered zero fee for purposes of relaying

Maximum amount (in satoshi) allowed anywhere. COIN is equal to 10^8

Coinbase transactions cannot be spent before this number of confirms

Who do you assume deepbit is responsible for this? Blockchain.info shows who relayed a block first, not who mined it.

Actually, the one reason why I like coin control GUI's, is because they give users insight in the system. More transparency and understanding are a good thing if you want to want people to trust the software and the system in general. This is for me enough to vote for including it, if it gets implemented properly. I'm not a GUI programmer myself, though, and have other priorities.

However, and probably contrary to why most people want this feature, I believe it's a bad thing from a usability point of view. Privacy shouldn't require people to micro-manage individual coins in a wallet. If the software too eagerly links coins together (and it does), the software should be fixed. If people want to prevent several sources of income to be linked entirely, the software should provide easy multi-wallet support (and it hopefully will, in a not too distant future). Both of these are far more important for the end-user, in my point of view. That said, no problem with providing the expert user an expert mode that allows micro-management.

SPV does not mean verifying transactions. It means verifying the block headers and their proof of work, and verifying that the claimed transactions do in fact belong to the blocks. It does require some trust, in particular it relies on the majority of mining power creating valid blocks, but indeed far less than just randomly trusting a central server.

It does not report averages, it reports estimates.

The problem with a 30-day average, is that it on average reports data that is 15 days old.

The graphs shown use a limited extrapolation to estimate the current hash rate based on data from 30 days ago (and other window sizes). If the hash rate seems consistently rising, it will report numbers that assume this rising continued.

Either run bitcoind, or bitcoin-qt. You can't run both at once (well, you can, but not out of the box, and it won't do what you want)

For those who are interested, I've created test binaries of the current development code.

Use with caution - several bugs were already fixed, and there are probably some left - so don't use for mining or merchant purposes.

The auto-import system is not yet implemented, so please run on a clean data directory. There are still issues with the inital block downloading, which require another major refactor to fix entirely, and with the recent improvements, those may now be the limiting factor. Use -connect to a trusted/local node, or use -loadblock or bootstrap.dat for initial sync, if you want to see the full potential speed.

The binaries are here. Use at your own risk.

That is done in a completely standard way.

Except for the fact that its hashPrev is 0, the genesis block is not special at all.

Indeed. I do plan to add an optional index for people who want such functionality.

It is already the case because the current code does not maintain an index of all transactions anymore - in normal working conditions there is no use for such an index. Since it is still very useful for debugging, I'd like to make it optional to maintain such an index.

Why do people today run a full node like Bitcoind or Bitcoin-Qt when they could run an SPV node like MultiBit or not a node at all, like webwallets or Electrum?