{ "episodeId": "SLP483", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "stephan_livera": { "name": "Stephan Livera", "role": "guest", "tag": "STEPHAN" }, "guest_2": { "name": "Guest 2", "role": "guest", "tag": "GUEST" }, "guest_3": { "name": "Guest 3", "role": "guest", "tag": "GUEST" } }, "segments": [ { "speaker": "stephan", "time": "00:09", "start": 8.51, "text": "Hi, you're listening to Stephan Livera podcast, a show about Bitcoin and Austrian economics, brought to you by swan dot com. As you've seen with the debt ceiling shenanigans, it looks like they are just going to be printing a lot more over the years. If you need to future-proof your business or your balance sheet, check out swan dot com slash business. Swan business can help you add Add Bitcoin to your corporate balance sheet and it's never been easier. The process is really fast, you can onboard your business, nonprofit or trust in one to two days and add Bitcoin to your balance sheet. You can get guidance along the way in terms of Bitcoin investment, custody and management strategy. Also, if you have staff and you wanna pay out a fringe benefit to them, let's say fifty dollars a month or a hundred dollars a month to your staff in Bitcoin, there is the Bitcoin Benefit Plan which makes it easy for you. You can use that as part of your recruiting and retention strategy to retain your Top talent. So if you're interested in that, go to swan dot com slash business to sign up. My favorite Bitcoin hardware in the space comes from CoinKite dot com. They have a range of products, most notably the Coldcard Mark IV, which is a very reliable device that you can use to make sure that you are holding your own keys. So don't leave your keys with a custodian, use the Coldcard, and you can use it easily with desktop software such as Sparrow Wallet or Specter Desktop or Electrum, or you can even use it with NFC with phone Apps such as Nunchuk. The cool thing with hardware like the Coldcard is that you don't have to phone home. It doesn't have to phone home to a company server. You can set it up completely on your own. You can airgap it by just plugging it into the wall and spinning up and initializing your wallet that way. And the Coldcard has a range of features. You can use it with SeedX or there's a Duress pin, a BrickMe pin, and you can use a passphrase, you can use multi-signature, there's all kinds of options. So go to Mempo.space is where I go to check the fee before I send Bitcoin on-chain transactions. It is a comprehensive Bitcoin explorer covering the Bitcoin ecosystem, whether that's the mempo, the blockchain, and second layer networks. And recently, there was the announcement about the transaction accelerator, which is a new service that Mempo are going to be rolling out. So keep your eyes peeled for more information on this. And in the meantime, use mempo.space. You can even host it yourself, so you don't have to trust somebody else. If you're with an enterprise, mempo.space has custom- Mempool instances, and you can have your company's branding, as well as extra support and feature requests with the team. So go to mempool dot space slash enterprise. For today's episode, we're talking about lightning in a high fee environment. What things change? How did the network and how did people perform in this recent round of a fee spike? And joining me are Nifty Nye, or also known as Lisa, from Base fifty-eight, who was recently working at Blockstream, D plus plus, who is a Bitcoin and lightning educator. And Nate, who's also at Voltage, head of support and education. Should they join me to talk about this lightning in a high fee environment situation? Hey guys, welcome to the show. And yeah, I just thought it would be an interesting one, obviously with what's happening, with the lightning fees and obviously being in a, in a higher fee environment in the, in the block space market, let's say. And so I know you guys all have a lot of experience working with lightning, you're often teaching other people how to use lightning. So, yeah, I guess We'll just kind of maybe, maybe we'll just quickly go through just to make sure everyone sort of knows who you are. Just take a quick, you know, thirty seconds and kind of introduce yourselves in terms of what's your main focus nowadays, Lisa, do you wanna start?" }, { "speaker": "stephan_livera", "time": "03:41", "start": 221.25, "text": "Sure, yeah, hey everyone, my name's Lisa, also go by Nifty Nai on the internet. I spent five years working at Blockstream on the Lightning spec, particularly around channel opens. currently taking a small break from being a protocol developer to build a Bitcoin technical education An initiative called Base58 and check us out on the web at base five eight dot school." }, { "speaker": "stephan", "time": "04:06", "start": 246.12, "text": "Fantastic, and Nate from, Voltage." }, { "speaker": "guest_2", "time": "04:08", "start": 248.25, "text": "Yeah, hi everyone, my name's Nate. I'm a Lightning Network hobbyist turned Bitcoin, I don't know, career guy that, does support and education at Voltage, and, yeah, that's pretty much me. Great, and D plus plus." }, { "speaker": "guest_3", "time": "04:24", "start": 263.96, "text": "Hi, D plus plus. I think people know me from Plebnet. I'm also a Bitcoin educator, and I- Also teach people how to code." }, { "speaker": "stephan", "time": "04:32", "start": 272.18, "text": "Fantastic. Well, I think, let's, let me just sort of set a few of the, you know, the rough high-level details, and then we can get into a bit of the actual discussion about lightning in a high fee environment. So, I think this is mostly driven by the recent round of ordinals and inscriptions, right? And so, you know, as, so f-for listeners in the future, we're recording this the 29th of May to 2023, and, you know, Big craze in the mempool, and, in mempolls, let's say, and if you were trying to get into the next block a-at the high priority, let's say, on mempool dot space, you might have been paying something like fifty dollars in terms of, in the fiat terms, and in sat terms, you might have been paying something like five hundred sats per vbyte, something in that range. Now, as we speak today, high priority is about a dollar seventy-eight in fiat terms and forty-six sats per vbyte in Bitcoin terms, but, About how you think Lightning nodes handled this recent round of high fees. Did they do it well or were people getting it wrong? What, what do you guys think? Maybe we'll start with you, Nate. Sure." }, { "speaker": "guest_2", "time": "05:40", "start": 340.27, "text": "Yeah. So, yeah, what I saw was, you know, a lot of channels. I don't-- So we're gonna get into this. I'm just gonna dive right into it. So it's like, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah Force closures, for those that don't know, is when a channel closes unilaterally, meaning only one of the two peers decides to broadcast the commit transaction, and this can happen, sort of automatically as a security mechanism for many reasons. and when the commit transaction doesn't have enough Sats in reserve to broadcast the fee for the, the closure, then this channel closure could be pending For a long time, especially if fee rates go up before, y-you know, just spontaneously, like it, it felt fairly spontaneous. And there are a few things that have come out that are helping to mitigate this. We could talk about anchor reserves and stuff like that, but a lot of folks were kind of caught like, \"Oh no, my, I just a forced close just happened for whatever reason, and now my transaction's at six sats per vbyte and a hundred and fifty sats per vbyte is like next block.\" so there's been some issues there, but that's-- I'll just leave it to either Lisa or you to jump in after that." }, { "speaker": "stephan", "time": "07:01", "start": 421.41, "text": "D, D plus plus, let's hear from you." }, { "speaker": "guest_3", "time": "07:03", "start": 423.01, "text": "Yeah, well, for one, I would say it's an un- unfortunate time for forced closures to be happening in such a high fee environment for one, but it's also important to kind of note the context, and that is a world in which folks are inscribing arbitrary data on the Bitcoin blockchain, and I think it's just really important to note that this- This isn't an attack on Bitcoin. Bitcoin isn't under attack. Bitcoin is working just fine. There are some folks who are competing for that block space, and Bitcoin has a free market fee environment such that you can bid for the block space that you want, and we're seeing people put monkey JPEGs on the blockchain. now that said, I, I do think that people minting, if you will, thousands of profile photos Photos and attempting to sell those to folks for real money, I do think that is a grift, to be fair. But it's not an attack on Bitcoin. Bitcoin's working just fine. I do think that those folks are going to get priced out by the economic activity. But all we've heard for the last year or so before inscriptions was the fee market, the fee market, the fee market. how is Bitcoin going to develop a healthy fee market? And does it need a hard fork? And does it need tail emissions? Does it need demo? And then we saw a healthy fee market, you know, become established out of a free market competition for block space, and those same people are saying that Bitcoin is under attack, which of course it isn't Now that said, I do think that this is a good little test net for us to start thinking about, well, what are we gonna do when we see Bitcoin develop a, a really, really strong fee market to the point to where it's not just fifty dollars to get into the next block, it's five hundred dollars or five thousand dollars type thing. And so that said, I'm really happy that we're having this discussion today. It, it just couldn't be more timely, and I'm excited actually to learn from y'all because- There's so many things about Bitcoin and Lightning that I don't understand. I feel like in prepping for today, I, I just have more questions than I have answers, if I'm honest. So, Nifty, Nate, and Stephane, I hope you don't mind if I pick y'all's brains today. I'm just considering myself to be a student of all of the new things that are happening on Bitcoin, which by the way, is a lot." }, { "speaker": "stephan", "time": "09:30", "start": 570.09, "text": "Well, I think you're right. There's a lot of things we're all learning, and, I'm curious to hear what Lisa has to say about this recent, fee market or block space market, let's say." }, { "speaker": "stephan_livera", "time": "09:40", "start": 579.54, "text": "Yeah. So I think like, I think this is really kind of highlighting one of the, not challenges, but sort of like, the interface between Lightning and, like, which is layer two and layer one, right? Kinda happens in that block space market, so to speak. So like Lightning's ability to function sort of relies on its relationship to being able to get transactions into blocks on the layer one. and there's definitely, I think, some challenges with the way that the current protocol is written, both in the Bitcoin layer one, as well as in Lightning, like the layer two protocol, these are like two separate projects, both have different protocols, but there's some interactions like between the two of them that we kind of see get play out And high fee environments, I think, really exacerbate or highlight some of the problems or issues or edge cases that there's current and ongoing projects to try and fix, right? So Nate was talking about, and Nate, maybe I misheard you, but you mentioned like someone had like a forced close go through or like a, a, a close forced. So forced closes are ideally never happen, one. So let's, I think we should like maybe say that like the fact that a forced close is happening is usually a sign that something is like kind of wrong in like the protocol So to speak, or if something is happening on the node that maybe shouldn't, and so maybe there's something we as like protocol developers on the Lightning side need to fix, or as Lightning implementers, maybe there's something with our implementation that we need to take a look at and fix so that whatever these, whatever's causing these force closes, we can like mitigate for the next time. one of the kind of frustrations that I've had with the force closes stuff is that it's been really difficult, I think, to get good information About what the root cause of these closures are. So Core Lightning has this really amazing thing that'll keep track of when your channel changes state, like so when you're-- There's like different phases that a new channel on Lightning goes through, like the process of opening it, when it's open, when it's operational, when it's closing, and we annotate why that, why each state change happens. So if there's a forced close, your Core Lightning node in its log should tell you who closed it, was it you? You or your peer, why it closed? Like, was it a protocol problem? Was there an error and it should be logging like what the error is? Problem is, like, I think we don't keep those logs around longer than like a hundred blocks or however many blocks after the channel closes. So unless someone is like scraping them or holding them or like recording them somewhere and like saving it, you do, like, get the information, but it doesn't stick around forever, I guess is what I'm saying. So I think there's definitely, definitely, I think a better job we could- We could do in terms of keeping and tracking this information so that we as like protocol and implementation developers can figure out what the root cause of it is, right? Because unless we know why all these forced closes are happening, it's very hard to know what needs to fix or what needs to change. Okay, so that's kind of like a high level thing. One of the things I think that like this like particularly high fee environment starts to highlight though is like the relationship between lightning payments and on chain, like the on chain Payment stuff or like, like Nate was talking about how, I think Nate, you mentioned like someone had a force close and they like, they're, the force close transactions get built at a point in time, and when the, like, force close contractions get built, and this has to do with the way that Lightning works, when those force close transactions get built, they have a built-in fee rate on them currently, right? And so you were saying there was one that went out that was at six sat per byte, right? which meant like the current one was like a hundred something Transaction isn't getting in a block anytime soon, right? And sometimes these close-close transactions, like if you have HTLCs on them, you only have so many blocks before it's possible for s-- like for someone else to take the money basically. So like when you have a forced-close transaction go through, especially one that has in-flight payments sort of like on it, the timeliness with which you're able to get that transaction into a block becomes like a really important problem or question, right? Okay. So there's a few things here. Like, one, why was it six sats per vbyte? Why wasn't it a hundred, whatever, sats per vbyte? You know, that's something about how the protocol works. The other thing is like, okay, so this kind of has to do with like when you have Lightning, I'm talking a lot, I can stop talking at any point." }, { "speaker": "stephan", "time": "14:07", "start": 846.64, "text": "No, no, go on, go on." }, { "speaker": "stephan_livera", "time": "14:08", "start": 847.6, "text": "Yeah, but when you have like a transaction that's got-- So the way that Lightning works is that you have these pre-signed transactions that you hold on to, right? and The way the Lightning protocol works is that every time the fees change in the network, you and your channel peer are keeping track of that, and you contact each other, you like call them up on the phone, you're like, \"Yo, the fee rates are different. We need to update our transaction that we have signed so that it reflects the higher fee rate, right? \" 'Cause if we don't do that and we have to like accidentally go to chain, we're gonna end up not getting in a block, and that's like a problem, right? Like there's a timeliness thing here. So your nodes will do this automatically. They automatically call each other up that they have a channel with and like, \"Yo, we need to like renegotiate, put the fees up, like, let's go. \" And then they'll like, both sides will issue new signatures for a new transaction at a higher fee rate, right? So there's a couple of things that can go wrong here. One is that when they get the phone call from the other peer, you might disagree with what they say the new fee rate is, right? So if I call you" }, { "speaker": "stephan_livera", "time": "15:20", "start": 920.29, "text": "And they're like, no man, it's like fifty, 'cause sometimes we get like nodes have different views of the mempool, they have, they're different implementations, they're running different algorithms that tell them what they think the current fee rate market is, right? So if there's any disagreement, that will lead to a forced close. So if they don't agree on what the current fee rate market is, then one of them will just send out the latest thing that they have. I don't remember exactly, it's been a long time since I've looked at this particular part of the code base Agreement about what the fee rate mempool is, and when the mempool's changing a lot, the odds of that happening with the current, the current lightning protocol, I can chime in a little bit about some of the changes that are coming through the pipeline and already on the way to kind of help with this. So the challenges with that, but current, for current lightning, if, if your, if your peer calls you up and's like, \"Yo, I think it's this,\" and you disagree, that'll cause a forced close, and if you haven't updated it since the six" }, { "speaker": "stephan_livera", "time": "16:20", "start": 980.21, "text": "To chain, and that's like how you end up with, that's one way you can end up with those sorts of transactions out on the mempool. Another thing that might happen here is maybe you haven't talked to your, maybe you haven't talked to your channel peer in a long time. maybe you guys haven't had a payment go through your channel, and like maybe they are running tour, and your connection, your ability to talk to them isn't good. When the fee rates start going up, all of a sudden all these nodes, everyone's placing phone calls, right? So it went" }, { "speaker": "stephan_livera", "time": "16:50", "start": 1010.27, "text": "Anyone, 'cause like you're all kind of in your fee rate range for all your transactions that you consider good. As soon as the fees start going up, because there's a lot more transactions in the mempool, all of a sudden every channel, every single person you've got a channel with, every single channel, they're, they're, they're having to call each other, right? All of a sudden there's all these phone calls happening across the lightning network. Everyone's calling everyone being like, \"Yo, we gotta hike the rates on this channel we've got, right?\" That happens for If all of your peers are connected to you over Tor, Tor's known to be kind of bad at like doing connections, right? Connections drop all the time. So if you call your peer up and try and renegotiate a new fee rate, right? It's the same as like all of a sudden, like the network getting flooded and every single channel getting a new payment that has to go through it. If for any reason your node is offline or like can't respond or the connection fails and they don't get back to you, that'll cause a force close, 'cause you called them up and tried to So the thing that your node does when your peer stops responding is you force close the channel, right? Because you need to update the fee rates, they're not calling you back. So there's a couple things that happen here, right? Like they can either disagree with you or they can fail to respond. And if either of those happen, the channel gets force closed. Then you might" }, { "speaker": "stephan", "time": "18:06", "start": 1086.06, "text": "get force closed, yeah. Yeah. And then I'm curious as well. So let's say in this example, the force close goes out at six sats per byte, is there some kind of weird game theory about who" }, { "speaker": "stephan", "time": "18:20", "start": 1100.23, "text": "He wants, you know?" }, { "speaker": "stephan_livera", "time": "18:21", "start": 1101.31, "text": "You can't rbf it, because rbf requires, so the way that lightning works is that in order to bump that transaction, you, for an rbf for example, you must get a signature from both peers. The reason you force close in the first place is you can't talk to your peer. You were trying to do effectively an off-chain rbf. This calling them up is effectively you guys re-signing for a higher fee" }, { "speaker": "stephan", "time": "18:47", "start": 1126.99, "text": "rate or" }, { "speaker": "stephan_livera", "time": "18:48", "start": 1127.67, "text": "off-chain rbf, right? Like, yeah, that's probably A good way of talking about it. I hadn't thought about it that way, but yeah, fee rates go up, you have to negotiate off-chain rBFs, basically. That's exactly this whole like phone call conversation, is like, \"Yo, let's make an off-chain" }, { "speaker": "stephan", "time": "19:00", "start": 1139.82, "text": "rBF, let's" }, { "speaker": "stephan_livera", "time": "19:01", "start": 1140.62, "text": "go.\" Like, yeah. But you can't get in touch with them, you have to go with what you've got because you just like it's, you, it's, what else you gonna do? So one of the things, so this gets into protocol changes, one of the" }, { "speaker": "stephan_livera", "time": "19:20", "start": 1160.27, "text": "Changing how you set the fees on these in reserve, what we call commitment transactions, like the transaction that you're holding onto that you do the off-chain RBF for, the thing that you signed on the force close. So the general idea is like everyone knows that this is a problem. The problem being like having to call them up or like having one that's out of date that you negotiated with a peer two weeks ago, they've gone offline, you haven't been able to touch with them, fee rate goes up, you've got transactions on it, like you've got inflate payments on it. On that transaction, you, you get in trouble and you can't talk to them. You need a way to be able to change, dynamically change the fees on this like in reserve transaction without having to talk to your peer, right? So then we start getting into like protocol stuff. This is like, how do we change the protocol so you don't have to do this? Also, the whole idea with like changing the protocol is, what if we don't have to call each other on the phone every time the stuff changes? Like, what if all those phone call conversations didn't have to happen anymore? What RBF, a lightning transaction, like the in reserve transactions. What if we just like had one thing and we didn't have to, we didn't have to change the fee rates because we could pick the fee rate at the time we needed to get that transaction mined, right?" }, { "speaker": "stephan", "time": "20:34", "start": 1234.48, "text": "Gotcha. Is this getting into the anchor outputs stuff?" }, { "speaker": "stephan_livera", "time": "20:37", "start": 1237.08, "text": "Exactly." }, { "speaker": "stephan", "time": "20:38", "start": 1237.78, "text": "Gotcha." }, { "speaker": "stephan_livera", "time": "20:38", "start": 1238.34, "text": "That's where, yeah, that's where this ends up." }, { "speaker": "guest_3", "time": "20:40", "start": 1239.97, "text": "I've got a question for Lisa. yeah, you mentioned the forced closes happening and it sounds like a lot of them were due to this fee negotiation thing not happening. Happening. I wonder to what extent how many of those nodes were, say, running Neutrino, meaning they didn't have a mempool to look at to, predict what the fee would be, and they're using some kind of API instead, which may be brittle, and to what extent we could-- I hate to say this, but to what extent we could put some of those fee estimations on, say, Nostr to help maybe further the Neutrino nodes who don't have a mempool." }, { "speaker": "stephan_livera", "time": "21:17", "start": 1276.73, "text": "Well, the mempool is a-- So, okay. So- So this is a good question. If you think about it, mempool information is gossip information about transactions, right? So sending everyone new transactions is something that, like, they're not doing because they don't want to have to have the burden of getting all that new information every time a new transaction goes out, right? So it's really trying to reduce the bandwidth. The problem is, like, Noster, my understanding is the bandwidth requirements are also quite high. So how are you, like, one, how are you packaging up that information? Distributed on Noster, is that actually going to allow you to cut down the amount of data that you're sending to these nodes or is it going to be like a similar amount of data? If you're, you're having an indexer or a condenser who's like, you know, the, the transport of how you get the data, changing it over to Noster doesn't change the amount of data or the provenance of the data or verification of who's sending you the data. Do you trust someone if you're getting like roll-ups of what the mempool currently fee rate is? Do you trust Changing over to Nostr is really just changing over the, the way that the information arrives. It doesn't help you with the problems that are like kind of inherent and why they're not getting that data in the first place, which is like, where is it coming from? What's, what's actually contained in the data? How do we make like a rol- how do you make up a summary of it so that you can send less data? But then, who's making the summary? Do you trust them? Like, so like, no, I don't, I don't think moving the data to What data and who's sending it and like what kind of data you're sending." }, { "speaker": "stephan", "time": "22:54", "start": 1374.16, "text": "I see. So then, I guess taking, running with that anchor outputs idea as you were getting into, Lisa, I guess then that would allow each channel partner-- well, does that allow each channel partner to unilaterally bump fees?" }, { "speaker": "stephan_livera", "time": "23:07", "start": 1386.63, "text": "Yeah, so that's the idea. So the idea with the anchor output, so there's, there's kind of two parts here. One we're like working on, okay, so eventually, we haven't done it yet. Wait, hang on, let me back up. Let's talk about anchor outputs. What is an anchor output? Anchor output is the idea that you can child pay for parent one of these, these, these, commitment transactions, and only the party who sends it or only one of the parties that send it has the ability to child pay for parent it. And there's a Now when we build these little inner reserve transactions, you have a special output on it. We add two special outputs that only each of the channel peers can put another transaction that spends it. So this guarantees that you will guarantees-- there was a bunch of other stuff that I'd have to make this, but I try and get as much as possible to guarantee that you're able to add another transaction with a higher fee rate that can anchor that down into the chain, right? Which is why they're called anchor outputs. So we're providing little hooks on this, like, transaction so that later, you can figure out what the new fee rate should be, make a new transaction that adds those additional fees onto this transaction and pulls it down into the chain or pushes it to the top of the mempool, however you wanna think about it. So yes, that's the idea behind anchor outputs. The long term plan is that eventually, in a perfect world, this is where we start getting into like, okay, we now we need protocol changes on the base layer to do this, like, package relay becomes the new thing. but when we're able to do this, we can remove the phone call thing with the update fees, so we no longer have to talk about what the current fees are. So you almost entirely remove this entire class of errors, so to speak, entire class of forced close vectors, because we're no longer when the fee rates go up, remember that everyone has to get on the phone and call their buddy and be like, \"Yo, we gotta change the fees.\" When you have anchor outputs for everyone, you no longer need to talk about what the fees currently are, so there's no longer an opportunity For your peer to not be available and cause a force close, and there's no longer an opportunity for you to disagree, 'cause you're not even having that conversation anymore. You're completely removing that conversation from the picture, so the force closes for that thing. You like basically cut out an entirely class of errors, so to speak, from like, whatever. Like, there's no longer an opportunity for you to have a reason to force close, 'cause you won't even be doing those actions anymore. And the reason you don't have to do those actions anymore is you can basically have a minimal Fee on this transaction and then have the anchors with the idea that the fee is small enough to be able to get that transaction into the mempool, and then that gives you the opportunity to add another transaction that can pull it to wherever it needs to be in the mempool, is the idea. It's getting kinda complicated though, and this is when you start needing something like package relays. What is the minimum amount of fees you need to get that transaction into a mempool? Because when the mempool gets full, that number changes. So now we've got this like kinda difficult, hard to answer question with anchor outputs using, without package relay, about like how do, how do we price, how do we, what do, what's the minimal fee rate? What's a reasonable minimal fee, fee rate that we don't have to call each other on the phone" }, { "speaker": "stephan", "time": "26:18", "start": 1578.2, "text": "anymore? Gotcha." }, { "speaker": "stephan_livera", "time": "26:21", "start": 1581.44, "text": "But this is, so now you're getting into an interesting side effect of using anchors, which is you need to have funds on chain available at any point in time in order to provide those fees. So right now, the current design of Lightning, every channel inside of it has a little bucket of Sats that's reserved to pay fees, and that goes up and down depending on what the current on-chain fee environment is, and those are siloed into every- So you've locked into the channel, right? And so as those fees go up, the amount of liquidity you have in that channel in order to route payments goes down, right? So this might also-- I haven't really thought through this thing here, this might contribute to on-chain divorce closures, maybe? Or at least like reduces, but it like, so on-chain fees rising have an impact on the lightning network capacity prior to anchors, because every, every channel has to have, every single channel is like a bucket of Funds of a fixed size, right? And every time when the fee rates go up, when you make that phone call, part of the results of those phone calls that go out is that everyone makes the amount of money available to be routed goes down, right? You call up and you're like, \"Yeah, I guess you're" }, { "speaker": "stephan", "time": "27:37", "start": 1657.23, "text": "saying it's like, it's less capital efficient, right? Because every channel has to have this reserve.\"" }, { "speaker": "stephan_livera", "time": "27:42", "start": 1661.55, "text": "Yeah. Every channel. Well, so but that means that when you go to chain, you have those funds already available to make sure that that transaction can get into the When you go to anchor outputs and remove that little bucket in each channel, all of a sudden you still need those fees, but you have them, you can kind of save them. Now all of a sudden your node has to guard and reserve Enough Bitcoin to ideally deal with any forced closes that happen at any particular time. And if you have too many channels and too many of them try to close at the same time, it's possible that you may not have enough sats on chain to save all your stuff. So the current protocol kind of, sort of saves your butt a little bit by having each of these channels take care of itself and self-regulate with how much it's saving for that particular, like, I want me to think about this So like one way that I like thinking about capital on Lightning is through the perspective or through the lens of like kind of like risk management, like you know, like when you make an investment, you sort of have to figure out what your risk profile is, like what's the risk that you're going to need to spend that money, so to speak. so like, there's like a built-in like risk calculation sort of done of how much of that channel is actually like reserved for fees versus now you have to figure out how much you globally are saving for every channel. So every additional channel you open, it used to be that it would, each one would kind of manage its own fee budget accordingly. now- Now your node has to make a decision about how to manage a like separate reserve tank, right?" }, { "speaker": "stephan", "time": "29:23", "start": 1763.46, "text": "Gotcha. To do this kind of operation in the case of the fees rising. Are" }, { "speaker": "stephan_livera", "time": "29:28", "start": 1767.5, "text": "you adding funds to this off-chain thing? Are you, are you, are you like, you know, this is like your, this is like, are you, are you filling that tank up? If you're not filling that tank up and you have to go to chain and high fee environment, like you're gonna be in trouble. Like you're not gonna be able to get your stuff in chain like you need to. So like, you know, the trade-offs here are like, well, the capital efficiency of what's in the channel is greater, but suddenly you've got this new responsibility of managing an, like, a reserve," }, { "speaker": "stephan", "time": "29:58", "start": 1797.92, "text": "an on-chain balance in your lightning node, right? I guess that's essentially the short version of what we're getting at here. Right." }, { "speaker": "stephan_livera", "time": "30:05", "start": 1804.56, "text": "So it's- To some extent, like if you think about it from a capital efficiency standpoint, you don't actually gain much capital efficiency by moving it to a different thing. Those are still funds that aren't being able-- That's still Bitcoin that you own that's not able to route payments, right? Yeah, that's true. And whether that Bitcoin that you own to route payments is like scattered across all these channels or in one like bucket, it's still capital that you're not able to deploy and be available for the opportunity of routing a payment, right? Yeah." }, { "speaker": "stephan", "time": "30:33", "start": 1832.94, "text": "Yeah. But I guess, I guess you could probably So that it means, in today's environment, if you're kind of concerned that there might be a big fee spike, you might say, \"Look, it's worthwhile. I'm okay with paying that, let's call it capital, increased capital cost. I'm okay with that. I'll just have bigger channels, less channels but bigger ones with a, with a reserve so that, with anchor outputs so that I can bump if I need to. Otherwise, I don't wanna risk getting screwed on the, in the high fee environment," }, { "speaker": "stephan_livera", "time": "30:58", "start": 1858.22, "text": "right?\" This is, I think this is where Because the cool thing about dual funding and the cool thing about splicing is it really allows you to decrease the number of channels that you're operating and get like, you can open a channel with liquidity on both sides with dual funding. So instead of two people having to open a channel, you cutting down the number of channels that you have is good for the network in a lot of ways. And this is one, this like capital requirement thing is good. I think Anchor outputs giving you as a channel operator, it gives you a finer grain- Opportunity to determine what your risk profile is in terms of capital that you're reserving for on-chain like responsibilities or obligations, potential obligations, right? I think that's a good thing, I think that's cool, 'cause like as an operator, it lets you determine sort of what your like risk is, like it gives you one more knob to mess with, maybe that's good, maybe that's bad, but I think it does let you kind of make more interesting decisions about like where you're putting your capital and what your risk is and-" }, { "speaker": "stephan", "time": "32:05", "start": 1924.78, "text": "Yeah. Yeah. And speaking of where you put your capital, this reminds me of something I heard D++ say. D++, I heard you at the, BTC++, in Austin recently, and you gave-- as part of your intro, you were saying, it's a famous saying, I think Tad Dajer popularized this idea that Bitcoin is for enemies, but you're saying, hey, while Bitcoin is the money of enemies, Lightning is for friends. Can you elaborate a bit on that? Because I think maybe there's something there that in a high fee environment, it's more" }, { "speaker": "stephan", "time": "32:35", "start": 1954.94, "text": "Trust them with your life, but maybe you trust them a little bit so that they're not gonna put you into a bad situation in a high fee environment." }, { "speaker": "guest_3", "time": "32:42", "start": 1962.15, "text": "Yeah, well, Nate can attest to the fact that when we started Plebnet, everyone on the main chain was just kind of fighting on Twitter, and we were having the best of time with each other with the magic of friendship, and we would sort of immortalize that friendship by opening lightning channels to each other. So really, it was just kind of meant to be, You know, a bit silly, a bit fun. That said, it is helpful to know who your channel partners are, because if you need to contact them for whatever reason, you can kinda go out of band on, say, Telegram. Plebnet is a fantastic place to do this, by the way. Plebnet.io, and you can be like, \"Hey, what's up? Is your node offline?\" And they might be like, \"Oh, whoa, I need to get a new UPS.\" Or, \"Oh, yeah, let me restart LND.\" Or, \"Ooh Using, it's probably time to upgrade. So it is, it is helpful to have those out of band channels, if you open to bigger nodes, like lightning service providers, it becomes, I think maybe a little bit less necessary because, they have infrastructure that's probably a bit more robust than like just kind of the pleb nodes running for their laptop under their beds type thing. But yeah, I mean, perfect opportunity for me to shell plebnet because what plebnet really is, is a peer to peer learning environment for folks who are interested interested in Lightning or running a node, who inev- who inevitably come up against some kind of roadblock that maybe prevents them from being able to do what they wanna do, and because this is such a new technology, it's not always easy to Google questions and find answers, especially when you're looking at like Core Lightning, for example, a lot of us wanna use Core Lightning, and we might have questions that- like I said, there's not like a Stack Overflow article or there is, and it's out of date. And so you can just talk to someone who's been there, who's had that exact same problem, who can help you, and, and folks are very generous with their time. Plubnet dot io." }, { "speaker": "stephan", "time": "34:41", "start": 2080.8, "text": "Yeah, great, I'll put the link in the show notes. Nate, let's go to you. I know, there was a post that I recently caught on the Voltage website. So, I presume maybe you might have had a hand Today and it, it had some interesting practical tips. Maybe you wanna just elaborate a little on those." }, { "speaker": "guest_2", "time": "35:04", "start": 2103.98, "text": "Yeah, so there's, you can, alright, so for those that are just running a Lightning node, that are sort of a hobbyist or whatever, and just, you know, you can't, at least right now, like, be a hundred percent sure that you can avoid a lot of these issues, but you can do various, mitigation strategies, I mean, I could go through a whole bunch, but like, like Dee was saying, choose your peers wisely. If it isn't a big node that you can have access to, you can go to somewhere like Amboss dot space and see if they have contact info put there, which is really, really handy. I think a lot of folks are doing that now. And then there's, yeah, so I'm actually on that blog right now. Yeah, I helped write this one. It was a while ago though, but, yeah. So, there's There's various settings you can do so a channel can only handle, I think it's four hundred and eighty-three sort of pending, in-HTLCs, yeah? Yeah, HTLCs, but yeah, I was gonna call them in-flight HTLCs. Yeah, so what you can do is because a lot of folks are streaming Sats and stuff, and that can sometimes knock a channel out of whack, is you can limit that, and you can also set minimum or maximum HTLCs depending on how much money, how your channel balance is. And what this is gonna do Hey, I don't wanna route payments bigger than X, like, so don't try to, because I don't have the liquidity for it. things like that help make the network more efficient and help keep your channels stable, especially if you're on tour. this, can be found in the LND configuration file if you're using LND for core lightning. I'm not 100%, I assume there's something in there for that too. but yeah, so, yeah, I'm just, I'm skipping through that right now. I mean, take advantage We said, yeah, I mean, it's really important too, I mean, not really, really important, but if you're spending a UTXO to open a channel, you should try to make sure there's some change, there's a change output associated with that so you can bump it. that's how the bumping works, is you need a change output to reallocate towards that, wrap that transaction up and make a new one. and a good rule of thumb for that is if you're opening up a channel, we'll just say, just at one That's in at eighty sats per vbyte, you would probably want to rebroadcast that at like a hundred and sixty sats per vbyte because the block weight is now double, so there's an effective fee rate for that. those are just, some, some ways that are practical on that, but I'm a big proponent of, quality over quantity when choosing your peers. There's so many peers on the network now that you can, you don't have to just throw a dart at a dartboard and hope that they're, that they're good." }, { "speaker": "guest_2", "time": "37:50", "start": 2270.46, "text": "so Bet your peers, and I think in a high fee rate environment, if, you know, if, if we're at a point where we're, where the block subsidy is, you know, under half a bitcoin and the fees are go like three or four bitcoin per block or something, which would be pretty cool, you're gonna have to choose your peers very wisely and have bigger channels. So to boil it all down, the best day to start a lightning node was yesterday, the second best is now, like, you, I really think that, I, I, yeah, alright. So I was basically just gonna say like, I feel like the future of Lightning I wanna see because a lot of folks are saying, \"Oh, it's gonna be, it's gonna be custodial, it's gonna be crazy.\" Yeah, like, alright, so, folks are saying, you know, \"Oh, it's gonna be like wallet of Satoshi on steroids is the future basically.\" And what I wanna see is I wanna see more folks right now today start Lightning nodes slowly, learn slowly, have low time preference on it, and then slowly And even though it is \"quote unquote\" custodial, at least if you rug pull someone, they know where to find you to, to punch you in the throat or whatever. So like that's where the future-- so that's kind of what I'm pushing, folks, like I really want folks to just start a lightning node sooner rather than later to prepare for five hundred sats per byte being the norm or, or higher." }, { "speaker": "guest_3", "time": "39:11", "start": 2350.75, "text": "So Nate, that's a really interesting point, that you can be the uncle Jim for, you know, your kids and your cousins, your sister and And brothers, would you do like an L and D hub thing, L and Bits, say, situation for that?" }, { "speaker": "guest_2", "time": "39:25", "start": 2365.12, "text": "Yeah. So right now there's a few ways to go around it. r-right now for core lightning, Lisa can correct me if I'm wrong, but L and Bits and L and D hub is the best way to go for now, I believe. which is basically just your node is the backend wallet for, or the backend infrastructure for various wallets that you can use something like Zeus with, so you can essentially, if your node has fifty million sat of capacity, you can create a wallet on it that says zero on it, and folks can use your liquidity to send and receive. On LND right now, Lightning Node Connect is probably the best way to do that, and Lightning Node Connect uses a simplified way of giving permissions using a random- English words to, offer folks custodial wallets on your own lightning infrastructure. So, which is really, really cool, 'cause now you can just say, \"Hey, you wanna lightning wallet? Download Zeus, scan this QR code that has eight words on it, and now you have a custodial, however you know who I am, but, you know, wallet.\" So, I really like the whole \"uncle Jiming,\" your friends and family. So" }, { "speaker": "stephan", "time": "40:31", "start": 2430.69, "text": "yeah, and look, I'm, I'm all for that. I think perhaps the challenge would Hang on, guys, that's not really that scalable, is it? How many people are actually going to, you know, manually go set this up and get people on? Now, maybe, maybe the argument would be, hey, it just needs to be easier software. Maybe it just needs to be a little bit easier, and, you know, maybe over time it gets easier. I know maybe similar arguments would be made about stuff like FedMe as an example, because FedMe can have multiple federations, there is that argument there as well. So we'll see kind of what happens there. We're racing against the clock" }, { "speaker": "guest_2", "time": "41:07", "start": 2466.94, "text": "of, of scaling. You know, the, the, the, the havings are gonna keep coming, there's no way to stop it. So we're in a race against the havings to get this layer two infrastructure going, and, you know, if lightning isn't the one, then I hope the one comes soon because we're, we're gonna need it in the future." }, { "speaker": "stephan", "time": "41:24", "start": 2483.63, "text": "Well, yeah, I mean, there's, there's, talk now about ARC as an example. I did an episode with Barak just recently, I haven't released that yet So, because it could be just a total fad, this whole inscription thing and now it's kind of back down, and then we've, we've got time for people to build things out, and maybe this was a great test run, for people to see how things are going to work in the high fee environment. Because in a high fee environment, a lot of things might change, right? In, in a low fee environment, I'll make a quick point here, that in a low fee environment, you can very cheaply move things around between different wallets, right? You might" }, { "speaker": "stephan", "time": "42:06", "start": 2525.96, "text": "And when I need to, I'll put some into a Lightning wallet, or when I need to, you know, but in a high fee environment, it really forces all of us to actually start being efficient, because now it's like each time if it's fifty dollars a transaction or twenty dollars a transaction, now we're thinking about it a little bit more instead of, oh, it's just fifty cents or whatever, right?" }, { "speaker": "guest_2", "time": "42:25", "start": 2544.83, "text": "I, in a lightning context, that's really important from a strategy standpoint because when you decide that you wanna do something in lightning, you-- figuring out how many on-chain transactions that's gonna take is actually, really, really important. so that's why- Watching, seeing Dusty's talk at the open source stage in Miami this year like blew my mind in a lot of ways and actually inspired me to start a core lightning node so I could learn more about plugins and stuff. w- because it's, instead of having to close, open a new channel or, or, or, do multiple things at the same time, you can use one transaction to move liquidity from three of your channels into another channel and, and that sort of thing, which, as you were saying, is, is an efficiency thing, which we need" }, { "speaker": "guest_3", "time": "43:13", "start": 2593.39, "text": "So I've got a question for the group with regard to moving liquidity around. What is the thought on the topic of channel factories? Because my understanding with channel factories is you wouldn't even have to do any on-chain transactions to move liquidity around since everything is sort of a virtual channel." }, { "speaker": "stephan", "time": "43:31", "start": 2611.37, "text": "Probably beyond my level to answer that one, so I'm not sure maybe Lisa or Nate if you know." }, { "speaker": "guest_2", "time": "43:37", "start": 2617.33, "text": "I mean, I'm, I'm a little bit versed in zero confirmation channels, which is something that Voltage is going to be, deploying as part of our Flow 2.0 liquidity service pro-provision service, which we're really excited about, which I can go more into, but, but I'm not really, know much about the virtual channels concept. Maybe Lisa does." }, { "speaker": "stephan_livera", "time": "44:02", "start": 2641.73, "text": "Not something I'm an expert on. I feel like the channel factory stuff is definitely in the realm of like, still like, kind of doing some research in terms of how to make that work for people. I think one of the things that a lot of the proposals I've seen more on like multi-party channel, which is like, how do you make one channel more efficient in terms of having multiple people on it? I think some of the challenges there tend to get into what I would say almost consensus level problems around like, how does a group of people determine And what the state, agree on what the state of the funds in a channel are and how many people have to sign off on that, and you start ending up, I think, kind of back in interesting, you know, this is like one of the problems of blockchain solves, is what is the current state. so I feel like, you know, as soon as you start getting into, and I could be wrong about how like the channel factory constructions work, which is fine, but anytime you start having more people, you know, trying to agree on state in a decentralized manner, like, yeah, Like, oh, well, blockchains fix this. so I think things like, you know, you start ending up with things that look more like federation. So like, fede-- there's kind of this like, like a channel is sort of like the smallest, the current lightning channel is currently the smallest federation you can get, and everyone who's in a channel is a party to that federation. So you have like some of like first class cit-- like these kind of like these citizenship tiers. I feel like you guys were talking earlier about Uncle Jim, Uncle Bob, and well, that's like You're no longer part of the federation of the layer two if you've got an uncle Jim or uncle Bob who's running your lightning node, they're now the first class citizen in terms of the federation, which is a lightning channel, and you are now just a client of theirs. Start moving into more federated things like Liquid or the proposed, you know, Fedemints that are in the process of rolling out, most people on those are gonna be like I hate to say second class, I'm gonna get in trouble for this, whatever, second class citizens on those networks because they're not members of the federation, right? And the members of the federation are really the ones that get a lot of the trustless guarantees. of that particular protocol. so anyways, channel factories, I feel like I have questions about, you know, what class you end up in on those is one question, and the other is, you know, what are the liveness, requirements that you need from everyone? Like, at what point is it like, \"Well, we need a blockchain to solve this because it's a consensus problem?\" problem of agreeing on what the current state of all the virtual channels are." }, { "speaker": "stephan", "time": "46:36", "start": 2796.45, "text": "yeah, I had a chat with, I didn't episode recently with Greg, Insta Gibbs, talk, who's working on some of this stuff around, you know, L-LN symmetry and some of these ideas around multi-party channels, and I, I think he, he might be a good person to ask, but, I, I know, yeah, definitely having more interactivity would make it even more difficult, and if people are already struggling in, in a two-party channel context" }, { "speaker": "stephan", "time": "47:01", "start": 2820.88, "text": "Future people sort of are more professional about it, they know how to do it, and maybe you have these small channel, multi-party channel things. Yeah, I guess it's too early to really comment authoritatively on it." }, { "speaker": "guest_3", "time": "47:12", "start": 2831.89, "text": "Well, I think part of, part of why I bring up channel factories is just from my preliminary pass over ARC, it looks a lot like a channel factory to me, with some differences, and that I think ARC does settle on chain periodically, and that part I don't, I don't quite understand, and that part I don't really understand how it- takes some of the stress off of the blockchain, given that it's always broadcasting to the blockchain. So I think" }, { "speaker": "stephan", "time": "47:37", "start": 2856.65, "text": "the answer in that case, in terms of the arc question, the ASP instead of the LSP, it has a very high capital requirement. The ASP has to have enough Bitcoin to basically fund all of the transactions that are going on inside that, and every five seconds it's like a coin join round, and it's not, it's not necessarily hitting the chain every five seconds, but there's like this kind of rounds going on, It's kind of a complicated thing, I'm kind of beyond my level as well, but I, yeah, I think that's kind of my understanding from talking with Barak, but, I think it'll, it'll sort of come out, yeah." }, { "speaker": "guest_3", "time": "48:11", "start": 2891.23, "text": "So just, just to clear that up, since you had a talk with him, every five seconds, are you replacing, are you destroying the previous transaction? That's what I don't understand. So I think the idea" }, { "speaker": "stephan", "time": "48:21", "start": 2900.82, "text": "is, yeah, you might be remixing, but you may not necessarily be remixing. Wow. So the Because of that ASP, the ASP is coordinating a round every five seconds, kind of like a coin join remixing round, but it's a virtual round. They're virtual TXOs. That's kind of this virtual concept that I think you're referring to. And there's a certain number of on-chain transactions required, but the ASP is basically doing that. But the point in that model is you can unilaterally still exit. I mean, just like in Lightning, so I think that's also an important point. I think another topic that would be interesting to chat about is swaps, because obviously, I'm I think it's a safe assumption, all four people on here, on this call or on this podcast, are, are Lightning users today, but not every one of our bills and things can be paid with Lightning. So there are times where we need to interact back with on-chain Bitcoin, and then this brings up that question of using swap providers. So as an example, Bolts Dot Exchange, and there are others out there, where they can give you, as an example, they can say, \"Hey, pay this Lightning invoice, and I'll pay out the on-chain amount for you Well, so I think that's an interesting idea. I'm curious if you guys have any reflections on the use of these swap providers, especially in a high fee context. So" }, { "speaker": "guest_3", "time": "49:41", "start": 2980.78, "text": "Yeah, I mean, just real quick, what I'll say is the proper way to do a submarine swap is to go through Strike. And let's just be real, like it's- Right, but that's a custo-" }, { "speaker": "stephan", "time": "49:55", "start": 2994.55, "text": "these are custodial swaps, to be clear. So what we're talking about in this case is like the, you know, the more trust-minimized way of, you know-" }, { "speaker": "guest_3", "time": "50:03", "start": 3002.66, "text": "Which is, which is why it's kind of a joke. And, and in Plebnet, we call this a ghetto submarine swap, where, to your point, it's, it's not actually trustless, but man, is it convenient." }, { "speaker": "guest_2", "time": "50:13", "start": 3012.64, "text": "It's important to, I, in my opinion, there's two major reasons" }, { "speaker": "guest_2", "time": "50:19", "start": 3019.31, "text": "Strapping a routing node, and you need inbound liquidity fast because you just want to get it going quickly. The other reason is your node is receiving a lot, and you need a way to offload that outbound liquidity. so yeah, I mean, I think that in a high fee environment, offloading that outbound liquidity in a way that, especially, you know, if you're getting like a lot of income, right? You know, and your, your channels should be reflective of the amount of income you're getting. But that aside, yeah, swaps Are useful, you know, we all know what Loop is and, and stuff. It's just, but swapping to a different side chain of Bitcoin is an interesting idea, you know, it's not trustless, it's def- I mean, Liquids definitely trust-minimized, but it's not trustless, but, you know, you could peg in and peg out, you know, so, so you can sort of offload your outbound liquidity, store it in Liquid, and then wait until maybe fees go down or something to peg out of Liquid, I guess is the idea for that." }, { "speaker": "stephan", "time": "51:19", "start": 3079.26, "text": "Right, and so I think this was an interesting one because BOLT dot exchange just recently brought out that feature of having an L BTC swaps, and then now they've got Lightning Bitcoin, on-chain Bitcoin, and L BTC, which is, you know, using the federation. And so I think the point Adam, Bach, and some others were making is that the minimum fees on Liquid are so low, and especially 'cause right now there's not a lot of Liquid users, so it's like the Liquid fees are very cheap, so this might be an opportunity for people who are running bigger nodes who need Operations. Lisa, I know you were, you were at Blockstream recently, so I don't know if you have anything to add there." }, { "speaker": "stephan_livera", "time": "51:54", "start": 3113.94, "text": "Yeah, I think like, you know, it's one thing that, Blockstream we talked a lot internally about helping people do. There was a project that was being developed, I don't know what the status of it is. I think it's a little like quiet these days. It's a peer swap project, which would help. Basically anyone swap with their peer using either liquid or on chain as a way to basically push funds. So like, why would you-- So like, I think there's a few things you can talk about with swaps. One is why would you use them? I think splicing kind of brings up a new and interesting way to think about it. I think another thing about swaps is like, you know, the thing I keep going back to and like go back to constantly is like capital efficiency. How much Bitcoin do you need to be available to make these operations happen? Where does that Bitcoin need to be located in order for it to be like a useful thing? you know, the availability of capital or like liquid and like, or, or Bitcoin in the right place is really, I think, gonna be one of the things. So like the fee rate market is like the big one right now, but there's definitely a future where the fees that you're paying are gonna be in relation to the availability of liquidity in the particular place that you're looking to do that swap, right? So basically what a- The swap requires, is it requires two x the capital to exist in different places for you to effectuate a change, right? So if I'm trying to, so what is a swap? A swap means I have a channel with Stephan, Stephan has on-chain Bitcoin, whether that's on-chain in Bitcoin itself or it's on-chain in liquid, you still have to have that Bitcoin available equal to the amount of Bitcoin that I have in Lightning. And so that's like, that's what I mean by the two x, right? Let's say I've got a bit- Bitcoin in a channel, you have to have a Bitcoin either in liquid or on chain available for me to push that liquidity to you, and you to either through Lightning or, I mean, either through Liquid or through on chain, send that Bitcoin to an address that I own, right? So like swaps are expensive in terms, like expensive, but the capital required to make that exchange happen is you both need a whole Bitcoin, right? So that's like, I think one thing when I think of swaps and like, yeah, it's expensive. What's nice About that is that if you're a vendor and you're selling a lot of stuff on Lightning, you're gonna get all of the money in the, all of the channels are gonna end up on your side, right? So now you have a problem. You need more inbound liquidity on Lightning in order to receive more money, right? So where are you? So you need to take this money in the channel that's yours. You're stacking Sats, right? You're earning money, you're running your business. Maybe you're paying some of your, like, expenses out with Lightning, but for the most" }, { "speaker": "stephan_livera", "time": "54:39", "start": 3278.99, "text": "Profitable business, which means you're earning like a Bitcoin a day on Lightning or whatever, right? So you're stacking Bitcoin. you need to be able to take that Bitcoin and probably put it in cold storage or move it somewhere, right? A swap is a way that will let you do two things at once, which is cool. It'll let you stack that Bitcoin, maybe you're stacking it on Liquid, maybe you're stacking it in like cold storage or something. It lets you both move those funds, you're taking someone else's funds, they're sending them to cold storage for you, You're pushing all your liquidity to the other side of the channel, which now means you can reuse it to re- to accept a full taproot. To start receiving" }, { "speaker": "stephan", "time": "55:16", "start": 3315.62, "text": "again, yeah." }, { "speaker": "stephan_livera", "time": "55:17", "start": 3316.72, "text": "Yeah. So this is one of the things that swaps do that splicing doesn't do. splicing, there's a way that you can marry splicing with liquidity adds, which will let you do a Very, very similar operation, almost. You can get rid of the swap stuff. You can have one on-chain transaction, so it's the same as a swap, which takes one on-chain transaction. You could use a splice plus a liquidity add or some mechanism of buying more capital from that node. So a swap means you can buy liquidity from anyone, splicing you would have to be buying liquidity from your channel peer for the most part, or they'd have to source it from somewhere. So then they would put more cap-- you'd pay them to put more- More capital on their side of the channel, at the same time you could then move the capital on your side of the channel to any on-chain address. That would all be on-chain and that wouldn't involve liquid. And then you're paying, you're stuck with whatever the current block space market rates are for doing that transaction versus if you're doing a swap on liquid, then you're only paying the on-chain fees on liquid or whatever. Okay, I've talked, I think" }, { "speaker": "stephan", "time": "56:21", "start": 3381.12, "text": "I get you" }, { "speaker": "stephan_livera", "time": "56:22", "start": 3381.58, "text": "there." }, { "speaker": "stephan", "time": "56:22", "start": 3382.2, "text": "Yeah, I think I get you there. And so I guess just to make it simple for listeners, whereas swaps, in this case where we're using Bolts, someone's making a payment generally, right? Like you're making a payment, yeah, right, where kind of moving the balances around As opposed to resizing up or down. Yeah, exactly. Okay, so that's the key point. And then it comes to also the fee rates, right? So I guess maybe today we're still, we're still lucky, right, that, you know, right now today fees are still low, it's still, you know, next block right now is sixty-six sat per vbyte as I look right now, but in the future it could go up a lot. And then what does that mean for Lightning fees? Does that mean in order to be a profitable Lightning routing node, you need to charge a Or in your PPM, variable fee, parts per million variable fee. Do you believe that, you know, we're in the glory days right now and that fees are going to have to go up in terms of Lightning fees?" }, { "speaker": "guest_2", "time": "57:22", "start": 3441.92, "text": "I personally think so. I think that if node-- people running nodes don't do the math and make their fee rates, appropriate based on the amount of capital they're spending or could even spend, so you're not only just the, the amount that you're spending to open the channel, but the amount that you could spend, you know, probability speaking in the future, then folks are just gonna be losing money all, all the time, and that isn't gonna be good. So you and, and, and, and nodes that are, in demand, that people are paying a lot, it'll cost more to route to them also probably. So, you know, as much as I enjoy paying less than one sat to route a Lightning payment, there's a good chance that isn't gonna be forever. However, it's still gonna be a much better deal than on-chain is gonna be though, which is what's important. So to boil it down on that, you know, if, if, if- If it costs you two thousand sats to open up a channel, you should set your fee rate, in my opinion, it's just my opinion, you should set your fee rate appropriately to where if that channel drains, you get that two thousand sats back at a minimum, like that's how I would do it personally. And it's important because the size of your channel, the bigger it is now, the, the less fee rate you have to put on it, because, just, just a percentage base of it, right? It's You know, trying to get two thousand sats back from a hundred thousand sat channel is probably gonna be very difficult compared to two thousand sats back on a twenty million sat channel, so these things, You know, and it's kind of unfortunate because people are gonna be like, \"Oh, so in the future, you know, nobody's gonna be able to run a Lightning node, it's gonna be like insanely difficult.\" And the way it stands now, that actually might, might, might be the case, you know, there's no denying it. So the future remains to be seen, but, my fee rates will go up as, as it costs more, to open channels and stuff." }, { "speaker": "stephan", "time": "59:25", "start": 3565.32, "text": "Yeah. And so just to put that in simple terms, it's also that there may be" }, { "speaker": "stephan", "time": "59:33", "start": 3572.74, "text": "Who aren't charging high enough fees, because the fee, the on-chain fees could rise to a level that they are now losing money on running that lightning node, and, you know, if you look at the average fee rate, so as an example, I'm just looking at mempool.space/lightning, average fee rate today is five hundred and twelve ppm, so five hundred and twelve parts per million, and so, you know, that's kind of the fee rate, or I guess the prevailing fee rate, and to be clear, that would be the fee rate per hop. So" }, { "speaker": "stephan", "time": "01:00:02", "start": 3602.76, "text": "Five people, you're paying that five times, right? So- For folks that don't know," }, { "speaker": "guest_2", "time": "01:00:06", "start": 3606.85, "text": "ten thousandths, ppm is one percent, so you can do the math on that, five hundred ppm." }, { "speaker": "stephan", "time": "01:00:13", "start": 3613.65, "text": "Gotcha. Yeah. And so I guess it's interesting to see where that goes. Of course, it gets into that conversation around, you know, people, I guess, are going to debate this for a while as around this question is, should Bitcoin be for everybody or actually you just have to accept that, you know what? Like-" }, { "speaker": "guest_2", "time": "01:00:27", "start": 3627.3, "text": "But there's, but there's another way to offset that cost, and that is to provide liquidity towards those that are willing to pay you for it also. So, things like liquidity ads and Amboss and Lightning Pool and stuff gives node runners a way alternatively, to than just fee rates. So it is very like running a business, very much like running a business. You have to figure out, you know, if, if you don't wanna lose Sats, you do have to do a little bit of calculation to figure out how you're going to, to play the game. A lot of folks actually still set zero Sats for their routing and their, they just sell liquidity on Amboss all day, and that's perfectly reasonable. so reminds me of zero fee routing, right? Exactly. Rest in peace. but yeah, so, so I just wanted to point that out there that, I, I believe liquidity markets will still be very, important in the future, and those will be reputation based. So those that have been around for a while, that have proven themselves, will likely charge a premium compared to, nodes that haven't reached that level, which is another incentive to start your Lightning node pos- as soon as possible if you're capable of doing so." }, { "speaker": "stephan_livera", "time": "01:01:38", "start": 3698.9, "text": "I wanted to like just point out maybe two things that I've worked on or like proposed that I think are kind of important in this like area of like how do we like, you know, what are you controlling? Like, are our fees gonna go up for routing things? How do you decide what to set your fees at? I think is an interesting question then, right? I think that like one of the big projects I worked on correlating last year was adding really detailed bookkeeping so that you can figure out where your costs are and how much you're spending money, where the Money is being spent. being able to have a detailed analysis of what, like, you know, what your historical costs have been, maybe figuring out a prediction of like what your costs might be, and how to like kind of price that into, you know, doing a risk calculation, right? Of how much do you think you're gonna end up paying in on-chain fees? what's your risk of a foreclosure, that sort of thing, can help you price your liquidity, both that you're selling maybe through liquidity ads or on Magma or how much you're charging for payments. To go through. There's another thing that I proposed last year, went out on the mailing list, which is a new kind of way of allowing people to introduce like price curves to the amount that they're charging for available liquidity in a channel as a way to dynamically, but with the static information, so like reducing the burden of communication on the network, but allowing people to set dynamic rates for their available liquidity, such that when you have less liquidity, you get paid more for it, which means that if If it's a popular route, you get paid more. and encouraging people to use routes that have more liquidity available, so this kind of like the, and even maybe give people an opportunity to like make payments at a discount, so setting negative fee rates for sending payments in what are called like indirections that the capital is a contraflow, right? So if you're sending a payment in a direction that most people aren't using, that's beneficial for the router and- And for people using Lightning, because it allows them to reuse capital without having to go on chain. So by introducing like these new mechanics, like the fee rate stuff, fee rate cards that allow you to do these kind of really cool price curves in a really like, update information, efficient way. The current ways of doing it are very bad for the network because they generate a lot of, gossip traffic. that'll really change the game, I think, in terms of like, giving node operators more knobs, more ways to kind of price their liquidity in intelligent ways that both enables them to reuse their capital more often, which cuts down on on-chain costs because you don't have to do rebalancing or like moving capital around, as well as, actually extracting more rent, so to speak, from, high in-demand routes, which is kind of a cool thing." }, { "speaker": "guest_2", "time": "01:04:34", "start": 3874.59, "text": "The idea on that is like if I have, I found like some, we'll just say that nobody else knows this, and I have a channel to appear, and I'm getting a thousand ppm, like pretty well, I'm earning a bunch of fees, with, in a negative fee rate strategy, after that drains, I can set negative fee rate at like two or three hundred to sort of force it back in, and my net is still seven hundred ppm, because then I'll flip it back around and then have it go the other way to keep the, the profit margin." }, { "speaker": "stephan_livera", "time": "01:05:04", "start": 3904.61, "text": "Idea is that, like, your channel will tend towards the middle, so like, the balance will be sort of more even in the middle, such that payments have the opportunity to go both directions" }, { "speaker": "guest_2", "time": "01:05:16", "start": 3916.6, "text": "or whatever. Gosh, yeah. It's like a sta- it's like a static state that's just kind of like, if the channel's this big, or, you know, if it's a foot wide, it's like at the six-inch mark just kind of floundering around. Yeah." }, { "speaker": "stephan_livera", "time": "01:05:26", "start": 3926.41, "text": "Exactly. And you introduce resistance or like decrease or increase the resistance in terms of what the fees are as Of either being one way or the other, right? so this kind of introduces a new physics to payments, such that, like, it's going against the flow, you actually get rewarded, and going in the direction where flow is like more, whatever, you get as a node operator, you get paid more. If that makes sense. So providing capital in like highly, in routes where there's not a lot of availability, you could get, you get automatically kind of paid more." }, { "speaker": "guest_2", "time": "01:06:00", "start": 3960.25, "text": "The trade-off is you need more bandwidth for the gossip, is that?" }, { "speaker": "stephan_livera", "time": "01:06:03", "start": 3963.93, "text": "No, it actually- Cuts down on the amount of gossip you need to do it, my proposal does. So currently people dynamically update their fee rates, which is very expensive in terms of gossip, because every time you update your fee rate, everyone on the node finds out about it. So every time, so more channels and more people running automatic fee rate adjusters is the worst possible thing you can do for gossip on the Lightning Network. Every new channel increases, adds three new messages on the gossip, and then every time you update it, you send out, every time you update the fees on your channel, you send out, A new piece of gossip for it. So if you have four channels between you and another peer, that's suddenly twelve gossip messages that everyone needs to know and keep track of, and every time you up-- that's four times that you update the fee rates, everyone's gonna need to know about it. So it's this very bad, like, almost exponential increase in the amount of data that's going out to do dynamic fee rates, whereas the proposal that I came up with lets you kind of set it once and they dynamically change based on how the liquidity in the channel shifts, and you don't have to- rebroadcast or send out any update, so it drastically reduces the amount of, of bandwidth gossip is taking up." }, { "speaker": "stephan", "time": "01:07:12", "start": 4032.96, "text": "Cool. and in terms of Lightning services, there are some that let's say rely on low chain fees, and when chain fees rise, maybe those services, they get less volume or, they, they run into issues because they're just not profitable. I mean, I guess an easy example might be like Moon Wallet as an example, because there are a lot of Moon Wallet users, and basically almost every payment on that isn't on-chain payment, and in a High fee environment, it's, it's pretty rough, whereas like a Lightning native service, maybe they have a slightly better time in a high fee environment. so that's one example. I'm curious if you guys can think of any others or have any, anything to add there." }, { "speaker": "guest_2", "time": "01:07:49", "start": 4069.3, "text": "I mean, Moon's the shining example of that, you know, Moon's a very, I don't even fully understand how it works, but I do know that it does have that on-chain component and it, it just, you know, they eventually fixed what was happening there, but it really, You know, I like when people and companies and developers are get really creative, you know, it's like, \"This is lightning, but it's not actually lightning, sort of thing, but it's really user friendly and, and kind of cool and, and like the appropriate environment.\" But I definitely wanna see, you know, as much lightning native apps and services as possible. I'm a big fan of Phoenix. you know, Phoenix is still has a little bit of a, of a headache when you're first getting going, but once you get going, it's great. So stuff like that, I really like, but I can't really think of any other examples off the top of my head." }, { "speaker": "stephan", "time": "01:08:40", "start": 4120.68, "text": "Yeah, but in fairness to the Moon guys as well, I mean, I know they, I think Dario put this on the mailing list, he said they've got a hundred thousand users, which is, you know, that's That's impressive, right? Like it's, so for all the, you know, complaints about that, I mean, they have a decent user base. I really love the idea" }, { "speaker": "guest_2", "time": "01:08:57", "start": 4137.79, "text": "of having on-chain and lightning sort of unified, because that's really nice user experience for people, you know?" }, { "speaker": "stephan", "time": "01:09:04", "start": 4144.96, "text": "Yeah. I think that comes back to the splicing concept as well, like the way Dusty explains it as well, is that, hey, in a world with splicing, you could have a more lightning native experience, and maybe splicing would enable the Moon Wallet guys to do something even more incredible with And or maybe it would also help, you know, the likes of Phoenix and Breeze and stuff as well. I guess one other area I'm curious to hear what you guys think in terms of the, the longer term future with Bitcoin and Lightning, it seems there's a lot more excitement and discussion around things like covenants, things like any prevout or check template verify. Do you guys have any views on that? Do you guys think it would be necessary, nice to have, or a bad idea? Do you have any thoughts" }, { "speaker": "guest_3", "time": "01:09:45", "start": 4185.73, "text": "on that? Yeah, I mean, I would say that I In your cold storage to me is a lot less interesting than all of the things that they can unlock for Lightning. So definitely looking at L2. Now whether we get CTV or any Privoat or both, is certainly not something that I can really predict. But I think a lot of us felt kind of some pressure last year to sort of sign off on the correct covenant proposal, and we, we, we kind of reacted. But now that the pressure's off, a lot of folks are coming back around and saying, \"Oh, Okay. Like now that I feel free to make a decision on my own terms and my own time, these are pretty interesting. Like maybe, maybe we are gonna think about doing this, you know, not anytime soon, but I would say in the next few years. And I think I would be against a covenant proposal that didn't enable L2 personally." }, { "speaker": "stephan", "time": "01:10:40", "start": 4240.04, "text": "Gotcha, yeah. Okay, great. Lisa or Nate, anything to add there?" }, { "speaker": "stephan_livera", "time": "01:10:43", "start": 4243.62, "text": "Yeah, I mean, I think the covenant stuff is, I was like, it's interesting. I think that, like- Like, I think people make interesting points about like, \"Well, we already have covenants on Bitcoin, or like technically covenant-style stuff. Maybe we've already like opened that can of worms. Now it's just like, what strategy are we moving forward with?\" yeah, I don't really have like, covenants aren't something I spend a lot of time thinking about. I definitely seem to spend more of my time thinking about liquidity problems on Lightning than, across the network, than the covenant stuff. But I think like, you know, there's only twenty-one million Bitcoin. where is that twenty-one million Bitcoin gonna end up? It's gonna be an interesting question in terms of which of these different Layer Twos, whether it's something that uses covenants or maybe it's like liquid or maybe it's something else like, which of these like actual Layer Twos, maybe it's like a federation like Liquid, where is this like, which of these is actually usable? Which actually- Has liquidity and the capital available for people to do exchange, and is like adding covenants gonna lock up more liquidity and like places that make it harder for other people to like use or do things with, you know, the more kinds of layer twos that we get, there's only twenty one million bitcoin to split between them, so, you know, some-" }, { "speaker": "guest_3", "time": "01:12:11", "start": 4331.92, "text": "Yeah, yeah, it's an opportunity cost of where you put it. So I" }, { "speaker": "stephan_livera", "time": "01:12:13", "start": 4333.95, "text": "think like, you know, the next like five, ten years, I think that's gonna become an increasingly interesting question." }, { "speaker": "stephan", "time": "01:12:20", "start": 4340.73, "text": "Yeah, I guess I might as well just add here, liquid-- as, as you, as I'm sure you're aware, Liquid already has some covenants. It already has like, there's Signet and there's Inquisition and things like this that are, are designed to kind of test some of these out. Maybe the idea is that people test some of these ideas out there and then it Proven out that it's safe as an example, and then maybe that's part of the pathway for some of these ideas." }, { "speaker": "stephan_livera", "time": "01:12:47", "start": 4367.27, "text": "Maybe we just leave it on Liquid, and if you wanna do cool, interesting covenant stuff, you just go do it on a side chain or they build it into Fedamun, and so all the funky, fancy contracts can happen in Layer 2, and we leave Bitcoin as the store of value and don't really- Have to think too hard about what covenants mean for Bitcoin because all of that experimentation happens on an L2." }, { "speaker": "guest_2", "time": "01:13:10", "start": 4390.32, "text": "Yeah. Nate, anything you wanna add here? I'm just, I'm a big fan of, of, privacy enhancing tools. So if there's a way to obfuscate ownership of UTXOs, whether it's by having multiple owners of a UTXO or, you know, I think that's really interesting and cool and I would like to mess with it someday, and I think- That, the privacy challenges of Lightning should be tackled also, which is a whole other can of worms. I'm really a big fan of Paul and Tony building the Mutiny wallet. I think that is an incredible project that everyone should be keeping tabs on. But just the spec in general, just, you know, Bold 11 has a lot of issues and hopefully we can really tackle these. You know, I know and respect the devs, especially the protocol devs very, very, very much, so I know that it's very, very difficult Difficult, but I have low time preference and I'm sure a lot of this will get solved in time. But we are in a race against the heavens, so we'll see what happens." }, { "speaker": "stephan", "time": "01:14:12", "start": 4452.53, "text": "One other area I was keen to just ask on is, HTLCs smaller than the dust limit. Alright, so this is kind of an interesting idea, especially in the high fee context, right? Because as fees rise, there's this kind of-- there are people who are sometimes commenting and saying, \"Oh, well, any amount in an HTLC below the dust limit is actually kind of- custodial or you're, you're trusting in that context. The" }, { "speaker": "guest_2", "time": "01:14:37", "start": 4477.23, "text": "best thing you could do in, to mitigate that dust thing is to just, increase the minimum HTLC size. you're, you're not going to, I mean, and it could be in the millisats too, but you know, it's like, oh, what should I increase it? It's, you, you look at your channel's activity and see what it's doing, you know, if it's really blasting through a bunch of like streaming payments and you're not really earning a lot from them, maybe, maybe bump it up to three or four sets or something. but, that, it, it's my understanding that's really all you can do to, to" }, { "speaker": "guest_3", "time": "01:15:16", "start": 4516.52, "text": "Yeah, well, I mean, I've talked to node runners who have their minimum HLC size as the dust limit, which is certainly one way of doing it. It's not my approach, but it's only gonna get worse as fees go up. This is only gonna become more of a problem. So again, good for us to start thinking about this kind of thing in a timely manner. And Stefan, I'm, I'm so happy that you posed this topic. I just think it couldn't be more appropriate for today, and I think that even just a few months ago, nobody wanted to talk Talk about what a Bitcoin world would look like in a high fee environment for whatever reason. We can't assume that fees are gonna stay low forever. As far as I'm concerned, Bitcoin has sort of a binary outcome. Either it does its job of being gold two point oh, of being the money, or it doesn't. And if it does its job, the fees are gonna be very, very, very high. I mean, we're talking hundreds of dollars per transaction, maybe thousands. And by that time, I don't know if we're gonna be pricing everything in dollars. Dollars might not be our unit of account, but, you know, for all intents and purposes, I'm just using the unit of account that we commonly think of today. So, I mean, look, my node, I have zero PPM, zero base fee, no minimum HTLC. You know, my node is for the plebs, by the plebs. It's basically just for educational purposes and my own personal use. And yeah, I am running this node at a loss because I'm paying for the infrastructure, I'm paying for all of the gear, and I'm paying for those Panel opens and closes and forced closures and all that kind of stuff. I'm not saying that's the right way of doing it. I don't think that we have to rely on altruism in order to create the next Financial rails for the entire global market. I'm just saying that that's what I'm doing right now, and I think it will remain to be seen kind of how the incentives play out. But to Nate's point, we're not gonna expect to see very low rates on Lightning forever, and I think we do a disservice to folks when we say that Lightning is free. And I am so guilty of this. I am so guilty of this because I wanna destroy every shitcoin narrative and say, \"Hey, Lightning is instant and Lightning is free.\" And again, This is a note to myself to better explain to folks that, okay, you are paying a percentage of the total, that percentage may change over time, because I don't want anyone to come back to me in a few years and be like, \"D plus plus lied, and now, you know, I'm having to pay half a percent,\" and, you know, \"She's a shit corner, 'cause she's like creating these false narratives just like everybody else.\" And so, yeah, for all intents and purposes, Lightning is like kind of free today, and, you know, enjoy it while," }, { "speaker": "guest_2", "time": "01:17:55", "start": 4675.72, "text": "I think, I think that's right. Going on If you're buying something from a service that a ton of other people are sending money to, you can expect to pay a higher fee rate than if you were just sending some Sats to your neighbor, for mowing your lawn or whatever. you know, if you buy something off of Bitrefill or the Bitcoin company, you can expect to pay a higher fee rate than just, like I said, than your neighbor." }, { "speaker": "stephan", "time": "01:18:21", "start": 4701.04, "text": "Yeah, interesting, and that's a fair point because the route, that route is Worth more, quote unquote, worth more, because more people are trying to travel that route, let's say. So interesting stuff. I think we'll probably have to wrap up here. I think we've been going for a while anyway, but, I'll make sure to include everybody's, links in the show notes. So D++, I'll put, your, your social media handle there and plebnet. Nate, I'll put, your social media stuff there, as well as the voltage dot cloud, the blog post, and" }, { "speaker": "guest_2", "time": "01:18:49", "start": 4729.18, "text": "for On that, who has been writing some fantastic stuff on the Voltage blog, so definitely check it out." }, { "speaker": "stephan", "time": "01:19:00", "start": 4740.53, "text": "Fantastic. Okay, guys, well, thank you for joining me, and, I'll chat with you soon." }, { "speaker": "guest_3", "time": "01:19:04", "start": 4744.77, "text": "Thank you. Thanks for having me." }, { "speaker": "stephan", "time": "01:19:06", "start": 4746.63, "text": "Bye. So let me know what you think about Lightning in a high fee environment. How did you perform if you're running a Lightning node? And you can find the show notes at stephanlivera dot com. Thanks for listening, and I'll see you in the Citadel." } ] }