Episode 34: Scaling Bitcoin With The Erlay Protocol

Aaron van Wirdum Live from Utrecht, this is the Van Wirdum Sjorsnado.

Sjors Provoost Hello again.

Aaron van Wirdum We've done it again, Sjors.

Sjors Provoost We've done it again.

Aaron van Wirdum We recorded the whole episode without actually recording it. Yeah. So we're going to do the whole thing over.

Sjors Provoost It's this thing where you press the button, but you don't press it hard enough. And you have to check if the red light is blinking. It is now.

Aaron van Wirdum Great. I think you have a bit of news, some exciting news for us.

Sjors Provoost That's right. You can now stream your sats to us. Yeah, you can. It's very cool.

Aaron van Wirdum How does that work?

Sjors Provoost So there's this thing called podcasting.

Aaron van Wirdum And us is our podcast. Us is the Van Wirdum Sjorsnado.

Sjors Provoost That's right.

Aaron van Wirdum You can stream sats to Sjors and me.

Sjors Provoost That's right. Uh, the… the way it works is this standard called podcasting 2.0. So for those who don't know, a podcast is essentially just an RSS feed with a bunch of information like the title and a nice picture. And for every episode, a link to some MP3 file that your podcast player downloads. But it turns out you can add more stuff to this RSS feed than Adam Curry, the original podcaster. He basically started a project called Podcasting 2.0, which adds a bunch of new fields. And one of those new fields is called value. And this value field lets you add, for example, a Lightning node public key to the RSS feed of your podcast. And then if you have a podcast player that understands this, like a normal podcast player will just ignore it, but a player like in the Breez iOS TestFlight app, I think also like in the Sphinx app, if they understand it, they will, and they have Lightning available, they'll start streaming sats to you as the people are listening. And you can suggest a rate, but people can choose it themselves.

Aaron van Wirdum So people can either listen for free or they can pay us.

Sjors Provoost That's right.

Aaron van Wirdum Well, let's see what they choose.

Sjors Provoost So, not only that they can… they can listen for free in a really you know, well-functioning uh, app maintained by Apple or they can use very experimental software and like have to deal with Lightning and… and then pay us. Um, we'll see which… which people prefer.

Aaron van Wirdum Sounds like we're going to be stacking sats, Sjors.

Sjors Provoost Yeah. I think the last time I checked the node, it was zero sats in it, but it's only been live for a couple hours.

Aaron van Wirdum The other thing I wanted to mention is people keep pinging me about the coin flip. Did you hear about the coin flip?

Sjors Provoost I did because you just told me in the previous take. But tell me again.

Aaron van Wirdum I'm trying to pretend a little bit like this is an original episode.

Sjors Provoost All right. I'll try that.

Aaron van Wirdum So the Speedy Trial… the discussion was winding down to block height or block time, which we discussed in our episode about Speedy Trial.

Sjors Provoost That's right.

Aaron van Wirdum That was about Taproot activation.

Sjors Provoost And the difference is basically, at least I find block height a little bit easier to understand, but the existing software so far in BIP 9 have all used block height, which is fine.

Aaron van Wirdum No, block time.

Sjors Provoost Block time, sorry, which is fine. It's just a little bit more difficult to think about, but in terms of code, I don't think it matters that much. So there's now two pull requests.

Aaron van Wirdum Yeah, and it looks like it's going to be the block time one based on a blockchain-based coin flip they did.

Sjors Provoost That's amazing, even though, you know, they can be gamed.

Aaron van Wirdum This was mentioned on the IRC chat as well. But, you know, it would be pretty expensive to game it.

Sjors Provoost Well, the future is at stake, right?

Aaron van Wirdum The future of Bitcoin is at stake.

Sjors Provoost Okay, but I'm glad somebody did a coin.

Aaron van Wirdum There's been a couple of [unclear] by now, so we'll have to see. This is not what our episode is about.

Sjors Provoost That's right.

Aaron van Wirdum Our episode, this episode, episode 34, I think, is about Erlay.

Sjors Provoost Erlay.

Aaron van Wirdum So Erlay is a project. I think it was started at the University of British Columbia, or at least University of British Columbia researchers. Gleb Naumenko, Alexandra Fedorova, and Ivan Beschastnikh were working on it, as well as Blockstream's Pieter Wuille and Greg Maxwell.

Sjors Provoost Yeah, Greg Maxwell is a Blockstream veteran.

Aaron van Wirdum Yeah, well, when the project started, maybe he was still there. I'm not actually...

Sjors Provoost No, he uses his personal email, so he might have been after. Okay.

Aaron van Wirdum So, yeah, Erlay, it's... The problem it solves, so the problem, Sjors, is that nodes use bandwidth.

Sjors Provoost Lots of bandwidth.

Aaron van Wirdum Yes, and this is a problem because we want people to be able to run full nodes. And if full nodes use bandwidth and bandwidth costs money, the more bandwidth means it's more expensive to run a full node, which means fewer people will run full nodes or at least they'll be incentivized not to. It would be good if we could reduce the cost of running a full node.

Sjors Provoost That's right.

Aaron van Wirdum So it would be good if we could find ways to make it cheaper to run full nodes, which means if we could find ways to reduce bandwidth use.

Sjors Provoost That's right. And we previously talked about downloading the blockchain as a source of bandwidth use. And we talked about some ways to make that smarter. But now we're going to talk about basically the transactions that are not yet in a block, the mempool.

Aaron van Wirdum Yes. So I want to finish the benefits, basically, or the problem we're solving. So part one is it would be good if we could reduce bandwidth. Or if people choose to keep using the amount of bandwidth they're currently using, if we could further optimize the efficiency there, then we could make sure… then we could have nodes connect to more other nodes.

Sjors Provoost Yes.

Aaron van Wirdum Which would in turn benefit network robustness. It would counter certain types of attacks like eclipse attacks.

Sjors Provoost Yeah, because we talked about eclipse attacks in earlier episodes and one of the solutions we already mentioned is well, just connect to more peers, and there is a big downside to that which we'll explain then I guess in a bit.

Aaron van Wirdum Yeah.

Sjors Provoost In terms of bandwidth use.

Aaron van Wirdum Yeah. So if we could optimize bandwidth use, that means people can either run a full node more cheaply or they can connect two more nodes, which counter certain types of [unclear] or bit of both.

Sjors Provoost Yeah.

Aaron van Wirdum That's what we're trying to do is reduce bandwidth use. So you already mentioned this. There's basically two main things that cause bandwidth. One of them is: forwarding… receiving and forwarding blocks blocks… themselves, and this is what the blockchain consists of. And the other thing is receiving and forwarding transactions.

Sjors Provoost That's right, before they are in the block.

Aaron van Wirdum Yeah. So, yeah, this is how transactions find their way over a network, which ultimately is how they find their way to miners so they know which transactions they can include in blocks.

Sjors Provoost Yeah, so every node has a thing called the mempool, which is where they keep track of transactions that aren't in a block yet, and they relay those to their peers. And you might say well, why… why would you do that? Well, there's some selfish interest, as in you want to know as soon as somebody is about to send you a transaction. You want to know as soon as somebody is about to cheat on you on Lightning. So it's nice to know that these transactions might start happening before they're in a block. But there's also an altruistic reason, like if nobody did this, then transactions would not get the miners because you'd have to know which nodes are the miners and send it directly to them. And so, especially because it's altruistic, you want to make it cheap or get a lot of value out of it.

Aaron van Wirdum Right. So, receiving and sending transactions over the network. Not the blocks, the transactions. How does this actually… actually work on the technical level?

Sjors Provoost Well, basically you just scream. That's kind of what it boils down to. I mean, you… you hear about a transaction. It's like, oh my God, everybody, did you know about this transaction? So literally, you know, you might be connected to I don't know, eight… eight peers outbound or even more inbound. And if you hear it from your first peer you will tell… tell all your other peers about it. And this is called flooding. So everybody just tells, gossips the transaction to as many nodes as they can. This uses an enormous amount of bandwidth, but it's very robust. Like it's very likely for a transaction to make it through and it will make it through very fast.

Aaron van Wirdum Yeah, well, it's a little bit more nuanced than that, I think, right? Because you send transaction IDs first.

Sjors Provoost Right, so there is some optimizations because what I just described would be sending the whole transaction. That would use a lot of bandwidth. But what you could do instead and what nodes actually do instead is sending short IDs, which is just a very short hash of the transaction. Not even the normal transaction ID, but something even smaller. And then when a node receives those, they can say, okay, I don't know about these ones. Tell me more. And then you give the whole transaction. So there's some back and forth, and this saves bandwidth, but it's a one-off saving. So maybe it reduces the total bandwidth by a factor of four. But that's it.

Aaron van Wirdum Right. To make this very explicit, what happens is I receive a transaction ID or a short version of a transaction ID, which is a hash of a transaction and then I guess an even shorter version of that. I check this against all of the transactions I have in my mempool. If I don't have it yet, then I get back to the nodes that send me the ID and I tell them, hey, send me this whole transaction. I haven't seen this yet. This node sends me the whole transaction. Now I turn to all my other peers and I send them this ID. And then some of these peers will get back to me and tell me I don't have this transaction either. Send it to me as well please. Yeah, and that's how it's forwarded. Or if they have it already then I'm not going to send them the whole transaction. I'm just you know, I send them the ID. They checked it, they already have it, so we're good. Yeah, um, now what happens is that this last example where I send out an ID and my peer already has that transaction that actually happens a lot, because you know, they are connected to so many other peers as well, and odds are they already got it from someone else. So it happens a lot, that these transaction IDs are basically sent for you know, for nothing. They're… they already had the transaction. So this is in a way wasted bandwidth. I'm sending this transaction ID to them, they're receiving it, but they already had the whole transaction. So I'm sending the ID for no good reason.

Sjors Provoost Yeah, and it's good to realize that it's kind of impossible… to at least naively impossible, to prevent that waste. But we can get into how much of that waste it is, but compared to the most ideal scenario where ideal, like a theoretical ideal scenario which is bad for decentralization reasons, but… If everybody just downloaded the transactions from a central website, well, that would be the most efficient way to do it in terms of data usage. But of course, we don't want to have a central website.

Aaron van Wirdum Right. Yeah, the numbers are, I think, more than half of all bandwidth that a node is using are these transaction IDs, sharing these transaction IDs. And then if they run the numbers at some point, and I think about 44% of a total bandwidth use of a node is basically waste… Are these transaction IDs that…

Sjors Provoost Are telling people what they already know.

Aaron van Wirdum Exactly.

Sjors Provoost Okay.

Aaron van Wirdum So this 44%, that's what we're going to try to bring down with Erlay.

Sjors Provoost That's right.

Aaron van Wirdum That's what Erlay tries to bring down. Now, Erlay, in order to bring that down, it uses something called Minisketch, right?

Sjors Provoost Yeah, it basically does two things, I guess, two general things. One is it still uses this flooding that we just described, and the other is it uses Minisketch.

Aaron van Wirdum Right. So what is Minisketch?

Sjors Provoost Yeah, the flooding is reduced, so it's only flooding now between publicly reachable nodes. And the general idea is that some nodes can be reached from the internet. They, you know, [unclear] is known, and other nodes are probably behind a firewall or just they have a privacy setting on and they're not reachable. But the idea is that every node that is… every node that is not reachable will connect to a node that is reachable, or almost everyone, unless you do it manually, right? Because otherwise, how do you connect to the rest of the network? So then the idea is that as long as all these reachable nodes… Have like, flood a lot between each other, then at least all the unreachable nodes are just one hop away from all the transaction data. So that's sort of the first step where it gets a little bit, you know, where you reduce the flooding to a smaller group of people. And then the second thing you do is, and this is the cool part, is the Minisketch.

Aaron van Wirdum Right. So what's Minisketch?

Sjors Provoost Okay. So the goal of Minisketch is to do set reconciliation.

Aaron van Wirdum What is set reconciliation?

Sjors Provoost Right, So a set is basically just a bag of stuff. In this case, the contents of your mempool. So the list of all your transactions, that's a set. Or the list of all the short IDs of your transactions is a set or whatever. And I have a mempool. So I have a set and you have a mempool. So you have a set. And then the question is, what is the difference between these sets? What are the transactions that I have that you don't have and that you have that I don't have? And that's probably just a fraction of the mempool. So that challenge in computer science is just called set reconciliation, trying to find out what the difference is and then trying for both of us to get the same set eventually.

Aaron van Wirdum Right.

Sjors Provoost Sending the least amount of data over and back and forth.

Aaron van Wirdum So one way we could do that is you just send all of the transactions you have in your mempool to me. I compare all of your transactions to all of my transactions. I can easily tell the difference and send you the transactions that you didn't have yet. Keep the transactions from yours that I didn't have, and now the sets are reconciled.

Sjors Provoost That is one way to do it. That is worse than what we just described with flooding.

Aaron van Wirdum Yes, this is a very resource-intensive thing to do. So... We're using something more clever than this. But this is the general principle. We're just using something mathematically more clever.

Sjors Provoost Exactly. So the mathematical clever thing is this. You take your... And this is where we're going to get extremely hand-wavy because I do not actually know or understand the moon math involved.

Aaron van Wirdum God knows I don't either.

Sjors Provoost No. That's okay, though. So the idea is I take my mempool, the set, and I do some math on it. And the end result is a little, maybe, I don't know, one kilobyte object or two kilobyte or whatever. Some small object compared to the rest of the mempool. And you do the same type of operation and you end up with maybe one kilobyte object. And now I send you my one kilobyte object. This is called the sketch. So I'm sending you my sketch. And that's just a tiny thing. You receive the sketch. And now the math says that if the difference between our two mempools was actually less than the size of the sketch, so if that was true, then you can actually figure out exactly which transactions are missing on either side. Only then. So if it… if the difference is bigger then you get gibberish. You don't know anything. But if the difference is the same or smaller, you can actually reconstruct which transactions I am missing and which transaction you're missing. And then the procedure is pretty simple, right? Your node will just give me the transactions that it knows I need. And it will ask for the transactions that it needs.

Aaron van Wirdum Right. So for some absurd reason, we have completely different mempools, then this won't work very well?

Sjors Provoost No. And the good thing, of course, about the mempool is that because you're syncing it all the time… And because there are rules about highest fee things are more important, it's actually fairly predictable what the mempool of other people are going to look like. So for the most part, it's going to be the same. So then it's just a matter of finding the right parameters to use with the sketch. How big do you want to make the sketches so that most of the time people will actually find the difference, but not so big that it just weighs more bandwidth than the flooding protocol. And that's sort of what the paper went into with simulations.

Aaron van Wirdum Yeah, so if it's close enough, then I can figure out which transactions are the difference, and we can reconcile just these transactions.

Sjors Provoost Yeah.

Aaron van Wirdum So without getting into the moon math specifically, I know there's been some other examples where this kind of math has been used.

Sjors Provoost Yeah, so it's interesting, and I only learned this today, maybe wrong on some of the stuff, but it refers to something called... What was it? Fuzzy [unclear], I think was the term.

Aaron van Wirdum I think so.

Sjors Provoost So it refers to an older paper from, I think, 2004, 2008,

Aaron van Wirdum This predates… the trick predates Bitcoin, basically.

Sjors Provoost Yeah, and I'm sure the general principle is even older. But the idea there is that, or the problem they were trying to solve was... For example, biometric identification.

Aaron van Wirdum Like fingerprints.

Sjors Provoost Yes. So if I want to go to my moon base and I want to enter the moon base, they want my fingerprint.

Aaron van Wirdum Of course.

Sjors Provoost But I don't want them to have a database.

Aaron van Wirdum Everyone knows you can't get into your moon base without a fingerprint.

Sjors Provoost Right. But I don't want them to have a database of my fingerprint. I don't want them to have a photo of my fingerprint. But they're going to need that, naively speaking, because when I put my finger on the little sensor, it's going to take a picture, and that picture is always going to be slightly different than what it was before. So they cannot just store, say, a hash of the image, right? They have to store the image itself and then look at it and say, well, this is so and so much different.

Aaron van Wirdum The reason it's going to be slightly different than before is basically it's a photo, and even if you take a photo of the same object, it's going to be slightly tilted or slightly darker or some pixel is going to be different at least. So it's going to be similar but not literally exactly a copy.

Sjors Provoost Right. Because every single pixel is slightly different. And the same really goes with normal passwords, right? One typo in your password and it just doesn't work anymore.

Aaron van Wirdum Right. So it could work. We could use, you know, take a picture of your fingerprint and then make a new fingerprint and compare it to. However, the problem here is that we don't want a database full of fingerprints because people can steal the database and abuse it and rob banks and leave your fingerprints all over there.

Sjors Provoost And there's another use case where this is an even bigger problem. Which is what if I want to put some Bitcoin on a private key that is generated by my fingerprint. So in this case, there is no database. There is just my fingerprint, and I want to construct a private key from that fingerprint. But if I do that, you know, take a picture on the device and then take the image and turn it into, you know, you can put the image literally on a COLDCARD and that's its entropy and it'll give you a set of private keys. And then if I repeat that, it'll give me a different set of private keys. So that'd be quite bad. And so it'd be nice, however, if you could do this in a way. And that's kind of what that original paper described, a way to do that. So it would take certain properties of the fingerprint or the iris scan, doesn't really matter what. And then it would create a sketch of your fingerprint.

Aaron van Wirdum Right. That's where the term sketch comes from.

Sjors Provoost Yeah.

Aaron van Wirdum It's a mathematical sketch, basically.

Sjors Provoost Yeah. A mathematical sketch of your fingerprint, which is not the same as a hash, but it is some sort of summary of it. But if you have that sketch, you cannot reconstruct a fingerprint. So it is similar to a hash and then you can't go back. It's a one-way function. But it is slightly more… it has a little bit more useful information than a hash does and it's very small. So what the Moonbase does, or what the

Aaron van Wirdum iPhone…

Sjors Provoost Yeah, what the iPhone would do, is it would store this sketch, and then when you reappear and you put your fingerprint on the sensor, it's now going to make a sketch of this new fingerprint. And then, because of what we just talked about, if those sketches are similar enough, you can actually reconstruct the difference. In other words, in the case of the Moonbase, you can say, hey, I can reconstruct the difference, therefore I think this difference is small enough. It's the real person. It's the real fingerprint. Or in the case of the private key, you can actually, because you stored a sketch of the original fingerprint, you can now, using the other fingerprint, essentially, your second fingerprint, and this original sketch, so you make a sketch of the new one, you can actually reconstruct the exact... sort of image that you would have had the first time around. And so you do get the same entropy. And so you can use your fingerprint to store your Bitcoin. Don't do this, but you could using this methodology.

Aaron van Wirdum And this [unclear]…

Sjors Provoost Yeah, that difference can also be used for mempool comparison.

Aaron van Wirdum Yeah, so this trick for comparing fingerprints is the same mathematical trick that we're now using in the context of Bitcoin for set reconciliation in mempools.

Sjors Provoost Which will make it more efficient to put your node on the moon. And or a full circle. Yeah exactly.

Aaron van Wirdum Okay, how is this actually used in Bitcoin then? What actually happens? So, well, what's sort of the step-by-step process if we're using set reconciliation?

Sjors Provoost Yeah, if this stuff were to be merged, right, in Bitcoin Core, well, the nice thing is it doesn't change any consensus rules, so it's just something people can use or they cannot use it. And you connect to peers, and if those peers support this way of handling things... Then, depending on whether they are public nodes or not, you would either do the original flooding or you would use the sketching. And you would basically exchange… you would keep your mempool synced by using these sketches.

Aaron van Wirdum Right. So instead of constantly sharing every transaction ID you receive with all your peers, now you're also once in a while just sharing a sketch. And based on that… sharing the transactions that you don't share yet.

Sjors Provoost Yeah. And this is so much more efficient that you can have lots and lots of peers with which you are exchanging these sketches far more than you could if you were using the flooding.

Aaron van Wirdum Right.

Sjors Provoost So you use flooding with a subset of your peers or not at all. And you use the sketches otherwise. And if the sketch somehow fails, there's a little fallback that's described in the protocol that says, well, if the sketch is too big, you can try something like half the sketch again and overlap those. And so you can do a second attempt if the difference is just a little bit bigger. And then if you give up, if it fails again because the difference was too big, great, you just fall back to the original flooding protocol. So that's kind of what it does. And there's a pull request on it. There's a BIP out there.

Aaron van Wirdum Yeah, this is… an actual, because it sounds very hypothetical, but this is actually something that's being developed and that could be merged into Bitcoin Core?

Sjors Provoost Right now.

Aaron van Wirdum Soonish.

Sjors Provoost I looked at the, only briefly looked at the pull request and it looks like most of the things are in there. But of course I haven't tested it or thoroughly reviewed it. So, but my guess is it'll happen.

Aaron van Wirdum All right.

Sjors Provoost Or maybe not if there's a huge problem, of course, but as far as I'm concerned, it sounds pretty good.

Aaron van Wirdum Yeah. Clear so far. Anything else?

Sjors Provoost I don't think so. That's all we got.

Aaron van Wirdum All right.

Sjors Provoost So thank you for listening to the Van Wirdum Sjorsnado.

Aaron van Wirdum There you go.