Psaná verze sedmé epizody Breaking Monero.
Justin: [00:00:00] Welcome back to “Breaking Monero” today Sarang and I are talking about remote nodes and some of the considerations that come when using a remote node. Now we all know that remote nodes are really convenient — most wallet clients or any cryptocurrency including Monero bitcoin and many others. We’ll try and encourage you to use a remote node because it’s easy to get started it’s easy to use. I believe even by default the Monero GUI clients provides an easy option for you to connect to remote nodes so it’s much easier for you to get started. You don’t need to sit there waiting for a potentially slow connection few days to get started. But despite these being really convenient you delegate some of the responsibilities and some trust to these nodes as you’re using them. So we want to make sure that people understand the tradeoffs that are involved in using these remote nodes. So Sarang is going to start off talking about the ways you can use Monero with different types of connections and really what these nodes do for you.
Sarang: [00:01:01] Right. So I mean in some sense regardless of the wall of software that you choose to use at some point you need to communicate with some type of software that’s been maintaining a copy of the blockchain. The reason you do that is that when you generate a new transaction your wallet software both needs to know the particular outputs that you’re trying to spend as well as being able to pull decoys for ring signatures. We’ve talked extensively about from the history of the chain. So at some point some software needs to have a copy of the chain. Now there’s a few different ways to do that. One of which you often hear people say is run your own node while running your own full node basically means that you have a machine somewhere some kind of device typically it’s a computer that actually maintains a full copy of the Monero blockchain. And as it receives new blocks tx them onto the chain verifies that they’re all correct and then makes that chain data available when you need to send a transaction and then it can scan new blocks that come in and update the balances of wallet that you’ve told it to watch for. However what you can also do typically is often with devices that are small and lower power it may be done in the storage capabilities for example like a phone where I typically don’t want to have to download and maintain a copy of the chain. That would involve a lot of time a lot of space and probably a lot of battery that I might not want to do. So in that case I can tell that wallet software to connect to a node (a remote node we call it) that’s maintaining its own copy of the chain somewhere else. That could be a computer that I control somewhere or it could be a computer that someone else has chosen to make available as a service to the community on the network. There’s also another option where you can use a sort of semi Custodial Service like mymonero or an open Monero server. And those work a little bit differently and that you delegate a little bit of trust to them so that they can watch for transactions on your behalf. But it’s not really quite the same thing. So perhaps just now you could talk a little bit about what any of these types of nodes actually does and why we need to interact with them at all.
Justin: [00:02:50] Excellent. So as you sort of hinted at — you need some way to communicate with other participants on the network. It’s all fine for you to sign a transaction locally but you ultimately need to tell everyone that you made this transaction take place to get it to other places. So the first thing you really need to use it for is getting information out to the rest of the network. So one way to do that is to connect to someone else who already has these connections and tells them to forward it along. Likewise if someone’s trying to send a transaction to me for instance instead of running a direct connection to other people on the network I might say “I’ll just communicate with this one person that’s running this node infrastructure and they’ll tell me when I have transactions that come through they will speed me blocks I’ll take those blocks I’ll look at them locally I’ll determine whether or not any of those blocks have any transactions that are for me and I learn about the network status updates so to speak through this this node and how it’s proceeding” but it’s really useful when using this remote node because it means that it facilitates the initial sync process. When you’re sort of putting your remote node back online sorry, when you’re putting your your wallets back online. So when you put your wall back online and it hasn’t been around for the past few days or hasn’t communicated with the network in the past few days it needs to look at all the recent data that’s been generated and that term and if any of it’s for you so use a remote node. That means that you can get those blocks directly if you tried to run your own remote. No, your own full node then you would need to sync up the block data sort of sort of that way.
Justin: [00:04:31] But one thing that we really want to emphasize though is that when you’re using a remote node you do not give away your private key so you don’t get the right to spend money to these nodes. Instead you’re simply sort of requesting information from them or giving them information. But none of the information you give them gives the remote not the right to spend your funds. And similarly we’re not referring to the private view key either like you would give to a mymonero or openmonero type service. These type of layer removed in terms of interactivity. It’s less interactive with these remote nodes compared to that sort of setup. But ultimately when you send transactions remote not give you the data that’s needed for you to actually build new rings and your transactions. So you have your one output that you’re trying to send to someone else. You need to find all the other outputs to send transactions. So to send this transaction so you request these other outputs from the remote node they give them to you, you sign on the transaction, give the transactions to remote node and then they broadcast it to the rest of the network. So Sarang can you talk about sort of the actual process of sending that transaction up a little bit more detail.
Sarang: [00:05:43] Right. So suppose that my phone for example wants to be able to interact with Monero network but I don’t want to run a full node on my phone that requires lot of space a lot of time to keep it up. So instead I choose to connect to a remote node and again that can be I know that I have personally setup and nobody has direct data or it could be a publicly available remote node that someone else set up on behalf of the network. First I have to do is I have to tell my wallet software to go and actually synk the full chain. Now that doesn’t mean that it downloads and keeps the whole block chain instead what it does is it requests block information which in particular contains transaction data. Again that node does not know what transactions are destined for me because I’m not going to tell it that it’s leaking information. So instead I basically tell us to just start sending me transaction data and my phone locally will go through and identify the transactions that were destined to me and use those to kind of store some balance information later on send transactions. And of course then as new blocks start coming in that the remote node passes onto my wallet — my wallet can kind of update itself. So it’s keeping a minimum amount of information and relying on the fact that the remote node is keeping its own copy of the blockchain in sync. Then when I’m ready to send a transaction and my wallet already knows what outputs I want to send. So what I don’t know though is all the other decoy output data, I know I remember my phone is not keeping that information because that would imply that I’m keeping the entire chain locally. So instead my phone goes and asks the remote node “please send me the details on the blockchain outputs 1 through 10”. Of course they’re actually going to be 1 outputs that are selected according to a distribution that we talked about earlier. But crucially when I say that I would like outputs one through 10 or one through 11 or however many I want depends on the ring size. I’m also going to be asking for the output that I already know the details of, because remember for every ring that I’m going to be generating I already know the true sender output I know the output that I want to send. But of course I don’t want to just ask. For the other decoys from the remote node because later when I actually send the transaction the node could be like ‘Wait you requested it only 10 decoys but this ring carries a loving members. I know which one the true spend is. That’s bad”. So instead my phone will request all eleven decoys that it’s going to want and then from there build the transaction with them. So again what’s the benefit? The benefit is that the remote node does not learn from that which output is the true spender. So it requests all the decoy information the node itself does not know necessarily what the decoys are. Then my phone will use basically, it’ll use its own crypto libraries to go and do the cryptography to do the signatures and do all the transaction generation stuff to build that transactions and then it will go and actually send the transaction off. So in theory there’s very little communication that needs to happen with the remote node to build a transaction it’s basically just pulling information about the decoys and the actual ring number needed to build a ring.
Justin: [00:08:28] Yes I think it’s important to note that there was a lot of effort that was put forth to limit the amount of data that is leaked to these remote nodes so it’s not super obvious that remote nodes could do a ton of really really bad things. But this is breaking Monero. We’re supposed to go through find all the limitations. So now we talked about the status quo of sort of how these remote nodes work. Now let’s talk about what happens if the remote node you’re using are evil -their attackers are trying to mess with you in some specific way. So what could the remote nodes do if they’re evil. Well they could know nothing could they. They do know for certain what IP address you’re using to connect to them. So if you are on your home network and without any other protections you just directly connected remote node and start sending transactions — they know your home IP because you open the connection from to them from that IP if you try to go through some caution where you. Yeah. If you go through some precautionary use like a VPN in the middle or something you distribute your trust to the VPN service or to the tor service or what other service you tried to throw in the middle. And that would help prevent the remote node from knowing the information based off your IP really clearly. So that would potentially help. But there’s a bigger risk to leaking your IP when you use remote nodes then compared to connecting to the network at random. Because whereas if you connect to the network normally from your real IP. People still don’t necessarily know you sent transactions from your IP. But if you use a remote node they know exactly what transactions you’re trying to set. Similarly they could try and provide you with bogus ring data — Sarang is going to talk a little bit more about this exact sort of attack more specifically and the ways that Monero is trying to mitigate this but you request information from the node and you have no ability to verify information other than the money you control locally, because you don’t have the local copy of the chain. So the node can try and mess with you under certain circumstances and in certain ways to learn some information about your transaction. And then finally they could just be like a simple type attack or they refuse to propagate your transaction. Suppose that you are sending a transaction from I don’t know, a specific Internet service provider connection and they don’t like that ISP for some reason they might just block transaction broadcasts from those sort of ISP companies. Those are some sort of risk you’re taking when connecting these remote nodes that they just won’t do what you’re hoping they will do. They might act in some way. So in that case they’re more so being annoying but they’re being annoying to hear an ill effect. You’re gonna have to find some other way to get your transaction out there. So Sarang can you speak a little bit more what happens if your node receives bogus data and what the concerns are there?
Sarang: [00:11:25] Yeah. This is something that’s kind of specific to Monero. So like I said when you need to send a transaction if you have a ring size of 11 like we do today if I’m going to be sending a particular output I already know the details of the output locally because my phone stores my own outputs data. That’s how it keeps balance information for example but it’s going to request 11 total outputs from the remote node 10 of which I know were decoys. But one of which I secretly know is my own. Of course the remote node could just decide “Well OK here’s what I’m going to do I’m going to replace some of those outputs that I’m sending back to my phone with other corrupted data or with information about outputs that the remote node itself might control” because again I locally don’t have any information about those. I can’t tell if they’re corrupted.
Justin: [00:12:09] So sorry to interject really briefly. So Sarang. To give an example suppose I am connecting to your remote node. I have my output that I’m trying to spend and I request eleven outputs from you. I request my own output I already control yet 10 others that I choose. But since I don’t have any means of verifying those 10 other outputs you might sort of mess with those with any number of the outputs they are requested. You might include information about the outputs you already control or with complete focus. Is that correct?
Sarang: [00:12:43] Yes exactly. So now on one extreme I is the remote node could decide to send justin for example just either all eleven outputs that I control or just all eleven just random totally corrupted outputs. Now Justin software knows his own output and since I sent all corrupted output information that means that the one that his phone knows about is corrupted.
Sarang: [00:13:05] So in that case his wallet (if it is set up correctly to do this the default wallets are) We’ll just raise holy hell and tell him that something is going on and that there was some kind of corrupted output. Now if he’s smart he will immediately disconnect from my node and never trust it again now what he could try to do if he was just I don’t know really really bad at this is he’d be like well fine I’ll just I’ll just try generating the transaction again. Well if his wallet is not smart that means it’s going to try to spend the same output again but it might request an entirely different set of decoys. And in that case I who am again receiving this information would be able to see the inputs that are in common between those requests that he made and try to pull some kind of ringing intersection shenanigans and figure out what is true spenders. But there’s a more insidious way to do it. So I’m not going to do this because as well it’s gonna freak out but what I could do instead is maybe I selectively pick just a few outputs. And again I don’t know which one his is. So I’m just gonna randomly pick a few of them and corrupt those and send the data back. Now if I’m unlucky I will have corrupted his true input and then his wallet will freak out and raise holy hell. But if I don’t and if I happen to only corrupt the ones that are used as decoys — his wallet software can’t detect that. And that means that if he sends the transaction anyway I can look at my my data and say “OK That means I know statistically at least that I have a greater probability of trying to determine what his true output is because I know it’s not one of the ones that I corrupted”. So the wallet can run I can basically try to pull some statistical attacks to try to gain information about what the true spend is. It’s kind of a subtle attack that only works some of the time it’s kind of insidious. It’s worth noting though that in all of these cases this does not mean that the wallet remote node can do anything like try to spend funds that it doesn’t control. That’s not possible. All it means is that the remote node can try to pull some shenanigans to either definitively show what the true spend was in the case of Justin requesting totally new outputs or it can try to corrupt selectively some of the outputs in an attempt to gain a greater chance of being able to guess the true ones statistically. So it’s very subtle and it involves the fact that you have to request information from the remote node some of which you can’t verify is correct.
Justin: [00:15:21] So if I was if you sent a transaction or sent outputs to me that were corrupt and I signed it and gave it back to you would that transaction be able to be relayed to the rest of the network or what. Were network rejected.
Sarang: [00:15:33] So it depends if the outputs that I’m corrupted are still valid outputs somewhere. If I just start replacing the outputs I send to you with just random BS data for example then you’ll basically be signing something that has BS data on it and then the network will just reject it. But if instead I happen to control a selection of outputs and those are the ones that I feed to you. Those are all valid up puts on the chain somewhere and I happen to control them. Then you would sign a transaction that does to the rest of the network appear valid and it would actually be accepted.
Sarang: [00:16:03] So it all depends on how I do the corruption
Justin: [00:16:08] So we’re now gonna end up with what are ways that people can mitigate against these sort of attacks. I mean the real obvious one here is don’t use a remote node right. If you can help it you can avoid all this by using your own node. There are still considerations with using your own node but ultimately that’s what’s best for your security and privacy. But and even if you want to sort of straddle the convenience of a remote node with the benefits of running your own full node what you could do is just run your own full node at your house and just have it running 24/7 and then you can have this your computer run a sort of software library like openmonero for example where you’re able to essentially connect to it as your own remote node or as your own mymonero type server. And that way you’re able to get all the benefits that you would get by connecting to a remote node but instead of trusting someone else with this data or trusting them not to pull shenanigans that you’re trusting yourself there’s no sort of incremental level of trust there. You’re getting all those sort of benefits by using your own set of infrastructure that you have set up not trusting someone else’s set of infrastructure. But there’s a few other reasonably safe options and this really depends on your use model. If you are willing to trust some people say I think Sarans is really awesome dude and Sarang is like hey I’m running a remote node or I’m running a node at this IP address if you want to send transactions through it by all means go at it. If I trust Sarang, then I can use this remote node. And of course I still need to trust him but if I’m willing to do that then that’s OK for my specific threat model identified in that case what’s potentially a little less safe it depends on the exact set of circumstances of course but you can just connect to a list of remote nodes at random connect to some remote node that you have no idea who runs it or any sort of circumstance, as an example there are several services and I’m going to share my screen here that show you or at least that pull up a list of all the remote nodes that are available. This is an example. It’s a node that owned that systems and you can see that they just scrape them in Monero network for open nodes. Now there’s quite a few of them on this list. I’m obviously not going to cover all of them or any of them specifically but just as an example. These are all nodes I can connect to right. They’re available. They let me do it. So I theoretically could connect to them and just connect to one at random but then of course I don’t know who’s behind it. They could be you know on some shenanigans or something. And of course the best thing you really can do is if your wallets starts complaining to you that something’s wrong with the remote node something is wrong with the remote node so stop — don’t use it anymore connect to another one, because if you’re getting some of these warnings in your wallet it’s really likely that the remote notice is acting up and trying to be malicious against you. It’s not like any reasonable or remote node will be configured e.g. bogus data to begin with by default. That does not make any sense so I mean that is not the case.
Sarang: [00:19:34] The best possible scenario is that you’re connecting to an unreliable node which you know is not useful. And then of course the worst case if it is being malicious and trying to pull some shenanigans in order to gain information. So there are plenty of trusted nodes that are either run by trusted community members or trusted themselves by trusted community members. But again the best solution is just to run your own or remote node. You can still use a lower power device like a phone to connect to that but you know that the chain data that’s being provided by is controlled by you and you are the most trusted person to you. I hope.
Justin: [00:20:09] Exactly. And then one last thing that we talked about a little bit earlier. If you want to help hide some of the network layer metadata from the remote node potentially not knowing what your location is for instance you can still route your connections or Tor or something maybe not if you’re syncing your data that would be really slow but especially if you’re just doing transaction broadcasts and things with remote nodes that could be pretty reasonable. If you want to use a VPN that you trust for instance that that might be beneficial for meant for many users with those specific threat models there too. All right. So I think we covered a lot about what the status quo is about what remote nodes are in Bitcoin and Monero and what’s unique to the Monero part and what some of the concerns are with using remote nodes in regards to security and privacy. Is there any last thoughts you want to leave listener with Sarang?
Sarang: [00:20:59] You know just that this is something that really depends on your personal threat model and your personal use case. And you know it’s worth sitting down for 10 minutes and deciding what level of trust you’re willing to offload onto other entities if any and then use that to make an informed decision about your interaction with nodes at all.
Justin: [00:21:18] All right. Thank you again Sarang. Thanks. Thanks again for watching.