A wallet does not contain any coins - it cointains the private keys necessary to spend them. The information about the coins themselves is stored in the network.

If you use the same wallet in two places, the first to spend it, gets it.

With block 127430, the total number of hashes estimated to have been performed as work in the block chain surpassed 10^19, or 10 billion billion hashes.

This may look like a large number, but at the current hashing speed, it would only take around a month to redo all that...

That's exactly what exchanges will do, and already do.

Early adopters do not necessarily get rich - they only get rich if they saw the exchange rate increase and didn't sell, from the very start to that hypothetical future moment resist the temptation to cash out and risk losing something or everything.

Also, in general I agree a somewhat better introduction rate function could have been chosen, but I'm far from convinced what a better rate would be.

An outgoing transaction that you created yourself, or one that was found on the network or through rescanning?

Grey can mean it depends on a transaction that is not known.

There's already a patch to fix it, see https://github.com/bitcoin/bitcoin/pull/276

This patch is superceded by http://forum.bitcoin.org/index.php?topic=8091.0

It is not merged yet into mainline.

If you are using 0.3.21 or later, this should work. You'll possibly need to wait until the blockchain is downloaded on the other computer though.

If you are using 0.3.20, you need start that the bitcoin program with the -rescan command-line option.

If you are using an earlier version, upgrade, and use -rescan.

See https://github.com/sipa/bitcoin/commit/5e1e458ecb0f5d8e42e1a7fc3b8f9e1d37f52e46

I changed it a bit to match the coding standards, and removed the if test before the while loops.

Which name do you want on it?

One upon a time, people will be telling stories about some fool who paid 10 billion UBC for a pizza!

I like it!

DNS does not completely replace IRC, as its database can only be updated by the maintainer, not by everyone.

However, nodes also pass known addresses (including port, even with IPv6 support) to eachother. So DNS bootstrapping is just bootstrapping, finding *some* node, that knows other accessible nodes.

1 "hash" is double-SHA256 applied to a block header. Because some parts can be pre-calculated, and some parts ignored for our application, it is in reality equivalent to processing approximately 1.9 SHA256 blocks.

There is an easy relation between difficulty and block rate. For each block the network finds, on average 2^48/65535 (=4295032833)  times the difficulty hashes have been performed.

There is a relation between the difficulty and the network hash rate as well, assuming you know how often a block is found. Assuming there is one block every 10 minutes (as the network aims for), there are difficulty*2^48/65535/600 hashes done per second (=7158388*difficulty). If there are more blocks found than 1 per ten minutes, the rate is proportionally higher.

Currently (at difficulty 244139), this means that each block requires on average a whopping 1048587089228612 hashes to be performed.

I believe Gavin has the alert key now.

Fixed.

It will not make more than 8 outgoing connections, but unless you supply -nolisten, it will listen for incoming connections independently. Maybe you just want to use -nolisten?

The hard part is not doing the sha256 checksum - it's verifying whether the ECDSA signatures are valid, and the transaction inputs are spent yet. So it requires both computation (an ECDSA signature verification is close a millisecond of CPU time), and disk seeks (random access to the block chain database).

Very nice! It doesn't seem to work completely yet, as I get weird character in the status column and status bar below. Apart from that, really good to see we don't need a dev branch of wxwindows.

One suggestion: is it possible to define _ yourself, so all the GetTranslationChar calls aren't necessary?

The difficulty is calculated through a formula that is based purely on information in the block chain, and is only valid within a particular branch of the block chain. Since everybody has this information, everybody just calculates it and verifies it for each incoming block. So the answer is: everyone.

IP addresses from those on the fallback node list are good candidates (https://en.bitcoin.it/wiki/Fallback_Nodes)

Hello all,

I've been working on restructuring the bitcoin source code a bit. A first step was splitting off all wallet-handling into a separate class CWallet, so that eventually eg. multiple loaded wallets at the same time are possible, less global variables are needed and in general the dependencies inside the code are improved.

I ended up changing somewhat more than expected, as really a lot of code depended on access to those globals.

A summary:

• A new class CKeyStore manages private keys, and script.cpp depends on access to CKeyStore.
• A new class CWallet extends CKeyStore, and contains all former wallet-specific globals; CWallet depends on script.cpp, not the other way around.
• Wallet-specific functions in CTransaction (GetDebit, GetCredit, GetChange, IsMine, IsFromMe), are moved to CWallet, taking their former 'this' argument as an explicit parameter
• CWalletTx objects know which CWallet they belong to, for convenience, so they have their own direct (and caching) GetDebit/... functions.
• Some code was moved between CWalletDB, CWallet and main.
• Main.cpp keeps a set of all 'registered' wallets, which should be informed about updates to the block chain, and does not have any notion about any 'main' wallet. Function in main.cpp that require a wallet (such as GenerateCoins), take an explicit CWallet* argument.
• The actual CWallet instance used by the application is defined in init.cpp as "CWallet* pwalletMain". rpc.cpp and ui.cpp use this variable.

The code is here: https://github.com/sipa/bitcoin/tree/walletclass/src

Note that the branch is not yet rebased against the current master, is a work in progress and may have bugs. There should not be any changes to the actual program logic, but segfaults or performance degradations are definitely possible.

Comments are welcome.