Table of Contents
- BitCoin Origins
Today marks the eighth anniversary of the publication of the Bitcoin white paper.
( Part-one was posted to reddit on the 1st November 2016 )
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.
It’s written as a conversational narrative.
It’s the style of writing I’ve chosen to explain how the tech was created.
Most academia write technical details in such a stifled way that it’s pretty much unreadable.
Writing as if a conversation was taking place - discussing how it could work - is much more interesting.
Like a play on a stage or a Tv documentary.
So the text itself is made up however the narrative surrounds what generally happened ( by someone without access to the actual email and IRC messages ).
Even without documented evidence there are a few fixed points I've been able to lock down.
One is the kicking off of the Prometheus project being in the first week of June 2008 due to finding the book from which the project was named.
Other points include the instructions for the two main logos - the gold coin and orange logos from 2010 ( the initial BC logo wasn't built from instructions ).
Bitcoin Gold Coin Logo Construction Animation
Bitcoin Orange Logo Construction Animation
Six Months In A Leaky Boat
I 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.
I 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.
In the early 1990's I obtained the book The 2024 Report from a second-hand bookstore in Palmerston North, New Zealand.
Chapter 6 mentions the creation of a CentroBank in 2005, Computerised Town Meetings and Third World people using CentroBank currency over their own country's fiat currency.
Every few years I'd find the book again and read over some of its content - always coming back to chapter 6.
I'd then hunt down the current crypto community Usenet newsgroups, message-boards, and IRC ( Internet Relay Chat ) channels to find out what was the current state of development in electronic cash.
Each time I was disappointed.
Occasionally I'd see a few folks attempting to create something, only to have everyone else trash their ideas and pull it to pieces.
After a few weeks of searching I'd return to my normal life.
In 2005 I began helping someone develop the tech for an online multi-player tank game prototype.
The IP ( Intellectual Property ) for most of its functionality was on the Win32 Asm message-board where I was a moderator at the time.
In early 2006 the developer made a deal to transfer ownership of the game's IP to a gaming company in return for a position in the company to continue building the game.
That gaming company, to get out of its deal, began a merging process with another gaming company which left the original developer stuck at a desk in an office with nothing to do while they continued development of the game themselves.
During 2006 they began a huge campaign to remove any mention of this tank game prototype from the internet.
That included sending an email to the administrator of the Win32 Asm Community message-board telling him to remove my threads which mentioned the prototype.
I found out almost immediately of the removed threads and messaged the admin telling him to put them back.
He explained some of the contents of the email he'd received and said he couldn't put it back due to IP violations.
This company was saying that the IP I'd created was theirs and that's why the threads were removed.
I told the admin that the threads themselves are proof that the IP is mine and definitely not that company's IP.
I said those threads show step-by-step how the ideas were fleshed out and conclusions reached.
He still refused to put the threads back due to the threatening content in the emails.
I told him that if they were threatening legal action against you, then put the threads back up.
No lawyer would be able to prove that the gaming company had created this stuff before I did.
He refused and said the threats in the email were not from a legal point-of-view and he'd be physically at risk if he put my threads back up.
From that moment on I decided I wouldn't spend my time helping folks on the message-board any longer and that I'm through with spending my time and effort to help others when it could be pulled from the board so easily.
For the next six months I googled the original developers handle and the game and noticed that every fortnight their were fewer and fewer pages with any information on him and the game.
In late 2006 I messaged the original developer asking him what's happening.
He gave me some details as I mentioned earlier and that he was deciding to leave the game development industry for good and never return due to how he had been treated.
By early 2007 there was no-longer any mention of the tank game prototype and the developer anywhere.
At this stage I was looking around for other things to put my mind towards.
I wasn't really doing anything in assembly on the board as every time I went on the board to take a look around I'd see someone who needed help with something then recall the removal of the tank prototype threads and stop myself.
I was very anti-open source up until that time.
The idea of folks coming together to help each other on the development of a project made me think they'd just be making junk software.
To be successful, any software needs to be driven by greed.
One form of greed is monetary gain.
Most of these open-source software developers were doing it for prestige or additions to their resume.
However there was one single thing that these open source software projects had which my previous projects didn't have.
The code was duplicated on multiple computers and folks had copies of the same source-code.
There is absolutely no way a bad actor could come in and force every single one of those duplicated repositories to capitulate and remove or delete their content.
Clearly, if you wanted to restrict how someone could modify the truth you have to distribute the data to as many computers as practical.
If you're restricted to trusting a few admins on a few message-boards, Usenet newsgroups and IRC channels then a few folks can be targeted for advantage.
These jaded feelings pervaded all though 2007 and by the end of the year I hadn't found any open source project that I could sink my teeth into.
Near the end of 2007 I came across my copy of The 2024 Report book again and re-read chapter 6 mentioning the CentroBank.
I again hooked into the various crypto community Usenet newsgroups, message-boards, and IRC channels to find out what was the current state of development in electronic cash.
Still pretty much the same.
I kept the crypto IRC channels up whenever I was online, to go along with the other IRC channels I was keeping an eye on.
A 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.
12th March 2008 (2) asks (3) to help with his white paper and code.
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.
Within a week or two (3) begins asking on a few IRC channels for help.
Request For Help
(3) was asking folks on the crypto IRC channel for anyone who could help him with his friends digital money project.
He needed someone to look it over and see any flaws it has and how to improve upon it.
At the beginning of April 2008 I noticed the chitchat among these crypto folks and kept wondering why they were giving (3) so much grief when all he was asking for was some help.
They really ripped into him, telling him that he was wasting his time, electronic money had already been proven to be impossible, that unless the Byzantine General's problem was solved it would be impossible to move data without double-spending, links were given showing all the info on failed projects, and silence, endless silence while the everyday crypto folks continued to chitchat on irrelevant issues which would never impact the world on any higher level.
After a day or so of coming online asking for help, the aggressive responses stopped and they just ignored him.
Just what the [redacted] was wrong with these people ?
Are they so jaded that they've all just given up ?
Are they so reliant upon the "expert" who were saying it's impossible that they just don't bother to think about it at all ?
The GFC ( Global Financial Crisis ) was just starting to heat up.
This was the time to finally crack this nut and figure out a working solution to electronic money.
Even though I hardly knew anything about the crypto tech - I'd only dabbled here and there over the years but never had a concerted and focused effort in learning the stuff - I decided to contact (3) and ask him what's up with these crypto folks.
He told me that he's been trying on many IRC channels and UseNet rooms and other crypto places ( message-boards, forums, direct emails, etc ) to get anyone with crypto knowledge to help him with his friends project.
"This is pretty much what the entire industry is like nowadays," (3) said. "Most of them gave up long ago. There are a few that kept trying but they are always being attacked like this."
"I know the feeling," I said. "I've helped folks on gaming websites with their projects and had the same type of insults and put-downs fired towards them just like these folks have been doing to you."
"Do you have a lot of cryptographic knowledge ?" (3) asked. "I don't recognise your handle and I've been around these channels for quite some time."
"I'm just in here listening out what everyone's talking about," I said. "I've actually been waiting for someone to come along and talk about global digital money but you're the first one to show up."
"But do you know much about crypto ?" (3) asked. "If you do then I can see if my friend will be ok with having you help us."
Well ... that's a turn-up I wasn't counting on.
I was wanting to listen and learn from folks who were actively working on this type of project.
I never thought I'd be in a position to be involved directly with them.
The lack of knowledge I had which was needed to even understand the discussions taking place, let alone understand how to push the tech so that it actually works, meant I'd definitely be a hindrance to any members of the project.
"I know pretty much nothing about crypto tech," I said.
"That's a real shame," (3) said. "You're the only one who has contacted me favourably over this and it turns out you cannot help at all."
I had to agree with him on that.
"I've always had an interest in the crypto tech," I said. "In the nineties I had a choice between learning crypto or learning assembly language on the Win32 platform and chose assembly due to a few countries treating crypto like munitions and saying you're a weapons smuggler if you play around with it."
"You'll find if you have the correct connections," (3) said. "Or job posts within a university you're allowed to practise playing around with crypto without as much of a problem. But you're still restricted in delving into some of the more darker elements of the tech. They have their real name and real reputation attached to the work. Many others use anonymous handles when they want to play with unofficial crypto possibilities."
"You mean they have their feet planted in both the light and dark sides ?" I asked.
"Yep," (3) said. "If their real identities were discovered they would lose their funding and be removed from their positions at the universities. With the loss of position they lose reputation and their real reputation means everything to these people."
"That's similar to my Scronty handle," I said. "Because it's tied directly with my real identity it forces me to make sure it's only ever used publicly for grey-to-light issues in the computing and assembly communities. For anything darker I go anonymous."
"Isn't this Scronty handle of yours anonymous ?" (3) asked. "It's not you real name, right ?"
"Yeh," I said. "But the top folks in the community know me personally by my name. They know where I live. I've even been around the home of the main founder of the Masm32 project and we know each others names, mobiles numbers, and home addresses."
"Then why bother with the handle then ?" (3) asked. "Why not just use your real name ?"
"It's my main internet handle I've used since I first came online in the mid nineties," I said. "Would folks listen to someone with the name of Gonzo the Great ... or Tim ?"
"What's this assembly community you're talking about ?" (3) asked.
I gave him a link to the assembly community and showed him a few of the threads where I helped folks out on various issues.
"You see that guy asking about xxx ?" I said.
"Yeh," (3) said.
"Well, when he asked the question," I said. "I didn't have a clue as to the answer".
"You see that other guy asking about yyy ?" I said.
"Yeh," (3) said.
"When he asked that question," I said. "I again didn't have a clue as to the answer"
"But you not only gave the correct answer," (3) said. "You also suppled an example program showing it working."
"Exactly," I said. "That's what I do. I really don't know anything about any thing. I don't retain information or recall memories like normal folks. I see something, deep dive into the information about it, think up possible solutions, program them up and confirm they work, and supply it as the answer."
"So you're going from novice to expert again and again ?" (3) asked.
"Yep," I said. "It gets pretty exhausting if the problem is challenging. My head runs hot due to the amount of effort the brain's putting into the issue. Hot like when normal folks get ill and run a fever."
"And this is your normal everyday level of activity ?" (3) asked.
"Not always," I said. "I do have to sleep and recharge before I burn out."
"Pretty cool," (3) said. "Do you think you'd be able to help on this project ? Without having expertise in cryptography I don't think my friend would be interested."
"Just tell him what I've just told you," I said. "Give him the links to my assembly stuff. Tell him that I'll be able to learn about crypto as I try to understand your project and point out issues as I find them."
"I'll try but I'm not sure he'll go for it," (3) said.
"Then tell him that what he really needs is someone that's not a cryptography expert," I said. "You've said yourself that most folks in the crypto space believe digital money is an impossible dream. What makes you think someone like that is what you need to help you ?"
"But why would he believe you can help ?" (3) asked.
"Tell him that you guys are having issues because you've got your noses too close to the workspace," I said. "That because you know crypto you cannot see what the real problem is. Having someone that's got fresh eyes in this space and is also capable of learning it is exactly what you need."
"I'll give it a go and see how he takes it," (3) said.
Quite a few emails were sent back and forth between me and (2) via (3) discussing what their problem is and how I might help.
This went on for a couple or three days.
"He's agreed with everything you'd said," (3) said. "But he's still edgy when it comes to showing anyone what he's trying to do. Trust is an issue here."
"Then why is he bothering to try and find anyone to help him get his digital money project working ?" I asked.
"He's not, really," (3) said. "He asked me to help him because we've helped each other out in past. I told him that we need to bring others on board to help work this out."
"Well, he'll have to make a decision soon then," I said. "I'm interested in this topic enough to start looking into it myself - whether helping you folks at the same time or going it alone. Seeing that crypto folks have pretty much given up on the topic means that someone's got to continue giving it a go."
(3) came back about a day later saying that his friend was ok to at least start seeing if I can help out.
"Great," I said. "Now for communication between us, I don't want my Scronty handle associated with this project at all. I don't want there to be any evidence that the Scronty character has anything to do with anything that some folks may deem to be dubious."
"Fair enough," (3) said. "My friend is of the same mind and doesn't want the public to know what he's doing in private. Are you going to create a new handle to use for the project ? My friend says he uses anonymousspeech for his website domains and email accounts."
I had a quick look-over the website.
"No, I'm not going to go to a mysterious website and enter in my credit card details," I said. "I'm not going to create the email account. He is."
"What do you mean 'He is' ? " (3) asked.
"I want your friend to create an email address for me that I'll use exclusively for our communication," I said. "I don't even want it recorded anywhere on a computer that my IP or my credit-card is associated with this project. I'm going to be completely off-the-books."
"I really don't think he'll go for that," (3) said. "But I'll ask him anyway."
About an hour later ...
"I don't believe it," (3) said. "He agreed that having him set up and control the email accounts is a good idea and that he had been thinking along the same lines. He wants to know how you think they should be set up ? Not hotmail, right ?"
"We cannot use any general purpose publicly used email hosting service like hotmail," I said. "But we also cannot use something that looks like it's a private email."
"Wait, what ?" (3) said. "You want us to use private email accounts that don't look like private email accounts ?"
"Yep," I said. "Your friend is going to create email accounts which look similar to the generic everyday accounts that millions of folks see and use everyday. Anyone intercepting our correspondence will just automatically dismiss them. We're not going to have an account like
I told (2) via (3) to generate a new TLD ( Top Level Domain ) for us to use for correspondence on the project so that any current 'net handles are not associated with what we do.
He asked for an example of what I mean.
I gave him a link to one of my Win32 Asm examples and told him to make a TLD that's similar to the generic TLD I was using back then ( the website address in the main file header ).
My old website was using cjb.net - scrontsoft.cjb.net
(3) came back saying that (2) had agreed to create the email accounts and that (2) was wanting my name for the account.
"What ?" I asked, "He wants my name ?"
(3) said, "Yep. And he's waiting right now. Give me your name to use as the account name."
I had to think quickly.
If I wouldn't associate my Scronty handle with this project then like [redacted] would I use my real name !
My full name is Phillip James Wilson.
My father always called me James ( as he thought that was always my intended first name ).
My wife's family were introduced to me as James and have always called me by that name.
But it'd be stupid to just use my middle name straight up.
I told (3) to tell (2) to use "jamie" for my name.
"That's your real name, is it ?" (3) asked. "Jamie ?"
I thought it an odd question to be asked and supposed (3) was just kidding.
"Sure it is", I replied. "It's short for Jim."
"How's Jim short for Jamie ?" (3) asked. "Isn't Jim short for James ?"
"From where I'm from, Jim can be used for both Jamie and James", I floundered. I really didn't know if that was true.
He came back after (2) obtained rcjbr.org and created the two email handles for us.
My email address used the name I'd given (3) to tell (2).
I only found out three years later that they both thought the name I'd given them was my real name, and that (2) had been using his real name all along ( for this super-secret project that we didn't want anyone else to know about our involvement ).
In my very first direct email to (2) I said, "You were supposed to create emails using rcjbr.net, not rcjbr.org !"
"What's the difference ?" (2) replied.
"At a glance rcjbr.net looks similar to cjb.net", I said. "It's supposed to look like one of these anonymous publicly-available accounts. None of them end with .org"
"Well, I reckon it's close enough," (2) said. "If you want to create another email address you can go to anonymousspeech and do so yourself."
All emailing between us from that point on was via these new handles.
I 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.
“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 URL to a website full of crypto-related links and said to go through that and look at the white paper.
It was a list of pretty much every single crypto related article up until that time.
Over 1,700 articles and webpages !
Encryption and Security-related Resources
- Crypto Link Farms
- Crypto Archives
- Crypto Social Issues
- Crypto Software
- Miscellaneous Security Items
- Anonymity and Privacy
- Random Numbers
- Public Key Infrastructure
- Security Agencies and Organizations
- Security Books, Journals, Bibliographies, and Publications
- Security People
- Security Problems
- Security Products
- Access Control
- Data Encryption
- Interception and Monitoring
- Investigative Tools
- Online Commerce and Banking
- Smart Cards
- Snake Oil
- Security Standards, Laws, and Guidelines
I said, "Are you serious ? Have you actually read any of these articles and website ?"
"Over the past few years I've read through all of these articles and followed all of their links and read those as well, " (2) replied.
By Jupiter, This guy must be insane !
I went up and down the list a few times trying out a few of the links.
I began finding that some of these links had died - the webpages no-longer existed.
Those links that did work usually ended up on a webpage with many more links to articles and webpages.
Once a week 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”.
I told him to reduce this huge list down to the top hundred articles he thought would benefit me to understand his whitepaper.
He returned with a list of website links and said to go through that and look at the white paper.
The list had 233 links in it - bloody [redacted].
He'd just copied the entire list from the Security Books, Journals, Bibliographies, and Publications section.
I opened up all the 'A' links and began going through the information one-by-one.
Again, many of the links were dead or the webpages had been updated and the information no-longer existed.
After a few days or so I’d gone through about half-a-dozen papers/websites which hadn’t cleared up anything.
I told him to break the list into chunks of 10, ordered by their importance, and to give them to me ten-at-a-time.
The idea being that when I get through one set of 10 he'd give me the next.
He came back with a white paper and website list that was 22 lines long which was a combination of link+description.
He'd just copied the 'A' group from the Security Books, Journals, Bibliographies, and Publications section.
I'd already read the stuff from the working links for 'A' group, but decided that, if it was going to be up to me to choose my own pace of education, I'll use a system.
I went back to the original list for the Security Books, Journals, Bibliographies, and Publications section and opened up all of the 'A' group links into multiple tabs ( Internet Explorer had come out with tabs just a couple of years earlier ).
30% of the links were dead.
I began reading through the working links - starting at the first.
The Story of Alice and Bob
Alice and Bob have very powerful enemies. One of their enemies is the Tax Authority. Another is the Secret Police.
This is a pity since their favourite topics of discussion are tax frauds and overthrowing the government.
Ummmm, this may be setting the scene for what is yet to come.
Against all odds, over a noisy telephone line, tapped by the tax authorities and the secret police, Alice will happily attempt, with someone she doesn't trust, whom she cannot hear clearly, and who is probably someone else, to fiddle her tax returns and to organise a coup d'etat, while at the same time minimising the cost of the phone call.
A coding theorist is someone who doesn't think Alice is crazy.
Yeh. I like that.
I'd on-and-off over the years heard and read crypto stuff, but this was the very first time I'd decided to put head-down-bum-up and focus on the topic with all my effort.
head-down-bum-up might be a horsing term ( the position you get into when you want to go very fast in a specific direction )
The other thing coding theorists are concerned with is information.
One type of information is called Money.
There are people who refuse to concede that money can be created and destroyed.
They spend their entire lives altering records and making adjustments to ensure that every time a bit of money leaves some place, an equal bit seems to appear somewhere else. These people are called accountants.
So an electronic cash system would need to both create money and keep an account of it.
An Analysis Of Security Incidents On The Internet 1989 - 1995
From - chapter 6
- Stealing passwords - methods used to obtain other users' passwords,
- Social engineering - talking your way into information that you should not have,
- Bugs and backdoors - taking advantage of systems that do not meet their specifications, or replacing software with compromised versions,
- Authentication failures - defeating of mechanisms used for authentication,
- Protocol failures - protocols themselves are improperly designed or implemented,
- Information leakage - using systems such as finger or the DNS to obtain information that is necessary to administrators and the proper operation of the network, but could also be used by attackers,
- Denial-of-service - efforts to prevent users from being able to use their systems.
Any electronic cash system would have to address all of these concerns.
Categories of Attack:
- Interruption - An asset of the system is destroyed or becomes unavailable or unusable
- Interception - An unauthorised party gains access to an asset
- Modification - An unauthorised party not only gains access to, but tampers with an asset
- Fabrication - An unauthorised party inserts counterfeit objects into the system [Sta95:7]
- Hackers - break into computers primarily for the challenge and status of obtaining access
- Spies - break into computers primarily for information which can be used for political gain
- Terrorists - break into computers primarily to cause fear which will aid in achieving political gain
- Corporate raiders - employees of one company break into computers of competitors for financial gain
- Professional Criminals - break into computers for personal financial gain (not as a corporate raider)
- Vandals - break into computers primarily to cause damage
So it's a real mess out there.
Shame the analysis doesn't really provide a solution.
An Electronic Pearl Harbor? Not Likely
Chablis - Market Analysis of Digital Payment Systems
This shows the typical payment systems as currently practiced by the financial industry.
You have the payer ( customer ) and the payee ( merchant ).
A transfer of value goes from the payer to the payee.
There are so many third parties involved I have trouble trying to keep up of who's sending what to whom.
I go through as much of this stuff as possible - trying to get my brain to retain some of it.
Computer Immune Systems -- Research
This is interesting.
Treating a computer security system like an animal's immune system to protect it from outside antagonists.
Immunologists have traditionally described the problem solved by the immune system as the problem of distinguishing "self" from dangerous "other" (or "nonself") and eliminating dangerous nonself.
This is something I've thought about for a long time.
There's no such thing as Evil vs Good or Capitalist vs Socialist.
There's only ever been Us vs Them.
And we only need to decide who is in the Us group and who is in the Them group.
It would have at least the following basic components: a stable definition of self, prevention or detection and subsequent elimination of dangerous foreign activities (infections), memory of previous infections, a method of recognising new infections, and a method of protecting the immune system itself from attack.
Credit Card Transactions
This provides an overview of a credit card payment process.
A single-page is here.
It mentions the First Virtual payment system:
- Neither buyer or seller needs to install any software in order to use the system.
- Buyers are virtually 100 % protected from fraud. No charges are processed against their account without their confirmation.
- Purchases are essentially anonymous. The merchant is never given the buyer's name from First Virtual.
- It is extremely easy to become a merchant, or seller, under First Virtual. First Virtual does not screen merchants, nor do they require merchants to have a special business accounts established with a bank. All a person needs to sell merchandise, services, data, etc.. over the Internet is an ordinary checking account.
- First Virtual has very low processing fees compared to other Internet payment schemes or even straight credit card processing.
- Merchant assumes all risk!
- Extremely long waiting period between when a sale is made and when payment is deposited in the merchant's account.
In the Appendix - Related Topics it mentions e-cash and micropayment systems.
It talks about DigiCash and how it's really just an e-cash system to help banks transfer transaction data across the internet.
Micropayments are said to be in the realm of 1, 10 or 15 cents, which is lower than the fee for actual credit card processing.
All of these things piggyback the current financial payment systems.
Cryptography and Number Theory for Digital Cash
Now we start getting into the meat and potatoes of it all.
An encryption algorithm must be associated with a reverse procedure that restores the original message.
- Algorithms--such as DES or RSA--are, in general, publicly known. This has the advantage that any weaknesses in an algorithm can be found by researchers.
- Any attempt at "security through obscurity", by keeping an algorithm secret, is usually self-defeating, because it will most likely simply mask weaknesses in the algorithm itself which could be exploited by anyone who has figured out what the algorithm is.
- But when a good publicly-known algorithm is used, security depends on the length of the key, which may be thought of as a string of 0s and 1s used in the algorithm to transform the data.
So don't roll-your-own encryption algorithm.
I make a proggy ( small program ) to test out the idea of using XOR addition to change a string sentence inputed by the user into junk and back again.
Encrypted message C = M + k
Where M is the message data and k is the key.
If M = 1011 and k = 1010 then C = 0001
If the encrypted message is XORed with the key again, we get the Message back.
So M = (M + k) + k
Security depends on the length of the key k.
In general, for a key of length N, there are 2 to the Nth power (2^N) possible keys.
A brute forced attack can now break DES which has a key length of 2^56 (2 to the 56th power).
2^128 is quite secure.
Electronic code-book (ECB) mode encrypts each 64-bit text block individually.
Cipher Block Chaining (CBC) is a mode of DES encryption in which the current 64-bit plaintext block is XORed with the previous cipherblock before encryption with the 56-bit DES key k.
That's seems a wee bit weird.
So if you've got 4 chunks of 64-bit data, then you:
- Encrypt the first 64-bit chunk with DES (2^56)
- XOR the second 64-bit chunk with the results of the previous step
- Encrypt the second XORed 64-bit chunk with DES (2^56)
- XOR the third 64-bit chunk with the results of the previous step
- Encrypt the third XORed 64-bit chunk with DES (2^56)
- XOR the fourth 64-bit chunk with the results of the previous step
- Encrypt the fourth XORed 64-bit chunk with DES (2^56)
Cipher Feedback (CFB) is the same except the XORing happens after encryption.
The biggest problem here is that both people involved in moving data ( transmitter and receiver ) need to have the exact same key.
This means you need to find a way to send the key to the other person in such a way that it cannot be intercepted and known.
This might include embedding the key inside a digital image and emailing the image to the person ( or place the image on a website and tell them to have a look at it ).
XOR is a type of symmetric key algorithm.
Public key, or asymmetric, systems, by contrast, use two different keys for encryption and decryption.
- Public key systems are typically based on relationships from number theory, and the process of encryption works by raising the message M to some power a: C = M^a.
- Decryption works by raising the encrypted message C to another power b: M = C^b.
- The first key, or power, a will be known to everyone--hence it is called a "public" key-- while the key b will be kept secret by the user--hence it is called a "secret" or "private" key
Diffie-Hellman & Discrete Logarithms
It provides a secure way for two parties to agree on (negotiate) a shared symmetric key by which to encrypt their current exchange of messages.
So you can switch public keys and no-one will be able to read the messages ?
No more having to find special ways to swap keys.
The secret random integer values shown in Steps in Negotiating Diffie-Hellman Key Agreement seem to have been selected so that the algorithm comes out correctly.
Choosing any other random value and the equations fail.
Let's see if the RSA Public Key System steps are any better.
- Get two large primes p and q
- Modulus n = p*q
- Euler's totient t = (p-1)*(q-1)
- Then it loses me when trying to describe how the public and private values are computed ( because it doesn't say )
Hash Functions & Digital Signatures
- Digital signatures are hashes of messages that are encrypted with a private key.
- Recipients can decrypt using the public key to verify the hash was signed
- A hash of the message can be made and compared with the decrypted hash to verify the data has not been altered.
- It's recommended to use SHA-1 for hashing which creates 160-bit long hashes.
- Suppose a customer wants a bank to sign a piece of digital cash with the serial number x, but does not want the bank to know which piece of cash it is signing.
- By using a blinding factor r, where (e, n) is the bank's public RSA key, the customer give the bank x*r^e mod n
- The bank signs this with its private key which allows everyone to use the banks public key to confirm it's valid.
- The bank cannot know whose cash this is belongs to - only that it is valid.
- Only the customer can decrypt the cash to be passed along to another person.
One way is using Zero-knowledge Proofs & Schnorr Protocols
You prove who you say you are by signing a random number supplied by the merchant with your private key.
The merchant uses your public key to confirm that the random number is returned.
I start up a conversation with (2) again to discuss everything I've read so far so that my understanding is correct.
"Wouldn't Man-In-The-Middle attacks be possible with this system ?" I asked. "Someone that's in the network between the merchant and the customer could send their own random number to the customer and confirm the proof and then in turn sign the merchant's random number with their own."
"They wouldn't just have a random number," (2) said. "They'd include something that's specific to the customer like an email address or mobile number. A Man-In-The-Middle wouldn't be able to spoof that as the customer would enter the email address into the merchants payment system."
"Unless the payment system is on a website and that website has been compromised," I said.
"Then the merchant would never be included in that transaction, " (2) said. "It'd be a facade site that just looks like a real merchant and the merchant would know nothing about it."
"So how would we stop that from happening ?" I ask.
"There's this thing called two factor authentication or 2FA," (2) said. "It means that whenever you want to make a transaction that you want to protect the software will send you an email with a link or an SMS message with a passcode which allows the transaction to go through. Any Man-In-The-Middle wouldn't have access to your email or mobile phone so it makes the transaction safe."
"That makes sense I suppose, " I said. "If someone has access to your email account or phone your probably [redacted] in many other ways."
"Yep, " (2) said. "If they had the email account or phone device they wouldn't even be bothering trying to pretend to scam you out of an online purchase. They'd move money directly out of you bank account directly."
"And what about this Schnorr signing thing ?" I ask.
"Don't bother with that one, " (2) said. "Elements of it have been under patent for the past few years so no-one is going to use it until the patents expire."
"Kinda like the GIF patent, right ?" I said.
"What ? The image format ?" (2) asked.
"Yeah," I continued. "At the end of the 1990's the patent for the GIF file format was sold and the new owner begun filing legal notices to everyone - mainly large companies - to cough up the funds to license the format. It was the number one image format on the internet at the time and this was during the dotcom boom."
"So what happened ?" (2) asked. "We use PNG and JPG files for images now, don't we ?"
"Yep," I continued. "A thread began on CompuServe about how we should fight this patent by creating a new image file format that had the benefits of GIFs - transparent backgrounds - and compression similar to JPEGs. Over time the format was decided upon and coded up and out popped the PNG file format. The format was so much more superior to GIF that it ended up superseding it."
"Not's not completely true though, isn't it ?" (2) said. "GIF animations are still all over the internet today."
"Well, the use for animation was also part of the discussions," I said. "Should we include the animations inside of PNG like GIF or not. In the end there was a second file format called MNG which was an animation-specific version of PNG. It never really took off and GIF was kept for having animated images."
"So why did we head down this path on GIF patents for ?' (2) asked.
"Because, " I said. "By the time the Schnorr patents expire the community might've come together and created something superior to it, making it obsolete."
"You don't know the crypto community very well, do you ?" (2) said.
We continued to talk about the various aspects of crypto usage and I carried on reading through the cryptographic resources.
I bounce around a few links and websites like cryptodox and end up on an NSA site which explained Elliptic Curve Cryptography.
What was really quite interesting is the table comparing the differences between RSA and Diffie-Hellman Key Size and Elliptic Curve Key Size.
Key Size (bits)
|Symmetric||RSA and Diffie-Hellman||Elliptic Curve|
This means that if we wanted to have really stronger encryption over the internet we should choose Elliptic Curve encryption because we could then get the equivalent of an RSA key of 15,360 bits with only 521 bits of Elliptic Curve.
Even just using to lowest level ( 160 bits ) would yield the same security as an RSA using 1024 bits.
- To use RSA or Diffie-Hellman to protect 128-bit AES keys one should use 3072-bit parameters: three times the size in use throughout the Internet today.
- The equivalent key size for elliptic curves is only 256 bits.
After going through a few dozen websites and articles I decide to give the brain a rest and look around for any electronic cash specific articles.
I skip down to the Online Commerce and Banking section.
Internet-based digital cash seems to have something on e-cash.
As private as cash ? Even a scheme designed to allow direct peer-to-peer fund transfers, without the intermediation of an entity functioning as a bank, could be configured to keep records of every transaction.
The return of bartering ? Yet the concept of merchant and consumer will inevitably change; we will see much more person-to-person buying, selling, swopping and bartering.
I bounce around a few of the various links on this site.
At one stage I end up on Magic Money Digital Cash System
It mentions using ecash in specific denominations of powers of 2 (1, 2, 4, 8, 16, 32, 64, 128...).
This went on for a couple of weeks until the websites and articles began repeating each other.
(2) and I would be discussing some of the stuff I'd read and he'd come back with references from sources I was yet to come across.
Some of the definitions for ideas and examples were quite peculiar and obscure.
"So which link is this info from ?" I queried. "I haven't read about that anywhere."
"This link here," (2) said, as he posted a URL to the article or reference.
"Interesting stuff," I said. "But where in the [redacted] huge list you gave me did you get this from ? There might be related items nearby."
"Oh, I didn't get this in that list I gave you," (2) said. "I've been scouring the crypto UseNet and mailing lists for quite some time and have dug through many of the references given in the reference section of any articles and white-papers that I've ever come across."
"When do you have the time to read all that ?" I asked.
"I'm a fast reader when I have to be," (2) said.
There's just no way he could've read every single item in this huge list, plus the articles listed in many of the linked websites, plus all the references listed in each article.
That would've taken years.
Surely a lot of skipping would've happened.
After a couple of weeks intensively going through the list of articles I came to the conclusion that (2) hadn't actually read much of the stuff on this website page.
He'd read the specific topics, however he'd come across the information from alternative sources.
When we'd discuss RSA I'd be referencing from articles within the huge list and he'd reply with links to sources outside that list.
Every. Single. Time.
So if this wasn't the main list he'd used to learn what he needed to write his whitepaper then surely I wasn't locked into it either.
Instead of going though the articles and websites one-by-one in order I decided to start randomly moving up and down the various sections and following there references to other sources just like (2) had done over the years.
The crypto is crypto and you really needed a mathematicians mind to wrap your head around some of this stuff.
And many, once they're inside that particular headspace, can never leave it.
That's when you see articles written by an expert mathematician that only other expert mathematicians could possibly understand.
But many of the crypto solutions to the double-spending problem were so archaic and difficult to comprehend that even the experts were baffled and it often came down to "I trust this person not to damage their reputation so I'll agree with their conclusion".
Or the rebuttals to white-papers were equally baffling.
I've been in this type of situation before.
During the Win32 Asm days I had to move 3D objects in 3D time and space.
One way of doing this was by using 4x4 matrix computations.
Rotation and translation on the x, y, and z planes plus scaling.
During normal programming you want to spend your time on the higher level objects and abstract the difficult math away.
And so you deep-dive into the math for matrix calculations and create program functions which allowed you to tell it where your object is, where it's facing and its velocity and have a function pop out where the program should draw it upon the screen.
After creating many matrix functions for everything from rotation of simple static objects, to how a car moves along a street, to how an aircraft banks and turns, to how a space craft rotates and thrusts, to how the camera works, you end up with the entire mathematics abstracted away and no longer have to deal with it ever again.
You only need to know which function to choose and how it will move your object.
I needed to find something similar for this electronic cash double-spending solution.
Surely someone out there would've done the same as I had done and abstracted the complex stuff away so that normal folks could use and understand it ?
I scrolled the huge list down to where it mentioned well-known crypto folks and I began to read through them.
- Links to home pages of cryptographers
- Links to cryptographers
- Ross Anderson
- Mihir Bellare
- Steven Bellovin
- Eli Biham
- Wei Dai
- Dorothy Denning
- Oded Goldreich
- Shafi Goldwasser
- David Jablon
- Bob Jenkins
- Phil Karn
- Lars Knudsen
- Markus Kuhn
- Stefan Lucks
- Terry Ritter
- Ron Rivest
- Phil Rogaway
- Greg Rose
- Ken Shirriff
- William Stallings
- Doug Stinson
- Serge Vaudenay
- Boudewijn Visser
- Bennet Yee
- Yuliang Zheng
Some of these links went to websites I'd already visited.
I kept going through one-by-one and to any links they had on their sites.
It was becoming clear to me that the whitepaper that (2) had already written wasn't going to work due to its reliance upon a third party server for time-stamping.
We kept referring back to articles and webpages in this giant list.
(2) would mention something and give a link to some obscure reference and I'd reply with a link to another article.
For the coming months we were going back and forth validating and backing whatever we were saying with references to experts.
P2P or Bust
After working steadily through many crypto articles and websites, learning the crypto basics and seeing how they applied to what (2)'s white paper was saying, I came to the conclusion that his version would fail just like all the other previous electronic or digital money attempts over the years.
I could finally see why all those folks on that crypto IRC channel were giving (3) so much grief when he was asking folks to help him and his friend on this project.
I told (2) that I really didn't see how his version of electronic cash would ever fly.
"I'm out," I said.
"What do you mean out ?" (2) asked.
"I'm done trying to get your electronic cash thing working," I said. "It's just never going to work when you've got to trust a single server for the time stamping mechanism."
"Then we'll use half a dozen," (2) said. "We'll use ten, twenty servers for the time stamping."
"The number of servers is not the issue," I said. "If there's a single server that the network depends upon then the network will never be safe."
"Are you saying that if we've got a hundred servers doing the time-stamping and having the software randomly choose which one to use for each transaction transmission, that the network itself is unsafe ?
"You're not getting it," I said. "If there's a single server that's controlled by a single entity then the network will never be safe. There will always be an attack vector from within that entity. Having a thousand servers controlled by a single entity has the same risk as a single server controlled by a single entity. It's the elephant in the room that the computer security industry always ignores and pretends is not really there. The attack vector comes from the employees of the server owners. You must trust the server administrators."
"So what do you propose we do ?" (2) asked. "I'm not going to give up now. I've put too much of my own time and money into trying to get this working."
"There's been the occasional person saying what to do about this," I said. "The only possible way for this system to work is if we use a peer-to-peer network."
I look back through my notes and bookmarked URLs and pass along every place I'd found in that huge crypto list where someone mentioned using peer-to-peer connections to remove trust in third party servers.
"Yeh, I remember reading some of these," (2) said. "But you can only create a network like this if you also solve the Byzantine Generals Problem. Everyone agrees that it's impossible to solve. People far smarter than us have been working on the solution for years, decades. We cannot use a peer-to-peer network. You'll notice that those people who say to use P2P don't actually show a working solution."
"Well, without being able to use a peer-to-peer network this thing will never work," I said. "So I'm off the project. Good luck with it."
"Can't you figure out a way to use P2P but without needing to solve the BGP ?" (2) asked. "If P2P is what I need to get my digital money system working then that's what I want."
"You said yourself that the entire industry believes it's impossible," I said. "Do you really think we can go up against 100,000 experts with a million hours of expertise between them ?"
"You said you'll help me with this," (2) said. "I even went out of my way to create private email accounts for us to work on this project. You can't just leave."
"Sure I can," I said. "I only ever said I'd try to help you. I never said I'd succeed. I even said if or when there came a time I could no longer help you on your project then I would leave."
"But what should I do now ?" (2) asked.
"Just go with the white paper and code as you currently have it," I said. "Use some of the ideas and modifications we've discussed over the past month and a half."
"I want this to work," (2) said. "I want this to be better than any of the previous digital money versions. You've convinced me that it must use P2P and I don't want to make something that's second-rate."
"Well, that's what you're going to have to do," I said. "Use your idea of using multiple servers for the time-stamping. It's not the best solution, but the best solution is currently impossible anyway."
"All right then," (2) said. "I'll have the time-stamping servers set up as a P2P network so that attackers can't take them all out."
And here ends my involvement with (2)'s digital money project.
Over the coming week I felt relieved that I was finished on that project.
It really didn't seem it was going to go anywhere due to the inherent problems being the exact same problems all the other past failed attempts had.
But this thing kept niggling at my brain.
I remembered how folks act in group settings.
When someone tells a joke there's often a slight pause while folks in the group hesitate and wait for signals and signs that the joke was funny to the group and it's Ok to laugh.
The very worst thing to do in a group is to laugh out loud to a joke you thought was funny but your peers didn't.
You instantly get bad looks from them.
Frowns, shaking of the head.
Far better to keep quiet until the group tells me it's Ok to laugh out loud.
These signals are usually not of a conscious nature.
Our brains pick up these signals automatically and the reaction it automatic.
It's the thing that gives us stage-fright.
The fear of being ostracised from our society, our peers.
The same thing would be happening to these 100,000 crypto experts and academics.
The 100,000 experts are incentivised to conform with their peers otherwise they'll be ostracised from the community, lose their funding and be thrown out of their universities.
These experts cannot think or write about anything radically different to what all their peers write and think about.
Their papers only provide incremental improvements on top of currently accepted theories and beliefs.
When a few folks studied Quantum String theory in the mid 1980s the entire scientific world descended upon them, crushing them.
Until a few more prominent researchers also studied it and began to say it may be correct.
There might actually be a solution to the Byzantine General's Problem but it cannot come from anyone currently working within the field due to peer pressure.
To [redacted] with it ! I'll give it a go myself !
I'm still going to need to chat with someone who has a lot of cryptographic knowledge.
I look through the UseNet and mailing lists for possible candidates.
Some of these folks appeared familiar - either from the crypto articles I'd previously read or from being mentioned by (2) and (3).
Looking through a short list I come to the conclusion that It may be better to have someone else communicate with these folks directly.
I thought not one of them would go out of their way to create anonymous email accounts for us to correspond through.
Even though (2) and (3) weren't as high in the crypto world and as knowledgable as the folks I wanted to interact with, they had factors which placed them far above any of these others.
They were driven.
He really wanted a practical working solution to digital money.
They'd already proven themselves by their actions.
Their reputations with me were completely merit based.
Many of the high level crypto folks were busy stroking their egos on the message-boards and mailing lists and IRC channels.
Many just wanted to argue and never actually produce anything concrete.
There were still issues with how (2) communicated and misunderstood some of the things we discussed.
Some of the links and information he gave were really hard to understand or see the relevance to the topic.
But he was tenacious.
And sometimes being tenacious and driven is far more important than going through life on idle.
I'm going to have to see if they'd be interested in helping me on my own electronic cash project.
It's very likely they'll tell me to go and jump, but it would be worth making the attempt.
There was something else that had been talked about since the early nineties.
With the advent of the internet we should begin to see folks coming together from all over the world to work briefly on a project and then moving on to other projects.
That hardly ever occurs.
It happens in a few startups.
For my project I wanted to see just how far the bar could be pushed.
Have folks from all over the planet join in to help on a project.
Some stay for a short time.
Some stay for years.
And to make it impossible; Each person didn't know who the others were.
Anonymous folks coming together to work on a super secret project.
A shield to protect them all.
A project, if it succeeds, that will have a greater influence on the human species than any other normal project where folks were in the same physical location.
Trying to find a practical solution to the Byzantine General's problem without it relying upon a third party was impossible.
Or was it ?
In The Hitchhiker's Guide to the Galaxy, there was this concept of an Infinite Improbability Drive.
The idea is that there really isn't anything that's impossible.
Just merely improbable.
And if you could calculate the improbability of something occuring, you would then be able to accomplish that thing.
So if I could figure out the improbability of figuring out the solution then I'd be in with a chance.
I'd have to start going through as many message-boards and UseNet groups as I could and try to extract their membership lists and filter out any duplicates.
Then try and find the average years of experience they have in the industry.
And from that see if I can guessimate just how many years of expertise is against me figuring out the impossible solution.
In the first week of June, 2008, I contacted (2) again and told them that I was going to give it a go and figure it out myself from scratch.
"You're not going to use any of my work," (2) said. "I only brought you on board to help me with my project. Not for you to go off and do your own based upon my stuff."
"I won't be using anything that you've come up with," I said. "You have been involved in the conversations over the past month or so, haven't you ? Or have you just been a delegate for someone else and I've been talking to another instead of you ?"
"No, you've been talking to me all along," (2) said.
"Then what part of <This [redacted] just won't work> don't you understand ?" I said. "I won't be using any of your stuff because from my perspective it's all broken because it's using ideas from previous flawed attempts. I need to start from the very beginning and work from the ground up."
"So why are you telling us this ?" (2) said. "Just go ahead with it and we'll carry on with my project. When you publish a whitepaper or release code you'll know for certain I'll be checking it for any similarities."
This wasn't going very well.
"You misunderstand me," I said. "I need folks to help test any of the ideas and solutions I come up with. To make sure I don't miss some fatal flaw."
"So what are you saying ?" (2) said.
"I want you both to help me while I figure this thing out," I said. "If I succeed then you get the digital money system you want. If I fail then at least we made the attempt."
"What ?" (2) said. "You now want us to work on your own project ? What the [redacted]!"
He wasn't very pleased with the proposal.
"Look," I said. "Your project is still there, right ? You can continue as you are and also try and help me do the impossible. As I figure anything out you can modify your own project to include it."
"All right then," (2) said. "It's good to see you're back on the subject again. How long do you think it'll take to come up with a solution ?"
"Dunno," I said. "It's taken the crypto and computing world a few decades to fail to deliver a solution. So give me at least half a decade to fail also."
I read a book called The E-Myth Revisited which talked about leveraging others so you can amplify the work being done.
I decided to begin my project by using as much leverage as possible.
Effectively this would mean trying to get (2) and (3) to do absolutely everything outside of the actually figuring out solutions to the problems.
(2) and I were discussing the idea of using a Development Name for the project so that we could talk about specific ideas with others without them cottoning on to what we were trying to create.
I was telling him about how Microsoft's Windows Vista was called Longhorn during development.
(2) said, "It should be something more specific to the project, but not too obvious. Maybe something from the ancient Greek myths."
"It's odd that you should say that, " I replied. "About a week ago I bought a Greek Myth book from a local book store. It covers all the greek myths."
"You're kidding me ? " (2) said. "You have really just bought a book on this ?"
"Yep, " I said. "I'll go through them one-by-one and you choose which one we should use."
"Ok," (2) said. "Go for it."
"There's a few dozen here, so it may take some time, " I said.
"Here we go..." I began. "It begins with Land, Sea and Sky myths ..."
When we got to page 134 it mentioned Prometheus stealing fire and wisdom from the gods.
"Put that one aside as a possible choice, " (2) said.
We continued, with me typing out each myth, god and titan and both of us discussing and dismissing each in turn.
After an hour I was beginning to think I was doing this "leverage others" a wee bit wrong.
Instead of leveraging (2) to do work and come up with a name I was now expending even more energy than I would've if I just did it all myself.
I'm going to have to re-access this leveraging idea again after this and decide which tasks I do and which tasks others do.
When I got to page 249, Prometheus appeared again.
This time it expanded upon what we'd read earlier and said Prometheus saw that [humans] lacked some of their basic requirements and so he stole fire, crafting and metalworking skills from the gods and gave them to [humans].
"That's the one !" (2) exclaimed. "We'll use Prometheus as the development name for this electronic cash project."
"Are you absolutely sure ? " I asked. "That first mention about Prometheus had a picture of an eagle pecking at his body. Not a good omen. Surely you can't be serious ?"
"It's the best choice so far, so let's use it, " (2) said. "And don't call me Shirley."
For the coming months we used Prometheus as the project cover-name in some correspondence.
I had to start from the very beginning.
Or begin at the start.
Given a computer network there had to be transactions sent to a recipient.
(2)'s previous 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.
We knew that a piece of electronic cash would be minted somehow, however once it was minted how could it be sent to someone else ?
(2) and I went back and forth with a few ideas, going through the physical process of different transaction types one by one and adjusting how a transaction data package would look like.
We began with a single piece of e-cash.
Like a piece of gold, it should be able to cut smaller pieces off of it.
That means by starting with one item we’d end up with two - the piece going to the recipient and the change coming back to the original owner.
I told (2) that when drawn into a diagram it looks like a neural network.
If we had a large piece and were paying that entire amount to someone then the input and output pieces would be the same.
If we had a large piece and were paying a small amount to someone then the input would be the large piece and the outputs would be the amount being paid plus a small piece as change.
As more people are paid we’d end up with a lot of small pieces in our wallet.
If we had a small piece and needed to pay someone a large amount then we could combine multiple small pieces to be equal or larger than the amount to be paid, and refund back to ourselves any change left over.
This means a transaction would have to allow multiple inputs and multiple outputs, with each input signed by the current owners private key and the outputs being the new owners public key.
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 keys
- Make sure the public key was sent to a very specific location so that we could “trust” that the public key was valid
- Use this quirky little command line proggy where I included my email address plus a link to the private key
- Embed the generated data into the email
This 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 wasn't in that list of 1700+ docs/websites at all.
It was to Hal's website where he very clearly explained how something called "Hashcash" worked.
He explained quite clearly how proof-of-work functions.
The idea of RPOW ( Re-usable proof-of-work ) is to generate a token ( coin ) once and be able to reuse it similar to folks reusing physical coins when they hand them to each other for payments.
His site mentioned something about bit gold with a link to Nick Szabo's Shelling Out article.
It was an interesting read, however it never mentioned what bit gold was about.
I followed a link on the Shelling Out page to Nick's main table-of-contents page
Starting with the first article, I began to read each one to try and find information about this bit gold Hal had alluded to.
After a dozen articles I gave up and decided it was probably something similar to all the other ideas out there but using Reusable Proof-Of-Work as the coin.
From there I went on to Adam's site:
(which was also not even in the original huge crypto list at all).
I read the Hashcash white paper sections until I hit the calculations and my eyes begun to glaze over.
I 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 Win32 Asm 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 a 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. The sender's and the recipient's email address is part of the header. If the sender email is the same as the person who sent it to you ( the Return address ) and the hash of that header matches the one you generate then you know it's coming from the same person."
It forces the user's 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's 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 recipient's 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.
“You’re saying that we can use this proof-of-work thing to inject electronic cash into the network and have it tied to fiat currencies, but how would the network know what the local fiat currency is to figure out the correct fiat-currency-to-electronic-cash exchange rate ?”, (2) asked.
“Maybe we could have a server that keeps a record of what the various electricity companies charge and have the software get the values from there ?”, I suggested. “Some of these new mobile phones, the smart phones, the cellular network phones in folks pockets, have GPS chips incorporated into them, right ? And everyone has them or will be getting them as they become more popular. This means everyone will have a device on them which will allow the software to include a GPS location so that the network knows which exchange rate to use for that particular minted cash.
“But how will the network know that the GPS coordinates haven’t been changed and set to another location ?”, (2) asked. “Wouldn’t that mean relying on a trusted third party again ? I thought you said we have to get away from that ? If we cannot trust a single computer for minting cash into the network then maybe we shouldn’t trust any at all ?”
“Uhh… dunno,” I replied. “I’ll get back to that later”, I said.
“Ok, ” (2) said. “How are we going to have the transactions sent to other people on the network ? All the other white papers are expecting people to connect directly to one of the trusted computers to purchase the electronic cash and to transfer it to someone else through them. If we’re not going to use a trusted computer for this and will have the proof-of-work generate the cash, then how do people receive or pay the cash ? Also: How would the network trust that the cash is valid if no computer is being used for time-stamping and validating the cash ?”
I told him I’d have to think about it.
Multiple ideas were given and discarded. He consulted with (3) about every possible solution and every one was a failure.
They either resulted in having to rely on at least one server to hook everything together or would break if multiple transaction messages were sent at the same time to different computers.
After a week or so of this I’d finally burnt myself out and decided that it’s quite possible that everyone else was correct when they said that you couldn’t solve double-spending in a digital world without depending upon a trusted third party.
I stopped emailing (2) at that point, hoping it’d all go away.
After a week he emailed me asking if I’d come up with another solution for testing.
I told him that I don’t think there is a solution and maybe he should just use part of what he had in his original white paper and rely on a trusted third party like everyone else.
He said something along the lines of “Like [redacted] I will ! You’ve taken me down this path of not trusting a single computer and that’s what I want. No-one's done that before and if we crack that nut, it will probably change everything ! ”
I told him I’m taking a break from it all for a while.
Another week passes and he emails me again.
He said, “How are you feeling ? Sorry to be so harsh on you but I really need this to work. I’ll leave you be if that’s what you want. Just let me know when you’re able to continue.”
Another week goes by and whenever I begin to think of the problem I just say to myself “To [redacted] with him and his electronic cash problem.”
For comfort I turn to perusing through some of my old Win32 Asm proggys ( I called them “proggys” because I thought of them as small, incomplete computer programs - kind of like examples and tutorials ).
I also begun reminiscing about the Amiga 500 days and the proggys I made back then ( late 1980’s through to mid 1990’s ).
Knowing that one of the most difficult issues with electronic cash revolved around the networking architecture and how data would be propagated by the networked computers I began going through some of the discussions I had back in 2005 and 2006 with someone who was attempting to make a tank game.
I explained to him the main difference between TCP and UDP ( Transmission Control Protocol and User Datagram Protocol ).
If you need data packages to arrive in a particular order with confirmation that they’ve arrived then you’d use TCP.
If you need velocity of data packets you can throw all the protocol error checking out and use UDP.
That’s one of the reasons great online multi-player games uses UDP. It reduces the latency with the data being transmitted around the network.
The main difficulty is in building the gaming system in such a way so that the data the servers and clients transmit and receive work when data packets never arrive.
TCP guarantees delivery if the network is functioning while with UDP you do not know if a particular packet ever arrived or if packets arrived in a different order to transmission due to separate packets traversing the internet via different pathways.
Many online games were usually built for single-player first and the multi-player code would be chucked into the code-base near the end of development.
This would mean that all of the game code objects and classes were made to use known values at any particular time and could not work in a UDP environment without re-architecting the entire code base from scratch.
You’d find many of the games that also included multi-player gameplay options ended up using TCP for the network communications and this made all of these games slow over the network with high latency and unplayable lag as the gameplay would be faster than the network data packets telling your computer where your opponents are located.
The various tanks games around 2005 were built as above. I persuaded this person to focus on the multi-player aspect of the game because he could always add in single-player later on.
Multiple players would have to drive and fire tanks around a field while being updated continuously about the complete state of the network.
This is usually accomplished by having a single server that receives all of the current data from all the player clients and dishes out the official game state back to all of those player clients so that everyone knows who went where, who fired at what and who has been hit.
However even with using UDP there is a bottleneck in the network with the server itself only being able to process a peak number of connections and data throughput every second. It could only scale so high.
We had talked about different ways to improve this by possibly having relay servers on some of the players computers or having a more peer-to-peer like structure so that each player's client only had to get the latest data from its nearest neighbours in the network and only transmit to their peers so that a fully server-less multi-player game could be created.
How the data could be moved about without someone creating a hack that could change the data packages in their favour couldn’t be figured out.
In the end he went with using a central server with both TCP and UDP depending upon what data packages were needed to be sent - general gameplay data (tank movements) via UDP and server state (for confirming who hit what) via TCP.
If a peer-to-peer network was to be used for electronic cash then to be scalable the data packages must be able to be transmitted with as high a velocity as possible. It must work with the majority of transmissions using UDP.
If two-way communication is required then a return ip/port can be included within a UDP data package or a TCP connection could be used.
I had also read and reread this thing that has been going around the crypto community for ages called the Byzantine General's Problem (or worded in a similar way).
It’s supposed to be impossible to solve and at least a couple of well-known academics and crypto folks had “proven” it was impossible to solve only a few years previously. They had pretty much staked their reputations on the fact that it was unsolvable.
I thought “Wouldn’t it be absolutely hilarious if the solution to this double-spending problem is also the solution to the impossible Byzantine General's Problem and could be found using ideas from the Amiga days and 3D programming and uses multi-player gaming techniques ? That would annoy the [redacted] out of the crypto community and take those elitists down a peg or two !”
(This is where you’d see the screen go all watery-wavy as the scene morphs to a time in the past when I was a moderator of the Win32 Asm community)
The assembly community and the crypto community share a lot in common.
They’re made up of some of the most brilliant folks in the computing industry where huge egos do battle against one-another.
You’d also find folks in one community existing within the other.
Both communities are made up of both light and dark actors.
The light actors are those who are very public.
They are academics, researchers, security professionals, and so on.
The dark actors are … (and that’s all I’ll say about them).
Except to say that the light crypto actors are usually doing work to undo what the dark assembly actors are doing.
It’s one [redacted] of a game !
To have a message-board that was able to accommodate all actors required a few tough rules and stiff execution of them if the forum was to continue to exist.
Many of the other assembly boards were being snuffed out by government actors forcing the hosting service to shut them down.
This was mainly due to the assembly forums insistence of allowing threads to exist which showed exactly how to break and crack various websites/ networks/ software/ etc.
Whenever one of these sites were shut down the members would disperse to the various remaining assembly boards.
So we received an influx of new members every few months whenever their previous venue went up in smoke.
However they never learned from the experience ( or, at least, some of them never learned ) and they would continue to openly chat about dark subjects on our board, which put our board in danger as well.
The moderators had to be strong but fair against these new-comers, especially knowing that they ( the moderators ) could be actively attacked ( digitally ) at any time.
Occasionally one of these new members would decide to DDOS ( Distributed Denial Of Service ) us, however they apparently forgot what message-board they were attempting to DDOS, and it always ended very badly for them.
We would also occasionally get someone with quite a bit of knowledge in various subjects - some of it very rare and hard-to-come-by. It would be terrible if that member left and took their knowledge with them.
They would complain that there were too many noobs asking questions on the message-board and it would be better if there was a higher level of knowledge and experience needed before the noobs could enter the message-board or post a question.
Once I told one of these members, “Ok then. Let’s say that thing you’ve been talking about for the past two weeks, and calling everyone else a noob for not understanding it, is the knowledge limit. I know that you only first read about it two and a half weeks ago. Let’s say I make that the limit and predate it three weeks ago and kick your butt out of this community ?"
“That’s not very fair”, he protested.
I told him, “None of us know where the next genius is coming from. The main members of this community, the ones that input more than everyone else, have come from incredibly varied environments. Some with only a few weeks knowledge are adding more to the community every week compared to members who have been with us for years. One of the members you’ve dissed in the past couple of weeks could in turn create the next piece of software that all of us use. We don’t know that. What we need to do is have a community that is absolutely inclusive for every single person on the planet no matter where they’ve come from, what their wealth is, what their nation state does, and to keep our elitism in check.”
“Ok, fair enough, I’m sorry, please don’t kick me out.” was the usual result.
These were very intelligent folks, however they had to be reminded that we are a single species moving through time and space together as one.
(This is where you’d see the screen go all watery-wavy as the scene morphs back to me figuring out this double-spending problem)
As you may tell, I don’t tolerate elitist attitudes very well.
Which also helped when I turned towards the elitist attitudes I read in some of these academic papers and crypto white papers ( some of which were more like notes than white papers ) and messages on the crypto forums and mailing lists.
“ ‘It’s impossible to solve the Byzantine Generals Problem’ they say ? Let’s see about that !”
Byzantine General’s Dilemma
The first thing to do was to discard everything all others had tried before.
For surely if they were on the correct path it would've been solved by now.
The problem is written a little bit differently depending upon where you read it.
An occasional academic may be more well-read than others and becomes the “official” wording used by many others.
I’ll paraphrase it a wee bit just so you get a general idea of the problem (pun intended).
We go back to the time of the city-states.
This is before the notion of sovereign states - there’s just a bunch of individual city-states that control the surrounding nearby country side.
Every so often a bunch of these city-states would get together and form something called an empire.
Alliances would change and friends would become enemies and enemies friends on a month-to-month and year-to-year basis.
To expand the empire the bunch of city-states would send armies controlled by generals to take over an adjacent city-state.
These city-states are huge (for their time) walled cities with armies in strong fortifications.
Let’s say there are six generals from six empire city-states that surround an adjacent city-state - all generals and their armies are equidistant from each other.
They cannot trust one another because at any moment one of them may become an enemy. Or they could be an enemy pretending to be a friend.
Due to the defensive forces of the defending city-state, the six generals know that they could take the city if every one of them attacked at the same time from around the city.
But if only a few attacked and the others retreated then the attackers would be wiped out and the surviving city-states, with their generals and their armies intact, would end up over-powering and enslaving their previous friendly city-states.
No-one could trust any other.
( This has massive parallels with modern day sovereign nations and their playing of the game with weapons, armies/air forces/navies, economics, currency, trade agreements, banks, education, health, wealth, and so on )
The generals have to send a message to the other generals telling them if they’re going to attack or retreat.
The problem is that a general could send a message to the general to his left saying that he’ll attack and send a second message to the general to his right that he will retreat.
Some possible solutions said that there should be two lieutenants to receive the message from the general and that they could check each others message to confirm that they are indeed identical before passing the messages onto the left and right messengers.
However the messengers in turn could change the message from “attack” to “retreat” or vice versa or not deliver the message at all.
Plus the generals, once a message has been sent out as “attack” could turn around and retreat, or vice versa.
I thought to myself, "I bet the folks who thought up this problem are feeling pretty damn smug about themselves."
However I was a moderator of an assembly community.
I’d translated the DirectX8 C++ COM headers into their x86 assembly equivalent ( using techniques built by others far more smarter than me, and with help for some files when DX8.1 was translated ), built a PIC micro controller assembler in x86 assembly language, and many other things.
And because I've done six impossible things this morning, why not round it off with creating a solution to the Byzantine General's Problem !
Elitist ego ? What elitist ego ? They’re all amateurs !
Let us begin:
What was needed was a practical solution.
Not the solution to a perfectly impossible puzzle.
One that works reasonably well in the real world.
In the RNZAF during the Avionics Technician training we were taught how to calculate various aspects of an electrical transformer.
You begin by imagining a perfect transformer with the number of input and output coils ( inductors ).
Then you begin adding in elements based upon reality.
The copper wire has resistance.
The looped wire cause a phase shift between voltage and current by 90°.
The copper loops also create resistance that's 90° out of phase with the straight copper wire and we change to using impedance instead of resistance.
We continue adding elements from reality until we have a pretty close approximation of how a transformer would function in the real world.
From an unreal perfect transformer to a realistic practical transformer.
The same needed to be done to the Byzantine General's Problem.
Many mathematicians and academics used a perfect scenario to place the generals and how they can communicate with each other.
This ended up making a practical solution impossible because of the unrealistic constraints placed upon the generals.
So beginning with a perfect Byzantine General's Problem we start adding in the elements until we have something far more realistic so that we can hopefully figure out a more practical, if not perfect, solution.
“Ok,” I thought to myself. “let’s start at the beginning. We need a network. What does that look like ?”
The Generals are going to be represented as computers. The servers in the network. The nodes.
The messages are going to be the data travelling between them.
Transactions will be used as the first example of data.
For those reading, hold your hands in front of you - touch the bottom of the palms together with the fingers far apart, thumbs touching each other, twist your elbow and wrists so that the fingers are pointing upwards - slightly curved.
These are the nodes in the network.
The node where the thumbs touch is your own node.
No node can trust each other.
For this network structure to work, it must work even with every single node actively hostile toward one another.
“Surely the network can trust my node. I’m good ! “, you may say to yourself.
But you would be wrong.
This network is not about you. It must exist even when you don’t.
If there were a hundred nodes then it’d be ninety-nine to one against you.
As far as the network is concerned, there’s ninety-nine nodes that cannot trust you compared to your one.
So accepting that all nodes cannot trust one another, plus they are actively hostile toward one another, we can …
“But hang on ! ”, you say. “What do you mean ‘actively hostile’ ? Surely they’re not all hostile ? ”
Even if most of the time nodes will play nice with one another, the rules of the game must be structured in such a way that they will work even if all participants were actively hostile toward one another .
Because if it still worked with everyone having a go at each other then you would’ve built something that could last for a very long time.
You could build something whereby sovereign nations could no-longer undermine other sovereign nations.
It would be the great equaliser that would allow stronger nations to stop screwing around with weaker nations.
It’s the ultimate golf handicapping system. Everyone could play this game.
Kind of like my moderating style from the assembly days.
So we have these hostile nodes.
It has to be able to work with any type of message or data package. Initially it will be built for electronic cash transactions.
I will type it as "messages (transactions)" below to indicate that the messages are the messages in the Byzantine Generals Problem and that the message could be any data whatsoever - "transactions" just being the first. Plus in a roundabout way a message is also a transaction whereby a transaction doesn't have to be only for electronic cash - it's just an indication of what items are being transacted.
We want to send messages (transactions) between them and make sure everyone agrees that the messages (transactions) are correct.
That implies that every single node would have to store an exact copy of all the messages (transactions) and be able to read through them and confirm that they are valid.
And whenever a node receives a message (transaction) it would check it for validity and if it’s ok then that message (transaction) would be passed onto the adjacent nodes.
But how to stop a node changing the message (transaction) contents and sending different results to two adjacent nodes ?
How about taking the possibility of messages (transactions) being able to be changed out of the problem completely ?
We could using private/public keys to sign the messages (transactions) so that they couldn’t be changed.
The owner could sign a message (transaction) with the owner's private key and everyone could check its validity with the owner's public key, but not be able to change it.
Right. The messaging ( transactions/ data/ etc ) part of the problem is partially solved.
Decision Making Mechanism
For electronic cash, everyone previously had tried to say one transaction is true and the other is false.
And they made convoluted processes and checks to try and figure out which transaction was true ( to be kept ) and which transaction was false ( to be discarded ).
However, I view things from a more universal lense.
- From the perspective of Alice, her transaction is true.
- From the perspective of Bob, his transaction is true.
- Everyone who sees Alice's transaction first believe her transaction is true.
- Everyone who sees Bob's transaction first believe his transaction is true.
Given two transactions sending the same digital asset, we need to decide which one is fact.
Looking at this partial solution to the Byzantine General's Problem I began to note that there were inputs and outputs.
The inputs being the decisions from the generals.
The output being the unanimous decision - attack or retreat.
All that we're trying to do here is to make a decision which no-one could dispute.
When all the inputs align, only then is the decision written down and made fact.
What we needed to solve was how to make a decision making mechanism.
It would solve not only the Byzantine General's Problem, but also every other type of choice which needs deciding.
Like the decision to choose which transation is the correct one to stop double-spending in an electronic cash system.
It occurred to me that I'd seen something else with similar properties to this.
Electronic or computer logic gates.
The way logic gates work is that, for a particular set of inputs, the output will be high or low - true of false.
In some of the early hacked-together computers of the 1970s, they were programmed by setting a bunch of swtiches on and off then tapping the write button to write that byte sequence into memory or punch it into a card.
You'd then move the pointer to the memory location to the next location, set the switches to another byte sequence and write that.
In this manner entire computer programs were written.
And all of the computing hardware ran using logic gates.
Logic gates are also a form of mathematics.
Logic gates can be coded into software and hardwired into hardware.
So if you could construct a decision making mechanism with logic gates then you would've actually built a system where mathematics controls the decision making process.
Does the impossible Byzantine General's Problem fit into logic gates ?
And if it does, how complex does it have to be ?
Looking at the explanation I'd already figured out, I came to the conclusion that the generals are all inputs into an AND gate.
The AND gate symbol:
With an AND gate the output will always be low until either all inputs are low or all inputs are high.
Once all inputs are low or all inputs are high the output will be high.
The output being high is used to decide to write the data to memory.
And all inputs are written to memory.
And what about the impossible double-spending problem ?
Is it solved in the same manner ?
It cannot be an AND gate, as we cannot have data being written if both transactions either exist or don't exist.
What we need is to have only one of the inputs written.
I found that there's a gate which match this behaviour without needing a complex structure oflogic gates.
The XOR ( exclusive-OR ) gate symbol:
With an XOR gate the output will always be low when either all inputs are low or all inputs are high.
Only once one input is low and one input is high will the output will be high.
The output being high is used to decide to write the data to memory.
And only the high input is written to memory.
This is absolutely brilliant !
That's two impossible problems which are able to be solved using two different logic gates.
And complex decisions can be made using vast combinations of logic gates ( a computer is such a device ).
So this invention solves both the impossible Byzantine General's Problem and the impossible Double-Spending problem.
One is for unanimous decision making and the other is for either/or decision making.
And the XOR mode of operation will allow us to use this invention to support a globle currency because, when given two transactions sending the same digital asset, we need to decide which one is fact.
Because that's what solving the Double-Spending problem actually is.
So, in the end, solving the Byzantine General's Problem does not solve the Double-Spending problem.
As they both use a different decision-making mechanism.
Now how do I solve the problem so that every actor plays nicely with one another ?
If we can make sure all nodes can get the identical data and that they can all validate that the data is identical and unchanged then the Decision Making Mechanism would be solved.
It became apparent that every major node on a network would have to store an entire copy of all of the data so that they could verify that the data was correct and hadn’t been modified.
The data would probably end up looking like a list or stack, with each incoming valid message (transaction) placed on top of the previous messages (transactions).
What looks like a stack but hasn’t got the memory restrictions like a normal assembly stack ?
When I was reminiscing about the Amiga 500 days I recalled having to muck about with IFF.
That’s the Interchange File Format.
The basics of it is like this:
In a plain text file there are chunks of data.
Each chunk of data begins with a chunk identifier - four characters that indicate to a program what type of data resides within that chunk (example “WAVE”, “FORM”, “NAME”).
An IFF file can have many data chunks of differing types.
The .AVI (audio/video), .ILBM (bitmap) and .WAV (audio wave) file formats are based upon the IFF.
I thought, “What if one of these data chunks was called ‘MSG ’, ‘DATA’ or ‘TSTN’ (TranSacTioN) ? ”
That might work.
Where would the proof-of-work thing come into play ?
Let’s say we replace the four-character-identifier with a header so that the proof-of-work can be done on it ?
That means the header would now include an identifier for what type of data is included within the chunk, plus a value used to modify the difficulty for generating a hash (the number of zeros needed to prepend the generated hash), a random value which increments as hashes are attempted so that the header data is slightly different for each hash attempt, plus the data itself.
But once a correct hash is generated, that particular node would mint electronic cash to pay for the electricity used.
Remember: The electronic cash is supposed to cover the actual fiat currency costs involved in doing the proof-of-work computations.
As the owner of the node computer is paid by an employer in fiat currency and has paid personal tax on it, and they have used that fiat currency to pay their electricity provider ( which in turn pays company, state and value-added or goods&service taxes ), then the electronic cash is equivalent to swapping your own money for a soft drink can from a vending machine.
Except, due to the media of this system, you’d be able to go to another vending machine and re-enter your soft drink can for a refund in fiat currency again ( minus a restocking fee ) and the vending machine could be anywhere on the planet.
That means an extra message (transaction) would have to be included within the chunks data for the minted electronic cash.
If there must be at least two messages (transactions) within a data chunk - the actual message (transaction) plus the message (transaction) for the node that generates the hash - then maybe there could be more messages (transactions) stored in each data chunk ? How would a bunch of messages (transactions) be stored inside a data chunk ?
I remembered learning about BSP ( Binary Space Partitioning ) around 2006.
BSP trees were used to store 3D graphic polygons that were able to be quickly traversed so that a game could decide which scenery to display to the game player.
Quake 3 Arena and Medal of Honour: Allied Assault ( which uses Q3A code-base ) used BSP trees for storing the scenery. Wherever the player was looking the tree would be traversed and only the polygons ( triangles ) that were viewable would be rendered by the graphics chip. Try to think of the players view in a game was like a searchlight beam and whatever the light touches is rendered onto a persons computer screen and everything else is ignored- unseen and not rendered.
“I wonder if I could break the transactions up into a binary space partitioned tree ?”
For those interested, a wee bit of light reading is here: Binary Space Partitioning
A binary space partitioned tree begins at one polygon and uses its surface as a plane to cut throughout the rest of the scene.
This kind of plane: Geometry Plane
Each polygon the plane hits gets sliced in two.
Note: The ‘node’ word used below is used for talking about the nodes in a BSP tree - not nodes in a computer network. Think of nodes as where an actual tree branch splits into two smaller branches.
All the polygons in front of the plane go into the left branch (node) and all the polygons behind the plane go into the right branch (node).
Traversing each branch (node) in turn, a polygon is chosen closest to the middle of the remaining branch (node) scenery and another plane slices the branch (node) in two.
The traversal continues until the entire scenery has been sliced up into left/ right (or up/ down) branches (nodes) and they all end up at the leaves (nodes) which store the actual polygon geometry.
If we use the messages (transactions) as the equivalent of the polygon geometry then we could have a bunch of messages (transactions) in the leaf nodes at the bottom of a tree-like structure inside a data chunk.
Instead of a group of triangle vertices ( polygon geometry ) there would be a single message (transaction).
But how to connect them all up ?
A BSP tree is linked up by having a parent node pointing to the two child nodes, but that’s in memory.
The BSP file that’s stored on a disc drive can be easily modified ( easy as in it’s possible instead of impossible ).
The messages (transactions) within a chunk cannot be allowed to be changed.
What if, instead of memory pointers or offsets pointing parents to children we use one of those crypto hashing functions ?
The bottom-most leaf nodes could use data specifically from their message (transaction) to generate a node hash, right ?
Parent Branch nodes could create a hash using the hashes of their two children hashes.
This would create a tree-like structure within a data chunk where the topmost parent hash could be included within the data chunks proof-of-work header.
This would allow all the messages (transactions) to be locked into a tree that doesn’t allow them to be modified because all parent node hashes would have to be recalculated and the trees root hash would be different from the original generated hash.
And that would mean that the entire proof-of-work hash value would be changed.
The same mechanism used to transfer the transaction data around the network would also be used to send the chunks of data.
If a network node received a changed dataChunk and compared it with one they already held then they’d notice the proof-of-work is different and would know someone was attempting to modify the data.
Bloody [redacted] ! I think this might actually work.
I email (2) to inform him that I was again making progress on the issue.
I explained the idea of having a simplified BSP tree to store the messages (transactions) into a dataChunk and have them all hashed together into a tree with the proof-of-work plus parent hash at the top.
He said, “If I change the transaction stuff to use this method I’m going to have to throw out half my white paper and a third of my code”.
“Well, “ I replied. “We've gone through this before. You can keep using your current transaction stuff if you want. The network itself will probably be something like Napster.”
“Ok. ok”, he said. “I’ll go with what you’ve come up with. But didn’t Napster get shut down because it used a central server ?”
“What’s another peer-to-peer network ? IRC ? Tor ? BitTorrent ?”
“I think we can use IRC to hold the initial node addresses until such time the network is big enough for large permanent nodes to appear”, (2) suggested.
(2) asked, “What’s to stop nodes from sending different dataChunks to other nodes ? If they’re just stacked on top of one-another then they can be swapped in and out at any time. That’s why a third party server is needed for setting the official time on the network for the transactions. Someone could create different transactions and change the time to whatever they want if they can use whatever time they choose.”
I said I’ll think on it some more.
A Kronos Stamp Server
If a third party cannot be used for a time stamp server then we’d have to reevaluate what is meant by time in a computer network.
What if how people think about time is actually wrong and everyone is assuming it to be something that it really isn’t ?
If you hold one fist in front of you to represent time - call it ‘now’ time.
If you hold another fist after the first fist you can call it ‘after now’ time.
If you hold another fist before the first fist you can call it ‘before now’ time.
What we’re actually looking at is a chronological order stamp. The actual time itself is pretty much irrelevant except for when comparing two things in their chronological order.
It should work whether the ‘now’ time is the time shown on your clock/watch right now, or on a date two hundred years from now, or 1253BC ( Tuesday ).
The before/ now/ after can be adjusted accordingly:
after ( Wednesday )
now ( 1253BC Tuesday )
before ( Monday )
And if the time value used is the time shown on your clock, is it the same as the time value shown on your watch ? On the microwave ? DVD player ? Computer ? Phone ? You may find that all the time pieces inside your own home vary by a few seconds or even a few minutes !
In an office almost every single person has a timepiece that has a different time to everyone else - even if it’s only different by a few milliseconds.
Does that mean as you walk from your kitchen ( showing 2:02pm on the wall ) into the lounge ( showing 2:01 on the DVD player ) that’s you’ve just entered a time portal and been magically transported back in time by a minute ?
Of course not. They’re all equally valid time values that humans have made up to be roughly synchronised with one-another.
All that really matters is the range of valid time values used to indicate “This is Now”, “This is Next” or “This was Before”.
If the network nodes all agree on what range of time values should be valid to be “now” or “near now” then each node could use its own time value in any data messages (transactions or dataChunks) and no third party timestamp server would be required.
I email (2) and let him know the time-stamp server issue has been resolved by having the nodes use a Kronos-Stamp.
“What the [redacted] is a ‘Kronos-Stamp’ ? ”, (2) asked.
I give him the explanation I gave to you ( the Reader ) above.
“But what’s this ‘Kronos’ word mean ?”, (2) asked.
“It’s short for “Chronological Order. It’s a Chronological Order Stamp. We don’t need a Time-Stamp any more,” I replied.
“But what’s with the ‘K’ ?”
“To annoy all those folks who’d rather get furious about misspelt words than try and understand the concept that’s being explained. ”
“Well, the crypto community won’t like it spelt like that. We’re going to have to call it a Time-Stamp server because that’s what they understand,” (2) said.
I said, “Time-Stamps are for systems using third party servers. Chronological Order Stamps are for peer-to-peer networks.”
“Ok,” (2) said. “We can use this time thing for making sure the dataChunks are in a chronological order but what stops someone from just changing the time of their computer to be a little earlier than someone else and having their version of the data accepted by everyone else?”
I said I’ll think on it some more.
A Chain of Data Chunks
On another project I was rereading some information about rendering graphical data.
In 3D graphics triangles are used to create any object you see onscreen.
Example of Triangle types:
Each numbered dot represents a vertex.
The data for the vertices are placed into arrays called buffers.
They’re just a long list of data points which are loaded onto a graphics card and told to be drawn.
A triangle strip is a strip of triangles which share the data points from the previous triangle.
Each triangle in the strip is drawn alternating between clockwise/counter-clockwise (indicated by the red and green arrows)
The very first triangle must have all of its vertices added (all three vertices 1,2,3)
Every other triangle in the strip only has to add one more single vertex and reuse the previous two vertices.
The second triangle just adds the data for the vertex (4) and reuses vertices 2 and 3 that’s already embedded inside the strip.
This makes the strip incredibly compact in size for the data it’s meant to represent plus locks each triangle inside the strip and they cannot be accidentally used elsewhere.
If a triangle was wanted to be drawn in a different order then an entirely new triangle strip would have to be created.
A key side affect is that a triangle strip can be set to start drawing at any vertices (except vertices 2 and 3) and the entire strip from that data point onwards will be drawn.
I was staring at this for a long time thinking “This could be used for the electronic cash project somehow, but how exactly ?”
I kept going through the explanation for the triangle strip again and again trying to understand what I was seeing.
Then it dawned on me.
The triangles were the data in a triangle strip.
The chunks were the data in the electronic cash project.
If the triangles were actually the dataChunks then that means the vertices were the proof-of-work header, with the embedded root hash for the messages/ transactions.
The lines in the triangle strip represented the reuse of previous vertex data.
So that means I could reuse the proof-of-work hash from a previous dataChunk and embed that into the next proof-of-work as well !
And just like a triangle strip the dataChunks couldn’t be moved elsewhere unless all the surrounding proof-of-work hashes were redone again.
It reinforces the Kronos Stamp by embedding the previous proof-of-work hash into it so we know what came before now and what was next after previous.
If the entire network was using their cpu power to generate these proof-of-work hashes then a hostile actor would need half the processing power to get a fifty percent chance of generating the proof-of-work hash for a block and modifying the data.
However every second block on average would be generated by an opposing hostile actor and so whatever the fifty percent hostile actor was attempting to do wouldn’t last for very long.
"I think I just solved the bloody thing !", I thought. "Aren't I supposed to shout 'eureka' or something now ? What should my shout be ? WooHoo ? 'Eureka' is already taken."
I begin googling ideas for a eureka replacement.
After about half an hour I couldn't find a suitable interjection and I thought "That's a bit of a disappointment. I'll just have to tell people I yelled WooHoo or something."
I needed to have some of the math for this looked at to see if I was on the right track.
I email (2) and let him know about this idea of hooking together the dataChunks like a chain so that they couldn’t be modified without redoing the proof-of-work hashing.
He liked the idea of a chain.
I said, “You see how all the appended dataChunk headers reuse the hash from the previous dataChunk header ? Take a look at the very first dataChunk.”
“What’s so special about that” , (2) asks.
“Well,” I say. “The first dataChunk header hasn’t got any previous hashes it can use, so in the beginning it will have to use a made up ‘previous hash’ in its header. In the beginning it has to use a manually created hash. In the beginning… get it?”
“What ?”, (2) asks.
“The very first data chunk is the Genesis dataChunk. In the beginning there is the Genesis dataChunk”, I reply.
He said he likes that idea very much as he’d just started being involved in a church in the past year or so.
I ask him to get the other cryptos he’s in contact with to play around with the numbers and see if this would work.
(2) asked, “Hang on. How would this solve the double-spending problem ?”
I said, "The nodes doing the proof-of-work would be trying to embed the message data ( unspent transactions ) into a merkle tree and into a dataChunk with the merkle root embedded into the proof-of-work header. They would be getting all of the new transactions from the network and checking them for validity. Any invalid transactions would be thrown out. Any valid transactions would go into a pool which would also be on-transmitted into the network to the next peer nodes when a peer node requests all transactions after a given time. Whatever transactions are in the dataChunk when the proof-of-work hash is generated is the accepted transaction version."
(2) asked, "But how do they know which is the correct transaction ? If Alice gives a dollar to Bob and then gives a dollar to Charles then how does a node know which is the valid transaction ?"
I replied, "Whatever transaction a node sees first is the only valid transaction it sees and every other transaction attempting to spend the same dollar is deleted as a double-spend."
"But how does it pick the dollar sent to Bob instead of Charles ?", (2) asked.
"That's the whole point," I replied. "As far as the world is concerned the dollar sent to Charles is equally valid. You may see a world where Alice spent a dollar with Bob then Charles, however many others may see a world where Charles was paid first then Bob. All we need is for one entity to make the choice: Who's on First ?"
"What ?", (2) asked.
"He's on Second," I replied.
"…", (2) thought.
"The entire system has to be able to take two truths and decide upon which of them is fact," I said. "From Bob's perspective, and every node that sees his transaction, his transaction is true. From Charle's perspective, and every node that sees his transaction, his transaction is true. The nodes are doing computations and deciding which of those transactions are fact by embedding it into a block and adding it to the blockchain."
"But what if a node receives a dataChunk from one peer node and a different dataChunk from another peer node. How does it know which one is the real first one ?", (2) asked.
I said, "As far as a node's reality is concerned, the first transaction or the first dataChunk received is the correct one. Any dataChunk arriving afterwards will have to be kept just incase another new dataChunk arrives that's been appended to one of the previous dataChunks that the node already has."
"And what happens then," (2) asked.
"They just keep the longer chain and throw the other dataChunk away as it's no longer the valid chain.", I replied.
"But how does a node know it's the valid chain ? Couldn't another node append another dataChunk to that discarded dataChunk ?"
I was beginning to get a wee bit annoyed by now. Does he expect me to do all the thinking here ? What happened to the others he was communicating with ?
"Look, " I said. "All nodes just accept whatever happens to be the longest continuous chain of dataChunks as the valid chain. As soon as they receive a dataChunk that extends the chain they're currently working on, they discard the dataChunk they're working on and begin hashing the proof-of-work with a new merkle tree of messages ( transactions ) from the pool of unspent transactions."
"But why ?", (2) asked.
I said, "Because that's the longest chain that's got the greatest amount of cpu resources spent on generating the proof-of-work hashes. For anyone to change the transactions inside the dataChunk they'd actually be competing with the entire network of processing resources. If they ever got close to fifty percent the rest of the nodes would just put more resources into play. They all have an incentive to do so as the electronic cash they'd get for generating an accepted proof-of-work hash would be greater than whatever transaction double-spend they could be trying to do or the extra processing resources they'd have to pay for."
I continued, "The entire system is like the body's immune system. There are hostile actors continuously attacking it and the immune system adjusts accordingly. The mining nodes are separate pieces of the immune system protecting the body, the data, from bad actors. Pieces of your immune system get rewarded if they do a better job in one area better than their peers. It's an evolutionary fight where the top gun gets the prize.
(2) asked, "But what are the calculations you're using to decide if this will work ? How do you know that a hostile actor won't be able to generate a whole lot of dataChunks beforehand and then replace a large piece of the chain in one go ?"
I said, "You and your friends are the cryptos. You do the math !"
He came back later and said that the math seems to be working out and that it looks like it may actually work. Better than actually work. It may make the chain stronger as the chain extends over time.
(2) said, "We really need to have a talk about calling it ‘dataChunk' first. I really don't think the crypto community will accept something called that. Can we change it to something else ? Something the community might find more relatable ? "
I power up the online thesaurus and entered "chunk" and copy/ pasted the resulting synonyms into an email back to (2) saying "Have a look and choose something."
He comes back and says "Block sounds familiar. I'll look it up and check."
He posts a link to a crypto info page that mentions Block Cyphers.
"They'd accept it more if it was called a chain of blocks instead of a chain of dataChunks," he said.
I had a read over the information and said "This thing has to do with generating cypherText from plainText spread across a block of fixed-length rows. If anything, they'll assume this chain of blocks has to do with integrating a block cypher into a chain and confuse the [redacted] out of them."
"Well," (2) said. "You choose another word from the thesaurus then."
I said, "Block may have to do as all the other words look rubbish."
(2) said, "Ok then, a chain of blocks it is. You may have to go over this stuff a few times before I get it. It's really ground-breaking stuff and there's nothing else like it out there."
The Missile Method
I said, "That's great. We can now look at the GPS location stuff and transaction tax again."
(2) said, "… wait, what ? I thought you hadn't figured out the GPS stuff without using a third party for keeping tabs on the global localised electricity prices, and what's that about a transaction tax ?"
I said, "This time the GPS stuff will be for the nodes generating the proof-of-work hashes. They're like miners digging the resources out of the ground - doing work to refine the ore to obtain precious minerals. We need a way to make sure the nodes themselves are spread out across the globe to stop centralisation into just a few mining farms. The whole thing must be distributed globally."
(2) said, "I think centralisation of the miners is inevitable. It'll end up as a decentralised network, not distributed."
I said, "I've got this method I call ( for now ) The Missile Method. It goes something like this: How many missiles does it take to destroy a network ? I don't mean some hacker's super special digital missile. I mean a physical cruise missile fired from a ship flying into a single level of a high-rise building to obliterate a network server that resides in there."
"When did we start talking about cruise missiles ?", (2) queried.
I continued, "If a network is totally reliant upon a single server for, say, a time stamp, then that would cost one single missile to destroy that network. If the minting servers were spread over half a dozen 'trusted' servers then that means only half a dozen missiles would be necessary to destroy that network."
(2) said, "I see where you're going with this."
I continued, "The network must be distributed and spread out enough so that it costs more in weaponry to destroy the network than the value of the network itself. A ratio of one missile per node would be best. It costs about one million US dollars for a cruise missile at the moment. If a trillion dollars was just placed into missiles ( just go with me here ) then that would mean we need the network to have about a million nodes. In other words: If every home ran their own node then all the fire-power in the world couldn't stop this network. Plus, for folks to use this everyday they'd have to access it from the new smart phones. There's no way these things would be able to hold the data for the entire chain of dataChunks - sorry, the chain of blocks. The phone data usage itself would be astronomical no matter how great the phone plan."
(2) asked, "If the smart phones can't hold the all the block data then how can someone make or receive a payment ?"
"It'd work similar to the original binary space partition (BSP) tree idea. Remember the search light beam and whatever it lit up was rendered on a screen ? They're the unspent transaction outputs. All the spent transactions are in the unseen shadows and can be eliminated. They're not needed any more once buried beneath enough blocks. Only their hashes in the merkle tree are needed for the block's hash to be validated. This means only the block headers and the unspent transaction outputs are needed to be kept. If there's a problem then a persons smart phone can connect to their home node server to get the fully validated chain. As a smart phone isn't running a full node then it has to trust the node it's connecting to and in a network built for not trusting anyone they can surely trust themselves."
"And this transaction tax ?" (2) asked.
"The idea is to automatically collect taxes from source and destination locations so that it's distributed automatically across regions, states, cities. Where the most transactions take place the most transaction tax would be collected"
"Like [redacted] we'll include a tax into this," (2) said. "No-one would want to use it if they also have to pay each time they transfer money."
"The idea is to stop large companies and rich folks from using off-shore accounts to hide their income and to get out of paying their fair share like the rest of us. The bridges and roads have to be paid from somewhere. A single transaction tax can replace all business income, personal income, value added and goods&service taxes. Of course, we'd have to use another word instead of ‘tax'"
I told him to use the thesaurus again and pick another word to replace ‘tax'.
He refused and said if I wanted folks to pay taxes they could use one of the outputs from the transactions.
I told him it would have to be locked into the code-base otherwise there's a huge incentive for criminals to use this system.
"Remember Al Capone ," I said. "He was done for not paying taxes. Even if folks get up to bad stuff, so long as they pay their taxes the tax department will leave them alone. Plus it would mean that the criminals themselves would be funding the policing services that are working to indict them. They'd effectively be paying to be caught. They'd be incentivised to continue using fiat currencies for their dubious deeds."
(2) wasn't convinced with the transaction tax idea.
It was fair enough too, as there was still the issue of figuring out how it could work when anyone could say they were at any location on the planet. It would have to work in spite of folks changing the location data.
I decided not to tell him about the other stuff that'd hook everything together until later on.
We continued to thrash out the issues on how the various aspects of this system would work.
In the end we decided that for the first experiment, to test if this could actually work at all in a live environment, we'd cut out anything that would rely on an outside service ( like exchange-rate data servers or GPS location tech ).
"I still think this thing may have problems," (2) stated. "What's to stop nodes from screwing around with the network ? Sending bogus transactions and blocks to bottleneck the network ?"
I told him, "We'll have to make sure that all of the actors play by the same set of rules and are incentivised to make sure everyone else also plays by the rules. Back in the late 1980s there was a movie called Wall Street. The main protagonist talked about how greed is good. While most folks said that character is evil or bad, I took notes. By harnessing folks natural greed we can bring about an ideology that benefits everyone."
"And how do we do that ?", (2) asked.
"By utilising Game Theory techniques during the implementation so that we can pick rules that will create a balanced game for everyone to play," I said. "I had an inkling of how to do this when figuring out the Byzantine Generals problem. That's why I call it the Byzantine Generals Dilemma; Because I had to treat the Generals as players in a Prisoner's Dilemma game so that no matter what strategy they chose they would still be choosing a valid strategy within the game."
That made me remember of something else that seemed eerily familiar.
I read most of Isaac Asimov's science fiction books. From the robot series to the Foundation trilogy ( later added to and made into a series ).
What always intrigued me in the Foundation books was the use of something called Psychohistory.
The basic idea was to be able to use statistical mathematics on large populations so that probabilities on future events could be computed.
They ( the Psychohistorians ) were able to use this information to control and guide the direction as the Foundation rebuilt a second empire.
The Foundation represented the base society that was being controlled.
The Second Foundation was a society of Psychohistorians whose entire purpose was to continuously update and re-compute the maths so that adjustments from realtime data could be made.
It was all built with probabilities and ranges so that when the physical Foundation went down a particular path all future probabilities from that point on were re-computed.
That made me recall something else with regard to small adjustments making huge changes.
Buckminster Fuller liked the idea of being called TrimTab. It's even on his gravestone.
You have this huge lumbering ocean liner called the human species. The ocean liner has a huge rudder to make it change its course. It's used for wars, famine, disasters, catastrophes, and so on. On the huge rudder there's another smaller rudder called a trim tab. When the trim tab is moved, it hauls the huge rudder over and the entire ocean liner turns towards a new heading.
The idea of a trim tab in Psychohistory is that you should be able to apply a very slight pressure at the correct time and place to direct the future course of the human species.
Of course, Isaac Asimov was just writing a science fiction novel. That doesn't mean it would at all be possible in real life.
But could something similar be fashioned ?
Something that has a function whereby it allows the human species to be made to follow a particular direction no matter what choices they made ?
"Why do we need to use Game Theory ?", (2) asked. "Can't we just code the basic e-cash idea up and license it out to online gambling sites ?"
I said, "Anyone can code up a blockchain to exchange digital commodities. If all the nodes within the network are invite-only then the blockchain itself would be private. But how long could it last ? How vulnerable would it be to attack vectors from within and without ? Employees, hackers and crackers, governments, conglomerates ? Would it last months, years, decades ?"
"You're just not getting this," I reiterated. "This is much, much more than an electronic cash solution. It's quite possible that it will change absolutely everything. We could build something that will continue for centuries and beyond."
"Everything how ? Change what ? How money is moved about ?", (2) asked. "I just want an electronic cash solution. I don't believe we need all this game theory stuff."
"Using Game Theory is the real technological breakthrough here. I'm going to studying up on more Nash Equilibrium ideas to give incentives to hostile folks to play the game as one people. The real tech behind this electronic cash is that it will use Game Theory to set the rules for all folks of the world to play the game as a Massively Multiplayer Online Role-Playing Game where everyone acts the role of Planetary Citizen.
It will be the worlds first field test of Psychohistory in practice."
"Wait, what ?", (2) asked. "Do you mean that if we can get actors locked into playing a game built with code that we can actually control what they do ?"
"Only influence or guide them, " I replied. "Like how in Ten-Pin Bowling the bowling lanes block the gutters so that the bowling ball bounces back and forth towards the pins."
(2) said, "If we can pull this off we might have a way of taking over the world !"
"But", I asked, "which of us is Pinky and which of us is the Brain ?"
"...", (2) said.
"Plus", I continued, "if we've got bi-polar we could actually be both brainy and insane at the same time. Insanely brilliant or brilliantly insane !"
"How long will it take to figure out this Psychohistory stuff ?" (2) asked.
"Dunno," I replied. "We'll go through some of the implementation ideas and I'll see what I can throw at it as I go along. I'd say that I'll only put enough rules in place to get the basic functionality working. From there we'd have the foundation in place to create the first code and get a few nodes up and running. Remember: we still don't know if any of this stuff will work yet. There could be a huge fatal flaw in it that we're totally unaware of."
"That sounds great. And then we can finally release the white paper," (2) said.
"Release what ?" I asked. "What white paper ? I thought you'd chucked that one away because I said it was rubbish ?"
(2) said, "My original white paper has been completely thrown out now, and two-thirds of the code I'd developed has been binned. This stuff you've come up with is absolutely out of this world. But I've been promising some people in the crypto community that I'd be releasing a cryptographic white paper this year. It's my way of coming out and being accepted in the crypto community. If you don't have a white paper you're irrelevant and ignored. Of course, your name will be at the top and most prominent."
I replied, "I don't want to release a white paper. Not just yet in any case. There's still too much to figure out and test first. Due to the nature of this project I really don't think it'd be wise to release it under our own real names."
"What do you mean not to release it under our real names ? How else would I be able to get accepted into the community ?", (2) exclaimed.
I told (2), "This tech will allow folks to move digital items about and use them as commodities and currency. We're going to have to push the commodity idea because practically every nation that has its own fiat currency also has laws against folks creating their own type of currency and monetary system. Unlike all of those others in the crypto community who have published many electronic cash ideas over the years and decades this is the very first time the nut has finally been cracked. It is not the government of your own nation that you have to be wary of. It is every single government upon this planet that will be gunning for us for releasing something they cannot ever control. Something that could quite possibly outlast the existence of any of their nations, their type of government, their constitutions. The descendants of us all will one day look back into their past and see what used to be called a sovereign nation with amusement. And they'll do so all the while continuing to use the tech from this electronic cash solution to be their own self sovereign individuals."
(2) said,"Uhh. That sounds really great. Pretty awesome if it can be done. Would it be possible for us to get a draft version of the white paper together so that I can start sending it around to a few people to get their feedback on it ?"
"I guess so," I replied. "All you have to do is go back through our emails and get the info from them to add into the white paper you're writing."
(2) said, "Are you ok with me sending other people the information on this ? You're sure it'd be fine if others saw what you've figured out before it's made public ? What if some of them decide to take what they see and quickly publish the solution in their own white paper as if they'd come up with the solution themselves ?"
I asked, "You're sending it to a few folks that are already known in the crypto community, right ?"
"Yes", (2) replied.
"Then it should be fine," I said. "The peers in the crypto community will know that the solution was provided by you to them and would be very quick to call out publicly anyone that suddenly publishes the exact same solution. They ( whoever tries to take credit ) would be incentivised to not publish because in doing so they'd be ostracised from the crypto community. Being ostracised from your own social and peer community would be a huge negative payoff and the more it adversely affects them the more they would stay away from that strategy."
(2) said, "You said we shouldn't use our real names on this paper. You're dead-set certain about that ? I was thinking your name would be listed first and I'd be second."
I said, "With my name in a larger font, right ? As I said before, this solution is unlike all the others that've been released, so we really should use something else. It'll also force folks to analyse the technology itself without relying upon the status and reputation of the authors. Many cryptographers, mathematicians, and academics would instantly dismiss this invention purely because we haven't made a name for ourselves within the community. All they'd have left is to test the ideas out directly and find out whether we're correct or not."
"Then what kind of handle should we use ?", (2) asked.
"Well," I replied. "We've been using made up internet handles all this time for our communication, right ? It'd have to be something like that."
"Just a made up handle ? What should it be ?", (2) asked.
"I don't know. Anything would do. However it has to sound like an actual name. Not something like the handle I used when we first started emailing and IRCing.", I said.
(2) said, "I've got something I've been wanting to use for years, but haven't found the right purpose. How does Satoshi sound to you ?"
"Japanese," I replied. "I was thinking more along the lines of a John Smith type handle, but this may actually be brilliant."
"You think we could use that as the handle ?", (2) asked.
"Absolutely !", I replied. "If this actually works and takes off then everyone will be searching for a Japanese fella and would be looking in all the wrong places. Unless, of course, you are actually Japanese. In that case it'd be quite a stupid idea."
(2) said, "No, no. I'm not Japanese. It's just a name I came up with a few years ago that I thought sounded cool."
"Could you adjust it to sound North Korean ?", I asked.
"North Korean ? What the [redacted], dude !", (2) exclaimed.
"It's just that, have you seen those new night-time images on nightearth ? North Korea is completely dark compared to the rest of the civilised nations of the world. Only ( some ) deserts are darker. If the handle seemed like it was a North Korean name it'd really make folks scratch their heads.", I said.
(2) said, "No way. If we're going to go with a made up handle and not use our real names then I want to use the Satoshi one."
"Fair enough," I replied. "If we used a North Korean-sounding name it just may get some innocent into severe trouble in that nation anyway."
"Right," (2) said.
"It has to be a full name," I said. "Not just a single anonymous internet handle. It needs a last name."
"Like what ?" (2) asked.
"Well," I said. "This is a Japanese sounding name and I like the James Clavell book Shogun so we could choose a lastname out of that. Otherwise, I'm reading Michael Crichton's Rising Sun at the moment. It takes place in the new headquarters of the Nakamoto corporation called the Nakamoto Tower. Kinda sounds similar to the Nakatomi Plaza in Die Hard, right ?"
"I like that. Nakamoto," (2) said. "I thought I recognised that name before and did a search around and found a Japanese philospher named Tominaga Nakamoto. He lived in the 1700s and questioned the entire structure of society of his time. That might be from where Crichton chose the name for that tower."
"Satoshi Nakamoto it is, then," I said.
Both of us went to create our own email address.
I found a generic email hosting service which was similar to Hotmail and Yahoo, except it was more Europe-specific.
I thought it'd screw with the minds of anyone who'd try finding out who we were.
A Japanese name using a German email service.
(2) came back with a paid-for anonymous service.
The same one he'd told me about for purchasing the bitcoin.org domain name.
So (2) had email@example.com and I had firstname.lastname@example.org .
"Ok then," I said. "If we're going to use this Satoshi anonymous handle we're going to have to do this right. It's going to have to play the role of a very intelligent crypto tech character. All public posts must be checked and double checked before submission. We can rely on spell-check for part of it however we'll still have to manually check for grammar and word usage. For instance using the words bought and brought correctly. It'd be better if posts only came from the one person to reduce the chance of folks noticing different grammar and word usage. As I've been communicating with everyone else through you, we'll continue with that. That means you'll have to do most of the writing/ posting/ emailing between all parties."
"I'm not that great a typer. It took forever to type out the white paper I was previously working on. This is really going to push me," (2) said.
I said, "If you want to do this you're going to have to step up then. Use (3) and me to help edit whatever you're going to publish. You send the white paper draft out to folks, send their questions back to me and then send my replies back to them. We can work the same way once we get a message-board up and running."
"What message-board ?" (2) asked.
"Once we can confirm this solution is plausible and we get actual working source code published we're going to have to create a message-board to cover development topics. Satoshi will have to be running the message-board and doing the majority of the posts."
"But why a message-board ? We can just use the crypto mailing lists," (2) said.
"We need to build up a community around this solution. You cannot do that with mailing lists. It's no-longer 1985. We need a place that allows folks from various levels in the community to come to get information, tells us of bugs, post about news related to the project. Tech folks love having their computer tech specs in their signature tagline which would be ideal for those running mining nodes. If one person saw that a community peer has just built a high-end tech machine which provides a payoff whereby it can mine for e-cash ten times faster than their own machine, then they would be incentivised to upgrade their hardware likewise and post the new machine tech specs in the message-board - thus affecting others who read the updated specs. They would effectively feed back upon each other, continuously upgrading and running faster and faster machines. The more processing power put to computing the proof-of-work hash, the stronger the network becomes. It's using Game Theory recursively to allow one players payoff in one game to affect the strategy of another player in another game, which in turn may feed back into that original game."
Draft White Paper
(2) asked, "Can you get the notes on this electronic solution together for the draft white paper ? I'll put something together with (3) and send it around to a few people in the crypto community I've been emailing your questions to."
I told him to just go through our previous correspondence and take the information from my emails to him explaining the system.
He asked me if I could go through the emails for him and make up a text file with the information for the system in it.
I thought, "What a lazy sod. After I come up with a great solution he can't even take the effort to gather the info himself."
I proceeded to go through the past few weeks and months of emails, copy/pasting the interesting relevant pieces into a sort of cohesive text file that covered the main parts of the system.
As I was pretty annoyed I purposefully left out some of the more interesting explanations and solutions to various sections.
I thought, "If he's wanting to publish the full system then he can go through the emails himself to pick out the bits I've left out."
He never did go back and add the missing parts into the white-paper.
(2) and (3) went through what I had given them and asked if this is what I want added to the white-paper and if I was sure I wanted it written like that.
I was under the impression that (2) was writing a white-paper and that my part would just be added into it.
Knowing that if this system has been figured out correctly and it is implemented well, then it's quite likely to become very well read by cryptographers, academics, computer programmers and pretty much everyone else in related tech fields.
If it is able to be scaled to a planetary civilisation size then it's also likely to be well read by every single human descendant in the centuries to come.
That would imply that the text of the white paper must be written in such a way that a child would be able to read it ( even if some of the concepts were not fully understood ).
I told them to use the language and vocabulary I typically use in my emails which try to transfer my message without requiring the recipient to reach for a dictionary.
For text to be easily read it's important that folks eyes can pick up, without effort, the division between sentences.
In the early 1990's I decided to do a correspondence course from ICS ( International Correspondence School ) on short story writing.
I bought an old typewriter from a local second-hand dealer.
It was an Olympia Traveller Deluxe typewriter similar to this:
The odd thing about this typewriter is that, instead of the letters being standalone, it had joined-up-writing type.
This made it very difficult to read paragraphs of more than a single sentence.
To allow the marker to read my typed answers easier I purposefully tapped the space bar twice for each additional paragraph sentence.
I told both (2) and (3) that they should always place two spaces after sentences.
Note: It took me three months after the source code release to finally get (3) to use the two-spaces rule but it took (2) another six months with both (3) and myself badgering him continuously.
When (2) finally understood that this technology could be used for much more than just electronic cash he apologised and from then on tried to always post with double-spaces.
I reminded him that he was posting on a message-board and that his previous posts had an edit button available for him to go back and edit the double-spaces into all his past posts. He declined to edit his past posts.
I said, "You're covering the calculation sections, right ?"
"The what ?" (2) asked. "Why do we need calculations ?"
"This is supposed to be a crypto white paper," I replied. "Crypto white papers have calculations in them. You have told me that you've got a pretty good maths guy on board to help figure out the maths of this stuff so get him to write up some calculations for the white paper. Crypto folks expect everyone in the community to be good at maths, right ?"
Crypto Community Trolling
(2) said, "Well, I'll see if a calculation section can be made. Don't put your hope too much in the idea that the people in the crypto community know much math."
"What do you mean ?" I asked.
"Many of them just follow everyone else," (2) replied. "They copy the maths from people who really know their stuff but the majority of them really wouldn't have a clue. That's why it's so important for us to be able to have a pretty good maths guy on this project."
"Really ? Is that so ?" I asked, intrigued. "I'm going to go and check something out."
A few days later I came back and said "I think you're correct. Many of the folks in the crypto community don't know much math and accept whatever they see at face value."
(2) asked, "What do you mean ? Why do you say that ?"
I said, "I've been arguing with myself on a crypto mailing list the past few days waiting for one of them to jump in and correct what I was saying. They didn't. So either what I typed just happened to be correct or they didn't really understand what I was typing in the first place."
(2) said, "Umm… arguing with yourself on the mailing list ? Uhhh… just what have you been up to ? How do you argue with yourself ?"
I said, "I had two handles on the crypto mailing list arguing with each other for the past few days. One handle was serious, the other not-so-serious."
(2) said, "That was you ? Oh [redacted]. You've really caused quite a problem here."
"What do you mean ?" I asked.
(2) replied, "Everyone in the crypto community is trying to find out who was posting that stuff. You used the name of someone well known elsewhere and some of the people I've been talking to have been talking directly with that person thinking he may be having a few personal issues. There's talk of professional defamation and getting lawyers involved. Oh [redacted]. What have you done ?"
I had a sense I'd caused a wee bit of a stir within the crypto community.
The project looked like it was going to be on shaky grounds if the folks (2) was trying to answer my crypto questions and proofread the white paper draft were also trying to crush me into the ground.
I asked, "So what shall we do ? Are you going to tell them it was me ?"
(2) said, "Hang on. I'll get back to you. Don't post to the mailing list any more."
He came back a few hours later.
(2) said, "Was it just one handle you were using or more ? There seems to be a lot of confusion out here and they don't know how upset they're supposed to be."
I said, "Two. One was Dave Korn. The mailing lists display a persons name at the bottom links section as their first name and the first letter of their second name. I decided to wind (3) up a bit by registering a Dave K handle. I like corn cobbettes so corn with a k. It means he'd see the links and be confused because he wouldn't remember posting in the threads. Are you saying that there's a real person called Dave Korn ? Really ?"
He came back to me after another hour or so.
"Right," (2) said. "I've been able to keep them off and to stop looking for you. I told them I knew who it was but I didn't hand them over your name."
"You didn't ?", I said. "That's really quite kind of you."
"Kindness has nothing to do with it," (2) said. "Without you the project's sunk before it even gets started. I'm going to have to buffer you from them. They've agreed that if you hand over the login details of those two accounts so that the real person can login in and make them their own accounts they'll stop trying to launch an investigation and prosecution against you. As it is there was talk about getting at me because I was refusing to give your name up."
I said, "And you wondered why we couldn't release the white paper and code under our own names ? If this is what your peers would do to you over a trolling test of their understanding of math, what do you think they'd do when we release this thing which makes all of their previous electronic cash efforts look foolish ? They all publish articles and white papers which are very difficult to understand and we're going to publish something a child could understand. Something that, if it works, will be the number one known and quoted crypto white paper for generations to come. It'll make all of their work look over-pretentious and pompous."
I gave (2) the login credentials of the two accounts and agreed not create posts like those again.
The draft white paper had begun to be circulated. I had not seen the draft. I was under the impression that my stuff was only part of it ( the guts of how it worked ) and that there was a large chunk covering all the other crypto-specific topics.
"Back to Game Theory and implementation of this thing," I said.
(2) asked, "So what part of the implementation should we start with ?"
"Let us begin with the remuneration for the miners and how the coins will be contained within the system," I replied.
"I thought we'd already covered that ?" (2) said. "The mining nodes set the first transaction as their own special one to themselves, right ? If they succeed in generating that block hash then they get the minted e-cash."
"That's correct however what's still to be decided is how much e-cash they'd receive as remuneration and how often miners would receive it. Will the system be inflationary or deflationary ? Will there be unlimited e-cash minted continuously into the infinite future or will it be limited ?" I replied.
"Why would you want to limit the minting of e-cash ? That'd make the whole thing grind to a halt wouldn't it ?", (2) asked.
"This is digital. The e-cash can be divisible into very small amounts. Just as there are some currencies that have Dollars and cents we can have Bytes and bits, where there's 8 bits for each Byte just like 100 cents in each Dollar."
"That makes sense," (2) said.
"And we could call it something like ByteCash or ByteCoin or Bytes and bits for Dollars and cents or Pounds and pence," I said. "You could say something like: I have 25 Bytes and 124 bits."
"I've been set on BitCoin for a while now and believe we should use that," (2) said.
"Isn't that like saying CentCoin instead of Dollars or PenceCoin instead of Pounds ?" I asked.
(2) said, "Other types of electronic cash have used the word gold or coin or cash to represent their idea. This thing is more like having a single gold coin that's able to be broken up into many bits.
"Well, I still prefer Bytes and bits, because there's 8 bits in a Byte," I said.
(2) said, "Tech people would known what you mean by bytes and bits, but normal people wouldn't. They wouldn't know what a byte is. But everyone knows what a bit is. A big bit, a little bit. They intuitively know that a BitCoin could be made up of large and small bits."
"Actually, that's sounds pretty good," I said. "I think you're correct. Let's go with BitCoin."
"I was going with BitCoin even if you disagreed," (2) said.
"We're going to have to decide how it's going to be spelt," I said.
"Spelt ? What does that matter ?", (2) asked.
"We have to formalise as much as possible. To standardise how this is done. Everyone that comes after us will use our stuff as the standard - not what the crypto community has come up with," I said.
"Very well, how should it be written then?" (2) asked, "The options are BitCoin, Bitcoin, bitcoin, bitCoin."
"We have the e-cash coin itself, plus the node network, plus the protocol being used across that network," I said. "Currencies are usually written using lowercase: dollars, cents, pounds, pence. So when talking about the e-cash coin it should be lowercase."
"That makes sense, I guess," (2) said. "But what about for the protocol and network ? And the project itself ?"
"We could use each spelling type for each use type," I said. "Bitcoin for the protocol, BitCoin for the project and bitCoin for the network, or some variation like that."
"That would be too confusing," (2) said. "We should only have the two types. One capitalised and the other lowercase. As you said, lowercase bitcoin for the coin and then Bitcoin for all other uses."
"Wouldn't that be confusing for folks if the project, network and protocol are all called the same thing?" I asked.
"[redacted] them." (2) said. "Let's see those others do any better."
I had a quick check of internet domain names.
"Ummm... There's a problem here," I said.
"What ?" (2) asked.
"bitcoin.com already exists and is owned by some random company," I replied.
"We can use .net or something instead ?" (2) asked.
"Maybe," I said. "Or make these folks an offer when it's time to release the project publicly. They don't seem to be doing anything active with it."
"Fine." I said. "So we now have the name. Next will be how the coins are minted over time so that folks are incentivised to join and use their electricity to generate bitcoins."
"How about just having it give 1 bitcoin to whoever generates the block hash every minute ? That's what many of those other e-cash attempts have done," (2) said.
I said, "One of the definitions of insanity is doing the same thing over and over and expecting a different result. All of those others used at least one central server for their failed attempts. So we go with decentralised. All of them had infinite coins being generated. Maybe we should limit them."
"I still don't like the idea of limiting the minting of coin," (2) said. "You said because this is digital we'd be able to break the coin up into very small bits, but that can't be done if the amount of bits is fixed at 256."
"Well," I said. "Instead of 8 bits in a Byte, sorry - coin, we use 8 decimal places ?"
"That sounds a bit better," (2) said. "We'd be able to increase the divisible amount even further if the value of a bitcoin ever got large enough."
"Right," I said. "However we'd have to either have the system use integer maths for computations or use doubles everywhere instead of floats."
"Why ?" (2) asked.
"Because there's a serious problem using floats in computers," I said. "The mantissa portion can only hold the accuracy of about 7 decimal points before failing. That's why in poorly coded computer flying or space simulation games rolling and banking sometimes fails to rotate correctly. Doubles allow up to 16 decimal places before its precision fails"
"That sounds great," (2) said. "Using doubles will allow us to use many more smaller bits of bitcoin over time without it affecting the values already stored within the system."
"Right," I said. "The alternative is to do what Steve Wozniak had in the early Apple II system."
"What's that," (2) asked.
"In the early Apple II there was no floating point in the BASIC code," I said. "It was all fixed-point arithmetic. There's a Youtube video somewhere of Steve Jobs complaining about trying to get Woz to implement floating point but he just never got around to it. So Jobs approached Bill Gates to implement the floating point on the Apple II."
"Wow," (2) said. "I didn't know that. Do you mean we should use fixed-point arithmetic instead of using doubles instead of floats ?"
"I reckon we shouldn't use either of them," I said. "We should just use whole integers. Eliminate any problems with precision entirely."
"But how would we be able to do decimal calculations if they're whole numbers ?" (2) asked. "How can we do division on whole numbers ?"
"We just use one integer for the whole part of a number and another integer for the decimal part," I said. "This means we'll never need to be concerned with these floating point precision problems at all."
"Ok," (2) said. "So we'll use unsigned integers for all calculations everywhere."
"What next ?" I asked. "Inflationary or deflationary ?"
(2) said, "Inflationary means a dollar today is worth less than it did yesterday and it will become more worthless over time."
I said, "As this thing is supposed to be around for a very long time, let's expand the timeline out a wee bit. In a hundred years time an inflationary currency will head towards a zero value, right ?"
"Yeah," (2) said.
I said, "And a deflationary currency will head towards an infinitely high value ?"
"That's the one for me !" (2) said.
"There's a problem though," I said. "A value of something is paid for work done today. Tomorrow that same work is worth less because time has been spent. If you spend work on laying down the tiles for a pathway now, why should that value increase over time to infinity ? The work done on those tiles really should decrease in value over time because the tiles themselves will wear down, the ground beneath moves and compacts slightly requiring more work to fix the location of the tiles in the exact same place again. What worth is that initial laying of those tiles now ? An inflationary currency would be better."
"So an inflationary bitcoin is what we should go for ?" (2) asked.
"Not exactly," I said. "If folk's bitcoin were to lose its value immediately upon receiving it then where's their incentive to chew through electricity to run a mining node ? So even though inflationary currency makes better practical sense I think we'll have to go with deflationary for now and see if it works. If it fails we can always set it up as inflationary and get it running again."
"Ok, then," (2) said. "Deflationary it is. How would that be set up ?"
"Well," I said. "This is going to be similar to mining, right ? That means digging resources out of the ground. If it's like gold then there's only so much gold beneath the ground. Over time it will become harder and harder to find pockets of gold. The soil where the pockets are found will become more and more diluted, so there's less gold for every square meter. This means that there will only ever be a maximum amount of gold ever mined from the earth. The remuneration is higher at the beginning and diminishes over time until all gold has been mined. This makes the gold more and more scarcer over time which in turn would force its value upward, so long as there is a positive demand for it."
"What do you mean positive demand for it ?" (2) asked. "Won't it always be in demand ?"
"Only with a continuously increasing population that has demand for the same scant resources," I replied. "If the human population ever begins to drop significantly then the demand for the same resources will also drop. Gold itself would drop in value as there would be less demand for it. There may even come a time when the population is dropping so fast that gold becomes almost worthless as the gold in discarded electronic equipment is enough for the real demand of society."
"But it would still cost money to gather the discarded electronics and refine the minerals again," (2) said.
"Not at all," I said. "By that time we would have pretty much replaced all labouring work with automated robotics. Mining, recycling, refining, manufacture, fabrication, transportation, buying and selling would be activities heavily carried out with little human intervention. Our current societies and the structures built around and for them are built with the expectation that populations will continue to grow indefinitely. Extend that out a few hundred years. A few thousand years. We either get to a top population equilibrium or our technology makes us reduce our populations. How can we enjoy our beaches if there's standing room only ? It's not sustainable. We may find, even in our own lifetimes, the beginning of the Great Contraction."
"And what would that be ?" (2) asked.
"That is when we begin the process of dismantling our great cities," I replied. "Folks who don't sell up and move will find themselves surrounded by empty lots and grasslands as machines slowly break down and recycle the material from the neighbourhood houses. The value of properties themselves will drop as there won't be anyone wanting to move to that location any more. The value of land will drop, the costs of construction will drop due to robotic machinery. Those folks who have placed their retirement savings in the value of their property will see it evaporate. However, as the value is locked inside an inflationary currency model the value of their property is heading towards zero anyway. The dollar numbers may appear to always go up, the property price always increasing, but the true value of the dollar is going down faster."
"It's not going to happen that fast, surely," (2) said.
"Maybe, maybe not," I said. "With the state of the global financial system at the moment it's very clear governments, financial institutions, banks and central bankers really have little idea of what they're doing. They're all experts who are repeating each other like parrots. I'm sure they can all wave a book in the air and say ‘this other expert says I'm right'."
"That's great for us, right ?" (2) said. "With the financial systems broken and in disarray this is the perfect time for a workable electronic cash."
"For this crisis ? No," I said. "It'll take us time to work out the implementation details and create working code. Then it'll take even longer to build up a decent network and start getting value into the system. It's not this financial crisis that Bitcoin is being built for. It is to be built to handle to next Global Financial Crisis."
"And when will that be ?" (2) asked.
"If you look it up," I said, "There have been recessions every 10 years or so for the past few decades. As this one started in 2007/2008 we should expect another around 2017/2018. But it could start before 2014 or after 2020. We really don't know. We just know it will happen. This is when Bitcoin must be fully tested and be able to expand to meet the demand when everything gets screwed up by these experts again. However this time, they will be taking the retirement savings of the Baby Boomers and lumbering the cost of their retirement onto everyone else. The Baby Boomers include these self same experts. This time we need to be able to say no to these experts and allow folks around the globe to exit their local financial system."
"So back to making Bitcoin a scarce resource deflationary system," (2) said.
Maximum Mineable Bitcoin
I said, "There has to be a top maximum limit to the amount of bitcoin that's able to be mined. Just like setting limits in a computer game."
"So what should we make the top limit ? A billion bitcoin ? A trillion ?" (2) asked.
I said, "Due to being able to break bitcoin up into incredibly small bits we won't need to have trillions or billions of mineable bitcoin. It'd be more like farads as opposed to ohms."
"Say what again ?" (2) asked.
I said, "In electronics we use farads to represent capacitance and ohms to represent resistance. Ohms are small values. We use a 1kohm resistor with an LED to make it light up. Farads are absolutely huge values. We usually use values that are milli, micro, nano and pico - a thousandth, millionth, billionth, trillionth of a farad. So a bitcoin will be like a capacitor. When the network starts running bitcoin would be almost worthless and we'd be using whole bitcoins. However, as time goes by and more folks enter the system, creating more demand, we'll begin using the smaller and smaller bitcoin values. A range of values: millibitcoin, microbitcoin, nanobitcoin, and picobitcoin. The nanobitcoin would be 9 decimal places and picobitcoin 12 decimal places so if the system ever gets that much demand we can make it use 9 and 12 decimal places instead of the original 8."
"Ok," (2) said. "Its range of values will have a spread similar to capacitors. How many of them if not billions and gazillions ?"
"Well," I said. "This technology is supposed to be the answer to the ultimate question of life, the universe, and everything, right ? That would mean there should be 42."
"42 what ?" (2) asked. "Surely not just 42 bitcoin ever ! Even with the large range of smaller and smaller values there wouldn't be enough divisible bitcoin to cover the value of all property in existence. 42 thousand ? Hundred thousand ? Million ?"
I said, "A million sounds about right, I think. 42 million. With the divisible range up to 8 decimal places that would allow up to 4,200,000,000,000,000 or 4.2 quadrillion bitcoin bits. Before we reach that limit the divisible number of bits can be increased by allowing the use of additional decimal places."
"42 million bitcoin still sounds low to me." (2) said, "Are you sure ?"
I said, "A maximum mineable bitcoin of 42 million."
"How are we going to have the coin enter the system over time ?" (2) asked.
"This is a deflationary system," I said. "However every time coin enters the network it's actually a tiny piece of inflation. To make this a deflationary system but still have inflating bitcoin entering it, we have to come up with a balance between release rate and hitting the target."
The first attempt was just having 100 bitcoin released every 10 minutes and see where that got us.
That would've had all coin in the system within 8 years, and then it would abruptly stop.
We needed a way to decrease the rate-of-release over time so that the system eases into a fee-based structure when there is no longer any coin-base transaction for the miners.
So we tried other computations.
Start with 100 coin every 10 minutes and decrease it by 1 each time wouldn't hit our target.
How about it stays at a set amount and then decreases in steps ?
Every X days or weeks it gets smaller ?
We kept mucking about with it, trying many different ways.
At one point we were talking about how long it would take for the network to expand and to allow the release rate to be spread over that time.
We expected it may take a century or two ( though we were hoping in our own lifetimes ).
The average life expectancy worldwide is around 70 years of age.
We were both born in 1970, so trying for a final release target time of our life expectancy plus 100 years seemed fitting.
The steps between the coin-base reductions could neither occur too fast ( so monthly drops were out ) nor to slow ( one computation had it completing in about a thousand years ).
We looked at typical government election cycles.
These are things which also could neither occur too often as folks would get too annoyed with them nor occur too infrequently for folks to be adversely affected when they came around.
They needed to be at a rate that allowed folks to keep their purpose in their minds.
So the decision was between a 3 year cycle or a 4 year cycle.
I mentioned that since leap years come every 4 years, we should set it as 4 years so that each chunk of time had the same number of days in it.
(2) did some quick calculations and saw that it came to 210,241 blocks ( 6 x 24 x 365 x 4 ) + 1 for the leap year.
A few attempts were made trying to use the exact number of blocks.
It was simplified to 210,000 so that at a rate of 100 bitcoin per block, the first chunk of time would release 21 million coin into the system.
The coin-base amount would be reduced each 4 year time chunk and we'd reach our target of 42 million around the year 2140.
So now we had our target in the future of how many blocks would be generated every chunk of time.
I asked (2) to go away and use what we'd figured out for the calculation to see what rate the coin-base amount should be reduced by.
I said, "Try and make it simple. Dropping 1 percent, 5 percent, 10 percent, etc. Whatever works out".
He came back with it reducing over the time but it was too precise.
I mentioned to him that it was too complex and has to be simplified.
"Like what ?" he asked.
"I dunno. Maybe just cut the rate in half each time. It doesn't have to be so correct."
"Won't there be a problem with the mining reward halving every four years ?" (2) asked.
"There might be around the exact time of the change," I said. "But it should all equalise out in the end. The miners will suddenly find that it costs them twice as much to generate a block hash so their mining expenses effectively double immediately. This should cause them to hold onto the minted coin until such time as the value of bitcoin rises enough to cover the original generating expense."
"But how do you know that will happen ?" (2) asked.
"Because if they don't hold onto the minted coin," I said. "And try to exchange it into their local fiat currency to pay their bills then they will quickly run out of funds to pay their electricity and equipment costs. That miner will no-longer be in the game. The only miners that will continue long-term will be those that only allow their minted coin to at least cover the generation expenses as a minimum. Realistically they'll have to try to make their revenue exceed their expenses by double just before the next halving."
"What's to stop them from selling their bitcoin immediately ?" (2) asked. "That'll stop them from holding onto the minted coin long enough to affect its real-world price."
"I guess we're going to have to force them to hold the mined coin for a set duration," I said. "We need to make sure that they stay in the game to allow the market price to adjust to the real expense costs. When they mine a block they won't know the electricity costs until their bill comes in and they know for sure that the bitcoin-to-fiat-currency exchange rate will cover their expenses."
"You mean when they mint a coin they can't spend it straight away ?" (2) asked. "Why would they bother spending energy to generate block hashes if they couldn't spend the block reward for half a year or more ?"
"It shouldn't be half a year," I said. "Only a month or two would be enough for the market to adjust to any excessive price hikes by the utility companies. It'll also allow adjustment due to the current cost of the computing equipment as the international markets fluctuate. If electricity costs remain pretty constant but computer equipment costs continue to drop then folks mining will find an incentive to add more hardware into mining. If the equipment costs stay the same but electricity costs rise then miners will be incentivised to find cheaper forms of electricity - even if that means reallocating the equipment overseas."
He came back with a few changes.
"What happened with the 100 bitcoin per block initially ?", I asked. "You've got it starting with a 50 bitcoin reward."
(2) replied, "I had to reduce it to 50 otherwise this system would release the coin too fast, even using 4 year chunks of time. But by cutting it in half each time we get pretty close to our target of the year 2140. It's crazy how it just came out right."
I told him it was great and we moved onto the next problem.
"So what algorithm are we going to use for hashing ?" I asked.
From Cryptography and Number Theory for Digital Cash:
Two well-known hash functions are RSA's MD5 (Message Digest 5) and NIST's SHA-1 (Secure Hash Algorithm). The hash values for MD5 are 128-bits long, while those of SHA-1 are 160-bits. Two other hash functions are RIPEMD-128 and RIPEMD-160, which yield respectively 128- and 160-bit hashes.
In 1994 P. van Oorschot and M. Wiener estimated that for $10 million one could build a special purpose computer to look for MD5 collisions, and these could be found in 24 days on average.
"MD5 is definitely out," (2) said. "SHA-1 is the most commonly used and recommended hashing algorithm".
We looked through a lot of articles about the various hashing routines that've been used over the years, making note of which ones had been broken.
It was quite disturbing that, given enough time, a way has been found to break each previously recommended hashing algorithm until an updated or new algorithm is discovered.
Diffie-Hellman and RSA is mentioned briefly on a Cryptography webpage.
We looked at The hash function RIPEMD-160.
I have another look at Hal's site
His proof-of-work example from Hashcash uses SHA-1.
On reading through his FAQ section I found a link to an announcement about how SHA-1 has been broken.
"Does this mean that we're not going to be able to do this ?" I asked. "Every crypto expert recommends using SHA-1 and here's an announcement stating that it was broken back in 2005 !"
"It should be fine," (2) said. "RSA is just a type of algorithm and SHA is a family of similar algorithms. There's SHA-0, SHA-1, SHA-2 which is also SHA-256 and many more."
"Ok," I said. "So that means we just use SHA-2/256, right ? Until such time that it's broken as well."
I have a read through the comment section of that SHA-1 Broken announcement.
Lot's of folks figuring out how much time it would take to break the encryption over various iterations.
Even the US government had begun to phase out SHA-1 usage (https://web.archive.org/web/20060921175854/http://www.fcw.com:80/fcw/articles/2005/0207/web-hash-02-07-05.asp)
... advances in computer processing capability make it prudent to phase out SHA-1 by 2010
"Is there a way we can extend SHA256 ?" I asked.
"What do you mean extend ?" (2) said.
"I mean, make it as good as a SHA512 would be," I said. "If SHA-1/256 has already been broken then how long before SHA-2/256 is also broken ?"
"We could just use SHA-3/512 directly," (2) said.
"How much is this code used by others ?" I asked. "We only want to use code that's in high use so that we know its implementation is not broken."
"That's why we're going with SHA-2/256, right ?" (2) said.
I had to think a little about the formula used for the hashing algorithm.
"You're familiar with the SHA formula, right ?" I asked.
"Yep," (2) said. "I've studied this stuff extensively."
"Ok, then," I said. "Is there a way to make the calculation go further ? It's pretty much generating a random number in a very specific way, right ?"
"Well, it's not quite like that," (2) said.
He goes on to explain in far too much detail how the algorithms work for each SHA variation.
He's confusing the [redacted] out of me. I just need this simplified.
"So to sum up, it really is a random number that's been generated in a very specific way, right ?" I said. "You said that the same algorithm is called over and over to mix up the number ? That's called a recursive call. If we recursively call the same algorithm again, will it stuff up the hashing algorithm or would it make it better ?"
"You mean change the SHA-1/256 algorithm to iterate more ?" (2) said. "You know already that we shouldn't modify the crypto implementations ourselves. We need to use the exact same code that already in use all over the industry."
"Ok," I said. "Then what if we recursively call the hashing function again ? Make a hash of the hash. That'd effectively double how many random numbers are being generated, right ?"
"What ?" (2) said. "You mean get the hash of the data, and then generate a hash of that hash ? Why would you want to do that for ? That's not how it's supposed to be used."
"Yeh," I said. "But it would extend the number of randomisation. Effectively a random number of a random number."
"Well," (2) said. "It's not quite a full extension. The first hash is from the initial input data. The second hash only has the first hash as its input data."
"But it's a random number of a random number, right ?" I said.
"In a very loose fashion, yes," (2) said.
"Great !" I said. "Then we'll use SHA256( SHA256(
"I don't know if that method of doubling the hashing will be acceptable in the crypto community," (2) said. "It's not really done at all, ever."
"The same folks who are still using SHA-1 three years after it was broken ?" I said. "Once SHA-3/512 is in greater use throughout the industry then we can swap it out. If any of them have a better way of improving the hashing security then we'll use whatever they come up with."
"What are we going to use to sign transactions ?" I asked.
"RSA is main method used in the industry at the moment," (2) said.
I look up a link I'd saved from when I was iterating through the initial large crypto article list.
Crypto Elliptic Curve which explained Elliptic Curve Cryptography.
I looked again at the differences between RSA and Diffie-Hellman Key Size and Elliptic Curve Key Size.
Key Size (bits)
|Symmetric||RSA and Diffie-Hellman||Elliptic Curve|
I send (2) this link and tell him to look over the size comparisons.
"Where'd you get this link from ?" (2) asked.
"From one of the websites in that huge list you gave me," I said. "A link from a link from a link. I decided to do what you do, and burrow down through multiple layers of references to dig out the real tasty information."
"I hadn't seen this comparison before," (2) said.
"Have a look at the centre column," I said. "We used to use keys of 1024bits for signing using RSA. Now we're using 2048. Folks have suggested using 3072bit keys and larger. And others have complained that even the 2048bit keys are too large already."
"We've got the same problem," (2) said. "We want the strongest crypto for Bitcoin. But all this data will be traversing the internet round and round. We need the smallest key that gives us the strongest protection."
"Exactly," I said. "Now look at the Elliptic Curve column. Look how much smaller the key size needs to be to gain the same protection as an RSA key. This means that if we wanted to have really stronger encryption over the internet we should choose Elliptic Curve encryption because we could then get the equivalent of an RSA key of 15,360 bits with only 521 bits of Elliptic Curve. Even just using to lowest level ( 160 bits ) would yield the same security as an RSA using 1024 bits."
"Hang on," (2) said. "ECDSA isn't really used much at all in the industry."
We continued a heavy discussion on the attributes of ECDSA and comparisons with current key algorithms.
Elliptic Curve keys grab points on a curve that are related to one-another through the use of formulas drawing lines through and across the curve.
At one stage I was suggesting we extend ECDSA by turning the 2D curve into a 3D curve.
"How the [redacted] do we do that ?" (2) asked.
"We generate a 3D model," I said. "Something shaped like a blob. We can fire vectors at it and use hit-tests to find where on the shape the vector touches. From that point on the shape we can fire off other vectors to hit other parts of the shape. After a certain number of bounces we can use the last point as the randomised number."
"It's bad enough that we're looking at possibly using ECDSA keys," (2) said. "I really think we should leave this untested and non-existent 3D stuff out of it."
"Fair enough," I said. "So we'll use ECDSA keys for signing ?"
"But it's still not something that's in wide use," (2) said. "We made a rule to only use what the industry currently uses."
"The industry's wrong," I said. "We're building something that, if it works, will change the entire landscape of the industry forever. ECDSA is clearly far better that RSA, the algorithm has been tested and works fine. The incumbents in this field are just waiting for someone to go first with it. We can be the ones that everyone else follows."
"I get the impression that you want people to stick to the rules when you want them to stick to rules, and throw them away and just wing it whenever it suites you."
"Now we're starting to know one another !" I said. "Think of the rules as more like guidelines. So long as we're heading toward to goal-line we can be as flexible as we need to be."
"Ok, then," (2) said. "We'll use ECDSA. The benefits compared to RSA make it obvious to be the method for any internet-based key use.
I had (2) go through the current list of port numbers used by known applications and systems.
"Pick a port number for us to use," I asked. "It's got to be one of the numbers that isn't being used by a system or application that many people use."
"What does that mean ?" (2) asked.
"It means don't pick 80 because that's used for the HyperText Transfer Protocol (HTTP) for websites," I said. "Don't use 443 because that's for HTTPS. Don't use 21 because that's used for the File Transfer Protocol (FTP). Pick one that has four digits."
"How about 7575 ?" (2) asked.
"Why did you pick 7575 for ?" I asked.
"You said to pick any number that isn't used by common software," (2) said. "Well 7575 fits the bill. What's the problem with it ?"
"When I said 'Pick any number' I meant it to still be specifically for Bitcoin," I said.
"You said pick any number," (2) said. "and I picked any number. And now you're complaining about it."
I had the feeling he was a wee bit upset with me again.
"How about you look through the list and pick a number if you know what to look for ?" (2) said.
"Fine," I replied.
I started scrolling through the list, ignoring any port numbers that were in use by popular software.
When I got down to the 8000s I thought, "Hang about... This might be the place to look."
"Have a look at the 8000 range," I said.
"Why should I ?" (2) said.
"Because an 8 looks like a B for blockchain and Bitcoin," I said.
He looked through and started throwing out random numbers from the 8000 range.
"You're still not being specific enough," I said. "Remember: If we're correct about most of what we've figured out then this port number will end up being as important as port 80 and port 443 and port 21 is today. Internet browsers will one day allow folks to connect to a Bitcoin server as easily as surfing the 'net or using FTP to transfer files."
"Well, you choose a number then," (2) said.
He was really getting annoyed at me.
I quickly scrolled down to 8888.
Something called the NewsEDGE server was using it officially and a couple of others unofficially.
I had a deck of cards nearby and kept glancing over at it.
My brain was obviously trying to tell me something but I didn't know what.
I flicked out the four 8s from the deck and spread them out on the table.
That wasn't it.
"Have you selected the port number yet," (2) asked.
[redacted]... that guy....
I then picked them them up and spread them out in my hand.
I checked the Port Number list for 8333.
Already taken by VMware Server Management User Interface (secure web interface).
But it's Unofficial!
That means we might be able to make Bitcoin the official protocol for port 8333.
"Got the port number," I told (2). "It's going to be 8333."
"What's so special about that number ?" (2) asked. "It's just as random as the ones I picked. Why is your random number better than mine ?"
"8333 is like four Bs in a chain," I said. "A blockchain of blocks ! Can you believe it !"
"[redacted] seriously ?" (2) asked. "Wow. So it's like the chain of blocks in Bitcoin. That's [redacted] amazing !"
(2) looked it up on the Port Number list.
"There's a problem here," (2) said. "Port number 8333 is already being used by VMWare. We can't use it."
"VMWare is using that port number unofficially," I said. "If we can build the Bitcoin network up large enough then we can make Bitcoin the official protocol for 8333."
"But you said I couldn't pick any number that's already in use by others so that there's no clashes," (2) protested. "And then you go and pick a number that does clash. With VMWare at that !"
"Well," I said. "That's before I discovered the perfect port number for Bitcoin."
"And the clashing ?" (2) asked.
I said, "We'll make sure the protocol handshakes first so that only connections can be made with other Bitcoin nodes. It'll be fine."
"If it's fine then what's with the picking of numbers not already in use ?" (2) said.
"That was just first preference, that's all," I said.
"Ok then," (2) said. "Hey! Not only can the number signify a chain of blocks, it could also mean four blockchains as well, right ?"
"You mean the idea for one main chain for each of the major sections of a civilisation ?" I asked. "Currency, Identity, Ownership, etc ? There's far more than four, isn't there ? And whatever we come up with, other people will come up with more."
"Yeh," (2) said. "But we can start with four blockchains. Bitcoin is the first proof-of-concept experiment. Once it's working we can bring the others online."
"I like that idea," I said. "We could also think of it as one main blockchain ( Bitcoin ) and other smaller ones attached to it. Like a large sprocket and smaller sprockets linked by the blockchain by their cogs."
Psychohistoric Game Theory
We were coming up with various ideas on how parts of the implementation would work together.
There was never anything concrete in the decisions.
Choose this way or that.
This value or that.
It was very unsatisfactory.
I needed to push through an effort and figure out if a form of practical psychohistory could be created that would help me in making better choices.
We discussed the various ways groups interact and listed them based upon how much effort or how expensive they were.
The most expensive ( and least profitable ) interactions were when folks go head-to-head competing with one another.
The least expensive ( and most profitable ) interactions is when they were inside a monopoly - effectively they were interacting with themselves.
You see these monopolies when one company owns many brands and those brands pretend to compete against one another to keep the government regulators at bay.
Cartels are another form of monopoly where multiple groups agree to have monopolies based upon geographic location ( the Spanish and Portuguese dividing up the Americas )
Any decision making had to take into account what would happen if the actors were running a monopolistic, merging, co-operating or competing strategy within a game.
Delving back into the realm of game theory I devoured as many reference sources as I possibly could over the coming week.
Following (2)'s example I pursued the reference material from any popular game theory works and in turn recursively absorbing their reference material.
Pages upon pages were written and drawn up of examples of game theory graphs following each formula one by one.
Once many of the formulas and graphs were learnt I went back through them and began inputting electronic cash and network system points into the formulas to see what would pop out.
It appeared to be working as I adjusted the points to fit the result I wanted.
After a few more days I began to realise that it just wouldn't work.
The points I was choosing were just numbers pulled out of the air.
They didn't have any basis in reality and could be adjusted at whim by whoever was wanting to make a note within their own bias.
I needed this to work no matter who's using it.
It couldn't use fixed locked in points.
Psychohistory is a probabilistic system which is supposed to give you a pretty reasonable idea of the direction groups of folks would head towards.
I needed to have these formulas work using probabilities instead of single points.
Looking up reference material I hunted down what symbols mathematicians use to describe probabilities and included them into the game theory formulas.
When someone makes a decision it's based upon their perception.
If they notice someone else doing something their perception modifies.
The formulas in game theory had to be probabilistic and also adjust depending upon weighted feedback from other running games.
I began looking around mathematics sites where they used ranges and percentages inside of formulas.
The first tests used only two values for the strategies in each corner of a game graph.
A high/lower value.
Instead of each actor in the game being completely isolated from each other, I decided to see how their strategies would change if they:
- didn't know what the other actor selected.
- knew what the other actor selected.
- perceived what the other actor selected.
This meant that actors could play strategies whereby they chose one strategy but made the other actor think they chose another strategy.
When an actor knew what the other person chose, they could actually be being lied to and so the chosen strategy ends up being detrimental for them.
Even with only a couple of values for each strategy I could have the calculations go round and around until a result pops out saying Actor#1 would most likely do X and Actor#2 would most likely do Y.
Every time one of them tried a strategy that would destroy their opponent I'd adjust the initial system attributes and run it again.
It was like when I used lock-wire to fasten bolts in the air force.
Lock-wire is a very thin wire which goes through holes in bolts and nuts.
When you want to make sure expensive equipment inside a jet fighter didn't shake loose and bounce abut inside the fuselage of the aircraft you locked the bolts/nuts in such a fashion that it's impossible for them to unwind and loosen.
The bolts/nuts unscrew counter-clockwise.
This means to insert the lock-wire through a hole in one bolt/nut, twist the two ends together and make it enter the hole on the other bolt/nut so that as a bolt/nut tries to unscrew itself the wire will try to turn it in the opposite direction.
It will always be trying to fasten the bolts and nuts.
That's the purpose of the psychohistoric game theory.
As the actors try to shake and break the system, the incentivisation system will be making it lock in tighter and tighter.
I started having the two actors in one game begin to influence the perceptions of actors in other games just to see which pieces might spiral out of control.
One way someone could break the system would be by spamming many tiny transactions throughout the network.
Tiny transactions are those valued in the sub-cents where the cost of transmission and validating a transaction cost more than the value of the transaction itself.
What to add to the design to counter that ?
Even though Hashcash was originally made for stopping email spam by forcing senders to use a form of proof-of-work to send an email - effectively making them spend money to send spam - that might work in Bitcoin for transactions.
We were already using proof-of-work for locking in the chronological order of data.
Maybe have a sender of a transaction generate a POW hash so that validators can confirm a certain amount of work was done to create the transaction ?
The sender will lose funds by having to pay for the electricity required to generate the hashes, right ?
No. That wouldn't work.
Someone could have arduino-compatible devices creating these tiny transactions and have them powered by cheap solar panels.
A single roomful of these devices - just a few ten thousand dollars worth, would bring the entire network down to a crawl.
What I needed was a way to drain the spammers funds and at the same time make the network stronger.
So I followed the money.
Transactions get sent to an address and change gets sent back to another address.
Any difference between the two addresses ends up as a fee that a miner can take.
As a spammer begins to clog up the network the mining nodes will only choose those transactions which give it the highest fees.
A fee market will rise automatically.
As the acceptable fee size rises either the spammed transactions will get completely ignored and never entered into a block or the spammer raises the fees their spam transactions pay.
If the spammer raises their paid fees then at some point they will run out of funds.
And something magical would've happened.
It becomes a transfer of wealth between the spammer and the miner.
A bad actor has just transferred all their funds to a miner just to be a pain in the backside for a short while.
And now that they'd out of funds, the spammer goes away and their funds stay within the system.
I told (2) about the solution to the spamming issue is to actively encourage folks to spam the network.
"Are you nuts ?" (2) said. "The worst thing we could do is to get people attacking us."
"Every system works if everyone is being nice and lovely with one another," I said. "It must be expected that there are bad actors out there and that they will attempt to break our system. If the system cannot withstand an attack then it will never work ever."
"But encourage spammers to spam ?" (2) said.
"That's that main idea here," I said. "To create a game whereby everyone believes they have complete and total free will. But they really don't. The system has to takes what their possible strategies might be and counter the negative strategies and enhance the positive strategies."
"And so it's made for spammers to spam the network ?" (2) said. "And what else ?"
"It's also going to have to allow miners to try whatever they want to try and monopolise the system," I said.
"But that will destroy it," (2) said.
"Then it would never work anyway," I said. "There will always be bad actors out there. As Bitcoin becomes larger it will attract folks from every moral and ethical background. It's got to work with those darker elements. Where another system would break, our one must gain strength."
When a node mines a block we've got to stop them turning around and transferring it immediately.
We've got to make them stay in the game.
So the coinbase needs to mature over time like a cheese or wine ?
For how long ?
About a month I'd say
Like [redacted] am I going to be forced to wait a whole month before spending the coin. If people can end up paying their electricity bills with Bitcoin then they'll need access to it a lot sooner.
They'll just have to spend the coins they'd mined in the previous months.
He ended up having the maturing rate set to under a day.
To have a planetary civilisation that is truely viable it would have to change the fundamental way material is mined from the ground, processed, fabricated, used. No-longer can anything just be dumped. Every single thing would have to be recycled in some fashion.
Literally tagging fabricated goods so that at any one time the entire planet knows who's responsible for that little piece of it.
On the 18th August, 2008, I was on nightshift and (2) emailed me that he was worried.
"I've been told that a patent has just been applied for that sounds like it might've come from our stuff, " he said.
He sent the link and said that one of the others he's been using to help with our questions mentioned this to him saying that wondered if it's a problem.
(2) said, "I partially trust that the people I've sent the white paper draft to will not use the information in it. But I don't know who else they might've passed it on."
"It should be ok, " I said. "As I've said before, if anyone uses the information then all their peers would ostracise them."
"Maybe, " (2) said. "But if we're correct, and we've actually solved the most important problem in the computing age, then you wouldn't need community peers any longer. You'd be beyond and above them. If anything, your previous peers would be coming to you to join your new community."
"You might be right", I said. "What should we do about it ? It's too late to withdraw the draft white paper from circulation now."
(2) said, "I've already told the people I sent it to to not send it on to anyone else. They've all agreed. But a few of them showed it to their friend/ acquaintances and we don't know who else has seen it."
"That may be a bit of a problem then," I said.
"More than that," (2) said. "Many of the people that are looking over the draft don't really understand what it is or means. They're treating it as if it's just another failed attempt for electronic cash and it's likely we're not going to get the suggested updates and corrections we were hoping for."
"We'll see after they've had a chance to have a decent look and have ay of their questions answered," I said. "For now, we've got to have something out their on public record so that if any of them start incorporating our stuff into their printed material we can point at a specific point in time and say they have to show proof that their material was created before us."
(2) asked, "What kind of public record ?"
I replied, "We're going to have to bring forward the purchasing of the domain name for the project."
"But we were going to do all that at the same time," (2) said. "Get the domain name, set up a hosted site and publish the white paper all at the same time."
"Well," I said. "This problem you've brought up means we have to get it now. Every now and then I've purchased a dozen domains at a time so the process is quite straight forward."
"I purchase lots of domains at a time as well," (2) said. "I think I have over a hundred now."
"Over... a... hundred... ?" I asked. "Seriously ? I don't take you as the type of guy that'd have an insane number of domains."
"Check them out," (2) said.
He sent a list of links to dozens and dozens of domains.
Checking out a few of them I could see he owned them all.
Bloody [redacted] !
This guy might be more crazy than I am !
"Remember that the .com address has already been taken," (2) said. "It'll take too long to try and negotiate obtaining that domain for those people so we need to decide what other domain to choose first."
"We've already decided that this has to be an open source project right ?" I said. "That would imply a non-profit organisation."
"Yeh," (2) said. "But this is also going to be an absolutely massive network. It should be .net ."
"Maybe we start with .org for the non-profit organisation - the open source project," I said. "Then .net for the network and later on obtain .com for commercial spin-offs ?"
"Ok," (2) said. "Go and purchase the .org domain name plus the various misspellings of it."
"Me ?" I queried. "Since you've got a lot more experience buying domain names maybe you should do it."
"Nah, you can do it," (2) insisted.
"Well, what about (3) ?" I asked. "He could purchase the domain name. Don't leave him out of the conversation."
"I haven't left him out at all," (2) said. "Some of the things I've been typing are directly from him. He thinks we should use the domain purchase to have you put in a bit of risk into the project. So far you've made us take all of the public-facing risks. It's time for you to share the risk with us."
"But you've got to use a credit card to make any purchase," I complained. "That means there'll be a real-world record connecting me with the project."
"And you think it's ok for us to have this link between the project and the real-world instead ?" (2) asked. "I thought we were in this together. (3)'s saying that if you don't buy the domain name that we should think about whether we stay together in this or separate."
"I'm going to have to think about this first," I said. "I'm not going to decide in just a few minutes. But while I mull it over, let's go through options to purchase it. Whichever one of us ends up buying the domain name, we won't just be getting it through a generic bulk domain name site, right ?"
"I use anonymousspeech for some of this stuff," (2) said. "It allows you to create anonymous email addresses and domains. Sign up at anonymousspeech."
"Ok then," I said. "But we're using a Japanese name for publishing this under we should use a Japanese domain name site. That way whenever someone does a whois on it it'll make them confirm that it is a Japanese person."
"anonymousspeech is completely based in Japan," (2) said. "Whois will show their Japanese servers."
"That's absolutely perfect," I said.
"Are you buying it now ?" (2) asked.
"Hang on," I said. "I'm at work at the moment and busy. Give me an hour."
I keep contemplating whether to use my credit card or not.
It's not really fair to the others if they take all the risk, so I sign up for an anonymousspeech account and go through the process of purchasing the bitcoin.org domain name.
Bank account records get purged after 7 years where I live so I just need to make sure I'm protected until such time that the records are removed from the bank forever.
It was quite a simple process.
It only took about quarter of an hour, and that's including reading everything to make sure I don't stuff it up.
I had to continue with a bit of work at that point for the next half hour.
Just before the hour was up I contacted (2) again.
"I decided to go ahead and get the domain for us", I said.
"Don't bother", (2) said. "(3) has said he'll do it."
"No, you don't understand", I said. "I've got it."
(2) said, "(3) said a quarter of an hour ago that he'll do it".
"I'm a wee bit confused", I said. "How could he purchase the domain name a quarter hour ago if I purchased it forty five minutes ago ? Is that anonymousspeech site double-dipping on domain charges ?"
"What do you mean ?" (2) asked.
"I'll see if I can make it clearer for you", I said. "Forty five minutes ago I went through the anonymouspeech site and purchased the domain for us. How is it possible for (3) to do the same ?"
"Hang on", (2) said. "I'll check this with (3)"
He came back a little while later.
(2) said, "(3) says that he's been trying to purchase the domain for the past half an hour but it keeps failing and saying it's already been taken. I thought you weren't going to get it because you didn't want your credit-card to be linked to the domain purchase ?"
"I guess I'm just going to have to be very quiet for the next seven years", I said.
Late morning 1st November 2008 (2) emails me.
"It's published," (2) said.
"What's published ?" I ask.
"The Bitcoin white paper," (2) said. "I've published to a crypto mailing list".
He sent me the link where he'd posted under his Satoshi email adderess.
After reading what he'd posted ( pretty much the Abstract and some supporting text ) I downloaded the Bitcoin White paper pdf file and looked it over.
It seemed pretty much straight forward.
I see he's changed the title to include Bitcoin as the name for the paper.
There's the Satoshi Nakamoto handle to represent us until we were sure it was safe to change it to our own names.
I noticed that he'd inserted his Satoshi email address up there.
There's the Abstract I wrote, when he'd asked me for an Introduction.
There's the Introduction section (2) and (3) wrote using some of the explanations from my previous emails.
"What's with the changed text in the Introduction section ?" I asked. "Some of these phrases weren't in the original section you showed me."
"Oh, that's to cover ourselves if those people that applied for that patent try to [redacted] us over," (2) said. "I took a few phrases from their patent application and put them into the Bitcoin white-paper. Like you said, if they did get some of their ideas from our draft white-paper then all of their peers will notice the same phrases used between ther patent and our white-paper. Their peers will ostracize them from their community and they'll never be trusted in a professional capacity ever again."
I smiled as I read his reply.
He was learning.
I begin on the sections.
Something's not quite right here.
He was supposed to paraphrase the explanations I gave him, but it appears most of the text is exactly how I'd sent it to him.
I notice the images were the ones he'd sent me to confirm that they were correct and agreed with my original images.
Now I know what drawing program he'd used to create the images he'd shown me - they were trimmed screenshots from Adobe Acrobat as he was creating the images directly inside the document.
I read some more and a knot of fear began to rise from the pit of my belly.
The text I'd given him to explain the system was mostly copy and pasted directly from my emails to him when I was figuring this thing out.
And that meant that there was close to a one-to-one correlation between private emails I'd sent and this text that was now publicly available and already on other peoples computers.
"At what time are you ever going to read and understand the Cypherpunks manifesto ?" I asked.
"What's wrong ?" (2) asked. "Isn't it like you wanted it ?"
"What I wanted it ?" I said. "You're the one who's been insisting on releasing a whitepaper on an electronic cash solution this year. Not me. I told you there's about another six months of work needed before a complete white paper would be ready."
"Yeah," (2) said. "But for this initial white paper it has all the stuff you gave us. The sections are all there and the spelling and grammar and sentence structure has all been looked over by others and adjusted and improved."
"What are you talking about ?" I said. "The text has hardly been changed at all. It looks like only about two to five percent of the text has been modified."
"But that's what you wanted ups to publish, right ?" (2) said.
He seemed to realise that something was amiss.
"Publish ?" I said. "I gave you the general explanation for the solution. Plus the rough grammar and vocabulary level to explain it to non-crypto folks. You were never supposed to use the text as-is."
"But we asked you specifically if that text was exactly how you'd like us to use," (2) said.
"You were supposed to use it as an example and type up the textual explanation yourself in your own words," I said. "You weren't supposed to use mine directly. What the [redacted] have you done ?"
I was pretty upset by this stage.
"Oh [redacted]," (2) said. "I thought this is what you wanted. We've got the Satoshi moniker and email address as the white paper author just as you wanted. We've got the Abstract and most of the information you sent over in the various sections. I even wrote up a Calculation section because you asked for it. And now you're saying that you didn't want it published like that at all ?"
"I was under the impression that my stuff would be only one part of the rest of the white paper you were re-writing after throwing out your earlier attempt," I said. "I had no idea that 90% of the paper was going to be only my text."
"Ok," (2) said. "I'll pull the paper down and we can go through it again and change anything you want."
"How long has the file been downloadable on the 'net ?" I ask.
"Only a couple of hours," (2) said. "I've notified others that've helped to edit it and only a few outsiders would’ve downloaded it by now. I can pull it and we can fix this."
I think it over for a few minutes.
Very few folks would've accessed the file, but looking into the future when the [redacted] hits the fan those few folks would been able to supply the original Bitcoin white paper file to the world and textual comparisons would be made.
"It's too late," I said. "This text has been distributed to whoever you sent the draft white-paper to, plus whoever they forwarded it onto. Leave it up there. Even if a single person has downloaded the file it would already be too late. I really can't believe you did this to me. After all my efforts to remain protected, anonymous and safe even from the outer Satoshi team, you've gone and thrown me out into the wild."
"I'm [redacted] sorry," (2) said. "I truely thought we were doing the right thing and didn't realise it wasn't what you wanted."
"What's done is done," I said. "We're going to be making many mistakes and missteps along the way and we're just going to have to roll with the errors and change how we do things as we move forward."
"Phew," (2) said. "Glad to hear that. I'll be far more careful in the future. We've still got a lot of work deciding how to code a working example of the solution."
"Yeah, about that," I said. "One of the changes is that I won't be coding up the solution any more."
"Wait, what ?" (2) said. "What do you mean you won't code anymore ? I thought we just cleared up the white paper release problem and will double check with you before we publish your text in the future ?"
"That's correct," I said. "But the white paper has already been released. My text and how I form sentence structure has now been sent into the world for one of the most secret projects that will have the largest impact on the future human species. If I code up the solution then folks will be able to compare the code structure to my previous code projects and the text I've posted in public. My previous public work was mainly code. And nothing crypto-related. So it'd still be difficult for anyone to check grammer usage. But I am now exposed. I will not be coding any more for Bitcoin."
"You can't do that," (2) said. "Who else can do this ? The others barely understand what you've come up with and can only handle small pieces of the puzzle at a time. You're the only one who understands how this entire thing works together. You can't stop coding it now."
"Tough [redacted]," I said. "It's done. Go read the Cypherpunks manifesto again and try to comprehend the bit about privacy and not giving out someone's private information without their express permission. My text is my private information that you made public. I'm no longer coding for the project."
"But who will code it ?" (2) said. "I've been telling the others that I'm creating code that will put into practice the ideas in the white paper. They're really interested to see if I can pull it off. If you don't code it who can ?"
"That's a SEP," I said.
"What's a SEP ?" (2) asked.
"A SEP is Somebody Else's Problem," I said. "It's when something's on the edge of your peripheral vision and your subconscious refuses to admit it exists."
"What ?" (2) asked.
"Go read The Hitchhiker's Guide to the Galaxy again," I said.
"That's not going to help me right now in having an example coded up," (2) said.
"How about you try and contact Hal," I said.
"Who ?" (2) asked.
"That guy who owns the RPOW website," I said. "The Reusable-Proof-Of-Work stuff. The site (3) sent me to when I asked him where he learnt about proof-of-work. If anyone exists that should be able to understand what I've written and also be able to code up a working solution, it'll be Hal."
"I'll try to contact him," (2) said.
Over the next week or so we had a few folks emailing (2)'s Satoshi email address, asking him about various aspects on the ideas.
(2) also kept tabs on any replies on the mailing list.
When a question came in he'd email me requesting the text for a reply.
The times that he emailed me and I was able to respond immediately there was almost a real-time back-and-forth between all of us.
However I still had a job to go to and often he'd email me and I was unabe to reply until my shift-work was over.
This had often happened with the folks in the outer Satoshi team.
I'd told him, when he wasn't able to give them my reply because I was unavailable, to tell them that he, himself, cannot reply because he had to go to work.
After a couple of weeks of this process he was complaining that he was frustrated that he was receiving all this correspondance but couldn't reply until I was available.
I suggested that he place my Satoshi email address at the top of the Bitcoin white-paper so that the emails would come directly to me.
He made the change and the Bitcoin white-paper was updated with a few other minor adjustments about three weeks after the original release date.
The website was also changed to show my Satoshi gmx email address.
He'd been using his Satoshi vistomail email address for all correspondance with those in the outer Satoshi team, mailing lists, plus others he'd asked questions regarding crypto and economics.
Most of the Satoshi correspondance continued via his account.
Oddly enough, not many folks thought to email Satoshi directly via the gmx address.
After a month or so the emailed questions stopped coming.
Most communication ended up being via the Bitcoin message-board - the first one on Source-Forge.
We'd created a Satoshi sourceforge account back on the 5th October before the white paper release.
Mine was nakamoto2. And here
(2)'s was s_nakamoto
s_nakamoto registered on 2008-12-10
The Bitcoin project on our sourceforge account was established around mid-day, 10th November 2008.
Due to server timezone differences the sourceforge servers logged the creation date as 2008-11-09 18:58.
(2) set up [two admin accounts] and removed the default account.
(https://web-beta.archive.org/web/20090106201347/https://sourceforge.net/projects/bitcoin/). nakamoto2 was mine, s_nakamoto was (2)'s.
I kept refusing to use nakamoto2 and sent any code adjustments or updates directly to (2).
Later on we established a forum on source-forge to help build up a community around the project.
All three of us had access to the Satoshi source-forge forum account.
Over the course of 2009, as the preferred direction of the project diverged between me and (2), there were a few posts made where Satoshi contradicted himself or used quite different vocabulary and grammar usage.
By August/ September 2009 we had new-comers checking through all previous posts and then creating a thread asking if Satoshi was an individual or a team.
Everyone up till that point had assumed Satoshi was an individual and now members were actively posting evidence that either Satoshi had some sort of bi-polar disorder or it was definitely a team effort.
That's where those original rumours - that Satoshi was a team - came from.
Hal came on board almost immediately.
He was really quite interested in how we'd used ideas from his RPOW for Bitcoin.
One of the first things he did was to change the code to use a more modern form of C++.
Vectors and maps.
Suddenly, I was unable to read the source-code clearly.
Coming from a 3D programming perspective, to me vectors meant a position and direction in 3D space.
A map meant height-maps, terrain maps.
When you read or think of something your brain pulls in all of the associated material for that subject.
Those folks who had only learnt about vectors and maps from straight C++ programming didn't have a problem reading this updated code.
But for me, my brain began to fail me - sabotaging my understanding of what I was attempting to read.
I complained to (2) that the source-code was becoming un-readable and asked him to tell Hal and the others who were helping with the code to stop using these modern vector and map syntax.
"I asked them," (2) said. "They came back and saif that this syntax is quite a few year old now and not new at all."
"So they won't stop using it ?" I asked.
"Some of them don't know how to program without using it," (2) said. "So that's the way the code will be from now on."
I threw my hands up in the air in disgust.
To [redacted] with them then.
They can go code up the proof-of-concept any way they wish.
I won't even bother looking at it.
There's nothing worse ( in programming ) when you've put so much effort into getting something working and then have someone else come along and mess it all up so you don't even recognise it any more.
But for this project to succeed, for it to be able to progress far out into the future, it has to be maintained and extended without my involvement at all.
I took this as another test of the fates.
To practice humility and be humble.
Allow others in to help guide the direction of the project.
It took quite an effort to stop screaming towards the rafters that they were [redacted] everything up.
Hal and others had many questions on the tech and channelled then to the Satoshi vistomail account - (2)'s account.
He in turn passed the questions onto me and I'd answer them.
(2) kept asking me to help out with the code and, every time I looked at it, I kept refusing and only made suggestions here and there.
Even though the code was reasonably complete, there were numerous bugs and crashes occuring.
Not from the code that I'd built, but from all these changes that'd been made.
In the first week of December 2008 I told (2) That the deadline for release is the 1st January 2009.
"I'm trying my best," (2) said. "The client isn't even able to run right now witout crashing. Can't you spend some time on it with us ?"
"I've told you already," I said. "I can barely understand what I'm reading in the source-code nowadays. Those others you brought in to help out have made the code so convulated the complex that they can't even find where these crashes are happening or what the bugs are. My code was never like that."
"I know," (2) said. "I really don't know why they changed it like they did."
"They're going to have to start putting asserts throughout the source-code," I said.
"What are asserts ?" (2) asked.
"They allow you to check whether something is true," I said. "And then the program will crash at that point if it is untrue or false. Folks used it in the Win32 Asm programs to make sure the program doesn't proceed if pre-conditions had not been met."
"But we don't want the program to crash," (2) said. "The one thing we want to stop happening is the program crashing."
"Not at all," I said. "If a pre-condition, which must be true, is currently false, then we most definitely want the program to stop. Normally in a program I'd code it so that all pre-conditions would be checked at the beginning of every single function and would fail gracefully if something was wrong. The program would continue to function and it would just display failure and error, and success messages to the user so they'd know what went wrong."
"These others," I continued. "Who have ripped out all my pre-condition code and built a 'I hope the objects and data being sent around the various functions are all correct and not broken', have made a buggy pile of mess. We need asserts on every single function call. And not just for the debug build. Use them for the release build as well."
"I told the others that," (2) said. "They said that using asserts is a good idea, but they shouldn't be used on the release build."
"They're the ones who've made this buggy crap of a source-code," I said. "I don't trust their coding skills now. If the code fails in an important function then have the entire progrm crash. That should force them to get it right."
"They're not going to like it," (2) said. "But I agree with you. The movement of this data is far too important. If something is wrong in how the code is handling a given situation then, as you say, it's better for everything to just stop and not allow bad data to become embeded into a block."
"In my Win32 Asm days," I said. "We used marcos everywhere, for everything. It was the main way we managed to get object-oriented programming techniques into the assembly world. Is it possible for the folks you've got programming the client to use macros for the assert calls ? Wrap up any call that can fail fatally inside a macro ?"
(2) passed along the suggestion and they began to use macros for firing off the assert exceptions.
Midway through December and the client would fail again and again.
Hal was making huge strides in improving the block handling code.
However, whenever the client dialog box actaully appeared, it would crash if you actully tried to do anything.
Come late December and (2) told me he doesn't think he'll be able to meet the deadline.
There's just too many issues with the code and it's just not possible to get them all fixed before the 1st January, 2009.
"What parts of the client do we really need to be running on the 1st ?" I asked. "The dialog box has to appear, it has to connect to another client, it has to create a block and send it to the other client. Just fix the pieces that must be working by the deadline and fix the rest over the coming weeks as they're needed."
"So we don't need the entire client to be completely functional on the 1st ?" (2) asked.
"Not at all," I said. "All you need is for it to create a block by finding the hash of the Genesis block header and use that inside its own header. There won't be any transactions except for the very first block reward inside that generated block. You can adjust my previous code so that the transaction structure is the same as what you're using now and then generate the binary for the transaction and use that directly inside the first block."
"Oh [redacted] !" (2) said. "This is great. We'll just focus on getting the transaction and block data transferring over the network and hardcode the first transaction and block."
"You don't even have to transmit the transaction for the first run of the program," I said. "That other client isn't going to be mining a block, right ? So it doesn't need the transaction this first time."
"But doesn't it have to validate the transaction ?" (2) asked.
"That's the bit of the code that's broken, right ?" I said. "Leave it for now and we'll get it fixed after the first block is embeded into the chain."
"But a block's supposed to be created every ten minutes," (2) said. "We can't hardcode each and every block until we get the validation code working properly."
"Clearly you're going to run the client just so that we can have the chain locked in as starting on the 1st Janary 2009. After that we'll stop it and get everything else working. It may have to be stopped for a few days or even a few weeks until it's fixed. Then we can start it up again."
"But there'll be a huge gap between these blocks," (2) said. "Won't that be a problem ?"
"This is a very experimental proof-of-concept project," I said. "It is expected that there will be times when we find a problem and tell everyone to stop running their clients until we fix it. There will be attack vectors we haven't discussed yet. While we adjust the code to patch these security holes there will probably be more of these pauses and halts."
"I don't like the idea of stopping the network just because a new attack vector is discovered," (2) said. "I'd much rather keep the network running and let everyone know when an updated client is available.
"If we have to initially send the data manually via email," I said. "Then that's what we'll do. Whatever it takes. We continue until it works."
"Right," (2) said.
"And make sure when you mine the first block you embed a real-world timestamp into it," I said.
"what do you mean real-world ?" (2) asked. "Isn't this entire system a chronological-order time-stamp system ?"
"I mean for the very first block," I said. "Just like those folks who hold up a magazine or newspaper to prove that on a given date they were there. We need the first block to prove that it was actually mined on that paticular day and not months earlier. It's got to be something that anyone can confirm that the start date was the 1st January 2009"
"I'll see what I can do," (2) said.
The 1st January, 2009 comes and goes.
I was expecting an email from (2) saying it's up and running and the first block had been mined.
On 2nd January 2009 I messaged (2).
"What's up with the client ?" I asked. "Did you manage to get it running and generate the first block ?"
"Sorry," (2) said. "I've been trying really hard. The others have been working their [redacted] off trying to get the basic functionality working. Another few days and it should be working."
"The deadline was the 1st," I said. "It was the perfect start-time for the chain. Start of a new year. Start of a new way for folks to become self-sovereign individuals. And you've missed it. [redacted]"
I was a wee bit annoyed.
The morning of the 4th January, 2009 (2) contacts me.
"I've mined the first block just as you suggested," (2) said. "The client crashed soon after and I just sent the block data directly to the others running the client."
He sent the block data as an attachment and I added it into the relevant folder.
"Have a look at the message I embeded into the transaction," (2) said.
I ran the client and looked at the block.
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
Archive from 2017
"Where the [redacted] is that text from ?" I asked.
"As it says right there, it's from The Times newspaper," (2) said. "It's a major newspaper in London."
He gave me a direct link to the website article.
"You think will be ok," (2) asked. "Or should I chose something else ?"
"I thought you said it'll still be a few more days before the client's stable enough to mine the first block before the program crashes ?" I said.
"It will be," (2) said. "As I said, the program crashed immediately. But I saw the headline today and thought it might be more relevant to the project. If you want I can wait a few more days for the client to be more stable."
"Oh [redacted] no," I said. "Buggy and crashing piece of [redacted] software or not, this headline is just perfect. In a couple more days who knows what the headline would be. I just had a look at the previous few days on The Times. It appears the Fates themselves have conspired to make sure the first block is mined on this day."
"I thought you'd like it," (2) said. "It gives us the real-world timestamp you wanted, plus has a dig at the incumbents who've proven they should have absolutely nothing to do with monetary supply command and control."
"Exactly," I said. "In fact, if we'd started on the 1st January like I wanted and just used some plain non-relevant text for the timestamp, then I would've asked you to stop and mine the first block again with todays headline."
"Great," (2) said. "I'll continue getting the others to get the client working properly and hopefully we'll have it functional in a few days."
"Fine," I said. "There is one concern I have, though."
"What's that ?" (2) asked.
"This paper is in the UK," I said. "And it's dated as the 3rd January, 2009. My timezone is the 4th January, 2009. You keep referring this headline as today. Are you physically in the UK at the moment ?"
"Let's just say I'm on a working holiday," (2) said. "I'm visiting family over here while working on the client."
"Seriously ?" I said. "You're on holiday and working on this thing ? It's going to take the others some time to fix the bugs so go have a break and relax for a few days. You shouldn't've been working on this if holidaying with your family. They come first."
"I'll send you over the current source-code," (2) said. "If you have time and are able, would you mind having a look over it and see if there's something obvious we're missing here ?"
I told him I'd take a look when able.
"I've checked the calculation for the bitcoin release rate," I said. "Why is there only going to be 21 million bitcoin released ?"
"You told me to half all the calculations, right ?" (2) replied. "So I did. 50 is half of 100."
"But it's supposed to release 42 million coin into the system over time, remember ?" I said. "If I'm looking at this correctly it'll only ever release 21 million."
"Yeah", (2) said. "But it hits the year 2140 like we wanted and the coin-base halves every four years. Just like you said. I talked this over with the others and they came to the conclusion that 21 million bitcoin with eight decimal places would mean that Bitcoin would be able to replace the M1 figure."
"The what ?" I asked.
"It's the total money supply in circulation globally", (2) said. "M1, M2 and M3 stands for the total amount of certain types of currency and accounts. M2 and onwards are for debt-based currencies and M1 was pretty close to 21 million."
"Who cares about the current global money supply ?" I said. "By the time Bitcoin starts being used by every-day folks the total money supply would've changed quite a lot. We're supposed to be replacing the current system with a better alternative. Not just swapping fiat for bitcoin."
"Well, the others agreed the M1 amount was closest to 21 million," (2) said. "and that's what the calculation gives us."
"It has to be changed back to its original value," I said. "If I'm calculating this right, we just need to set the initial block reward back to 100 bitcoin again so that 21 million is released into the system within the first four years, 10.5 million within the next four year and so on until around the year 2140."
"But it won't hit the target year of 2140 like we wanted," (2) said.
"That doesn't [redacted] matter," I said. "That year was just to be used as a guide to release the 42 million coin. The total release amount is the only thing that's supposed to be set in stone. Everything else can be changed to whatever we want."
"Well, I can't change it now," (2) said. "The others have agreed with me on 21 million and if I change it now they'd get suspicious that someone else is involved in this."
"Then as far as I'm concerned this version of Bitcoin isn't the correct version," I said. "It'll still be useful to have it out there in the world so that we can test it and see if our ideas work, but until it's updated and had this and other issues fixed I'll only see it as a broken execution of the implementation design."
A few days later he supplies a link to one of his websites.
"I've posted the first public message regarding Bitcoin outside of the mailing lists and the Satoshi handle," (2) said.
I have a look and notice that it appears he's created an entire fictional character based around the handle he's been using as his email address.
I get a worried feeling that it might not be a made-up handle after all but chose not to pursue the thought further.
He'd pretty much announced the Bitcoin release in this website blog after stating his original attempt was a failure.
From Cracked, inSecure and Generally Broken
"Well.. e-gold is down the toilet. Good idea, but again centralised authority. The Beta of Bitcoin is live tomorrow. This is decentralized... We try until it works. Some good coders on this. The paper rocks"
"Are you [redacted] kidding me ?" I said. "You'd better take that down or remove to post."
"Why ?" (2) asked. "I want the world to know what we've accomplished. It's possibly the greatest thing to be built since the founding of the internet itself."
"But there's some really great concerns here," I said. "We really don't know how governments and banks are going to react to Bitcoin and we have to protect ourselves. Once it really takes off there will be many folks hunting for us and looking for the very first Bitcoin posts. You'll be targeted. Your hosting service will be subpoenaed and IP addresses handed over."
"I use TOR for everything online," (2) said. "They won't find me."
"So the character you're using on this site isn't real and cannot be linked directly back to you ?" I ask.
"Character ?" (2) queries.
There was a confusing back-and-forth between us.
In retrospect the emails would've looked amusing.
Him from the perspective that it was his real name and blog site.
Me from the perspective that it was a made up handle and fake actor blog site.
In the end he reluctantly agreed to remove the announcement about Bitcoin and replaced it with a snarky reply to whoever in the future was hunting to us "Bitcoin - AKA bloody nosey you be...."
I told him to leave the word Bitcoin out completely but he refused.
He found the idea of leaving a message to someone in the future highly amusing.
After a few days of badgering him he removed the post from the front page - at least ... while I was still checking on it.
We still had many other issues with the code-base and began going through them one-by-one.
I told (2) to go through the various hacking IRC channels and forums to ask folks to try out the client software and to see if any of them can break it.
"Why do we want hackers to test the software ?" (2) said. "What do they know about cryptography ? We want people who know crypto and can check if it's correct, don't we ?"
"We need this software to be the most unbreakable software that's ever existed," I said. "That means getting hackers to try cracking it open and finding the flaws in the current design. Some will try fixing it while their peers will try breaking it. Their egos will make them attack, stretch, snap, and repair the thing just to make sure they can prove themselves superior to the others."
"But they're not cryptographers," (2) said.
"You may be surprised," I said.
Every few weeks (2) would come back to me asking me to run the node software on my computer.
"Why do you need my machine running ?" I asked. "Aren'y you busy trying to expand the network ? Where are all the others ?"
"I'm only being able to get one or two to run the software at a time," (2) said. "They run it for a few hours or a couple of days or even up to a couple of weeks. But they always turn the software off and go away."
I'd run my desktop computer for a few days before the wife complained too much about the noise of the fans as it ran all through the night.
He was running his machines 24 hours a day and leaned heavily upon (3) to pick up the slack when their were hardly any others in the network.
For the coming weeks and months I would ask (2) where he was posting requests for help running nodes ?
Which forums and IRC channels ?
I wanted to check them out to see if:
- He was actually making requests.
- How he was asking for help.
He always insisted he was trying everywhere.
Starting on the crypto channels, boards and mailing lists.
Then on the computing and gaming forums.
Then on the assembly forums.
He never sent me any link to any of these posts, or which specific mailing list, IRC channel or message-board he said he was posting to.
I searched and searched many of these locations and never found a single post by anyone asking folks to help test some peer-to-peer software.
51 Percent Attack
"Hal reckons he's found a fatal flaw in the system," (2) said.
"Oh really ?" I asked. "And what would that be ?"
"If a miner has over 51% of the hashing power," (2) said. "Then they can [redacted] around with the network and stop transactions getting embedded into a block."
"That's highly unlikely," I said.
"I know it's unlikely," (2) said. "I told Hal that but he really thinks this is the end of Bitcoin. Once someone gets over 51% everything ends."
"No," I said. "I mean it's unlikely they'd be able to stop transactions getting embedded into blocks. You're talking about the longest valid chain, right ?"
"Right," (2) said. "The 51 percenter would be able to generate the longest chain. Over time only the blocks they generate would be in the longest chain. They can knock everyone else's blocks off."
"And continue that frame of thought," I said. "Once every block in the chain is theirs, and they're the only one verifying and validating these blocks, then everyone else will know who they are, what IP addresses they use. Everyone else will just blacklist that miner and that bad actor will end up playing in a sandpit by themselves."
"But that would mean everyone could confirm that those IP addresses are from that same bad actor," (2) said. "That's not going to be possible if they're always switching them dynamically."
"Then we'd cut them off some other way," I said. "Change the proof-of-work data, the acceptable transaction types, etc."
"And they'd just adapt to those changes as well," (2) said. "I think Hal's right. If a miner gains 51% of the hashing rate then we're [redacted]."
"In that case I don't think it would be a problem after all," I said.
"Why not ?" (2) said. "This is the worst scenario that's been discovered yet."
"Well, it all comes down to whose game are you playing," I said. "If someone is able to gain over 50% over the hashing rate then it effectively becomes their game. And they would've earned it. The amount of funds they would've used to obtain that amount of hardware means they've bought ownership from everyone else. But even if that happens it should still work out fine."
"If someone has the funds to buy so much equipment to take over the network, how is that fine ?" (2) asked.
"Because it would still be in their interest to keep the whole system working as it should," I said. "If they keep playing as a good actor then they will reap the rewards from the mining reward and miner's fees. If they choose to be a bad actor and [redacted] around with everyone's transactions then the value of bitcoin will drop to fiat currencies and it will get to the point when the value of the bad actors bitcoin is less than the capital costs of the hardware and the electricity costs to keep that equipment running. If they continue to be a bad actor they will always kill themselves. Every single time. They have absolutely no choice but to play my game my way."
"Even if that's how it all works," (2) said. "Others currently running mining nodes will get freaked out and leave the system. They'll never come back. It's taken me so much effort just to get the low number of people running the client software on a regular basis that I don't want to lose them now. I'll never be able to build the network back up again."
"It's unlikely anyone will ever know if someone has over 50% of the hash rate," I said. "They wouldn't be doing it by using a single static IP address. Their machines would look exactly like everyone else. It could've happened already. Anyone that's concerned can get more of their own hardware mining. Fear of missing out ( FOMO ) will keep folks adding more and more machines for mining bitcoin while its value steadily increases over time"
Martti Malmi used the handle Sirius-M.
He was the second public handle to work on the Bitcoin client code-base.
Early in 2009, (2) came to me saying that someone had contacted him asking him to help out on the project.
"I was about to reply that we're fine," (2) said. "And we don't need outside help at the moment."
"We as in I, right ?" I said. "We don't want folks to realise the Satoshi handle is backed by multiple people."
"Right," (2) said. "Anyway, I thought I'd better pass this by you and get your opinion on this guy."
He sent me a copy of the entire email correspondence where this person was saying he'd been looking for a project exactly like Bitcoin and he wanted to help out in any way.
"Fantastic !" I said. "Tell him he can definitely help on the project."
"What, ?" (2) said. "But we don't need anyone else at the moment. There's enough C++ programmers and cryptographer advisors."
"We need to build a community around Bitcoin," I said. "And the default answer if you're building an Open Source project that will need to scale globally is Yes! It does not matter if there's no current position for a volunteer at the moment. It's more important that, when a person fronts up with time and skills and says they want to help for free, you say Yes! and put them to work."
"What work should we put him onto ?" (2) asked.
"Get him to start helping on the code-base bugs immediately," I said. "Even if they're bugs that others are currently working on."
"But he doesn't have much experience with the code-base and development in general," (2) said.
"What's far more important than a current skillset," I said. "Is the desire and self-incentivisation of someone who is willing to learn that code-base and code it how we want. We need others to see that someone with little knowledge in crypto can be useful and productive in our project. We can use his public profile to encourage others to volunteer to help us out. As Bitcoin scales there will come a time when we can no longer be in charge of its direction. The direction we want it to head in has to be imparted on those who we choose to come after us. If we control the public volunteers then the public will know the pathway."
"What do you mean there'll be a time when we're no longer in charge of Bitcoin ?" (2) asked. "I'm never going to step away from this."
"There will come a day when your body dies," I said. "That's when the culture of the Bitcoin community must be able to endure without us. We have to set in motion right now machinations for the Satoshi handle to be de-commissioned."
(2) went away and talked to the others he had helping us in the background.
"They've decided they don't want Martti's help," (2) said. "They're saying that they're the one's who have helped the most on getting the bugs out of the code and getting it working."
"Did you tell them that this is more about building up a community around Bitcoin ?" I asked.
"Yep," (2) said. "But they're saying that we don't need a community built up and we're fine just as we are, working in the shadows. They don't want some person that has hardly any experience in coding and no knowledge of crypto coming in and making the public think he's far more important to the project than them."
"Tough," I said. "The main purpose of the project from my perspective is not about the digital cash, but about seeing if a form of psychohistoric game theory can control and guide whole populations. For that test to succeed we need to build a public community that's involved in the Bitcoin project and evangelising it."
"But they're really adamant that they don't want external public help," (2) said. "
"We won't be bringing him in," I said. "He won't know about the others you've brought in to help us. We need external, public helpers on this project and Martti is the first guy to come to us. We are not going to turn him away. I'd rather turn those others away."
"You're saying that you'd pick Martti over the guys that actually stopped the client crashing ?" (2) said. "Why are you turning against them ?"
"Remember how the German National Socialist party rose to power in the 1920's and '30's ?" I said."
"When did this conversation have anything to do with Nazi Germany and Hitler ?" (2) asked.
"When they first tried to gain control they used physical violence via remnants of the army," I said. "When that failed Adolph chose a completely different tact and decided on gaining control via the proper election process. He told the current band of military thugs to stand down and to no longer go around causing violent issues for the party. Those that chose to stay with the current order and continue to cause violence everywhere were removed - eliminated."
"You're now saying that the guys who've helped us the most should be eliminated if they don't accept your new public policy ?" (2) said.
"It's not a new public policy," I said. "I told you long ago that we're going to have to build up a community around the project. If every one of those people who're working on the project right now disappeared without a trace - would the project survive ? Would it continue to grow ? There will be a hundred more to replace any of the current few helping us. If they want to leave, then let them. This is not their project. It's meant for the entire human species. Not for their own personal play-thing. It also means that they'll be able to start involving themselves publicly instead of staying hidden."
(2) went away and told the outer Satoshi team members that we're going to allow the Bitcoin project to become more public.
After a few weeks one of them was so [redacted] off that he left.
And so the very first steps to replace the hidden and secretive Bitcoin code developers with public-facing developers had begun.
Scammers And Fanatics
Around the middle of 2009 (2) again asked me to run my computer so that we had another node for his client to connect onto.
"Why don't you get (3) to run his machine ?" I said.
"I have been," (2) said. "But he's getting annoyed having to run his computer all through the night and wanted me to get you to help out."
(2) didn't know that (3) and I had been talking frequently about many things over the past few months.
Pretty much every time there was correspondence between me and (2), I'd send an email off to (3) just in case (2) left something out in what I was asking folks to do or what text is supposed to be posted as an answer to someone's question.
I had to do that because (2) would quite often leave text out or adjust it so that its meaning or emphasis moved.
So I was already expecting this request from (2).
I'd already vented my frustration at (3), who'd calmed me down a wee bit.
This was good because it meant I didn't blast into (2) as much as I was going to.
"What the [redacted] have you been doing ?" I said. "You're supposed have been building up the network over the past few months so that we'd have actual real-world statistics on how nodes will function realtime. What kind of delay is realistic when transactions and blocks of various sizes were transmitted across the planet. What is the optimum number of connected nodes so that data can be propagated most efficiently."
"I've told you before," (2) said. "It's difficult to get anyone to run a node for long. They don't see any real world value in bitcoin but they do see the cost of electricity."
"I told you to get hackers involved in this right from the very start," I said. "My kind of people. Not yours. Hackers, Game programmers. They could include Bitcoin as the in-game currency. And just like on the World-of-Warcraft sites, folks would naturally start exchanging bitcoin into and out of their local fiat currency, thus creating an exchange rate automatically. The entire ecosystem already exists."
"Well, as I told you," (2) said. "I've already tried those computing and hacking sites. They're not interested."
"Really ?" I said. "And which sites would they be, exactly ? You've refused to tell me exactly what you've said and where you've said it to ask for help. And I've searched extensively all over the 'net trying to find any posts which may have come from you. I haven't found any yet."
"You've been trying to check up on me ?" (2) asked. "That's not a nice thing to do to a friend. I have been posting on forums, IRC channels and mailing lists. Just not the normal ones you would've checked out."
"You're saying that you've requested help," I said ."But not in the main locations that most of the folks in the industry would be. Just what mysterious sites have you been going to ?"
"That's none of your business," (2) said.
(2) had apparently run out of legitimate places to ask folks to help test the node software.
He began posting on other sites and IRC channels which attracted those folks who were interested in multi-level-marketing, scams and Ponzi schemes.
The types of folks who wanted to get rich quick.
He was able to get a lot more nibbles from this crowd and we were now getting more nodes up continuously.
This is when we began to see the fanatical behaviour of folks running their equipment into the ground.
Over-clocking their CPUs, burning out the chips within a month or two and having to replace them, sending us abuse that our client software was costing them more in hardware than in electricity.
I told (2) that there had to be a throttle in the client code so that miners could choose how much CPU power to be sent towards hashing.
I estimated that the optimum mining percent would be around 20%-25%.
This would allow folks to use their everyday computer without the performance being adversely affected.
This is also the power that 3D screen-savers used ( i.e. the aquarium screensaver ) which was one of the goals for the software - incorporate it into major screen-savers of the day so that every computer can be mining while the machine wasn't in active use.
A rate of 20%-25% would mean the hardware will reach End-Of-Life being the software destroyed it.
"It doesn't matter if we add in performance controls into the client or not now," (2) said. "These people are already purposefully over-clocking their computers just so they have an edge over the others. Your Incentivisation system appears to be working as intended. They're now actively trying to out-do each other."
"But what about the complaints about their machines burning out ?" I said. "How should we go about getting them to be a bit more sensible ?"
"Isn't this exactly what you intended ?" (2) said. "Either the exchange value between bitcoin and their local currency rises to allow them to replace the hardware they're burning out, or they perish and those that mine at 25% will be the ones who are still around in the years to come."
"Sure," I said. "But you've said that we've got hardly any nodes running on a continuous basis. We cannot afford to have the few fanatics run out of funds within a few short months."
"You misunderstand these people," (2) said. "These are my kind of people. I guarantee you that to save face and to replace their spent funds they will get as many of their friends and family involved as they can. Even if the others they bring in only last a few weeks it'll be enough for them to recoup their running costs. The multi-level-marketers ( MLM ) know how to influence people and have the greed of a get-rich-quick ( GRQ )scheme to bring them in. The more people that use bitcoin, the more it's worth."
Some of these new folks were absolute fanatics when it comes to MLM and GRQ.
It was the reason they were still in the game after many years.
Those who weren't fanatics burnt out within a year or two.
(2) was able to being folks in who had many years, some even a decade or more, of experience.
The sourceforge message-board was inundated with these people.
The forums ended up being divided between the tech side and the GRQ/ speculation/mining.
Almost a ten-to-one ratio of posts.
It actually looked like any other MLM or GRQ site.
It didn't look like our Bitcoin site at all any longer.
I told (2) about my concerns.
"The message-board has gone to [redacted]," I said. "But if this is the boost we need to expand the network then so be it. We still need it much larger so that we can gather real-world information on how the data transverses nodes across the planet."
"Exactly !" (2) said. "I knew you'd come around and see it my way."
On the source-forge message-board all three of us had access to the Satoshi handle.
This had caused quite a problem as we often didn't read what the others had written and over time Satoshi would contradict what Satoshi had written just two weeks previously.
That's why we'd decided to create a new message-board and have the contradictory posts from source-forge disappear from the 'net.
In late 2009 (2), (3) and I had a huge discussion over the problem of these posts.
Some of the members of the message-board had begun to make posts which quoted various Satoshi messages which were stating opinions at odds with one another.
Most of those posts were between me and (2).
(2) would notice a question and didn't wanactt to wait until I was available to answer it - so he'd give an answer with which I was opposed.
Some of the members were starting to ask whether Satoshi was a single person or a group, as the posts were making it pretty obvious different people were posting under the same Satoshi handle.
The vocabulary was different, the grammar was different, the opinion and stance on a particular topic was different.
It was clear that Satoshi was having an identity crisis.
I wanted Bitcoin to go in one direction.
(2) wanted Bitcoin to go in another direction.
(3) just wanted to keep us together, going in the same direction.
"What are we going to do ?" (2) asked. "Everyone's suspicious of us now and they're pretty sure there's multiple people behind the Satoshi handle. We're [redacted]. All our effort of being able to hide behind a single character has gone."
"We're not [redacted] yet," I said. "We're going to have to create a new message-board. We're going to have this source-forge board fade away and disappear."
"How's that going to solve anything?" (2) said. "Everyone who's currently on the board is seeing all these posts questioning who Satoshi really is. They're analyzing every single post we've ever made and comparing the differences and posting times."
"We start a new board," I said." Folks memories a very poor. Over time they will forget the specific details of why they believe Satoshi is a group and not a single individual. They will only remember the hints that it may be so. There will no-longer be an proof once we move onto the new message-board."
"But those people right now are pretty convinced Satoshi is a group," (2) said. "Mainly because we kept posting opposite opinions on topics. What's stopping some of these people from making an archive copy of the source-forge message-board right now ? In the future they'd be able to show these contradictory Satoshi posts and Satoshi will no-longer be followed or accepted as an authority figure for giving guidance where Bitcoin should go."
"It's very unlikely anyone will save a copy of the source-forge message-board," I said. "They have no reason to. However, even if they do save a copy and later on post sections of it online, it is an easy thing to make folks believe it's faked text and damage the reputation of the poster. Remember: The current folks who are members of the Bitcoin community will end up being the minority in the future with the influx of new blood. The new folks will see Bitcoin as a way to transact and invest funds. They won't be like the current crop of members who see Bitcoin as an uber tech project and a hippy anti-establishment system."
"But what if they save an archive of the entire site ?" (2) asked. "Something that's not just a bit of text that can be changed. People would know that someone would've been able to fake an entire years worth of messages."
"If someone ends up doing that," I said. "And posts links to it on the 'net, then I'll come up with a solution to handle it. There's absolutely no point in worrying about something that has an extremely small chance of happening."
I was initially going to roll-my-own and code up a message-board database and front-end structure from scratch.
Due to the time it would've taken to do that we begin to look at the current state of message-board software.
We worked through which software we'd use and where we'd host it.
It was decided that I was going to administrate the message-board.
(2) mentioned that Marrti ( Sirius-m ) wanted to help out and that he'd mucked about with websites and message-boards before.
I convinced (2) to push all the message-board set-up stuff onto Marrti and to keep me out of it.
I laid it on really thick as to why Marrti would be a better choice than me.
Things like: To build up a community we need to get others involved as much as possible. This guy's keen to help and if we don't give him something to do he might leave, etc.
The real reason I wanted Marrti to look after the message-board rather than me was so I could keep myself protected in the background.
If I only ever exist through (2) and (3) then it'd be very difficult to be compromised.
So far the only compromised position I'd placed myself in was the purchasing of the bitcoin.org domain name from anonymousspeech.com .
On the new message-board we decided to only have one of us make the actual posts.
That person would be (3).
He was the only really sane, calm and collected one between us all.
He was the only one who could get both arguments between me and (2) and make us agree to a compromise.
The only adult in the room.
And so (3) would make our posts on the new message-board, (2) would retain the vistomail email account and I'd retain the gmx email account.
All posts would still come through me and (2) so that the content would be correct.
On the 17th December 2009 the new message-board went live when version 0.2 was released.
Bitcoin 0.2 released
For this new message-board I wanted to start purposefully guiding and building the community.
We'd use multiple handles which each had their own character backgrounds to play a role on the board.
I wanted to have a few controlled threads so that we can manipulate the community in a particular direction.
This had to be as inclusive a community as possible.
During my time as a moderator on the Win32 Assembly message-board I came to realise that for every 10,000 members:
- Only about 1,000 visited the board every month
- About 100 were posting across the various threads
- Around a couple dozen were actively producing ideas and code and helping others out.
It is that couple dozen per 10,000 who push the community forward.
They're the ones in our society who help guide the direction of the human species into the future.
And whenever those few dozen per 10,000 are put down, suppressed, thrown out, jailed, ostracised, then that community and civilisation diminishes and ends.
The difficulty is in finding who these dozen/10k are.
On the Win32 Asm board they came from absolutely every corner of the Earth.
Rich or poor, urban or rural, educated, self-educated - from everywhere.
And that means any community needs to be completely open and accepting of everyone.
We do not know where these gems of humanity will come from.
So on the message-board we were to create a few threads every now-and-then to make the community understand what is acceptable and what isn't.
(2) usually had threads beginning with one of his other handles and the very next post he'd come in with a reply by Satoshi.
Most of his threads were along the lines of "Can we do this, can the tech do that, does this mean X and Y ?"
And Satoshi would come in and agree with that handle and supply more details.
This is partially so that community folks knew the kind of direction we wanted Bitcoin to head towards, plus it allowed (2)s other handles to appear more intelligent ( having the direct support of Satoshi ) so that they'd be listened to at a later date.
So (2) usually filled his handles with characters who had Satoshis support.
I decided to have both newbie and smart characters so that they could play off against one-another.
I wanted there to be threads asking questions that a newbie would want to be answered but they would be afraid to post.
And so I'd make a post under a newbie character handle and have the smart handle reply with the answer.
This allowed the real newbies to see that the members who are knowledgeable in Bitcoin aren't going to bite their heads off for asking newbie-type questions.
It allowed them to not be afraid being surrounded by these uber-elite crypto-maniacs and for them to post their questions without a concern.
Any posts which put down others were either deleted or frozen and the posters messaged reminding them how they're supoosed to behave.
One of my handles was I-am-not-anonymous
I'd begun that handle as a newbie and going through the motions of someone trying to install the Bitcoin client for the very first time.
The types of warnings that pop up would scare most newbies away.
I-am-not-anonymous early posts
I even used it to weigh into the Bitcoin symbol debate.
The current symbol and logo was bc on a circle of gold.
Folks had been suggesting all kinds of nonsense and I didn't want a fractured network filled with different symbols.
We definitely needed an improved symbol and logo however everyone was going about it the wrong way.
Bitcoin Symbol and Logo
The first Bitcoin B symbol - released 24th February 2010 - was originally created in Paint Shop Pro 7 over the course of a chat between me, (2) and (3).
(2), (3) and I were chatting back and forth about improving the Bitcoin project logo and symbol.
I said, "The glyphs used in the TrueType-Fonts were usually created using certain angles, lengths, radii and sizes so that each character can remain similar to one another. Huge globally-recognised companies have logos made that conform to a set of instructions that allow the logo to be duplicated by anyone. This allows them to use the identical logo on many different media - from television advertisements, to websites, to print magazines, to t-shirts, to vinyl stickers on vehicles. We need our symbol and logo to be made in a similar fashion."
"How the [redacted] do we do that ?" (2) said. "Making a logo as a set of instructions ? I don't know the first thing about doing that."
I told him I'd give it a go.
The idea was to make a symbol that could be accurately duplicated by others by using concise sizes and ratios.
It would then be possible for folks to recreate the same symbol and use it as a logo and a currency symbol on any type of media they wanted.
I powered up Paint Shop Pro 7 and begun.
It took quite a bit of effort to make the whole design work together.
There were many mis-steps and deletions and restarts.
(2) used the instructions and created the B symbol that's on the Bitcoin logo released February 2010.
He'd played around with the instructions a wee bit and ended up making the angled cut on the lower horizontal bar half the size it was supposed to be.
The vertical bars were also mis-aligned, however I'm unsure whether that was due to an error in the instructions or (2) just stuffing about.
Those hole shapes were made from a rectangle on the left, a smaller circle to the right of it and the upper curve made by using a circle the size of the B shape that curved between the top of the rectangle down to the top of the smaller circle.
The large circle was then cropped and the rectangle/circle/cropped-large-circle was cut horizontally to make up the upper portion of the hole.
It was then duplicated, mirrored vertically ( along the horizontal plane ) and combined with the upper hole shape.
These were then used to create the top hole shape and the right-hand-side B bumps.
Due to the instructions for the hole shapes not being as specific and exact as we wanted, those original instructions were never released.
I've recreated them from memory and may post them at some stage, however the updated version was more important.
A slashdot article on Bitcoin on 11th July 2010 suddenly makes thousands of folks aware of us.
Bitcoin project stats July 2010
Ever since the initial solution was discovered to the double-spending problem we'd discussed ideas for an anonymous marketplace.
(2) was focused on using Bitcoin for online gambling and I was focused on the marketplace.
Over the past two years the topic of the marketplace would rise again and the main topic was on the ethics and moral backbone of such a service.
I'll include the types of discussions we had in this story timeline here, however some of these discussions took place even before the genesis block was formed.
"How's the marketplace idea going ?" (2) asked.
"The general layout for folks to add items and to make bids and purchases is all straight forward," I said. "It still needs to be coded up, but that's not much of an issue."
"So when's it going to be ready ?" (2) asked. "You said you were going to have it ready with the first client release. You've been working on this on-and-off for ages now. Is it ever going to be ready ?"
"The problem I'm having is in trying to figure out how to control the type of items allowed on the service," I said.
"What do you mean 'allowed' ?" (2) asked. "This is supposed to be an anonymous marketplace, right ? That means anyone can sell and buy anything."
"That's the dilemma," I said. "There are some things that shouldn't be allowed."
"Like [redacted] there's anything that can't be allowed," (2) said. "I'm not going to go through all this effort to create an electronic currency that no-one can control and stop and then have a marketplace where they're restricted in what they can do. It goes against the philosophy of the CypherPunk's Manifesto . The default stance is everyone has a right to absolute privacy."
"Don't you go throwing the manifesto back at me," I said. "I'm the one who's had to continually remind you about it over the years, remember ?"
"Well it still stands," (2) said. "Privacy of the users comes first. This means we cannot choose what they can or can't post onto the marketplace."
"Look," I said. "The main purpose of the marketplace is to be another piece of the puzzle towards a planetary civilisation. It's supposed to be a place where folks from around the world can come together to barter and swap items. Many will use Bitcoin for the funds transfer. Over time the type of planetary civilisation we want - the moral code and ethical behaviours that will be inherent in the civilisation - will form naturally."
"That's right," (2) said. "And that means it must be totally open and not subject to any controls."
"Not at all," I said. "The folks forming the new planetary civilisation are the ones who decide upon the moral code and ethical behaviours that are acceptable. They also equally decide on what is definitely not acceptable. This implies that I need a mechanism for the majority to dictate to the minority what is acceptable."
"I don't think this democracy way of thinking works at all," (2) said. "We shouldn't have anyone telling anyone else what they should post on the marketplace. It should be a natural free-for-all."
"How do you think Bitcoin works ?" I asked. "It is a democratic system. The majority comes to a consensus and the minorities either get on board with the same consensus or they're booted out of the system. Actually, they effectively boot themselves out. I need to use the same mechanism with the marketplace. Have nodes that can gain fees by running the proof-of-work hashing algorithm to make the marketplace have its own consensus. If folks want to change the type of items allowed in the marketplace then the majority of hashing power must also be in agreeance."
"What ?!" (2) said. "You want miners to be keeping the marketplace together ? Are you crazy ? No-ones going to use a marketplace that's so inefficient. They just want to post items on the market and have people bid for them. They're not going to run the marketplace client software 24 hours a days to secure its consensus rules like Bitcoin. That's why it's going to use Bitcoin in the first place, right ? Bitcoin has the secure consensus rules locked in by miners. Not a marketplace."
"Not at all," I said. "I've told you many times before that Bitcoin is only the first proof-of-concept experiment to see if a group consensus can be formed automatically without a single authoritarian overseer. I'm now trying to implement the same thing into a marketplace service. If I can do that then many other services would be able to be implemented using the same system. We will be able to decentralise everything."
"You've been trying to figure out how to do this for two years now," (2) said. "If you haven't come up with a solution by now then maybe it's just not possible and we have to go with a totally open anonymous marketplace where anyone can sell and buy anything without aving others decide what thye can do."
"There are some really sick folks out there in the world," I said. "I'm not going to build a platform that caters to them."
"Maybe it's not up to us to decide who's unwelcome and who is ?" (2) said.
"Tell you what," I said. "If we include into a Bitcoin transaction the original idea of the GPS coordinates of the sender then it might work after all. A completely open anonymous marketplace would become a honeypot for all the Societal Undesirables of the world. After six months of collecting GPS coordinate data on their locations we'd be able to send that data to whichever local law enforcement agency that cooresponds to that location upon the planet. We'd be able to help clean up all the Societal Undesirables in one hit, leaving the anonymous marketplace and Bitcoin full of Societal Desirable folks and all the rotten scum will be left within the old fiat currency and governmental authoritarian systems."
"Are you [redacted] kidding me ?" (2) said. "You're suggesting using Bitcoin and an anonymous marketplace to target our users ? Who makes you the one to decide who's a Societal Undesirables person or not ? I've struggled for years to build up a netowrk of users and nodes for Bitcoin. If word got out that we were collecting their GPS coordinates and sending a selection of them to law enforcement officers the project will be killed and no-one will ever trust to use it again."
"The point here is that it's the community itself that decides what is acceptable or not," I said. "Not me. Not you. The community coming to a consensus. The problem is that we need a voting system similar to Reddit where folks can up and down vote items to decide what's going to be allowed. But the typical voting systems on YouTube and Reddit can easily be Sybil-attacked. That means hash mining where the miners are the ones who vote on items. Instead of a Merkel tree of transactions in a block there'll be a Merkel tree of new marketplace items to be sold. Only the items that particular miner accepts will be written into the ledger. To add GPS coordinates into this I have to find a way a miner can confirm the GPS location before accepting the item. Kind of like how some sites make you confirm your email address before completing a sign-up process."
"And how do you do that ?" (2) asked.
"I still haven'y figured that out yet," I said. "I haven't been working on this too much. Only when you remind me I look into it again."
"Well, I'm not adding GPS coordinates into the Bitcoin transactions," (2) said. "You can add that inside a higher layer on top of Bitcoin if you want, but I'm keeping the Bitcoin protocol as it currently is."
"You said if I ever figured out how to include GPS coordinates without relying on a third party that you'll add the data into the Bitcoin transactions," i said. "Are you reneging on that ?"
"You still haven't figured out how to do it without a third party," (2) said. "And now that you've told me your plan to send the locations of Societal Undesirables to the police I definitely don't want that data inside any transactions."
"Well, maybe it's time to stress test the Bitcoin system a wee bit," I said. "I can make a copy of the Bitcoin source-code and add in the additional data myself. Including the coordinates for the planetary scale geodesic sphere and the transaction taxes which will be locked into those corrdinates across the planet."
"You can't do that," (2) said. "There can only be one code base for Bitcoin. We can't have two or more versions of the Bitcoin protocol."
"The system is designed so that it expects anyone and everyone to create their own version of the Bitcoin protocol," I said. "And the protocol that succeeds is the one where all of the various versions come to a consensus on parts of it and not a consensus on other parts. It's like the IFF ( Interchange File Format ) that the chain of data chunks - the blockchain - is based upon. Programs that understood certain chunks would accept them and ignore the chunks that they didn't undertstand. The Bitcoin protocol is supposed to allow transactions of unknown types to be embeded into a block even if other client software cannot read it. The hashed proof-of-work confirms it is valid data to someone."
"You're not going to create a competing version of Bitcoin," (2) said. "I won't allow it."
"You're not going to allow it ?" I said. "You still seem to misunderstand the entire technology here. The folks who use the system itself are the ones who decide what is Bitcoin and what isn't. Not you."
"The Satoshi handle still pulls a lot of weight in the community," (2) said. "I'll tell them all to ignore you. That you're an active hostile actor who's attacking the Bitcoin network. You won't get anyone to run your version of the Bitcoin protocol."
"The original implementation of the transactions," I said. "Was to include a UUID ( Universal Unique IDentifier ) so that anyone can create any type of transaction they want. You purposefully left that out. All I'm suggesting is that we make the Bitcoin transaction structure more like we'd originally worked out."
I was more than a little annoyed at this stage.
It was around this time someone called Gavin joined the community ( late May 2010 ) and began mucking about with the Bitcoin source-code.
He'd been reading up on some of the historic info on Bitcoin and had started asking questioning on the message-board.
By an odd coincidence he asked a question directly related to the argument I was currently having with (2).
Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
(2) took this opportunity to make sure everyone would avoid me if I began creating a version of the code-base with an adjusted transaction structure.
June 17th, 2010: "I don't believe a second, compatible implementation of Bitcoin will ever be a good idea," (2) said. "If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version," (2) said.
"Why the [redacted] did you say that?" I asked.
"I told you I'm not going to allow you to fork the code and change what I've built," (2) said.
"And what's with telling them that you've been working on this since 2007 ?" I asked. "You know that's not true. You started your project full-time back in 2007, and had been working on it part-time for half a decade before that, but that project was stopped late May 2008 when it was obvious it could not continue in its current form. This thing is my project, not yours."
"We agreed to give the Satoshi character a background which included what I'd worked on previously, remember ?" (2) said. "Not once have I ever said that I personally invented this technology. It's from Satoshi's background only."
"Well, I don't like it being mentioned," I said.
"If it's an issue of acknowledgement then I can fix that right now," (2) said. "I'll post right now on the message-board that that you're the real genius behind the Bitcoin tech and that you're the real inventor."
"You'd do that for me ?" I asked.
"Sure," (2) said. "I have never told anyone in private that I'm personally the inventor. I've been the main one coordinating the development of the source-code for a working client. You can't take that away from me. But I will always aknowledge you as the inventor. Do you want me to make the post now ?"
"Definitely not," I said. "We're still playing this game from the shadows and it's still too dangerous for any of us to be known publicly. Remember: Once it's safe enough to come out of the dark we're going to be changing the white-paper and replace Satoshi Nakamoto with our names again, just like in the first draft."
"Not right now, then," (2) said. "Ok. But whenever you want, you let me know and I'll make the post under the Satoshi handle."
"And you better keep your word," I said. "It might be a couple of years or more before it's safe for us to come out publicly."
"Please don't be mad at me for having to say those things about forking the code-base," (2) said. "The system is just too fragile to have you muck about with it at the moment. In a few months when we have hundreds more nodes and a lot more developers helping with the code then you can start talking to them about your adjustments."
"Maybe," I said. "We'll see."
"In any case," (2) said. "Aren't you supposed to be focusing on the anonymous marketplace ? You keep dropping it but that was always your thing. The poker stuff was mine and the marketplace was yours, remember ? Try and see if you can get it to work on top of Bitcoin instead of changing the transaction structure."
25 July 2010 Wikileaks Afghan War Logs release.
"You've been telling me to add the other stuff later since late 2008," I said. "I don't think your ever going to let me add in the geodesic sphere data and GPS coordinate code."
I was really quite annoyed at (2) by now.
The whole purpose of the technology was not only for an electronic cash system.
The electronic cash system was only ever a test-case to trial the real technological break-through in the real world.
It was also the most important test, as I was going to need a form of currency for stage 2.
The main technological break-through was the psychohistoric game theory and how a culture could be formed independant of any authority or third-party over-seer.
To be able to create an environment where everyone is free to join or leave at any time and be productive in their own way.
I might be able to figure out a way to add these other services on top of the Bitcoin network, however I still wanted pieces of it to be embedded inside.
Currently I was working on many other types of projects outside of Bitcoin and didn't have the time required to spend designing such services.
There was a website which was effectively a marketing portal to sell products I was designing to allow sellers to use affiliates and multi-level-marketing to help move their items.
They would spend the same amount as a marketing budget however, instead of the funds just going towards displaying banners on folks sites, they'd be able to get others to physically go to prospects to push their items ( similar to merchandisers going to distributors to store their manufacturer's products )
Most of the complaints I've had since the beginning of the year had fallen on deaf ears.
It'd got to the stage that, for every email or message sequence behind me and (2), I'd also email (3) to make sure he was up-to-date and aware of what was or what wasn't happening.
(3) could clearly see a dis-connected happening between what I wanted to happen in the project and the direction (2) was taking it in.
I began looking at the others who were publicly helping out in the project to decide how to push the project to be guided by more public figures.
I decided to stop helping (2) and (3).
They'd effectively taken over the project and stopped making the adjustments I'd suggested over the past year.
Whenever (2) would send me an email from someone or pointed me towards a posted on the message-board so I could help formulate a reply I'd say I was too busy at the moment and to get the others in the outer Satoshi team to help him.
This happened again and again until (2) begun to realise that I wasn't giving them any help at all.
"I really need you to help me with this stuff," (2) said. "If you're not going to help me then I'm going to need to find someone who will."
It was clearly a bluff, but I'm not the type of person to accept bluffs.
I see all possible futures in the present tense.
Whatever is being bluffed is one possible future and I will act as if that future has already happened.
And so I acted as if the future where someone else is helping (2) with the project already exists.
"I've moved onto other things," I said. "I won't have time to help you on the Bitcoin project any longer."
"What does that mean ?" (2) asked.
"That means that it's time to start having publicly-known folks to become the ones maintaining the project," I said. "Take a look at the folks who are most active on the message-board and have been sending in helpful suggestions and code changes. We'll pick one to be your second."
"I don't want one of them to be my second on this project," (2) said. "It's progressing well enough and getting more traction now."
"If tomorrow you get hit by a bus then the project halts immediately," I said. "We need outside blood for this project to continue on into the future without us."
(2) came back with a list of the most active current members, including Sirius-m (Martti), Mike Hearn, Jeff, Gavin, and a few others.
There were about half-a-dozen names on the list.
"I think you should approach Gavin," I said.
"Why Gavin ?" (2) asked. "He's been involved the least amount of time compared to the others. I was thinking Marrti as he was the first to publicly join us."
"Gavin is the best choice," I said. "He has a background of being involved in Open Source projects. Most of those others aren't interested in having the project open. Some have even suggested in closing the source-code to the public and being more selective to who can see the current state of the code. We need this project to remain Open Source for it to survive and thrive. Gavin will keep it Open Source above all others."
I had another reason for choosing Gavin.
In his previous projects he was involved in programming within the 3D realm.
VRML - Virtual Reality Markup Language.
As the creation of the Bitcoin technology had relied heavily upon concepts from 3D graphical programming, I imagined that Gavin had a mind which would be able to understand the tech far better than those who'd only been involved in crypto or straight computer technology.
Those others would only ever see a crypto project or a computer science project or a mathematical problem solving project and they would treat it as such.
(2) approached Gavin and asked him to help out more directly.
Marrti was pretty stroppy about the idea, however he came around to understood our reasons.
With Gavin helping (2) out more and more, I had effectively stopped my involvement in the project with (2).
I'd still receive the occasional email on the gmx address and answer them or pass on their details to (2).
I just wasn't reading every single post on the message-board any more and let (2) come up with any answers wit the help of only the outer Satoshi team members.
Late August 2010 Sweden issues arrest warrant against Julian Assange.
Bitcoin Symbol and Logo #2
Around mid-October 2010 I saw an opportunity to remake the Bitcoin symbol and logo again and improve upon the design.
It was approaching the 2nd anniversary of the release of the Bitcoin white paper.
I'd decided to stop helping (2) because he'd effectively stopped listening to me and chose to create a new symbol and logo instruction set as a departing gesture.
Embedding the number 42 a couple of times into it was another type of departing gesture.
I wanted the new instructions to be better than what I'd produced back in February 2010.
I spent quite a bit of time on the symbolism for the various pieces of the Bitcoin symbol and logo.
The symbol being the Bitcoin B and the logo being the symbol on a 13.88° angle enclosed within an orange circle.
The main issue was the shaping of the B holes and the rounded right-hand-side curves.
All of the pieces for the symbol and logo had to be scaled relative to each other piece.
I created and recreated different ways to make the hole shapes until it looked pretty nice.
However, the creation of the hole shapes now needed for many ovals to be generated and it was quite laborious to make them.
I couldn't find a quick-and-dirty method to create the hole shape that still looked nice or had the numbers ( the scaling percentages ) appear connected.
This meant that it took about a quarter of an hour to create the initial hole shape if you use the mouse cursor to click on every scaling menu item or tool button.
Once the keyboard shortcuts and button defaults were figured out I was able to get the hole shape generation down to about a minute
22 October 2010 Wikileaks release Iraq war logs.
I had bitboy go through the instructions until they were written clear enough for him to recreate it.
It took him about half an hour just to create the initial hole shape and if just one step was missed the entire thing would have to be created again from scratch.
He said he'd spent about an hour and a half just to get it drawn as close as he could, but even then he found the shapes weren't aligning to each other correctly.
His software was snapping the shapes to the grid which he had to turn off.
Then all values were being rounded down so that any scaled shapes ( which were most of them ) were not able to align correctly with each other.
He kept having to manually adjust each edge of each shape so that they touched one another.
And he recreated the logo again and again trying to get the thing drawn to the instructions as close as possible.
He apologised for the errors in his versions because his drawing program kept snapping to grid or snapping to pixels so the actual sizes of some items were incorrect.
He'd also played around with the rounded shape to try and make it better and ended up distorting it a bit too much.
He said it took him so long to go through the instructions that he really didn't want to go through them again to fix the stuff-up and asked if he could just post my own version.
I told him that the idea was for the community to see that someone new to the community could be productive and do something very useful even if they weren't experts in the tech.
He was to post his version, even with the errors present.
I told him that most folks would never see the mistakes because the whole thing is going to be rotated onto a specific angle.
The updated instructions for the November 1st 2010 symbol/ logo were never released publicly because the instructions for generating the hole shape were just too harrowing for bitboy.
If he found it difficult, then many others would find them likewise.
They weren't the easy-to-follow instructions I had wanted after all, so I thought I'd leave it until I can figure out a better way of creating the holes.
Due to circumstances, I never had a chance to get back to the symbol/ logo again.
The instructions were obliterated around mid 2011 along with every other piece of Bitcoin-related data and information so only bitboy should have a copy of those original instructions now.
Here's a link to a reproduction of the original instructions for the Bitcoin Symbol and Logo.
I think the accuracy of those instructions are around the high 90's percentile.
22 October 2010 Wikileaks release Iraq war logs.
1st November 2010 New Bitcoin symbol and logo released by bitboy.
In the middle of November 2010 (2) came to me with an unusual request.
(2) asked, "I was just wondering if it'd be possible for you to hold a large and important file for me for a few months".
"What file ?" I asked.
"The wallet file for the coin I've mined over the past couple of years," (2) replied.
"Why would you want to do that ?" I asked.
"There are a few things that I'm keeping an eye on," (2) said. "And I might need to keep the data away from my possession for a few months."
"It must be something pretty [redacted] serious if you want someone else to hold onto your coin," I said.
"Let's just say that, if what I'm concerned about goes badly for me," (2) said. "Then there's a possibility that my home may be raided and the computers with my coin on them will be removed."
"I don't want any data from you on my computer," I said. "Pass it along to (3) instead."
(2) said, "I trust (3) as much as anyone can trust another with everything else except my wallet data."
"Why wouldn't you trust him with your coin ?" I asked. "(3)'s got a substantial amount of coin himself so you know he'll keep it safe for you."
"He's got a lot of coin for himself," (2) said. "And I trust him completely to keep his own coin safe. But I don't trust him enough to hold onto my coin. I've got far more than he has and he'd have too much temptation if I sent him the file."
"Then send it to Gavin," I said. "You trust him with the Bitcoin project, right ?"
"It can't be Gavin either," (2) said. "I trust him wit the direction he'll take the project absolutely. But the amount of coin would tempt him far more than it would (2). It must be you."
"Why me ?" I asked. "You've been ignoring much of my advice for the project all through the past year. Why would you come and ask me for anything ?"
"Because," (2) said. "You've proven that you're the one person on the entire planet that I can trust absolutely."
"How so ?" I asked.
(2) said, "Even with me either ignoring your requests for adjustments in the code or the direction the system should take, you still kept your mouth shut and never argued in the forums against me."
"We agreed to make sure we kept on the same page for all decisions, remember," I said. "That, even if we said the wrong thing or disagreed with one another, or made a mistake with an idea, we would keep the narrative in agreement so that it keeps the devision down. No matter what direction you've taken the Bitcoin project away from the original intent, the narrative must continue in agreeance else the community will split"
"Exactly," (2) said. "And you've kept to that even with your disagreements against me. At any time you could've posted messages saying what you want to happen and prove that you're the one where all the ideas came from. But you haven't crossed me at all."
"That's because I want to keep myself safe," I said. "To keep myself protected. That's one of the reasons why all my correspondence and communication with others has always gone through you. That still stands and is why I still won't post under my own personal handle in the forums or email anyone with my real email address."
"Exactly," (2) said. "You've proven with your own actions that I can trust you completely."
"Well, I don't want your coin," I said. "Aren't there any others you can use ? What about the folks you got involved in the outer Satoshi team ?"
"All those others are less trustworthy than both (3) and Gavin," (2) said. "So what makes you think I'd trust any of them with my wallet ?"
"Just encrypt it so they can't access any of the keys," I said. "It'd effectively just be a file with random data that they can never use."
"No," (2) said. "It has to be you."
He was being persistent as [redacted].
I finally relented.
"Ok then," I said. "Send the file over and I'll keep it for you for a few months."
"Not right now," (2) said. "I'm just checking if you'll do this for me."
"What ?" I said. "So when do you want me to hold the file for you ?"
"I'm not sure at the moment," (2) said. "It all depends on how this thing I'm keeping an eye on blows up. Probably sometime in the new year."
"Alrighty then," I said. "let me know when you want the transfer to take place."
28 November 2010 Wikileaks begins releasing state department cables.
They'd been more active this pass year and releasing far more leaked data than ever before.
They were irritating the [redacted] out of folks who had access to trillions of dollars worth of violent technology and the assets to deploy to use them.
(2) and I discuss them at length, trying to decide what courses of action we have available to us if they continue down this pathway of using a stick to prod the governments of the world.
He and Sirius-m ( Martti ) had a similar frame of mind:
- [redacted] the governments of the world.
- What can they do to us ?
- We should encourage Wikileaks and Julian to keep poking away.
I kept telling him that any business could easily purchase enough mining power to wreck Bitcoin and the experiment would be snuffed out in an instant.
"This system we've built will withstand such an attack, right ?" (2) said. "You've told me previously that if someone gains more than 51% of the proof-of-work hashing power then we can adjust the consensus rules and fork away from them - leaving them inside their own little playground with their own bat and ball and no one else to play with them."
30 November 2010 grandfather Desmond Meyer died.
He was my closest male role-model and it still hits me deeply.
This was the guy that taught me how to manipulate and kick a football, combine the correct fuel/oil for a lawnmower and mow the lawns to leave them looking nice.
All these little details that no one ever thinks are important which ends up forming a basis of how you go about your day.
He was a co-founder of the Ferrymead Printing Society in Christchurch, New Zealand.
On that website's history page my grandfather is the one on the far right-hand-side in this image
As mentioned here:
- "The Ferrymead Printing Society was founded in 1973 by Des Meyer when land was set aside for a printing works at the planned Ferrymead Historic Park."
Ferrymead is an historic park that has been built like a small village from a hundred plus years ago with many of the shops fully functional.
Working steam and diesel engines, trams, a bakery, a school, blacksmith, etc.
The Print Shop had many printing machines from over the past century and many were maintained in working order.
As a teenager I went with my grandparents once a month and helped out around the shop.
Tourists could come in and purchase Wanted - dead or alive posters and we'd print their names on them.
It was here where I learnt a little bit about how the different colours from inks came together to create coloured images.
There was a large white cardboard poster on the southern wall which included four images with each quadrant coloured in cyan, magenta, yellow or black.
The center had all four images overlapping so that folks could see how they all came together for a coloured image in a magazine or newspaper.
This was the poster in my head when I was deciding upon the orange colour for the new Bitcoin logo.
A CMYK of 0, 50, 100, 0.
A logo for the future my grandfather would've been able to print using technology from a century ago.
The first week of December 2010 I was in Christchurch, New Zealand dealing with my grandfather's funeral.
For three days the tears streamed never ending down my cheeks.
Dropping Into The Shadows
We'd been using multiple handles on the message-board for the past year or so.
There were more new members in the Bitcoin community every day.
And they all wanted to know who the [redacted] this Satoshi character was.
A few members began hunting us in earnest.
"(3) is seriously ill," (2) said. "He fell in his shower and is now in a hospital."
"[redacted]," I said. "Did he slip and hit his head or what ?"
"You do know he's a paraplegic, right ?" (2) said. "How the [redacted] would he be able to slip in a shower ?"
"Oh, right," I said. "Well if he didn't slip then what happened ?"
"All I know is that he fell in the shower and he's now hospitalised," (2) said. "I never knew he was in such a bad shape, health-wise."
"Will he still be able to be online," I said. "And check the Satoshi text for the emails and post the forum messages ?"
"Our friend is in hospital," (2) said. "And all you're thinking about is the spelling and posting of Satoshi's messages ?"
"It's not that," I said. "I hope he gets well soon just like you. It's just that, if he can no-longer check for the spelling and grammar usage and post to the message-board under the Satoshi handle then folks will begin to notice discrepancies in the posts just like they did back in 2009 on the source-forge message-board. Remember how bad that got ? Folks began notice the contradictions between our posts and we ended up having to execute a plan to move onto a new message-board and delete the old source-forge message-board before anyone had the fore-sight to archive all those posts."
"You think, with (3) unable to be as active as before, that it'll go back to how it was back then ?" (2) asked.
"I think it'll be worse than that," I said. "There weren't many in the community back then and we knew that the types of new folks would be different from the early supporters. The early supporters would move on and the community would forget about the early posts. But the rumour that Satoshi is a team and not a single individual came from those posts in 2009. The rumour still persists today. If you decide to post instead and the vocabulary changes and the grammar usage changes then it'll make folks realise that there's more than one person to hunt down. And nowadays there're a lot more hunters in the game."
"It's not as bad as back then," (2) insisted. "We were all using the Satoshi handle on the Source-forge message-board in 2009. That's how posts with contradications appeared in the first place. That's also why we decided to have (3) do the postings on the new message-board only."
"And there are folks who have been checking the times posts have been made," I said. "And they've figured out the timezone Satoshi resides within. (3)'s timezone. If we continue to post on the message-board we're going to have to make sure we still post within his timezone. We're most certainly going to slip up."
"What can we do, then ?" (2) asked.
"We're going to have to drop using the Satoshi handle altogether," I said.
"But how will the direction of the project be guided ?" (2) asked.
"Pass the reins over to Gavin," I said. "Ask him if he'd like to be the lead developer for the project while Satoshi takes a back seat. We can still use our other handles for communicating on the message-board and for posting code changes."
A day or so later (2) comes back to me.
"I've passed the running of the project over to Gavin," (2) said.
"And how did he take it ?" I asked. "Is he Ok with that ?"
"I didn't exactly ask him," (2) said. "I asked him if it was Ok to place his email address under the Satoshi email address on the bitcoin.org website. He said it was fine. I then removed the Satoshi email address."
"What the [redacted] dude !" I said. "You were supposed to ask him. You were never supposed to just dump him in it. What if he doesn't want the burden of being to sole access point for the project ?"
"You think I should've directly asked him ?" (2) asked. "But what if he said No ?"
"If he said No then we'd find someone else, like Mike or Jeff," I said. "Or, preferably, have all three of them run their own forks of the codebase so that we don't have a single point of failure in the project."
"I don't want multiple versions of the code," (2) said. "We went through this before, remember ?"
"That was when you would've been the one trying to keep them all compatible with each other," I said. "With more active members there're now enough folks to look after the code without you."
A week or so later Mike emailed me via my gmx email account tellng me that he was working on a Java SPV ( Simplified Payment Verification ) client and that he was looking at building it into an Android app.
I hadn't really taken notice of what had been happening in the code updates for over half a year and I had to scamble to try and get up-to-date so that my reply made any sense.
It was really quite odd to receive an email via the gmx account.
Even though it was the email on the top of the Bitcoin white-paper and on the website, most folks used the vistomail email because that's what (2) used to communicate with others.
Unless (2) began a conversation using his vistomail email account then hardly anyone contacted us.
Even on the message-board, most folks posted whatever they wanted to talk about, however hardly anyone specifically asked us questions within a thread.
Though there were a few direct-messages on the board, I found it strange that hardly anyone went to the source for direction or information.
This meant most of the time (2) was doing the correspondance and passing the email or message content onto me and (3) and others in the outer Satoshi team.
I gave Mike my initial idea for how SPV would be implemented.
SPV clients would pretty much have to trust a full-node server and poll for specific transactions they're interested in.
That way the SPV client would only ever need to obtain a chain of signed transactions back to the various codebase transactions plus the block headers to confirm the current UTXO ( Unspent Transaction Output ) was correct.
(2) never liked the idea of folks having to trust any node for this to work.
I always argued that folks could trust their own node and run a Family node at home to which all their SPV clients would connect.
Due to the difficulty of creating Fraud Proofs for SPV clients, I explained an updated version where the client would at least verify every block before discarding them and only keeping the block headers and transactions.
I had to check what (3) had been posting on the message-board and look at the current updates in the github repository from the stuff (2) and whoever they still had helping them behind the scenes.
I kept wondering if I was emailing Mike stuff which was obvious and anyone in the community knew and that he'd realise that I wasn't the same Satoshi that was communicating on the message-board or via the vistomail account.
I even wondered if he had emailed (2) via the vistomail email address and would be able to tell that they're definitely very different people.
It was a risk, but what the [redacted].
If my emails caused problems for the others then so be it.
Mike talked a lot about how the Android phones worked, or the functionality that was available.
I began looking into iPhone apps and how a similar SPV client could be built by coding it up based upon Mike's Android project.
It was obvious that these field devices, these phones, had finally got to the stage of actually being useful.
Their ram and storage capabilities had slowly risen over the past few years.
Trying to build an app from scratch would be a huge steep learning curve.
The language syntax was very different to what I'd been used to over the years and learning it would be just as difficult as learning Java and building Android phone apps.
Mike wanted to know how the figure of 21 million coin was worked out.
I decided to give him a hint that the original figure was 42 million so that at least someone outside of the inner Satoshi team knew.
(2) would never admit to anyone that the release-rate calculation was incorrectly changed and executed in code wrong.
As I was playing the Satoshi role in these email exchanegs with Mike I had to still follow the standard back-story we'd created.
So instead of telling Mike the release-rate is wrong I said: "I thought about 100 BTC and 42 million, but 42 million seemed high."
Parity is reached with the US dollar.
One bitcoin equals one US dollar.
A great milestone.
On the 10th February, 2011 a Slashdot article on Bitcoin reaching US parity brings awareness of Bitcoin to thousands more.
At the end of January 2011 Silk Road is up and running and a few private tests ( posted publicly ) are run to confirm it functions as intended.
Mid-Febraury 2011 Silk Road goes live to the public for anyone to sell their own items.
Holding the Bag
(2) emails me saying if I remember a few months ago when he asked if I'd be able to hold is wallet for a few months.
"Sure I do", I said. "But you haven't mentioned anything about it since then so I thought you'd decided against it".
"No", (2) said. "I was just waiting for something to happen. It's now happened and I want you to hold onto this file for me. Only for about two of three months".
"I don't like this", I said. "You know my views on having anyone's data or information on my computer or my information on other's computers. I'll do this only because you need me to hold them. But as soon as your situation has cleared up you need to take them back".
"Exactly what I needed to hear", (2) said.
He sends over an email with an encrypted file that holds a [redacted] tonne of bitcoin.
I check the hash for the file to confirm that the file is correct and uncorrupted.
I copy it to a USB drive and delete/empty trash the email.
On the 22nd February, 2011 there was a massive earthquake in my home town of Christchurch (Chch), New Zealand.
My mother lived in the north-east corner of Chch at the time.
The entire eastern side of the city was wrecked.
No water, sewerage, electricity. The roads were screwed.
I put in an application to my employer to get time off to help her.
Within a week I was in Chch while the massive aftershocks were still ongoing.
I was there from 2nd March 2011 to 22nd March 2011.
We couldn't stay at her place due to no sewerage for the toilets, no electricity for boiling water, no running water at all, so she was staying at my brother's house in western Chch.
Every day we'd travel to her place and I'd spend much of the day digging the liquefaction silt from her driveway and the road.
When driving to her cousin's place who lived in the next suburb over I had to drive her little hatchback along the sidewalk, then across the street to the other sidewalk, along that sidewalk then up through the middle of the road, then to a sidewalk again.
I was treating her poor car like it was a 4WD.
The earthquake and aftershocks had made the asphalt on the roads bubble up a wee bit.
These bubbles were sometimes so large an entire vehicle could plunge into them.
And we never knew if the asphalt we were currently driving over had one of these cavities beneath them.
Luckily my mum's house was on a slight rise.
Her cousin's house was on the flat and the liquefied silt had entered up to a foot inside.
They'd spent the past week digging themselves out and the silted stains were everywhere.
After a week staying at my brother's house my mum and I were kicked out.
He never really understood what the folks in the eastern suburbs were going through as the earthquake damage to properties on the western side of the city were small and mostly cosmetic.
We ended up staying at mum's friend Jeannie in Kiapoi, a small township just to the north of Chch.
Jeannie's house had been immediately red-zoned after the main quake.
That means it had been labeled as unliveable and to be demolished in the near future.
My mum's place wasn't red-zoned.
But at least the electricity and sewerage and water worked in Jeannie's broken house.
I stayed there for the rest of the duration of my time in Chch.
The aftershocks were tremendous.
Over 5.0 on the richter scale and quite shallow ( around 5kms deep )
You soon learn that it's not the magnitude that matters so much but the depth.
Most common quakes are twenty or more kilometres deep and their energy isn't powerful enough to do massive damage up on the surface.
But a shallow 4 quake can do more damage than a deep 6.
The aftershocks came day and night.
We never had even half a nights sleep.
Nerves were frayed and tempers were short most days.
In the morning's we'd work around mum's home to try and fix pieces of it.
Sawing and rasping off an inch from the bottom of a few doors allowed them to close so that, once the water and sewerage was temporarily put on again, we could go to the toilet without giving a show.
In the afternoon we'd head to my brother's house for food.
We'd moved all the old family photos to my brother's house the week before and I began to use a digital camera to photograph them all in case something happened and they were lost.
During the final days I was in Chch we spent most of the time just trying to relax and watch the tv.
Mike Hearn had begun to email me again and I spent some time going over discussions on the message-board and answering his questions about ideas that had yet to be implemented in code.
It felt good to be able to delve back into the project again like this.
(2) had been pretty much ignoring my advice and suggestions for quite some time and I was able to let Mike know what some of the ideas were.
If (2) wouldn't implement my ideas, then perhaps Mike would ?
We'd been following the Liberty Dollar issue from the very beginning.
At least, (2) had been following it ( like he followed pretty much everything ) and he updated me regularly.
(2) had mentioned it many times during 2008.
He was arrested in the middle of 2009 and charge with counterfeiting the US dollar.
Then on March 18, 2011 NotHaus found guilty of making coins.
It was called a form of domestic terrorism ( the coins undermined the US dollar ).
That means they'd most probably classify Bitcoin as a form of international terrorism because it undermines every single government-controlled currency.
I was still in Christchurch at the time this news broke.
During my downtime, when not trying to fix the roadway outside my mum's place, I would go to my brother's house in the western side of the city.
Over the past week I'd been laying out old family photos on my brother's dinner table and using a digital camera to take photos of as many as I could before I had to head back to Sydney.
On March 19th, (2) sent an email notifying me of what has occurred with NotHaus.
I'd hardly slept more than a couple of hours at a time for the past two and a half weeks.
I really didn't need more of this [redacted].
Dropping The Bag
I arrive back home from Christchurch, utterly exhausted, to find that Mike Hearn had finished built a second code-base for Bitcoin.
March 23, 2011 Google Engineer Releases Open Source Bitcoin Client
Thousands more are alerted to Bitcoin again.
One day someone gets indicted from creating a physical currency and having it called a form of terrorism, a few days later everyone hears about another type of digital-commodity-based currency that has no borders.
I'm definitely getting a wee bit frayed around the edges by now.
I told him that I wasn't going to be doing anything around Bitcoin for a while.
"What do you mean by that ?" (2) asked.
"I'm just going to move onto other things for a while," I said. "I'm totally stuffed through the lack of sleep and the stress and worry with what's happened in Christchurch and the attention we're getting".
"Ok then," (2) said. "But you'll still be around when we need you, right ?"
"Sure thing," I said.
About three or four weeks later ...
"The issue's been dealt with and the danger has passed", (2) said. "Can you send the file back to me now ?"
"I thought you wanted me to hold it for two or three months ?" I said. "It's only been a few weeks".
"I thought I'd need you to hold them for longer," (2) said. "But it appears the danger has gone for now".
I was exhausted from dealing with the earthquake and the stress and worry about who might be hunting us.
I was also pretty damn annoyed in how the execution of the electronic cash proof-of-concept has gone.
From wanting it to be run on every single consumer computer and electronic appliance it looked like it was heading to be centralised into huge data centres which would make it vulnerable to physical attack.
So I told (2), "While I was in Christchurch I had a hard-drive failure and lost the data. Hope you had a back-up".
There was a large pause before the next email arrived.
"What do you mean 'had a hard-drive failure and lost the data' ?" (2) asked.
"Well," I said. "I didn't want to accidentally create multiple copies of your coin and leave them lying about. When I came home from Christchurch my desktop computer had a hard failure. The discs spun up and it worked for a few minutes then it crashed suddenly with the discs making a terrible grinding noise as they ground to a stop".
"What do you mean ?" (2) asked again. "Have you lost the wallet data ?"
"Well, I didn't exactly lose it," I said. "But it should still exist in the email you sent to me on your end. Have a look and it should still be there".
"I deleted it the moment you confirmed the hash of the file was the same," (2) said. "This is not good. Not good at all".
He sounded quite upset about it all.
He'd [redacted] me off over the past year with the changes he'd been making to Bitcoin that took it further away from its intent.
Whether the changes were needed or inevitable is debatable but I was still extremely annoyed he'd ignored my instruction and advice more and more.
A few more emails went back and forth.
Him being really upset.
Me being supportive:
- "Hard-drive crashes do happen you know".
- "It must be the fates that made this happen".
After letting him stew for about a week ...
"Good news !" I said. "I gave the computer case a hefty shake, opened it up and blew all the built-up dust away, re-seated the RAM and graphics card and turned it on. It booted up !"
"What ?!" (2) asked. "Does that mean the coin hasn't been lost ?"
"Sending it back to you right now," I said.
After he received the file back he confirmed the hash was correct.
I told him I deleted the file on my end so he's the only one with the data now, and that he really should make a backup of it on a USB drive just in case his hard-drive failed.
"How do I know that you've deleted the coin on your end," (2) asked.
I should've made him sweat for another week.
"Look," I said. "If I was the type of person that'd say I'd deleted your coin file but still kept it around, then I wouldn't be the type of person you'd entrust with it in the first place".
"But how do I know for certain ?" (2) asked.
"Have you given this file to anyone else ?" I asked.
"No," (2) replied.
I said, "Then if any of these coin ever move then you'll know exactly who moved them, right ?"
"Well, OK then," (2) said. "I just wished I had a better way of confirming that I have the only copy".
After it appeared that he'd calmed down somewhat, I deleted my copy of his wallet.
Gavin Visits The CIA
28th April 2011.
(2) emailed me in a panic.
"Did you read that ?" he asked.
"Read what ?" I returned.
"Gavin's posted on the message-board that he's off to visit the bloody C.I.A !" (2) exclaimed.
I went and had a look at Gavin's post .
"Well," I said. "We did think that a few three-letter-agencies might by looking through the message-board, the bitcoin.org site and hunting for us, right ?"
"Yeh," (2) said. "But this is very different to that. Having them just roam around the board, private messaging some folks or making fishing posts to discover the attributes of some of the members is one thing. This is something completely else."
"It is a wee bit unsettling, that's for sure," I said. "We're pretty well protected though. This [redacted] with what Wikileaks has done wasn't specifically seen but we knew they'd become alerted to us eventually. I personally thought they'd become aware of us when the online casinos start using bitcoin for a currency replacement. The entire anonymous set up of the Satoshi character and Bitcoin keeps us protected from this. Unless you've been mentioning stuff to Gavin that you really shouldn't've ?"
"No," (2) said. "I haven't told Gavin anything more than the usual project-related stuff."
"Good to hear," I said.
"We need to go through our options with regard to this situation," (2) said.
"What do you mean options ?" I asked. "There's really nothing we can do, right ? We can't even ask him not to go because that in itself will alert whoever in the CIA he's communicating with. They might very well hope that we'll break our silence and try and contact him directly again."
"As far as I'm concerned, Gavin is a traitor," (2) said.
"That's a bit harsh, don't you think ?" I said. "If anyone gets a request from the CIA to go and have a chitchat with them, what would you expect them to do ? Say no and hope they just go away ? They're locking up anyone they don't like under the guise of terrorist. If Gavin says no then they hide him away somewhere and get the information out of him behind the scenes."
"That'd be better than to openly converse with the CIA," 92) said. "And calmly walk up to them and give them everything he knows about us and the project. I'm pretty sure he doesn't have anything personal on me but others on the outer team might've been messaging or emailing him over time who I might've slipped in details I shouldn't have."
"That's why you should've done what I did," I said. "And only go through a single intermediary - you."
"It doesn't matter now," (2) said. "He's a traitor and I want to know what our options are to handle this."
"Just what are you meaning by options ?" I asked. "What are the usual options when you have a traitor in your midst ? What do sovereign states do to traitors ?"
"You're talking about Silk Road," (2) said. "That's not what I mean by 'an option' here."
"Well, Ok then," I said. "Glad we sorted that bit out".
"This is all your fault," (2) said. "You're the one who told me to choose him to be the project second. You're the one who told me to hand the Alert Key and project over to him."
"You didn't exactly hand it over to him though, did you ?" I said. "I've since found out that you pretty much dumped it on him without even asking. What the [redacted] man! You were supposed to ease him into it and, if he declined, we would've found another way."
(2) said, "With it being confirmed that these agencies are inside the compound, what do we do ?"
I said, "We're going to wait and watch. And be very, very careful. We'll read what's happening on the message-board and direct message anyone via the other handles. I mean we as in you. Personally, I don't think it's a good idea to visit any Bitcoin-related website at the moment. You can guarantee that they're all being watched and every single member is being made a note of and analysed and tracked."
2014 Bitcoin documentary
Gawker Silk Road Article
In May 2011 the Bitcoin project begins to attract a lot more attention.
Slashdot May 16, 2011
launch.co May 15, 2011
On May 29th 2011 I make an archive of my Bitcoin-related emails.
During the archiving process Outlook crashed.
After a computer restart I found that the Bitcoin subfolder no-longer exists and that the archived file was corrupted.
As I was using POP3 at the time, I had no other copies of those emails and they were gone forever from my end.
I email (2) telling him what had happened and asking if he could send me his copy of our correspondence.
(2) said, "The data is far to large to send as an attachment. The email attachment would have the data from three years of emails. The best way would be to encrypt a copy of it to a USB drive and post it via mail".
I said, "I really don't think it's a good idea for me to have my home address on your computer. Maybe I'll check out how to organise a Post Office Box you can send it to ? It'll be a Sydney address".
"What ?" (2) asked. "Are you saying you live in Sydney, Australia ?"
"I've been here for almost a dozen years now", I said.
I then receive an email with the Subject Title that included the word address.
The Email client I was using at the time displayed the first few lines as a synopsis of the email so that you can have an idea of what the contents may be without opening it up entirely.
At a glance I saw it was (2)'s personal address.
I deleted it immediately, including emptying the email client trash folder, but not before noting two things:
- He lived in a suburb in the northern part of Sydney.
- He'd been using his real name all of this time.
"Ummm...", I said. "Did you just send me an email with your personal details including your home address ? Because if you did I'm just letting you know that I deleted it immediately. If it wasn't your personal details would you mind re-sending it as I no-longer have it".
"Those were my personal details", (2) said. "But why did you delete them ? I want you to have them so that we can meet up face-to-face. I can even give you a USB drive with our email archives directly. It's so amazing that we've been in the same city all this time!"
"Dude", I said. "With all that's happening at the moment do you really think it'd be wise for us to meet face-to-face ? If one of us has been compromised then we'd be putting the other into danger as well. Also: What's with the idea that you've been using your real name all this time ? Whatever happened to being cautious ? When we started working together you didn't know who the [redacted] I was or where I was from".
"What ?" (2) asked. "You mean (xxxxx) isn't your real name ? You've been lying to me all this time ? I've trusted you".
"Seriously ?" I said. "Every so often you've been mentioning the Cypherpunk's Manifesto but I think you either haven't read it fully or don't understand its principals. The idea is to be private and to only give up personal information when we choose to. We started working together with you creating new anonymous email addresses for us both so that we didn't know each other and could converse without either of us knowing any personal details of the other. And you promptly began using your real name immediately ? Wow !"
"But we live so close to one another", (2) said. "If we meet up we can progress this in ways which are too difficult just over the internet."
"Until such time that Bitcoin becomes more acceptable to normal people we cannot meet face-to-face", I said. "At the moment there are government agencies that are becoming more and more aware of Bitcoin and some of the smart ones might catch on that this technology is unstoppable and can never be suppressed or removed. And what do you think will happen if the anonymous marketplace that has no morals or ethics becomes well known to the wider community ? It may be a couple of years before we can get together".
And then it happens.
Gawker June 1, 2011
Oh [redacted] !
All emails prior to 29th May 2011 were already lost.
I pretty much did a forensic clean of my system again and again.
Every time I went through everything and was certain all bitcoin-related material was removed, I'd come across another item.
I went everywhere from typical document folders, into the Windows Registry, to removing any "Recents" from the Registry and from the physical folder location itself.
It's amazing how many places various applications squirrel away bits of data.
It took me a few days, purging a couple of hours at a time.
I thought I'd never be able to remove everything, but finally I was able to go through and not find any more information or links.
The last item that linked me to the Bitcoin project ( other than what was on (2)'s and (3)'s computers ) was the bitcoin.org domain purchase from August 2008.
I just had to keep my head down and be quiet for another four years and those records would be gone forever.
I told (2) and (3) that I'd obliterated all Bitcoin related material from my end and that they should do the same on their end.
"You what !" (2) asked. "How many bitcoin did you just delete ?"
"The value was worth about $40,000 US dollars when I deleted the file," I said.
"You didn't have to delete them," (2) said. "Just encrypt them and store on a USB stick. No-one would've been able to access them."
"The types of folks who are hunting us would not care whether they can access them of not," I said. "They just need to see that we've got something to hide and that it's Bitcoin-related. The governments around the globe have been locking up folks on suspected-aiding-terrorism charges and throwing the key away. I had to make sure there was absolutely nothing on my computers that showed I had any idea what Bitcoin or crypto was. I even deleted the crypto stuff I'd picked up during my assembly language days."
A chain is only as strong as its weakest link.
And the blockchain tech ensures that, not only is the weakest link the one currently being welded onto the end, but every previous link in the chain gets stronger and stronger with each appended link.