Temple Melville - Blockchain, Bitcoin and You

W hen Satoshi Nakamoto produced his white paper Bitcoin: A Peer-to-Peer Electronic Cash System in 2009, he can have had no idea what he was unleashing on an unsuspecting world. I would have to say not only was the world unsuspecting, it was also largely uncaring!

With everything else moving at the speed of light in the world of technology, some may feel that the whole Bitcoin and Blockchain thing just suddenly arrived on the scene out of nowhere, but, as ever, the truth is somewhat different.

What we now think of as the blockchain in fact emerged from work that Linux programmers carried out in the late 1990s and early 2000s. What they were doing was producing robust and quickly developing coding by using thousands of programmers and coders all over the world. Its true that English is the language of the internet, but some of these people didnt speak English. What they did speak was code.

One problem that these coders solved concerned both the duplication of work and what we call 'version control'. How did Mr.A in Norway know that Mr. B in South America hadnt already done that bit of work? The answer is that all the code had to be ranked by time. So if Mr. A did some work at 9:05:45 that fact was broadcast to everyone who was working on the problem. As a result they were able to tell what the very very latest version was, and so there was no duplication and work progressed in a linear fashion rather than disjointedly.

This was the basis of Satoshis thinking. If everyone had the information at the instant it was available, that meant that 'cheating' or changing any of that information, was almost impossible. If fifty people were told a thing, then to change that thing meant you had to get fifty people to change their minds, and you then had to change the information that was in the fifty peoples inbox.

This of course is an oversimplification, but I think you can see the point.

Satoshis next brilliant insight was to say: maybe you dont need all fifty people to agree, maybe you only need twenty-six out of the fifty. As a result, the system Satoshi proposed showed that as long as more than 50% agreed a solution, that solution could be taken as true. In reality, if the solution goes to all fifty users at once it is extremely unlikely anyone is going to be a naysayer.

The next aspect which Satoshi Nakamoto's paper addressed related to was what was happening in the world of traditional finance at that time. Trust in banks, their ability to be the guardians of the ledgers, and trust in other financial institutions was at an all-time low. If Satohsi's paper suggested there could be an alternative payment mechanism that didnt have any interference from traditional bankers, then the world might be a better place. What was needed, the paper suggested, was a system of decentralised confirmation, not one-point confirmation. But there was a problem and this problem which is called the Double Spend problem, is only related to money.

The thing is, we can re-create anything digitally. Its why e-Books and downloads for music exist. You want them identical thats why we are buying them. You dont want a different ending of the song you download to the one you just heard on the radio, and the quality must be, and is with digital, the same evey time. Being the same is no use for money though. The 1 in your pocket or bank account is inherently different from the one in mine. Theres a wonderful skit that Tony Hancock did when he deposited a 5 note into his bank then decided to take it out again. Of course, he got back a note that didnt have his signature on it. So it wasnt 'his'. And he was absolutely right it wasnt his. It had a different number on it.

And that, Ladies and Gentlemen, is the problem. Digitally they would be identical although for a system of money to work, we need them to be different.

Satoshis brilliance was to create conditions whereby each string of code WAS different. This meant that, having been created, the code was broadcast to all the computers that were on the system instantly. This meant that anyone looking at the current state of the code could be sure it was correct. At the same time, the bit of code that had been allocated to each individual was unique to them, and locked into place.

And this book will explain how that all happens.