Page 3 of 3
At this point the node can submit the block to all the other nodes for inclusion in the official chain - the nodes also check the block for consistency at this point and once again make sure that a transaction doesn't spend a Bitcoin twice. Once the block is validated and submitted to the system the transactions within it have received one confirmation.
Notice that this doesn't mean that the transactions are good. The reason is that there are lots of copies fo the database being updated asynchronously across the network and it is just possible that two or more nodes solved the problem at more or less the same time and some copies of the database might have been updated with a different "next block". At this point the split in the database cannot be detected by a distibuted system - each node thinks it has the correct chain - let alone corrected.
Two nodes have different chains due to being updated by two different sucessful solutions to blocks in different parts of the network
However at the next step the block generated either fits uniquely into copy A or copy B of the database. Suppose two nodes attempt to continue the two chains:
Two candidate blocks but X only fits the end of chain A and Y only fits the end of chain B.
If the block that wins the proof of work and is sent out to the rest of the database continues copy B and not copy A then copy A is discarded and copy B becomes the one true database.
Chain B now becomes the "bad chain" because it cannot be updated by the winning block. Note that Chain A would have been the "bad chain" if chain B's block had finished first!
Of course it could be that by chance two nodes complete their task at the roughly the same time and the database splits again" However as time goes on this becomes increasingly unlikely and eventually one database will win out as the true record of how the Bitcoins have been transferred.
Thus after six more valid blocks have been added to the chain that the transaction belongs to its status is changed to confirmed. The idea is that after six more transaction blocks have been processed the original block is well and truly embedded in Bitcoin history never to be undone.
What this means is that a user spends a Bitcoin and then has to wait until the transaction is confirmed for the transaction to become permanent. If the user is dishonest and tries to spend the Bitcoin twice then the probability is very high that only one transaction will reach the status of having six following validated blocks and so one transaction will fail and the other succeed.
So it is very likely that even though the database is distributed and updated asynchronously a single coherent history of transactions is eventually agreed upon.
Notice that this is still a probabilistic statement and it could conceivably go wrong but the probability is very low - unless someone finds a way to make it happen.
The need to do work makes the system dependent on the fact that the majority of CPUs engaged in the network are honest. However, if you had enough computing power at your disposal then you might be able to fool the system by solving two different blocks before anyone else could. In this situation you would be able to get two versions of a transaction's history, so allowing you to spend the same Bitcoins twice say.
However, to keep this up you would have to repeat the sting, not once but six more times and maintain the split in the database. This seems like a very difficult task. There may be something in the implementation of the idea that makes it vulnerable to manipulation but the basic idea seems good.
To a programmer the proof of work method of ensuring the acceptance of a single valid distributed database that is updated asynchronously is fascinating and it certainly has other applications.
In the future there will be additional complications to the system that results from its growth. The first is that eventually the nodes that validate blocks will stop being rewarded by the creation of new Bitcoins. The whole idea is that there are a limited number of Bitcoins and as this limit is approach Bitcoin miners will be rewarded less and less often. At this time some other means will have to be used to pay them for processing transactions - a charge will have to be levied. Even today some transactions carry a premium to encourage nodes to process them.
More interesting from a programmer's point of view is what happens when the database gets too big for a single machine to work with. At the moment it is about 200MBytes and every node works with the entire database. The interesting news is that the database already has a Merkle hash tree to enable it to be used piecemeal secure in the knowledge that it hasn't been tampered with - but Merkle trees are another story.