WBD376 Audio Transcription
Bitcoin Tech #6 - The Threat of Internet Centralisation with Shinobi & Dhruv Mehta
Interview date: Friday 23rd July
Note: the following is a transcription of my interview with Shinobi & Dhruv Mehta. I have reviewed the transcription but if you find any mistakes, please feel free to email me. You can listen to the original recording here.
In this interview, I talk to Shinobi, the host of Block Digest, and Bitcoin Core Developer Dhruv. We discuss the importance of decentralisation, the protocols that power the internet and how a centralised internet threatens Bitcoin.
“The price of freedom is eternal vigilance…‘how prevalent is an attack’ is not really an important question, ‘how possible is an attack’ is the important question. When the value is 10x of today or 20x of today what people are willing to spend to attack it also goes up.”
— Dhruv Mehta
Interview Transcription
Peter McCormack: Take 3; we're going to get this one done! Dhruv, how are you doing, man?
Dhruv Mehta: I'm doing great, Peter, thank you for having me. How are you?
Peter McCormack: I'm good, man. This is your third appearance on the podcast; it's just the first one we're actually getting done!
Dhruv Mehta: Yeah.
Peter McCormack: Shinobi, how are you doing, man?
Shinobi: I'm doing all right. I'm amazed. I have been without nicotine since 4 July and I'm not ripping my face off.
Dhruv Mehta: Congratulations!
Shinobi: Oh, come on, Peter, I saw that! You were supposed to be with me, dude. You were supposed to put that down with me on the 4th in memoriam to England getting their ass kicked!
Peter McCormack: Well, this is you getting your ass kicked; I'm going to blow smoke the whole -- I actually gave up; I'm just having it just for this session to fuck with you! Anyway, look, we've actually got important stuff to talk about.
Firstly, a big thank you to Ben Prentice for coinciding this exactly at the same time as Jack Dorsey and Elon Musk are about to talk, so yeah, thanks for doing that; I think this is a much more important conversation, unless you're somebody who's hoping and praying your bags go up. Dhruv, you reached out to me, you reached out to the team. We don't really know each other. All I know about you is you're a Core developer, so you should introduce yourself to the listeners, tell them all about you and what you're working on.
Dhruv Mehta: All right. So, yeah, I would like to tell you a little bit about why I work on Bitcoin, followed by what I am doing for my project right now. I grew up in India in the 1990s and outside home, the world looked like it was financialising, companies were coming to India. There was globalisation, these tall, glass buildings were showing up; I wanted to work in one of them so bad. And at home, we still had a lot of traditional influence.
So, friends would talk about stocks and at home, people would talk about gold; they were gifting each other gold on birthdays and anniversaries and whatnot. And as a kid, I just didn't get it. I thought we had access to these amazing assets and we were still gifting each other this thing that's clunky, it could get stolen, you'd go to the market and the guy would use a black stone and scratch gold on it and then tell you how many carats it was and you were kind of just, "Okay, well that's the purity of it". I didn't really get it.
But then, a decade later, I saw what 5% to 15% inflation had done to my parents' ability to buy a modest, two-bedroom apartment in a tier 2 city in India. They'd worked hard, they had good luck, but these stores of value, like the dollar, gold, real estate, had gone so expensive that it was hard to be retired in a reasonable way.
After I learned about Bitcoin, I learned how all rulers basically manipulate money. India has cultural memory of the Maharajas and the British and even their democratic government demonetising their hard-earned money, or clipping coins, or whatever they did in the past; and the response to that they developed is gold. So, that's the justice angle of why Bitcoin is really important to me.
But my naivety continued and I worked early in my career at companies like Google, building the search and ads infrastructure. I started a Y Combinator funded marketing automation start-up and I helped build the surveillance data. I learned it from inside out as I built it, but I helped build it. And, now that I realised what I'd done, I'm kind of ready to blow it up. And I truly believe fix the money, fix the world. It should be fix the money, fix the incentives, fix the world; but I'm here to do it.
The project I have picked to work on has to do with the verifiability of our money, of Bitcoin. So, on your podcast, you've talked previously about the properties that make a good money: scarcity, durability, divisibility; and verifiability is the one that's most important in the peer-to-peer layer of Bitcoin. So, I recently got started on my project to make that running a full node, which is essentially the verifiability of Bitcoin, more robust.
Peter McCormack: Nice, man.
Dhruv Mehta: Yeah, that's the why.
Peter McCormack: That's the why, man. Well, listen, I'm glad you reached out. Must remember we've got our degenerate regular, Shinobi, on the show. How are you doing, man?
Shinobi: Who gives a crap what fucking Elon's doing right now? This is so much more important!
Peter McCormack: All right, brother. Well listen, Dhruv, I'm glad you reached out to me, because you want to talk about an interesting topic. Self-confession; Ben did a lot of the preparation work for me, but in going through it, it's like this is a really important topic, this is an important subject, you were like, "I want to talk about internet architecture, as it is very important towards Bitcoin".
So, we're going to dig into how the internet works. So, how decentralised is the internet itself?
Dhruv Mehta: Yeah, that's a great question. TCP/IP, which is the protocol, is very decentralised. The internet as we use it is extremely centralised, right. TCP/IP, decentralised; internet, super centralised. And the reason for that is that there are three primary sources of trust that we regularly use when we are on the internet, so I want to walk you through an example of what happens when you go to a website in your browser, and then we can talk through the sources of centralisation there. Does that sound good?
Peter McCormack: Yeah, sounds great.
Dhruv Mehta: Okay. So, let's say you go to BitcoinCore.org or WhatBitcoinDid.com. The first thing that happens is your computer has no idea where this website is hosted. So, it does something called a DNS lookup, so Domain Name Service lookup. These are servers that are typically run by ISPs or big tech companies like Google and Cloudflare. So, your computer browser asks the operating system, "Where is WhatBitcoinDid.com?" It goes, "I don't know, I guess I'll go ask the DNS server". It asks the DNS server; it gets back an IP address, which you've seen these four numbers separated by dots, right; 192.168, you might have seen that for your router at home. You get back an IP address which is where the computer is that hosts that website.
So, that is the first source of centralisation, that DNS lookup, because you have to ask someone, a central entity, where the other computer is. That entity is corruptible. Instead of going to your web computer for your website, the ISP could decide to send it to Shinobi's computer and Shinobi could host a home page that says, "Ha ha, Peter, you should quite smoking!" That's a DNS hijack; that's the first source of centralisation.
Let's say everything goes okay and you get the right IP address. The next thing that has to happen is your computer has to figure out how to reach that computer. Not every computer in the world is directly connected to every other computer. So, you're going to go, "Hey, how do I reach this IP address?" Your computer has no idea; it asks your gateway, that typically has no idea. It goes to the ISP. The ISP runs these servers along the way, called routers, which will route the traffic. So, somewhere up in California here, the ISP will say, "Okay, this looks like an IP address that is in the UK somewhere; I don't really know where", but it's going to send it to the UK node and then, in the UK perhaps, it knows it's closer to Bedford and how to route it.
So, there are these IP routers along the way, which are trying to get you from one IP address to another IP address. This is another corruptible entity. It's a source of information where you're putting in trust to find another computer. Your traffic could get directed to the wrong computer, because ISP decided to hijack your IP address and this attack is called a BGP hijack; a Border Gateway Protocol hijack, because the Border Gateway Protocol is the technique used to update these tables along the way, the look-up tables, that help you find any computer on the internet. Does that make sense so far?
Peter McCormack: It does, but also the way you were describing the way it routes sounds a little bit almost like the Lightning Network?
Shinobi: Exactly it does. The only difference really is the liquidity requirements, but routing on Lightning is the same general problem as routing on the internet.
Peter McCormack: All right. Yes, that's clear so far.
Dhruv Mehta: All right. I just want to say, it's a little bit different from the Lightning Network, because for the Lightning Network, you get to pick the path. You can even do things like, you can pick two paths with multipath payments and you can put them together. You can do a lot of different things as the sender. However, with the internet, ultimately there are only so many c-links and these entities control them; and so, it's not like you really get to pick your path. You go through some sources of tremendous centralisation.
On the Lightning Network, you don't like a source of centralisation, just spin up a node, add liquidity and that's no longer central. You can't do that on the internet. It's quite different in that sense from the Lightning routing.
The third source of centralisation on the internet is certificate authority. So, let's say you get sent to the right computer, it sends you back a website, how do you know the content of the website is really coming from where you think it's coming from. We don't have to go into the details of this particular social centralisation, but essentially, they send you back a cryptographic signature and your operating system comes back in with certificate authorities that can verify that yes, you are indeed on Amazon.com, or you are indeed on WhatBitcoinDid.com.
So, those are the three sources of trust that makes the internet very centralised: DNS; IP routing; and then, certificate authorities.
Peter McCormack: Okay. And just out of interest, could those centralised entities that we rely on to run the internet, could they ever become decentralised, or is that one of those things where you just have to accept that's the way it is?
Dhruv Mehta: I think it's very important to distinguish between the protocol and the infrastructure. So, TCP/IP, the protocol, is extremely decentralised. If you and I really wanted to connect our computers with an ethernet cable, we don't have to go over an ISP. TCP/IP is decentralised. Because there are so many people that want to connect to the internet, we have built this hub and spoke model, where the ISPs are the hubs -- it's just like the traditional financial network is also a hub and spoke model.
We tend to start with decentralised protocols, like bearer cash, and end up with hub and spoke models like the traditional financial networks; start with a decentralised TCP/IP and end up with a centralised internet. We're seeing this a little bit with decentralised Bitcoin, Lightning right now is pretty hub and spoke. And so, hub and spoke scales.
Shinobi: Wait, some things you can decentralise to some degree right now, but just not all the way down to the base layer. Like speaking of DNS, where somebody finds out how to get WhatBitcoinDid.com and actually get an IP address to go to, you can run your own DNS server, you can cache things that once you find out some things, IP address, that stays on your local machine. And for that website, you don't need to go to a third party anymore. But those packets still have to go out to your ISP and then go through that routing layer, and you still have to depend on those things; but at least you know the IP address.
So, it's like some of things can and are decentralised if people choose to do so, but that's more towards the coordination side of things and not the bottom layer actually moving stuff.
Dhruv Mehta: Yeah, we can definitely mitigate the risks, yeah.
Peter McCormack: Okay. Well, we don't need to get into the Lightning thing at the moment, but just by the way, I don't hate the hub and spoke model personally. I know some people are decentralised purists, but I use the Lightning Network actually entirely using a custodial wallet at the moment, because I still haven't used my Lightning node, and I don't keep too much on it, so it doesn't bother me too much. But I know that has some potential issues or criticisms, but anyway, by the by, it is what it is.
Okay, so comparatively, how decentralised therefore is Bitcoin?
Dhruv Mehta: So, Satoshi seemed to really understand this hub and spoke issue. So, traditional financial networks have banks as the hubs and they can suppress any financial activity between these entities, companies, people, whatever, by just passing a law and going after the banks, because there is a CEO to go after, there is a throat to choke.
Satoshi built Bitcoin in a way that there are no throats to choke. It's a peer-to-peer network. Every node typically connects to eight other nodes and there is no one throat to choke. My node does exactly what Elon Musk's node does; it doesn't care how many followers he has on Twitter. There are no super validator nodes. A node is a node on Bitcoin.
But ultimately, these nodes have to talk to each other somehow; they have to have a communication link. And today, the most popular communication link is the internet. So, while the Bitcoin protocol is super decentralised, the transport layer we use today of choice is the internet; and, as we discussed just now, that has sources of centralisation in it, which leak into Bitcoin. What I want to talk about as an example of this and to drive towards the project I'm working on and motivate that, is how this affects existing nodes and new nodes when they come online.
So, when you have an existing node, it already has something called ADR DB, Address Manager Database. It knows thousands of peers that it can talk to, so it can choose from them and talk to them. And because proof of work consensus is such a strong property, all we need is one honest peer, which is connected to the honest network, to know the truth. Everybody else can lie to my node, but if I can connect to one honest network, my node will know the truth.
This is wonderful, except when your node doesn't know any peers yet. So, you just spun up a new node; how is it going to find out the truth of all transactions that have happened? So, what we're trying to figure out is the UTXO set and the blocks are these diff patches on the UTXO set; we're trying to find that truth of the current UTXO set.
So, my node comes up, doesn't really know any peers to talk to, and this is where the risks from the internet leak into Bitcoin, where my node has to go ask someone, "Hey, tell me a few Bitcoin nodes; who should I talk to?" Once I know a few, I can ask them who their peers are, and can ask them who their peers are, and I can crawl the network; but in the beginning, I have to go to someone.
So today, the way this works in this query response system that the internet is, is that there is something called the Bitcoin seeder. It's a separate repository of code than Bitcoin Core. In Bitcoin Core, there are nine domain names that are hard-coded. These are run by long-term Bitcoin contributors and they run seeders, which are crawling the Bitcoin Network, so Peter like Pieter Wuille and Luke Dashjr, they're running these nodes. They have a lot of real-life proof of work in the Bitcoin ecosystem, so we trust them to run these nodes and be honest with us.
But the first thing my node does is, it has to resolve a DNS address. So, one of the DNS addresses here is seed.bitcoin.sipa.be. One of them is dnsseed.bluematt.me, which means that my ISP can attack the seeder. If I'm using my ISP as a DNS server, it could send me to a dishonest seeder, which would seed me with dishonest peers, and I would never find out the truth, because I'd never find even one honest peer. Does that make sense?
Peter McCormack: Well, a little bit; but more in that it sounds risky. So, how do you mitigate that?
Shinobi: Well, it's only risky if you get caught. And, if you are the person who is controlling the DNS names, what they resolve to your access to the internet, you're going to have to go out of your way to find a new source of information for them to get caught. And until they get caught, they completely control your view of the Bitcoin Network.
They could just stop feeding you blocks after, like block 600,000, if they have the energy and the resources. They could mine fake blocks on top of block 600,000 and then give you those fake blocks. And, because they've completely controlled who you've connected to on the network, you're only connected to people who will give you those fake blocks and go, "Yes, these are real".
So, if they catch you when you're bootstrapping onto the network like that, especially if they have the energy for proof of work, they can just completely lie to you and there's no way to figure that out until you find a new connection to try to talk and find other peers on the network.
Peter McCormack: It doesn't sound like there's much of a reason to do this though. It's a lot of effort for what benefit, because they can do it at an individual level, maybe a few individuals; but if we've got tens of thousands of nodes already live, it's not like they can disrupt the entire network?
Dhruv Mehta: So, this was the attack on new nodes. There's a separate attack they can do on existing nodes, which also I want to talk about. So, we talked about IP routing, how computers talk to each other on the internet. This is surprising to many people, but Bitcoin peer-to-peer traffic is actually in plain text; it's completely unencrypted. So, when my node sends you a block, along the way you can inspect the TCP packet and you can see the peer-to-peer command, you can inspect the packet size. The Bitcoin protocol is very easy to fingerprint and you can just drop the packets. The router could just say, "No, this traffic just doesn't go to the next node".
There are a lot of countries in the world where there is only one state-controlled ISP, right. So, if existing nodes can't talk to each other, new nodes can't bootstrap… It's not that they can ban Bitcoin; people will find a way. People will use a satellite; people will use something else; but it's that they can make it hard to use, is one thing. And then the other thing is, you can lose trust. So, like Shinobi said, if they're mining fake blocks, I could be giving up my labour, or selling goods and services, for fake Bitcoin; and then, if the system loses trust, then people will go to some other scarce asset to store their value.
Peter McCormack: Right, so they can send you blocks whereby you believe you've accepted real Bitcoin, but --
Dhruv Mehta: It would be a hard fork technically, yeah.
Shinobi: But then, you know, the reorg comes and the transaction paying you doesn't wind up in the longest chain. I would even go a step further. You can play games with this type of infrastructure to affect mining. Look at the larger-tier networks, what if they stopped taking blocks from this group of miners and sending them to everyone else, but would take blocks from everyone else and send them to this isolated group of miners? You could start playing games with the profitability of individual miners, if you wanted to start playing with blocks flowing around, because all of this is unencrypted and you can see that.
Dhruv Mehta: Yeah, you can even co-opt hash rate, right, so the way these networks work. If there's one node and everyone else just has hashers and, if you do a BGP attack on the full node, you could just co-opt that hash rate.
Shinobi: So, instead of mining with the pool you think you're mining on, that connection got cut off and this malicious pool that was having you mine on their blocks, where they get paid instead of the mining pool that will actually give you your share.
Dhruv Mehta: Yeah.
Peter McCormack: Okay. So, these all sound like scary situations and sound like the kind of thing someone like me, who's just a typical moron, would have no idea if it's happening, no idea how to check for it. I trust this trustless system that my node is fine; or, when I use another person's node, it's fine. So, is there work being done to mitigate these problems; are they rare; does it happen; or, should I have a new skillset which allows me to ensure this isn't happening?
Dhruv Mehta: That's a great question. So today, there is already a bunch of things you can do, if you are technically able to do them and if you are in a hostile regime. So, you can run your node on Tor; you can be behind a VPN. These are techniques that make that traffic harder or impossible to fingerprint, but there are other issues with it in that everybody cannot use Tor; our block propagation times would be very, very high, which would result in consensus being harder to achieve in the network, if everyone were to use those techniques. Also, most node operators don't have the technical expertise to set this stuff up. So, there needs to be something that comes out of the box.
So, in 2016, Jonas Schnelli, one of the Core devs, started working on BIP 150 and 151 to provide end-to-end encryption and authentication between Bitcoin peers. So, I mean if we can go into the technical details, tell me how much is too much, but there's a Diffie-hellman key exchange that happens between the peers; and then, the man-in-the-middle attacks are still possible, but they become observable, so you can tell if you are being attacked at least.
This BIP then, in 2019, it was changed to be BIP 324, which had a lot of traction. There are a bunch of PRs that have been merged. BIP 324 gives us cryptographic assurance that we are talking to the node that we started talking to originally and the traffic is not being tampered with. Does that make sense so far, or do you or Shinobi have any questions on that? Shinobi, do you know about BIP 324?
Shinobi: Yeah, actually I have been wondering for years why there was not more motivation to get those types of things done. I'm especially glad though with the jump from 150 and 151 to 324, I believe, worked most of the cryptographic aspects of it, I think from Pieter Wuille and Greg Maxwell.
Dhruv Mehta: Yeah, they have been mentioned in the BIP, the ideas being mostly from them. And we are, I would say, 60% implemented at this point; the work has slowed down a little bit. So, I got funding earlier this year from Square Crypto, Human Rights Foundation and Gemini to work on authenticated seeds. What I want to do is build on top of BIP 324.
So, what we can do is the seeding process I talked about, where you're talking to a seed node, that you want to be sure you're actually talking to the seed node; it's not DNS hijacked or BGP hijacked. We can use BIP 324 to do a Diffie-hellman key exchange through the code case; or, we can do a BIP 150-style authentication challenge. But the work I am doing is to make sure that the seed nodes -- when your node is talking to a seed node, it has cryptographic assurance that it is actually getting back results from them.
Shinobi: Sort of like an identity key, so that the node can be sure. Instead of just the domain name hard-coded, you have an actual key that they have to sign with.
Dhruv Mehta: Public key, yeah. And one of the building blocks of this is obviously BIP 324, because we also want encryption along the way. BIP 150 does not allow for authentication without end-to-end encryption. So, that's the work I'm doing. And once you have that in place, you can be assured that your new node, you can still get censored in that your ISP might still drop all your packets going through that IP address, but you cannot be co-opted. And if a node is censored but not co-opted, the node operator will typically find another way to do it. If you're co-opted, you might not even know that you've been co-opted, so it eliminates that completely.
We take the risk that was technical previously, in terms of DNS and BGP hijacks, and we reduce it to social risk, which is, "Are the nine seeders really honest?"
Shinobi: Let's go further than the nine seeders. That's a massive starting point, but what about general just plug in a key; why do I have to go to a DNS bootstrap node? Peter, give me your node's identity key; I know you, Peter, I trust you. I want my node to first connect to your node, because I think you did that right. I personally know you and there is way more trust there than just this ephemeral group of developers.
Dhruv Mehta: Yeah, and that will become possible as well with these projects, because we already have the seed node command line flag with the Bitcoin Core node, and you would essentially seed yourself with Peter's node and know for sure that you're talking to Peter's node, because we will have end-to-end encryption and authentication. So, that will totally become possible; you won't have to rely on the nine default seeders.
Peter McCormack: This is one of those conversations I feel like is really super important, but I'm just like, "Okay, what am I meant to do? I like Bitcoin, I've been told I should run a node, I've set up my node, I'm under the belief that now I'm running a node I'm able to validate UTXOs; and now I'm like, are these real blocks; am I being scammed? I have no idea what I'm meant to be doing now". How prevalent is this on the network?
Dhruv Mehta: It's a great question. Did you see that recent Alex Gladstein tweet? It was something like, "The price of freedom is eternal vigilance"; it's kind of like that. We're backing $0.5 trillion, $1 trillion of monetary value; how prevalent an attack is not really an important question. How possible is an attack, is the important question. When the value is 10X of today, or 20X of today, what people are willing to spend to attack it also goes up. When it starts to hurt their ability to print money, they're going to be willing to print a lot more to spend it to protect their ability to print!
Shinobi: Also politically, Peter, look at what's been going on for the last couple of years. You have these insane copyright movements and antitrust moves against big internet companies in Europe; you have demands for similar things going on in the United States, because of our social media issues and how that ties into politics. There are a million excuses in general, politically, to just start playing games with internet infrastructure.
The Press Secretary of the White House quite literally said, "The White House is quite actively approaching Facebook with things they want removed and censored". If Bitcoin continues growing, how common these attacks are right now, while this is a child's toy just sitting there, doesn't matter. What about when we have superpowers going, "Turn this thing the fuck off right now".
Dhruv Mehta: Yeah, and I just want to add one thing. So, what you should be doing is, I think, what you're already doing. So, you're running a full node; you're doing tremendous advocacy; you've got people to do Core dev funding to move projects like this forward. I'm funded by Gemini, which is one of the people you've got doing that. And then, upgrade your node; so, every time we do a new release and we launch these features, upgrade your node and add that layer of protection to the network.
Peter McCormack: Okay, so what we're really talking about here is, are you saying these are theoretical attacks, or do we know these attacks are happening now?
Shinobi: They have happened; not against Bitcoin, but these types of attacks in general on the internet absolutely have happened. They happen all the time. I think in the last couple of years, there was actually a major incident where somewhere in the Middle East, for a whole day, internet traffic, for no reason, was just being routed through the middle of China. So, you just have to ask yourself why and what could China gain? But, these things happen.
Dhruv Mehta: And it's a little bit of an arms race. If somebody else has nuclear weapons, you don't ask yourself, "Are these sorts of attacks happening?" You get your own nuclear weapons! The fact that it's possible is enough; it doesn't have to happen. The circumstances will change incentivising these sorts of attacks if they're possible and we have to mitigate them before they happen and we lose credibility on the network.
Peter McCormack: Right, okay. So, how are you approaching this project? How complex is it; what's the solution; should I be worried? I keep thinking, at any point, it's almost at that point now that people say, "If you are using a hardware wallet and you are not running your own node, you are trusting someone else's node". Well, I have to say, what do I trust more? Do I trust Ledger's node, or Coldcard, or whoever that hardware wallet I'm using, do I trust their node more than I trust my ability to know if I'm being scammed on my node? Yes, I do.
Dhruv Mehta: So, that's tricky. Because, when you say you trust Ledger's node, what you are saying is you trust literally everything from your finger on the keyboard up onto Ledger's node and then you trust Ledger's node. So, you're trusting your operating system, you're trusting your ISP, you're trusting their ISP and then you're trusting the fact that, if the government shows up at that CEO's doorstep and asks them to do something, they're willing to die on that hill. You're trusting a lot of things.
If the trust was just that their technical expertise is more than your technical expertise; sure. But it's not that. You are trusting a lot of infrastructure in between as well.
Peter McCormack: But I think, realistically, that's what the majority -- and I'm going to put a number out there. People might say this is wrong, but over 95%, maybe 98% of people right now are trusting other people's nodes; are going through that.
Dhruv Mehta: Oh, it must be higher, yeah.
Peter McCormack: Okay, so it's over 99%. So, it's a decimal of 99%?
Dhruv Mehta: Sure. I think, what's important to think about is the floor of the security that the network provides, not what most people are choosing to do. So, if everyone runs their own Bitcoin node and everyone is using end-to-end encryption or authentication, the floor of censorship resistance, the floor of security is much higher. So today, you don't know any known attacks on Ledger's servers in the UK and you're comfortable using it. I think that's great; but I think the fact that there's a certain level of difficulty to attack Ledger's node and that, that level of difficulty goes up, and the level of difficulty for you to run your own node comes down, these are very important things for adoption; these are very important things for people's ability to put their trust in this.
If there's one such attack somewhere, there's going to be a decade of FUD about, "Remember how that one time, that government was able to do so-and-so to Bitcoin?" and we keep moving the line of defence forward, as Core devs, to make sure the cost of those attacks keeps going up and the floor of security and censorship resistance in a hostile environment keeps going up.
Shinobi: I mean, Pete, think about you. You think the odds that Ledger's server gets messed with are non-existent. Okay, so what happens when it does? What do you do; what's your option? "I'll just spin up a node". Well, if Ledger's got attacked and these types of things are going on, is spinning up your node safe; how do you know who you're talking to, you know what I mean?
The whole philosophy is, everyone should be able to run a node when they need to or want to. Well if, when they wind up needing to, becomes a much hairier situation than it is today, then you have to think about these types of issues; because what good does it do if somebody goes to spin up a node and that winds up not fixing a problem for them, because they get attacked in one of these ways, because the infrastructure they depended on was not dependable?
Dhruv Mehta: And, from a game theory standpoint, it's also that because, Peter, you could run your own full node and you don't have to depend on Ledger's node, there's less incentive to attack Ledger's node, because you have this great fallback option that they know you'll exercise. If there was no fallback option, the incentive to attack those hubs in the hub and spoke model is much, much higher. If there is a throat to choke, it will get choked at some point.
Peter McCormack: Okay, okay.
Shinobi: My goal was to scare people with this episode, and I think by Peter's reaction so far, we're doing a good job!
Peter McCormack: Well, it just makes me think, well I'll just hodl for now! I won't spend, because I've got no idea; damn scared to receive. Let me ask you a question. If I'm running a multisig wallet and I'm using Casa, which means I'm not using a node; say if I'm sending straight to my Casa multisig address, and say it's a 3 of 5 and they're all separate keys with separate hardware wallets; say I'm using a Trezor, a Coldcard and a Ledger, so I'm not using a node for any of those; am I in a safer position there when I'm trying to send Bitcoin?
Sorry, I'm just figuring stuff out in my head. Is this only an issue with receiving, because it's blocks on top, or is it an issue with sending as well?
Dhruv Mehta: Just receiving, because that's where your node can get messed with.
Peter McCormack: Yeah, because if you're sending, unless the other person is also having that same issue, which is unlikely, so that doesn't matter. So, even if I'm receiving and I'm receiving in my Casa address, do I still have the same risk in a multisig address, because it's just an address?
Dhruv Mehta: Well, I think we should be careful to not be alarmist. I don't think you should worry when you use Bitcoin with a service like Casa today in the UK. I think it's more than likely you shouldn't worry, but that doesn't mean you shouldn't think about your security model going forward and how you move the line of defence forward; those are two different things.
Then, I think we also want to draw a distinction between a wallet and a node. Your 3 of 5 wallet is just 5 xPubs, which are Extended Public Keys, which are generating these addresses. Ultimately, I don't know Casa software well enough, but if you're probably using a node that's run by them, they probably have reasonable security; they're probably on top of things. But, Casa's node, does it have a big target on its back? Probably.
Shinobi: There actually are things that have already been done to attempt to kind of improve mitigation of these types of attacks. I forget exactly which variant it was, but the changes to peering logic recently in Bitcoin Core to take into account autonomous systems and how many diverse ones you're peering with.
Dhruv Mehta: Yeah, there a lot of mitigations in place. And one thing you can always do, Peter, is you can go query the node for the hash of the tip block, for the block tip, and then compare it with some block explorers on your own internet; you can do stuff like that.
Peter McCormack: Dhruv, have you listened to my show?
Dhruv Mehta: I'm a huge fan; I've listened to most of it!
Peter McCormack: How do you think I know how to do that? The tip of what?!
Dhruv Mehta: I think your level of knowledge has been such a moving target.
Peter McCormack: Yeah, of course.
Dhruv Mehta: You've learned so much recently.
Peter McCormack: Yeah, but hold on, you just said a thing. What was it you just said? I can go and get the tip of the block?
Dhruv Mehta: Yeah, the blockchain is like a list of blocks that build on top of each other and the latest block has a hash. It has a hash which is a unique identifier for that block.
Peter McCormack: Right, so they can't fake that?
Dhruv Mehta: Yeah. So, if that hash matches with the hash you see on the Blockstream explorer and matches with the hash you see on another explorer, Mempool.Space explorer, then their node is in good shape.
Shinobi: I think really quick here, Dhruv, just to make this clear for Pete. A big part of the reason you can do that is because of the certificate authorities. So, when you connect to that website, you have this guarantee provided by its web certificate that, "I actually am this website", so it's harder, with that website, to play the types of games where you're stopping information for getting there, or sending fake information.
Dhruv Mehta: And even so, you're still trusting that Casa, Blockstream and Mempool.Space aren't colluding. Ultimately, nothing is going to beat the level of security guarantees you can get from running your own node, so I do really think you should run your own node, and I'm sure Casa lets you point your Casa wallet to your own node.
Peter McCormack: Okay, so this is only with new nodes, right? But there is a potentially with already running nodes, right. Yeah, I just feel sorry for the listeners, because they're going to be in two camps. There's going to be a camp who are really smart and going, "Oh, fucking hell, Pete. You're just an idiot. If you did your work, you'd figure this out; we know this". And there's going to be another camp going, "Huh? What? I didn't know about these risks. I didn't know someone can do this to be. I don't know if I'm being scammed. I don't know if the blocks I'm receiving are real blocks now".
Shinobi: Well, here's the thing. The example of checking the block hash on a block explorer website, it's the certificate authority and the fact that that connection to that website is encrypted that adds some security guarantee there. Because, like Dhruv said, the peer-to-peer communications between Bitcoin nodes is not, so you can play any game you want with that stuff. But when you connect to a website like that, as long as the certificate authority is not malicious or not compromised, then you know that's Blockstream that you're talking to and it's an encrypted channel.
So your ISP, if they try to stop data from getting there, or put attempt to put fake data in there, all they can do is stop, but they don't know what they're stopping because they can't see anything. So, as long as you trust, or can trust, the certificate authority, like cross-checking these other sources of information actually does provide that extra guarantee that your node is not being messed with.
Dhruv Mehta: And I want to add something which also probably makes the people who are worried feel better; today, the amount of monetary value backed by Bitcoin's Network is at a level, so all of these attacks, if exposed, involve a tremendous loss of credibility of the attacker. Whether that's the government, whether that's ISP, if they're exposed, they lose credibility in a big, big way. The monetary value in the network is at a point where that credibility is still probably worth more to a lot of people.
It's when the value backed by the network goes up, like 10X, 20X from here, that the end, they are losing ground anyway. That's when they are not worried about losing their credibility. These attacks, they will eventually get exposed. In the meantime, people who do transactions they thought were real, but weren't real, and so on and so forth. So, I don't think today, the reason they're not prevalent is big ISPs are not willing to lose their credibility over stuff like this.
But what happens a decade from now? We have to be ready for what happens a decade from now.
Shinobi: And most importantly, users need to understand these tools to deal with them a decade from now and what the landscape is, to protect themselves. It does no good if all these things are built and then users don't know they exist, don't know why they exist and don't use them. They have to know and actually use them.
Peter McCormack: So, can you fix this, Dhruv?
Dhruv Mehta: Yeah, so the projects I mentioned, BIP 324, it adds end-to-end encryption, makes censoring Bitcoin traffic very difficult or nearly impossible, and then authenticated seeds on top of that, using BIP 324, once we authenticate the seeds, the seed nodes cannot be hijacked, either DNS or BGP hijacks, and those projects are already under way.
Peter McCormack: And how long do you think they're going to take?
Dhruv Mehta: BIP 324 was a 2019 BIP that saw significant traction in 2019/20 and recently, I've been in touch with Jonas to help move that forward faster as well. In Bitcoin, it's hard to give you timelines, but this is my full-time thing. I want to move BIP 324 forward and I want to authenticate the seeds, I know Jonas Schnelli has already put in tons of work into it. So, it's hard to give timelines, but I would like to get it done in the next year or two.
Peter McCormack: And when this is done, this will be, what, batch released as part of a soft fork?
Dhruv Mehta: There is no soft fork. Actually, that's a great question. The way BIP 324 is written is, it's opportunistic encryption. So, let's say I run an old node that doesn't understand this new encrypted protocol. You are running a brand new node, because you're diligent and you upgraded your node to the latest release. If your node tries to initiate a connection with my node via this encrypted protocol and I don't understand it, I drop it; you can connect with me via the unencrypted protocol.
So, it's not that the network gets fragmented, but if most people don't upgrade, the encryption benefits will not really come through.
Peter McCormack: Yeah, so that's the important thing. It's not necessary, but we want people to do it.
Dhruv Mehta: Yeah, and we see pretty reasonable upgrade rates across Bitcoin Core nodes, so I feel optimistic about it that when it's ready, people will use it.
Shinobi: Pete, to go a little deeper real quick, when you're talking how nodes communicate to each other, that never requires a fork. That is completely disconnected from the consensus layer of things. And there are actually proposals on, I think, Antoine Riard's AltNet, that want to change Core so that you can plug and play any protocol for nodes to talk to each other into Bitcoin Core a lot easier, so that we can have a lot more diversity in connections to protect against these kinds of things.
Peter McCormack: So, I guess I understand what the attack is, I definitely understand what the attack is; not how it's being deployed, but I understand what's happening on my node. I understand I'm receiving fake blocks, I understand how that can affect me in terms of imagining I've received Bitcoin and then there being a reorg and I lose it. I understand all that; that all makes sense to me.
I don't know how to check but, as you said, I can check the hash of a block and that's not too difficult to do. I can get the hash from my node. I use Umbrel, so I can get it from within the browser; I can go to Blockstream and any other, and probably check a couple if I felt like I needed to. I mean, the reality is I've been running my node for a while, so I'm pretty sure I've not been subjected to this attack; but at the same time, it would be very interesting to go through the process.
But ultimately, it's just another thing, and this is the kind of thing I say that really pisses people off, but I don't want to care about it; I just want you to fix it!
Dhruv Mehta: Yeah. And we should. If we want worldwide adoption, we can't have everybody learning the details of DNS and BGP hijacks; that's not how it should work. And that is precisely why, even though today you could mitigate the attack with Tor or VPN, what we want to do is we want to upgrade the protocol that comes, kind of batteries included, with one of the releases, and then just upgrade your node and you get the benefits. We don't want a world where everyone has to learn everything.
Peter McCormack: I'm pretty sure, doesn't Umbrel come with Tor packaged into it?
Dhruv Mehta: I have not used it, but it probably does.
Peter McCormack: So, if it does, do I not have to worry about this anyway?
Dhruv Mehta: Are you using it? I would be surprised if Umbrel was Tor by default.
Peter McCormack: I thought it was; perhaps it isn't. I don't know.
Dhruv Mehta: So, here's the issue with Tor. The block propagation times are really, really slow on Tor, because you have the three hops; there are only so many other nodes on the Tor Network; so, it really depends on your configuration. Some nodes are configured as in, they allow Clearnet as well as Tor peers. So then, the block propagation times are okay and you're getting some security by being connected to the Tor nodes.
But if you really wanted to go all in, you would be all Tor and then, block propagation times would be much slower, which is a different problem.
Peter McCormack: Oh, man! Every time I think I'm getting somewhere, I take a few steps forward and then I get a few steps back because I'm like, "Aargh!" Yeah, okay, well listen, look, I'm sure this is super interesting. People listening, certainly some people listening, will be like, "Wow!" Definitely there's going to be a group of people in my audience that are going to be like me like, "Huh?" But, okay.
Shinobi: We can go another step further for ten minutes or so, if you're down, Peter?
Peter McCormack: Yeah, let's do it.
Shinobi: I could argue how Bitcoin and things built on top of Bitcoin could actually help fix two of the problems with the internet infrastructure: DNS and certificate authorities. Ultimately, all those things are is, some authority arbitrarily connects two things. They take google.com and they connect that to Google's IP addresses and then they go, "This is so", and then they pass it down to all the other DNS servers. It's kind of like a hierarchy, where you have the ones in charge, and then you have the ones below that that are just easier for people to connect to. And all the information ripples down, and that's what it is.
Well, one of the first altcoins was actually Namecoin, specifically a system using a token in a blockchain, and the token is not necessarily required for this type of thing if you design it right, where anybody could openly get their name like that, their name space that's easy for people to recognise, and connect that to IP addresses or servers they connect to. That blockchain, verified with proof of work, allows you to -- there's the same kind of thing, but no hierarchy. It just propagates out to all other servers, and they now know which key is tied to this name and this server address.
So, you could have a domain name system like that that provides that same auditing and the guarantee where it's real easy for a user to do, but there is no central authority that can just arbitrarily revoke things or change things without proving the correct authentication mechanism, like they have the right key tied to that to change something related to that domain name. So, you could actually build something on top of Bitcoin that ironically helps alleviate the centralisation issue of the internet itself.
Dhruv Mehta: That's really interesting. What you're saying is that DNS is essentially a database and you could use a distributed ledger to maintain that database. The follow-up question I would have is, how do you then bootstrap a node that's trying to maintain that ledger?
Shinobi: Well, you've got to piggyback on top of Bitcoin's proof of work, which would be the only rational thing to connect that to, and then validate everything. And then also, just by the nature of this, you can have proofs for inclusion, or lack of inclusion, if you want to canonically order these. It's not Bitcoin itself; you can make a lot of design decisions.
So, you could even go in a direction making the validation of it as modular and lightweight as possible, where you can validate certain things without having to fully validate everything.
Dhruv Mehta: I'm not sure that that answers my question. My question is, I'm spinning up a new node that's going to keep this distributed ledger of this distributed DNS; I still have to ask someone, "Who are the other peers I talk to for this distributed ledger?" Because, the internet is fundamentally a query-response system; you have to ask a query and get a response.
Shinobi: Okay, I see what you're saying. The idea would be to piggyback on top of Bitcoin with the canonical commitment like, say, a chain of transactions starting with an identifiable transaction committing to the state of things. So, as long as you can bootstrap into Bitcoin itself, then you can use that anchor point as a way to bootstrap into this new DNS system.
Dhruv Mehta: I see. So, you can mitigate the risk on the Bitcoin layer using Bitcoin 324 and authenticated seeds, and then build a distributed DNS system on top of Bitcoin. That's fascinating. Yeah, that makes sense.
Shinobi: And, the same kind of logic, just a different cryptographic commitment structure, but you could do the exact same thing with certificate authorities; allow people to plug into that, although that would be a lot harder to deal with because now, we have to have the politics conversation of, make all of the browsers let people import their own authority key!
Dhruv Mehta: Wouldn't you have to make public the private keys of the people that were having certificates issued to them?
Shinobi: Well, no, because my whole thought process there was people could solve the issue and then people could form their own authorities that people would choose to trust or not.
Dhruv Mehta: I see, like a web of trust model, yeah. Fascinating.
Peter McCormack: Okay, well listen, is there anything else to add to that?
Dhruv Mehta: No, I'm good.
Peter McCormack: Well, I'm going to put this one out there --
Shinobi: Be very scared of the NSA, Peter.
Peter McCormack: Yeah, well I mean, listen, you don't have to be; I spoke to them this morning! They're not worried about this right now; they're watching Elon!
Listen, if people want to follow your work and they want to ask you questions, get in touch, because they're not going to ask me about this one, because I'm clearly vastly out of my depth, how do they get hold of you?
Dhruv Mehta: I'm on Twitter. My handle is @dhruv. Yeah, I'm happy to get questions and have conversations and learn along the way.
Peter McCormack: Shinobi?
Shinobi: Yes?
Peter McCormack: You don't need to tell everyone where you're from, but thank you for joining us for this. This was interesting, and it's making me think quite a bit. But I need to have my brain turned around. I'm probably going to have to relisten to this one, which I don't ever do with my shows, because I hate my voice; but I think I need to just go back and listen to this one and try and take this all in.
But, listen, praise you for your work, man. I do these shows, I did one the other day on the Lightning Network that actually came out today, with Christian Decker and Carla Kirk-Cohen, and again it was like a whole bunch of shit; I had no idea what they were talking about. I'm just glad they're working on it. So, it's the same I can say to you. I'm just really grateful we have people like you, amazing people, working on this stuff and looking to the future of Bitcoin and making it as robust and as strong as possible. I also want to congratulate us all for getting through this interview finally!
Dhruv Mehta: Yeah, and likewise, Peter, I have to say your podcast is one of the -- it was a big part of my orange pilling process. So, thank you for doing the work you do.
Peter McCormack: Well, no worries. I guess that's more for what other people said than me, but that's brilliant, man, and I appreciate it. And I heard some little bit of sound in the background, but I think we can get rid of that, but I appreciate you, man.
Shinobi: Peter, you've got to promise me one thing though when this episode drops. You need to include a poll in the thread asking whether, after listening to this, people got a little scared or not!
Peter McCormack: Well, I think they will. But what I'd be more interested in is two polls: do you understand the attack that Dhruv is talking about, and are you scared; and, do you not understand the attack, and are you scared? Because, there may be people who understand it who go, "Yeah, I understand it. I'm not scared, because I know what the fuck I'm doing", and I think that's what it's going to be. People who understand it are like, yeah, they're not worried. People like me will be like, "Oh, shit, this sounds scary. I don't know how to deal with this".
But, look, we'll put it out there. It will be interesting.
Shinobi: It's just my inner troll; I'm morbidly curious.
Dhruv Mehta: It's not the first time Peter will have contributed to crashing the price of Bitcoin!
Peter McCormack: Dude, listen, that wasn't my fault. Fuck you, Elon Musk! All right, dudes, love it, brilliant; glad we got there in the end. Shinobi, I will talk to you next month and, Dhruv man, stay in touch, keep letting me know what you're working on. If you need me to tweet anything out, let me tweet it out. If you've got something else to come back on the show and talk about, please come and do it. It's been great talking to you, brother.
Dhruv Mehta: Thank you so much for having me.
Peter McCormack: No worries; anytime. Peace out, Shinobi!
