{"id":332,"date":"2012-09-14T01:00:00","date_gmt":"2012-09-13T23:00:00","guid":{"rendered":"https:\/\/www.fussylogic.co.uk\/blog\/?p=332"},"modified":"2012-11-17T10:46:51","modified_gmt":"2012-11-17T10:46:51","slug":"bitcoin-explained-ii","status":"publish","type":"post","link":"https:\/\/www.fussylogic.co.uk\/blog\/?p=332","title":{"rendered":"Bitcoin Explained (II)"},"content":{"rendered":"

This is part II<\/a> in my \u00e2\u20ac\u0153Bitcoin Explained\u00e2\u20ac\u009d series.<\/p>\n

The problem we left at the end of part I<\/a> was that the construction of a valid chain of payload-storing blocks is trivial (for a computer) to create. For a financial system we want it to not be trivial, we want it to be incredibly hard to recreate a chain, so hard in fact that there can be only one chain.<\/p>\n

The solution that Bitcoin uses is a proof of work<\/em> system. Here \u00e2\u20ac\u0153work\u00e2\u20ac\u009d means computational work. It\u00e2\u20ac\u2122s worth noting that the work we choose must have two very important properties:<\/p>\n

    \n
  1. It must be very hard to do (this is the \u00e2\u20ac\u0153work\u00e2\u20ac\u009d part)<\/li>\n
  2. It must be very easy to verify (this is the \u00e2\u20ac\u0153proof\u00e2\u20ac\u009d part)<\/li>\n<\/ol>\n

    There is no point in a proof of work system that requires as much work to check that it is valid as it did to create the work. This is what renders suggestions that Bitcoin should use folding@home<\/a> or SETI@home<\/a> as its computational work, invalid. While the work done by those two systems is indeed hard to do (meeting criteria #1), there is no way to verify the correctness of that work other than by repeating it (failing criteria #2).<\/p>\n

    The proof of work system used by Bitcoin is one that combines nicely with the block chain system it already has. An additional piece of data is stored in each block. This data has no purpose other than to alter the final cryptographic hash of the block (any change of input alters a hash significantly). It\u00e2\u20ac\u2122s called the nonce<\/a>; it\u00e2\u20ac\u2122s not (for UK readers) a paedophile, its use comes from the noun \u00e2\u20ac\u0153nonce\u00e2\u20ac\u009d, meaning<\/a> \u00e2\u20ac\u0153The one or single occasion; the present reason or purpose (now only in for the nonce)\u00e2\u20ac\u009d. Strangely, given the purpose of a cryptographic hash, the nonce\u00e2\u20ac\u2122s job in a block is to be a use-once number that effectively brute-forces the block hash to a particular value.<\/p>\n

    That brute forcing of block hash is hard work, but, (drumroll) is easily verified. Exactly what we want for our proof of work system.<\/p>\n

    The \u00e2\u20ac\u0153particular value\u00e2\u20ac\u009d of hash being searched for is any hash less than a pre-determined target<\/em>; we\u00e2\u20ac\u2122ll come to how that target is determined later, but for now simply accept that there is a hash-target, and that target is itself listed in the block (i.e.\u00c2\u00a0changing it would also change the hash). Finding a nonce is hard because there is no way to know without recalculating what effect any value of nonce will have on the final hash (if there were then the cryptographic hash would be a failure). If we\u00e2\u20ac\u2122re looking for a nonce that results in the hash being numerically less than some defined target value, there is only one way to find it: we have to try many different values of nonce, one by one. However, once we have found one, it\u00e2\u20ac\u2122s easy for someone else to do the same calculation using that found nonce to see that it really does result in a hash less than the claimed target.<\/p>\n

    I, as a Bitcoin node, get sent a block by my peer. I do not trust that peer, since it is just some computer on the Internet, it could be feeding me bogus data. I perform two initial checks on that received block:<\/p>\n