Bitcoin Origins

Afternoon, All.Today marks the eighth anniversary of the publication of the Bitcoin white paper.As a special tribute, I will provide you with a short story on the origins of the Bitcoin tech.I've been out of the game for many years, however now I find myself drawn back - in part due to the energy that's being added by the incumbents, in part due to information that's become public over the past year.I haven't followed the Bitcoin and alt coin tech for the past five or six years. I left about six months before (2).My last communication with (2) was five years ago which ended in my obliteration of all development emails and long-term exile. Every mention of Bitcoin made me turn the page, change the channel, click away - due to a painful knot of fear in my belly at the very mention of the tech.As my old memories come back I'm jotting them down so that a roughly decent book on the original Bitcoin development may be created.The following are a few of these notes.This is still in early draft form so expect the layout and flow to be cleaned up over time.Also be aware that the initial release of the Bitcoin white paper and code was what we had cut down to from earlier ideas.This means that some of the ideas below will not correspond to what would end up being made public.Bitcoin LogoBitCoin OriginsSix Months In A Leaky BoatIntroductionI have always found that there’s a vast gulf between knowledge and understanding.Wherever I looked I’ve found very intelligent folks who had immense knowledge in their subject but with little understanding of what to do with it, how to mould it, how to create something new.They could only ever iterate incrementally to improve the knowledge in their given field.Understanding comes from experiences outside of knowledge in a particular subject.The following story is about a most unique project and the understanding that was used and applied to the e-cash problem which resulted in the experiment called Bitcoin.It is to show the thought process, stream of consciousness, arguments, examples, concerns and fears that went through our minds has we tussled with this beast and hammered out something that may actually work.There is no verification of truth here. There is absolutely no evidential proof that I had any part in the project. All evidence was purged in late 2011 - the reason will become apparent. Only (2) should know of my involvement (until now). Take this as just a fictional story if you wish.Who am I ? I went by the ‘net handle Scronty back then.scrontsoft.comI have always been interested in computer and electronic technology since the age of eleven. Seeing what others had made these machines do, and then trying to push it a little bit further out.Whenever there was a problem to be figured out I would always begin with what the current state of knowledge was - after all, we all stand on the shoulders of all those who have gone before.Quite often I found that the assumptions folks hold for a particular problem are the things that are holding them back from figuring out a new solution.So I would begin by questioning peoples basic assumptions on various subjects“What if that wasn’t true ?""If it didn’t exist what could it be replaced with ?”This usually resulted in annoying all of these knowledgable folks.“That’s the way it’s always been”“That’s the best industry standard for this”“All the letters after my name means I’m right and you’re wrong”“That’s what’s written in this book I’m holding”“Everyone quotes from this person so he must be right - so I quote from him as well”You get the idea.You see it on every single message board since the mid-nineties onwards.There’re also a lot of egotistical chips on folks shoulders where you’d find that they’d look down on others and belittle them on topics that they themselves had only just learned a few weeks earlier.This is particularly true in programming and crypto forums.StartA couple of guys worked with an online betting company.They had a problem.For punters to use their service they had to provide credit card details and pay for chip tokens.However, many times a punter would play the online pokey machines, lose all of their money and then reverse the credit card charge saying “It’s unauthorised. It wasn’t me”.Sometimes the company’s network would not record the funds transfer correctly and so the punters funds were removed from their credit account into the company’s account but no record of it was made on the company’s end - so the punter didn’t receive any play tokens and, again, tried to reverse the charges.The large credit card issuing companies also actively stopped allowing credit cards to be used for online gambling and began refusing to reverse the charges.What these guys needed was a way to transfer funds between punters and the online betting companies so that both parties could trust that everything was above board.That a payment could not be made by mistake and once a payment went through it was unchangeable, irreversible.(2) had been on the periphery of the cypherpunks group since the mid 1990’s. When I entered the project in early 2008 he had been working on the problem part-time over the past five years. Over the previous year or so he’d been working on the problem full-time. He was writing a white paper for an e-cash system for the online betting/gambling company to use ( or to license out the solution to multiple companies ) plus writing the code for it.He was attempting to implement a working example of electronic cash.There were other cryptographers who he was communicating with however it just wouldn’t “work”. There were always too many attack vectors with the solution and even though, from a cryptographic point-of-view, the white paper and code was appropriate, he found it unsatisfactory.After talking to his friend (3) it was decided that maybe they had their noses too close to the grindstone and that they should find someone who wasn’t a cryptographer to look over the ideas.The problem is that to find such a person is very difficult. He’d have to be smart enough to understand cryptography (or learn it), also be interested in the subject but also not currently be a cryptographer.Usually the folks who were smart enough and had an interest were already cryptographers.Through various IRC (Internet Relay Chat) channels (3) came across me and I ended up being put in touch with (2).With my work in the Win32 Asm community I’d shown I was smart enough and could figure out the solutions to difficult problems.Plus I’d made sure my public profile was always dealing with grey-to-white topics (no online gambling stuff).Request For HelpI was asked to take a look over what had been written in the white paper and see what needed to be changed as the code implementing it just wasn’t working - the pieces wouldn’t fit together or the whole thing would fail if certain pre-conditions in the network weren’t met.(2) wanted to publish the white paper before the end of the year (2008).I began reading through the document - understanding very little.Hashing and encrypting and decrypting and private keys and public keys.Different types of hashing algorithms, encrypting then hashing and hashing then encrypting.Oh my!“Just tell me what I need to change to make it work” - (2) kept asking me.“I dunno what the [redacted] I’m reading here” - I replied.(2) thought that maybe he’d made a mistake and he’ll just try and find someone else.I told him that he’s going about fixing it the wrong way.“How should it be fixed ?”, he asked.“Well, first I need to know what I’m reading. So you’re going to have to give me info on the various crypto stuff in here”, I said.“No no no”, he said. “ If you learn the meaning of the cryptographic jargon you will be influenced by it and would no-longer be the “non-cryptographer” that we need to look over the white paper”.I told him that without learning the jargon I cannot read the paper in the first place.Also - as I learn I will understand more and will be able to tell you what you need to change.If or when it got to the stage that I’d learned too much and also had my nose too close to the grindstone then I could leave the project and he could find someone else to replace me.He agreed that having me learn a bit about cryptography may be a good idea (:roll-eyes:).He told me to get started.I asked where the information was.He said “Google it”.I said “Nope. You’ve been working in this area for the past few years so you can give me a link to the websites with the info."He returned with a list of website links and said to go through that and look at the white paper.The list had about 109 links in it - bloody [redacted].One-by-one I began going through the information.After a few weeks I’d gone through about half-a-dozen papers/websites which hadn’t cleared up anything.Once three or four weeks had gone by I threw my hands up in disgust and told him “At this rate I’ll be here all year and still not understand all the pieces. You’ve got to filter this down for me. You’ve already read all of these documents and websites so give me a list of the most important docs/websites you think would be helpful in understanding your white paper”.He came back with a list of about 23 white papers and websites.“Now list them in the order you think I should read them in”.He came back with a sorted and filtered list of crypto-docs and websites.I began reading through them - starting at the first.TransactionsGiven a computer network there had to be transactions sent to a recipient.The initial white paper was pretty much a shuffling of the various cryptographic e-cash white papers at the time. We knew that when someone wanted to send a payment to another person it would have to be transmitted across a network securely.But how to solve the double-spend problem ?A piece of physical paper cash can only be in one place at a time - you cannot double-spend a physical currency note. All current electronic cash solutions relied upon a central server to control the allocation of coin and to make sure no coin could be double-spent.But if that server went down, or was unaccessible due to a DDOS attack or government intervention ( or someone just tripping over a power cord ) then no more money.We knew that a coin would initially be minted somehow.I found most of the methods written in white papers and on websites were rubbish ( Personal opinion here. No disrespect to those who wrote those white papers ).They either tried to pretend to act as central banks or tried to allow a “mates club” whereby they all agreed who's going to get coin at a particular time.Kind of like politicians using an "independent" third party to give themselves a pay rise.One day he came back to me saying his friend (3) wanted to communicate directly with me but he was a super-paranoid fella and I had to encrypt any messages using private/public keys.It was a [redacted] nightmare.I had to:Generate the private/public keysMake sure the public key was sent to a very specific location so that we could “trust” that the public key was validUse this quirky little command line proggy where I included my email address plus a link to the private keyEmbed the generated data into the emailThis was all so he could confirm that the message was indeed from me and had not been intercepted or changed.Then he decided that I’d also have to generate new private/public keys for every single email just in case a previous email had been intercepted.I told (2) that this just wasn’t going to happen.I’ve always disliked using command line programs directly and always thought that they should always be executed from a GUI ( Graphical User Interface).I said “You’re going to be my filter for this project and main conduit in this team. I send emails to you, you communicate with whoever you need to and send their replies back to me. Or you send their requests to me and I reply back through you.And what’s this annoying command line proggy anyway? What the [redacted] is it doing?(2) gave me the link to the information - it was in that list of 109 docs/websites but not in the filtered list of 23.It was to Hal's website where he very clearly explained how something called "Hashcash" worked.Hals RPOWFrom there I went on to Adam's site:Hashcash(which was not even in the original list at all).I read the Hashcash white paper sections until I hit the calculations and my eyes begun to glaze over.HashcashI read the first few paragraphs and knew this was something interesting.I asked (2) if he could check whether this document was the final version or if there had been improvements/ amendments/ updates to it.He said he thought I was wasting my time with this and I should continue with the other docs/websites in the list he’d provided me.I told him that I’m the only one who would know what info is important and to look into the Hashcash origin for me. He came back a couple of days later and said it was confirmed that the public document linked was the final version of the Hashcash paper.I asked how he could confirm it?He told me that he’d contacted the original website author Hal and asked him for any updated document and Hal had replied back with the exact same public link.He’d even copy/pasted Hal’s reply in the email to me.I said “Wait… What ? …”“You actually contacted the original author of the reference material ?”He said “Yep. Who else would I go to to confirm the document, except to the author themselves ?”I told him it was really quite rare to have someone check with the original author or sources. Most folks read something and take that as fact, or read the reference documents and take those as fact.If someone read about the Boyer-Moore search algorithm they take it as fact that what they’ve read is the official final solution. I haven’t heard of anyone contacting Boyer or Moore to check for any updates/ improvements/ amendments.The Boyer-Moore search algorithm is something that went through the rounds on the Win32Asm community forum for a while.I found this quite intriguing. Even with (2)’s occasional grating personality it would be very useful to have someone who’s prepared to hunt down the original authors like this.I asked him if he'd contacted the Hashcash author and he said he'd sent emails to every single author of all of the websites/ white papers and only about a dozen or so had ever replied back to him.I had begun to write up a list of what the various problems were for creating an e-cash system from the other e-cash system white papers and websites I had been studying.I was still referring back to the white paper (2) had supplied me however it was really just a mishmash of what everyone else had been doing over the years.Hence why it failed like all of the others.One of the problems was a trusted time stamp so that folks would know that funds hadn’t been double-spent. Another was the minting of the tokens in the system and trusting the minting source.If I recall - practically every single white paper out there ( including the one suppled to me ) used a trusted third party as the source for a time stamp and a convoluted method to check it hadn’t been tampered with.And the minting either used a trusted third party to generate coins on a regular basis or had a network of nodes agree on how many tokens to generate and give to each other.(2) said that we need to use the trusted third parties because how else can we trust the time stamp and the minting of the tokens.I told him he was thinking of it in the wrong way.You’re assuming a trusted third party is needed, just because every single other cryptographic white paper says that’s how you do it.But you’re also saying that you can’t rely on a trusted third party because that makes a single point attack vector that can bring the whole system down to its knees.“Remember Sherlock Holmes” I said. “ ‘When you have eliminated the impossible, whatever remains, however improbable, must be the truth ?’.The assumption of a trusted third party in an functioning e-cash system must be eliminated as impossible for this to work.So if we cannot have a trusted third party for this, what are our other options ?”“I have no idea”, (2) replied. “Do you believe this proof-of-work thing you’re looking into can be used for this somehow ?”.“I dunno. It definitely has some possibilities. It’s made for making sure the data being sent and received comes from a known trusted source and that it hasn’t been tampered with”.It forces the user computer to generate a hash of the data to find a hash with a prepended number of zeroes. If the hash isn’t found it increments a value and hashes again. It just keeps repeating until a hash is found with the correct number of prepended zeroes.This means that the user computer has to spend time working on the hashes until it finds one and only then can it stop.It was designed to eliminate the email spam problem that we all have because a spam-sender would need to use a lot of computing resources to generate hashes for all the emails sent out ( the data that’s hashed includes the recipients email address so a new hash is required for every single email recipient ).It also has a throttle so that the difficulty in generating a hash can be increased over time as the general computing hardware improves.The minting problem is also sorted due to the electricity used in generating a hash can be used to mint the e-cash and put it into circulation.Effectively - the real fiat-currency cost (via electricity consumed) of generating the valid hash is how much e-cash is given to that minter.It also sets what the price of the minted e-cash should be, as there is a direct correlation between a real-world electricity bill and the digital e-cash amount minted.Taking the time used to generate the hash with how much energy the cpu used during the generation ( only the time spent on hashing - not other computing resources ) with the local electricity costs of the suburb/county/province/state/nation the minter resides within, then each minter could have a locally-adjusted e-cash value added to their account.It would mean that someone minting in a country with cheap electricity due to state-subsidised support would receive less e-cash because less real-world fiat currency was expended in the generation of the hash.So now we had a mechanism in which this e-cash would work.I'll stop this story here for now and post a follow-up depending upon its reception.The follow-up will contain some of the details of how the idea of a chain of blocks came about, plus some of the tech that was left out of the initial white paper and public code release ( it was, after all, just the first experiment to check whether this tech would actually work ).As a side-note:When you read the Bitcoin white paper again, the Introduction, Calculation, Conclusion and References sections were written and edited by (2) and (3).The Transactions, Timestamp Server, Proof-of-Work, Network, Incentive, Reclaiming Disk Space, Simplified Payment Verification, Combining and Splitting Value and Privacy sections were from text copy/ pasted from emails from me to (2) explaining how each part worked as they were being figured out.I wrote the Abstract text when (2) asked me to write the Introduction. (2) used it as the Abstract section because he found it too terse for an introduction.(2) and (3) edited the entire document and removed any double-spaces from it, adding titles to the various sections and adjusting between 2% and 5% for spelling errors and grammar/ sentence structure.You can see the original Abstract with double-spacing here: Public Mailing-list PostingThere was a huge misunderstanding between us all during the formation of the white paper which I'll mention next time.Cheers,Phil(Scronty)vu.hn via /r/Bitcoin http://bit.ly/2fbGSee