EB95 – Adam Back: Why Bitcoin Needs A Measured Approach To Scaling

Transcript

[Music] This episode of Epicenter Bitcoin is brought to you by voltoro.com, the goldto bitcoin exchange. Trade gold to bitcoin instantly and securely starting at just 1 mg. Go to voltoro.com to deposit some Bitcoin and start trading today. [Music] Hi, welcome to episode Bitcoin, the show which talks about the technologies, projects, and startups driving decentralization and the global cryptocurrency revolution. My name is Sebastian Kua and my name is Brian Fabian Crane. We're here today with Adam

Bach. Adam Bach is here the second time on this show and of course many of you will be familiar with Adam Bach. He is the inventor of proof of work or of hash as it was called then. And uh so he's he's one of the few people who were cited in the original Bitcoin white paper and more recently he's been involved in with side chains and spec specifically blockstream where he's the president and founder and he's also been very vocal in the whole debate about uh scaling Bitcoin and about increasing the block size and if that should be done and how it should be done. And so we're super excited to have him on because so far we've sort of had a little bit too much uh we had a lot of one side on

which is Gavin and Mike and we haven't so much the the guys taking another viewpoint on and and today we're having Adam on to to fill that role and talk about a lot more. So thanks so much for coming on Adam. Hi thanks. It's uh good to talk with you guys. Absolutely. So you know when we talked about the topics a little bit before you said something interesting and I think that might be a good way to start. So you mentioned that well it's also important to talk about what Bitcoin actually is and and of course I don't know if we had that question asked in that podcast. was always sort of presumed uh that you know people knew but why

don't you share what you see like what do you see in Bitcoin and what would you like to see in Bitcoin? Yeah, I mean it sounds like a silly question, right? What is Bitcoin? Because people have been very enthusiastic and using it for a number of years now in the increasingly in the in a mass market and all kinds of interesting applications. But um you know there there were a number of other electronic cash systems before Bitcoin. Um you know we also have PayPal and things like that. Um, and I think you know a lot of people may not uh have the history of it but uh as far as I understand it PayPal started as a bearer

electronic cash protocol. So something much more Bitcoin like on Palm Pilots and kind of migrated presumably for practical reasons um into a kind of central web service where the web service has your balances and can therefore apply policy to them. And you know, PayPal is grappling with complex issues and attempts at fraud and uh civil attacks and gaming their systems. So they have to they ended up in a situation where they had to apply policy and of course there are false positives.

So there's a kind of ongoing gripe about um uh you you'll hear users who are complaining that PayPal froze their money and it took six months to get it back. And you know, more often than not, the user didn't do anything particularly wrong. They just tripped over some kind of semi-automated abuse policy. And so, one thing that's exciting about Bitcoin is it's um decentralized. So, there's no central party that can, you know, that has to or can apply policy to your ownership. So, you know, if you have uh electronic cash, I would say generally speaking, means that you should be in sole control of it. It should be the electronic analog of, you know, paper notes in your pocket, Swiss

Franks or British pounds or US dollar notes. And um there's there's nobody that can sort of, you know, make a policy decision and the bank note in your pocket with a given serial number stops working. And in fact there are very good reasons that this shouldn't be the case because if um if people are in doubt as to the validity of their notes they they get very worried and try to take them to the bank as fast as possible. So this is the concept of fungeability and it's a long established principle that electronic cash system it's very important that it be highly fungeible. Um, and it this this dates back to presumably there are other uh

precedents in other countries, but one of the early ones was a court case in Scotland um in the 17th century where a a wealthy merchant sent, you know, some very large denomination banknotes to a business contact and he was quite worried. He sent them in the post and he was a little worried that they would get stolen in transit. So, you know, he made little marks on them that he would recognize. So, um and uh unfortunately the notes didn't arrive and so, you know, he reported the problem and eventually turned up at the bank and so he sued bank he sued the bank in court to get the notes back and uh that that arrived at the president. So, the courts

eventually decided that uh no, it it was more important that the currency remained funible than this this particular merchant be made whole. um and their their reasoning is quite interesting which is that you know the economy and confidence in the money as a unit exchange would be seriously damaged if if the reverse decision would be made. So and also you have this general problem that money changes hand many times and the uh you know this the discovery of the crime or the fraud is often delayed. So, you know, if you if you if if somebody robs a convenience store at gunpoint or something and mix off with some high

denomination notes and they circulate through the economy a dozen times and you end up with one and you tried to deposit at the bank, chances are that that was nothing to do with you, right? So, it's and and the crime may not be reported for a you know, a day and the investigation takes a while. So the general principle is that electronic cash should be fungeable and then the other interesting thing is that um you you get with bitcoin a kind of permissionless innovation. So you know any anybody can uh any any startup or individual open source developer or power user can uh pick up some open source software and start writing

applications. So there's an analogy people draw between um the early early days of the internet. So before the internet there were uh various large telephone companies. Some of quite a number of them were uh government state-run monopolies. And in order to bring to market a new telephon application, you would have to go and negotiate a you know a a contract with a very large company. And they may easily say no. for example, if they thought it competed with one of their strategies, they might say no. Um, and so on once we had the internet and open innovation and many startups and individuals playing

with open source software and, you know, communication applications, we we got where we are today with, you know, everybody really enjoying the internet and all the things it can provide and a very fast pace of innovation. Um and so one of the exciting things about Bitcoin is that it's open for innovation. And if it you know let you know if you run a thought experiment what if um at the beginning Satoshi has not been anonymous and he had gone and obtained some venture capital money and started Bitcoin.com.

Um chances are Bitcoin wouldn't exist today. Right? first sign of any kind of political controversy in its early days and that company would have been shut down and there are nu numerous precedents. So uh digash went through a process like this. This was an electronic cash company using cryptographic protocols that are the central server analog of things like uh zeroache. So David Chum was a cryptographer that invented um blind signatures with applications for electronic cash and he started a company at some at some stage the company set up a demo server without even a connection to the existing banking system and the Dutch banking regulator called them in for questioning

to say you know you can't just be standing up banking related services like this and requested them take it down and nevertheless there were people who were trading these coins just with a viewpoint that if people sold small things for them, they might create a floating value because DigiCash had promised that the demo server, they would only ever release a million of these beta bucks and they had a foreter. You could email them and they send you a few a few coins to play with. Um and so there was a bit of trade and there's a kind of uh um analog of how Bitcoin bootstrapped in that story but unfortunately um Digicash went bankrupt and so people had coins but they were

useless because the central server went offline. Um so you can see in like these three stories that um decentralization is is basically the distinguishing feature of Bitcoin and why it succeeded where the other systems didn't. Now, you know, Digicash went bankrupt. Everybody lost their coins. PayPal became centralized. It lost its bearer e-cash properties. And they're grappling with ongoing abuse problems that have, you know, fallout for users and um it's it's prone to sort of account seizures and uh you know, six monthlong kind of arbitrary dispute resolution processes. And presumably if you want to, you know, PayPal may be a

fairly forward-looking company, but some companies uh tend to act in a proprietary way and will not give you access to their APIs. You know, there are examples of startups that started out with an API and then they felt that got competitive to their existing product line or they develop a new product line and they closed the API. So you're really if you end up with something that's centrally controlled, you um you're ultimately beholden to the good behavior of that central control point. And so kind of summary level to thing thing to say about all that is that you know decentralization is the key differentiary of Bitcoin that allowed it to bootstrap and you can build centralized things on top of

Bitcoin. So you know there are many hosted wallet services like uh blockchain info, circle, coinbase and the various competitors and they're relatively centralized. You know they have in some in various forms custody of your coins and they can and do apply policy to them at times. So those are examples of centralized things. You can certainly build those on top of a decentralized system but you can't build a decentralized system on top of a central system because it doesn't make sense, right? So I think what what we need to do generally speaking is to hold on to and make sure we retain the decentralized nature of Bitcoin and its permissionless properties. Now of course

there's a question of scale and trade-offs in there. We can certainly make trade-offs to you know improve scale um and balance that against security and decentralization. And that that's really what the current uh discussion in the public uh amongst the technical community is about. Right. So I think you you touched on an interesting aspect here, right? I think the aspects of permissionless innovation. I think we've talked about that so many times and there's like there's no question. And I think that that is just revolutionary and has so much there's so much potential there and it's really something where you know other systems just can't compete with an open system and

decentralized system like Bitcoin and yeah I think fungeability and and and that sort of cash right I think that's actually very fitting that in the white paper you know how much he emphasized the role of this is electronic cash uh as opposed to you know some I don't know some settlement network or payment system or something like that. Um I in my view actually probably most people would agree with you like most people in the Bitcoin space in the cryptocurrency space would agree with you that those are you know fundamental critical uh features of Bitcoin and that those should be preserved and guarded. Uh at the same time, you know, what we've seen

with the block size debate is there's been a lot of disagreement and a lot of sort of heated controversy, people being also quite rude with each other, I find. So obviously even if one agrees with some of these large principles and then I do think there's quite a lot of agreement there in the community that doesn't necessarily help with the actual decision- making and and this is a conversation that we've we've started having more and more and we're trying to start to have more. So how do you think that decisions should be made? I mean you've mentioned some principles.

Do you think those are anybody should hold them? What if people disagree with those principles? What is your what is your view? How should basically decisions about where Bitcoin is going to go? Who should make those decisions and how should they be made? Right. Um so I I just step back briefly to the So I think if you're talking about sort of requirements and properties of Bitcoin, there's generally relatively wide agreement. Um and when you talk about scalability, you know, clearly everybody wants to scale Bitcoin because in in the security main domain like internet security domain, there's a concept of delivered security, which

means, you know, um the amount of security you deliver to users is based on the amount of security you deliver to each user multiplied by the number of users that manage to use it and benefit from it. So it's uh I mean that that introduces all kinds of things into security considerations. For example, it should be usable. It should scale because you know it's it's also not interesting if only you know a few hundred or a few thousand users can benefit from security. So sometimes PGP gets criticized on this basis because it's difficult to use or you know bitcoin also I mean there are millions of users of bitcoin but it can also get criticized that well it doesn't scale very far right now um you know with the

current parameters and uh sort of security scale tradeoff you have you know seven transactions a second or thereabouts. Um and while that's you know generally that that adds up to quite a lot on a yearly basis and the blocks aren't actually full now and uh you know Rusty Russell did some statistical analysis to show that I think it's 45% of the transactions in those sort of 13 to 40% full blocks are less than a dollar in value. So you you could probably make a reasonable argument that um the people that

potentially you know if if you are transferring very small amounts of money change tip or or something that is for tipping or you know moderately centralized but if it's you know if policy if policy crept into it and somebody seized you know a couple of dollars on change tip for most people that wouldn't be as concerning because they could switch to a different tip. service or a different hosted wallet. Whereas if Bitcoin itself um became centralized to that degree, it it would present a problem. So right, so I mean I think if you if you if you look at it that scaling is a trade-off between security as it relates to

decentralization and scale, um the sensible thing to do is to pick some kind of pragmatic starting point. Um, and so we've had a number of proposals. So, you know, there's Jeff Garzik's BIP 100, uh, which which was published first, and then a little bit later, Gavin's BIP 101. Uh, Jeff did a BIP 102, which is a very simple one that's just a 2 megabyte block size. Um Jeff's Garzix was kind of similar to Gavin's in some ways but had some minor voting uh which he he proposed as a a form of balance so that the block size wouldn't you know

automatically grow but the miners would have to collaborate to grow it as it made economic sense kind of thing. Um and then there's more recently bit 103 from Peter um which is using the Cisco scaling numbers and also has another sort of uh more minor advantage and the other quite interesting one is by Greg Maxwell and Mark Friedenberg which is um the flex cap proposal. So and and that is allows a bursting of block sizes in in reaction to you know sudden demand and also for miners to pay for bigger blocks. So you know if if the blocks at a given point

in time are too small to meet the demand uh that means there are excess transaction fees that are left on the table. So if miners can see that you know if there's uh excess transaction fees they can collect and they have a mechanism to pay to increase the block size they can increase their profitability and solve the scaling problem. Adam, let's let's wait for a second before we go into that discussion and let's talk about how the decisions actually will be made because cuz right now when you talk about BIPS, right? So when you talk about BIPS then uh you know those are basically sort of proposals you know pull well they're not pull requests I guess but there's sort

of outlines of changes to be made and then they might be integrated in Bitcoin core right but then one of the interesting things about Bitcoin is that the the in the end the software you know Bitcoin core of course it has a lot of weight because that's what most people use. But in the end, what matters is, you know, the software people run. So, so how how do you think of those two? Do you think is the right way to try to discuss what's the right BIP to do and then integrate that in Bitcoin core or or is it the better way that maybe some people say we won't go that way, other people say we want to go that way. you

know they have different implementation software and then you try to convince the miners and the wallet providers and exchanges to switch to you know uh yeah how do you think about that right so um there is I mean you know not not everybody's aware of it because it's a kind of uh small technical community but there is a a relatively formalized BIP review process and is described. So, BIP, Bitcoin improvement um proposal and BIP one is a kind of charter and uh framework for how BIPS will be you know so there's a

there's a process for how BIPS will be will go through from sort of outline review so I mean the process specifically is you you discuss on a bitcoin development list um your outline of of an idea of how you think something could be improved. That could be scalability or it could be a new feature or what have you or or you know a bug fix and then there is a review discussion and if it's you know if it's not obviously broken or defective then there's a BIP number assigned and then you specify in more detail. You provide a draft implementation, there's testing, and then there is a a a planning of how to deploy that. And all of the changes

so far have been soft forks with the exception of a sort of accidental hard fork that was fixed uh in a rush basically to a much earlier time. Um and so with a soft fork, you you have miners bringing it in, you know, uh triggering it. Um so soft forks are backwards compatible and you know this to to change the scaling in this way. Um it's a hard fork and it's the first planned hard fork. So a lot of people may not realize that a soft fork like the average time from a soft fork starting to be deployed in the network until it triggers and becomes active is 6 months.

So, you know, so BIP 66 was the most recent one. And um upgrading a Bitcoin network is is potentially a high-risisk thing. And in fact, the BIP 66 uh nearly when it when it finally triggered nearly created a network fork. I mean, in fact, it did create a network fork. It was just that people manually fixed it. So that that kind of illustrates that even something that everybody is agreeing with it's you know just fixing bugs and adding features even that can potentially go wrong. So um on that basis you know it's it's far lower risk if everybody agrees on a way forward and works together to try and make it happen. So the the other thing to say

because there also seems to be some confusion in the wider uh Bitcoin community is the difference between a software fork and a network protocol fork. So of course in open source software it's it's known that people can fork software and it's encouraged. You know that's why there are open source licenses and GitHub makes it easy to fork things. And the idea there is as you said just a moment ago that you know if if some group of community of users decide that you know a particular user interface skin or a focus on a different feature set is interesting they can go right ahead and do that and whichever one becomes popular that will tend to win in the market. But typically there's no you know it's it's not a binary

decision right both both versions can exist in the market and compete and users can use them based on their preferences. Now, unfortunately with a blockchain, it's not really a software fork that's concerning. You know, we already have lots of different pieces of software that could connect to Bitcoin. Many different wallets actually also different implementations of Bitcoin core and that's just fine. But yeah, a network fork is essentially a new altcoin. uh you know yeah I mean that's that's one I mean that's that probably wouldn't uh be a very popular thing uh a way to express it to some people but um it's it's certainly the case that having um you know that that Bitcoin's

consensus model requires all of the nodes in the network basically the vast majority of them to run a bit a bit wise compatible protocol version. So you mentioned the BIP uh process and there is some formalization around how that that that occurs. Now with regards to some more um controversial changes like the block size, right? You know there are multiple BIP bips uh trying to address this uh which come from different perhaps ideological uh background. people coming from different ideological backgrounds

or having different visions of what Bitcoin is or what Bitcoin should be. In this case, it doesn't seem like a clear process of how to implement the BIP would help in establishing consensus on what um what we should do. You know, we have to come back to the to the I guess higher level discussion of what Bitcoin is or what Bitcoin should be. how how can we come to consensus on these sorts of decisions? Um so I mean I think there has been some you know because of the nature of online discussion forums and you know Twitter is a very concise communication mechanism and people on Reddit sometimes

get into some kind of heated debates and people misread nuances in online discussions that maybe wouldn't arise in a facetoface discussion. Um there is tended to be this sort of you know black and white thing that it's claimed that you know particular set of core developers don't want the block size to change at all. They want to keep it at 1 megabyte and somebody else wants to increase it. But that's uh significantly a miscatategorization I think because um you know for example Greg Maxwell has proposed flex camp which is a way to increase scale via increasing the block size. Peter will proposed another one that increases the block size. Jeff Garzik has proposed another one and Gavin has proposed another one and I proposed a couple myself as well. So,

you know, it seems that pretty much everybody wants to scale Bitcoin. The question is it's really complicated and we're not, you know, there is no silver bullet. So, what what we're what the technical community is trying to do is to figure out which is the sort of pragmatic, safe, secure way to do this. Um and I think you know outside of um so just in evaluating the bit process the the bit proposals that's a discussion that you know frequently can and uh happen in within the Bitcoin development bit process you know I mean that's that's happened many times in the last four years and many complex new features

and security defects have been fixed in that way and so there's no reason to suppose that couldn't be continue to be the case. Um so another another concept that's been put forward is that um this this concept of whether it would move faster if there were one person who were the final decision maker. Um and I think Mike Hearn was the first person to propose this. And I think the danger with Bitcoin is that um there's a lot of other people's money at stake, right? So there's you know $4 billion economy and you know as we go forward into the future if if Bitcoin sees adoption in

certain segments you know for international settlement or as a gold a competitor to gold or something that could turn into a $4 trillion economy and if you if you turn around and think for a few minutes about you know would you personally like to be the final arbiter I think you'll find the answer would be no because you would be subject to you know immense amounts of international pressure, potentially blackmail, you know, people bugging your equipment or trying to sabotage and if you have children or something, you might be worried they'd be kidnapped. You know, even governments and central banks, central banks employing like noble warrior economists struggle to, you know, um avoid moral hazard and pressure influence of pressure on them.

So I think Bitcoin's like attempt to avoid those kind of you know security risks or another kind of risk is that a particular individual may have a hidden agenda or be working for you know a criminal organization or a foreign government with a a conflict of interest or something that if if there's a peer review process where a group of diverse people have to review changes and approve it. That's the best we know how to do in terms of avoiding, you know, those kind of influences creeping in.

So, of course, with Bitcoin, this is what's so different than from other open source uh projects is that there's so much at stake uh sort of immediately at stake and and directly at stake and but so it it seems like I mean the the benevolent dictator model may be uh difficult to implement for Bitcoin. However, the BIP process only seems to take into account sort of technical um considerations and is very much centered around the technical community and the and the core developers. Uh and you know there's also the voting with mining which does also include other industry actors um opinions but not all of them only the

miners not for example like payment processors or companies providing uh services to to Bitcoin. What what do you think about like creating a a working group uh in the uh internet engineering task force for instance or like like we do with HTML or you know other network protocols where there's an actual working group of people coming in from the industry and different industry actors weighing in and a a real review process um which takes into account everybody's considerations right I mean I think that's basically what the bit process tries to do and you certainly see uh So, we didn't talk about this just now, but there is a um a workshop like a technical workshop uh in

Montreal on the 12th and 13th of September which is basically a a physical meeting which is a continuation of the BIP reviewer discussion evaluation process. Um and there are certainly many many types of people going there and there are something like 14 15 sponsors like commercial sponsors on the website and and also academic sponsors and there are a range of people there you know from u Bitcoin technical enthusiasts to companies sponsoring and sending technical people from academia people from the mining community all present to have this exact discussion and you know while the the uh cord developers have to implement things.

They would also be the first people to tell you that they are not there to make decisions, you know, um that affect users. They're there to do what the what is in the best interest of the users and to hear and balance the sort of requirements from different constituents. So I think the main thing to keep in mind is that you know it's it's a trade-off between security and decentralization and there are multiple parties involved. There are users and Bitcoin ecosystem companies and miners and if you favor one thing one particular feature you will disadvantage somebody else right so you know miners profits will fall or something.

It's time for a word from our sponsors, voltoro.com, the gold to Bitcoin exchange. Now, we all know there's been no shortage of Bitcoin exchange scams and hacks in these recent years. And that's why when Philillip and Josh, the two brothers behind Voltro, decided to start that exchange in the wake of the Mount Gox disaster, they wanted to do things differently. So they're really pushing the bar forward and innovating in terms of security, transparency, and auditability to ensure that customer funds are safe, secure, auditable, and so that there's no there's none of this Mount Gaus, you know, stuff going on.

It's all on the up and up. So if you've been listening to the broadcast, of course, you know Voluro and perhaps you like Volto and you like what they do. Well, something new is happening. Something really exciting is happening and that's Voltour is doing an equity crowdfunding campaign through Bank to the Future of Sammy Dixon who of course you know as well by this point. Uh so if you're interested you now have the chance of actually owning some equity in a startup which is sort of a new thing equity crowdfunding and not just a startup but a great Bitcoin startup a great startup in the space and you can even invest with Bitcoin. So if you're interested check it out that's on Bank to the Future. So bnktothe future.com and of course we'll put a

link in the show notes and we would like to thank Volro for their support of web center of Bitcoin and hope they're going to have a fantastic crowdfunding campaign. Adam. So, of course, this all sounds good and sounds reasonable, right? But like what then happens? Let's say in this in this example that we've been talking about with variety of different bibs uh about increasing the block size. What happens when people just can't agree? You know, there there's positions that just can't be reconciled. There's no consensus can be reached. What happens then? Does that just end in a in a stalemate or or is there some process then to go after that that will actually

resolve situations like that? Well, I mean I think it's the you know the task at hand is complicated and so there is also a value to um not acting in a hasty or rash fashion, right? because you know there's nothing worse than rushing a change and breaking Bitcoin you know accidentally introducing a bug or something. So um but I do think that you know there are plenty of prior examples of complicated technical discussions within Bitcoin that reached a consensus and something got implemented. But what if no consensus what if no consensus is reached here?

Uh I don't think we're there yet. And and also I think that Right. But but let's just if you stay on the governance thing, right? Then it doesn't matter whether we'll reach a consensus here or not because I'm pretty sure that there will be lots of decisions about the future of Bitcoin where no consensus will be reached. And maybe with the block size thing, you can say that's really a an engineering question, right? So because personally I agree with you. I think everybody wants to scale Bitcoin. I don't believe Blockstream wants to keep it intentionally small. I think that's idiotic and I think just as much Mike Kern and Gavin know all want to scale Bitcoin and they also want to keep it decentralized. I think everybody

wants to keep it decentralized but people disagree, right? But then let's say in the future maybe there are things where actually people want Bitcoin to do different things and that's why there's no agreement. So there needs to be consensus is not enough, right? It's not going to you you won't be a we won't be able to reach consensus I think. Right. So I mean I think there are there are some short-term and some longerterm trends that help this. So um you know to to be clear that side chains arose significantly before blockstream right and in fact the reason I became interested in side chains is because when I got interested in Bitcoin and caught up with all the protocol details

then I tried to find ways to improve Bitcoin and I'm from an electronic cash cryptography background. So I found a couple of ways to improve Bitcoin's fungeability and privacy and things like this. And so then I said, you know, went and talked to core developers and said, how about implementing this? And it became apparent that, you know, because what I was asking for was like relatively complicated, you know, somewhat high risk because the amount of code involved, they were quite interested in the features, but it was very difficult to implement them in a really short period of time. And that's basically a symptom that you know the core protocol is about providing a secure and usable base um that people can build things on top of. So you could

think of it maybe a bit like TCP IP or something. You know all all the internet stuff is built on top of TCP IP and a TCPI basic protocol once the basic R&D was finished has like pretty much been static for decades, right? So once I discovered this problem, you know, as many other people have encountered, right, that that Bitcoin uh does, you know, does have a fair amount of for progress. There's quite a lot of code being written. Interesting new features get in there, but it's, you know, there's there's a sort of bottleneck around security assurance and careful validation um and focusing on the most important things first to ensure Bitcoin security and safety. it doesn't uh progress as

fast as general you know like internet stuff that people are accustomed to and so that's where I started focusing on okay well how could we uh you know add a layer or a way to do this faster and that's what side chains are it's a way for different people to work on different features independently and without them having to be in Bitcoin core so sort of layering so that you do things at layer one instead of layer zero and um you know So to take this specific example, you know, if if some of these extension generalized extension mechanisms that allow people to implement novel features or features that maybe not even mutually compatible in parallel, you know, if that kind of

extension framework, which might be side chains or extension blocks or something proposed by other people, if that were implemented before the block size, you know, before we got close to some kind of scaling issue, the answer would have been quite different, which is somebody would have used the extension to make a higher scale opt-in uh extension for example right so I think the the further future is more clear right that in I think in the future it's reasonable suppose that we will have additional layers uh with with extensibility and also additional ways to get to scalability like lightning which preserves bitcoin's properties um so and I think the way to bridge where we are

now is to focus on shorter term simpler solutions. So something that will create the time and space in scalability terms so that you know we don't have immediate scaling problems for for the technical community to develop and validate those features you know to for example see the lightning scales. Adam so let let me just paraphrase if I understand this correctly. So I mean I think in the long term what you're talking about I mean I think the the side chain's vision has always been compelling right it's always been compelling that you can have like sort of this innovation with different chains and then move the the bitcoins there so you you have the some of the

same network effects the same value etc. So that has always you know at least from sort of a big picture been in a compelling way to go about it and I do agree that you know once side chains are implemented and functioning etc that this does partially solve the the issue of reaching consensus and and adding new features and stuff right because you you can do it on the side chain and then where you don't have to get the agreement and just users vote with with their coins and and with their usage so That makes sense. But then when you talk about the, you know, the core Bitcoin protocols, I mean, of course, the implications of what you're saying is that then you think the core Bitcoin protocol should basically, you know,

remain the way it is or do as little make as little changes as possible. Um, and then we still have the issue, right? What about those changes? How are those decisions made? Yeah. So, and I wouldn't say as little as possible. I would say as much as is safe and you know it's there's been a lot of changes that have gone into Bitcoin in the last year even to do with scalability for example the lip sec 256k1 uh that Peter Wüer and Greg Maswell worked on which increases the uh digital signature validation speed by a factor of six to eight and when you're talking about scaling Bitcoin you know if if it weren't for that work um increasing the

block size you wouldn't actually help because the CPU would be the bottleneck. So, you know, there there is progress. There are new features. You know, there's check lock time verify coming in soon. There's version bits. There's a bit on relative check lock time verify which helps lightning um become more efficient. And you know, looking backwards in time, there are quite major new features such as the P2SH feature. So I I wouldn't want to characterize it that Bitcoin doesn't progress because there's a lot of you know interesting features and a lot of progress happening but just to say that you know it's it's interesting to try to structure Bitcoin in the longer term such that there is

there is a base that has core required features and then there are other layers that allow people to do things more quickly. So I mean you see it right now already in the sense that you know there are existing layer one things if you want to look at the hosted wallets as layer one and the bitcoin exchanges and the applications that are built using bitcoin's p2sh features like you know trustless escrow or uh trustless custody and trustless exchange all these kind of things are built on top so what we want is the core to be flexible enough to allow people to build things directly on top and also for the core to be flexible enough to allow people to extend Bitcoin. I mean, you know, if if you look at Bitcoin currently, one of the

problems is it is a one-sizefits-all, right? So, you know, you've got you've basically got to trade off the interests of different people who have uh you know, so miners want to maximize profit and collect fees. Users would users and merchants would prefer low fees. So, they they can't both have what they want, right? So, what ends up happening is is a general compromise. And you've got people that want to scale Bitcoin like m microp payment scale and maybe you know trade off a fair amount of uh decentralization to get there. And you've got people who really value the decentralization and uh permissionless features that you get from that. Um and so again you can't you know you can't swing to one extreme. You've got to

you've got to do some kind of balance in the middle. So you mentioned decentralization. I'd like to come back on this because we mentioned it earlier. Uh and one thing that's sort of interesting about decentralization is that uh unlike centralization, you have to keep fighting to keep it. I mean, and this is true in Bitcoin, we we see that the Bitcoin community keeps trying to keep it decentralized, whereas you can have a central system and it will stay centralized as long as you want it to. Um, now that's sort of one of the core values of Bitcoin and we recently had Stefan Thomas on who argued that the the decentralization was not an end in itself that what was important was censorship resistance uh and security.

Do you agree with this? Yes, I mean that's that's true but uh decentralization is the only way we know how to do that right now and and also to say that you know there are specific electronic cache protocols. I mentioned uh in a pre- discussion and I think just earlier the electronic cash protocols of David Ch. So he was the first person to uh formalize this and that actually has much more robust fungeability sort of cryptographic fungeability than Bitcoin but it's centralized and you know basically I think that illustrates the point because digash is long bankrupt and everybody who had digash coins lost them and bitcoin is here and running today and kind of reached a much you

know reached masscale adoption where digash was unable to um and similarly the other use the other sort of story that I describe ried to was PayPal which went from um a sort of bearer electronic cash concept and ended up with a centralized service that succeeded but is you know a frequent complaint amongst users is the arbitrariness of the kind of uh free account freezes and things like that. So you know centralized things are inherently vulnerable to um policy choices by the centralized party by you know permission seeking in order to do any innovation on top of it. They can cut you off anytime they want and we

see that frequently in the you know wider uh internet ecosystem. Um, so I think you know as I said earlier that the decentralization is the key differentiator for Bitcoin and it's always easy to build centralized systems on top of decentralized ones. So to give an example I mean there's there's no reason why for example the major bitcoin hosted wallets. So many of them already provide inservice netting which is to say you know if if we're both users of let's say circle and I pay you that transaction doesn't hit the blockchain and the same for two users two users of coinbase but you can go beyond that and say that um these services could provide

netting between them. So let's say you know Coinbase and Circle they allow users on to pay users on the other system. So if I'm using Coinbase, you're using Circle, and I want to pay you, Coinbase and Circle could send themselves a private message about that, and once a day when the transaction balance had netted out to like a million dollars or what have you in either direction, they could send one transaction on the Bitcoin chain. And that would allow, you know, the various hosted wallets to collaborate and scale very well, right? And that that would cover presumably quite a large percentage of Bitcoin users. So that's something that's open today. Lightning kind of does something like that in providing a right caching layer for Bitcoin that actually preserves the

decentralization properties of Bitcoin um and and could make that kind of you know sort of generalize that in a way that you less have to trust the hosted wallet service. So it's sort of interesting how what you're proposing essentially looks a lot like how banks uh you know settle uh their their balances between themselves. So um on on decentralization there's one other question I want to ask you. So you know we we look at different things to see if Bitcoin is decentralized or not. You know mining pool number of mining pools number of full nodes number of wallet implementations.

um what what is the most important metric or what are the the most important metrics to um properly identify like how decentralized Bitcoin is or isn't. Yeah, it's it's a really interesting question because um you know un unlike conventional security measures where you can say you can fairly accurately measure the amount of effort that would be hypothetically needed to you know brute force a key or something which we understand quite well at this point. Um the decentralization metrics are you know there are a number of factors and it doesn't translate into a single number but nevertheless there are

you know a number of indicators that Bitcoin decentralization is you know it's still functioning reasonably well but it's a bit of an E right now. Um and so if you look at the main ones, you've got um the number of pools or you know self miners or vertically integrated miners and their percentages. So you know there are a number of um quite high percentage hash rates pools and vertically integrated miners such that you know arguably it would only take you know a a policy decision by maybe three to six of them to sort of fairly effectively implement a policy. I mean

part of the way that Bitcoin achieves um policy neutrality is that there are different people who will process a transaction. So you know potentially even if 75% of the hash rate um wanted to sort of freeze or block uh a bitcoin payment you know say say uh Wikileaks had received a payment and somebody wanted to stop them spending it let's say um now still the remaining 25% would eventually process the transaction. So it would just be delayed not blocked. Um but nevertheless there is there is a degree of c centralization there. And it's it's uh I think much much more centralized than people would have hoped

if you'd asked about this. You know a couple of years ago people didn't really foresee how centralized things would grow once pooling kicked in. And also another kind of metric is the number of uh ASIC manufacturers that are selling direct to the public or to you know small businesses or people that would buy $10,000 or $100,000 worth of mining equipment and put it in a in a small warehouse or in a garage or something. Um and the number of independent ASIC manufacturers is I think decreasing. You know, there are still a couple that will sell to the public, but there are also more that have turned their attention to vertical integration or have merged or been bought and a few that have gone

bankrupt through of sort of poor timing in the market of, you know, a weak price and a late delivered product or what have you. Um, and so those are two interesting forms of uh decentralization. Another very interesting one that people are I think largely not aware of which is actually behind some differences of opinion I think at protocol level is this concept of running it in uh a full node of an auditing node and so the percentage of um economic in the economic interest in the network that is validating transactions that it receives via its own full node and I think we're seeing

evidence that that is falling as well and that that is an interesting and necessary part of the Bitcoin security picture that the proportion of economic interest in the network should that that is you know relying on a full node that it's under its control or trusted by it should be real you know relatively high. if if it falls too low, there's no longer a security assurance for uh users because you know the miners are providing a service to users and particularly for SPV users and if there are no no auditors there's no kind of checkpoint there's only miners uh sort of you know balanced against other miners. So that's to say you know if we

have a lot of you know a very high ratio of economically dependent auditors we can tolerate a more centralized um ratio of large miners and vice versa because you know miners fighting against each other for sort of vying for block rewards partly hold each other in honest because because of the sort of policy of not building on top of uh incorrect blocks. That's a consensus rule, right? But what makes that a consensus rule is partly that auditor, you know, full node auditors are looking at that. Um, and I think I see in some of the, you know, more aggressive block proposals um,

articulation of uh, sort of less emphasis on the importance of full node auditors. I've seen people be, you know, potentially quite content for full node auditors to over time be only possible in data centers and increasingly, you know, high bandwidth, more expensive data centers. Um now of course you can't like constrain the network so that only somebody on you know a dialup or uh you know a GSM modem or something really low powered and with you know a Raspberry Pi or something that that would be too constraining and you know might already run into troubles but it's it is a balance and you do want to make it easy

and you know not too ownorous to run full node auditors because you want you know the majority of uh medium-sized and power users and so on to run full nodes to assure themselves more robustly about the security of the system and actually the security of the system as a whole benefits from that. It's not just something they do for themselves. They they run it for their own security. the fact that they run it for their own security holds the system secure because they would reject payments that didn't check out from their full node and that information would flow back to you know the SPV users that sent it to them for example. So I think that's actually one of the if you boil it down, you know, going from the requirements about what

Bitcoin is and why decentralization and permissionless is a is a key component of it and you translate that into okay, what are what are the mechanisms that make Bitcoin secure, then this the importance of full nodes and a decent ratio of full node auditors. So it's not just running a full node. If you just run a full node in a data center and you don't do any transactions, that's actually quite useless. So it's not the number of nodes, it's the amount of economic interest that is relying on those nodes and has sort of direct trust or control of them because that's what holds the system secure and validates you know a bigger percentage of transactions to a higher level. So the things that tend to degrade that are you

know uh block sizes getting more full um uh CPU validation getting bottlenecked, memory getting bottlenecked and also companies outsourcing running full nodes to third parties or um running their entire Bitcoin business via an API from a third party because then that kind of audit is done by them. You know, having said that, there are there are trade-offs in that some of this software is relatively technical to run and you know, if a very small startup doesn't have the expertise, it can be more secure to outsource it. So, it's a balance, but I think ultimately we do need quite a high proportion of full nodes. So, again, it's a balance. Adam, do do you think there's any way of

getting that back? because it it seems like already today it is for the vast majority of at least sort of individual users maybe not business users running a full node it doesn't I mean people aren't doing it right because I mean I I've tried it and I I I used to run a wallet with a full node and and it's just uh I mean I use a laptop and it just doesn't work you know so right do you think there's getting that back.

Yeah. So I mean there there are you know there are some sort of uh inherent sort of you know bandwidth, speed of light, latency kind of con sort of mathematical and network property constraints but there are also a number of software and protocol constraints and the software and protocol constraints have been you know people have been working hard on improving them to improve Bitcoin security decentralization so they can increase scale. So examples of that are the optimization of the CPU bottleneck which isn't you know which isn't in Bitcoin yet but will be I think in the next major release. So that will make it much less CPU intensive to catch up with the network.

And the other one is the header first change to Bitcoin that Peter will implemented going back a little bit ago. And so depending on when you last run a full node it now syncs you know an order of magnitude faster than it used to. um just just in terms of the peer-to-peer transfer protocol was the first version of it was quite crude and inefficient and so people would resort to using you know bit torrent to fetch it but now the actual integrated catchup protocol is much faster that's the other thing to say is you don't need to run a full node all the time you can just you know use your smartphone send amounts of bitcoin around and if you at some point get involved in a larger highv value bitcoin transaction with this uh new faster

catchup headers first optimization. you can just turn your turn a desktop on or a laptop and tell it to sync and it will you know take half an hour or something and then you'll have your high assurance that yeah that transaction really cleared or something and certainly for Bitcoin businesses I think it's um important that they do that you know if they're running a web server running a full node shouldn't be ownorous um and you know I mean ultimately particularly if any if if businesses have custody of client funds or they're you know selling things um and they have the expertise then it's it's certainly useful thing to do and there's a uh one one form of kind of you know security standardization in

the Bitcoin ecosystem is there this uh cryptocurrency security standard I think it's CCSS or something like this um that's been proposed and I think they're discussing suggesting as a minimum bar that people with the expertise I I think there tiers of security. So that you know to go beyond the kind of simplest security minimum bar to go for the middle one you would be it would be strongly recommended that you would be running a full node. And so the other thing to say is that you know the the protocols get more efficient. So um the other form of decentralization comes from the block transfer time. Um, and there are protocols now that we didn't used to

have to synchronize blocks much faster. So, there's the relay protocol, a relay network protocol that Matt Carell implemented. Um, and there are also uh, so that's a kind of add-on. And I think at this point the majority of the mining hash rate is actually using that and it it so basically what happens there is all all of the transactions are already broadcast. you know, the the current Bitcoin like the native Bitcoin block transfer mechanism sends all of the transactions over the network twice which doubles the bandwidth for block propagation unnecessarily um because you know you've already received all the transactions and validated them and then you transfer the block again which

serializes the transactions. So what the relay protocol does is it uh makes use of the fact that you've already got the transactions and it just communicates which transactions in are in the block and typically that happens in a single TCP packet. So the um you know the relay latency is massively lower and that's not uh yet you know kind of um standardized and implemented uh completely enough to be integrated into Bitcoin core but I think that's something that people were interested to do in in the midterm and you know so if that were to become a standard part of Bitcoin we would have an opportunity to you know maybe increase scale or improve

some other features um because you know lat like block latency is what affects uh centralization. So there's a ratio between the block block relay time how long it takes to transfer a block across the peer-to-peer network which is claimed to be you know order of 10 to 15 seconds with the relay network that's subsecond. So you want a low ratio between the relay time and the block interval. So uh because if if the if the block transfer time and the block validation time in terms of validating

all the signatures in it gets to be a significant portion, then your you know your mining is basically dead, right? While while you're doing that validation, you can't build on top of a block. And so that favors larger miners because if they produced a block, they already know it's valid. so they can immediately build on top of it. So you can tend to get a cluster of you know semi-rusting miners in a collusion who are building on top of each other's blocks immediately and people who have you know a slower network connection or more latency get disadvantaged economically and therefore they become unprofitable and tend to drop off the network. So these kind of network compression protocols are you know coming online. uh Gavin also worked on

IBLT which is another mechanism to do it and a few other people have worked on it as well. So there are things happen a number of things happening in the network protocol and decentralization and scalability that are improving the experience of running full nodes closer to the you know bandwidth and latency limits making it more lightweight to run a full node for the CPU side and making it less prone to centralization by having more efficient uh more intelligent sort of network compressed block relaying. Um, so things things are progressing I think generally.

Today's magic word is debate. D E B A T E. Head over to let's talk bitcoin.com to sign in. Enter the magic word and claim your part of the listener reward. [Music] So Adam, we're almost at the end of our end of our show. Now be we can talk talk a little bit about blockstream in a second maybe uh but you know there's been a lot of a lot of this heated debush uh discussion and I feel like if you if you've seen uh some uh you know discussion forums particularly Reddit we've seen uh some side especially I

think Gavin and Mike they've done quite a lot to sort of articulate their points of view I think we've seen that less happening uh at least less maybe it's happened on a Bitcoin dev mailing list but not so much to the wider Bitcoin community of uh I think the people working at Blockstream and some of the other core developers. So what would you like to what would you like people to take away from here and what would you like to sort of say to people who are you know engaged with Bitcoin, care about Bitcoin, wanting to be successful but aren't like deeply in that technical process of figuring out what the best way to go about improving it is.

Yeah. I mean I I think what you said was true there that um you know there has been some attempt to sort of popularize uh a given implementation amongst companies and I think it's um you know the it's you know it's hard forks are risky well I mean soft forks are already risky we you know we nearly saw this failure with uh the fourth of July fork um and hard forks are potentially more risky. So the the best hope to minimize risk is for uh the upgrade to be you know for everybody to be fully on board

with making the upgrade because you know with a hard fork it's it's not backwards compatible. So you essentially need everybody you know all the full nodes in the network to upgrade you know all the businesses and all the miners and all the people running full nodes really need to upgrade and so the upgrade life cycle as I said like you know the soft fork upgrade time is typically 6 months so I think it's um we'll actually get to a safer and faster upgrade of scalability if we take a month or so to you know get people to agree on what the best way to do it is because then, you know, once everybody's in agreement, you can do an upgrade much faster because

all you're waiting for is for everybody to upgrade, right? Um, and I think there's some, you know, misconception also about a soft fork upgrade is triggered by miners, but a hard fork upgrade is really triggered by the econom the massive economic supermajority having upgraded their equipment and miners are just one segment of that. So, it's it's good that miners indicate they've upgraded, but that doesn't at all complete the picture. You know, if miners upgraded and the users didn't, we'd have a different kind of problem, which is the we'd have a security problem because the hash rate that is running on the network that the users are using would fall and they'd be vulnerable to attack until the miners, you know, kind of switch network or something. So, it's really the case

that you want everything to be upgraded at the same time. Um and I've I've talked about sort of uh you know simpler pro proposals like um so some something short-term that happens over a 4 year time frame rather than a 20 or 35 year time frame. So particular parameters I proposed are like 2 megabytes immediately 4 megabytes after 2 years 8 megabytes after four years and then re-evaluate based on you know what we see from uh some of these new uh scaling features coming online.

There are multiple inflight right now. Um, from seeing how lightning works out for scalability and for seeing how decentralization progresses, there's also work on decentralization. There are some ways to improve uh mining decentralization with protocols particularly related to pool protocols. Uh, you know, there's a get block tape get block template type of extension which um gives you the variance reduction which is the main reason people pull without delegating the block selection to the pool. you can you can do that work yourself and still have the pool uh help you with uh variance reduction. So those kinds of things have been working on and I think would easily be online within this kind of you know 1

to four year time frame. So I think within 4 years, you know, like say within 3 years we start evaluating where things are, the world will look very different. I mean 4 years is basically an eternity for Bitcoin. That's as long as it's been in the public eye. So I think that's you know plenty long enough for a time frame and if we start with something very simple you know an 8 megabyte cap has been well validated whereas if things stretch far into the future you know the it's difficult to forecast the future sort of like uh you know weather forecasting more than a few days out it gets increasingly uncertain and you'll either overshoot and uh you know Bitcoin will be insecure or the

miners will be unprofitable and not secure in the network or you'll undersshoot and you'll have congestion. So, you know, if if we do it within a short time frame, we can get um it's much more predictable, much more likely that everybody will uh get on board with the same proposal. Um and also, you know, it it will be good to have have a little bit of focus also to see how the flex cap proposal works. I think otherwise we're at risk of you know people jumping on the first simple proposal that has been put out there. I mean it's incredibly simple right just just to change the parameters as has been done. It's basically a day of coding. So there's a risk of sort of jumping on to the first simplest

proposal that's been articulated or maybe articulated the most widely in a nontechnical community at the expense of not make not taking benefit of uh much more effective proposals. So the flex cap proposal can really effectively balance you know provide security while providing uh scalability and bursting capabilities that the other proposals can't provide. So it really protects against um sort of the denial of service risks that come with increasing the block size because it's all within the framework of uh profitability. So miners can scale within what's profitable for them to do, which can allow them to, you know, burst and still makes um DOS expensive, which is what you want.

Otherwise, some, you know, miners could potentially um engage in different pro, you know, different uh sort of network optimization approaches that could see blocks being constrained to push up fees or um miners competing between themselves in a cartel and pushing up the block size to the maximum to squeeze out smaller miners or something like that. So the you know some of the proposals I think Jeff Jeff Garzix is kind of interesting and flex cap is kind of interesting but we really need to um see some network testing and some analysis and the parameters to be selected and proposed for flex cap and reviewed so that we can make u an informed debate. So I think the you know

the scaling scalability workshop in Montreal should be quite interesting. we can continue this kind of discussion we've been having here and talk about selection criteria and see actual uh you know network measurements presented about latency and bandwidth. Um so you know it's it's more like the way that uh NIST goes about selecting you know the new AES standard or the new new SH3 standard um where there are a number of proposals a series of workshops and um it's it's it's analogous in the sense that for any any encryption or hashing standard there's a trade-off between security and speed. So that's in a sense

quite similar to Bitcoin. And when they make that determination, you know, people put quite a bit of effort into actually measuring the speed. They will make, you know, actual uh sort of hardware circuit implementations. They won't produce them but they'll run them in a simulator and evaluate which proposal is most efficient and people will analyze the security properties of them and you know after a period of time they will select one and then those things are much better able to stand the test of time because it's extremely expensive to have a failure in the field within cryptographic protocols because it's very difficult to upgrade and bitcoin has that kind of property but magnified you know um bitcoin is far more complicated than SHA 3 or DSA. And

yet, you know, uh there's there's all this pressure right now to kind of, you know, jump on the first proposal or curtail review of potentially better proposals. So I think it's it's fortunate but I think that you know if if we do the the sort of validation of the proposals um we can still get get to scalability and get the network scaling faster because the the trigger mechanism is basically upgrade everybody upgrading not not so much you know a minor hash rate or who has some code out there first. So um if if we get everybody you know all the companies and all the

miners and all the users on the same page about a sensible compromise that you know doesn't have any obvious attacks um then we can see an upgrade in a really much shorter compressed period of time. Well, Adam, I think that's a that's a great note to end on and I certainly certainly hope that will happen and I hope that the workshop Montreal will, you know, do its part to to move in that direction and, you know, I wish I wish it was possible for me to take place as well. I'm sure it will be extremely interesting and I'm especially glad that you know different sort of different points of view come together. for example, you know that Gavin and Dre will be there as well as well as you

guys who have clashed on on some occasions in this discussion. So I think that that's super valuable that people actually come together and try to work out some solution. So, um, we didn't have a chance to talk about Blockstream today and side chains, but hopefully we can do another episode at some point down the line where we can speak about some of the actual things you guys are working on because there's some really cool and exciting stuff like the this confidential transactions. Uh, sounds great. So, would love to come back to that at some later stage. So, Adam, thanks so much for coming on.

Yeah, thank you. I mean I think just to say about you know it's being portrayed that people have you know uh large differences of opinion but I think basically if you look at all of the current bit proposals and draft proposals that they are all all invisaging increases in block size they are just making slightly different tradeoffs on different time horizons. So things are actually quite a bit closer than you know it might sound reading some of the recent news articles or some of the kind of uh online discussions that you know maybe get heated and uh there are many people who are not actively involved in the technical discussion who who obviously want to

participate and it's it's difficult to you know get down to the fullest details and understand all these trade-offs because you know it's it's no criticism of anybody really that one may not fully understand the protocols in a sense that this is basically cut leading edge cutting edge stuff and even the people who you know are writing the code are still learning new things about consensus limits and scalability limits. It's you know Bitcoin is fascinating. It's at the bleeding edge. Absolutely. Yeah. Before we wrap up uh we are still doing the t-shirt contest. So, if you want to leave us a review on iTunes or Stitcher and just send us an email at

showepenterbitcoin.com, we will uh draw one t-shirt per week. And so, uh just yeah, leave us a review on iTunes or Stitcher or any anywhere else really. I mean, anywhere where you listen to us where you can review the show. Uh definitely helps us in getting more more audience and having the show be more known on those networks. Yeah. And I actually sent out a bunch of t-shirts last week to to the US and to Italy and stuff, so some people will get them soon. Yeah. So, uh, thanks so much for listeners. Thanks so much for listening. Uh, you know, we put out these episodes every Monday. You can get them, of course, uh, in your favorite podcast apps on iTunes or Android, etc.

You can also get the video uh on YouTube and YouTube.com/personbtc. And of course, if you like the show, you can support us by leaving a tip. The tip address will be in the show notes. So, thanks so much and we look forward to being back next week. [Music]