 The title of this talk is hardware software trussware How many of you have been paying attention to this whole business about a fork? Anybody heard of a fork? There is a culture gap that is being expressed in this fork and Most people look at this and they see the obvious culture gap Most of the mining happens in China Most of the miners are Chinese a lot of the development happens in Western nations a lot of the developers are from Western nations and At a first class it looks like the culture gap is some kind of east-west thing It's not in In fact, I think a much better framework for thinking about this is That the culture gap at the center of the debate we're having today is a culture gap between people who build hardware and people who build software and Those cultures have been diverging since the 1950s If you're involved in computer science if you do hardware or software for a living You know what I'm talking about Software goes way back, but not as far back as hardware Because the very first software was hardware and if you wanted to use a computer It ran one program Some of the first computers run very specific programs probably one of the earliest examples is the enigma cracking machine at Bletchley Park built by Alan Turing to crack the German cryptography during World War two it did not have software per se It had inputs you could input the message and it would try to figure out the key But it only ran one program and You could barely really call it a computer was an electro mechanical device with a bit of electronics very primitive software started happening in the 60s and Software represented a giant leap forward because until then if you wanted to reprogram a computer You had to change its wiring or You had to flip a lot of switches like a lot of switches like 10,000 switches and a big bank of switches and if you got one of them wrong That was a bit of a problem programming in binary not fun And out of this gradually we started having these two cultures emerge the culture of people who build hardware and the culture of people who build software and the Fundamental difference has to do with the life cycle of development and That persists to this day When you build a hardware device your life cycle is measured in months if not years 18 to 24 months You design a chip to do something you make some architecture decisions These decisions will arrive at the marketplace two years from now, and if you got them wrong you start again If you make a mistake in hardware Things happen, and you can't issue a patch if you ship a phone that has a nasty tendency of blowing up There is no software patch that you can issue that will fix the battery issues It's out there in people's pockets getting hot The culture that comes out of that is a very conservative culture the planning timelines for building hardware very long and They require Absolute precision if you make a mistake you don't just Change a line recompile try again issue a patch you recall a billion dollars worth of silicon and turn them into scrap Because you made a mistake a nanometer scale mistake and at first software was like that Because if you programmed say in Fortran on a punch card And you had six minutes of compute time a day, and you spent 20 hours writing your software and punching it into cards, and then you submitted it to the mainframe and During your six minutes the mainframe would go error Now you have to go back spend a day figuring out why Fixing it punching it back into cards and putting it back on the mainframe during your next six minute window that's how programming started and If you were a programmer in those days The attitude was well, thank God. I don't have to flip a thousand switches to do this This is so much faster. It only takes 48 hours to do one life cycle and Gradually this gap started shrinking and shrinking and shrinking if you're a really really crap programmer You don't even plan design or Think much about your software You just put some shit together Hit run see what happens Fix it run see what happens fix it run see what happens you iterate really really fast The really great programmers are not that sloppy They put some thought into every line they change But all of us have moments when we start hacking that's Where the phrase hacking comes from? From Berkeley in the 1970s where that's how they fixed software You just hack at it it works But that encourages a mentality where your worst mistake lasts two minutes and No one gets to see it because you don't ship that That's the beginning of a drift apart of two cultures in Hardware your mistakes are immortalized on silicon and they might start fires In software your mistakes disappear somewhere in a git log Nobody really has to look back at the previous commits and see all of the horrible codes you wrote Right, we all do that if you've done software programming That's how most of us program That has some very interesting implications for the current debate Because there's another fundamental and really important difference in the culture between hardware and software Hardware is all about ship date you work two years for that day When it ships and once it ships it's out of your hands you made the right design trade-offs great You made the wrong design trade-offs you're going to be five years behind your competitors until you figure it out again But that ship date is the last date And once it's out there it's out of your hands Look recently at the perennial battle between AMD and Intel How many of you are familiar with chip architecture and AMD and Intel? About two years ago not too many so I'll make it simple two years ago AMD and Intel started working on their latest generation chips and Having a five-year horizon they had to make some bets some trade-offs and design decisions AMD made the bet that most systems of ship have a graphical processing unit and that for Advanced mathematical operations matrix manipulation floating-point arithmetic, etc You would have a development environment that would take that Optimize it to an open GL and ship it to the graphics card for processing Because it's a thousand times faster for that kind of work So why would you do that on a general-purpose CPU? It didn't seem sensible So they decided Let's put 64 cores on a chip, but only give them four or eight floating-point arithmetic units Intel said the software is not going to get that good. It's not going to specialize these instructions Let's put just eight cores on a chip, but give every one of them a floating-point arithmetic unit Two simple trade-offs right two decisions is the industry going this way or is it going that way? Are we going to be able to leverage this new technology or not? Will the software catch up with what we're trying to do? Will the architectures of the future look more like this or like this? Agonizing over that choice they get a ship date in mind and they ship Intel got it right AMD got it wrong Intel dominated the desktop and server environment for this cycle Right now AMD gets to try again four years later three or four years later that simple trade-off changed the fortunes of that company and the direction of an industry We see this in other examples. Let's go for bigger hardware. I I'm a fan of aviation. I'm a private pilot. I love that stuff Boeing Airbus Five years or so ago. They made a very important bet Airbus said it's mostly going to be about hub and spoke connections You're going to have big hub airports and they're going to run Hundreds or thousands of passengers on single routes So what we need to build is a double-decker Aircraft that can see it's more people than ever before and Boeing said no it's going to be mostly regional point-to-point and if we take an aircraft and allow it to extend its range to 12,000 nautical miles Then that choice is the better choice and they built the Dreamliner Boeing was right Airbus was wrong Boeing shipped a hundred times more Dreamliners than Airbus will never catch up quite So now they get to try that again But it's going to be a five-year life cycle if there's a bug in your software Even in this environment, you can fix it in a matter of hours ship and you release done So one important difference is this idea of ship dates once you put it out there You're locked in for a couple of years and that makes you have a much more conservative attitude but It has a good side Because you will only encounter one of those ship dates a Couple of times a decade three times four times a decade. That's it with software However, something else happens Your ship date is not the end of your problems. It is the beginning of your problems because once you ship maintenance starts and Very quickly it became apparent in the software industry the software behaves a bit like perishable produce It's got three days of shelf shelf life after which if you haven't done maintenance it starts rotting on you Software Gradually degrades Especially today's software which is open source software in a very dynamic environment with lots of dependencies to third-party libraries Everything is moving SSL changes something we find a new bug new release The tolerances of the network change new release Berkeley DB doesn't behave the way you expect it new release and so software is Like a never-ending relationship Which you're trapped in Like there is no ship dates. It's continuous shipping. It's continuous maintenance There is no and now we're done There's only and now our troubles begin This divergence has created a massive culture difference between the culture of minors and the culture of software developers It is at the root of the current discussion. We're having from the perspective of someone building hardware of Course what you're not going to ship a new chip architecture to fix the problem Just juice up the clock speed This architecture still has Plenty to go right. It's got room to grow Change a parameter for God's sake juice up the clock speed and we can keep the current architecture and just ship it From a software developers perspective If you're looking at the bigger space It's much better to change the architecture now before you have a lot of technical debt and software crud and accumulated UTXO and Enormous blockchain sizes on your data store that you have to keep forever and Of course, you're going to be maintaining this shit either way might as well do an architecture change This is the fundamental culture difference between the mining community and The software development community and Bitcoin and not just Bitcoin Bitcoin is just the one that has the strongest biggest most vocal mining community But that's not the end. That's just the beginning Because without even noticing we now have a completely new category Which is going to create a completely new culture and that is trust where? What is trust where Trust where is this weird? Emergent phenomenon that happens when you combine Consensus rules that are running and instantiated in software with the backing of hardware Deployed on a global network with a diverse set of participants All of the headaches of hardware all of the headaches of software and some new ones now When you ship is really important Because if you're making a consensus rule change you have to coordinate an entire global network But the ship date is no longer the end of your problems It's just the beginning of their problems because now you have to maintain it forever and every mistake you make gets baked into the blockchain and has to be carried with you in the consensus rules forever in Bitcoin There are no bugs There are only Consensus rules created through tradition So how many people here are software developers who've worked in Bitcoin at all. All right, you probably know about this one It's a classic So when you write to multi-signature script and The code gets to the part where it says object multi-sig verify The code has to go and pop as many keys off the stack as You've defined as the last parameter and Right, and then inspect the signatures which should be M M event and do something Turns out object multi-sig verify pops one extra value That's a bit of a problem Because if you do a multi-sig of three keys and it pops four things there aren't four things on the stack and If there aren't four things on the stack you get a stack error And your script crashes and your money is no longer spendable when that bug happened because it did happen accidentally back in probably 2011 it wasn't fixed before some people put spendable Bitcoin and redeemed it on the script on the blockchain and To do that what they did was they put what's called a null Value a dummy value So they go, okay You want to pop four things off the stack? Three of which have to be keys and one which is gonna get ignored. Here's blow Key key key and so you pop blue key key key throw away the blue keep the three keys It works done But now that script has to be valid forever because every node in Bitcoin validates everything forever Oops Now Developers are writing new versions of the software multi-sig is now part of a paid to script hash formula Guess what it still pops an extra value And so I write in my book. There's a big old notice and it says You will see an extra value in all the redeemed scripts. That's because there's a bug that bug cannot be fixed It's with us forever Why can it not be fixed? Because the fix is worse than the problem I Mean sure you could fix it. You could just put a thing in the code that says from now on just pop three and Everybody knows it and they write redeemed scripts that just pop three fine, no problem But now you have a piece of code in your blockchain What is effectively a soft fork that says before block X? Pop for after block X pop three if you see the script So that all of the scripts that came before a valid and all of the scripts that will come next are also valid But don't need that dummy value What you've done is you've moved the crud from your scripts into your code And now these two three lines of code need to be maintained forever. What if there's a bug? If you write three lines of code on average one of them is going to be wrong So for every line of code you add to the consensus rules You've got to make sure you don't add a bug How do you coordinate an international network so that everybody makes sure they change the rules at the same time? And you don't accidentally invalidate transactions This is the essence of trustware The essence of trustware is we are now writing software That gets backed by hardware Deployed on a network and establishes a set of global Consensus rules which if you make a mistake on these consensus rules and go out of consensus you can lose millions You can get cheated out of transactions You can be suffering replay attacks or malation attacks or all kinds of other attacks. This is not a game This is a new software frontier. Only it's not software is Trustware and trustware is way more complicated than software or Hardware or software and hardware put together because there's also a global network component that's controlled by independent actors Why on earth would we do all this? I mean it doesn't sound like a fun development exercise. Why are we creating this thing that will have its own culture Trustware developers consensus experts That requires its own deep understanding and analysis and review Why are we doing this? Because it gives us something amazing It gives us a decentralized platform of trust that is neutral and not controlled by anyone and that's worth it But it's bloody painful and so This is where we are today Within this network, especially in the case of Bitcoin. We are now seeing a direct Conflict it's not a violent conflict. It's simply a conflict of ideas It's a disagreement about the future of the network It's a disagreement about the future of the currency and the future of the consensus rules. I Have to assume good faith. I think both parties see the way forward as the best way forward for Bitcoin But in technology, it's not just the matter of opinion There is truth truth mean something There are correct opinions and incorrect opinions There are opinions that match the facts and ones that don't It's not a system of belief. It's a system of science Unfortunately, most of the conversation that's happening Really looks like a system of belief or more likely a competition of soccer So on the one hand you have diehard fans of FC Barcelona and on the other hand diehard fans of Manchester United There is no right or wrong. There is no correct answer There is only my team and your team and your team is wearing the wrong color They look silly and they can't play soccer clearly Any intelligent person can see that Unfortunately that doesn't lead to any scientific conclusions, which is why we're here So what we're seeing today is the culmination of a fundamental culture clash between people who primarily build manage deploy and run Hardware and people who fundamentally build manage and maintain software and That's why you'll notice there's some Chinese people on the software side and some westerners on the hardware side And this is not a culture clash between East and West It is a culture class between hardware and software and from within that a New culture is now emerging a culture of developers who are building trust where who are gradually Seeing the nuances and incredible difficulty of building a system of consensus rules That is backed by hardware and deployed on a global network and that is trust where thank you