The title of this talk is ​“Hardware, Software, Trustware.” How many of you have been pay­ing atten­tion to this whole busi­ness about a fork? Has any­body heard of a fork? There is a cul­ture gap that is being expressed in this fork. And most peo­ple look at this and they see the obvi­ous cul­ture gap. Most of the min­ing hap­pens in China; most of the min­ers are Chinese; a lot of the devel­op­ment hap­pens in Western nations; a lot of the devel­op­ers are from Western nations. And at a first glance it looks like the cul­ture gap is some kind of East/West thing. 

It’s not. In fact, I think a much bet­ter frame­work for think­ing about this is that the cul­ture gap at the cen­ter of the debate we’re hav­ing today is a cul­ture gap between peo­ple who build hard­ware and peo­ple who build soft­ware. And those cul­tures have been diverg­ing since the 1950s.

If you’re involved in com­put­er sci­ence, if you do hard­ware or soft­ware for a liv­ing, you know what I’m talk­ing about. Software goes way back, but not as far back as hard­ware. Because the very first soft­ware was hard­ware. And if you want­ed to use a com­put­er, it ran one pro­gram. Some of the first com­put­ers ran very spe­cif­ic pro­grams, prob­a­bly one of the ear­li­est exam­ples is the Enigma crack­ing machine at Bletchley Park, built by Alan Turing to crack the German cryp­tog­ra­phy dur­ing World War II. It did not have soft­ware per se. It had inputs. You could input the mes­sage, and it would try to fig­ure out the key. But it only ran one pro­gram. And you could bare­ly real­ly call it a com­put­er. It was an electro­mechan­i­cal device with a bit of elec­tron­ics; very primitive.

Software start­ed hap­pen­ing in the 60s. And soft­ware rep­re­sent­ed a giant leap for­ward, because until then if you want­ed to repro­gram a com­put­er you had to change its wiring. Or you had to flip a lot of switch­es. Like, a lot of switch­es. Like 10,000 switch­es in a big bank of switch­es, and if you got one of them wrong…that was a bit of a prob­lem. Programming in bina­ry, not fun.

And out of this, grad­u­al­ly we start­ed hav­ing these two cul­tures emerge, the cul­ture of peo­ple who build hard­ware and the cul­ture of peo­ple who build soft­ware, and the fun­da­men­tal dif­fer­ence has to do with the life cycle of devel­op­ment. And that per­sists to this day. 

When you build a hard­ware device, your life cycle is mea­sured in months if not years. Eighteen to twenty-four months. You design a chip to do some­thing. You make some archi­tec­ture deci­sions. These deci­sions will arrive at the mar­ket­place two years from now. And if you got them wrong, you start again. If you make a mis­take in hard­ware, things hap­pen and you can’t issue a patch. If you ship a phone that has a nasty ten­den­cy of blow­ing up, there is no soft­ware patch that you can issue that will fix the bat­tery issues. It’s out there, in peo­ple’s pock­ets, get­ting hot.

The cul­ture that comes out of that is a very con­ser­v­a­tive cul­ture. The plan­ning time­lines for build­ing hard­ware are very long. And they require absolute pre­ci­sion. If you make a mis­take you don’t just change a line, recom­pile, try again, issue a patch. You recall $1 bil­lion worth of sil­i­con and turn them into scrap, because you made a mis­take. A nanometer-scale mistake. 

And at first, soft­ware was like that. Because if you pro­grammed, say in Fortran, on a punch card, and you had six min­utes of com­pute time a day, and you spent twen­ty hours writ­ing your soft­ware and punch­ing it into cards, and then you sub­mit­ted it to the main­frame and dur­ing your six min­utes the main­frame would go, ​“Bzzt! Error,” now you have to go back, spend a day fig­ur­ing out why, fix­ing it, punch­ing it back into cards, and putting it back on the main­frame dur­ing your next six-minute win­dow. That’s how pro­gram­ming start­ed. And if you were a pro­gram­mer in those days, the atti­tude was, ​“Well, thank God I don’t have to flip a thou­sand switch­es to do this. This is so much faster! It only takes forty-eight hours to do one life cycle.” 

And grad­u­al­ly this gap start­ed shrink­ing and shrink­ing and shrink­ing. If you’re a real­ly real­ly crap pro­gram­mer, you don’t even plan, design, or think much about your soft­ware. You just…put some shit togeth­er, hit run, see what hap­pens. Fix it, run, see what hap­pens. Fix it, run, see what hap­pens. You iter­ate real­ly real­ly fast. The real­ly great pro­gram­mers are not that slop­py. They put some thought into every line they change. But all of us have moments when we start hack­ing. That’s where the phrase ​“hack­ing” comes from. From Berkeley in the 1970s, where that’s how they fixed soft­ware. You just hack at it until it works.

But that encour­ages a men­tal­i­ty where your worst mis­take lasts two min­utes. And no one gets to see it, because you don’t ship that. That’s the begin­ning of a drift apart of two cul­tures. In hard­ware, your mis­takes are immor­tal­ized on sil­i­con. And they might start fires. In soft­ware, your mis­takes dis­ap­pear some­where in a Git log. Nobody real­ly has to look back at the pre­vi­ous com­mits and see all of the hor­ri­ble code you wrote. Right, we all do that. If you’ve done soft­ware pro­gram­ming, that’s how most of us program.

That has some very inter­est­ing impli­ca­tions for the cur­rent debate. Because there’s anoth­er fun­da­men­tal and real­ly impor­tant dif­fer­ence in the cul­ture between hard­ware and soft­ware. 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 gonna be five years behind your com­peti­tors until you fig­ure it out again. But that ship date is the last date. And once it’s out there it’s out of your hands.

Look recent­ly at the peren­ni­al bat­tle between AMD and Intel. How many of you are famil­iar with chip archi­tec­ture at AMD and Intel? About two years ago— Not too many, so I’ll make it sim­ple. Two years ago, AMD and Intel start­ed work­ing on their latest-generation chips. And, hav­ing a five-year hori­zon, they had to make some bets. Some trade-offs, some design decisions. 

AMD made the bet that most sys­tems that ship have a Graphical Processing Unit. And that for advanced math­e­mat­i­cal oper­a­tions (matrix manip­u­la­tion, float­ing point arith­metic, etc.), you would have a devel­op­ment envi­ron­ment that would take that, opti­mize in OpenGL, and ship it to the graph­ics card for pro­cess­ing. Because it’s 1,000 times faster for that kind of work. So why would you do that on a general-purpose CPU? It did­n’t seem sen­si­ble. So they decid­ed, let’s put sixty-four cores on a chip but only give them four or eight floating-point arith­metic units.

Intel said the soft­ware is not going to get that good. It’s not going to spe­cial­ize these instruc­tions. Let’s put just eight cores on a chip but give every one of them a floating-point arith­metic unit. 

Two sim­ple trade-offs, right. Two deci­sions. Is the indus­try going this way or is it going that way? Are we going to be able to lever­age this new tech­nol­o­gy or not? Will the soft­ware catch up with what we’re try­ing to do? Will the archi­tec­tures 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 dom­i­nat­ed the desk­top and serv­er envi­ron­ment, for this cycle. Now, AMD gets to try again, four years lat­er. Three or four years lat­er. That sim­ple trade-off changed the for­tunes of that com­pa­ny and the direc­tion of an industry. 

We see this in oth­er exam­ples. Let’s go for big­ger hard­ware. I’m a fan of avi­a­tion; I’m a pri­vate pilot. I love that stuff. Boeing, Airbus. Five years or so ago, they made a very impor­tant bet.

Airbus said it’s most­ly going to be about hub-and-spoke con­nec­tions. You’re going to have big hub air­ports, and they’re going to run hun­dreds or thou­sands of pas­sen­gers on sin­gle routes. So what we need to build is a double-decker air­craft that can seat more peo­ple than ever before.

And Boeing said no, it’s going to be most­ly region­al point-to-point. And if we take an air­craft and allow it to extend its range to 12,000 nau­ti­cal miles, then that choice is the bet­ter choice. And they built the Dreamliner. 

Boeing was right. Airbus was wrong. Boeing shipped a hun­dred times more Dreamliners than Airbus, who’ll nev­er 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 soft­ware, even in this envi­ron­ment, you can fix it in a mat­ter of hours, ship a new release, done. So one impor­tant dif­fer­ence is this idea of ship date. Once you put it out there, you’re locked in for a cou­ple of years. And that makes you have a much more con­ser­v­a­tive attitude. 

But, it has a good side. Because you will only encounter one of those ships dates a cou­ple of times a decade. Three times, four times a decade. That’s it. With soft­ware, how­ev­er, some­thing else hap­pens. Your ship date is not the end of your prob­lems. It is the begin­ning of your prob­lems. Because once you ship, main­te­nance starts. And very quick­ly it became appar­ent to the soft­ware indus­try that soft­ware behaves a bit like per­ish­able pro­duce. It’s got three days of shelf life, after which if you haven’t done main­te­nance it starts rot­ting on you. 

Software grad­u­al­ly degrades. Especially today’s soft­ware, which is open source soft­ware, in a very dynam­ic envi­ron­ment, with lots of depen­den­cies to third-party libraries. Everything is mov­ing. SSL changes some­thing, we find a new bug, new release. The tol­er­ances of the net­work change, new release. Berkeley DB does­n’t behave the way you expect­ed, new release. And so soft­ware is like a never-ending rela­tion­ship, which you’re trapped in. Like, there is no ship date, it’s con­tin­u­ous ship­ping. It’s con­tin­u­ous main­te­nance. There is no ​“and now we’re done.” There’s only ​“and now our trou­bles begin!” 

This diver­gence has cre­at­ed a mas­sive cul­ture dif­fer­ence between the cul­ture of min­ers and the cul­ture of soft­ware devel­op­ers. It is at the root of the cur­rent dis­cus­sion we’re hav­ing. From the per­spec­tive of some­one build­ing hard­ware, of course you’re not going to ship a new chip archi­tec­ture to fix the prob­lem. Just juice up the clock speed. This archi­tec­ture still has plen­ty to go, right. It’s got room to grow. Change a para­me­ter for God’s sake, juice up the clock speed, and we can keep the cur­rent archi­tec­ture and jut ship it.

From a soft­ware devel­op­er’s per­spec­tive, if you’re look­ing at the big­ger space, it’s much bet­ter to change the archi­tec­ture now before you have a lot of tech­ni­cal debt, and soft­ware crud, and accu­mu­lat­ed UTXO, and enor­mous blockchain sizes on your data store that you have to keep for­ev­er. And of course, you’re going to be main­tain­ing this shit either way…might as well do an archi­tec­ture change.

This is the fun­da­men­tal cul­ture dif­fer­ence between the min­ing com­mu­ni­ty and the soft­ware devel­op­ment com­mu­ni­ty in Bitcoin, and not just Bitcoin. Bitcoin’s just the one that has the strongest, biggest, most vocal min­ing community.

But that’s not the end. That’s just the begin­ning. Because with­out even notic­ing, we now have a com­plete­ly new cat­e­go­ry which is going to cre­ate a com­plete­ly new cul­ture. And that is trust­ware. What is trust­ware? Trustware is this weird emer­gent phe­nom­e­non that hap­pens when you com­bine con­sen­sus rules that are run­ning and instan­ti­at­ed in soft­ware with a back­ing of hard­ware deployed on a glob­al net­work, with a diverse set of par­tic­i­pants. All of the headaches of hard­ware, all of the headaches of soft­ware, and some new ones.

Now, when you ship is real­ly impor­tant. Because if you’re mak­ing a con­sen­sus rule change, you have to coor­di­nate an entire glob­al net­work. But the ship date is no longer the end of your prob­lems, it’s just the begin­ning of the prob­lems because now you have to main­tain it for­ev­er. And every mis­take you make gets baked into the blockchain and has to be car­ried with you in the con­sen­sus rules, for­ev­er. In Bitcoin there are no bugs. There are only con­sen­sus rules cre­at­ed through tradition.

So how many peo­ple here are soft­ware devel­op­ers who’ve worked in Bitcoin at all? Alright. You prob­a­bly know about this one. It’s a clas­sic. So when you write a multi-signature script and the code gets to the part where it says opcheck multisig verify, the code has to go and pop as many keys off the stack as you’ve defined as the last para­me­ter. N, right? And then inspect the sig­na­tures which should be M (M of N), and do some­thing. Turns out opcheck multisig verify pops one extra val­ue. That’s a bit of a prob­lem, because if you do a mul­ti­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 crash­es, and your mon­ey’s no longer spendable.

Now, when that bug happened—because it did hap­pen acci­den­tal­ly back in prob­a­bly 2011—it was­n’t fixed before some peo­ple put spend­able Bitcoin and redeemed it on the blockchain. And to do that, what they did was they put what’s called a null value—a dum­my val­ue. 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 bleh, key, key, key.” And so you pop ​“bleh, key, key, key,” throw away the bleh, keep the three keys, it works! Done. But now, that script has to be valid for­ev­er. Because every node in Bitcoin val­i­dates every­thing, for­ev­er. Oops.

Now, devel­op­ers are writ­ing new ver­sions of the software—multisig is now part of a pay to script hash for­mu­la. Guess what. I still pops an extra val­ue. And so I write in my book—there’s a big ol’ notice and it says, ​“You will see an extra val­ue in all the redeem scripts. That’s because there’s a bug. That bug can­not be fixed. It’s with us forever.”

Why can it not be fixed? Because the fix is worse than the prob­lem. 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 now every­body knows it and they write redeem scripts that just pop three. Fine. No prob­lem. But now you have a piece of code in your blockchain, what is effec­tive­ly a soft fork, that says, ​“Before Block X, pop four, after Block X, pop three if you see this script.” So that all of the scripts that came before are valid, and all of the scripts that will come next are also valid but don’t need that dum­my value.

What you’ve done is you’ve moved the crud from your script into your code. And now these two, three lines of code need to be main­tained for­ev­er. What if there’s a bug? If you write three lines of code, on aver­age one of them’s going to be wrong. So for every line of code you add to the con­sen­sus rules, you’ve got to make sure you don’t add a bug. How do you coor­di­nate an inter­na­tion­al net­work so that every­body makes sure they change the rules at the same time and you you don’t acci­den­tal­ly inval­i­date trans­ac­tions? This is the essence of trustware.

The essence of trust­ware is we are now writ­ing soft­ware, that gets backed by hard­ware, deployed on a net­work, and estab­lish­es a set of glob­al con­sen­sus rules which if you make a mis­take on these con­sen­sus rules and go out of con­sen­sus, you can lose mil­lions. You can get cheat­ed out of trans­ac­tions. You can be suf­fer­ing replay attacks or mal­leation attacks or all kinds of oth­er attacks. This is not a game. This is a new soft­ware fron­tier, only it’s not soft­ware. It’s trust­ware. And trust­ware is way more com­pli­cat­ed than soft­ware, or hard­ware, or soft­ware and hard­ware put togeth­er because there’s also a glob­al net­work com­po­nent that’s con­trolled by inde­pen­dent actors. 

Why on earth would we do all this? I mean, it does­n’t sound like a fun devel­op­ment exer­cise. Why are we cre­at­ing this thing that will have its own cul­ture, trust­ware devel­op­ers? Consensus experts. That requires its own deep under­stand­ing and analy­sis and review. Why are we doing this? Because it gives us some­thing amaz­ing. It gives us a cen­tral­ized plat­form of trust that is neu­tral and not con­trolled by anyone—and that’s worth it. But it’s bloody painful. 

And so this is where we are today. Within this net­work, espe­cial­ly in the case of Bitcoin, we are now see­ing a direct con­flict. It’s not a vio­lent con­flict. It’s sim­ply a con­flict of ideas. It’s a dis­agree­ment about the future of the net­work. It’s a dis­agree­ment about the future of the cur­ren­cy and the future of the con­sen­sus rules. 

I have to assume good faith. I think both par­ties see the way for­ward as the best way for­ward for Bitcoin. But in tech­nol­o­gy it’s not just a mat­ter of opin­ion. There is truth. Truth means some­thing. There are cor­rect opin­ions and incor­rect opin­ions. There are opin­ions that match the facts, and ones that don’t. It’s not a sys­tem of belief, it’s a sys­tem of science.

Unfortunately most of the con­ver­sa­tion that’s hap­pen­ing real­ly looks like a sys­tem of belief. Or more like­ly a com­pe­ti­tion of soc­cer. So, on the one hand you have diehard fans of FC Barcelona and on the oth­er hand diehard fans of Manchester United. There is no right or wrong. There is no cor­rect answer. There is only my team and your team, and your team is wear­ing the wrong col­or. They look sil­ly and they can’t play soc­cer. Clearly. Any intel­li­gent per­son can see that. Unfortunately that does­n’t lead to any sci­en­tif­ic con­clu­sions, which is why we’re here.

So what we’re see­ing today is the cul­mi­na­tion of a fun­da­men­tal cul­ture clash between peo­ple who pri­mar­i­ly build, man­age, deploy, and run hard­ware; and peo­ple who fun­da­men­tal­ly build, man­age, and main­tain soft­ware. And that’s why you’ll notice there’s some Chinese peo­ple on the soft­ware side and there’s some Westerners on the hard­ware side, and this is not a cul­ture clash between East and West. It is a cul­ture clash between hard­ware and soft­ware, and from with­in that a new cul­ture is now emerg­ing. A cul­ture of devel­op­ers who are build­ing trust­ware. Who are grad­u­al­ly see­ing the nuances and incred­i­ble dif­fi­cul­ty of build­ing a sys­tem of con­sen­sus rules that is backed by hard­ware and deployed on a glob­al net­work, and that is trust­ware. Thank you.