Next Generation Lightning

Hi, you're listening to Stephan Livera podcast, a show about Bitcoin and Austrian economics brought to you by swan dot com. Today we're talking about Phoenix wallet and next generation lightning experience for Bitcoin and lightning users. Joining me is the CTO of Esank, Bastian, and he joins me to talk about a bunch of things dealing with a high fee environment. The new Phoenix splicing update, the new fee structure, dual funding, liquidity adds, can A-Sync steal from users? His thoughts on any prevail, biggest challenges, and reasons to be optimistic on Bitcoin and Lightning. And now onto the show. Bastien, welcome back to

the

show.

Hey Stefan, thanks for having me, glad to be here.

Yeah, it's been a while since we last spoke, and I know you are now CTO over at Achain, so congratulations on that. And, I have to say, congratulations on the new version of Phoenix. I've been playing around with it, and I've found it really great. So just having splicing, and obviously we'll get into all this, but I found it really slick in terms of merging that kind of on-chain and off-chain world, and actually giving users Simple experience, right? Of course, I have my own node where I have my own channels and all that, but I wanted to just kind of play around with this and see what it's like for a typical, you know, user who's not, let's say, really into Bitcoin that they're gonna run their own Lightning node with their own manually managed channels and things like this. so let-- yeah, let's get a bit of an update from you. What's, you know, what have been the main priorities for you guys over at Async and working on Lightning?

Okay, so what-- the thing that decided our priority was the high fee event, that was caused by the over-inscription and all the other stuff. We saw that the mempool could get full again, the fees could rise again, and we knew that the last time that happened, Lightning had a lot of issues dealing with it, and we've since made a lot of changes to the specification to make it better, for example, anchor outputs was mostly a result of what we had seen with high fees and the issues we were having with fast closing channels when the fees were high, so we made- We don't know how it puts to fix that, but then that, that's already been made, that's already been shipped more than a year ago. But there are still things where Lightning has issues with dealing with high fee environment, and it's really important to be prepared. And now, what's the right time to build tooling and to build features that would make us more resilient to high fee and the next high fee environment, because it will happen, it will happen at some point, so we need to be ready. So that's why our priorities, we're working on dual funding and splicing,

You are more efficient with the transactions, the unchain transaction that you make, and you are able to move liquidity around much more efficiently. And since we also want to be able to onboard more users, we need to make sure that each user only consumes one of your UTXOs, because if you have many channels per users, that means you are using a lot of UTXOs per users, and when that user disappears and you have to close those channels, this is gonna cost a lot of unchain fees, if the unchain fees are high, and this is something that could make you potential- Eventually go out of business if you aren't really trying to make it economically viable to run an LSP, for example. So we need to make sure that LSPs can be as economically viable as possible if we want this business model to even survive and users to be able to benefit from that.

Yeah, that's interesting. I noticed in the prior version of Phoenix, I had, I think I had maybe eleven or twelve channels, right? And so you think about that, that's twelve UTXOs just for one person, and now of course, I'm running on the new splicing version that you So now I have one channel and one UTXO, so I think that's kind of an obvious one. That's like on the, the client, the user side, but obviously on your side as the LSP that, you know, that's running underlying that, I suppose there are efficiency gains that are won by doing this. So can you elaborate a little bit why splicing has so much of an efficiency gain?

Okay, for example, we have some users, de-depending on what your usage pattern in Lightning is, if you are, for example, only receiving all the time and not spending Pretty much, you just end up getting more inbound liquidity added all the time, which requires a non-chain transaction, and without splitting in the previous version of Phoenix, we would open a new channel every time. So some users end up with a hundred channels, and a hundred channels means that when this user decides to just disappear, decide to just uninstall the app and never tell us anything about it, we have to fast forward a hundred channels. That means Getting a hundred commitment transactions on chain, commitment transactions are big because they are spending two of two multisig, so they have an expensive witness, so that has, that really has a high cost on the LSP, and since you have to account for that in your pricing model, that actually affects all your users, which is really bad. You want to make sure that you're able to give users the lowest fee that you can still get away with while staying economically viable, so you want to make sure that you avoid those pathological cases. And now that we have splicing, there is still some- Somewhat of an issue for someone who is only receiving on Lightning, because whenever they receive, they will keep needing a new splice that increases the size of the channel. But eventually, the, the channel is gonna get bigger and bigger and bigger, and when they start spending that amount, then they're gonna be able to receive without making on-chain transactions, because they will have a big channel with liquidity on both side. And we now have only one potential channel to force close, even if the channel sizes shrinks and grows, it means we, we know that we only have one commitment on the- Transaction to potentially claim on chain if the user disappears, which is much more predictable and which will cost much less fees for us, so we can have a discount on those. And that, that's why all of those placing transactions when they happen, we don't take a fee on that. We only make the user pay for the on-chain fee that goes to the miner, but there's nothing going to Asunc on all those places.

Yeah. And so one other area to talk about is the fees. So there was a shift in the fees. I think previously, and I can include the Show notes for listeners who are interested, but you have a table where it shows the old fees and the new fees. And basically, it's like in the new model, you're paying on the, whatever the on-chain fees are, plus zero point four percent on the outgoing Lightning sending, whereas historically, you would have had, I think it was like a one percent fee on the incoming in order to swap that on-chain amount into Lightning. So I guess that, you know, depending on how you use Phoenix, it could be a big drop in your fees, but maybe some users on the other- On the other hand, we'll say, "Oh, look, I could get it much cheaper by doing my own Lightning node and all that, " but of course, I understand S-INC also needs a business model, and you obviously have to make money to fund the development and fund all of this. So could you just outline a little bit on the, the fees and how people have been reacting, and, you know, in your experience or in your discussions with customers or users?

Yeah, so it's, it's exactly what you described, and what's interesting is that we added a feature inside Phoenix

We're just not gonna do the unchain operation, and you're just gonna see a notification saying that something had happened, you could-- we, we potentially needed to create, to do a splice for you to receive some payment, but we didn't do it because the unchain fees were higher. And similarly, when you are swapping funds in, you're gonna send unchain money to your Phoenix wallet, but then if the current unchain fee rate is too high to complete that splice and, add those funds into the channel, it's just gonna sit there, and we're gonna tell you Spending swap in, spending splice in, but since the fee rate is currently high, you, you can just keep accumulating them in your unchain Phoenix wallet, and when the fees are gonna drop, then that's when the transaction will be made to splice those funds into the channel. So users can play with that configuration, set some fee ceiling that they are comfortable with, so that nothing happens that is surprising basically. And if everything that happens, you, you have, you have the ability to configure the maximum fees you're gonna pay, so you shouldn't be surprised by that, whereas before- Or you really didn't have a way to turn it off or to say if the fees exceed that amount, I don't want the operation to, to happen. And one other, thing that's related to that is that you can also completely disable this. You can completely disable on-the-fly liquidity, which means that you then become fully, fully non-custodial, non-trusted. You don't even have to trust us with zeroconf anymore, and everything that happens is something that you control. You can, you, you can swap in and entirely control that without any trust in us. And if you disable the automatic on-the-fly spli-thing, then there's absolutely no trust between you and us, which is really nice for, for some users, even though that means you have to manage liquidity yourself a bit more, and it, it can be a bit more painful. But that's where we are thinking on adding things like liquidity ads to give you tools to manage your liquidity in a different way, which is fully trustless. But all of those things are trade-offs between UX and, power users versus normal- Users, so we still want the experience to just go well for normal users who don't want to configure anything, because someone who really wants to configure very complex things is gonna be able to run their own node. And if you're able to run your own node, then that's better, just do that and don't use, don't use a wallet that doesn't have a node attached to it, just connect to your own node and do your own things. But for people who won't want to run their own node, we want to give more hooks without sacrificing too much UX, and usability

In Phoenix nowadays, just for listeners who haven't played around with the wallet yet, when you go to receive, you either got Lightning or you can go over to on-chain. It's got a static on-chain address, which is the keys to which are controlled by your, you know, by your twelve words, and so the idea is that you could be receiving on-chain payments to that address, and then based on your automated channel management setting that you set in the Phoenix app, if the fees are below, you know, a certain level, let's say five thousand sat or one thousand sat or whatever On-chain amounts that you-- that have been received into your wallet are actually, I guess, spliced into a lightning channel or flipped into lightning, and now you've kind of got that, all of that in your lightning balance. would you say that's right? Yeah. Yeah, exactly.

And also, the, the address is currently static, but we're gonna make it dynamic, soon. It was just for this first version that it was simpler to use a static address, but this isn't-- we don't recommend reusing addresses, even though users-- we cannot prevent users from still

But we're gonna rotate that address soon. But even though rotating it with a Taproot doesn't give you much privacy because it is still-- you can still see that this is going to be spliced into the channel, it's still sending to the same address, so it's not, it's not really giving you great privacy, but not rotating it at all is giving bad privacy. So we will start by rotating this address and then we will add Taproot, which will give us better privacy.

Gotcha. And so one other thing I'm curious about, and maybe this is something, this is a further away conversation, but as an example, if you receive on chain, but the other person sends it with a very low fee, is there something there where you would be looking at having some kind of child pays for parent functionality built into the wallet? Because right now, you could be sort of stuck where somebody sends you an amount, let's say the prevailing fee market or rate is, you know, six sat per byte, but they send it at two sat per byte. And you're kind of then stuck, right?

That, that is going to be hard. It's better if, sender does RBF here or if, or if they do CPFP on the, on the change output because that, that address is actually a swapping potential address. It's a two of two between your Phoenix wallet and, Asak, which means that we are first waiting for that first transaction to confirm, and when it is confirmed, we can then trustlessly use zeroconf to splice it into the channel because none of us can double spend that because it's a Two of two between you and us. So it means that if we wanted to do CPFP, that CPFP would have to be paid, would have to be signed by both Asunc and Phoenix, and there start to be edge cases where someone can, actually play security games and potentially double spend. So it's potentially hard to make it secure if we only CPFP on that two of two address.

I see, okay, yeah, that's a fair point. Okay. And so one other thing, in terms of the, how you're thinking about the typical user for Phoenix? As you mentioned, if you are receiving on chain, maybe if you're a merchant and you often need to, excuse me, be receiving in and then constantly be needing to size the channel up, meaning you're hitting the chain each time, is the wallet designed more for a spender or maybe it works better if somebody's receiving over Lightning or actually even that might not, because you, you might still need to be resizing the channel up, right? Each time it might require an on-chain transaction. So would you say the wallet currently is sort of- It works better for a regular spender than for like a regular receiver, is that fair to say?

Yeah, I think that we can even say that Lightning as a whole doesn't work well for people who are only receiving. If you're only receiving, that means you're gonna have inbound liquidity issues, and Lightning isn't really well designed for that. Stacking slowly with regular, payments that you receive without ever spending is really not the best way to use Lightning. But if you are a regular spender, then you have no issue, and that means that if you- Even if you want to spend more than you actually receive, that case can be handled by swapping, swapping funds in from Unchained, so you can keep sending and sending and sending, and you would, you only have to pay the Unchained fees for your swaps, but that's it. And if you are sending a lot and receiving sometimes, then that's perfect. Ideally, if you have almost balanced flows, that is perfect. And if you are-- if you want to be able to receive mostly, and, if you want to be able to receive mostly, what you should do is first Enough channel, and then you should swap funds out with a submarine swap to get inbound liquidity on that channel so that you can keep receiving without having to increase the channel size. So any merchant, for example, who is mostly receiving, the way they will have to deal with their inbound liquidity is that they will regularly have to watch when they have a lot of money on that side, they should do a submarine swap to move that liquidity on the other side of the channel to be able to continue receiving more funds. And that's something that can be automated And that's something that I think we-- people will be able to work on in the future. All the solutions are, are basically here, but you just need to automate them and have more submerging swap providers on the network.

Gotcha. Yeah. And so as you said, the ideal case is balanced flows, meaning, let's say you're a merchant or you're receiving, your SATs, and then you're occasionally, you're spending them on, you know, your bills or other things, whether that's, you know, going to Bitrefill or whatever else. And so Flow there, but otherwise it works well in the case where, let's say you are, let's say you receive a smaller or a larger amount on chain and you just spend it out using Lightning smaller amounts, that kind of works pretty well because you're staying off chain for the most part.

Yeah. After spending, you can receive on chain, so you should, yeah, you should try to keep that kind of flow going as much as possible where you, you receive, for example, your salary, this creates, this makes sure that you have a big enough channel, then you Your channel, your salary while the weeks are, are going, and then before receiving the next salary, you see how much you still have left here, and you then just swap that to your cold wallet because that's your savings, that the money that you still have at the end of a month, and that creates more inbound liquidity so that you can receive your next salary without having to increase the size of the channel, which is really nice.

Yeah. And then I guess from an LSP perspective, right, from a-- I think perspective, if that user leaves a very- Very big amount inbound. Is that kind of an ongoing cost for you guys, because you, you're still maintaining that channel? But I guess, am I, as I, as I'm understanding it, it means basically the business model is that you need those users to be spending enough and getting, earning enough out of their spending fee, which is a zero point four percent. So let's say you're spending a thousand dollars, that's a four dollar transaction fee. basically the model then is that you kind of, you need to make enough out of them spending there. And, you know what, Is that kind of the right understanding there?

Yeah, that, that's really hard to figure out how to behave in that case and what users expect, because generally it's weird to use Lightning just, just to stack. La-- La-- Lightning is made for payments, it's meant to be your pocket wallet, the thing you use on your phone to make regular payments. So people who want to keep a lot of inbound liquidity, this is, as you said, a cost for us, because this liquidity that we could allocate elsewhere so that it's used more efficiently, and we're not getting paid for that liquidity Now, so we are trying to think about what we could do here, if people are actually realizing that they are getting that inbound liquidity and that maybe they should pay for it, and maybe are people ready to pay, for example, a subscription using liquidity ads that would, where we would make sure that they constantly have enough inbound liquidity to receive their payments, but they pay a monthly fee for that or weekly fee or something like that, or if that's not the case, we need to use splicing regularly to take those- Out of a channel where they are idle and into a channel where they, they are better used. And that's why it's really important to have splicing because it's the most efficient way to move your liquidity around between your channels. And that's really-- we don't realize it now, but running a lightning node is a highly competitive business. It's an open market where anyone can come in, offer lower fees than you do, and offer the same services, because our goal is to make everything, specified so that anyone can at some point run with the same features so that the network is still Open and there's no lock-in to any specific vendor. So that means your fees are gonna be, your, your revenue is, is always gonna be low. You're not, you're not able to, you're not gonna be able to make a huge profit because someone else is gonna be able to come in. So you need to make sure that your costs are as low as possible. And the people who are gonna be able to survive are the people who are gonna be able to move your, their liquidity around at the lowest cost possible. So you really need to have splicing, which allows batching, which Five or ten channels where liquidity is idle and in a single transaction, take those funds out of that channel and move them to two or three other channels that are really active and really need that liquidity. And whenever you're gonna be watching the mempool a lot, watching how the fee rate evolves, and you will take the opportunity whenever the fee rate is low, for, for example, on, and there's not in, not a lot of demand for block space, the lightning service providers are gonna be the buyers for that block space because it is at a discounted rate and they will- Will jump in to do all of the on-chain transaction, all of their splays, whenever the fee rate gets low enough, which is really nice as well because it smoothes the fee rate, curves as well, and it generates more revenue for miners as well, because some people think that lightning is an attack on miners, but it's not at all. Lightning nodes will constantly need to be moving liquidity around, which will always require on-chain operations, so lightning is really useful for miners because it increases the size of the pie basically, mo-more people are gonna be using like the Bitcoin for payment. And it still increases the number of on-chain transactions that people will do overall. So I think it's really a win for miners that people will take these opportunities when the fees are low to make transactions and to still get, the miners some fee revenue.

Really interesting comments there on the mempool dynamics, as you said, because there will be certain users of the blockchain when the fees go low. So historically, that has been Bitcoin exchanges who might do their consolidations of their wallets when the fees go down to one sat per byte or whatever, go low. And so I guess what you're saying as well is in a similar way, all the Phoenix users out there will also become users of the chain when fees are low because they might have their automated fee management settings. Such that, you know, when it goes below, whatever, three thousand satoshis or whatever that number they set, when it goes below that number, now you're gonna be hitting the chain to kind of flip your on-chain money into off-chain money, into lightning, let's say. so that'll be a really interesting thing to see, and I think to the point you were making as well, it's that right now, there's not a lot of people who use lightning for payments. Now, personally, I do. you know, I earn and spend Bitcoin as many

Where I was in Malaysia and I showed people I was using Phoenix, spending at the cafe and it was self-custodial on both sides, I will say. But yeah, it might also be that, you know, because Lightning is still growing, it's small, but it is growing, that as more people can accept payment with Lightning, well then people will have more of a reason to even earn with Bitcoin and spend over Lightning, which is why I, I think, you know, it's a pretty cool approach that you've got here because you have splicing, whereas historically it w- It would have been a big fee to kind of take your full salary into the Phoenix wallet, because you would have been paying one percent on that entire amount, whereas now you can, if you want, even though it's not-- you won't have as many features as like an, an, an on-chain only wallet, you can use Phoenix like an on-chain wallet, right, right now, because of splicing. So I think that's an interesting angle, and maybe we'll see more companies start to accept Lightning, and then you can start to natively, you know, live on Lightning, Today, there's still a lot of cases where you still have to end up paying on chain, which, you know, unfortunately. But the idea, I guess, is that as more people accept Lightning, then we start to actually get more efficiencies because now you might only need to do one or two on-chain transactions and still, and do like twenty or thirty off-chain transactions, like with Lightning. So I think that's an interesting angle of, of kind of where things are going with, with the mempool and with blockchain usage. do you have anything else you wanna add on that before we move

on People don't realize it because they, they didn't understand why it didn't work well, but it really helps with payment reliability because when you have a lot of channels, your inbound liquidity is split between, for example, ten channels, it's really hard to tell the user how much they can receive with a ten-channel payment, because if you look at those channels, you think that you can just add all the inbound liquidity from every channel and that's the amount that you are able to receive over Lightning. But actually, that would only be true if the sender knew exactly how the liquidity was split between your channels and was able to split the payment accordingly, but senders don't know that, they don't have this information, and this is also dynamic information that can change over time. So usually senders aren't able to respect that split. So when people try to receive the maximum amount that they think they can receive on the Lightning, it end-- it ended up creating a new channel, and people just didn't understand that, and that didn't make any sense, and there was no way for the wallet to actually tell them, "This is the amount you can safely receive on Lightning." Whereas now with Lightning, since you The, the sender doesn't have to split anything, or even if they split, you know exactly how much you can receive, so you can start showing people, "This is the amount you can receive without needing to do a splice." And this is really nice because some payments that would otherwise fail because the unchain, fee, the unchain, channel is just rejected or fees are too high, they will just succeed now, and it just makes more sense. So we can also make it more visual for users and start, adding things in the app to make it more intuitive. Exactly how much you can send and receive and, why you need to grow the channel size if you want to receive more. So that's something we're working on, and I hope we, we're gonna be able to make it more easy to understand for our users.

Gotcha. And so one other question on the area of splicing before we move on. So are there other batching ideas that you see that could come with splicing? I think you mentioned one earlier where, let's say, async on your side as an LSP, Lightning Service Provider, on your side, you might look at Your users would be like, "Oh, hey, there's, there's these fifty users who are not using the capacity on, on the inbound side on their channel. We could take that opportunity to resize it and do that in one batch operation." Do you see other batch operation possibilities there because of slicing?

Yeah, there are a lot of things you can do, and e-even if you forget the wallet use case for just routing nodes, your routing node, you, you have to allocate your liquidity efficiently as well, because if you put some liquidity towards a node where you route no payment, this is idle liquidity as well. So routing nodes will really frequently have to look at how their liquidity is used to see the places where it's unused and to splice those funds to a different channel. And usually when you run a routing node today, you see that there are some channels that get depleted almost instantly and some channels where nothing happens. So you want to constantly, but that also isn't predictive of the future because the flows on the network are changing a lot, and you, you can't just think that this is always gonna be the case, but when that happens You can move your liquidity around, and then when the channels that tend to get depleted fast stop having activity, then you can move it back to another channel. And what's also interesting is that you can batch that with a lot of other things that you may want to do. For example, in the same transaction, that you are-- that is doing a lot of splicing activity, you could also be coordinating a coin join, or you could also do-- be doing a pay join with a merchant. All of those things, you can batch them in that transaction, which makes it much better for your on And much more efficient as well, because you're m-- you are making only one transaction instead of several.

Back to the show in a moment. Swan dot com is the lead sponsor of this show, and they are organizing Pacific Bitcoin Festival twenty twenty-three. This is going to be more than just a conference, this is a festival and a celebration of the incredible world of Bitcoin. It's a lifestyle, it's a thriving community that is working together to forge an awe-inspiring bright orange future. There is an incredible lineup of top-notch speakers, people like Max Kaiser, Stacey Herbert, V- DJ Boya Party, Preston Pish, Greg Foss, and so many more. The dates are October 5th and 6th in LA at the Barker Hangar, but make sure you come into town maybe one or two days earlier because there will be some pre-events. There will be a pleb party. This is going to be a fantastic event. I think if you spoke to anybody who was there last year, they will tell you it was an incredible vibe. You really had a chance to actually go and talk to all kinds of interesting people, whether they were Bitcoiners, speakers, or whatever Awesome vibe. This year it's gonna be even bigger and better. There'll be a main stage for dedicated talks, panels, fireside chats, as well as a swan dome for deep dive sessions and all, all kinds of other activities and things that are going on. So make sure you check your dates in the calendar, make sure you book those out October fifth and sixth, get your tickets over at pacificbitcoin dot com, use code livera for a discount. Bitcoin has grown beyond a single layer. It's a fully fledged multi-layer ecosystem. You can see the mempool, the blockchain And second layer networks like the Lightning Network over at mempool dot space. It's a comprehensive Bitcoin explorer, and you can use it as part of your navigation in the Bitcoin ecosystem. I use it all the time when I'm about to send an on-chain transaction, I like to check mempool dot space so that I can see what the prevailing, block space market is looking like, and that allows me to target my fee appropriately depending on whether I'm looking to get that transaction in into the next block or otherwise. Mempool dot space has a range of awesome features They are continually updating things. They have a block template algorithm which allows you to, sort of audit the blocks and see what transactions are being included. They have a way to visualize RBF, Replace By Fee. They have mempool blocks that are scrollable and they've got a mempool accelerator integration which is coming, so keep an eye out for this. You can find out more over at mempool dot space. And now back to the show with Bastian. Yeah. So we've spoken about the benefits of splicing. You mentioned dual funding, so can you tell us a little bit about this concept of dual funding? Well, firstly, what is dual funding, and then how are you looking to use that in Phoenix?

Okay, so it, it really looks very simple at first glance. Before dual funding, when you open a channel, only the guy who opens is able to put money into that channel, and the other one has to wait to receive payments before they have liquidity in the channel, or they have to open the channel in the other direction, which really doesn't make any sense. It, it would be much more efficient if whenever you want to open a channel, the other, know that you're opening the channel too, can also decide to put some funds in that channel in the same funding transaction. So that looks really We thought it would be done very quickly, but actually there were a lot of subtleties in that, and it was also a good opportunity to actually create a protocol for interactive transaction construction, where two or more people collaboratively create a transaction by adding inputs, adding outputs to it, which is a very nice protocol that we, that allows building some batching on top, and actually that protocol is used in dual funding and also in splicing, which means that splicing is just the same protocol as dual funding But for a channel that is already open. So it took us a lot of time to design that protocol correctly, make sure it end all batching without, creating loops where you end up not being able to complete the batch because two people are deadlocking, waiting on signatures or something like that. So there were a lot of subtleties around that that are now resolved, and dual funding, I think, is ready to be merged, we're just waiting for final internal testing between Eclair and CLN. But apart from that, the spec should be, should be final. And there are also a lot You do, how, how do you handle fees basically? Because if I want to open a dual funded channel to you, and you decide to add ten inputs to that, I'm not gonna pay for that, I'm not, because otherwise you, you could be hijacking that transaction to make other completely unrelated on-chain transaction, and I would be paying the fees on that. So the way the protocol is designed is that the initiator pays for the common fees of the common fields of the transaction, for example, the version, the end of time, they pay for their inputs and their outputs, and if the other If a peer wants to contribute to the channel, the other p-peer will pay the fees for their own inputs and outputs, so we actually split the fees between the two participants, which is, which is really nice and efficient. And also there were also issues around disconnection because before dual funding, opening a channel was not atomic but very quick. It was only one or two round trips to exchange signatures, but now that it can take a while, where you keep saying, "Oh, I want to add this input to the transaction," "Oh, let me add that one," "Oh, I want to add that output as well," it takes longer, which means there's-- it's more likely that there's gonna be a disconnection at some point. And if you are disconnected in the middle of signing the actual transaction, you won Connect and just resume that. You don't want to have to go through all those steps again to recreate again the same transaction that took you five or six round trips, for example. So we, we had to add a protocol for reconnection and resuming a signing session. So that's something that is done now, it's just waiting to be finally tested, between CLN and Eclair, but it should be working fine, and this is the, the thing we also use in Phoenix. So this is something that people will be able to build on Taproot.

I see. And so would you So to be clear, this is Eclair is the lightning implementation, you know, written and developed by your team a-at Async, and Phoenix is, let's say, the consumer-grade smartphone wallet. so are there applications there where a Phoenix user, the consumer level user, will use dual funding? Is that gonna be exposed at the user level or is it kind of all gonna happen in the background? Or what's the thinking there?

Okay, so the users aren't seeing it right now. If you, if you, for example, start with a brand new wallet and- And you just, you're just gonna initiate it by receiving on chain, then we're gonna actually use the dual funding protocol, but you're gonna be the only one-- Oh, actually no, in that case, we are gonna put some, a small amount in to make sure that we are paying the fees for the commitment transaction and everything, so we are actually needing dual funding, and, when the channel is opened, there's gonna be some liquidity on both sides, and if you receive your first payment of a lightning in that case, all the liquidity will be-- We are gonna That liquidity to you so that at the end it's the same, there's liquidity on both sides. So it's actually using dual funding under the hood, but users don't really have to think about it. But one important thing is that dual funding is also the, Stepping stone for liquidity ads. Liquidity ads is a way to open a channel to someone while requesting them to put liquidity on their side. And you have to pay for that, because if some, some random guy opens a channel to you, you have no reason to actually put liquidity on your side or allocate liquidity to that guy, because you don't know them, they're potentially a new node that has no prior activity on the network, so you have no way of knowing that this is gonna be an efficient use of your liquidity. But if that guy is ready to pay for it and, in that, in that initial funding transaction, then it makes a lot of sense, and that's what liquidity add does. It lets you tell the network, if you want me to put liquidity on your side when you open channels to me, h- here is my price, and people can just connect to you and initiate that. And that really needs dual funding because without dual funding, the guy would connect to you, open a channel, and you would open another channel to them, which really doesn't make sense from, an on-chain, efficiency. So dual funding is really For liquidity adds and for, for a lot of other protocols that we're gonna build, build on top.

I see. And so with liquidity adds, what are some of the other uses that the-- Like, so is that a, a case where Eclair users will, will see that more than the Phoenix users?

Yeah, I think so. We, because it, it's hard to know how we would use that in a wallet, because I think, I don't know if users are ready to pay something like a subscription or to see something that says, "Pay for a..." Inbound liquidity, because non-Bitcoin users don't understand the concept of inbound liquidity. If you, if you have a paying app on your phone, if you have Venmo, Paypa-PayPal or something like that, you sh- you don't think that there's any requirement on receiving money. You, you think you're just able to receive any amount of money without having to pay anything for that. And for most users, we don't want to have to explain that. We, we want them to keep having that easy UX where receiving payments just works, but it actually costs something. So

If we should educate users around that to make them understand why they would have to pay something to be able to seamlessly receive, or if we should just try to hide it as much as possible with, efficiency gains on the protocol, efficiency gains on the on-chain fees, it's really hard to tell. But on the routing node side, for a routing node that comes to the network because they have liquidity and they want to do something with that liquidity, liquidity adds is really, really makes a lot of sense because you're gonna be able to tell the whole network, "I am selling my liquidity, if you Great, here is my price. Just connect to me and ask me for, for inbound liquidity, and I'll give it to you. And this is a new, a new way to generate yield on top of the normal routing fees that, nodes are used to.

Great. And so, yeah, let's see if there's more progress on liquidity adds at, on other implementations. I know Lisa Nugget, previously at Blockstream, now at Base fifty-eight, was, obviously a, a big proponent of that, of that idea. And so you've also mentioned in the

You and the team would like to work on things like BOLT twelve and asynchronous payments. So can we get into some of those? Maybe if we could start with, your thoughts on BOLT twelve, and, you know, what would that look like if it's brought into the Phoenix app?

Yeah, so BOLT twelve is great, but BOLT twelve took a lot of time to do, to develop because the first time Rusty presented it was actually in twenty nineteen at the Berlin Lightning Round. This is really a long time ago, but the, the use case is really simple. When used to having a potentially a static address that you could put somewhere and people can pay to you and you don't have to be online to generate new addresses all the time. And Lightning invoices are one use, they're single use, and that, that's something that people have trouble understanding. And Lightning invoices are also something that you should keep private as much as possible. You should ideally not post them on Twitter because there is some information in there that could docs your privacy. So Using Bolt twelve is a way to get back to that normal Bitcoin use case where you just have a si-a single static QR code, single static offer that you can put anywhere, and it actually lets people generate, get invoices on the fly whenever they want to pay you, which is really nice, but it required a lot of changes to the protocol, a lot of complex changes because we needed a way to do messaging on Lightning, non-payed messaging that had to be really efficient to protect against DOS. This is something we call- Onion messages, it has been merged to the specification and has been fully implemented in Eclair, CLN and LDK, so th-this part is done. It also required some privacy things because we wanted to take that opportunity to make sure that we improve receiver privacy, and this thing is Blinded Path, which is a PR I wrote a bit more than three years ago and was also recently merged to the specification and fully implemented by CLN and Eclair, and is a work in progress in LDK and a work in progress in L- But the specification is final and has been agreed upon. And then on top of that, once we have those two building blocks, we're able to actually double twelve, and it is cut complete in both CLN, Eclair, and, almost LDK as well, I think. So we are really ready to do interoperability testing and start shipping that thing. But there's a big step, there's a big step between having all the code for the protocol and making it into a product and making the UX around it. So that, that's gonna be taking Some time, but that's definitely one of the main thing we want to work on in Phoenix because it's gonna be a great improvement for usability and, a lot of scenario where people are, have, are limited by what, Lightning allows them to do right now. So yeah, this is gonna be really interesting and it also lets us do a really, better Lightning address, basically a non-custodial Light-Lightning address, because the issue with Lightning address today is that people love it, it's great UX, but it is sacrificing custody and privacy. And we can do better, and, with Polt12, there's a way to make it better. So that's when we're gonna be able to add that type of feature that people are already starting to get used to. So they, they want to see that, they want to see that happen in many wallets, and we're gonna be able to do it soon.

Yeah, that's really cool to hear, because there, I think there's definitely a use there around the donation use case, because a lot of people today, maybe they're not ready to go and run BTC Pay server The other way a lot of people are going, as you said, is to use custodial Lightning addresses, which are custodial often in the Bitcoin sense, and also custodial in the sense of needing to run a web server where you're trusting, is it ICANN or what, you know, to route across the internet, and maybe there's potential for that to get hijacked. Whereas in a BOLT twelve world, maybe that would be a bit easier for users if they just have one app that they download and install, and okay, here's my QR, you can donate to me there. And it Perspective. Like, let's say we had a contact list in our Lightning wallets, Lightning apps, and, you know, I wanna donate whatever, or I wanna make a quick payment to Bastian, and here's his Bolt twelve code that I've saved into my wallet as my contact list, thing. And so I think maybe that would give people a UX that's closer to what they're used to with fiat fintech, right? Because today, with, if they've got, whatever, Cash App, Venmo, PayPal, whatever, they, they might have a contact list and say, We could start having that in just a lightning non-custodial app, so I think that would be really cool, to see. of course, I know it takes a lot of time, and I know you guys are working hard on that, but I think that would be a really cool thing, for people to, let's say, use lightning in a very frictionless way.

Yeah, because that is really convenient. That's really how you want to use any payment app. You, you have your phone, you have your list of contacts, those are people that you, you For example, or you see them in real life, you've seen them at least once to be able to set that up, and you just wanna be able to regularly send to that guy in your contact list, and you don't want to have to do that round trip where you tell them, "Oh, please, can you give me a Lightning invoice, and then I'll, I will pay it." So really, having contact, a contact list is really nice from a UX perspective, and it's something that we've wanted to do for a while, but we didn't have the right tools at the protocol

One other thing to add there, I'm just thinking out loud that ti- typically today, when you go and sign up to a service online, typically they'll ask you your name and your email, and they'll send you correspondence to that email, right? They don't think too hard about the email protocol and the SMTP and the, IMAP and all this, they just, okay, this is Bastian's email, send him an email. Maybe that's gonna be the future with Bitcoin as well. It'll be like, hey, you're signing up with us, and if we need to Boom, or if we need to, if we need to do a refund, boom, straight to your Lightning address. So maybe that's or, or your Bolt twelve in this case. And so maybe that's another way that online commerce could actually be revolutionized with Bitcoin, right? This idea that you, you don't have to do this manual dance back and forward of, oh, hey, send me an invoice for fifty thousand sats and I'll send you that. Like it might just be more like, no, give, paste your Bolt twelve and whenever we need to make a payout, boom, out

That you need to be able to receive somewhat offline. You don't, i-if you are, if you have to be online all of the time for those payments to happen, this is very limiting and the success rate is gonna be too low. So we need to be able-- and that's also something where people who are used to normal Bitcoin wallets, you don't need the recipient to be online when you're sending to them. You just send to that address, then you go offline, and when the other guy at some point comes online and the transaction has been confirmed, they get the funds. And it should feel that way in Lightning as well, and this is really hard because if you don't want to give custody of your funds, there's no such thing Bitcoin can do that because there's this Shared medium, that is the blockchain, but Lightning doesn't have that because Lightning is an entirely peer-to-peer network and there's no information that is saved globally anywhere, so we fundamentally can't recreate exactly that same experience. We need people to be able to come online to exchange signatures because that's what gives the security guarantees that Lightning offers. But we can still add a delay, and that's where asking payments when you are using LSPs come in. The, the idea is that the sender comes online To make a payment, they initiate that payment, which means they're gonna send something that goes through their LSP to the receiver's LSP, and then the receiver's LSP sees that the recipient is not online, and they're gonna be able to fail it back, but only all the way to the sender's LSP, which will not fail, fail it back to the initial sender, which will keep the HLC they have with the sender, and when the receiver's LSP sees that the receiver is online, they're gonna try to ping that receiver and notifications to make sure that the phone comes Back online, and when the fund comes back online, the receiver's LSP can send a signal back to the sender's LSP to say, "Retry that payment, this receiver is now online," and then you're gonna be able to complete that payment, and the sender has just had to come online once to send the payment, then the receiver has to come online once at another time to receive the payment, and then at some point later, the sender also has to come back online to see that the com- the payment, the payment was complete. But all of this can happen Happen asynchronously, which is really great. But same, it builds on a lot of, yeah, there's a lot of things that it needs to build on top of. So if you, if we wanna do it very correctly, we need PTLCs, we need trampoline as well to be able to do that retry efficiently without having the sender come back online, and we need somewhat reliable, notifications to make sure that the, mobile phone can be woken up and we can tell them that there's something happening. So we, we ac-- we know basically most Of, building blocks that we need to have, we just need some time to actually implement them.

Right. Yeah, that's interesting to see. And so that could also enable a whole new level of ease of use. So you mentioned pTLC and trampoline and notifications are, as required for that. is pTLC, so point time locking contracts instead of HTLCs, hash time locking contracts, is pTLC dependent on having taproot channels or are they independent?

Yeah, taproot channels This is the first step towards a PTL-C taproot channels just makes you use taproot for the funding transactions, the transactions that create, lightning channels, but doesn't use taproot yet for the payments themselves. PTL-C is the next step where we actually use taproot for the payments and music too and add, add up of signatures and all of those, those fancy things that create a larger design space basically because it will allow us to add more features to the payments themselves and it allows us to have also private- Privacy gains on the payments, but it's gonna take a while because we don't even have a security proof on the cryptographic, building blocks that we're using. For example, on adapter signatures with Music 2, there's no cryptographic proof that this is secure. We, it really looks secure, there, there should be no reason why it wouldn't be secure, but at some point we need a formal proof to make sure that we can really build on top of that. And no, no one is really using adapter, adapter signatures right now. There's not enough good support yet. Even in the cryptographic libraries that we use, and those are the things that you really wanna make sure are properly implemented and are secure, so we don't wanna rush them at all. And PTLCS is also, is also a very large change to the Lightning codebase is, because it's basically changing almost everything. We're gonna need new extensions to existing messages, we're gonna need new messages, we're gonna be, need to be using music to everywhere, which means we have to deal with complex cryptographic nuances and manage that state in a safe way. It also means that we have to change the way we make, and sign payments in a channel to a synchronous version instead of an asynchronous one, because otherwise there are some things that don't work for PLCs. It's a lot of internal details that the users don't have to see, but require a lot of protocol changes, so it will take a lot of time. We, we know that there's nothing major that is blocking, but it's gonna be a lot of work, so it's gonna take time before we get there.

Gotcha. And when it comes to, the other That I think some users may have a, a concern about or just maybe they're uncertain about this idea. When using Phoenix, the app, how much, I guess, trust are they placing in, in Async or the LSP? So for example, can Async try to cheat the user, or is there some kind of background watching app, or is there a background watching in the app that stops the user being stolen from, let's say?

Okay, so the, the trust they have is with the zero-conf part when they are receiving. funds and we are adding liquidity. When we are opening a channel or splicing on the fly, this is a zero-conf operation where we could potentially double spend it. So if users don't trust us, they should just not spend that amount yet and wait for the transaction to confirm, and then this removes the trust requirement. But it's really hard to see, and you, you receive those funds, you wanna use them. So you wanna be watching the chain, but if we double spend, you actually can't do anything about it. It's too late, you, you have lost. You, Have a proof, you can show the channel history, which will show that we actually double spent ourselves, and you can post that online so that people see that we are not trustworthy. But there is trust with zeroconf. With zeroconf, there's always gonna be trust where one side needs to trust that the other, other is not gonna double spend that transaction at some point. So this is the main trust aspect. Then on the privacy part, we are seeing the destination of your payments right now. That's also one of the other reasons we want to move to bolt twelve, because we blinded paths, that is Able to see the destinations of your payments anymore, which is a good thing. So that is really one of the big improvements with Block 12, unless you are paying Phoenix to Phoenix, because if you pay Phoenix to Phoenix, then obviously we see everything. But, but yeah, for other payments, when you are paying s-someone who isn't on Phoenix, you're gonna be able to get back, receive a, a good privacy, which is something we-- that, that's why, that's why I've been working on the Blinded Path specification, that's why This use case, and I'm really happy that it, it has been accepted and implemented in everyone else's code base, so that we can move to a world where receivers get privacy again and LSPs don't have to learn about the, the recipients of the payment they are helping, send.

I see. And so, yeah, just on that question of the Phoenix user and how much trust they're placing. So as you said, there is that trust. If, if you are using zero confirmation just in time channels, of course, the user can disable that and just say no. No, I'm just gonna wait for everything before relying on these amounts and doing payments. are they also reliant just in, in other ways or are, you know, can you, you know, can you explain for them why it is that they, you know, once, once those channels are, you know, set down on chain or is, you know, that tran- that transaction has confirmed on chain, why is that user not able to be stolen from by an outsider? Because, you know, in that case.

Because the, the Phoenix wallet is actually- Actually a full lightning node. It is actually watching the chain, it is connecting to an Electrum server, and you can point it to your own Electrum server. Because for example, if you, if you point it to our Electrum server, then we could cheat potentially. Potentially we could not tell you about the transactions that are happening. So people who don't trust us should run their own Electrum server or just connect to another Electrum server than ours, and you can just configure that in the app very easily. That means your app is constantly watching the chain in the background, as long as you At least once, I think it's every two weeks, but I, I think it's two weeks, the time out that we put. If you come online once every two week and we have tried to cheat, you're gonna be able to detect that and Phoenix is automatically going to be signing the transactions that get your funds back. And if we are publishing a revoked state, Phoenix is gonna be able to see that and actually penalize, do the penalty transactions to get all the money from the channels back because it just acts as a full node on your phone.

Back to the show in a moment. When it comes to securing your coins, it's always the rule, "Not your keys, not your coins," and CoinKite dot com can help you with this. They have an awesome range of hardware and accessories that you can use to secure your stash or to help make sure that you can recover your coins. So the Coldcard Mark IV is a fantastic device. It has multiple secure elements, and you actually need to compromise multiple parts of the device. That means the two secure elements and the microcontroller. In order to actually try and compromise and extract the seed. So the Coldcard is a really reliable and secure device, and of course, you can use it in combination with other devices as part of a multi-signature. You can use tools like a passphrase or other tools like SeedX or there's all kinds of features available there. The Coldcard is a really phenomenal device, it's really great to use. For those of you who have more than the amount that you're comfortable keeping on a smartphone, a Coldcard is a great choice for you. So go to CoinKite dot com. And get your cold card using the discount code LIVERA. And now, back to the show. Gotcha. So just to summarize, as you said, Phoenix app on your phone currently calls out to an Electrum server to understand the channel state, and if that channel state has changed in some way, in an unexpected way, as you said, the app is able to do a justice transaction, as you're saying, right? Is able to sort of claim back funds, and in that case, you know, so it's kind of like async, the company And the LSP has an incentive not to try to cheat, because obviously, y-you might lose funds that way, and the, all the users out there on their Phoenix wallet are gonna see that, because the Electrum server will warn them, because of the background watching every two weeks, right? Or at least, as long as you come online once every two weeks, you'll notice that, do a justice transaction, and, you know, Aync would lose money. I guess that's kind of the short, answer, because I've heard, you know, and the reason, obviously, I Trying to assert that it's not non-custodial, right? That you're still kind of having to trust async, but in this case, you can set up your own Electrum server, and there already are a lot of other Electrum servers, like non-async Electrum servers, that are helping you not be stolen from in this case, right?

Exactly. I, I think this is just mostly people are afraid and not understanding what's happening, and some people who don't understand what's happening are saying things that are just plain wrong and that frightens people, but this is really, your funds What's interesting is that even if you don't come back online for two weeks, we still wouldn't take the risk of cheating because if you, if you-- we can't know that you are really offline, you haven't connected to us, but you can still be monitoring the chain, and if we try to cheat, you would still penalize us. So it's really-- it would be really, really dangerous for us to try to cheat here because the Lightning protocol makes sure that if you happen to see those transactions on chain, we would be screwed. So it's really- It's really, asymmetric in that, in that sense where cheating is really dangerous on Lightning today, even if the other guy is a mobile wallet, because you have no way of knowing whether they are really offline or not. So trying to cheat on our side would be really dangerous.

Gotcha. And so when it comes to running a big node, obviously you're, you are running, well, it's probably the biggest Lightning node on the network, at least public wise, is over five hundred and twenty-nine BTC, last I checked. so what does What's it been like from your perspective as a company running that? How do you keep it safe? I mean, obviously only the element to which you're able to, you know, disclose, but obviously the, the reason-- let me just contextualize this. The reason I'm asking this is because some people say, "Oh, Lightning requires hot, you know, keys. Is that unsafe? And is that gonna be a problem for the Lightning Network broadly? How do you see that problem being solved or dealt with?"

Okay, we actually published a very long blog post about, about that on our blog, so I think r-readers should go there because this is really technical. The way we approach that is that five years ago, we started working p-people when they, Lightning is a hot wallet, so it means you, you have to be constantly signing. So this is really different from Unchained, where you can just put things on a cold wallet and not use it. But then when you start thinking about securing your keys against someone who potentially will have access to your machine, especially since we run in the cloud and pot- and some people may have access to the machine, Oh, just use an HSM. But actually, it's not that simple because in Lightning, even if you put the keys in a secure hardware, if that hardware is just blindly signing anything, you don't, you don't have any security. So that hardware actually needs to understand the Lightning protocol and understand the state of your node, the state of your channels to make sure that it, it only signs, transactions that don't steal money from you basically. So we started working on that, and we were working on prototyping that based on, ledger hardware, and at some- At some point after, I think two or even three years working on that, adding all those policies, adding all, all those code that would run inside an HSM, we realized that we ended up almost re-implementing all of Lightning inside the HSM because it really boils down to that, you realize that if you want to close all the attack vectors, all of the Lightning node kind of needs to run inside the HSM. And then we started stepping back and thinking, what if we could just take the Eclair node, the Eclair codebase, and run that entirely Inside an HSM. And there are a lot of cloud providers that have been working on that, the trusted computing thing where, yeah, they wouldn't see what you are running, they wouldn't have the ability to tamper with anything that you would do. And AWS has shipped something like that, which is called Nitro Enclaves, which runs on, on their, they've been building their custom, hardware called Nitro that is built for, for virtualization, efficient virtualization basically. And this lets-- this also let us, let them build a secure version of that where they Enable a lot of access, and that's what we've been using for, for how long? I think at least six months, a bit more than that, we've been deploying our node in that secure enclave so that in theory, no one has access to it, and access to it is secured by connecting with a custom app that we have on Ledger devices on our side. And all the details are in the blog post, so I recommend people reading about that. But that's, that's the way we protect our node today.

Great. And so kind of related, I know there's a project out there called VLS, Validating Lightning Signer. I've done an interview with that, so listeners, if you're interested, you can go back and check that episode with, Ken Sedgwick. And so just turning to Lightning more broadly, I think one other criticism that people have is that Lightning right now is very custodial. There's a lot of custodial users, and of course, you're building non-custodial, you're building self-custodial, so, you know, obviously you're, you Offer any comment on that idea that a lot of Lightning users today are custodial. Do you believe that it will remain that way?

I hope it won't. And that's why we are fighting hard to create a wallet that isn't custodial and that i-that has a good enough UX and that has fees that are as low as possible to be competitive with custodial wallets. But obviously, building a custodial thing will always gonna be easier than building a non-custodial one. So there's always gonna be a small trade-off between how much you pay And, what UX you get, but we are trying to make sure that that trade-off is as small as possible when going from non-custodial to custodial. There are use cases where non-custodial is never gonna win, for example, people who just want to play around with Lightning with a hundred sat and don't want to really use it and want to demo the, those use cases of having very small amount of money where it's not, it doesn't make sense to make the extra on-chain transaction, then you can't do anything and, custodial will win. And there Could where wallet providers could be custodial when your amounts are small and become non-custodial when the amount get bigger, but that is, that is really hard from, from a legal point of point of view because you still have to act as a custodial business, and that's not something we want to do, for example, but maybe other people are ready to, to build that kind of thing. But we, we really hope that we can make the non-custodial experience as good, but potentially a bit more, expensive, but at least as- As good as custodial, so that people really have an incentive to move to the non-custodial thing. And I, I really hope that all of the things we are learning with Phoenix, all, all of those, protocols that we are building to make, wallet users like easier, are things that we slowly add to the specification so that eventually it becomes a standard and everyone is able to use that, and more people can build wallets with different sets of trade-offs, because I think there are a lot of potential different sets of trade-offs people would want in a wallet The, they are, they are wallets that are custom for, that are better for some users and other wallets are better for some other kind of users, other profiles of users, and I hope that we soon get a world where there's a large enough choice of non-custodial lightning wallets that work well, that have all the services that a user may need to be able to have a good UX and aren't too expensive compared to custodial ones, because otherwise, if, if everyone is using custodial lightning Then it's not really Lightning and it's not really Bitcoin. It's, it's not your keys and you're always in danger of, of the other guy just running away with the money. And that's not something we want to encourage.

On a related note, it's probably fair to say that we should expect fees to rise over time. Now, maybe that's also an open question, but I, I'm probably more on the side that I think fees will rise over time. You know, who knows when? But, you know, what, what typically happens is you get these big bull

And the fees rise at the same time. And so in that scenario, do you think Phoenix can sort of handle that case where, let's say, I mean, just, just to pick numbers, let's say, you know, to go on chain it costs, you know, twenty dollars or wh- whatever that is, maybe seventy thousand satoshis or something like that. Would that make the non-custodial wallet model, you know, difficult to use? Or do you think that maybe in that environment, more people are going to be on Lightning per se so they don't have to? Go to chain as often. Do you have any views on that?

Okay, so what happens to Lightning when the unchain fees are consistently high is really complex because the issue is that if something isn't, if you have a ten thousand satoshi xPub and the unchain fees are seven, seventy thousand sats, it doesn't even make sense to claim that unchain. So if you have to post those and go unchain, then nobody has any incentive to claim that. You, you would just let it go to the miners or wait for the unchain to- To drop back so that someone can claim it, and at that point it could be either peer because the HLC has timed out, so it doesn't become trusted, but it becomes, yeah, it's-- I, I don't think there's a word for that, but, you, you're not trusting your other peer not to cheat, but nobody has an incentive to go and chain because everyone lose, loses potentially, and things, and most HLCs just end up being trimmed and just go to the miners if they're, if they aren't used, and every, everything goes to un When that happens, both sides of the channel really have an incentive to keep going in Lightning and never go on chain. But if something happens or if one of the guys wants to cheat or just grief the other guy, because if you go on chain, it would more be like griefing than actually you could steal funds potentially, but it's mostly a griefing attack, and this could be really annoying and this could be really bad for the usability of the network, and it's really hard to know how people will behave when that, when that kind of things happen. And that's why It's really tough because Lightning wants to abstract away from the unchained fees, but actually you can't really, because you still need to use the blockchain as a settlement court. So you still need to potentially, if you want to make sure that you, you really get your funds back, or you implement some kind of scorched earth scenario to make sure that people, if they try to brief you, you're gonna lose money, but they won't win, it really becomes nasty. So it's really hard to say how it will happen. We hope that the unchained fee rate is It's gonna be fluctuating a lot so that there's always opportunities to get things confirmed at a low enough or acceptable enough fee rate. But if it is consistently high, yeah, it's really harder to define exactly where the trust requirements are in Lightning.

Yeah, I think that's fair. And let's see if other future technology, helps with that. Also related, there has been a bit more discussion about APO, any prevout. I know a lot of Lightning developers, especially protocol developers are Really interested in this, wanted to get your take on APO, and, you know, are you pro APO? What do you see as the benefits? You know, why should people think about APO?

Yeah, I, I am pro anything that would let us have a better lightning, a better, more efficient way and more simpler way of, of doing, layer two protocols on top of Bitcoin. So we know that we need some form of covenant there. We are eventually gonna need that, and I think most people agree that at some point we need It's hard to decide which solution is the best because we don't want to create too many soft forks that actually achieve the same thing or realize six months after a soft fork that there was a better way of doing this. But I think there's also been a lot of research and a lot of discussions around that design space for the past year or two years. It's really, it's always hard to push for a soft fork. It's always hard to, especially one like that that is kind of open-ended where you don't know exactly all the things that you're gonna be able to do With that, but in a way, that's the same with Taproot, you don't know how people will, use Taproot and those, those, tap, tap script trees, potentially in ways that you didn't expect. But of course, really create a much larger design space. I think they're necessary, I think they're useful, and I think that APO is a quite simple and elegant solution that, at least for Lightning, gets us exactly what we need to be able to build, a better Lightning, ba-basically. So I'm really pro APO With anything else that would let us build something like L2 and that would let also other layer two developers or other people who work on coin pools or, any other kind of, layer two thing that help Bitcoin scalability. Whatever works for all those, for all those use cases, I'd be happy with if we get one, and I hope that we make progress on some sub fork coming in the future that adds some kind of covenant. And many people are pushing for that. I am pro, pro that, effort. But yeah, my, my voice doesn't count in, in any way, but I, I, I still support that, and I think it, it's gonna be useful for Bitcoin as a whole.

And, you know, just speaking off the cuff, if you have any ideas on what Could be improved in the Phoenix or Async experience. Like, let's say we wa- we waved our magic wand and we had APO and, there was work being done to bring LN symmetry or L2 to the network, what kind of benefits do you think that would bring for you from a Phoenix or Async perspective?

Mostly simplicity. It really simplifies a lot the protocol and something that is simpler is actually easier to secure. So Lightning is really complex, there are a lot of potentially secure security issues It's also very complex to build on Taproot because there's a lot of code and a lot of complex protocols, so whatever we can do to make it simpler and more efficient is really worth it. And L2 is a good way of achieving that. It makes it, it makes, it really simplifies the protocol, it makes it, it makes it also cleaner from an architectural point of view, so it's gonna be easier to build, PTLC related things on top of L2 as well than on top of the current, and, Symmetric protocol. So really towards getting a cleaner protocol, easier to understand, more secure, more efficient. It's, it's a lot of gains.

Okay, great. and so just looking out more broadly, what do you see as the biggest hurdles, the biggest challenges, in developing, Lightning and Bitcoin applications, just more broadly?

I think we're in a good state where it's becoming easier and easier, and the abstractions are getting Getting better, the protocol is getting better so that people can start build-building rely-reliably on top of it. I think that the, the main issue for Bitcoin and Lightning development is funding, is getting people, is getting a business model that lets you get funding to actually build a product, because all of those things that we build in, in this open source fashion, in a pure open and decentralized network, we're building them so that there's no lock-in. So th-this isn't something that VC-VCs tend to- Like lock in, because the, if you tell your VC's, "I'm getting a lot of users and they are locked into my platform," that's what guarantees that you're gonna be able to make money. But we're actually doing the opposite. We're building something where we don't want any kind of lock in, and we want users to be able to choose the best thing that fits their needs. So it's gonna, it's really always gonna be hard to monetize that. The goal is to still make it as viable as possible so that people can still run a business and, be Much harder than regular SaaS technology project to get funding for. So I think that's the main reason why we are lacking some projects is that it's really hard to make sure that people can build a team, spend years and years operating and building that thing because all, all of those things take so much time to build that you need to be sure that you have enough money to build it all the way to the, to, to when you're ready to get it into the hands of end users. So that, that's in my- In my opinion, the main, the main issue, the hardest thing to solve, and it's non-technical, but it's really the hardest thing to solve in the Bitcoin environment as a whole.

Gotcha. And so just to finish off, is there anything on a positive note you wanna mention, about where things are going, Bitcoin and Lightning-wise? What are you, what makes you excited about building in Lightning?

It's really been an interesting year, and I think the next year is gonna be really interesting because it looks like we spent years talking about a lot of features that are big Dual fundings, placing, bold twelve, taproot, pTLCS, all of those things, we've been talking about them for, for some of them five, six years, and this is actually really-- we are, we are shipping those things now. It took a while, it took really a while to converge on what the exact protocol would look like and, what the issues were, how to fix all the potential security issues, how to work with the also layer one developers to make sure that the mem- Pool was more flexible to make sure that Lightning was secure. All of those things take a lot of time, but this is really we're, we're at an exciting time where we are finishing a lot of those features and everything is starting to converge and people, all the implementations are working on almost all of those features at a different pace and with different priorities, but we are all converging towards kind of a new version of Lightning with a lot of these new features that will really make it more efficient, more reliable, more- More secure, easier to use. So it's really exciting to see all of those things actually happening.

Yeah, that's great to see. I like what you guys are doing. Of course, it's very easy to build custodial things, but you've actually taken the hard path of trying to help people use self-custodial things. And I like that the Phoenix wallet is making it really easy for people to not have to think about lightning. So if you're just a regular consumer who just needs to use a wallet on your phone and you don't wanna think about on-chain or off-chain, Phoenix Lightning actually really makes that quite easy because of the splicing and because of some of these new features you're talking about. So, you know, hope you, hope you guys, keep doing well and I hope people out there actually think about, giving, giving it a go. And yeah, that's, pretty much a good spot to finish up there. So, Bastian, thank you for joining me today.

Thanks for having me. That was really great.

So what do you think about Phoenix? Give it a try. I'm a fan of the wallet because they really make it easy and simple for a non-custodial user experience that allows you to simply merge the on-chain and off-chain worlds of Bitcoin. So give it a try and let me know what you think. Find the show notes over at stephanlivera.com/513 and I will see you in the citadels.