Ben Carman - 00:00:00:
I think, like, the next age of bitcoin privacy is probably going to be things of, like, not just privacy enhancing technology, but also like, making it look like normal on chain activity. We figure out a way to hide amongst the crowd, but it's very obvious we're the guys in the crowd all wearing masks versus now we'll be able to be the guys in the crowd that are just like, wearing everyday street clothes that look like everyone else eventually. A major problem with things like CoinJoin is, you do a CoinJoin and say you have like an enemy set of 100, but as time goes on, those other CoinJoin participants kind of can accidentally Dox it or like, screw up the privacy and like, Mergecoin or they deposit in the coinbase or something. Your set kind of slowly goes down over time. So you could actually just CoinJoin a Lightning channel where you could slice it without updating it, just do a CoinJoin of a Lightning channel, and that would basically allow you to have even more privacy with your Lightning node if you weren't around. In 2014, Apple bans like, all bitcoin wallets from the App Store and people were breaking their iPhones, really mad and stuff like that. That's like, well, now if you had an iPhone, you couldn't have a mobile wallet. So with Mutiny, you just go to a website and now you instantly have a mobile wallet.
Kevin Rooke - 00:01:14:
Ben Carman is a Lightning privacy researcher working on a handful of Lightning projects, including Mutiny Wallet, the Bitcoin Company and Vortex. In our conversation, we explored the state of Lightning Network privacy. Today, we discussed the challenge of improving one's privacy, and then we got into the work that Ben is doing to bring Lightning Wallet directly into the browser. With Mutiny Wallet, Ben has also been added to today's show splits. So if you enjoy this show and if you learn something new, the best way you can support myself and Ben is by sending in sats over to the Lightning Network. You can use any Podcasting 2.0 app. There are lots of them, but my favorite to use is Fountain. Before we get into today's show, just a quick message from our sponsors. Today's show is sponsored by Voltage. Voltage is the premier provider of bitcoin and Lightning node infrastructure. Today's show is also sponsored by Stakwork. Stakwork is a Lightning powered transcription tool that takes the best of AIs and humans to create better, faster, and less expensive transcripts. We'll have more from Voltage and Stakwork later in the show. Ben, welcome to the show. I am so excited to talk about Lightning privacy, Mutiny, and all the work you're doing. But before we get into it, let's give listeners your background. Tell everyone how you first discovered bitcoin and why you decided to build on Lightning.
Ben Carman - 00:02:42:
Yeah. Hey, Kevin, thanks for having me. Bitcoin journeys. It feels weird. It feels like I've barely been into bitcoin for that long, but I guess I've been here for five years so it's kind of a while now. But I got into bitcoin at the very top of 2017. Bitcoin is at like twenty k and I was like, oh, I want to get rich too. And then obviously didn't. But yeah, I was in college studying computer science and heard about it on a comedy podcast, bought a little bit and was like cool and then price went down. But I started watching a bunch of Andreas videos and started listening to podcasts and stuff like that and quickly fell down the rabbit hole and my entire political beliefs changed. And here we are five years later and during that, maybe about a year in the bitcoin, I was like, I had some shitty internship where I did nothing all day. So I just started doing open source work at my job and just filling the time and I ended up falling in love with it and then later dropped out of college to actually go and pursue that. Yeah, it's what I've been doing for about the last four years. And I started out working on Wasabi actually and enjoyed that and then later got hired full time at a Suredbits and did that for two years working on DLC and maintaining the Bitcoin S library, which is like a scala implementation of Bitcoin. And after that later joined the Bitcoin company, which I have been here now for about a year and a half. And kind of all during that, just like my main open source interest has really just been like Bitcoin privacy. And then as Lightning has matured more, it kind of has evolved into that as well, where not only is it good privacy tool, but as well, it's really cool tech anyways too. So just enjoying it and all that stuff.
Kevin Rooke - 00:04:44:
Yeah. What attracted you to, first building open source software and then second the privacy aspects of Bitcoin and Lightning?
Ben Carman - 00:04:55:
Open source is just like it's just beautiful to work on something I love is like a problem I have a lot of where I work at the bitcoin company right now is a lot of our stuff. It's just like we're talking like gift card, random APIs and stuff. If something breaks, it's like, I can't just like, let me just go to the GitHub and see what am I doing wrong or something. It's like, oh, I got a file support ticket, or send an email to some random dude that is like a terrible worker and get a reply back in a week versus open source. Be like, oh, let me just go read the code and see what is happening here. Maybe it's a bug on their end, maybe it's a bug on my end. Maybe the documentation is bad and I can fix that. You kind of own the whole stack almost always. So it's really nice. You just have complete control of what you're doing. And it's like you end up collaborating with some of the coolest people in the world, where you make a poll request to Bitcoin Core and Peter will reviews your PR. It's like, holy shit, you don't get that level of expertise in a normal job. I remember my first poll request to Bitcoin Core was a documentation PR, and I learned so much in just that PR. It was, like, really cool and it's kind of like a beautiful thing. It's like all the collaboration that happens between open source, not just like inside of a project, but between projects and stuff like that. That's what I really enjoyed. And then privacy is a cool thing because it's not just something that's like, obviously it's good for the world and benefits people. It's also a very hard problem. So it's something that it's not just like, oh, let me just add privacy real quick. It's something you need to think about and it's always evolving and it's an arms race of where you get better, then the attackers get better, and so you're always trying to improve and it's really like a hard thing, but once you accomplish it, it's pretty cool. I sent a transaction that no one knows about and it's a powerful feeling to have. And really, actually, it's not like you can build something like a random Bitcoin app, but if it's private, you could actually change the difference for the world versus just along the same payments is what every Bitcoin wallet does. But making a private payment is not something that everyone can provide and that is actually a lot more powerful.
Kevin Rooke - 00:07:16:
Right? You just said privacy is an arms race. Who's winning the arms race right now in Bitcoin?
Ben Carman - 00:07:24:
That's a good question. I don't know. I think we probably are because there's like chain analysis, like elliptic and all their competitors and stuff, and actually they make a lot of money, which is one scary. But the thing is that the privacy devs are heavily underfunded and we seem to be winning in that regard where these chain analysis people, they can't do anything against things like CoinJoin or Lightning. So that's why when places like BlockFi were like, blocking withdrawal or deposits of CoinJoin funds, it's because we want in that regard where they're like, we can't track this, what do we do? So they just had to resort to blocking it. I think that's a sign of us winning where we've reached a point where they're just like, we know this is anonymous, we don't know where it's coming from. And they have to just throw their hands up and be like, sorry, it is about that. They block it. But that's what happens when you work with regulated institutions. So I think in that regard we're winning. But there's always ways to improve. And a lot of it too isn't just like adding things to Bitcoin or writing better software. A lot of it, as well, it's just like education and telling users like, don't do this, don't do that, because sometimes we first get a bitcoin. You might just use one address. This is easy, but you quickly realize you shouldn't reuse addresses if you care about privacy. And that's a lot of things. It's like super simple things like that, where you can have the best users in the world being the most private. But if everyone on Bitcoin is reusing addresses, then it doesn't totally matter because you want a huge entity set of all Bitcoin users. So to do that, you need everyone improving their privacy.
Kevin Rooke - 00:09:27:
It strikes me that are there two parts to this privacy battle? Like the one side you mentioned where you have a CoinJoin or some kind of privacy practice that's put in place to make transactions anonymous or hard to track. And at some point a service might throw their hands up in the air and say, hey, we can't do anything about this. We're going to stop all transactions. Right. But that presents another problem, which is like you could win the privacy battle and come up with a solution that can't be tracked. But if you then lose the regulatory battle and have all the services out there not allow people who use this CoinJoin or whatever privacy preserving tactic it is, if all these other services get regulated to the point where they can't even service those people, it almost ends up being a bit of a loss. Right. It feels like there's almost two battles that you have to win.
Ben Carman - 00:10:27:
Yeah, definitely. The thing is, the reason they were able to block this transaction, they say it's explicitly like a CoinJoin. It's very obvious, On-chain. When someone's doing a CoinJoin, this user is seeking privacy. We don't like that, so then they block it. So I think the next age of Bitcoin privacy is probably going to be things of not just privacy enhancing technology, but also making it look like normal On-chain activity or just any bitcoin activity. Lightning is a perfect thing of this because Lightning is a straight, like UX, improving the bitcoin. I think it improves a lot of things. Faster payments, cheaper payments. You've run a Lightning podcast, but as well it increases like sender privacy a whole bunch where if I deposit a new exchange, the exchange has no idea where that money came from. So when Chainalysis is like, where did this money come from? They're like, oh, we don't know. That's how Lightning works. If they want to support Lightning, then it's just like, well sorry, we're giving users privacy. So I think things like that improve it. And for on chain, there's lots of different ideas on how to do this. There's stuff like Coinswap where instead of doing what the CoinJoin, you like swap coins with users and you can trade histories. Also, Waxwing, he gave really good talk at Bitcoin plus plus I don't know if it's up on YouTube yet, but it will be eventually. And he talked about this thing CoinJoin basically you do CoinJoin that don't look like CoinJoin. It looks exactly like normal on chain activity and by doing that then it's just like it looks like this user made ten payments but actually this isn't that user anymore. They did a bunch of CoinJoin and this is now renewed coins and now they don't know exactly where the money came from when you deposit it. So stuff like that should improve it a lot. Where right now most of our privacy techniques are explicit. You're saying like I am a privacy seeking user and the power is up, you don't like that. So they try to stop that. But as we move further into this stuff, like we've solved, okay, we can kind of we figure out a way to hide among the crowd. But it's very obvious we're the guys in the crowd all wearing masks versus now we'll be able to be the guys in the crowd that are just like wearing everyday street clothes that look like everyone else eventually. And that will really help the privacy aspects moving forward. We're now you're kind of talking about the sensors that persistent access to privacy where say they can sensors choosing it, but after the stuff we could blend into the crowd completely and they wouldn't even know that we are privacy seeking individuals.
Kevin Rooke - 00:13:05:
Right, that makes sense. In preparation for this conversation, I took a look through the Cypherpunk Manifesto from Eric Hughes and I wanted to just read off a section of it that I thought was particularly relevant. Eric says when my identity is revealed by the underlying mechanism of a transaction, I have no privacy. I cannot here selectively reveal myself, I must always reveal myself. Therefore, privacy in an open society requires anonymous transaction systems. He says until now, Cash has been the primary such system. An anonymous transaction system is not a secret transaction system. An anonymous system empowers individuals to reveal their identity when desired and only when desired. This is the essence of privacy. So my question to you is, is the Lightning Network going to be the privacy preserving successor to Cash?
Ben Carman - 00:14:07:
Maybe, I don't totally know, the Lightning has a problem or no problem, but a trade-off of as the more you increase privacy, the lower payment reliability becomes. So today we have like decent payment reliability where before this we were trying to use Beta Live, I was able to deposit $10 easily and it worked just fine. It works. But if beta was using the most private way of using Lightning, as I was too, maybe the payment wouldn't work as well. And as trade offs where now if everything was over tour, then payment is going to go a lot slower and connections could drop accidentally and stuff. If you're also using stuff like binded routes then you can't try every route that I can find in the graph and stuff like that. So it does get harder. I think eventually the Lightning community is going to have to kind of make a decision. Or maybe it'll just bifurcate of which way are we moving? Are we going to go towards like maybe we just say, like, fuck it. Lightning is not going to be the private payment network. We were going to focus on 100% of payment reliability and then we build privacy as a layer three on top of it. Or maybe we say Lightning should be our private payment network and we focus on 100% of privacy and then Paint reliability goes down. And then we just work on ways to solve that later. It's all trade offs, but I think we can reach a good middle ground as well. As I said, the network can bifurcate where you could have payments from river to Zebedee be 100% reliable. But if you have activists in North Korea paying to activists in Africa, maybe that will be a harder payment. But if it's more private, then it's kind of worth it for them. So I think it'll eventually probably just be trade offs, but it does have much better properties than Bitcoin in some regards of privacy. So I think we can achieve it. It's just a lot of work to go.
Kevin Rooke - 00:16:19:
Right. Are privacy and reliability always going to be trade-offs? What's the fundamental reason why these two you're trading off one for the other?
Ben Carman - 00:16:32:
The main reason is on Lightning, you have like these I guess to start out on Bitcoin, you just have to say, I want to send my funds to this address and that's it. You don't need to have these hops or anything. So the main privacy concern there is just like, where did my funds come from? And now I'm going to link it to your address. So you're worried more about previous history versus with Lightning, you kind of have this fixed node ID that you tie all of your channels to and all of your receives are saying like, this is my node ID, please pay me. So you're kind of inherently reusing the address always enlightening when you receive money. That's like the main problem in privacy. And as well, for the reliability, we don't just say, I'm saying to this address, we have to find a payment route across the network to this thing. So if you make my node ID harder to find, well, now it's harder to actually find a payment to reach you. So that's like the main trade off you get there, where one of the most likely things that will be happening in Lightning in the next few years is something called Blinded Pass, which basically says you don't really give your Node ID. You say, here's an encrypted way to get to my node ID. And then it uses like the onion routing to find you but the thing is you supply that. So you say this is a blinded path to get to me. And the thing is, if that path doesn't work, then the user can't make another attempt to pay you because that's the only way they know how to get to you is that blinded path to get to you versus like if today if you don't use a blinded path then if that one fails, they just try not to get them. Try 100 different paths until it works. So it would become then like, oh, that path didn't work. And then you give them a different one and they try again. Maybe that doesn't work and things can fail. So it's a lot harder in that regard and as well as things like just using a clear net over Tour. Tour is much slower so just payments take longer and stuff like that. So it's just all different trade offs there that are hard to do. But I think we're going to move in the right direction.
Kevin Rooke - 00:18:51:
Now I think you might be biased for this next question, but I have to ask whether or not you think you mentioned this bifurcation possibility that the Lightning community could split or could decide we're going to go all in on reliability or all in on privacy. If that were to be true, which direction do you think the Lightning community should push in towards privacy or towards reliability?
Ben Carman - 00:19:21:
Question honestly, it should probably be both. And it's just like users will pick which one they want. Like maybe like when it's river paying Zebedee, they're just like, you know, it's a company to a company, so they don't care. So they'll do the completely like reliable way, totally unprivate payment or not unprivate, but less private than it could be. And then when I'm say like receiving donations or someone on the internet, that's like Caudal not raising funds for his court trial or something like that, he wants to accept it more privately so then they would use more privacy seeking Lightning techniques. I think that's a perfectly viable world where instead of like it being a network wide decision, it's a user side decision. The only problem there is things like routing nodes. If you try to run like a completely private routing node, you kind of get screwed or you kind of screw over other people if you're using torn stuff. Now my parents go through you and it ends up being way slower. So there's kind of trade offs there, but in most regards it should be like a kind of user decision. So that should kind of make it better. But if my wallet doesn't support those privacy features that pay you, then I just can't pay you. But I think that should be easily solvable because most people are good at updating and stuff. But yeah, I don't think we'd have a total bifurcation. It'd just be like kind of like, okay, I'm going to download Muun wallet. Okay. This is the reliable wallet. It's not private. And then, okay, I'm going to download private Lightning wallet. Okay. This one's more private and can make payments in the ways I want. So I think it would more move to that regard, but we'll see.
Kevin Rooke - 00:21:16:
Yeah. Do you think people today using the Lightning Network understand the importance of privacy? Do you think there's a gap in educating people about it, or I just love to hear your sentiment on how aware people are today about their privacy, and I think you view this as a very important issue, and I guess some bitcoiners that do as well. But I get the feeling that it's not everyone. And certainly when I step outside of the bitcoin space, I never hear talk about privacy. Like, everyone knows all their data is online everywhere, and they basically have given it up.
Ben Carman - 00:21:54:
Yeah.
Kevin Rooke - 00:21:54:
So I wonder, do you think bitcoiners as a group are appreciating the importance of privacy?
Ben Carman - 00:22:00:
Yeah, it's a hard problem. I know bitcoins are definitely doing better than normal right now. I'm in my childhood bedroom, and my parents have an Alexa downstairs. It's just like they're totally owned. But I think bitcoin is definitely more conscious of it, and at least they won't make fun of you for seeking privacy. They're like, okay, I congratulate you, but some people are like, I'm too lazy, or I have better things to do, or they don't want to pay the trade offs, which is fine. Like the quote you just read, you're allowed to reveal information if you'd like to, so you should just be conscious of that and know the implications, I think. So if you want payment reliability and not privacy, that's fine. There's nothing against that. Making a quick payment for coffee is extremely nice, so that's fine. But yeah, I think the Lightning community, by and large does understand it. I think a good data point on that is recently when Amboss announced they were going to have people extend all their channel no balances to them. Everyone was like, what the fuck are you doing? This is not cool. And they kind of rescinded that. So it seems like people kind of care. It's not as good as it could be. A lot of people still do a lot of bad privacy practices and stuff. But I think by and large, there is a at least people know that they should care about it and want to care about it. So I think and then when ours obvious things like that, they're like, well, we cannot do this. This is not good for people. So it does seem like people are actually working on it and stuff.
Kevin Rooke - 00:23:50:
So far it feels like the fight for privacy, at least in the bitcoin and Lightning community, has been a bottom up fight, where it's been advocates and users demanding privacy themselves, and not a top down one where a company or a government is improving the privacy for their users or their citizens. But recently I have seen a couple of promising announcements from Apple and Google trending in the direction of more privacy. I believe both released end to end encryption. I think Google did Gmail and Apple did some icloud upgrades. I wonder, is there a case for top down privacy or does that go against the idea of users kind of enforcing their own privacy?
Ben Carman - 00:24:44:
I think there is extremely strong case for it a good statistic on this and definitely why you should once Apple rolls out the encrypted backups, you should definitely use it. I think Apple complies with 90% of all when they like the government request data from them, they give it back 90% of the time. Not only is that just like a waste of their time and a huge headache, but they probably have entire lawyer staff they need to pay of like, approving and denying these and just like all this extra software they're written to extract that data and give to the government, stuff like that. If you can just say the other hands up, sorry, we don't have the data, we can't give it to you, it's encrypted, then they don't have that problem anymore of having to deal with that. And I think we saw that pretty well during the trucker's stuff in Canada when the government was subpoenaed noncustodial wallets. Dude, we don't have the money. It's a non custodial wallet. When you don't have the power to, like, screw over your users, it just makes it life easier. Sorry, like, sorry, I can't and then, you know, there's nothing they can do. So I think it definitely lowers your burden on required needs of things you need to worry about, like regulatory wise, it does make the actual software sometimes less user friendly or harder to use or harder to develop, but I think we have good enough engineers in the world to solve that problem. I think getting around the lawyer stuff is like, always a nightmare no matter who you are. So I think that's a huge plus for the top down case. And I think I do like the two cases you just mentioned I think are hopefully proof of that. Even if it's just users demanding it or if they're just like, this is a headache to deal with, I think it's all an improvement either way, so.
Kevin Rooke - 00:26:38:
Okay, that makes sense. There's a case then for companies to get rid of their legal overhead and their expense headaches by implementing privacy practices that don't even let them see the data that a government might want to access. But now at the very extreme end of this top down approach, is there a case for a government ever trying to promote privacy? I mean, that's typically the person that you're shielding information from or you're saying, I don't want to reveal this information to a government. Is there any case for could you make a case for a government wanting their citizens to have more privacy? Because we can do it at the company level?
Ben Carman - 00:27:23:
I think you probably can make a case. Like you said, normally you're fighting against your own government. If we did live in a world where our government actually cared about us, I think we could have that where a good example is. Like when the Equifax happened here in America, I think tons of 100 million people entire tax info got leaked. And I think the data was then probably quickly sold to all China and our enemies and stuff like that. So if our government actually cared about privacy and security, then all of our citizens data would not have been given to an adversary. So I think that's like a strong case for them. But the problem is they care much more about being able to use that data against us than China using it against them. So it probably won't happen. But I think, like, you know, there is a case for them to, like, you know, if we're like national security of, like, we don't want our enemies having data on our citizens as well. Like, you know, the like, you know, they're like CIA agents or like NSA agents or, you know, military personnel are included in that data, so they can use it against important people and stuff like that. So maybe that's the case, but I wouldn't bet on it.
Kevin Rooke - 00:28:40:
Yeah, that's fair. Okay. That's really good stuff. I want to shift the conversation to a report that you worked on recently, Lightning privacy report. And you did this this great report. I'll link it in the description. It highlighted three different sections of Lightning privacy. One was a routing analysis. One was channel CoinJoins, one was blinded paths and trampoline routing. Could I get you to kind of explain at a high level how each of those three items might harm a Lightning user's privacy?
Ben Carman - 00:29:19:
Yeah, this is some work. That me, Evan Kaloudis, Tony Giorgio and Paul Miller, I guess. And Max Hillebrand, got sponsored to do by Wasabi and MAGIC Grants to work on. Just basically just kind of doing an overview of Lightning privacy and how would you design a privacy focused wallet. And this is kind of like just the report we came up with after some research and talking to various members in Lightning community, as well as just doing our own research. If you go to Lightningprivacy.com, you can read all the articles or blog posts about it. I guess we just go through each individually. Like, routing analysis is kind of when I'm making a payment, not to a direct channel party, but like, across the network, how do I make sure that someone doesn't know information about this payment? So Lightning has this nice property of what's called onion routing, where if Alice is paying Bob or say, Alice paying Carol, but they both have a channel to. Bob. Bob just knows, okay, Alice sent a payment to me. I need to forward it to Carol. He doesn't know if Carol is the actual recipient or if it's then going to Dave. Bob doesn't know if Alice was the actual sender, if it previously came from someone before, and if you incorporate things like multi path payments, he doesn't even know the amounts and stuff like that. But there are some different ways you can actually still find out a lot of information. There's been some good research papers on stuff like if you are able to probe lots of channels. Basically like a probe is just like you kind of send fake payments to a node and see if they succeed or not based on they all fail, but you get different error messages on why it failed. And you can kind of Gillian information for that, where if you get an error message from like if you're trying to probe Alice, but you get an error message from Bob, you know, okay, this payment was probably too small and you can lower the payment size and then it makes it to Alice. Now you know, okay, this channel has about this much balance and you can just try different amounts and see like, okay, their channel has 0.1 bitcoin in it and you can kind of glean that from just probing for free. The idea of all this is like, how do we solve these kind of problems when making payments? And kind of what we found is one of the biggest problem right now that was planned to be fixed is basically using hash time lock contracts instead of point time lock contracts. Basically right now your Lightning payment is secured by a hash where when you make a payment, everyone along the entire route says, like, this is the hash, and then they unlock it with a pre-image. And if you don't know what those terms means, it doesn't really matter. That's kind of the idea. And the problem is that hash is exactly the same along the entire route. So if Alice, Bob and Carol all collude and be like, hey, look, we had the same payment, and they can clean some information about that, especially if Alice, Bob and Carol are all the same actor, well, then he thought you made a payment across three peers and they got some privacy. But actually, it was the same person, and now they have the extra information. So something called point time contracts will let us fix this. Basically works the exact same as HTLCs or hash time loud contracts. But with these we can make it so that instead of having the payment hash being the same across the entire route, it will be a random number between each peer. So you wouldn't have it like a direct be like, okay, we have the exact same payment kind of thing. So that would improve kind of payment privacy a lot, where now you can't just run a bunch of routing nodes across the network and see payments going across all the way that is planned to actually comes to Lightning Network. It's been planned way before we wrote any privacy research stuff. It's a huge privacy improvement, but it does fix some minor attacks as well. That's like one of the main ones we found. But the thing is, too, even if we use this point in time, life contracts and you can no longer could have this definitive, like, oh, this is the same payment, but you can still kind of do some analysis. Where in the same second we both receive if I send a payment off and then it comes to my other node with pretty much the same amount, it might be like, okay, I just got a million sat payment and then a million stamp payment showed up on another node. Those are probably the same payment. So things like basically we call it like timing analysis and amount analysis or other problems. The timing analysis is really hard to solve. This comes again to the payment reliability versus privacy stuff where you could say like, okay, here's the payment, but don't forward it for 3 seconds. So that would kind of hurt the timing analysis. The problem is now my payment is going to take at least 3 seconds longer, so you're hurting your payment reliability. So there's another trade off there and with the amount analysis we can kind of solve that with things like multi-pass payments where instead of just making a straight shot payment to someone, you split it up. So there are kind of solutions there, but we kind of go into more details on how maybe a perfect version of doing multi-pass payments could work. Because today I think most implementations just like they just implemented it in kind of a naive way of just like, let's just split it up and just keep having the amount until it works instead of kind of trying to seek more privacy seeking ways of doing the splitting and stuff. That's kind of some recommendations we gave and stuff like that. We have some cool graphics in there as well if you want to look at that stuff.
Kevin Rooke - 00:35:32:
I hope you're enjoying the show so far. Just a quick message from our sponsor, Voltage. Voltage empowers engineers to integrate Bitcoin and Lightning Network payments into their business stack with an enterprise grade experience. The team at Voltage is building the complete tool set so that you can do more than simply spin up nodes, but also understand and interpret your node data. Their new product, Surge, gives engineers the capability to quickly solve problems and optimize operations. With node insights and visibility through time series data, you get dynamic and complex insights never available before. You can get complete control with insanely fast onboarding advanced client side encryption and zero management infrastructure, making backups networking and upgrades simple. Get a free seven day trial today at Voltage.cloud. And so that's the routing analysis, the first section there. What about channel CoinJoins? How can that help improve someone's privacy?
Ben Carman - 00:36:34:
Yeah, so this is what the section I wrote. Primarily, it's a Lightning privacy problem, but it's mostly actually like an unchained privacy problem where Lightning is great, has all these nice privacy properties. We don't take payments forever, and we have this nice onion routing, all the stuff I just talked about. But at the end of the day, you have to open a channel with your unchained bitcoin. And if you opened it with your KYC funds from Coinbase now, it's kind of obvious. Okay, Coinbase is like, this guy just opened a Lightning channel. Ben Carman owns that node. That's not the best. So using things like using just traditional on chain privacy techniques can really improve your Lightning privacy. Because now instead of linking all of your funds that were linked to your identity to now a random pub key, you could actually break that link with something like CoinJoin. So I kind of break down multiple different ways of how to do this. The first is kind of what you can do today, where you just take your normal bitcoin and CoinJoin it and something like Samourai, Wasabi or JoinMarket. And then and then you just like, send that to LND, open a channel, and now you have a more private Lightning channel, which is interesting and cool and huge improvement. But what I think is more exciting is basically opening Lightning channels inside of a CoinJoin. So basically, if you could, instead of doing this three step process of getting bitcoin Coin joining it, then sending it to your Lightning Wallet, and then opening a channel, it's a lot of steps there. Instead, if you just had your Lightning Wallet, CoinJoin the funds inside, and then open a channel inside of that CoinJoin, you would greatly improve your privacy because, one, you're just saving on chain space and time and fees. So that's really nice. But as well, you kind of like, not only are you improving your privacy, but if everyone else is opening Lightning channels, you're improving privacy for the entire network. And privacy only comes from hiding amongst the crowd. So if it's just you doing it, then it's like, oh, I know Ben. He's the guy that does that. That's him. But if you 1000 other people are doing it now, it's hard to delineate who's doing what. And the really cool thing is, once you're opening channels inside of a CoinJoin, now they don't know, okay, your channel counterpart, you'd be like, okay, I know this channel came from this person, but they have no idea. Like, the fund linkage is very hard to do. And as well, in that transaction, there's like a bunch of other channel opens. Now they don't know, okay, are those Ben's channel opens or those Kevin's channel opens. They don't know if so you're kind of getting this more privacy of like because you normally don't just open one channel, you open many channels. So this would kind of improve that where you can kind of open many channels without revealing that. Okay, I just opened five channels. I just opened one. It just looks like you presented a CoinJoin opening channel. So only your channel counterparties would know exactly where this is coming from. So that would improve it a lot. But the problem is today that the current CoinJoin implementations wouldn't really support this because opening Lightning channels is actually kind of a hard problem. There's a lot of denial of service stuff built into Lightning implementations to make it so you can't just say you're going to open a thousand channels with someone and they never do. And then they have to be forced to do all this processing and stuff. So there's like all these timeouts and timing stuff to prevent a DDoS detector on your Lightning node. So it kind of makes it so your CoinJoin implementation needs to be aware of all these to have to be able to properly do a CoinJoin. So I kind of talk about that in there. And then further, we kind of talk about what would be the end game of the coolest version of this. And something that we came across that would be probably I think would be really awesome is Splicing Coin Joins. So if you know what Splicing is, it's basically like a way to update a lighting channel. So you can have an open Lightning channel and be like, say you have a one bitcoin channel, but we're getting a ton of payments. Let's make this a two bitcoin channel. What we normally have to do is either just open another one bitcoin channel or close it and then open a two bitcoin channel. But that's extra on chain transactions and we're going to have some downtime or the two channel ways. It's kind of ugly. So what you can do is with slicing, you basically just kind of update the channel where we do a transaction to basically like, we'll add in that one more bitcoin and the channel will never close. It'll just be confirming and we can still make payments during that confirming stage. And with that you can kind of update a channel. And the cool thing is this CoinJoin or this Splice protocol allows for not just like two channel parties to participate. It allows for anyone on the network to participate. So I'll say, like, hey, what's splice? And then you're like, cool. And then once we agree to Splice, we'll announce to our peers like, hey, we're doing a Splice if you want to get in on this. And they can come and join and then they'll do the same talk to their peers. So you kind of end up getting like this huge transaction of many splices. And around this you could build basically a CoinJoin. You could say like me and all my peers are just doing a big splice to update our channels. And the cool thing is, if we ended up doing something where we could just not add or remove funds from this splice, we can just say, well, we have all these open Lightning channels, they've been open for a year, I want to make it and update it. So I want to remix my coins again, basically CoinJoin. So you could actually just CoinJoin a Lightning channel where you could splice it without updating it, just do a CoinJoin of the Lightning channel and that would basically allow you to have even more privacy with your Lightning node. Where a major problem with things like CoinJoin is you do a CoinJoin and say you have like an envy set of 100. But as time goes on, those other CoinJoin participants kind of can accidentally DOX it or screw up the privacy and merge coins or they deposit in the Coin base or something. Your set kind of slowly goes down over time. So with this, with the Lightning channel, it's kind of supposed to be stuck open forever. But this, you could kind of remix it and kind of get that privacy back of always being able to CoinJoin as well. This could greatly improve just CoinJoin and Lightning liquidity at work. I think today, like Samourai maybe, it probably has one of the most highest volume they have like 5000 bitcoin in their pool of CoinJoin funds. But I think Lightning is in the same regards. Like if we can merge those two now, we're doubling both size of CoinJoin Liquidity and Lightning Liquidity. So I think that could be a huge boom for both. And we write about it more and there and how it could work and all the trade-offs, but I think that would be one of the coolest potential things we could do. But the problem is Spicing is years away. But I'm excited about that though.
Kevin Rooke - 00:44:06:
That is very interesting. And just on the topic of CoinJoin, I think you mentioned Samourai has 5000 bitcoin in their CoinJoin implementation. Do we have any idea of how big this crowd of users is or any estimate on it? Because you mentioned hiding within a crowd is kind of the idea for privacy with CoinJoin's. How big is this pool in terms of number of people today? Or can we estimate that?
Ben Carman - 00:44:36:
I don't know if we can estimate it. It's hard because if you just made the assumption like one UTXO one user, it would be like a huge number and probably not a very good number. So it's kind of hard. The nice thing is Samourai doesn't even know that number, so it's kind of hard to estimate. But the nice thing is a lot of times with Bitcoin privacy. The user count is important as well, but the liquidity account is just as important because if you come in with 100 bitcoin and everyone else has one bitcoin and it's like, okay, that's that one dude with a lot of money and he's doing it, not only do you want high user count, but you want high liquidity. So big amounts can come in and small amounts can come in and look the same. So we may not have the exact use account, but if we have enough liquidity it should be okay.
Kevin Rooke - 00:45:33:
So this 5000 bitcoin, what exactly does it represent then? What is liquidity in terms of in the context of a CoinJoin?
Ben Carman - 00:45:41:
So like this 5000 bitcoin kind of represents like 5000 bitcoin has gone through Samourai and has not been like spent out of it basically. So like there's like 5000 bitcoin that's been coin joined and they're just sitting there now. They need to be going to remix later or not, but it's been coin joined through their coordinator. So it kind of looks like that. This 5000 bitcoin is all, you know, in the same UTXO cluster kind of thing where trade analysis sees like one of these UTXOs is know, okay, this is a Samourai user. Is it Ben? Is it Kevin? Is it Joe? I don't fucking know. It's a Samourai user and that's all they know.
Kevin Rooke - 00:46:22:
I see. Okay, let's go then to the third topic of this Lightning privacy paper. Blinded paths and trampoline routing. Tell me more about those.
Ben Carman - 00:46:33:
Yeah, so this is around basically like kind of receiver side privacy. So the first topic we talked about the routing node stuff is kind of like on Sunder side privacy where actually have pretty good privacy. When you receive a payment, you don't know where it came from, you just know this is the last hop, they gave it to me and stuff like that. So that's pretty nice. But the receiver side has actually kind of terrible privacy on Lightning. For one, you have this fixed node ID. So it's basically like you're always reusing address on bitcoin where everyone just knows. Okay, you just look it up on Amboss and you can see like, okay, this is the user's node here's all their public channels, they have about like one bitcoin of channels. You can delay a lot of information from that and you can see their fees and stuff like that and make estimates of how much they're earning. So there's a lot of problems there. So if I wanted to receive a payment, I have to give you my node ID and say like, this is me, and then you can just go and look it up and see what you're doing. That's kind of a problem. If I'm making a payment to you, maybe you trust me. Ben's not going to I don't care if Ben sees that information. But the problem is like if I'm making a payment or if I'm making a withdrawal from Strike. Maybe I don't trust Strike and I don't want Prime Trust or US government to know that this is my Node and I have all this money on it. Maybe I bought a bunch of KYC free bitcoin but then received a one dollars payment from Strike and now they see like oh, Ben Carman has all the KYC free bitcoin. That would be a problem. So the kind of solution to this is basically just figuring out ways to hide that Node ID. And the first is a blinded path. We kind of talked about it earlier, but basically you're saying instead of saying like, this is my Node ID, I say this is encrypted path to pay me. Basically just start from the path and figure out how to give it to one guy and then he can unlock the next hop. And then they'll each unlock the next hop until they figure out how to eventually get to you. This does reduce payment reliability like we've talked about, where if that blind path they give you doesn't work, then that's the only way you know how to get to me. But it does improve privacy a lot and it's probably like the best solution we have for receiver privacy. I know if you've been watching Lightning Privacy for a while you probably have heard of Rendez-vous Routing. This is basically just like the Rendez-vous Routing version 2.0 of basically the best way to do that. This is actually hopefully being rolled out soon. I know Eclair has mostly support for it now and I think someone else is working support on it and Eclair definitely has support for the next thing trampoline routing, which is basically a way to kind of just say it's when you're making a payment, you say I guess it can be for both. Yeah, it's on both sides. Basically if I want to receive a payment, let's say I'm not a well connected node or anything like that, you could say use this trampoline to get to me, they know how to get to me. So then the sender will then just send it to that trampoline and then the trampoline will get it to the end user. So this lets you kind of delineate your routing to that trampoline and you can actually chain these trampolines. You could say like, okay, get to this trampoline and then this one, then this one, then pay me a lot of these hops of privacy and the trampoline doesn't know where they're sending it, if it's a trampoline or if it's the actual end user. So you kind of can create this multilayered routing kind of thing of your payments. And this is kind of like the way to fix blinded path like payment reliability where now it's like, I know this trampoline can always pay me, then they can get to there and do this. Then they do the blind and path magic to get to me and it's a little more private. So merging these two makes it kind of like hopefully the best solution we have. And these things too. Trampoline routing is actually like a good UX improvement for things like mobile wallets because right now, like mobile Wallets, they either need to sync the entire chain graph network graph of all Lightning nodes so they can make payments and figure out how to make a routed payment to someone. So it's a lot of data as well as be fairly like CPU intensive and you need to always keep it up to date with all the channels opening and closing. But a lot of times my phone maybe if only make a Lightning payment once a month, then I have to sync that all again and do all the recalculations and downloads that's a lot so I can just offload that to my LSP and be like, you go make this payment. But a lot of times it's not very private. You just say like, hey, I'm paying this guy, can you pay for me? So you kind of lose your send your privacy. So with trampoline you could say, hey, I'm making a payment but just send it to this other trampoline. So now you're kind of like offloading that where they don't know. Okay, say you're using Bitfinex and so you're connected to Async node, they're your trampoline. But now I say Bitrefill is also a trampoline. Then it could look like Async when I say, hey Async, please make this payment a trampoline payment, it's going to go to Bitrefill. Async doesn't know if I'm buying a gift card on Bitrefill or if Bitrefill is just another trampoline and I'm going to go make a payment to like Stacker News or to you or if I'm actually just buying a gift card. So it kind of gives you more plausible deniability there of just being like, where is this payment kind of going?
Kevin Rooke - 00:52:44:
So how does the trampoline act different than a regular Lightning node would if I'm routing through a bunch of different nodes? The nodes don't know where the payment is going either, right?
Ben Carman - 00:52:54:
Yeah. So when I make a normal route to payment, I say like, hey Async, here's my payment, give it to this next guy. And it's going to be someone that Async has a channel with versus a trampoline. It's just like, hey Async, here's this payment, now make a payment to this guy. And it's not someone who they have a channel with, so it could be anyone across the network. So they have to do then like the actual routing algorithm of figuring out how to get the payment to get there. But it lets you do this. It kind of breaks that link of like having to calculate that entire route yourself.
Kevin Rooke - 00:53:25:
I see, that makes sense. Okay.
Ben Carman - 00:53:28:
So that's like, the major improvement. And I think blind and fast and trampoline routing on their own are powerful tools, but together it makes it really powerful because you can still kind of get that payment reliability back as well as improve the UX around it where it actually works and you get more plausible deniability and stuff like that. These two are kind of close to happening, at least in the Eclair, Bitfinex world. I don't know about the rest of the network, but I think actually LND is working on it. So I think it is hopefully coming soon. And I think as well as a lot of the protocol does understand, this is probably like the most pressure thing they could do for Lightning privacy that's not like a complete overhaul of everything. That's good to see.
Kevin Rooke - 00:54:24:
Now, with this report that you have released on Lightning Privacy, what's is there a roadmap or a plan to extend some of these topics or to continue contributing to this website? What's the plan moving forward for this initiative?
Ben Carman - 00:54:43:
Yeah, since writing this, we've gotten some feedback and learned a lot, so I want to update some stuff, but it's all open source, so if people want to write issues or pull requests, they can definitely update it themselves. But yeah, we'll probably update it as things happen or new research comes out and be like, oh, this is a problem. We'll write an article or something on it. So we wanted to make it like a living kind of research page, but it's only been out for like a month or two, so we haven't updated it much. But, yeah, we'll probably be updating it. And if anyone listening this has ideas or questions, they can make a pull request or an issue, and we'll be happy to answer them.
Kevin Rooke - 00:55:24:
Makes sense. Okay. Now I thought we could get into Mutiny. This is a wallet that I saw a tweet that you posted a little while ago about Mutiny. It says with Mutiny, if you have a browser, you have a Lightning wallet. 2.65 billion people can have a Lightning wallet if they go to our website. Can you give listeners a little bit of a back story on how you decide to build Mutiny, why the browser is so important?
Ben Carman - 00:55:53:
Yeah, basically, me, Tony, and Paul, when we were doing this Lightning privacy research, we kind of are like, we should build our own wallet. And that was like, a year ago. And then Tony and Paul built a proof of concept at a Hackathon here in Austin, and then they went to kind of work on it more, and one of them got banned from the App Store on Apple, and they're like, what the hell? This sucks. So basically they just were like, screw Apple, screw the App Store. What if we did it on the most permissionless way to distribute things, the web? So basically, let's do it. So part of the Bolt.fun Hackathon, we set out to build basically a Lightning node in the browser, and basically the way we do it is using BDK and LDK, really great libraries and really great teams. We got a lot of support from them working on this. But basically when you go to I think if you go to testnet.mutinywallet.com, it's our testnet version, or reckless.mutinywallet.com, it's the main net version. If you go to the websites, there's now a Lightning node running in your browser. So it all runs inside of Google Chrome or Firefox, whatever you're using, and all the state is saved into your browser storage and all that stuff. So there's literally a whole Lightning node running in the browser. There's a lot of problems with that and hard things to do. The hardest was probably networking, where when you make a connection to another Lightning node, it has to be like a raw TCP connection, basic Internet connection, but from a browser, you can't actually make that. You only do WebSocket connections. So we had to build a proxy around this where we basically just have this really dumb proxy that just takes in WebSocket connections and outputs TCP connections to whoever you say you want to open a connection to. And the nice thing is, because Lightning is encrypted and authenticated and all the stuff, we don't have to worry about encrypting any of the data or anything on top of that. It all comes inherently with Lightning. But either way, yeah. So that was kind of our biggest struggle, but we were able to solve that as well. The hardware was like, no one ever done this before. So, like, getting support from BDK and LDK's teams, they're like, wait, what are you doing if you're a madman? And then a lot of our codes kind of just like we took code from LDK and just had to copy paste it and fix it to work in the browser. And we're making PRS now upstream to those two repos, but it works. So, yeah, we can have an entire Lightning on the browser, which is pretty awesome, I think, because we started this with getting banned from the App Store. So if you weren't around in 2014, apple bans, like all bitcoin wallets from the App Store, and people are breaking their iPhones, really mad and stuff like that. Now, if you had an iPhone, you couldn't have a mobile wallet. So with Mutiny, you just go to a website and now you instantly have a mobile wallet. So it kind of makes it extremely hard to stop users from having mobile wallets. And as well as web is like an extremely resilient platform. The government has been trying to shut down Pirate Bay for over a decade now and completely failing. And that's just a website. So same thing. Like, as long as anyone can host this very simple website, now you can serve Lightning Wallets the nice thing, too. It's very easy to self host when you go to reckless.mediawall.com. You have a little bit of inherent. Trust with us that we're not changing the code and you're going to put money in and just immediately swoop it to our address. But it's very easy to self host where it's just running a basic web server. So hopefully we're working on different guides and making it better so users could just host it themselves on maybe their own Versailles account, or if they really want to do it on their own bare metal, host it on Umbrel or something like that. And then you just go to your own same way you talk to your Umbrel but on your phone. And then you can actually have a Lightning Wallet that's completely self hosted in that regard.
Kevin Rooke - 01:00:27:
Yeah. What are the downstream implications of everyone having a Lightning wallet in their browser?
Ben Carman - 01:00:36:
I think some of the integrations we could do would be really cool because the web is like the end all, be all of how basically most people interact with computers nowadays. Where your phone is, if you're using an app, a lot of times it's just talking to the Internet. Or you click a link immediately, it just opens a browser and stuff like that. So if we can get basically any apple just immediately have a Lightning Wallet built into it, where we think of ways where you could have a Pay with Mutiny button the same way we have Pay with PayPal or Apple Pay, and you don't need to check if these are has the app downloaded or anything like that. You just literally just go to renewal.com/Pay/ the invoice and now they're at the Pay page and you just hit Pay and it's instantly there the same experience you kind of have with all these other fiat payment networks. So I think that could be really powerful. And because it's the web, like, we're kind of unstoppable here, so we can implement like a lot of stuff we were talking about with like privacy stuff. But it's also like we talked about governments don't really like it when users do privacy seeking things. So maybe if we lose privacy, Lightning Wallet on the App Store, maybe Coinbase wallet is okay, but our wallet is not okay, and we'll get delisted, but being on the web, they can't delist us. So we can kind of build this. We're using the censorship resistant money we need to make a censorship resistant wallet as well. And kind of the web really enables that where it's shouldn't be hard to shut down. So that's what I'm really excited about. It it's been really interesting building it because when we did it, I thought people were like, what the hell are you doing? You're a madman. This makes no sense. It kind of doesn't make sense. It's not the most secure way to do it, but it's really cool in the censorship resistant aspects. And it's been cool to see a lot of people recognize that when they're like, yeah, this is like an unstoppable wallet. That no one can kind of fuck with now. And it's really cool to see, and there's always been fun, like people point that out and bouncing ideas off of that and stuff.
Kevin Rooke - 01:02:46:
Yeah, you're right. The web does seem to be having a bit of a resurgence lately, and I'm trying to wrap my head around why. I think maybe there are some people who express the concerns about Apple and their dominance in App Stores, things like that. But I look around the tech ecosystem and I see things like Replit, where you're coding in a browser. I see figma where you're designing in a browser. I see this Mutiny now where you're running a Lightning node in your browser, and I see it happening all over the place. And I don't think everyone's doing it for the reason of privacy or the reason of getting back at Apple or getting to be able to be censorship resistant. Do you have any idea of why we're starting to see so many web products come to the fore today?
Ben Carman - 01:03:42:
I think it's a lot better of a developer experience as well. It's something I've talked about on Twitter a lot, but we had some user initially, if you click the settings page, your seat would just be immediately there in plain text. So someone was demoing it at Bit Dev. They hit Settings and leaked their seats. Everyone at the meet up and like, that sucks. So they made an issue and within an hour we had fixed it and deployed it and it was done. Now if someone had click Settings page, that one show up. You have to click reveal. So you get this extremely fast iteration process where any update we do is immediately deployed and it can be fixed for users versus like the traditional App Store kind of cycle. It's like one to two weeks where we work on a new update, all right, it's ready. We need to QA it, and then after it's ready, then we'll submit it to Apple and Google. We probably wait for both of them to approve it. Once they both approve it, then we hit send, and then users hopefully update the app versus like this is just like the second we deploy it now, any user going to the website will instantly have the updated version. So you kind of get this very quick iteration cycle and for one makes like, the user to team like, feedback loop much better, where anything we do is immediately getting feedback on as well. Any improvement we make, the user instantly have. So we're able to kind of outpace all of these things where if we had it in the App Store, we could work on this feature or work on this thing, and then it comes out two weeks later, and then user updates maybe a week later. And then they give us feedback and it's like, okay, to fix that, we're going to have to take that whole like, three week thing again. And it's like, it's just like a very long arduous process, so you're not delivering to the users as quick as possible. And because of that, you could be wasting time on things that users don't want or don't like or are just not the priorities they need right now versus with the web we can instantly deploy to them and allow us to really just iterate so much faster. That's like something I really enjoy. We've gotten, like one of our friends gave us a design review. If we're doing design stuff too, it's not just like, hide the seed kind of thing. It's like, okay, make sure this button is aligned correctly. Do this and do that. With that, we can easily deploy it and then not just like the QA testers or whoever's helping make sure it's right, but literally all your users will see the new updates. You can get instant feedback. Or maybe designers like, oh, this is a great idea. And then you deploy it and all the users like, this is so ugly, what did you do? And then you can revert it. Versus like, with the App Store model, you would do that and then in like a month you revert it. But in that timeline, it's like, well, maybe the users are already now trained to this new design, so let's not revert it. And you kind of get into this weird state. So this faster iteration process really, I think, helps. Mutiny has, like zero users or two users. So it doesn't really help us as much. But I think for these other companies, like Replicate and stuff like that, it really helps them a lot. Because you're running a billion dollar company, you really need to be responding to user needs and demands, and I think that really helps them.
Kevin Rooke - 01:07:08:
Yeah. Now, when I hear the word browser and wallet, when I first heard Mutiny, the first thing that came to mind was, well, what's the closest thing to a browser wallet? Alby. And being a browser extension, can you highlight some of the differences between what Alby is doing as an extension and Mutiny as a browser wallet?
Ben Carman - 01:07:28:
Yeah, So my understanding is Alby is more interface for your lighting node where you'll connect Alby to your LND node running on your server, like on Ampler or something like that. So it's more of like a front end for your actual Lightning node running somewhere else. Versus with Mutiny, it's an entire Lightning node. It's LND. It's everything built inside the browser, Alby it just kind of likes to make payments and receive payments for. This is like apps we're running and watching the blockchain routing, sending, HTLCs, all that kind of stuff. That the complex Lightning stuff that it does. So we kind of have that difference there. But the cool thing is the way we built this, all the core logic is in Rust, which can kind of be ported anywhere. So right now it's in the browser, but we could just take the exact same code and kind of port it into a browser extension. So now we could basically give we're actually one of the Alby guys is one of our first users, and we've been talking to them about how could Alby run this and be like, instead of if you don't have your own Lightning node, okay, Alby will be your Lightning node, kind of thing. And now you have an entire Lightning node running in a browser extension. So I think that could be extremely powerful. But yeah, that's kind of the difference there.
Kevin Rooke - 01:08:50:
Very cool. All right, I know we're running out of time. I want to finish this off with what I do at the end of every show. It's called the Lightning round. Few rapid fire questions for you. You ready?
Ben Carman - 01:09:01:
Let's do it.
Kevin Rooke - 01:09:02:
I hope you're enjoying the show so far. Just a quick message from our sponsor, Stakwork. Stakwork is a Lightning powered platform for generating high quality transcripts of all your audio or video content. They combine AI engines and hundreds of human workers all over the world who are paid over the Lightning Network to assemble these transcripts. And that's what let Stakwork create better, faster, and less expensive transcripts. To see the results for yourself, you can check out my personal website, where I host transcripts for all my podcast episodes. If you want to learn more about Stakwork, visit stakwork.com. That is stakwork.com. All right, first one. If you could change one thing about the Lightning Network, what would it be?
Ben Carman - 01:09:50:
Good question. More users. Let's go with that. Let's be optimistic.
Kevin Rooke - 01:09:57:
More users. Okay. If you could make a guess on how much Bitcoin, a public capacity, will be on the Lightning Network in ten years, what's that number?
Ben Carman - 01:10:11:
Where are we at now?
Kevin Rooke - 01:10:12:
About 5000. Now.
Ben Carman - 01:10:14:
5000, okay. In ten years, I'll say 500,000.
Kevin Rooke - 01:10:21:
Wow, that's a big number. Are there any books that have meaningfully changed your view of the world?
Ben Carman - 01:10:29:
The Three Body Problem series probably has nothing to do with Bitcoin or philosophy or anything. It's a sci-fi series. But that book fundamentally changed how I think about a lot of different I guess some philosophical things, but a lot of are we alone in this world? Kind of things and stuff like that. So I think that's a great book series.
Kevin Rooke - 01:10:52:
Yeah. Who's one person that you'd like to give a shout out to in the Bitcoin or Lightning Space for doing great work?
Ben Carman - 01:11:04:
I'll give a shout out to Keyan at Stacker News. I freaking love Stacker News, and I really respect how he operates it where he's like I remember he gave a pitch at Bitcoin magazine conference in Miami, and he's talking about like, oh, he doesn't take any money right now, any rewards and stuff given the platform is given straight back to the users and stuff. He's really just trying to treat the user as best as he can so he can get the most users and really grow the product. And I really respect how he runs that. So shout out to Keyan.
Kevin Rooke - 01:11:38:
Yeah, Keyan's great. Awesome. Well, thank you so much for the time. I thoroughly enjoyed this conversation. I learned a lot from it. And where can listeners go to learn more about you and your work?
Ben Carman - 01:11:51:
Yeah, thanks for having me. It was a lot of fun. I'm @benthecarman on pretty much everything. If you want to have any questions or talk to me, probably just DM me on Twitter or something and I'll reply.
Kevin Rooke - 01:12:05:
But yeah, sounds good. Thanks again for the time. Hope we can do it through.
Ben Carman - 01:12:08:
Yeah, have a good one.
.png)
.png)