Home < Scaling Bitcoin Conference < Montreal (2015) < Overview of Security Concerns

Overview of Security Concerns

Speakers: Peter Todd

Date: September 12, 2015

Transcript By: Bryan Bishop

Tags: Security problems

I am going to talk about scale-related security issues. Scale-related security issues. I said scale, not scalability. We are not talking about scalability. We’re talking about changing numbers, and what are the implications, what attacks are easier or harder by changing the block size number. What are we trying to accomplish? What is the system meant to be? Nobody really agrees of course. What’s interesting is that as much as we disagree about what was meant to be, there are a lot of key things about what bitcoin could be, these visions share some details.

Chief among them is validation. You can ask the question, what are we trying to prevent? We’re trying to prevent invalid transactions, giving money that doesn’t actually exist. The SPV just sees that a transaction can be linked to some blockchain. It doesn’t know whether the transaction is valid. In bitcoin, we have the ability to determine if things are valid, by going back in history and validating each step. Here transaction 0 was spent and then there was transaction 1 and so on. There are many cases. Obviously if something goes wrong, we have an invalid transaction and we’ll notice this, if we go back in history and find it. Similarly the transaction may not exist in history. Money might be spent twice.

That pretty much covers all of the different use cases that people want. Are the rules being followed? That’s all. When you talk about attacks, what are the attacks possible? It’s pretty boring. There’s invalid data in the blockchain, and if you don’t know if it’s valid, then the system doesn’t work. The whole attack and scale-related thing is how much data do I need to determine if someone is doing something invalid. And right there, and if I’m going to go through transaction history, immediately in the case of bitcoin due to optimization issues and things that could potentially be done but haven’t, long story short is that I need transaction history. We can improve on this.

Quick example. I like to use Where’s Waldo here. Imagine the problem of finding the two transactions spending the same money was akin to Where’s Waldo. Did two waldos exist? It’s very easy to prove this. We show everyone else the two waldos, in one place, here’s where they are, and going back to my previous slide, tx1a exists and tx1b exists. And that’s our proof, very easy. You don’t need very much data to show this. In a system where information is easy to propagate and otugh to censor, I can just spread this proof to the rest of the world. Forward a tax when this happens.

From a miner’s perspective, one of these issues about how bitcoin actually works is that it’s a lot of effort to go through and find that double-spend or invalid waldo. There’s a lot of techniques in the future to consider. Right now for scaling, this is one of our big issues. How do we manage this problem that currently we have O(n^2) validation for anyone that mines and creates valid blocks has to have access to this data.

Another big scaling thing is what does it take for someone external to the system to attack it. BitcoinXT blocks, which blocks have been produced on the blockchain that advertise supporting BIP101, it goes up and then goes down again, there was an external attack where someone ddos’d slush’s mining pools and essentially extorted them. Riley didn’t give up. What does that have to do with scale? Again, if you’re in an environment where the way we participate in bitcoin is to relatively centralize targets like slush mining pool. It’s fairly easy to go and choose these targets and attack them until they give up. To the extent that the question of scale changes these tradeoffs, that’s another scale-related security concern.

The fact that we have this issue at 1 MB is definitely cause for concern and we should think carefully about this. When I was talking about what we want in bitcoin, there’s some controversy about - what do we want from bitcoin? It’s not clear to me that this is something tha twe have good answers for; the main thing that is in common with most systems is that there are single points of failures. In any centralized or distributed system, you have these points of control and you can target them by pursuing them legally, technically or so on. And currently in bitcoin we kind of look a little like this. We haven’t done a great job on fixing mining centralization. If your goal is to decrease the single points of failure, you should be talking about that as a security concern.

Now we have this issue where in bitcoin anything that can lead to a monopoly or incentives to further centralize can be seen as a security consideration, this causes issues with the inherent goals of the system. So here’s probably the biggest topic in this. Do large miners have an advantage over small miners? China versus the USA in a simplified model. How does this come into play?

The question is, who is going to find the next block? China has slightly more hashrate than the US, so chances are that block #3 is going to be found by China. Imagine that it is. Well we have an issue. The great firewall of China. What’s interesting is that for a brief amount of time, depending on block size and data propagation rate, at this moment the US mining pools don’t know that block #3 exists. From their point of view, block #2 is the most recent valid block. So they are still working on block #2 trying to extend the chain. So they might be fine there. But when they find that block extending the chain, the Great Firewall of China exists and now we have this fork and how is that fork going to get resolved. What’s the probability of who finding which block? China still doesn’t know about block 3b, and even if they did, the way the incentives work is that you might as well mine on the block you found first because that’s the block more likely to propagate to the widest number. Then they go mine block 4, at this point maybe the US knows about this maybe not. By the time it resolves, it’s ….. lSo after all that, what happened here?

In terms of monopoly, what we said is that the US had a disadvantage there, they did a lot of work and didn’t get rewarded for it. And in a nutshell, that’s one of your more interesting questions of scalability. Do we have a system where there are incentives for people to get bigger? And for larger pools once they are bigger, what kind of profitability do they then have? And I can go talk a bit about this, let’s go look at what research is being done. First of all we have the pre-selfish-mining paper work, we have people who have now shown with some math depending on how you assume blocks are propagating, if I get 50% of the hasing power then right there who is going to find the next block, chances are that I am going to find the next block and the other 49% are less likely. Once I’m at this threshold, now I have the advantage. A bit more worked followed up, depending on how we propagate information around, this threshold is about 30%, which was shown in the selfish mining paper in different ways. And on top of that we have done various simulation results, the big one is sipa’s work (Pieter Wuille) where we have shown- and he used realistic mining and latency networks where if you look at the situation with China, for the amount of time it takes for data to propagate, people who are not parts of that group, are earning something like 8% less revenue. In reality it doesn’t happen that way, because of Matt Corallo’s block relay network, the miners are just assuming that the previous blocks are valid so they are doing “SPV mining” essentially.

In the worst case, which we must always consider, there’s fairly significant revenue difference between small miners and large miners. Ultimately I think that this being an overview, I’ll kind of say let’s go look at that and figure out where we can go from there. Let’s do our assumptions on the worst case. I was planning on leaving time for questions, I’m happy to stop here.