Introduction

(crowd cheers) - Hi everyone. Who is that ridiculous guy? I don't know, just crazy stuff going on at this conference. How's everyone doing? Are you having a great first day? (crowd cheers) Rodolfo just told me that this is the largest LaBITConf ever. I am so happy for him. What a fantastic success. This is my sixth out of seven, and I'm so happy to be here again for my second time in Montevideo, second time in Uruguay. Last time I came for a vacation, and in order to have a vacation, I didn't tell anyone I was here, and then I hid in Punta del Este for ten days with no internet connection. It was wonderful, wonderful. Alright, let's get started. I wanna talk about software development culture in this unique area of open Blockchain software development.

Software and finance

So, first of all, how many people in the audience are software developers? Whoo, quite a lot. And how many people are not software developers at all? Like no interest or understanding on how to code? Fantastic, we welcome you too. (crowd laughs) That sounded very patronizing, but no, we do. You know, there's something interesting that happens in our industry, which is, there's a very fundamental difference between the people who are involved in software development and the people who come from a financial background. And one of the reasons for that is those two domains have never come together the way they have come together with BitCoin and open Blockchain technology. For the first time, money is software, and software is money. Protocols determine trust. Security is based on open systems. And it seems contradictory. In a financial space, the idea of open systems is the opposite of security, right? Because in open systems, the basic idea is we let everyone participate, and in finance the basic idea is we let no one participate unless we know who they are, and then sometimes not even then. (laughs) Alright? So, open systems versus closed systems.

The cultures of the people being involved in both of these spaces are very different

And the cultures of the people being involved in both of these spaces are very very different, and in fact, you can see that every day on the conversations we have online on social media. All right? Especially, when you see some people who come from a financial background, from an economics background, or even from a libertarian and Austrian economics background, where they see no value in the software side of the industry and consider anything that's not Bitcoin as a waste of time. Ah, kids playing with software, creating new terms, and trying to do new things, and they're full of bugs, and all kinds of broken. And then, at the same time, you have people who come from a software engineering background, who neither understand nor want to understand the world of finance. Ah, conservative bankers, who needs a monetary policy? Defy for the win. (laughs) That culture clash is really interesting because these two cultures have been apart for a very long time, and of course, you've got one culture software engineering, which is a very new and young culture with a very new and young industry in science, coming to meet a very conservative, very old culture that has been around for centuries. And that culture clash is felt a lot in our industry and outside our industry. Outside our industry, we're just the weird people trying to do software as money, right? Inside our industry, there's all of these weird bankers who are not seeing the world as we see it, which is of perfect software that's easy to use, and they're stuck in their ways with their models. And that clash is going to change.

Fundamental shift in how we see money and have seen money for centuries

And the reason it's going to change is because the fundamental idea behind Bitcoin, which now is a whole ecosystem, is the idea that money can be software, pure software. It can be implemented as a pure protocol not an institution of trust, but a protocol of trust, a language of trust, in pure software. Money as a content type. Money as a transmission protocol. Money as data. And that is a fundamental shift in how we see money and have seen money for centuries. Because for centuries, we've seen money not as data, but as something physical. The more physical, the better, right? And Bitcoin represents the exact opposite of that. It represents something that is invisible, that is implemented in software, but can deliver trust as a protocol service. But this is a new space, and we don't quite know how to do software programming for financial applications. This is complicated stuff. Well, one of the interesting things that all humans do is they assume that if they have expertise in one area, they can easily transfer that expertise to every other area, right? So, if somebody's smart in one space, they think, we think, that we are also smart in any other space that is even closely related. So, that's how you end up with people who are really good at programming thinking they can also be really good at financial engineering. Or people who are very good at financial engineering thinking they can be very good at programming. Of course, reality has a way of breaking that vision quite quickly. It's like, so we built this thing, and it was a decentralized autonomous organization. We fund raised $150 million, and then we had a bug and everything got stolen, but it was fun while it lasted!

Software

(laughs) This culture of systems is really interesting you know, I've been working in software since I was ten years old, when I first encountered software programming for the first time in my life, and I was immediately in love. I was in love with this idea that you could take just thoughts and convert them into something that worked, that did something. You could take thoughts and convert it into action. I don't know if that, is a form of art it's certainly a form of expression taking things that are purely in your head, writing them down as a series of instructions, and then the moment when the computer actually does what you told it to do, often not what you wanted it to do (crowd laughs) afterwards, you find out that you told it to do something slightly different, and it followed it absolutely correctly, and not what you wanted to do, but that moment is golden. If you've ever had that experience, it's an incredible feeling of control, and of the ability of people to conquer machines. I think it satisfies our ego to be God-like and tell the machine "Computer, do as I say" Not as I mean, but as I said. (laughs) Let's see what happens that moment, when it goes well, is beautiful, right? But it's not a science. In many ways, this is such an early science that we still have a lot of ambiguity. One of the great programmers of our era once said "If we built houses the way we build software, one woodpecker could end civilization" (laughs) And it's so true, right? And now, we're discovering what happens when you try to take the fragile, complex, and often very vague world of software, and introduce it into the machines that govern our lives. A great example, and one of my hobbies is aviation. You know, it's one thing to tell the computer to put a pink box here, and the computer instead puts a pink box there, and you're like "Aah fucking CSS, what is it floats?" (groans) And then your like you spend four hours trying to move the pink box from here to there, I mean, it's frustrating, but when instead, what you're trying to tell the system is "If your Boeing 737 Max's nose is up here, push it down there" and instead it's here, you push it down there, bad things happen, right? So, introducing software into engineering disciplines, into engineering industries, without the rigor that most engineering industries and practices have, causes bad things to happen. And this is because software engineering is still a new science. You know how did engineers figure out how to make bridges that didn't fall down? It's really simple. They spent hundreds of years making bridges that did fall down, right? And every time a bridge fell down, they would "Oh, interesting, so if the wind blows just like that, whoops we should do it differently next time." And then repeat and iterate, right? And then you build a building, and it stays up for a while, and then it falls down, and lots of people die, and then you go "Oops!" And you build a better one next time. Really, in order to get to an industry where you have very good execution, very high accuracy of deliverable, very high quality control, what it takes is simply five or six hundred years trying fucking up, and then trying again, right? Until recently however, in software, the results of our fuck-ups are rarely lethal, and they're rarely destructive for entire economies, right? The pink box in the wrong place isn't going to destroy the world. The nose altitude of a 737 Max is gonna kill a lot of people.

We're making this software transition into the real world without yet having the engineering discipline, which is a bit of a problem. How do you fix that problem?

So we're making this transition of software into the real world without yet having the engineering discipline, and this is a bit of a problem. How do you fix that problem? There are a number of approaches to fixing that problem. One approach is to take and apply rigorous mathematical proofs in order to ensure that before the software is used in the real world, you know exactly what it will do. Exactly what it will do. Under all possible circumstances. And then you have a slightly better chance of succeeding. The other one is to throw the software out, test it under difficult conditions by having real people do real things with it with real money, and then when, inevitably it does crash, and people lose their money, you go "Whoops!" and you try again, and again, and again, and again and again and you iterate as fast as you can, improving. And you say "Listen, I know we still have bugs, I know there are still bugs in the code, but we don't have that bug anymore, that one, we fixed. There may be more, but I'm pretty sure that one isn't happening again" (laughs) We learned the lesson the third time.

Consensus critical systems

So how do you marry these two worlds? This is a very interesting concept, and it became much more serious on January 3rd, 2009, when Satoshi Nakamoto unleashed the software of Bitcoin onto the world. Now, a lot of people have asked me "What do you think of Satoshi Nakamoto's work?" And I say "That's the most brilliant white paper I've ever read." Nine pages, concise, insightful, predictive, just a brilliant scientific paper. The software?' (shudders) I mean, really? If there's something you can say about Satoshi Nakamoto, not a very good programmer. (laughs) Because as soon as that software was released, a whole bunch of much better programmers took one look and went "Oh, we'd better start fixing some things here because there are some nasty bugs in this software." And then an interesting phenomenon happens. And the interesting phenomenon is that when you operate inside consensus critical systems, what does it mean to say consensus critical systems? Systems that follow rules that cannot be changed, and follow them precisely while trying to synchronize across thousands of computers that are also following these rules. Systems like that, are very difficult to manage. And one of the reasons they're very difficult to manage is because, it doesn't matter if the thing isn't doing what you expected, as long as, all of the copies of the thing are doing the same thing. Which means, if you introduce a bug, and all of the copies of the thing believe that is the correct way to do it, well, now it is. Because someone went and put money against that bug, and now you've got to carry it forward. It's difficult to understand that to people who are not into software engineering, but again, the fundamental issue in software engineering is the computer does not do what you want it to do, it does exactly what you told it to do, even if you told it wrong.

Difficulty retargeting algorithm

Every 2016 blocks in the Bitcoin Blockchain, we go through a dance called the difficulty retargeting algorithm. The difficulty retargeting algorithm ensures that we recalibrate the difficulty of Bitcoin mining in order to achieve a ten minute target between blocks. It happens every 2016 blocks, and it takes the average time of the previous 2016 blocks in order to decide how much time a block should take. Oh, no, actually, it takes the average of the previous 2015 blocks. Why? Whoops! (laughs) So, Bitcoin on average, issues blocks at just a hair less than ten minutes. Why? Because there was an off-by-one error. An off-by-one error. If you're a programmer, you know what that means. It means that if you want to go to the third floor of the hotel, and the hotel numbers the ground floor as one, then the third floor is three. But if it starts numbering it at zero, then the third floor is actually two. And if you do that in programming, bad things happen. So there are bugs like that. What do we do about it? Absolutely nothing. We can't fix it. We can't fix it because it's the basis that every block has been calculated up to now. In order to fix it, you have to put a rule in the software that says "Until the block where we fix it do it every 2015 average, but from that moment of, after do it every 2016 average." Now, in order to make that fix, you've now introduced a five or six lines of code into the system, and you have to get everybody to coordinate and launch that code without fail because if some people don't launch that code out of that retargeting period, they're going to get the wrong answer, and they're going to end up on a different chain call it Bitcoin Slow. (laughs) Coz it's gonna issue blocks a bit slower and you're gonna have an inadvertent fork. So you have to have a massive coordination thing in order to introduce three or four lines of code to fix a problem that does it really matter? No, so, okay. For the rest of history, Bitcoin is gonna do that calculation wrong. When multisig was introduced, the multisig script had a bug in it, and it didn't work unless you had an extra item on the stack because it did one too many pops. Great, every single multisig script since then has an extra item on the stack. Why? Because the fix, was worse than the problem. Because actually creating a fix, again, massive coordination, and what do you do about the multisig scripts that have it versus the ones that don't have it, the ones that followed the bug versus the ones that didn't follow the bug how do you coordinate that everybody knows when the bug gets fixed, and then is it worth it? Coz maybe in the three lines of code you add to fix this problem, you have a worse problem, and now you have to add three more lines to fix that problem.

Writing code for Blockchains is very difficult

Writing code for Blockchains is very difficult. I describe it a bit like a ship of consensus that gradually has barnacles that attach to the hull, and these are the bugs that were introduced in the code and are now the rules of consensus. Did we mean them to be the rules of consensus? No, but they are, and so what do we do? We carry them forever because we need to be able to make a client sync even if it's never seen the Blockchain before, from the Genesis block, all the way to today without too many rule changes. It is an incredibly difficult environment to do software engineering, and none of us should know how to do this, right? I'm certainly not a good enough programmer to work in that space. I prefer doing this stuff. But there are even great programmers who make these mistakes, and it's a very difficult problem to solve. I think of it as a straitjacket of consensus. You may think that things that are not part of consensus don't matter, and in April of 2013, we discovered that a database bug wasn't part of consensus cause the 26 block fork divergence that was almost catastrophic for Bitcoin. Because even things that you didn't think are consensus, are now consensus. Very difficult to do programming in that world. There are two approaches to escape the straitjacket of consensus and to move fast. Well, actually there's three. One is, move slow. That's what Bitcoin does.

It's almost impossible to introduce change that will not be controversial

Move slow. It's a deliberate designed decision that says "This thing is now $100 billion aircraft with 10 million passengers on board, and we are trying to do engine maintenance while flying." You'd be very careful sticking that screwdriver in there, right? That's the engineering that you're doing on a live production adversarial global system on which hundreds of billions of dollars are riding. It's almost impossible to introduce change that will not be controversial, resisted, the cause of a fork, or potentially introducing a catastrophic bug. So, when people say "When are Schnorr signatures coming to Bitcoin?" When we've tested them, and then tested them, and then tested them again, and then tested them once more just to make sure, and then a hundred times more just to make sure again and we'll probably get it wrong the first time.

Difficulty bomb

There's another way of doing this, and that is, the method that Ethereum uses, which is, "Oops, hard fork." (crowd laughs) Oops, hard fork. In fact let's introduce a mechanism-- (crowd claps) Ah, I see. You think this is a criticism of Ethereum. (crowd laughs) No, You like that? - [Crowd] Yeah. - They introduced a mechanism that would ensure that hard forks must happen called the difficulty bomb, in order to ensure that you cannot stagnate core protocol development and consensus role development, that you force change, that you force coordination at least once or twice a year, in order to ensure forward momentum. That is not a bad choice. It's not a good choice. It's simply a different choice. And it has advantages and disadvantages.

You don't build it by magically being right the first time

Just like the choice that Bitcoin makes, which is very slow and conservative development, has advantages and disadvantages, and of course, the biggest disadvantage is that people can say, "Well, you haven't done anything in two years! Come on, do something! Schnorr signatures, something! Increase the block size! Let's throw some stuff out there, see what works!" That's not Bitcoin. Bitcoin is the state level robust system that resists. But that can be Ethereum, and in fact, it's great to have platforms that can move faster. And that means breaking things. A lot of people in Bitcoin hate that. Guess what? That's mostly the finance culture talking, because the software engineering culture in Bitcoin does not hate that. They see the necessity of introducing rapid change and iteration because that is the way you build a bridge that doesn't fall down. That is the way you build a dowel that doesn't get drained and hacked in the first week of its operation. You don't build it by magically being right the first time. You build it by being right non-magically the twenty seventh time, and assuming that the twenty six times when you lost money are okay because they're part of the experiment.

The Lightning Network

That is a valid choice. And to conclude, I'd like to introduce something for you to think about a bit which is why I'm really excited about the lightning network because the lightning network introduced another valid choice, which is now generating the most rapid development model for Bitcoin that we've seen in the past six or seven years. And that model is "Hey, let's just leave the security to the slow moving very very conservative core protocol, and let's do all of the fun stuff on the layer above." And what that means is if you have five different lightning network nodes that are operating within the standards, all they have to do is agree on the basics, and they can go explore things that the others don't agree on. They're not operating inside the rules of consensus and suddenly, within the lightning development community, we have now seen a completely different culture emerge and flourish.

With a few more great ideas, approaches, and a bit more courage, we are finally going to develop the kind of engineering culture that even bankers can respect

Check out how developers work in lightning versus Bitcoin, and you will see a culture that is much more like Ethereum, where things are moving fast, where companies are trying new techniques, and new solutions that are not necessarily synchronized because they don't have to be. So, option number one, do it on the base chain very conservatively. Option number two, force continuous change on the base chain until you can iterate fast enough to keep fixing bugs, and now, option number three, keep the conservative development on the base chain, and move all of the rapid development one layer up where you now can play with a bit more freedom and flexibility because you've left the security for the protocol that does the security right. And with a few more great ideas, approaches, and a bit more courage, we are finally going to develop the kind of engineering culture that even bankers can respect. Thank you. (crowd cheers) Thank you. (mellow music) - [Announcer] If you enjoyed this video, please subscribe, like, and share. All my work is shared for free, so if you wanna support it, join me on Patreon. (mellow music)