Why another (intentionally) conflicting transaction? Just mark the unconfirmed transaction inactive...

Edit: see pull request described here: http://forum.bitcoin.org/index.php?topic=7330.0


It is a situation that is currently hard to reach, but nonetheless possible when moving wallet.dat files around, and can potentially leave you with a permanently corrupted wallet.

Consider this scenario:

• Alice receives a 50BTC coin
• Alice creates backup of her wallet
• Alice goes offline
• Bob imports A's wallet
  
• Bob sends 20BTC to Carol (sending 30BTC change to a reserve key)
• Alice comes online before Bob's transaction ends up in a block, or somehow does not receive the block it is in yet
• Alice sends 10BTC to Ted, using the 50BTC coin as input

The network already knows about Bob's spending of the 50BTC coin, so it will not accept Alice's transaction anymore. Alice should be using the 30BTC change coin, but does not know about this yet. The result is that Alice has a transaction in her wallet which will never be accepted by the network, but Alice still assumes it is valid. Even worse, Alice will try to use the 40BTC change of that transaction in further transactions as well, and those transactions (and everything resulting from its change) won't be accepted by the network either.

You may argue that copying wallet.dat files around is always a dangerous business, but I don't like the idea that being unaware of a transaction happening using one of your own keys can potentially break things.

I'm working on a patch to detect cases where the blockchain conflicts with a wallet, but the question is: what to do when it happens?

Some possibilities:

• Edge case, don't bother
• Silently drop the offending transaction from the wallet (very easy)
• At least give a warning message in the GUI (easy, but what to do in bitcoind?)
• Mark the transaction somehow as inactive, and show this in the GUI and RPC calls (needs some changes, including update to wallet.dat format if you want keep these permanently)
• Try to recreate the transaction, using inputs that do exist (after user confirmation in GUI, or using special RPC call)
• Automatically try to recreate the transactions (probably too dangerous)

Bitcoin transactions in general do not have a from address. You may derive which addresses its incoming funds passed through, but there may be more than one, and some or all of them could belong to shared accounts. Actually, it's even possible to have no assignable "from" address at all - it's for example possible in the protocol to have a "spend to anyone" transaction, without defined recipient address.

There is a currently unimplemented feature of the protocol, where transactions can be given a version number, and a new version of a given transaction can be created, overriding the previous one as long as it is not accepted into the block chain. I assume that is meant to be used to update transactions with a higher fee when the original one wasn't enough.

In a sense, you are right. The difficulty is just an artificial construct to maintain a more or less constant block generation rate. However, the thing that is beneficial to the network is (honest) hashing power, and more hashing power will result indirectly in higher difficulty.

Nice work.

I'm in favor of a reorganization, especially adding some compilation units that do not include all .h files. Some .cpp files are very large, and include large amounts of code in header files that are included everywhere, slowing down compilation a lot. Furthermore, main.cpp and main.h contain the largest part of the internal logic, without clear separation, though they contain several classes and functions which surely don't all depend on one another.

I'm not sure a separate file for each and every class is the way to go, though. Ideally we have some layers and clear rules about which can access which (for example, i'm not sure rpc.cpp should interact with db.h-defined classes directly). In that sense, your work here is a step in the right direction, by at least separating the classes from eachother. If we can agree on how to organize them in separate directories, and maybe split the remaining functions as well, we can be there. Then we can still decide whether we want all separate files, or simply one .cpp/.h per layer.

Do you plan to keep your branch synced with git's main for a while?

Transactions always consume the output of a specific previous transaction. If all funds available to that first address arrived there through many small transactions, you would need a lot of inputs to consume it as well. Bitcoin only conceptually deals with "money coming from an address", in reality it always comes from a previous transaction.

If the transaction does not show up either in the block chain or in the pending transactions list, most likely it never managed to reach the network, while it did get stored in your client. Eventually it will be retransmitted, but that may take long (days?).

Basically yes, both cover part of the problem of using the same key(s) on different installations.

One problem still remains though: if you try to spend coins from node A, while node B already spent them without A knowing about it, it will happily create a transaction and assume it will be accepted by the network, which it won't, possibly leaving you with a corrupted wallet forever. So, even though some wallet-sharing issues are already covered, it can still be dangerous.

Bitcoin currently does not check whether transactions received from the P2P network contain spends from your own addresses. Presumably because this was considered an impossible situation, but it happens when people copy wallet.dat files around.

This checking is done anyway when rescanning, and a full rescan of the entire realnet blockchain currently takes 11s on my old laptop, so I think the overhead of doing this check on incoming transactions as well, is very limited.

This issue was mentioned here before: http://bitcointalk.org/index.php?topic=3638.msg52145#msg52145.

Pull request is here: https://github.com/bitcoin/bitcoin/pull/157

Would it be cryptographically safe to use the (hash of) the public key as IV when encrypting the private key part?

Another idea: store the actual randomly-generated AES key for encryption of the private keys in the wallet itself, encrypted itself using a key derived (using the nice key derivation function you have for scratch-cards?) from the passphrase. This way, you can easily change the passphrase without needing to decrypt/reencrypt everything in the wallet. This encrypted key could also contain a hashed version of itself, to verify integrity.

A change passphrase RPC call / wx thing could be added, and setting it to the empty string would remove encryption (and turn all ekey fields back to key fields).

I'm not sure what is best. On one hand, I think the "generate coins" option gives both the wrong impression (either "bitcoin = free money!", or "bitcoin = worthless, people can generate it themselves!") and gives people false hope ("what the fuck? it takes 137 years to generate something?! Bye"). On the other hand, the idea of mining may attract people to become involved (like myself...).

I am quite sure though that a "Generate coins" flag in the UI is a bad idea. The only reasonable thing to use it for is testnet, and people who need that, typically don't need a GUI flag. I'm in favor of removing the miner code from the default client, but have an simple reference RPC miner as a separate binary included in the distribution. Ideally, this program should look at the nBits field in the received work units, and give an estimate of expected BTC/time and time/block. Some explanation in a mining.txt file may be useful as well.

The alternative would be leaving miner code in the default client, and either only make it accessible through RPC, or at least rename the option in the GUI ("Verify transactions", or "Support network", or "Generate blocks", but not "Generate coins") and show a warning that it may take ages.

For older clients you need to delete blk0001.dat and blkindex.dat, and let it redownload the block chain...

Yes and no.

Technically, you are wrong. Miners create blocks, and blocks introduce new coins to the system. Each unspent transaction output ("coin") is traceable to the blocks it descends from, and not further. At the level of the block chain, there is no pre-existing pile of coins, only a formula which determines how much new BTC each block is allowed to introduce. There is no bitcoin community involved here, except that our acceptance of the rules gives (real life) value to BTC.

However.

I like your way of looking at it. Since the formula for the value of coins sums up to a finite amount, you can identify the sum of the coinbases of all not-yet-mined blocks with a pile, and say miners of new blocks are allowed take from that pile, in a controlled way.

So, I applaud your effort to explain how the system works in a nice way, but maybe it can confuse people who are trying to understand it at the technical level.

I'm afraid you misunderstood some things. Mining is the process of generating blocks, but it is much, much slower than the numbers you give.

The bitcoin executable you can download does a number of things. First of all it manages your wallet (the coins you own), and allows you to send and receive them. Apart from that, it also contains a built-in miner, which uses your CPU to generate coins. Without knowing its actual speed, I think it is safe to say that generating coins now using that will at least take a few years, sorry if you had your hopes up.

Mining is currently mainly done using certain high-end GPU's, which are way faster at this than CPU's. The total number of coins to be earned every day is limited by the system, so the more people are trying to get a share, the less everyone will get. This may sound like a bad idea if you wanted to have some extra income from it, but it's actually a very good thing for the security of the network.

Bitcoin is not about mining, it's about creating an independent currency, which you can buy and sell. However, if you insist on mining, you can join a pool (which can give you very small but much more frequent payouts), or look into GPU mining if you have a fast graphics card.

PS: could you tell us where you got the information about 50 coins every 6 hours, or that it only requires 1.3GHz of your CPU?

One "hash" as in the 600Mhash/s a graphics card does, corresponds to one sha256(sha256(block_header)). The block header is 80 bytes, which is padded to 128 bytes, and split into to 64-byte parts.

The actual algorithm (in pseudo-code) is:

So, when looking at the actual algorithm, there are 3 sha256 updates involved. However, since the nonce is in the second part of the block header, the state of the hasher after update A1 is precomputed once for the whole range of nonces, limiting it to only 2 updates (A2 and B).

However, there are still more optimizations involved. Each sha256 update consists of 64 rounds. In the first 3 of update A2, the nonce isn't used, so these can be precomputed as well. Furthermore, the last 2 or 3 rounds do not influence the highest bits of the resulting hash (which are used for determining whether it passed the difficulty test), so these can be skipped as well.

Bottom line: a 600MH/s device, is actually doing 600000000*120 sha256 rounds per second. This roughly corresponds to doing 1125 million separate sha256 hashes (of data blocks < 64 bytes).

And yes, M stands for 1000000 here, not 1048576.

Assuming the hashing power of miners is constant over time, the average number of generations per unit of time is also constant, and the generations are independent from eachother. This leads to an exponential distribution for the time between two generations (see http://en.wikipedia.org/wiki/Exponential_distribution).

To estimate the parameter lambda of this distribution, we need the total hash rate of the network (currently around 600GH/s) and the difficulty (82347.22294654). Since each tried hash has a chance of 1 in 4295032833*difficulty to result in a block, lambda is network_speed/(4295032833*difficulty), or around 0.0016964/s currently.

The mean time between two generations is 1/lambda, or 589.47s currently. This is independent from any information from the past. In fact, it doesn't even matter how long it was since the previous generation. Even if there hasn't been a block for 5 hours (highly unlikely), it will still take on average 589.47s before a block is founds.

Other statistical information you can derive: the standard deviation is also 1/lambda, or 589.47s.
To find the 95% range, use the formula F(x;lambda) = 1 - exp(-lambda*x) = 0.95, or x=-log(1-0.95)/lambda, or 1765.9s currently.
To find the chance of not finding a block in a period of T seconds, use exp(-lambda*T), which is about 0.22% for T=1 hour. For T=1 day, it becomes 0.000000000000000000000000000000000000000000000000000000000000022%.

About your last question, you could say we want A and B to correspond to 2.5% and 97.5%, leading to intervals between 14.92s and 2174.53s (36 minutes).

Note that the network tries to have lambda=1/600s, but as long as hash rate is increasing (which is true most of the time), it is actually systematically faster.

The protocol deals with transactions down to 0.00000001 BTC just fine. Most miners will however not accept such a transaction without fee.

Transactions are never eaten. Either they are accepted, or they are ignored by miners.

Also see the scratch-cards mentioned on http://bitcointalk.org/index.php?topic=1514.0 and http://bitcointalk.org/index.php?topic=4555.0, which are in fact actually usable as physical bitcoin currency. The only necessity is trust in the issuer of the card, though...