The King’s Wi-Fi

Getting your Trinity Audio player ready...

This article was first published on Dr. Craig Wright’s blog, and we republished with permission from the author.

The proof-of-work definition that I used in describing how Bitcoin solved the Byzantine generals problem¹, when questioned by James A. Donald, derives from the SANS testing process, which I’d been going through in the USA.

I had been involved with SANS training and conferences since 1997. Between then and the time I dropped off doing courses in 2015, I had gained over thirty certifications. The courses included two master’s degrees². The areas of study covered information security, programming, and much more. I took all three of the GSE hands-on exam³. I did so while studying for a master’s degree in law, a master’s degree in statistics, and several other master’s degrees. In the process, the testing component of the SEC-617 course, which was used in the GSE hands-on lab, involved an exercise where a number of us needed to work together.

In the exercise, the GSE cohort needed to crack the ‘King’s Wi-Fi’. Using AirSnort, Aircrack-ng, WEPCrack, etc., we could work together in an aim to break into the network, prior to being discovered, as a demonstration of a pen testing exercise.

Ironically, one aspect of my writing that has not been picked up on is that my description of how Bitcoin solved the Byzantine generals problem was taken from the SANS exercises. The requirement was that the exercise would work in a group; we all needed to configure our machines using wireless cracking tools to capture the Wi-Fi and attack the wireless network managed by the SANS/GIAC examiners before the time would run out. So, a few weeks later, when I had returned from the U.S. and released the white paper, Mr. Donald asked me about the problem¹ that Bitcoin solved.

The solution to the problem was not one that was fully provided at the SANS exam. Each of us, as a cohort doing the GSE test, wanted the same result. There was no issue of trust. Yet, it remained an issue that was on my mind. At the conference, we could all contact each other using Jabber and other tools. There were no issues of not trusting one another.

On November 13th, Mr. Donald sent me a rather long, rambling message⁴, saying that the Byzantine generals problem was a classical hard computer science problem, one that would not be solved easily. James Donald said I could not model the system under attack. I had done so many times. The entire purpose of my PhD thesis evolved around “The Quantification of Information Systems Risk.” I used economic processes in econometrics in the modelling of risk.

I was already getting frustrated with Mr. Donald as he called Bitcoin “bitgold”, continuously. Bitcoin was not bit gold, which did not seem to be something many people wanted to understand, and it remains something people don’t seem to understand. I had been explaining over and over again that Bitcoin was not a system where every single person would run a node. I believe I made it very clear that only a few nodes would exist, but unfortunately, individuals such as Mr Donald kept going on about anti-government, anti-bank, and other crazy ideas that they wanted to be part of my creation.

The problem that BTC Core, and originally Mr. Donald, had was that in my system, a large transaction can be traced and made subject to orders of proceeds of crime. My goals for Bitcoin were not to design a system that suited the anarchist concept of a government-free money. My system was designed to provide micropayments for the web and the Internet generally. It is not 50% of the people running the system making the decision; nodes are commercial entities that are subject to government control, regulation, and law. Here lies the constant point of difference between myself and all those seeking to change Bitcoin from the beginning.

You see, with large commercial nodes as I envisioned them, the nodes can make changes with respect to the coins. It is a distributed database, and write once read many (WORM) databases are changed all the time. For public company transactions, every accounting platform used within the United States follows the same form of system. It is required so that companies cannot change the records. Errors can be fixed, but the methodology is to append a record. So, when I came back to respond to James Donald over half a day later, I did so having taken my writings, including those from the recent courses I had done, and modified them using the context of the information security sessions at the SANS Institute.

My argument was simple: networks become commercial data centres, and as such, a few nodes service the rest. I had explained the scenario before I even launched Bitcoin ⁶. Importantly, as I explained in section 8 of my white paper, simplified payment verification (SPV) would be required to be run, so that users did not need to run server farms. For some calculations, remember that I pointed out that there would be over 100 GB of bandwidth per day. There are 144 blocks discovered every day. So, the argument for blocks of 1 MB is very simple: it doesn’t exist.

If we have 144 blocks and an average bandwidth of 100 GB being transmitted in the same day, we have an average block size of 694 MB. Transactions follow a Pareto distribution. Consequently, to be able to handle such a level of load, requirements are much higher. In 2004, I completed a master’s degree in Network Systems Architecture and Design. I understand bandwidth allocation very well. In the past, I also held Cisco certifications, both in security and networking.

Authors such as Balogh and Medvecký (2012) addressed the problem using simulations. But, we can calculate it using a Pareto distribution. Measuring in gigabytes, and accounting for a distribution where we have a long-tail effect with an average of 694 MB, ends up giving us a requirement that each node can handle block sizes between 5 and 10 GB. Yes, to compete with Visa in 2008 would require that Bitcoin can handle up to 10 GB in any ten-minute period. So, Bitcoin was not designed to handle blocks of 1 MB. Doing a little bit of simple maths would help you determine that I had been talking about large server-farm systems in 2008, before I launched Bitcoin.

But, the problem I’m solving isn’t the one that some people want to talk about. Other people, those of BTC Core, followed the maligned ideas of James Donald, and sought to create an anarchist system that allowed the transfer of money for illegal activities. Which is not how Bitcoin works.

You see, when you have large commercial entities, which every proof-of-work blockchain system must lead to (and, by definition, every proof-of-stake system—whether it is blockchain-based or not), you end up with a scenario where the systems can be subject to law at scale. Ten years ago, Bitcoin was not operating at scale. Which made interactions more difficult. But as Bitcoin scales, the ease at which server farms can be detected grows. The requirement for Bitcoin to be subject to legal action lies in its scale. Ideally, such scale will come with increased transaction volumes, but it may also be developed through price and manipulation.

So, we are now entering a time where BTC, too, will become subject to law.

References

1. Bitcoin P2P e-cash paper [Cryptography Mailing List]. (2008, Nov 13). Satoshi Nakamoto Institute. https://satoshi.nakamotoinstitute.org/emails/cryptography/11/
2. Certified Professional [Craig Wright]. GIAC Certifications. https://www.giac.org/certified-professional/craig-wright/107335
3. Security Certification: GSE [GIAC Security Expert (GSE) Certification]. GIAC Certifications. https://www.giac.org/certification/security-expert-gse
4. Bitcoin P2P e-cash paper [comments]. (2008, Nov 13). metzdowd.com. https://www.metzdowd.com/pipermail/cryptography/2008-November/014847.html
5. Bitcoin P2P e-cash paper [comments]. (2008, Nov 13). metzdowd.com. https://www.metzdowd.com/pipermail/cryptography/2008-November/014847.html
6. Re: Bitcoin P2P e-cash paper. (2008, Nov 2). The Mail Archive. https://www.mail-archive.com/[email protected]/msg09964.html
7. Balogh, T. Medvecký, M. (2012). Average Bandwidth Allocation Model of WFQ. Modelling and Simulation in Engineering, vol. 2012, Article ID 301012, 7 pages. https://doi.org/10.1155/2012/301012 ID 301012, 7 pages.