podcast: https://stephanlivera.com/episode/353/

Stephan Livera:

John, welcome back to the show.

John Cantrell:

Hey, how’s it going? Happy to be back.

Stephan Livera:

So John, a lot has happened since the last time you were on the show. You are now working with Sensei and you’ve got this new Lightning node and interface that you’ve got to present and talk about. Do you want to just maybe tell us a little bit about the journey for yourself in terms of how you got to where you are now since the last time we spoke, since you were cracking Alistair Milne’s 12-word seed.

John Cantrell:

Yeah—it has been a while. It all actually tells a good story in a way, that I got here by following that path. And so I think last time we talked, we talked about cracking that seed word, and I was also working at the time on that Juggernaut project—I don’t know if you remember that, but basically that was what you see with Sphinx and Zion and a couple of these other Lightning apps where they’re using keysend payments over the Lightning Network to transmit data. I was playing around with a lot of that technology and seeing what you could build with that. And so I was doing the chat with Juggernaut, and I don’t know if you saw last summer I did a prototype of a project I was calling The World Computer—it was just a joke at Ethereum, but the idea was using that same keysend technology, and instead of sending chat messages, you were sending HTTP requests and responses. So you could model HTTP—or how a lot of the Internet works—over Lightning. That was an experiment where you could monetize any API service, essentially, using this keysend technology. But one thing I kept coming back to with both of those projects was this onboarding problem of like, Okay, so I’m building this app on top of Lightning, which means (a) my user needs to have Bitcoin, they need to have a Bitcoin node running, they need to have a Lightning node running, they need to open some channels, they need to have liquidity, and then (b) they need to hear about my app and need to get my app and they need to connect their node—it’s just like, if you want to get a user on one of these apps, it takes 10,000 steps for this person to get on it. It just felt like maybe we’re too early or like, Yeah, someday—maybe when Lightning is more ubiquitous, these apps would be more feasible. Basically, at the end of the day, it led me down this path of, Well, let me focus my time on this onboarding problem, because it just seems like that’s where we’re at currently—we need to make this onboarding as easy as possible. How are we going to bring the world to Lightning? And so as part of that, I just had to keep going deeper and deeper into Lightning and actually make sure I understand how it’s all working. And that led me to the projects that Spiral—or then Square Crypto—has been funding: the Bitcoin Development Kit and the Lightning Development Kit. For those who don’t know, those are just two software projects that make it easier for developers to build apps that interface with Bitcoin and the Lightning Network. So I went deep on those and ended up applying and getting a grant through the Spiral grant program to work with these two libraries together—they’ve been spending years of time and energy developing these libraries, and no one was really using them together. And so it would be nice—if you were building a Bitcoin wallet or a Bitcoin application with the Bitcoin Development Kit—that it would work really well in tandem with the Lightning Development Kit, because these projects were developed mostly in isolation. So some of my work has been to explore building using both of those, and the culmination of that is what is now being called Sensei, which is a Lightning node implementation that is built on top of both of those projects—the Bitcoin Development Kit and the Lightning Development Kit.

Stephan Livera:

Excellent. And just for people who aren’t familiar, what is BDK and what is LDK? If you could just give a beginner’s explanation of what those are?

John Cantrell:

Yeah, sure. So let’s start with the BDK. So BDK is the Bitcoin Development Kit. It’s written in Rust, though they have bindings for other languages. But the core idea is, if you are a developer and you want to build a Bitcoin wallet or any other application that interfaces with the Bitcoin network—so that means that either it talks with the peer-to-peer network, or it needs to create and sign Bitcoin transactions, or manage UTXOs, or all the other handful of things that an application might need to do that wants to interface with Bitcoin—there is just a lot that you would need to build as a developer. You need to be able to connect to the Bitcoin network, you need to be able to fetch blocks, you need to be able to create and sign transactions, which in and of itself can be very complicated. Like, how do you select UTXOs and UTXO management? So there’s just an endless list of things that you need to implement, and instead of having every single developer needing to re-implement this from scratch, the Bitcoin Development Kit provides some nice abstractions around those concepts to make it a lot easier to work with. And one of the most important things that it provides is peace of mind—like, when you’re working with people’s money, it’s scary—you don’t want to have a bug that causes someone to lose money. So when you’re working with these projects, it’s not 100% guaranteed, but you feel a lot better that there’s a handful of experts and people looking at this project to make sure that it’s safe. Again, we don’t want to trust, not verify, but at some level you have to trust a little bit. And o it helps you just be more confident and not have to deal with all the minutia and low-level details of wiring together and signing Bitcoin transactions. It’s a toolkit for developers to do just that—to work with Bitcoin.

Stephan Livera:

Yeah. So it can be understood as like a way that let’s say you want to create a Bitcoin app without necessarily doing all the low-level details, as you were saying, of how the transaction should be crafted and constructed—you can leave some of the heavy-lifting to BDK and you’re working at a higher level or higher layer in the stack, as it were.

John Cantrell:

Yeah. It’s a lot like any library you use—the idea is you can abstract away a lot of the details and not have to worry about the low-level implementation details. You can just focus on your application and the business or application-level details that are important to you. So it just lets you work way faster with more confidence.

Stephan Livera:

Yeah. And now if you could just give a quick overview for LDK as well?

John Cantrell:

Yeah. So it’s sort of the same concept except the Lightning Network is even more complicated, I would say, than just plain Bitcoin network, because it’s a whole separate peer-to-peer network, a whole other protocol that needs to be communicated and followed. And so basically, again, it provides the building blocks and high-level abstractions around the core components of the Lightning Network. So if you want to build an application or a wallet that can operate over the Lightning Network, whether that’s send and receive payments, open and close channels, send and receive messages over keysend—whatever it might be—the Lightning Development Kit just makes it easier for developers to add that kind of functionality to their applications.

Stephan Livera:

Excellent. And so now where does Sensei come into the picture? What is Sensei? And what do you see people using it for?

John Cantrell:

Sensei is a Lightning node implementation. It’s built on top of Lightning Development Kit, so I didn’t re-implement all of the protocol-level details, because that’s what the Lightning Development Kit is for. But basically I added a bunch of APIs, so there’s the HTTP API, the HEC APIs, as well as encryption and backup of the keys and all the kind of things you would expect from an LND or C-lightning. So I sort of look at it like it’s an LND/C-lightning/ACINQ alternative, but with the LDK and BDK back end. So it’s just yet another option for the market, with its own little twist. At the highest level, you can think of it and use it like you would LND—it’s not as mature, so I wouldn’t say, Go do that today, but the idea is that it is yet another option to run as a Lightning node. Now with that said, one of the main differentiating features that it showcases—at least in V1—is this idea of the lightweight child node. I actually had this idea a long time ago, and I was going to try to build it in LND, but with LND and C-lightning—it illustrates one of the main benefits of working with LDK, is that you can pick and choose the exact components that you want to work with when you’re constructing your node or your wallet or your application. The idea is that, with a Lightning node, there are a bunch of components. To work on the Lightning Network, you need to have—one is the network graph. So when a node joins the network, they’re broadcasting information about their node and all their channels, and all the nodes on the network that want to be able to route payments need to keep track of this graph. They need to keep track of what other nodes exist, what other channels exist—so if I want to send a payment to you over the Lightning Network and I don’t have a channel with you, my node needs to be able to compute a path to you before I can send you a payment. So that’s like a whole subsystem of the Lightning Network that every one of these lightweight nodes technically doesn’t have—you could trust someone to help you route a payment while still being non-custodial. So that’s one component, is the network graph. The other thing is the chain data. So when you’re running a Lightning node, you need to monitor the base Bitcoin layer chain to make sure that someone’s not trying to close the channel on you or publish an old state, and just make sure that people aren’t doing funny things—and you do that by monitoring the chain. And that’s typically a very heavy piece of a Lightning node, because you need to also be running a full Bitcoin Core node, or equivalent. So those are two good examples of pieces of the Lightning Network stack that could be shared. And that’s one of the main things that Sensei does, is it says, You’re going to run a full Sensei node, which is going to run and manage a network graph, it’s going to connect to Bitcoin Core and monitor the chain for you—but why not be able to spin up 1,000, 10,000 lightweight nodes that appear to the rest of the peer-to-peer network like regular nodes? They maintain their own channels, they maintain their own on-chain wallet, their own new UTXOs, their own keys. As far as anyone is concerned, they are full nodes. The only difference is that they share the network graph and the chain data of the parent node. And so that’s the first of many differentiating features that you’ll see with Sensei, is this focus on this onboarding problem. Here’s a model—the Uncle Jim model or the Galoy Money model—where you might not be able to run your own Lightning node and manage its uptime and its liquidity. You almost need to be like a sysadmin to be able to run and maintain a Lightning node, and so it’s not really going to be for everyone. Maybe 10 years from now it’ll be on your router or something and you won’t even know your running one. But today it requires a little bit of expertise to be able to run a Lightning node. But you probably know someone—one of your friends, one of your family members, someone in your community—that does know how to do this. And you trust those people a little bit, right? You trust your friends, you trust your family, you maybe trust some people in your community—that’s why they have those labels, almost—it’s like the definition. And so the idea is you would have someone running a Sensei node, and then they could maybe spin up a hundred or a thousand or however many nodes they want, and let their friends, family, and local community use it. That’s one potential use case. It’s not necessarily the only one, but it’s an interesting one. And if you’re familiar with LNDhub or LNBits, these are other solutions to this problem, except those are more like all the child accounts are just database entries. So there’s one Lightning node, and then they just have records for how many sats everyone has. But they don’t exist on the Lightning Network, they don’t have their own channels—there’s really just one node. So this is an alternative to it where they actually have a full Lightning node. And the name Sensei translates to something like, The one who comes before. And the idea is I see this as a way to onboard new people and then maybe teach them, make it easy for them to become “true Bitcoiners” or something, and someday they could migrate their node and become their own full node—that flow doesn’t exist today, but the idea is that there would be a way to eject from the Sensei node and take it with you and you’re now running your own node.

Stephan Livera:

Let me just summarize a little bit there. So for listeners who were following along, as we’ve spoken about before, there’s a concept of let’s call it an Uncle Jim node, as popularized by our friend, Matt Odell. The idea being: you might run the infrastructure for your family and friends, so you might be running a Bitcoin node and they connect their wallet to your Bitcoin node. And so in a similar sense, what you’re explaining is it’s like Sensei is sort of like that, but for Lightning nodes, in a loose sense. And previously, as you were saying, somebody could have run, let’s say for example, LNDhub and BlueWallet. Now I know BlueWallet is changing infrastructure as well, but previously that was something you could do—you could run LNDhub, which was like a wrapper over LND, which is from Lighting Labs. The idea being, you could have lots of clients—or nephews, in the Uncle Jim model—they have an account with your LNDhub server, if you will. And they’re like a client or a user. And so in this way, as I understand you, Sensei is setting up a way to have a shared infrastructure that other clients or child nodes or nephews and nieces in the Uncle Jim model, they can be your nephew or niece. They can piggyback off your infrastructure, because you’re the one watching the Bitcoin blockchain to make sure there’s been no channel closures or other things going on, and you’re also helping them in terms of the routing map or the network graph. So maybe another example would be if somebody is using, let’s say, Phoenix wallet, and you’re offloading some of your route-finding to the ACINQ node, in that example. But in this example now, the idea is Sensei is going to be something that a lot of people could run. Like, the more technical person could run that, and then they will find a way, or maybe there are other ways, that the child or the nephews and nieces in this model can connect in and use their wallet and have their own node piggybacking off the Sensei. So could you explain a little bit about how that might work? Like, how might the child node interact? Would it be like an app? Or how would that look?

John Cantrell:

You nailed it. Those are exactly the models I had in mind. And another potential use case is like another wallet developer who wants to model something like ACINQ and Phoenix. They could use Sensei as their back end—that’s another goal of the project, but like you said, I think for now, as in the very early beta release of Sensei, the child nodes can log in through a web admin, basically. So when you’re running your Sensei node, it exposes a web admin over HTTP that can be visited by any browser. When you create these child nodes, the passphrase the child uses to encrypt their seed data is also used as their login to this node. So in one form of it, they could just navigate to your IP address, essentially, on the Sensei port, and then log in to this admin and manage it that way. But yeah, in reality, in the future, there would be a companion app that wouldn’t be called Sensei, but maybe Padawan or something. I don’t know, something about a student, and it would help them really get onboarded to Bitcoin. But in the meantime, in the short-term, since I don’t have a lot of help, I want to make it compatible with things like Zeus and Ride the Lightning and other remote control apps. There’s no reason why a lightweight child node can’t be remotely controlled by apps like Zeus today. So that would be the short-term. And longer-term, I would hope there’s a more customized app that’s focused on easing and onboarding new people like pre-coiners to Bitcoin.

Stephan Livera:

So in your mind, as we were saying it, this is like the Uncle Jim model, so I presume then the target users of Sensei will be the Uncle Jims out there, the people who want to try to run the infrastructure for their friends and family. Is that mainly your target audience?

John Cantrell:

Not quite, I mean yeah, from what everything I’ve said so far, that is definitely it—it’s like the hobbyists, the PlebNets, all the people out there participating in that style today with LND. I think they should give it a try and see if there’s something there for them, or other use cases I’m not even thinking of to take advantage of these lightweight nodes—I have a couple interesting ideas in mind. But at the same time, one of the benefits of building on top of BDK and LDK is that I automatically get all of the cool features that they’re working on for free. And a lot of those features—as you might imagine, since it’s been recently announced that Cash App is using LDK to power their Lightning integration—there are a lot of enterprise-focused features that the LDK team has been working on, and I’m excited to be one of the early users of those features as well, and make those available to Sensei users. I think there’s actually going to be, coming down the line, a lot of really interesting functionality that businesses who want to offer Lightning can get from Sensei without having to roll their own. I look at it as a way to get a lot of the great features in enterprise functionality that LDK will have without having to completely roll your own—so maybe it’s like a transitional period. The ultimate solution is just to integrate LDK directly and you can do it yourself. And if your use case demands it, then that’s the way you should go. But maybe this is a way to get started with some of those features without having to build the whole stack first.

Stephan Livera:

What platforms is Sensei available for?

John Cantrell:

Well today, I’m nervous to let people use it. Right now you have to be able to download and build and run from the source. I haven’t published binaries or anything like that—that hopefully will be coming in the coming weeks as I get a little more testing and make sure that I’m comfortable saying, Hey, go ahead and actually try this on main net. But it’ll be available for all platforms. It should be runable on Linux, Mac, Windows, and potentially mobile—I haven’t tried it yet. But yeah, the big three, for sure.

Stephan Livera:

How technical do you have to be to use Sensei today? And let’s say in the near future, how technical would you have to be?

John Cantrell:

I guess I would say: if you can run LND you can run Sensei. It’s very much similar to that level of expertise. You need to be able to download the binary, run the binary, use the CLI tool to unlock it or set your passphrase or whatever it might be. It is skewed towards a developer as a user, because it does expose a bunch of APIs that they can use to control it through software or automate it or do whatever they might need it to do. But it also has nice web admin. So it is a little bit more user-friendly out of the gate than something like maybe C-lightning, where it’s all command line. So I don’t know, I’m towing the line on how user friendly it is, and I think the browser-based admin does help the less technical user get started. I’ve been aiming for this idea of making it similar to WordPress—I don’t know if you’ve ever tried to install WordPress on a server, but sort of like that. You can get it installed on a server and they have a nice onboarding flow and it’s relatively easy to use through the web admin. So I’m sort of targeting that, but at the same time, it is also flexible and open to someone who is capable of taking full advantage of the APIs.

Stephan Livera:

And as I understand, you are intending to have this built out, or at least try to get support for it into some of the popular node-in-a-box—Umbrel, Raspiblitz, et cetera—that’s also your intent?

John Cantrell:

Definitely, yeah. I think they’re a great way to distribute something like this, because those users already have Bitcoin Core running, which is going to be a dependency to get this running. And so they all have these app stores now that make it really easy to add. And so yeah, that’s for sure coming pretty shortly, as soon as I give the thumbs up on the binaries for people to start using it, it’ll roll out on those stores. And I think they’re also the target users—someone who’s running an Umbrel node or Raspiblitz or something is definitely the type of person that I want to try out Sensei.

Stephan Livera:

And just having a look through the documentation I saw references to Nigiri. So what’s Nigiri?

John Cantrell:

Yeah, that was actually new to me as of like 2 weeks ago, and I added it because I found it amazingly useful. I almost tried to build a similar tool a year ago. But basically, Nigiri is a tool that you can run on your machine that makes it really easy to run development servers for Bitcoin and Electrum and a couple other things—I think they support Liquid. So basically, when you want to develop on top of any of this software, it’s kind of a pain because you need to get them all running locally and then be able to start and stop them on demand and have them all talk to each other all on your local computer. So this just makes it really simple—you just install this one tool and then you can just be like, nigiristart, or whatever the command is. Sorry I’m not super familiar with it, actually. And it will start up Bitcoin, it’ll start up Electrum, it’ll even start up Liquid, and they will all be connected and talking to each other, and it makes it really easy to mine blocks on your network and send money to a test address to fund a wallet and stuff like that. So it just makes local development on Bitcoin super easy.

Stephan Livera:

So it’s like an easy way to package together some key pieces—Bitcoind, Electrum, Explorer, and then the user is able to quickly spin this up and then they want to connect it to all the other pieces. So I think the other interesting aim is this idea of trying to get everyone onto the Lightning Network. So it’s interesting, because there’s this whole range of possibilities of ways that people are getting onto the Lightning Network. And look, let’s be honest: in many cases, a lot of them are coming in custodial, but there are others who are coming in and let’s say like a hybrid model, and then others who are doing the more sovereign, set-up-my-own-everything node with my own channels and everything. So how do you see Sensei playing into this and being part of that mix of let’s say custody, sovereignty options?

John Cantrell:

Yeah. Like you said, there’s a lot of options. And I think maybe unfortunately or maybe not—I don’t know—for the vast majority of people today, it’s going to be through like a Cash App in a custodial manner. And I think that’s okay in the short term, and I think what’s really important about Bitcoin in general is just that it’s an option—it always needs to be an option for people to opt out or to exit these custodial situations ideally before they need to, when they’re ready to. And so for me, it’s just that—it’s making sure that the option is there when they’re ready, and making that transition as smooth as possible. And like you saw—I think we messaged a little bit about my thread of onboarding the entire world—obviously, with today’s tech and readiness of Lighting Network, we can’t really onboard the entire world immediately. It’s going to take a long time, and that’s why I said maybe it’s fortunate that a lot of people will start with custodial solutions, because if, tomorrow, 7 billion people wanted to use the Lightning Network non-custodially, I think we’d have a little bit of a problem. So I think in the short-term we need these custodial solutions as a crutch, and let it be more of a slow drip onto noncustodial Bitcoin. And in the long run, maybe it won’t even be for everyone—maybe people for some reason are okay trusting Cash App or their government or whatever it might be, and they just want to be able to interact with the rest of the world once we’ve all transitioned to Lightning. So how I think about Sensei is exactly that same mindset of like, as of today the child nodes are custodial with the admin node, and so it’s not ideal and I don’t particularly like it, but it’s an easy way to start. And the idea is exactly how I outlined, is that I want to make the steps from the pre-coiner all the way to being an Uncle Jim yourself to be as easy possible. And so I think people are going to go on their own journey and at their own speed, and I hope that Sensei and the suite of products around it can help them take that journey. So at a high level, that’s how I would answer that.

Stephan Livera:

And so, just as an example, let’s say using the Sensei, Uncle Jim mental model here, let’s say some users are coming in and they want to be a child node on your Sensei. How is it going to work in terms of swapping in and swapping out? Like, as an example, there are other wallets and LSPs, Lightning service providers, who help with these kinds of things, where maybe they’ll offer, let’s say some kind of turbo channel capacity. Or in this case where let’s say you have a Lightning balance, but you need to spend out into a Bitcoin balance—they offer things like a submarine swap or some kind of partnership where they help you do that. So that way the user just gets a nice experience where they can just pay one QR code and they don’t really think about it, but actually in the background, there’s all this technical wizardry going on. So how are you thinking about that from a Sensei point of view, being able to swap in and out of Lightning?

John Cantrell:

Yeah. I think you hit on a bunch of things there. And one angle of Sensei, and I think in general, is the Sensei node will have to operate more of what people have been calling—well this term is now being debated a bit—but an LSP, or a Lighting service provider. The idea being that there’s a lot of things you do to ease the onboarding of new Lightning users. And as you mentioned, these swaps are one great tool to use to onboard a user so they could deposit Bitcoin. So you can show them a regular Bitcoin address—on-chain Bitcoin address—that when they send their Bitcoin to it, it actually at the same time is doing an atomic swap, and the service is opening a Lightning channel for the same amount to them. They’re funding their Lightning channel by funding their wallet, essentially. This is a great step, and I think you see Muun Wallet kind of does this, though it’s a little unclear, to me at least, exactly what they’re doing, but it’s something along these lines. And the idea is that when I deposit my funds, I’m actually funding my Lightning channel and they’re opening it to me. And you can do other tricks like use zero-conf channels in this case—I think that’s what you described as a turbo channel. It’s becoming more formalized now, like actually into the spec, what a zero-conf channel is. And so that would also mean that they don’t have to wait the 3 or 6 confirmations to start using the channel. This would be like, I deposit the money into my 2-of-2 multisig with my Uncle Jim, and he immediately opens a zero-conf channel to me with the same amount of liquidity pointing towards me. I can then transact over Lightning essentially instantaneously, because there’s a little bit of trust there with the Uncle Jim.

Stephan Livera:

So essentially Sensei software, Sensei node runners can kind of become like an LSP for their child nodes, and maybe even that’s a monetization model there for them to think about in the future that they can say, Okay, you can be a child node of mine, and I’ll be your swap provider—and I’ll obviously take a fee for that. Or they might do something around the channel fees, let’s say the routing fees, and maybe that’s their model for monetizing this, or just at least to recoup their costs of channel fees when they’re opening things and closing things.

John Cantrell:

Yeah, for sure. I think I alluded to—a lot of the features coming down the pipe are around this LSP idea, because I also said originally, I want to focus on the onboarding flows, and a lot of this is around opening channels, providing liquidity, rebalancing channels, and making sure that all of that is as hidden, essentially, from the user as possible. At the end of the day, I’d prefer a “Lightning” wallet, or a Bitcoin wallet that never mentioned Lightning or never mentioned channels. I don’t think the average user is ever going to want to care about that stuff—and shouldn’t have to. They just want to be like, I’m in this Bitcoin economy and I want to be able to send and receive money for goods and services that I want, and I don’t really care about submarine swaps or splicing my channels or rebalancing my channels. There’s no way that that that should be present in the UI. So I think a longer-run goal of Sensei, and I think just the whole community, should strive for that, is to have wallets where all that stuff is removed. You’re always going to have the power users who want to have that control, and there’ll be plenty of services and wallets for those users. But I think there needs to be a strong focus on wallets that don’t even ever mention Lightning. I think it’s probably a mistake.

Stephan Livera:

One area that some users might be thinking is privacy. What kind of privacy implications would there be for, let’s say, the child node user on a Sensei? Is it basically that they—again, my mental model here is I’m thinking of, let’s say the Phoenix user on ACINQ—ACINQ knows where all the payments are going, obviously. Is it a similar kind of model then in the Sensei project?

John Cantrell:

Yeah. As of today, and I think in the long-run, there’ll always be some privacy trade-offs, because even if it became non-custodial, the whole point of the lightweight nodes is that they’re sharing some information with the parent node. And so there is that privacy trade-off for sure. But I’ve been thinking that maybe there’s some interesting privacy use cases for Sensei, actually, where the person running Sensei spins up tons of child nodes that are actually theirs, and they’re all connected through TOR. And so from the outside world, it looks like you have 1,000 entities, but it’s all really you. And so maybe there are cool tools and privacy-enhancing ways to use Lightning that way. Right now it’s hard to spin up tons of nodes. It’s the whole Bitcoin layer 1 like, Don’t reuse addresses—well, maybe someday like, Don’t reuse public keys, your node pubkey on Lightning or something. I don’t know, maybe you always iterate to a new node. But it’s more complicated than that, obviously, because you need channels. And so it might be expensive to set something up like that.

Stephan Livera:

Yeah. And it could also be that let’s say in the same way that like a lot of users who are all using the same VPN, in some sense they’re creating an anonymity set for one another, that if there’s lots of users all using that same VPN—or maybe in a similar analogy is like people who are like CoinJoined anonymity sets. So maybe there’s actually some level of hiding in a crowd. Let’s say you’ve got one Sensei node and there’s hundreds of child nodes off of that, piggybacking off that Sensei, then that’s actually in some way masking some of that behavior, perhaps.

John Cantrell:

Yeah. It’s possible. I haven’t really thought too much about the nodes, but yeah, I think something like that—

Stephan Livera:

Because they would still have each of their own unique channels, so I guess when they’re receiving it’s a different thing, but when they’re paying maybe there’s something there. And also another question I’ve got just around routing: so typically the way things work, if you are, let’s say as an example, in some of these Lightning wallets that are operating a little bit of a hybrid model or some kind of a phone wallet Lightning, they generally will not route payments. As in, they will not be a routing node. As in, other people will not be routing payments through them—they can pay or receive, but they’re not routing, they’re not being the route through which other payments go through. So is that still going to be true in the Sensei and child node case, or is actually like your child node can still be routing payments?

John Cantrell:

Your child node can route payments, yeah. For sure. Yeah that’s one of the differences. It doesn’t have to though, like you could have a model where the Sensei just has all its channels open, or like all the child nodes opened a channel only to the Sensei, like a parent node. And in that case, you would end up looking a lot like these mobile clients you talked about, where all the mobile users are just these leaf nodes. But there’s nothing stopping a lightweight node today from opening their own set of channels, and then they could use those for routing, for sure.

Stephan Livera:

Gotcha. With the broader Lightning Network, onboarding a lot of people, I’d love to chat a little bit about that thread you did—and listeners, I will put that in the show notes, so that’ll be stephanlivera.com/353 for this one, have a look—but you were chatting a little bit about what exactly it would take, hypothetically, if we were to onboard everyone on Earth, almost 8 billion of us now. And if you could just tell us a little bit and explain a little bit what that would look like? And some of the high-level numbers, I’ve got them here, if you don’t have them off the top of your head.

John Cantrell:

Yeah. I can pull it up. Obviously it was a bit of a hypothetical—there’s a lot of assumptions in there that aren’t very realistic, but it was a thought experiment just to try to understand how much time and space it really would take to onboard the entire Earth onto Lightning, like on a Lightning channel, to get a sense for the magnitude of those numbers. And then think, Well, what can we do to reduce that? And like we mentioned earlier, if we really did need to onboard 7 billion people tomorrow, what would that look like? And what would happen? And realistically in the future, what’s coming to to help us with that problem? If you look at the base case of just a simple channel open—for those who don’t know, a channel open is basically just: you fund a 2-of-2 multisig address, and so it’s a single Bitcoin transaction. It can be as little as one input and one output. So the input is funding the channel and the output is this 2-of-2 multisig that represents the funds in the channel while the channel is open. And so that takes up a certain amount of space. It’s 121 vBytes. Again, there’s some assumptions there already, like that you’re using a native SegWit input, and that’s the only input and the only output—usually you have a change output. So there’s already some grace taken to say like, What is the minimum size today? Anyways, if you filled a block—which has a limited block size—with these transactions, I think it would be about 8,200 people can open a channel in a single block of Lightning, which means, with the 7.7 billion people, it would take roughly 18 years for everyone on Earth to open a lightning channel. And again, the massive assumptions there are that you can consume 100% of the block space without problems. It’s not a really reasonable assumption, because Bitcoin is a global phenomena that is being used by all sorts of people for all sorts of use cases, and you can’t just go like, Okay, we’re going to take the next 18 years and only open channels with all the block space. But again, it’s an extremely rough estimate. And 18 years—honestly, if that was the goal for hyperbitcoinization, if you told me in 18 years everyone would be on Lightning, I’d be like, That seems good enough today. But luckily we can do a lot better. And so the simplest way to improve this is with something that we could do today, and it’s actually—well, it’s not really easy to do, I hope Sensei makes it really easy to do—but is batch channel opens. And so basically you’ve heard of transaction batching, like we used to have this this problem where exchanges wouldn’t batch withdrawals. Basically every time you asked to withdraw from an exchange, they would send a single transaction to you, and so was cluttering the block space and causing fee spikes and whatever. But eventually I think nowadays most businesses and exchanges use batch transactions, which is basically, they send from one input and then they add 1,000 outputs, so they can do 1,000 withdrawals in a single Bitcoin transaction. So this saves a ton of space. And so you can do the same thing with the Lightning channel opening transaction. Again, an exchange could do this, right? They could say, You want to withdraw to a lightning channel. And so they could batch 1,000 users or 10,000 users or whatever the number is, and basically they have one input which is from their cold storage or hot wallet, whatever, of the exchange, and each output is one of these 2-of-2 multisigs, and it represents a Lightning channel between 2 users. And so this basically means each output is only 32 vBytes. So instead of 121 vBytes per channel, it’s now down to 32 vBytes. So this lets us do something like 31,000 channels per block. And that’s what this batch channel opening is, where one transaction is opening thousands of channels. So if you filled 100% of the block space with these types of transactions, it gets down to just under 5 years—a 4X improvement, basically, if we use batch channel opens. And this doesn’t require any new soft forks, any new tech—just same old Bitcoin transactions, but using this batching idea. And 5 years really is a lot better. Again, we can’t use 100% of the block space for this, but conceivably, if it’s really going to be the next 20 years, 50 years to really onboard the Earth, maybe we can eek out 5 years worth of block space or block time, however you want to call it, to open these Lighting channels. So that’s promising to me—that seems doable. Again, not all 7 billion people are going to want to do non-custodial Lightning, right? There’s going to be some large percentage of people that probably stick to custodial solutions, and they’re not going to be part of this. And like I said, they’ll probably be spread out over much longer than 5 years. So I think even with just batch channel opening, we could probably onboard a significant portion of the Earth to Lightning today. And then I go on—I don’t know if you want me to continue with another improvement—

Stephan Livera:

Yeah, no, I’d love to talk about the multi-party channel part of it as well.

John Cantrell:

Yeah, so this one’s cool. So basically, now that we have Schnorr signatures and can do MuSig—which is a way to aggregate signatures, essentially, in a Bitcoin transaction or in a UTXO—you can have multiple people. So normally it’s a 2-of-2 multisig where there’s 2 people in the channel—it’s between me and you—we open a channel and it’s just the 2 of us, and we fund a 2-of-2 multisig. In a multi-party channel, it’s the same thing as a multisig that you’re used to where it’s, instead of 2-of-2, you could have 10-of-10, 100-of-100—there’s really no limit. It’s probably a practical limit, but there’s no theoretical limit to how many people you could put in a multi-party channel. And these multi-party channels—because of the signature aggregation—they still just take up that single 32 vByte output. And so this really scales how many people you can onboard in a single transaction in a single block, because theoretically you could fit the whole world in one transaction, but they’d all be in a single channel. The trade-off here—there’s a couple things I’m not talking about here that a lot of people were mad at me or said this isn’t really the case, is that (a) it’s really complicated. There’s actually nothing stopping multiparty channels from existing in today’s Bitcoin. Like without any soft forks, we could actually get this. It becomes a bit of an engineering challenge, because it’s already quite complicated to negotiate all the communication and logistics of a 2-person channel, and so as you continue to add people to these channels, there’s just a lot of shared state that needs to be moved around in the right order and everything signed correctly—and it’s just a lot logistically to actually implement, especially with the way that Lightning works today where you have this penalty mechanism. So basically the security of Lightning comes down to fact that—well, it’s not the only thing—but one major aspect of it is that if someone tries to broadcast an old state, you can penalize them by broadcasting a penalty transaction that steals all their money. And so there’s this disincentive to cheat on Lightning because you’re going to lose all your money. And this actually introduces a lot of complexity into the Bitcoin scripts that are used, and the state that you have to maintain. And this grows exponentially as you try to add more people to a channel. So it’s theoretically possible, but it’s definitely very complicated to pull off. But luckily in the future, there’s an improvement proposed called Eltoo, spelled differently than the L2.

Stephan Livera:

Eltoo, yep.

John Cantrell:

Yeah, sorry—those two are confusing. But yeah, so basically there’s an improvement to Lightning that hopefully will come that removes this penalty mechanism and makes it a lot simpler to implement Lightning, and will make doing these multi-party channels a lot simpler. And so we’ll probably see people start to experiment with them. And right there, basically, if you had 10 people per channel—so 10-of-10 multisigs in each transaction—now you take that 5 years and you take it down to half a year to onboard the whole world. So these can really potentially scale the onboarding of people to Lightning, though it’s a little bit of a different use case, because a multi-party channel is slightly different—instead of just opening with 1 person, you need to be able to communicate, and I think there’s a social aspect that needs to be figured out to support 100 people in a channel. You need someone to coordinate this. So I don’t know, maybe we need software like Wasabi or something that’s coordinating these CoinJoins, we’ll coordinate these channel openings between thousands of people. So there’ll be some creative software and solutions we’ll probably see once Eltoo comes, but at the end of the day, it does make it extremely easy to onboard these people. One piece of information I left off is you basically just push the problem down the road to channel closing. So at the end of the day, everyone needs their own UTXO, like if you’re not controlling your UTXO then what do you really own? And so in this multi-party channel case, you’re sharing this one, UTXO with 10 people or 100 people or 1,000 people. And that’s fine while it’s locked in the multisig and you’re using it for Lightning, but what happens when you want to get out of this? You want to close the channel and you want to go back to Bitcoin? Well, now each of those 10, 100, or 1,000 people are going to need their own UTXO again. So you push the problem of onboarding to offboarding. Like, how do you close Lightning channels? You run into the same scalability problem there. Maybe the answer is you just don’t close these very often, and people just always operate within one of these big Lighting pools or something. I’m not sure what the future will look like, but it is definitely an interesting thing to explore.

Stephan Livera:

Yeah that’s a really interesting idea. And so maybe it ends up being some kind of thing where you have to close out of one multi-party channel and enter into some other multi-party channel. So that way maybe there’s some kind of management way to—

John Cantrell:

Oh yeah, that’s cool. Like, you’re moving into another group of 1,000 people—you’re just always using a thousandth of a UTXO or something. I don’t know.

Stephan Livera:

Yeah, I don’t know. If we were really gonna get that crazy and that far out—because even the UTXO set is one of the things that’s hard to scale as well. So a lot of this stuff we’ve been talking about is just the channel opening part of it, and channel close part, I guess. But then we also have to think about, Well, what if they’re rebalancing channels? What if they’re swapping in and out and all of these things? But we have to have confidence in the talent of the engineers and the entrepreneurs who are building solutions around this. And of course, like we were saying at the start, a lot of people will be coming in custodial. They’re not going to start non-custodial. So important part is really that they could self-custody if they needed to—that’s probably the ultimate point. So just to round up the discussion, do you want to just tell us a little bit about—so we’ve spoken about Sensei—can you tell us about Eltoo technology? Could you tell us a little bit about that? Is that a project? Or what’s that?

John Cantrell:

Yeah, it sounds like a bad name. Odell also already called me out on it. I think we have too many Eltoos/L2s now—so yeah, maybe I’ll rename it—but the idea is I just wanted to create a wrapper or a parent organization around Sensei and the suite of products and services that I have in mind. So it’s like a lab-style company and basically just focused on layer 2 tech—accelerating the adoption of Bitcoin. And Sensei is the first of hopefully many things to come, and it’s just a way to give it some structure. So there will be some services around maybe LSP-style services that will come down the line. But I’m also interested in exploring other layer 2 techs. So Lightning is just the most prominent one today, but there’s things like statechains and Chaumian federated mints that are being worked on behind the scenes. There’s also this Nostr project that has gained a little bit of steam recently. And so I have my eyes on all these things, and I’m trying to figure out what makes sense and how to tie them into Lightning and Bitcoin in general and how they might help with general Bitcoin adoption. And so it’s just an umbrella to contain all of these projects that I hope to work on.

Stephan Livera:

Excellent. And so for listeners who want to get involved or contribute in some way or get in touch with you, what’s the best way for them to get into it?

John Cantrell:

I do have DMS open on Twitter. So @JohnCantrell97. I also hang out mostly in the BDK and LDK Slack and Discord channels, so come on over there if you’re interested in those projects—always happy to help if I can. Yeah, those would be the two main ways.

Stephan Livera:

Excellent. Well, thanks again for joining me. I enjoyed the chat.

John Cantrell:

Yeah, thanks for having me. Hope we get to talk again soon.