MIT Bitcoin Expo 2021: The New Normal - How Much Security Is Too Much Security

May 19, 2021 04:00 · 4746 words · 23 minute read

So next up is another member of the MIT DCI.

00:06 - Tadge Dryja, who is known as the co-inventor of the Lightning Network, and is a Bitcoin developer working on scalability, most notably his project, Utreexo.

00:16 - Thank you for joining us, Tadge. Hello? OK.

00:20 - Hi. Is this working? Cool. Everyone.

00:24 - Thanks, [? Emil. ?] Let me share screen. OK, cool.

00:27 - So hi, everyone. It’s too bad we can’t be in-person.

00:31 - But I think by next year, we’ll be able to do this again in person.

00:35 - It’s been a long year without conferences. And I guess for maybe many people watching, the MIT Bitcoin Expo last March, that was the last time I saw a bunch of people in person, because it was right at the beginning of this whole thing.

00:50 - Anyway, cool. And thanks to [INAUDIBLE],, that was a really good start-off for the day.

00:58 - I’m going to talk, in some ways, the opposite side of things and saying, well, do we have too much security? And talking about defending against 99. 999% attacks.

01:10 - Which just sort of a silly way to put it, but yeah.

01:13 - So what is too much security? Like Bitcoin is pretty secure, right? Well, yeah sure.

01:18 - There’s all these issues, these problems, but generally, there haven’t been big reorg attacks.

01:25 - We haven’t seen that kind of thing. And if you mined a bunch of Bitcoin in, I don’t know, 2010, it’s still there, right? We haven’t seen these kind of huge breaks, which is great.

01:36 - It’s still working. If it stopped working we probably wouldn’t be talking about it still.

01:41 - And more security is better. We need to keep strengthening it, to some extent.

01:46 - But maybe it’s too secure. So what does that mean? What does too secure mean? So I have some examples of too much security.

01:55 - And some of these may be somewhat technical, some of them less so.

01:58 - But, like, 8,000-bit RSA keys. You see them sometimes.

02:01 - People use like– they’re like, “hey, send me an SSH key so I can give you a log-in to the server, or whatever. ” And then it’s like this giant, two-page long RSA key.

02:09 - And you’re like, “Oh, OK. ” It works, right? It’s slower, but it’s sort of overkill.

02:16 - It doesn’t really meaningfully do anything stronger than like a 2,000- or 4,000-bit RSA key, right? Or maybe it does, but we can’t think of a reason why it would.

02:26 - It seems like any computer that can break a 2000-bit RSA key before the sun burns out could also break an 8,000-bit RSA key before the sun burns out.

02:36 - As far as we can tell. We don’t know of anything.

02:39 - And so, it’s sort of, hey, maybe there’s a reason.

02:42 - But we don’t have a reason for this to be more secure.

02:45 - Similarly, 24-word BIP39 seed phrases. So some of you may use these kind of seed phrases to store your Bitcoin.

02:55 - It’s just a bunch of words. And basically what happens is you write down the words, you hash that all, and it turns into this seed.

03:01 - And then you derive your private keys from that seed.

03:03 - And this is a cool system. You can do it with 12 words.

03:07 - And that’s secure. Or you can double that and use 24 words.

03:11 - Which is more secure, I guess. But in a certain sense, I think it’s less secure because it’s sort of, now, it’s longer, and it’s easier to screw something up or forget part.

03:23 - And it doesn’t, as far as we know, give any meaningful security gain over the 12 words.

03:28 - The 12 words gives you 128 bits of entropy.

03:31 - And the 24 is, well, twice as much– 226 bits of entropy.

03:35 - What computer can do 2 to the 128 operations, but not 2 to the 256? We don’t know about anything that can do that.

03:46 - It doesn’t seem like there’s any theory that leads to that.

03:49 - So it seems sort of like, why are you doing this.

03:53 - And then another funny example, like TSA. Not that I’ve been to an airport in the last year, but I do remember them.

04:00 - And remember it being like, is this even secure? Like it seems like you can get stuff through here.

04:06 - But it’s a huge waste of time, and everyone’s taking off their shoes, and like I don’t know.

04:10 - Yeah. So there are costs and there are problems with this, sort of, too much security thing.

04:16 - And then sometimes it can sort of paradoxically reduce security.

04:18 - I would say, something like a 24-word seed phrase, I would use the 12 one.

04:25 - I was like, look it’s smaller. There’s just as much cryptographic security and less likelihood that you’re going to lose it or something.

04:35 - So we sort of want like a defined specification.

04:38 - Like, OK, what security level are we targeting here? And in Bitcoin, there is no specification.

04:44 - It’s just a paper, and then there’s a code base, and it keeps changing.

04:48 - And even the code base, like there’s a bunch of different clients, and who knows.

04:53 - But we can look at it and sort of say, well it mostly has 128-bit secure.

04:58 - That seems to be the design. And so the meaning of that is that it resists an attacker who can perform up to two to the 128 operations.

05:09 - And “operations” is a little vague, because whether that’s hashes, or elliptic curve operations.

05:15 - And those two things are different, hashes are much faster generally, than elliptic curve operations.

05:20 - So there’s a lot of sort of subtleties here.

05:23 - But generally you can say, OK, this is two to the 128 operations to break this.

05:29 - Some things, on the other hand, have more security in Bitcoin.

05:32 - I get some examples there, but a big one I keep thinking about, forever, doesn’t really matter.

05:39 - You’ve got these 20-byte Pay-to-PubKey Hash or Pay-to-Witness-PubKey Hash addresses.

05:43 - So I’m sure people are familiar, if you use Bitcoin you have used one of these two types of addresses.

05:50 - The all-lowercase EC1 prefix one is the new Bech32-type segwit address.

05:57 - And the older style that starts with a one and is mixed-case is Base58Check addresses.

06:06 - And so these use 20-byte hashes. So 160 bits of total hash output.

06:14 - And that’s kind of overkill. If you’re targeting a 128-bit security, now you’ve got this 160-bit hash and you don’t need it.

06:23 - That extra four bytes doesn’t really do anything as far as we know.

06:28 - And so you could shorten these things. So in the bottom here, this is what the length of a current Bitcoin address.

06:37 - And I’m saying you can shorten it to this long, with no meaningful security loss.

06:42 - You still have the same properties. It’s still two to one– The idea is yes, it’s easier now to perform a second preimage attack on the key hash.

06:51 - But the second preimage attack on the key hash is already much harder than just figuring out a EC private key from a EC public key.

07:00 - So people aren’t gonna– you’re always going to go for the easier attack.

07:03 - And so with this shorter address, the easier– now those attacks are both as easy as each other.

07:09 - The second preimage and the private key derivation now become equal.

07:13 - So it does seem more efficient. And you can have a little bit shorter addresses.

07:19 - Not the huge difference, but you could. So this is something of an overshoot.

07:23 - Am I saying, we really need to switch to like 16-byte PubKey hashes.

07:27 - Well probably not, this is not a huge gain.

07:30 - It’s already widespread. And anyway, we’re switching to Taproot, which is even longer, pretty soon anyway.

07:36 - And so it’s not like a big deal but it’s sort of like, huh, yeah you probably could shave off four bytes there with no real problem.

07:45 - And those kind of things, it’s like, well yeah.

07:47 - Are there inefficiencies here that we can use.

07:51 - We can sort of say, hey, let’s tweak this. This is overshoot.

07:54 - We’re going too far here. And we can get better efficiency and better performance in other parts of the system, without meaningfully getting rid of security.

08:02 - It’s sort of too much here. On the other hand, there are some things in Bitcoin that have less than 128-bit security.

08:08 - So for example, Pay to script hash. It’s 80-bit secured.

08:13 - And it’s the same length as the– the addresses are the same length as the Pay-to-PubKey hash ones.

08:18 - They’re 160 bits long. However, there’s sort of– the tricky part is it’s a different threat model.

08:24 - Whereas, in Pay-to-PubKey hash, you’re just making your own key and someone sends money to it.

08:31 - In Pay to script hash, there are potentially many cases.

08:35 - And maybe most of the cases, it’s like multisig where there’s multiple keys involved.

08:40 - And that’s interactive. So you might be making a multisig address with people who you don’t trust.

08:45 - And if that’s the case, they may be able to perform collision attacks and say, hey, what’s your key? And then, OK, here’s my key.

08:53 - But actually, they have this other separate key, and then they can take the whole thing.

08:57 - So there are attacks where you can do it in two to the 80 operations because of the length of Pay to script hash.

09:03 - This is fairly limited cases. It’s limited to cases where you’re creating multisig addresses with people who are trying to attack you, which maybe you shouldn’t do, but maybe you should.

09:13 - Lightning networks rests on the idea of you’re opening multisig channels with people and they might try to rip you off.

09:21 - And we have defenses against this. So this is fixed with Pay to witness script hash.

09:26 - And you have a back up to 2 to the 128 security.

09:31 - So what I want to say is, yeah this is sort of theoretical, but 2 to the 80 operations has happened.

09:36 - Bitcoin has done, I don’t know, 2 to the 90 or so hash operations and all the proven work ever.

09:42 - So the other thing that really complicates this is that, in Bitcoin, there’s all these traditional sort of cryptographic security guarantees where we’re like, OK, here’s this elliptic curve property, and here’s these hashes.

09:57 - And we know about preimage attacks and collision attacks and all these things, but then there’s also these economic incentives.

10:02 - It doesn’t fit in the standard way, because clearly, you don’t have to do 2 to the 128 hashes to, say, rewrite the entire Bitcoin blockchain.

10:12 - The total thing is something like 2 to the 90.

10:14 - So yeah, way easier to just reorg from genesis, or more than 51% attack.

10:21 - And so it’s like, well, we clearly are not just using 128 security.

10:27 - We also have the sort of economic incentive assumption.

10:30 - And it was initially described as the attacker ought to find it more profitable to play by the rules, such rules that favor him with more new coins than everyone else combined, than to undermine the system [INAUDIBLE]. .

10:42 - That was Satoshi back in the day. And that is one of the huge aspects of Bitcoin that makes it possible.

10:49 - Because it’s not possible to get this kind of consensus with the traditional cryptographic standard guarantees.

10:58 - So we do something here, right. We sort of are also relying on this, assuming there isn’t a 51% attack.

11:07 - Which could happen, but hasn’t so far. We’ve got economic incentives that sort of reduce this.

11:13 - Can we leverage these and combine the 51% attack assumption for better for worse by reducing security in other places? Now, this seems dangerous, and I know.

11:22 - But yeah, one of the reasons you probably don’t want to just try this everywhere– 51% hash rate changes.

11:30 - So what may have been secure against the 51% attack a few years ago would not be today.

11:37 - The Bitcoin mining rate has increased by trillion times– compared to 10 years ago, it’s, I don’t know, trillions or something.

11:46 - You can look it up. Also, 51% attacks don’t really kill Bitcoin.

11:51 - They’re bad. Definitely want to avoid them, but it’s not like, oh, there’s a 51% attack.

11:56 - It’s all over. We’ve got to all switch to, I don’t know, [INAUDIBLE], or something.

12:01 - It more like halts the system. And potentially temporarily.

12:06 - So you don’t want to put your coins at more risk by saying, OK I’m leveraging this 51% attack.

12:13 - But what about 99. 99%? So this is secure against really powerful attackers.

12:20 - Not 2 to the 128, but so powerful that they can easily destroy Bitcoin.

12:25 - So something like this where you could say, look, an attacker would either have to perform 2 to the 128 operations, or perform operations equivalent to mining a million blocks of the current difficulty.

12:37 - Oh, well yeah, Bitcoin only has 600,000 blocks or something and most of those are much easier than current.

12:43 - So if you have an attacker that can reorg to genesis in the span of a few days, yeah.

12:49 - Or it might be overkill to defend against that.

12:52 - Current is the important part. You can’t target previous difficulty.

13:01 - So something like, oh, I’m going to make my address shorter based on the current difficulty is tricky because your UTXO might stay there for a long time.

13:11 - So there is an application to this, which is something I’ve been working on for a while, and it sort of led to this.

13:17 - So if you have a secure accumulator for Bitcoin, so instead of a Merkle tree just using transactions and block.

13:23 - So right now in Bitcoin, you have a Merkle tree of all the transactions.

13:26 - A block going to this Merkle tree structure.

13:29 - You put that Merkle root into the block hash, the block header, and you hash it.

13:33 - And that’s the structure of Bitcoin. But we can also use the same kind of technology to say, instead of keeping track of every UTXO, every coin in the system just in a regular database, we also put this into a kind of Merkle tree accumulator.

13:47 - And this is something that’s working now. It’s pretty cool.

13:51 - And this is a good application for this reduction of security.

13:56 - Where Merkle trees rely on collision resistant hash [INAUDIBLE].

13:59 - So in general, in Merkle trees you say, OK, you add these four aspects– 0, 1, 2 and 3, you add them into this set, and then you hash them together in this way.

14:12 - So you only have one hash at the end. But then people can prove that 0, 1, 2, and 3 were in the original set.

14:18 - So the proof for 0 is 1 5. The proof for 1 is 0 5.

14:22 - The proof for 2 is 3 4, and so on. So if you want to attack it and say, OK, well, there’s a 2 and– I want to insert something, and then prove something I didn’t insert.

14:33 - Well, you need to find two things. So find 2 and 2 prime where 2 is not equal to 2 prime.

14:40 - Find two different elements you want to insert where the hashes are the same, and then you insert one of them, and then you prove the other one.

14:48 - But the proof for the other one is the same.

14:51 - And so now, you’ve sort of broken the security of the system, because you insert this 2, and you prove 2 prime, which is different.

14:59 - And this is a collision attack. So finding two different things that hash to the same thing is a collision attack, which is easier than a regular hash preimage attack.

15:12 - So if you have a 256-bit hash function, it only takes two to the 128 operations to perform this type of attack.

15:22 - Is in contrast to a preimage attack where it takes the full two to the 256.

15:28 - So we can sort of mix these– the mining proof of work and a prevention of these collision attacks.

15:35 - So what you can do is you can say, I’m going to put the block hash confirming a transaction into the UTXO data that goes into this Merkle tree.

15:43 - So now you have got this commitment to the proof of work.

15:46 - So for example, in this two element we were putting there, commits to the proof of work.

15:51 - It also can commit to its position within the tree so the attacker can’t collide with an arbitrary element of the tree.

15:58 - So for example, the hashes are now the number two, because where it is, the block hash that confirms it, and the UTXO [INAUDIBLE] So this makes collision attacks much harder.

16:10 - Because instead of just performing a single hash, sort of an attempt at finding two colliding hashes, you need to mine a block for every attempt.

16:20 - And you can’t reuse this work if every time you try one, it changes the block itself.

16:29 - So it’s these two trees together. You’ve got one Merkle tree that goes into the block hash and another Merkle tree for the UTXO.

16:36 - So now, you’ve change the amount of work you have to do.

16:39 - It’s still a collision attack. It’s still 2 to the 128 operations, or 2 to the n/2 operations, but the operation has changed from a hash, one hash function, to mining an entire block, which currently is 2 to the 70-something hashes.

16:57 - So that is a huge increase, even though, in some sense, it’s still a collision attack.

17:01 - So yeah, if you have 32-byte hashes here, you would need to mine 2 to the 128 blocks to collide.

17:11 - Or just to do a preimage attack, you need to do 2 to the 256 hashes.

17:16 - However, if you reduced your hash length to 16 bytes, well, now you’d need to mine 2 to the 64 blocks to collide, or 2 to the 128 hashes to second preimage.

17:26 - And 2 to the 64 blocks is a lot of blocks– 18 quintillion blocks.

17:33 - So it does seem like, yeah, it’s a reduction in security.

17:38 - But really, is there a meaningful attacker that– are you meaningfully defending against an attacker that can mine 18 quintillion blocks? Doesn’t seem like it.

17:49 - So that’s the general idea I’ve been talking about here.

17:54 - Do we need to reduce hash sizes for these things? No.

17:57 - Is too much security a waste, though? Yeah, it can be.

18:01 - It would be very efficient to reduce the size of these things by half and potentially reduce downloads, and reduce disk storage, and speed things up.

18:09 - That’s a meaningful gain. Maybe more so than addresses are a little bit longer than they need to be, but it’s not like addresses are twice as long or anything.

18:19 - And this is, I think, an interesting idea. And I sort of want to put it out there because it’s something we should think about.

18:25 - Maybe there are places, other places people are working on where there’s proof of work happening.

18:30 - The Bitcoin blockchain keeps going on and doing enormous amounts of work.

18:36 - And maybe we’re wasting some of that work. Maybe we can keep using it for something to increase efficiency.

18:44 - And I’m sure if you looked at the news, or whatever, in the last six months and Bitcoin’s been going up, a lot of people think Bitcoin is really wasteful and it’s totally pointless.

18:57 - I don’t think they’re right about that, but there is things where like, yeah are we using this proof of work? It’s happening.

19:02 - Are we really taking full advantage of it? Can we leverage it for more efficiency and more power in the system? And then I have the sort of– I mean, where you can [INAUDIBLE] there are potentially 16-byte hashes, which might be better.

19:20 - So thanks. I have this out here as sort of an idea.

19:23 - I’m not like, hey, we should reduce security of all these things.

19:27 - But I do think it’s an interesting topic. Where it’s like, hey, are there areas here where we’re leaving some performance on the table.

19:34 - Or potentially paradoxically reducing security by going too far.

19:38 - Like this– OK, so questions, comments, disagreements? And also, yeah, I wanted to reiterate something that [INAUDIBLE] said at the end of the last presentation, I work at the DCI.

19:48 - It’s really cool. If you’re interested in this kind of stuff, get in touch.

19:54 - This is a GitHub link of one of the things I’m working on.

19:56 - You can look at it. Get in contact.

20:00 - We’re pretty cool. Everything’s remote now so if you’re in whatever part of the world, that really doesn’t make much difference.

20:06 - So yeah, thanks. Cool. Should I start answering– there’s questions on this? We have some questions from the audience, I’ll ask them to you to save yourself the logistics there.

20:17 - OK. So one of our questions is, would you suggest saving the state of the blockchain in some way to reduce resource consumption? Yeah, so I didn’t go into this, maybe, not enough here, where the idea of the Utreexo project, this accumulator I’m working on with a bunch of other open source contributors, is great.

20:42 - The idea is, it’s sort of like pruning the entire UTXO set.

20:47 - So currently in Bitcoin, you can store the whole blockchain, which is 350 gigs.

20:51 - Or you can prune it and say, look, once I’ve got the blockchain, I don’t really need to keep it around.

20:55 - I can delete most of it. And you store the UTXO set, which is about four-something gigabytes.

21:01 - The current state of who owns what. And this basically prunes that as well.

21:05 - Utreexo says, OK, don’t store the UTXO set either, store basically a little Merkle root up.

21:11 - And it’s not quite just a Merkle root but it’s less than a kilobyte.

21:15 - It’s very small. And then transactions prove that the UTXOs they’re spending exist.

21:21 - With these Merkle proofs. And so that’s one example of where we can potentially leverage smaller proofs.

21:30 - So yeah, so it is a different way to pruning the UTXO sets.

21:34 - So now, you don’t need the blockchain. You don’t need the UTXO set.

21:37 - You can run a full node in a very small amount of space.

21:40 - And that’s what our code currently does. So if you’re interested check it out.

21:43 - OK. We have time for about two more questions.

21:47 - So the next question is, converse to what you were saying about reducing the hash size, isn’t increasing the hash size supposed to future proof the system instead? Well, maybe.

22:06 - So it’s sort of like, well you can’t. In that you could say, let’s make a new system and we’re going to put something in Bitcoin where we have 512-bit PubKey hashes or something, or we use an elliptic curve that’s 400 or 500 bits long, or something, and double the security.

22:25 - Well, OK, but you still have almost everyone using the previous part of the system.

22:32 - So if someone makes a computer that can derive a private key from a public key, which takes 2 to the 128 [? EC-OPS, ?] or something like that, yeah, maybe you’re safe, but everyone else isn’t.

22:46 - And so really, the whole system is broken. You’re not alone.

22:51 - And so you’re like, if you’re saying, I’m going to make my bitcoins twice as secure as everyone else’s, it sort of doesn’t work.

22:58 - Because if everyone else’s bitcoins get stolen, it’s not worth much to say, well, I still have mine.

23:04 - Because now, bitcoins have just all been stolen, and everyone just leaves the system.

23:11 - So there may be ways to upgrade, but you kind of need– maybe not everyone, but almost everyone– to upgrade.

23:17 - Because if there’s 5 million coins out of the 21 million that are stealable with this new computer, the system pretty in trouble.

23:27 - We’ve got two more questions. The next one is, what about quantum computers? Is Bitcoin ready for that? Right now, no.

23:36 - Definitely not. If you have a quantum computer, you can grab all Satoshi’s coins from Craig Wright or whatever.

23:43 - There’s so many unhashed public keys that are known that have enormous amounts of coins.

23:51 - And so you sort of pick one and perform the– [INAUDIBLE],, I always get them mixed up.

23:59 - You perform that attack, and then you take all the coins.

24:04 - So no, right now it’s not. There could be.

24:10 - A system like Bitcoin would be pretty amenable to quantum safes.

24:14 - So we know a bunch of quantum-same signature schemes.

24:16 - So we could use that. They’re worse in that they’re bigger and slower and stuff.

24:20 - But you could do it. But yeah, the question of upgrading is very difficult.

24:26 - You sort of have to change everyone’s keys because, if there’s still five or six million coins, even if it’s only a quarter of the coins out there that are now stealable, it’s like, wow, is this system really going to survive that? There’s also a question of quantum computers and proof of work.

24:41 - How do those interact? So right now, no.

24:44 - It’s something people are sort of thinking about.

24:46 - But it’s hard because you got to upgrade everyone.

24:48 - But it maybe is the case where if a quantum computer comes out or it’s imminent, it’s scary enough that almost everyone sort of moves.

24:55 - And then we make some kind of software to say, OK, all these old guys are now frozen forever.

24:59 - And it would be very disruptive. But it’s probably something that can be survived.

25:02 - But we’re not really planning for that right now.

25:07 - Really. Great. Thank you, Tadge, for your thoughts on Bitcoin’s future security.

25:15 - Our next panel is with Michael Perkin. Also talking about Bitcoin security.

25:23 - Joined by Jameson Lopp, Jimmy Song, and Michael Flaxman.

25:28 - We’ll be back in a few minutes with the Bitcoin security and privacy panel.

25:34 -.