Peter Todd Discusses Consensus at BitDevsNYC on 4/28
Peter Todd led a discussion on the nature of Consensus, Bitcoin, and Blockchains on the first night of the Inside Bitcoins 2015 conference in New York. This talk ...
What's up party people? We just finished up a talk here from Peter Todd. He did a great little Q&A about Bitcoin block size. Sorry, yeah, the Bitcoin block size, what megabyte, how hard consensus is, a bunch of things like that. Now, I started the video about a minute into what he was saying and so we missed the first part of it. It was mostly just an intro, but let's go see what he has to say and I'll check back with you later. Party time! Storj party time! Without all the stuff, I think a lot of us like Bitcoin.
You know, it's quite conceivable that you could have PayPal take a copy of Bitcoin and start signing blocks and say, "Yeah, this is a PayPal ledger." You know, it's functionally, actually, the same thing as Bitcoin except for this minor bit where we can still freeze people's funds. You know they can implement that and I know projects that are going down those lines, especially for say government's crypto-currency projects. Again, another one of the things which I think I get consensus on what makes Bitcoin different and special that other things can't copy is the decentralization. Well, item number three. Where does the decentralization come from? And I think certainly at some level, you have to have a very wide variety of people able to participate.
How big that group of people needs to be? How wide it needs to be? I think you could get 20 different opinions from 10 different people, but it certainly needs to be more than one. I think, again, it's another one of these yes I think I can get consensus over that statement. Well, then the next issue is if you want to have a wide variety of people participating, obviously, at some point you're going to be picking who can be participating based on what kind of computational resources they have. If you need people to have a faster internet connection or a slower internet connection, that changes who can participate. We are not going to consensus on what are the right thresholds, but I think we can get consensus that there are thresholds. It's a pretty obvious thing that not everybody has an infinitely fast internet connection and not all of us live in the exact same place in the world.
So, there certainly is going to be issues there. And then the next step after that is, well, what do we do about this? And I think this is where there is a bit of disconnect where often some people in the community, go, yes the block size will increase and destroy those consensus, but, all right consensus over whom? You can certainly get 10 people and call it a group and call it a consensus. But if you go and talk to people in the core dev community, and I will name names. I'll say your Gregor Maxwells, your Peter Rule, your Vladimir, etcetera, etcetera They're not really agreeing on exactly when this should happen, if this should happen, what should happen first, what should be a prerequisite, and I'm not seeing that as what is being communicated to the public. And I think people should realize this. It's not a guarantee this gonna happen.
It's gonna happen soon, We don't know. What we do know is that there's are a lot of alternatives. You've got things like hub and spoke payment channels. Lightning system is another potential one. Already people do off-chain transactions. Like Satoshi dice I'll quickly move to all our.
. . I will go make a deposit and then, with my deposit funds, I'll go click the magic. Let's go lose money at a rate of 1% per gamble, and that's kind of where things went. The same way that chain tip is another example, what chain ti replaced was a system where every single tip was a Bitcoin transaction. Every single tip cost a couple cents and you couldn't tip small amounts without losing a lot of money.
And, naturally, market forces led that changing, getting replaced. Again, it's one of things, what are the right level of market forces? What's the right level where a transaction should be on the chain or shouldn't be on the chain? Again, you're not going to get consensus easily over this. It's just not something you can because it's fundamentally not a technical decision. It's a political decision shaped by technical realities. And I think any company that is trying to assume they are going to get a nice clear decision, I'm sorry that's just not going to happen. We don't actually know.
And then, I'll go on to my last thing I want to say is that fundamentally the tech itself does not scale. The whole idea of everyone knowing everything about every transaction, which is inherent to the trust model of Bitcoin right now. That's simple ON squared scaling. You can't just get away from that. No matter how much you go push and pull that constant K value, you'll never get away from the fact that fundamentally it's ON squared. Obviously, we can change the tech.
We can change underlying algorithms but, right now, with the current trust model that's how things are. And, there's no consensus on exactly how things should change. I'm not trying to say that there is one thing that is or isn't better. I'm just pointing out, again, we don't have consensus and you can't build a business assuming this. And since we don't know to go and make the scale better, again, we can't predict the future. If we say increase the block size to 20 megabytes and 40 times more Bitcoin traffic suddenly appeared because 10 different banks decided to adopt 10 different versions of Factom, each of which weren't compatible with each other.
Well, I'm sorry, but Bitcoin transaction fees are going to way up and I just can't predict that. And for all I know, maybe these banks won't give a damn about spending $10 per transaction to use Bitcoin. I can't predict the future and nobody can and if you get enough demand, you just bump up to the problem that you've got a system that doesn't scale. Chances are that's not going to happen, but who knows? It's not something you can guarantee. So, long story short is if you have a business, you should understand what the alternatives are. You should understand the whole role of alternatives, and you should understand that we can't predict the future.
Are you a proponent of bumping up against those limits before we need to decide these things? Well, in the context of this hypothetical letter that I'm writing up, I think we're, what I would say bud, is that there is no consensus that we should or even what bumping up means. Well, so, if it's the block size we're talking about then, the network starts getting backed up. But remember, we've already bumped up against them. Transaction fees start going up and...
Like I say, we've already bumped up against those limits. The question is what is the definition of bumped up? We know that I can't send large numbers of transactions for very low fees. If you do that, they will just sit in there in the mempool for a long period of time. But it seems that people naturally know this, and they stop doing that. Most wallets these days have settings that set a lower or higher priorities and a lot of people use the higher priority. I personally use that all the time because I want my transaction to go through.
So right there in a sense, yeah, I did bump up against that limit because I actually had to go make a choice. But does that constitute bumping up? We don't have consensus over that. So the hypothetical letter you're writing would be to communicate this sentiment that it isn't decided among the developers? Yes. So, the general sentiment is that you think that it will eventually increase the block size more than it will scale. What is the sentiment of the general public which you think is misguided? I think the key thing that the public is missing is this notion that it has been decided that, yes, the block size limit will be increased and even more importantly that that will fix all the problems. Right.
Because regardless of whether or not you have consensus over it, regardless of whether or not it happens, fundamentally the system has N squared scaling and you just can't get away from that. And the only way that you can go get cheap transactions, if say transaction volume continues to increase exponentially, is you centralize Bitcoin. That's just how the system works. We don't know what those limits are. We don't know what the time-frames are and we can't predict them in advance because it's all about how many people use the system. So, in a world where the number of transactions grows by many orders of magnitude and transaction fees stay low, it's either centralization or many different side trains, is that correct? Or what are other solutions? Again, the key thing is with the current Bitcoin architecture, it's very simple what the result is.
It either becomes very centralized, or transaction fees go up. With other architectures, there's a lot of different possible outcomes. Maybe we'll go fundamentally change how the Bitcoin blockchain works. Maybe it will find a way to chard in different parts. Maybe it will find ways to. .
. things like the Lightning network. Chances are we're going to do multiple things at once. By centralization, he means increase the block size. Well, no, it specifically means decrease the number of full nodes. Decrease the number of full nodes as a result of the block size? Yes, yes.
As an example being, if we had one terabyte blocks that had to be passed around every 10 minutes, there's not many people in this room who can even get access to hardware fast enough to process that. That's just a given. That would also mean decreasing the number of mining pools because of the higher block size would increase the latency of transmitting them, right? And, also simply the cost. What? And simply the cost, too. Sure, yes, obviously that's another facet to centralization, another aspect of centralization, in addition to the number of full nodes increasing. Yeah, and actually that's a good point.
That's something I should probably put in there to go and point out how potentially one of the things that makes Bitcoin very robust these days is when something goes wrong either due to a technical mistake or due to some kind of regulatory activity, it's very easy to just go and say, "All right I'm going to set up a new pool. I'm going to setup a new full node, etc. and very quickly switch over to something new." When you have 20 megabyte blocks, when you have 100 megabyte blocks, one gigabyte blocks, all these things become more and more difficult. And at some point it becomes impractical. Similarly at some point it becomes impractical to validate everything.
What I'm getting from this is you would be a proponent of like smallish blocks plus something like... Yeah, I think most of the community is. What small means is up for debate, but I don't think you can actually find anyone who agrees that we can scale Bitcoin up by only increasing block size. Do you feel sentiment, outside sentiment that does not feel that Lightning is good? I think the thing is there's a lot of people don't understand even these options really exist.
Again, this is one of those disconnect things where you talk to people outside of this community, and from their point of view it's just, "Oh, yeah, you get rid of this silly anti-spam limits and everything's fine." And we use Bitcoin exactly the way we do. The problem is if the network does not scale. . . Part of me wonders if the economics mining change significantly with something like Lightning and if you might get pushback from people who have large interests.
Well, it's one of those things where the economics change both ways. The economics change significantly if you increase the block size because suddenly your fixed costs go way up. Equally, the economics could change if you make very good alternatives to using Bitcoin directly. If I'm using something like Lightning, or if I'm using something as simple as payment channel, I'm taking potentially hundreds, thousands of transactions and turning them into one. You can argue I'm ripping offliners. On the other hand, miners can't do anything about it.
They can choose not to put the transaction in the block. But, you can do it in a way that they don't even know what the transaction does. Right. Well doesn't economics help speed that along, so the idea is if you increase the payment fees to 10, 20 bucks, then people have a huge incentive to use something like Smoke, micropayment stuff for your basic transactions and everything else. Or when you just need a clear, you just do one transaction. So, the economics would point it in the right direction at least.
Yeah. I think, again, depending on your definition of consensus, you can get a lot of people to agree with that, but not everyone. I'm not totally sure I can actually get, and again, this is something I want to do as an open letter with a lot of people signing it. And I'm not sure that I can actually get consensus to make statements like that. Just in case anyone is confused and who doesn't know what a payment channel is, it's a method of using a number of transactions to bundle, sync a lot of transactions into one. We went over it fairly in-depth at the last meetup, but if you want more information come talk to me after and I'll send you some reading material.
And there are ways to leverage it network wide so we could scale up without having to increase the number of transaction, etc., etc. Do you think that it would help to get buy-ins to guarantee a working reference and limitation for any of the pools to implement all at the same time so that there is no like Lightning gets rolled out and someone has an implementation and nobody else does? Well, keep in mind, pools are devolved in things like Lightning in the big picture. If they want to participate in that new economy. It's just the script. There are some certain upgrades to the scripting system to implement Lightning itself.
But, as an example, hub and spoke payments, which is sort of slightly more primitive version of what Lightning can do. Mining pools, you can implement hub and spoke payment channels in a way that mining pools can't even know that they're being used. Right, and I'm saying those intermediaries, those people running the hub performing similar now to ... Not really, there's no trust involved.
Right, but there's not trust, well little trust in ... Collectively, miners basically call the shots in the sense that if they choose to, they can destroy Bitcoin. Whereas, in a hub and spoke payment channel system, all you can go do as your hubs is lock up people's money for a temporary period of time. It's, I would say, a very different kind of trust and it's the sort of thing where it's quite conceivable people start running Tor sites, running payment channel hubs and you have no idea who they are, but you know the worst they can do is your money will be locked for a day, a week, whatever it is.
And that's actually pretty acceptable really. Are you guys working on a reference implementation? No, there's not no specific funding yet which is something I also wanted to co-fix. Implementation of Bitcoin check? Like for paid to contract cash? There is a payment channel implementation, but nobody's kind of put all the pieces together. Do you think that the scalability part would cause a disagreement between two parties or two camps of people that would disagree on which version of Bitcoin is the correct version? Do you think that is a serious issue? Oh yeah, and it's one of the issues too is where there's no safe way to actually upgrade the network to do this because there is no way to determine if the nodes you're connected to will or will not actually accept this upgrade. Similarly with miners, one of the things miners could do if they decided, "All right, we will not allow an upgrade to happen" is suppose you're going to, say, flip a switch in your end version and you're going to average high, yes I will accept 20 megabytes and up blocks. Miners could choose to say, "All right, we're not going to actually accept this so we're going to flip that switch," not actually implement the code and the moment any miners are foolish to go follow along, upgrade, suddenly they're losing money.
And if you can get a majority to say, essentially, "Screw you. We will not do this," you can go screw over the minority who decided to upgrade and cause them to lose a lot of money and it's quite possible these types of politics could play out if people did not want this to happen enough. And I know a lot of mining pools realize that. Right now, orphan rates matter a lot and that is with the equivalent of IBLT implement, with all these very good relay improvements implemented. You can't actually improve that that much. And orphan rates already matter, so to increase that by up to 20 times is a pretty big number and potentially a very large profitability hit.
A lot of people would say, "Well, I don't want to go take this risk." Equally, there's a lot in the academic community, for instance, and a lot of papers are pretty clear that, yes, you cannot pay for hashing power in the future without a limited block size because otherwise there is no supply and demand market. There is no profit margin for miners. So again, it's one of those things you could get a lot of people in the mining community say, "We're just not going to accept this." And it may be to the point where, yeah, we're going to sabotage this. Not much we can do about it really.
Thank you. It seems like the hub and spoke and Lightning network those things are going to take a while to roll out. The infrastructure is not there yet. I think for Lightning network, we need to fix transaction malleability. Are you against increasing the block size in the short term until we get this longer term infrastructure? Me, personally, I am because I suspect what will happen is the politics of it will just mean that you sabotage efforts to go and fix the problem in a fundamental way. There's a moment you increase that suddenly the reason to do something like Lightning goes away and it gets much harder to get support and funding for these solutions.
There's lots of reasons. Again, why haven't we seen it already if there are all these reasons? We've been able to implement hub and spoke payments for easy two years now, and they offer very big security improvements too. Yet nobody wants to put up that $100 grand to get it done. It's a lot of money to go put this up and you really need that solid demand. Whereas if you just take view of, "Yeah, we'll just increase it. Oh, shoot we took too long.
We'll just increase it again." It's very easy to get in the habit of just making Bitcoin more centralized as quick fixes over and over again. Well you could say the Lightning network is going centralize it too, right? You're going to have all these parties that control... I would disagree, because I believe that having centralized layers on top of a decentralized layer is a much preferable scenario than a centralized layer where you cannot have decentralized layers on top.
Also, look at it this way too. Right now, we already have that situation. A vast majority of Bitcoin users go through a very small number of channels. We've already accepted that kind of centralization. So, something like Lightning doesn't actually change the status quo very much because we've already accepted it. Rather it goes and puts it into position where the status quo can be both useful, can get you more privacy, and potentially could involve less trust.
Right now, a lot of people say you use Coinbase. Coinbase has their money. Something like Lightning can change this to a situation where the central hubs actually don't have people's money. They can cause disruption, but there's limits to what they can do. So do you think that there is currently. .
.is there currently any concrete plans to upgrade the networks for, let's say, 20 megabytes block size? No, nothing concrete. And part of this is, in the sense that on the one hand we have a concrete plan to do this which is you change the number and you just cross your fingers and you hope. But the real issue is that nobody has actually done the work to go and determine what attacks are you making possible. Gavin ran some tests on a laptop but that's not how you test security software. You don't test it to make sure it works.
You determine if it can be broken, and that's a completely different engineering task. And, unfortunately, the latter is a hard part. The easier one is to just change the number and see if it continues to run. An analogy I like to give is imagine if we had a bottleneck with ECDSA signatures. We say, "All right, verifying signatures is too slow. Do we really need 160 bits? Why don't we just reduce it to 80? You know 80 runs really fast.
I ran a test on my laptop. I mean, I could do 10 million transaction verifications per second, obviously that works." But that says nothing about whether or not someone can break it. You just can't test your weight in knowing if something can be broken. You had another question. Oh yeah, I'll come back.
You mentioned that in the Lightning network hubs were centralized, is there any dynamic that would cause them to centralize? They're inherently centralized. Yes, that's exactly it. And it becomes a balance between, I think in practice is what you would see is hubs would essentially appear along community lines. In a real world example that's already happened, all the dark web markets, basically, all of them work by you deposit money to the site and then it moves money around within the site by changing database centers. So the equivalent you would see with something like the Lightning network there is you would have a hub corresponding to a single market. You would put up a deposit that you are guaranteed to get back, and from that deposit you give money to other people within that hub, and the moment you give that money, long story short, they instantly get the money in a way that is irrevocable, and the person in the middle has no access to it.
So it's centralized in some senses, but on the other hand so what? Can we force the hubs to centralize more and more? Well, if one group of people is using one hub, one group of people is using another hub, you can use things like Ripple where if I want to go send money to you and you're on a different hub, I send money to my hub, the hub sends money to the hub you're on and it goes to you. This stuff takes more software, but it's not a winners take all situation with appropriate software like others form of centralization are. You equate the hub to something bad like it tries to freeze people's funds. It's trivial for someone to go set up another hub and say, "Look everyone who the Coinbase hub got kicked off, why don't you join this new hub which runs on a Tor site and it's out of U.S. jurisdiction, and you don't have to trust them.
" What do you mean by more central like for a payment hub? That was the implication that hubs, well remember there are intermediate nodes that actually send out transactions, right? The implication was in this conversation that those intermediate nodes would centralize more and more like mining pools, concentrating, concentrating by those intermediate functions in one set of hands. And I was wondering whether there is actually any dynamics or mechanics that would force that. Well, they become more functional the more people that can transact through a single hub. I don't think that anybody claimed that. Peter was suggesting that the price was going to get so high that it wouldn't make sense to ..
. you'd have to go through a Lightning network to get your transactions broadcast, but that's assuming the transaction fee gets that high. Well, it's also a matter of supply and demand. So the converse is, given that the Bitcoin technology currently doesn't scale modulo like potential advances in actually how to structure blockchains. We know it's a simple trade-off, where I want to do the overall transaction volume that can be handled by say, a hundred Lightning hubs, a million transactions a day. That's going to have an impact on how many mining pools can exist, how many full nodes can exist.
It's just this trade-off. If I want to scale to a billion transactions a day, that's a lot of data to go push around the network and the number of people that can participate in that goes down drastically. At some point, which is worse, having Lightning network hubs where you can go pick and choose who you want to be involved with or a centralized, underlying layer that you have no choice about? It's unfortunate that a trade-off exists. It'd be nice if someone invented a better way of doing blockchains, but you can't just assume someone is going to. You gotta go work with what you have and let people go develop better systems. But it's going to take some time to get the Lightning network out? They haven't even finished the proposal, like they said transaction malleability.
. . We know hub and spoke payments work fine. That's very well accepted. Remember, the Lightning network is an optimization of something that we already know works and this stuff always happens gradually. People, as an example, ChangeTip .
That was a gradual market led pressure that drastically reduced the transaction volume on Bitcoin by moving a lot of stuff off Bitcoin. It'd be nice to see change to influence to payment channels to be a little more secure, to not having customer funds and that's something that can happen naturally. But a lot of this stuff doesn't happen if you just continually make that trade-off without putting in that market pressure. So hub and spoke payments could happen. They haven't happened. There aren't many people doing them yet, right? It's not like a large thing.
And for this to happen, for this to be the scaling solution, that needs to show up. Assuming transaction volume continues to climb before people start setting up lots of hub and spoke payment systems, do you know of any proposal that you like for how to scale this network? Well, again, the simplest thing you can do is hub and spoke payment channels and simple off chain transactions. We understand how this tech works pretty well. We've seen the demos. We know how it works in the lab. It's pretty clear that this stuff can be done and, more importantly, it's not like there's really good alternatives to this.
It's not like you can wave a wand and hope that when you do your block size limit increase you'll be bale to go and get commercial interest in going and making a proper solution. We don't really have topped out planning of this stuff. We have to go work with what we have which is market forces. And if transaction fees start climbing, that provides very strong incentives to the fix the problem. It provides strong incentives across all ecosystems. Could the reverse happen in terms of reverse scalability? So you could have a portion where transaction volume is increasing, you're having this problem, you're increasing transaction fees and then you have solutions like hub and spoke and the Lightning network and then it no longer becomes a problem and all.
You can fit hundreds of thousands of transactions into a single clear transaction through the Bitcoin blockchain. Then you only really need a few transactions and these hubs are taking care of a majority of the transactions on the network, so you don't need seven transactions per second. You need a lot less and you need a lot less miners to validate and do all this stuff because your transaction volume goes down. Well, keep in mind with miners it's not a matter of how many miners there are. It's having enough and throwing enough money at the problem that nobody can out spend you. Now as for lowering the block size, I don't know.
Maybe there will be consensus to do that in the future, but it's too far into the future to speculate about it. Like I say, my idea for writing a letter on this and just stick to what we know, what we can confidently get consensus about and present that to the public and let them make decisions. Is there a conceivable world where you have a hard fork and Bitcoin with and Bitcoin without a system like this? The first issue that comes to my mind is dumping and pulling hash rate to just and then printing a few blocks on that network. Are those the primary concerns? I think, ultimately, if we end up in a situation where we have two Bitcoin networks, that's a very unstable and dangerous situation because that's really saying one of the two is likely to lose out and it's likely to end up in a positions where it is no longer secure in the sense that winners can organize, "All right let's just go kill off this 10% either big blocks or small blocks, straggler and get this issue done and over with and get the markets back on our side." And if 51% is attacking that smaller chain plus hashing power makes sense. Well, at some point it probably will just the same way we saw it in Litecoin versus Feathercoin where they were able to get enough hashing power together to go attack Feathercoin over and over again until the coin was killed.
And were the methods used just like printing empty blocks and dumping hash rate and pulling back? In the case of Feathercoin, it was due to huge re-org attacks. Re-org attacks, what does that mean? It's when they reorganized, say, a day's worth of transactions and defraud exchanges. Oh so they would go back in time and like reprint? I have one last question. Are we done? I just have one last question, Peter. How come you're not going to Richard Branson's blockchain summit? Because. .
. He's still charging people $10 grand to go. So you still gotta pay even if you're on the list. Even if I was invited, I already told my parents I'm going to climb some random mountain in the Alps with them. So, I would much rather spend time with my family versus Richard Branson's silly thing. Will you be around for a little bit afterwards for questions? All right, cool.
Guys, round of applause. All right, that's it for that. I think that's a pretty interesting, plays things out right out. I've actually come to a lot of conclusions myself lately about consensus, about the Lightning network proposal, about raising the block size. The Bitcoin blockchain is a very sensitive thing. It's not too sensitive, but it's very sensitive and forks can cause major damage.
So if we start playing with this stuff, it could have some serious ramifications. Peter Todd did a great job. He really has got me thinking. So that will probably influence a lot of what I talk about on my channel, but I don't know. Hopefully, you've got some opinions of your own. If you do, why don't you leave them in the comments below.
Certainly tell me what you're thinking. You can always tweet me @DeRoseTech and if you like this video, subscribe to my channel. Later, party people.