Episode 77: Peer-to-peer Encryption

Aaron van Wirdum Live from Utrecht, this is Bitcoin

Sjors Provoost Explained.

Aaron van Wirdum Sjors, you were just telling me that one of the reasons you came up with the topic for this episode, which is BIP 324, peer-to-peer encryption, right? One of the reasons you came up with that is because you had a call with other Bitcoin developers about this.

Sjors Provoost Yeah, that's right.

Aaron van Wirdum Sjors, since when do Bitcoin Core developers call? What is this?

Sjors Provoost Very rarely.

Aaron van Wirdum What is happening? I know Bitcoin developers as... IRC wizards and they're on a call now that sounds like Ethereum Bitcoin Cash type of communication what's going on?

Sjors Provoost No, so the idea would be to put these calls on some sort of podcast or feed if the Optech folks are organizing it So…

Aaron van Wirdum So, okay so what is this tell me more?

Sjors Provoost No, it's basically just a short lecture by the people who are working on a project so the people who work…

Aaron van Wirdum So it's like an educational type of thing?

Sjors Provoost Yeah, but then, of course, the idea is to get some feedback from people and to encourage them to start reviewing it.

Aaron van Wirdum So is it like online bit devs? How am I supposed to think about this?

Sjors Provoost Maybe you could see it as an online Socratic small seminar with fewer people talking.

Aaron van Wirdum Okay. Is this new?

Sjors Provoost I think it's very new. At least I was only invited very recently, so who knows?

Aaron van Wirdum Okay.

Sjors Provoost Maybe it's a third level, what is it called? oh yeah Illuminati.

Aaron van Wirdum Yeah, it's like this invite only thing where you're you're you enter the the inner ring now.

Sjors Provoost The Bilderberg exactly.

Aaron van Wirdum Yeah, so we're gonna oh no before we get to peer-to-peer encryption of course first everyone's favorite part of the episode Sjors stacks sats where you read boostagrams

Sjors Provoost That's right.

Aaron van Wirdum Sjors stacks sats. Sjors stacks sats, Sjors stacks sats.

Sjors Provoost This is a shame that we don't have video. Okay, we have one from AdFake for 3,000 satoshis saying Mike in Space has finally done something noteworthy.

Aaron van Wirdum Haha. Okay, I'm going to give you an outro tune as well because otherwise... it's a bit awkward to get back to the rest of the episode so

Sjors Provoost No, I think it's fine.

Aaron van Wirdum Sjors stacks sats. No, see this is better now we can go All right now everyone knows that the Sjors Stacks Sats part of the episode is over and we get to business so business today Sjors, is BIP 324 324 peer-to-peer encryption

Sjors Provoost That's right.

Aaron van Wirdum a little bit of background on this… is this used to be called BIP 151, 151, right? And it used to be Jonas Schnelli's project. Jonas Schnelli retired as Bitcoin Core Developer. And the project is now led by Dhruv. Am I saying his name right? Yeah, so it's Dhruv, Pieter Wuille, aka sipa, and Tim Ruffing. And all three names are on the BIP. So it's the three of them are working on this. Okay, great. So yeah, so they picked up the project from Jonas when he left and they rebranded it or renamed it or they got a new BIP. So now it's BIP 324. Do you know why?

Sjors Provoost Yeah, I think it's because enough of the things about the proposal have changed that it was worth just giving it a whole new BIP number.

Aaron van Wirdum Also, do you know why 324?

Sjors Provoost No.

Aaron van Wirdum That would require you to get into Luke Dashjr's… mind. I think there's a logic to the numbers somewhere in his brain. Yeah, but I don't think anyone else in the world knows it.

Sjors Provoost We did an episode about the coin improvement process basically but we did not go into numerology for the same reason we didn't go into numerology for Ordinals.

Aaron van Wirdum Right, okay so let's get going then. Why, so we're talking about, I guess we always start with like a very short two sentence explanation of what we're even talking about. So what we're talking about is encrypting communication between Bitcoin nodes, right? So right now nodes don't encrypt. So nodes send, I think, three things between each other, which are blocks, transactions, and each other's IP addresses, right? IP addresses of other nodes.

Sjors Provoost Pretty much.

Aaron van Wirdum And right now they do all of this unencrypted.

Sjors Provoost That's right.

Aaron van Wirdum Now the idea is to encrypt this. So that's very short sort of bird's eye.

Sjors Provoost Yeah, exactly. So the, you know, unencrypted traffic is, you know, remember the days when HTTPS was considered a feature, you know, when websites would say, oh my God, we have an HTTPS certificate. Well, before that time, you could just eavesdrop on anything you were doing at a web shop. But Bitcoin Core nodes still use that old method.

Aaron van Wirdum Right.

Sjors Provoost There's reasons for that.

Aaron van Wirdum There's reasons for using the old methods?

Sjors Provoost There's reasons. There's definitely reasons it's not using HTTPS. But it is nice to have some sort of encryption, and that's what I guess we'll get into.

Aaron van Wirdum Okay, so why would that be nice? So what's the problem we're trying to solve, or what's the problem Bitcoin developers are trying to solve?

Sjors Provoost They are spying on us.

Aaron van Wirdum Who is spying on us?

Sjors Provoost They, the government.

Aaron van Wirdum Everyone?

Sjors Provoost All of them. No, so basically the problem is that Bitcoin nodes are talking to each other in a way that anybody with access to the network can eavesdrop on it. And then I especially mean people with physical access to the network. So they could have a machine on the wire. This could be somebody monitoring your home. This could be your internet provider monitoring all their customers. This could be a spy agency monitoring all the internet companies, even without the internet companies knowing that this is happening. They can basically see exactly which node it's sending, which transaction to which other node, if they wanted to. Now, I don't know if they're doing that. Maybe they really don't care. I haven't seen any evidence that they're doing it. I know because they're already, you know, if you look at things like chain analysis, that they're already doing a lot of work, just the hard way. As far as I know, chain analysis is not getting data from the spy agencies.

Aaron van Wirdum Yeah, well, that ties in with the question I was going to ask. The question I was going to ask is, so what if they do? All the data is public anyways, right? It's all going on the blockchain anyways.

Sjors Provoost Well, what's on the blockchain is public, but the question which IP address created a transaction is definitely not public or not supposed to be public, but it is if you look at the transaction. So if I make a transaction on my node and I send it to the nodes around me, then a spy agency that can see all the internet traffic would be able to see basically this transaction exactly where it started. And that, of course, would be very interesting information for them. Right now, as far as I know, the only companies that do these are these chain analytics companies. And they have to do it the hard way. They have to make lots of connections to lots of different nodes and monitor it that way. None of what we're going to discuss is going to make that impossible. But the idea of just looking at the whole network and seeing what's going on, that's the thing we want to prevent.

Aaron van Wirdum Okay. So I'm going to try a concrete example. So if I send a Bitcoin transaction, you know, I spend my own Bitcoin, then that transaction would have to originate from my node. And in that case, my internet service provider, for example, would see that, oh, look, that transaction came from Aaron's node. So these must be Aaron's bitcoins. And that's the type of spying we're talking about, right?

Sjors Provoost Yeah.

Aaron van Wirdum While if that connection from me to the network would be encrypted, then they wouldn't see that that specific transaction originated from me. And the same is true, of course, for miners, for example, who create blocks. We'd like miners to be anonymous on the network. And if an ISP knows where blocks originate, they know where a miner is, right?

Sjors Provoost Yeah, and in a perfect world, they would not be able to do that. Now, this proposal will not get us to the perfect world, but it will get us to a slightly better world. And there's also the issue, that's privacy, I guess. The other issue is censorship, potentially. because this internet provider that saw that transaction coming from you might also think well you know what we don't like this guy we're gonna block just his transactions not everything else and they can do that too they can get in the middle of our basically of the communication between our nodes and they can selectively listen to it let everything through except one or two things that they don't like to let through

Aaron van Wirdum Right yeah these are sort of two sides of the same coin right so it It is because if there's no privacy, then that would also allow specific censorship. Well, if all Bitcoin traffic data, if all the Bitcoin data looks the same, they can't single out transactions and therefore they also can't block certain transactions.

Sjors Provoost Yeah.

Aaron van Wirdum Right? Okay.

Sjors Provoost And then I guess the third category would be things like miners when they are, you know, maybe you could eclipse attack them. So we had an episode about eclipse attacks very early on. which basically boils down to showing one thing to one node and showing other things to other nodes. And the companies that are operating the internet have some power to do that.

Aaron van Wirdum Okay, so that's the problem. I think we've now covered in general lines what the problem is we're trying to solve with peer-to-peer encryption. Is that right?

Sjors Provoost Yep.

Aaron van Wirdum Okay, so what is the solution? The solution is to encrypt data. Is it that simple?

Sjors Provoost Yeah, pretty much. Well, that's at least the beginning of the cat and mouse game. The beginning of the cat and mouse game is to say we're going to encrypt all the data so that when somebody is looking at our internet connection, all they see is noise. They cannot read the individual transactions. They don't even know. At first glance, they don't even know what is a transaction and what is not.

Aaron van Wirdum Okay, so more concretely, how does it work?

Sjors Provoost Okay, so the idea is that when you connect to another peer, You do a handshake with that peer, and that handshake basically creates an encrypted connection between the two of you.

Aaron van Wirdum What is a handshake?

Sjors Provoost A handshake is basically saying, here's my key, and then you say, here's my key.

Aaron van Wirdum Okay.

Sjors Provoost There's a little bit more to it, of course, but the general idea is they call it a Diffie-Hellman key exchange.

Aaron van Wirdum Right.

Sjors Provoost If you Google that, you'll find it. We've talked about it in other podcasts, too. It basically means I get your public key, you get my public key. And we can combine those keys into a shared key, basically a key that both of us know.

Aaron van Wirdum Do you want to try to explain how this works?

Sjors Provoost No.

Aaron van Wirdum I can give it a try. Let's see if this works. Because I think I got a way of explaining it that might actually be sort of understandable over audio even. All right. I'm going to give it a try. Are you ready?

Sjors Provoost Yep.

Aaron van Wirdum Okay, so basically you got a mathematical one-way function, right? So you take a number, we've explained one-way functions. You take a number, you put it through a one-way function, you get a different number.

Sjors Provoost Well, it's not really a one-way function because theoretically you can go both ways. In practice, you can't.

Aaron van Wirdum No, no, I think you don't even know where I'm going with my explanation.

Sjors Provoost Well, we talked about hash functions in another episode about hash functions. Those are actually one-way functions. There is no way back.

Aaron van Wirdum Well, but I mean, that's how, so that's how you derive a public key from a private key, right?

Sjors Provoost No.

Aaron van Wirdum Well, it's definitely a one-way function from a private key to a public key.

Sjors Provoost No, it's a two-way function. The thing is just that the way back is so difficult that in practice you can never go back. That's what we hope in theory.

Aaron van Wirdum Well, that's…

Sjors Provoost But a hash function is really one-way.

Aaron van Wirdum [unclear] that's not a one-way function?

Sjors Provoost Because you can go both ways in theory. Mathematically speaking, it just goes both ways.

Aaron van Wirdum Is this what we discussed and I forgot about it? Did you explain what the difference is?

Sjors Provoost I think I did, yeah.

Aaron van Wirdum Because it sounds the same to me.

Sjors Provoost So a hash function is really one way. Okay. From a private key to a public key is more is easier than from a public key to a private key so you know it's like it's it goes both ways but the toll on the way back is very high.

Aaron van Wirdum Can you excuse me if I call it a one-way function for now?

Sjors Provoost A one-way-ish function.

Aaron van Wirdum Okay, I still think it's a one-way function but all right so you have a number you put it through a one-way-ish function you get a different number right?

Sjors Provoost Yep.

Aaron van Wirdum now if you do it twice you get a different number again.

Sjors Provoost Yes, sure.

Aaron van Wirdum Okay, so what is a public key it's basically a number put through one one-way function right?

Sjors Provoost Yes.

Aaron van Wirdum Okay, so now I take your public key so that's your secret number put through one one-way function and then I multiply it with my own secret number so now what we get is a mix of two secret numbers and one one-way function okay and you can do the same thing right you could take your private key and then you have your secret number and my public key so that's my public so that's my private number yeah so now you got a mix again of two private numbers plus one one-way function the reason no one else can do it is because then the only way they could do it is take two public keys so now they get two private now they get a mix of two private numbers plus two one-way functions so you get a different number That's basically it, right?

Sjors Provoost Yeah, I'm not sure if that made a lot of sense.

Aaron van Wirdum I mean, I'm not sure if people can follow it over audio, but I think it's correct. I think this is the simplest way of explaining it.

Sjors Provoost It could be, but it basically boils down to, yeah, exactly. I know my private key, you know your private key. We don't want to share our own private keys. So I give you my public key, you give me. Your public key and we do the math and basically now we have a shared key.

Aaron van Wirdum Okay, so that's Diffie-Hellman and that's what Bitcoin nodes would use. So practically speaking, does it mean that every Bitcoin node has a public key?

Sjors Provoost No, so that's a big distinction. We are not doing identity here. because that would actually be kind of controversial. Every node should pretty much look like every other node.

Aaron van Wirdum Is this one of the biggest differences or maybe the biggest difference compared to BIP-151? Because from what I recall... BIP-151 did use identity, or that was part of the plan?

Sjors Provoost No, I think it also made a distinction between these two things, but maybe the distinction was done in a slightly different way. But the idea was always that these are separate things.

Aaron van Wirdum Okay, so what then happens instead, I would assume, is every time a node tries to connect to another node, they go for this handshake, which means at that point they generate a new key pair.

Sjors Provoost Yeah, they do it for every connection so if I connect to you and then somebody else connects to you they're all going to see a different key you're not going to present yourself as the same identity.

Aaron van Wirdum Yeah, I'm going to generate keys for every new connection.

Sjors Provoost Yes.

Aaron van Wirdum Okay, so and then establish a new Diffie-Hellman secure connection based on every new key and every new… with every new…

Sjors Provoost Exactly. Right, okay.

Aaron van Wirdum so that's how it works does that solve the problem that we discussed in the first part of the episode?

Sjors Provoost There's a little extra so I mean it's always a cat and mouse game right but so right now what happens if somebody is just passively listening to our traffic all they see in this example would be somebody sending a public key and somebody else sending a public key and after that they just see noise they have no idea what the rest of the traffic is because it's encrypted now you could say that that's a good start because now at least they won't be able to tell which transactions are which but they could still and sort of here's the trade-offs, they could still get in the middle. So because when I connected to you and you connect to me, how do I actually know that it was you? I don't because we don't have identity. So you don't have a public key. You don't have something on your website that says it's me. I just have your IP address. And besides, I'm connecting to random nodes in the internet anyway, right, as a Bitcoin node. So the man in the middle attack is still possible, but this is called an active attack. So if the government or whatever wants to see our traffic, they would have to do it in such a way that I think I'm connecting to you, but I'm really connecting to this government server. And then the government server connects to you and pretends it's coming from me. And that way I'm doing a Diffie-Hellman exchange with the government and you're doing a Diffie-Hellman exchange with the government. Now, this proposal contains a countermeasure to that risk. which is that we could get on a phone call and we could look up this thing called the session ID. And this session ID is just basically saying, well, okay, we have a connection session. And if that number is the same, then we know we are directly connected to each other. If the number is different, that means there's somebody in between us.

Aaron van Wirdum Okay. So I got the first part. I don't think I need to repeat that, right? That was pretty straightforward. I think people probably know what a man in the middle attack is, even the name reveals it.

Sjors Provoost Yeah. In this case, I was making a government in the middle attack.

Aaron van Wirdum Right.

Sjors Provoost But yes.

Aaron van Wirdum And then you said one of the ways to solve it is... I don't know.

Sjors Provoost So you're not preventing it.

Aaron van Wirdum Yeah.

Sjors Provoost But first of all, it's more expensive because the government can no longer or whoever's eavesdropping can no longer just listen. Like don't just put their ears on the cable. They have to actually install a computer that actually does all the handshaking. So it takes some CPU power, takes some much more work. And if they do it because of this session ID, if we communicate outside of the protocol, we can compare nodes and then we can see that there's somebody in between.

Aaron van Wirdum Right. I guess this...

Sjors Provoost It's very similar to how it works with Signal. For example, if you add somebody as a contact on Signal, you show each other a QR code and that is really a way to see that, okay, my Signal device app is actually connected directly to your Signal app and there's nobody in between.

Aaron van Wirdum Yeah.

Sjors Provoost You have to do in person or on the phone.

Aaron van Wirdum Serial number kind of thing.

Sjors Provoost Yeah, exactly.

Aaron van Wirdum Okay. This sounds like a theoretical thing because no one's actually going to get on the phone to see if we have the same Bitcoin node.

Sjors Provoost So the good thing here is that if the government wants to surveil everyone then there's going to be some people that will do this and then they can actually say hey this is happening and then they can make a bunch of noise so this is relying on an incentive for governments to not get caught doing this so it's a more work and b they would not be able to do it undetected right now they can do it undetected right

Aaron van Wirdum Okay so it sounds so this is what it sounds like if a government really wants to spy on you on your node on your node traffic or an ISP or they they would still be able to do that however it would require more resources so right now they don't need to do anything extra they're just kind of spying on you by default just the only thing they got to do is you know point their eyeball towards the data and then they can see what's going on yeah And if this peer-to -peer encryption would be deployed, then they would actually have to install stuff and sync the blockchain.

Sjors Provoost Maybe not sync the blockchain, but they definitely have to do some work there. And you would be able to see that it's happening.

Aaron van Wirdum And then potentially, yeah, if people would actually get on the phone call, which is something that you might do.

Sjors Provoost Again, only a small number of people have to do this to catch them. Now, of course, we're still not in paradise because we just said that the government, when they're looking at our channel, I don't want to make this sound like Lightning, but looking at our connection, all they're seeing is noise. But it does turn out the cat and mouse game doesn't end there. Noise still has patterns to it. So for example, if I'm sending you a transaction, that's a very small little thing. If I'm sending you a block, that tends to be a bigger thing. And those blocks also are all sent around the same time. So I could guess that I was sending you a block. Just by looking at, you know, I'm looking, you know, the government might be running their own node. They see, oh, there's a new block coming in. And right around that time, there's a lot of noise on all these different connections. Well, what would that be? So then at least they'll know that these people are running a Bitcoin node. Also because they're all running on port 8333, which is a bit obvious.

Aaron van Wirdum Yeah, we also discussed that in another episode.

Sjors Provoost But again, it's already an improvement, right? So port 8333 is something you can change. But right now, whatever port you're running on, the first thing you say when you connect to another node is, I think it's literally the word Bitcoin. So a ISP just has to listen for the word Bitcoin on any connection and then know that it's Bitcoin. And with this, they would not. Now, in order to make it impossible for a government to even look at these patterns.

Aaron van Wirdum Wait, maybe there's something worth pointing out. Why? wouldn't that still be the first word? Why wouldn't you still, you first need to know that you're talking with another Bitcoin node, right?

Sjors Provoost Yeah, so here is where the handshake, we should probably go into a little bit more detail about what that handshake looks like.

Aaron van Wirdum Okay, yeah.

Sjors Provoost So instead of saying, hello, I'm a Bitcoin node, would you like to talk to me? What I'm going to do is I'm going to send you somewhere between 64 bytes and I think two and a half kilobytes of what looks like completely random data. But again, what looks like completely random data. And then you will send me also completely random data between 64 bytes and two and a half kilobytes.

Aaron van Wirdum Right.

Sjors Provoost And part of this data that looks like noise is your public key. In fact, it's the start of the data. So the first 64 bytes are going to be your public key and the other way around. And then the rest is called garbage. And there's a little trick that, well, doesn't really matter, I guess. But basically I take the first 64 bytes and I know it's a public key and then I'm going to treat it as a public key. I'm going to treat it as a Diffie-Hellman exchange. And that actually allows me to also read the rest of the stuff that you're sending me, this garbage. And then I know, okay, we're done with a handshake and then we do our usual protocol.

Aaron van Wirdum Right. So what's in the rest of the stuff?

Sjors Provoost So an outside observer will just see randomness.

Aaron van Wirdum Yeah.

Sjors Provoost but you will actually know that it's a public key.

Aaron van Wirdum And what's in the rest of the stuff?

Sjors Provoost Garbage, literally, like random stuff or zeros.

Aaron van Wirdum Oh, I thought you said that you can decrypt the rest.

Sjors Provoost Yeah, so I think my understanding is that the garbage itself, you can still decrypt it and then you can check that it is nothing. basically, but there's a difference between something that's encrypted, but it's empty. Like basically you write a piece of empty text and you encrypt it. And if I decrypt it and I see an empty text, then I know you actually encrypted it. It wasn't real garbage. Now, the reason we don't do it more simply is because if I just sent you 64 bytes and you just sent me 64 bytes, then any government again can see, oh, well, a Bitcoin node is anything that sends 64 bytes and then replies with 64 bytes. So to make that more difficult, this garbage is added. So the packages can be larger, can be smaller. But there has to be a way for you to know when the garbage ends and when the real communication starts.

Aaron van Wirdum Okay, what's the goal here? Because I thought the goal was not necessarily to hide that you are a Bitcoin node that is doing Bitcoin-y stuff. But I thought the goal was to hide what Bitcoin-y stuff exactly.

Sjors Provoost The goal is to make it possible to completely hide in the long run. To completely hide that you're doing Bitcoin stuff.

Aaron van Wirdum In the long run. So what else would be necessary for that? But that's not where we are now.

Sjors Provoost No, the general thing that you're going to need for that is called traffic shaping. And traffic shaping means that instead of sending your data the most efficient way possible, so I need to send you a block, I'm just going to send you one megabyte as fast as I can. What you do instead is know you're going to make it look like something else. So instead of sending you the block very quickly, I'm going to send it very slowly. And instead of sending you individual transactions, maybe I'm always going to send you 10 bytes per minute. And sometimes those 10 bytes are empty. Sometimes those 10 bytes are actual things. So I'm just going to look like something else. Maybe I'm going to send a signal to you looking like a YouTube video. And then... So that's basically the goal. And in order to be able to do that, Bitcoin Core might not be doing that itself. Maybe there would be some additional software that's doing that on top of Bitcoin Core. But in order to do that, it has to have very moldable material, like clay, basically. So it has to be able to change everything. It has to be able to make messages longer, make them shorter. Well, not too much shorter. So the function of this garbage in the beginning is just to have this extra space that you could use if you need it. in order to hide what you're trying to do.

Aaron van Wirdum Interesting, okay.

Sjors Provoost And beyond that you can also you don't have to send everything at once so you can in the future you should be able to send 10 bytes and then nothing and then 10 bytes and then another 10 bytes so that even the handshake would be broken up into smaller pieces or make part of a bigger piece whatever is necessary to hide from the censors.

Aaron van Wirdum Okay, so that's the long-term plan but for now so for if this is implemented if this BIP… This peer-to-peer encryption is implemented. Where that would bring us is basically ISPs and spies. They can still see that you are a Bitcoin node communicating with other Bitcoin nodes, but they can't see what you're communicating exactly, right? That's where we would be with this proposal.

Sjors Provoost They already have to start doing some homework, yes. And that homework is, you know, the Great Firewall of China should have no problem doing this. It's kind of their job, but your average home internet provider might not be used to this.

Aaron van Wirdum So what happens? So let's say this is deployed. What happens? And then you send this blob of, you know, apparently it's public key and some nonsense, but I'm not upgraded yet. So what happens then?

Sjors Provoost Yeah, so there's two steps here. One is that you can use the DNS seeds that we've talked about in one of the first episodes to find other peers that have this feature enabled. However, you cannot really trust DNS seeds. And more importantly, somebody can mess with the information provided that way. So first of all, you'll try to connect to peers that can actually support it. But then what happens is basically you send your 64 bytes. If the peer that you're talking to does not understand this protocol, it will just hang up. It's like, this is not a valid Bitcoin connection, bye.

Aaron van Wirdum Leave me alone.

Sjors Provoost Well, yes. And then the protocol suggests, or really that's what the implementation does, it will just try again using the original protocol. So it tries the new protocol immediately. If it fails, it falls back to the old protocol. And this is much better than the other way around.

Aaron van Wirdum Would my node still pick up the phone the second time?

Sjors Provoost Yeah.

Aaron van Wirdum Okay.

Sjors Provoost So it's better than the other way around because if you do it the other way around saying, hey, I know you're a Bitcoin node, but let's do the secret handshake now, then you've kind of already ruined it because you've just told all the spies that you're a Bitcoin node.

Aaron van Wirdum Right.

Sjors Provoost So that's why it's good to be able to immediately try the new way. And the only thing that happens is you get disconnected. Now, I think there's some subtlety there. I think it's like nodes from version 22 and older. I think they give you a little bit of punishment for doing this. But more recent nodes have already anticipated that this protocol is coming. And so they will not punish you for that. They'll just disconnect, but you can reconnect.

Aaron van Wirdum Right. Okay. What I remember from, so I wrote about BIP 151 like years ago, 2016, I think. And what I remember from back then was that there was some controversy about it. And this had to do with the authentication. Well, I wasn't sure how to pronounce that word. That's why I sort of skewed the microphone to the side. Authentification. Am I saying that right? I think so.

Sjors Provoost Authentification.

Aaron van Wirdum I got it down, finally. Is that still... So how was that solved? Is that solved? What's going on with that?

Sjors Provoost Yeah, so there's really two things. There is encryption and there is authentication. Encryption is just the idea that we're hiding what's in the messages, but I can do that with anyone. Authentication is saying, okay, I know that I'm connecting to this specific person. And that was controversial because if you have nodes, if you start working with nodes that have an identity and you say, I'm only going to allow people, you know, from the KYC whitelisted node list or something like that to connect to me, that's kind of where you don't want to go. That said, that's exactly how Lightning works. And it has not ended the world yet, but…

Aaron van Wirdum Yeah, but I guess on Lightning it's also a little bit less crucial.

Sjors Provoost Well, on Lightning you need reputation so it is they kind of need this concept of identity in order to have some reputation not too much but a little bit I think that's one of the reasons why they need the way they do it but on Bitcoin in this proposal there is no identity and there's also no authentication however it can be built on top of it That's just not part of the proposal, but the proposal does make it possible. So if you do want to say you're running a server park yourself with a bunch of Bitcoin nodes and you only want to connect them to your own nodes, then you might be able to build something on top of this system that will let you do that. But the sequence would be this. So another node from the internet connects to you. That'll always work with this new protocol. And then once you've done that, you can say, okay, now I'm going to have some other messages with that node that does the authentication part. So you call a node, you answer the phone, you say, what's the secret password? And if they don't give the right answer, you hang up. That's kind of the analogy.

Aaron van Wirdum Right. So is there any, does this resolve the controversy? Is there still any controversy left as far as you know?

Sjors Provoost I'm not sure. I mean, you can still make the argument at any step that makes authentication slightly easier is bad. Then again, I think you can also make the argument that some risk might be warranted given that it's also bad when governments can spy on all the nodes. So I think that discussion could still be had. In any case, this proposal itself does not do authentication. So as I said before, if I connect to multiple nodes, all those nodes will see a different public key from me. There's no shared identity. Of course, they all know my IP address.

Aaron van Wirdum Yeah okay is there anything else on the technical side of this proposal that we haven't discussed?

Sjors Provoost No, I think one minor detail might be fun to mention the the way the public keys are exchanged in the beginning as you know A public key is created from the private key, but that actually looks...

Aaron van Wirdum Through a one-way function.

Sjors Provoost Yes, no. But the way you do that normally, if you look at a public key, you can recognize that it is a public key. And the reason is because it's like 64 bytes, for example, or maybe, yeah, I think it's 64 bytes or 32, whatever. If you look at an internet—if you look at—if you see something on the internet, you see these 64 bytes, then you will notice that if you see lots of public keys, you'll notice that you don't see all the possible numbers randomly. So it doesn't look random. It looks like you're only using half the numbers, because roughly half the numbers are a real public key if you have a random number, and the other half are not a real public key. So that creates a pattern that you don't want. Because then again, the eavesdroppers will just look at a connection and see, well, half the time it's a public key, half the time it's not. So it's probably Bitcoin. And so there's one little ingredient there that converts your public key to a different format that does look completely random. That's one of the little innovations that goes into the implementation.

Aaron van Wirdum Okay.

Sjors Provoost And that way the entire handshake looks like completely random data rather than a public key followed by random data.

Aaron van Wirdum Right. So where is this project? What's the status now? When can we expect it in Bitcoin Core, if ever?

Sjors Provoost Well, it's not a consensus change, so you can already run it if you want to.

Aaron van Wirdum Is the code ready?

Sjors Provoost Yeah. It's testable. I don't know if you want to use it on your main node. You can look at BIP323.com, which has an overview of sort of the open pull requests. And it also links to one pull request that has the whole thing. And other than that, you can wait. I'm going to guess it's going to be in a future release.

Aaron van Wirdum Is there? Yeah. Can you give any sort of, I mean, developers?

Sjors Provoost No.

Aaron van Wirdum Okay. I'm not even going to finish the question.

Sjors Provoost It depends on, you know, how many people get excited about something at the same time that tends to speed up review. So maybe it's going to go faster now, but maybe not.

Aaron van Wirdum Okay. Well, thanks, Sjors, that was clear enough for me. Hopefully for our dear listener as well.

Sjors Provoost Yeah, I think I can also do a shout out to [unclear] Livera's podcast, episode number 433, where he has, I think, all of the authors on the call also explaining conceptually why it's cool. And I could make a nice addition to this episode.

Aaron van Wirdum Cool.

Sjors Provoost So thank you for listening to Bitcoin

Aaron van Wirdum Explained.