Hi! I've got a bachelor's degree in computer science with a cognate in economics.
I have been really following along with Bitcoin since November 2012, around the same time I pre-ordered a BFL Jalapeno.
Since then, I've been learning way more than I ever really needed to know about cryptography and statistics. Though I probably don't need to go this much in-depth, I'll go ahead and freestyle rant about what comes to mind.
Out there in the magical land of the Internet, I have a machine that's running bitcoin-qt. Right now, this machine is connected to 23 other machines running some software, including
173.242.112.53 to try and help zero-fee transactions make it into blocks found by Eligius.
Side note: Speaking of Eligius, this is the pool I mine on with my stupid NVIDIA GPU at just enough to cover electricity costs at the current exchange rate and difficulty. The pool has had a stroke of bad luck recently. I guess that since I ostensibly have to prove that I know more than the average newbie, it makes sense for me tell you that "Eligius has had a stroke of bad luck" simply means that other pools keep finding blocks before Eligius.At any given moment (and every 10 minutes, on average), one or more of those 23 other machines can send me a packet of data that can be interpreted as a block ("block X"), let's say generated by BTCGuild (nowadays, there's like a 40-45% chance that it was, which would be quite troubling if someone other than eleuthria were running that pool). When this happens, bitcoin-qt looks at block X and runs through several validation rules:
- Are the transactions valid?
- Are all the hashes correct?
- Does block X's header's hash contain the minimum required number of leading zeroes, as required by the current network difficulty?
- Does block X form the longest valid chain (ties are allowed)?
If the answer is "yes" to all of the above, then my machine tells all of the other machines it's connected to about block X, and they (probably) run the same checks themselves.
At some point, the other mining pools (sticking with my Eligius example for now) hear about this and do the same kinds of checks. When those checks pass, if block X forms a longer valid chain than what its miners are currently building off of, Eligius will (hopefully) tell all of the connected miners to switch to building off of block X. After all, most clients aren't expected to accept a block that doesn't form the longest valid chain -- that goes against the rules that people agree to when using Bitcoins.
Sometime between when BTCGuild generates block X and when Eligius hears about it, it's possible that one of the miners connected to Eligius finds another block (block Y) that builds off of the same previous block as block X. When this happens, Eligius will happily propagate block Y to all of the nodes it's connected to, who will now will see a tie for "longest valid chain", and issue new work to its miners to start building off of block Y. At this point, the block chain is temporarily "forked".
A "fork" like this isn't the end of the world. Eligius will eventually hear about block X. When it does, it (hopefully) doesn't tell all its miners to switch from building off of block Y to building off of block X, as they're both equally viable candidates for "longest valid chain", and there's a cost associated with switching like this. Suppose that Eligius finds block Z that builds off of block Y before hearing about any blocks that build off of block X (highly unlikely, but possible). Then, Eligius will propagate block Z out to the network.
Remember, BTCGuild is still trying to build off of block X. If block Z reaches BTCGuild before they find their own block Z' that builds off of block X, then that forms the new longest valid chain, and they'll be forced to abandon block X. We would call block X an "orphan".
All of the inputs to transactions that were included as a part of block X are now viable inputs for transactions added to future blocks. In most cases, if a transaction made it into orphaned block X, it will likely have been seen by enough of the network that a transaction with the same inputs would be rejected, but it does open up the possibility that a future block mined by someone at a later time could contain a transaction with the same inputs and different outputs, which is almost surely going to be embedded into the blockchain. This is obviously extremely unlikely, but since there is that possibility, it's often recommended to wait until several blocks have built upon the block containing your transaction before going to spend those coins.
I guess that sounded like a conclusion, so I'll stop there. Can I get out, please?
