The next generation of Bitcoin Lightning wallets is here with Phoenix from ACINQ. Rejoining me is CTO of ACINQ, Bastien Teinturier to talk about how the team is innovating a great self custodial experience for bitcoin and lightning users:

• High Fee environment
• New Phoenix fee structure
• Splicing and what it enables
• Dual Funding
• Liquidity Ads
• Building on a smartphone app
• Can ACINQ steal from users? 
• APO
• Biggest challenges
• Reasons to be optimistic

Links:

• Twitter: @realtbast 
• Phoenix Splicing Update post

Sponsors:

• Pacific Bitcoin Festival (code LIVERA)
• CoinKite.com (code LIVERA)
• Mempool.space

Stephan Livera links:

• Follow me on Twitter @stephanlivera
• Subscribe to the podcast

Podcast Transcripts:

Stephan (00:00.638)
Okay Bastion, welcome back to the show.

Bastien (00:03.122)
Hey Stephan, thanks for having me, glad to be here.

Stephan (00:05.758)
Yeah, it’s been a while since we last spoke and I know you are now CTO over at Async. 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 a very 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, 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?

Bastien (00:55.93)
Okay, so the thing that decided our priority was the high fee event that was caused by all the 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 some outputs to fix that. But then 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 we’re at the right time to build tooling and to build features that would make us more resilient to 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 were working on dual funding and splicing.

which are really important tools to make sure that you are more efficient with the transactions, the on-chain transactions 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 user, that means you are using a lot of UTXOs per user, and when that user disappears and you have to close those channels, this is going to cost a lot of on-chain fees if the on-chain fees are high.

And this is something that could make you potentially go out of business if you are 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.

Stephan (02:41.278)
Yeah, that’s interesting. I noticed in the prior version of Phoenix, I had, I think I had maybe 11 or 12 channels, right? And so you think about that, that’s 12 UTXOs just for one person. And now of course I’m running on the new splicing version that you have. So now I have one channel and one UTXO. So I think that’s kind of an obvious one. That’s like on 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?

Bastien (03:20.074)
Okay, for example, we have some users, depending on what your usage pattern in Lightning is, if you are, for example, only receiving all the time and not spending much, you just end up getting more inbound liquidity added all the time, which requires an unchanged transaction, and without splicing in the previous version of Phoenix, we would open a new channel every time. So some users end up with 100 channels. And 100 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 force close a hundred channels That means getting a hundred commitment transactions on chain commitment transactions are big because they are spending a two of two multi-seg So they have an expensive witness So that really has a high cost on VLSP 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 are able to give users for 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 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 a channel. But eventually the channel is going to get bigger and bigger and bigger. And when they start spending that amount, then they’re going to be able to receive without making unchanged transactions because they will have a big channel with liquidity on both sides.

we now have only one potential channel to force close, even if the channel sizes shrinks and grows, it means we know that we only have one commitment 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’s why all of those placing transactions, when they happen, we do not 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 async on all those places.

Stephan (05:15.362)
Gotcha, and as I understand the, 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 blog post in 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 whatever the on-chain fees are plus 0.4% on the outgoing Lightning sending. Whereas historically you would have had, I think it was like a 1%…

Bastien (05:15.974)
So yeah, I think it’s a win.

Bastien (05:42.206)
Exactly.

Stephan (05:45.25)
fee on the incoming in order to swap that on-chain amount into Lightning. So I guess that’s, you know, depending on how you use Phoenix, it could be a big drop in your fees, but maybe some users on the other hand will say, oh look, I could get it much cheaper by doing my own Lightning node and all that, but of course I understand Essinc 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 fees?

and how people have been reacting in your experience or in your discussions with customers or users.

Bastien (06:19.742)
Yes, it’s exactly what you described. And what’s interesting is that we added a feature inside Phoenix where you can set your fee ceiling. Whenever the fees are gonna be higher than that fee ceiling that you decided, we’re just not gonna do that on-chain operation. And you’re just gonna see a notification saying that something had happened, we potentially needed to create, to do a splice for you to receive some payment, but we didn’t do it because the on-chain fees were higher. And similarly, when you are swapping funds in, you’re gonna send on-chain money

your Phoenix wallet but then if the current on-chain fee rate is too high to complete that splice and add those funds into the channel it’s just going to sit there. We’re going to tell you that you have pending swap-ins, pending splicing but since the fee rate is currently high you can just keep accumulating them in your on-chain Phoenix wallet and when the fees are going to 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 have the ability to configure the maximum fees you’re gonna pay, so you shouldn’t be surprised by that. Whereas before, 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 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 non-custodial, non-trusted, you don’t even have to trust us with zero conf anymore. And everything that happens is something that you control. You can swap in and entirely control that without any trust in us. And if you disable the automatic on the fly splicing, then there’s absolutely no trust between you and us, which is really nice for some users. Even though that means you have to manage liquidity yourself a bit more, and 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.

Stephan (08:24.642)
Gotcha. Okay.

Bastien (08:42.558)
then that’s better, just do that and 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.

Stephan (08:57.954)
Gotcha. So just to summarize a little bit what’s going on there, 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 12 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,

certain level, let’s say 5,000 SATs or 1,000 SATs or whatever the level you set, then only then it is those on-chain amounts 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. Okay.

Bastien (09:43.114)
Exactly. Yeah, exactly. And also 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 is not, we don’t recommend reusing addresses, even though users, we cannot prevent users from still sending to the same address, even if we rotate it every time you show one, but we’re gonna rotate that address soon. But even though rotating it without Taproot doesn’t give you much privacy because it is still.

You can still see that this is going to be spliced into a channel, it’s still sending to the same address, so 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 get us better privacy.

Stephan (10:26.594)
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 sats a byte, but they sent it at two sats a byte, and you’re kind of then stuck, right?

Bastien (11:02.99)
That is going to be hard. It’s better if the sender does RBF here, or if they do CPFP on the change output, because that address is actually a Swap-In Potential address. It’s a two of two between your Phoenix wallet and Async, which means that we are first waiting for that first transaction to confirm. And when it is confirmed, we can then trustlessly use zero-conf to space it into a 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 signed by both Async 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 all do CPFP on that 2 of 2 address.

Stephan (11:32.635)
I see.

Stephan (11:51.718)
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 for 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, you know, over lightning or actually even that might not because 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 it sort of works better for a regular spender than for like a regular receiver? Is that fair to say?

Bastien (12:43.046)
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 going to have inbound liquidity issues. And Lightning is not 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 even if you want to spend more than you actually receive, that case can be handled by swapping.

swapping funds in from Unchain so you can keep sending and sending and sending and you only have to pay the Unchain 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 want to be able to receive mostly what you should do is first receive a big amount once so that you have a big enough channel and then you should swap funds out with Submarine Swap.

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 their 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 basically here, but you just need to automate them and have more sub-marine swap providers on the network.

Stephan (14:20.142)
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, um, your sat and then you’re, occasionally you’re spending them on, you know, your bills or other things, whether that’s, you know, going to bit refill or whatever else. And so then you’ve kind of got a bit of a balanced flow there. Um, but otherwise it works well in the case where let’s say you are

Let’s say you receive 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. Whereas it’s obviously, yeah. Gotcha.

Bastien (14:55.494)
Yeah, and then you can receive off-chain after that. Yeah, after spending, you can receive on-chain, so you should try to keep that kind of flow going as much as possible, where you receive, for example, your salary, this creates a, this makes sure that you have a big enough channel, then you’re gonna spend your salary while the weeks 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’s the money that…

you still have at the end of the 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.

Stephan (15:33.602)
Gotcha. Yeah. And then I guess from an LSP perspective, right, from Async’s perspective, if that user leaves a very big amount inbound, is that kind of an ongoing cost for you guys? Because you’re still maintaining that channel. But I guess, as I’m understanding it, it means basically the business model is that you need those users to be spending enough and earning enough out of their spending fee, which is a 0.4%. So let’s say you’re spending $1,000, that’s a $4 transaction fee.

Basically, the model then is that you need to make enough out of them spending there. And you know what? For them, convenience factor may justify that, right? Is that kind of the right understanding there?

Bastien (16:14.578)
Yeah, 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 to stack. 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 it’s liquidity that we could allocate elsewhere so that it’s used more efficiently and we’re not getting paid for that liquidity right 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 funds out of a channel where they are idle and into a channel where 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 going to be… Your revenue is always going to be low. You’re not going to be able to make a huge profit because someone else is going to be able to come in. So you need to make sure that your costs are as low as possible. And the people who are going to be able to survive are the people who are going to be able to move their liquidity around.

at the lowest cost possible. So you really need to have splicing, which allows batching, which will let you take, for example, five or 10 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 example, and there’s not a lot of demand.

Bastien (18:36.266)
for block space, the Lightning Service Providers are going to be the buyers for that block space because it is at a discounted rate and they will jump in to do all of their on-chain transactions, all of their splices whenever the fee rate gets low enough. Which is really nice as well because it smooths the fee rate curve 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 more people are going to be using 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.

Stephan (19:29.098)
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 when it goes below whatever, 3000 Sats 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. I earn and spend Bitcoin as many times as I can. I love to show it to people. I did a video recently 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 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 think, it’s a pretty cool approach that you’ve got here because you have slicing, whereas historically, it would have been a big fee to kind of take your full salary into the Phoenix wallet because you would have been paying 1% 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 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 live on Lightning, let’s say, because currently 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,

Stephan (21:43.682)
then we start to actually get more efficiencies because now you might only need to do one or two on-chain transactions and do like 20 or 30 off-chain transactions like with Lightning. So I think that’s an interesting angle of kind of where things are going with the Mempool and with blockchain usage. Do you have anything else you wanna add on that before we move on?

Bastien (21:53.266)
Thank you.

Bastien (22:03.75)
Yeah, also it really helps people don’t realize it because 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 10 channels It’s really hard to tell the user how much they can receive without an unchain 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 do not know that. They don’t have this information. And this is also dynamic information that can change over time. So usually senders are not able to respect that split. So when people try to receive the maximum amount that they think they can receive only in Lightning, 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 splicing, since you have only one channel, 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 on-chain 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’re gonna be able to make it more easy to understand for users.

Stephan (23:49.07)
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 and be like, oh, hey, there’s these 50 users who are not using the capacity 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 splicing?

Bastien (24:25.17)
Yeah, there are a lot of things you can do. And even if you forget the wallet use case for just routing nodes, your routing node, 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 is not predictive of the future because the flows on the network are changing a lot and you cannot just think that this is always going to 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 is doing a lot of splicing activity, you could also be coordinating a coin join, or you could also 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-chain privacy, and much more efficient as well, because you are making only one transaction instead of several.

Stephan (25:45.606)
And so, 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?

Bastien (26:01.766)
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 a channel in the other direction, which really doesn’t make any sense. It would be much more efficient if whenever you want to open a channel, the other node that you are opening, that channel 2, can also decide to put some funds in that channel, in the same funding transaction.

So that was really simple and 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 allows building some batching on top and that 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 ended up 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 are now resolved and dual funding, I think is ready to be merged. We’re just waiting for final interop testing between Eclair and CLN. But apart from that, the spec should be final. And…

There are also a lot of edge cases around what do you do, how do you handle fees basically, because if I want to open a dual-threaded channel to you and you decide to add 10 inputs to that, I’m not gonna pay for that. I’m not because otherwise you could be hijacking that transaction to make over 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 a common field of a transaction. For example, the version, the end lock time.

they pay for their inputs and their outputs, and if the other peer wants to contribute to the channel, the other peer will pay the fees for their own inputs and outputs. So we actually split the fees between the two participants, 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.

Bastien (28:24.178)
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 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 wanna be able to reconnect 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 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 thing we also use in Phoenix. So this is something that people will be able to build on top of.

Stephan (29:11.602)
I see. And so would you say then, so to be clear, this is, Eclair is the lightning implementation, you know, written and developed by your team 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 going to be exposed at the user level, or is it kind of all going to happen in the background? Or what’s the thinking there?

Bastien (29:38.878)
Okay, so the users are not seeing it right now. If you, for example, start with a brand new wallet and 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 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 over Lightning in that case, all the liquidity will be… We are going to be the only one funding that transaction and then pushing that liquidity to you so that at the end it’s the same as 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 random guy opens a channel to you, you have no reason to actually put liquidity on your side that 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 initial funding transaction, then it makes a lot of sense. And that’s what liquidity add does.

tell the network, if you want me to put liquidity on your side when you open channels to me, 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 unchain efficiency. So dual funding is really one of the prerequisites for liquidity ads and for a lot of other protocols that we’re going to build on top.

Stephan (31:36.102)
I see. And so with liquidity ads, what are some of the other uses that the like, so is that a case where Eclair users will see that more than the Phoenix users?

Bastien (31:52.942)
Yeah, I think so. Because 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 inbound liquidity because non-bitcoin users don’t understand the concept of inbound liquidity. If you have a paying app on your phone, if you have Venmo, PayPal or something like that, you don’t think that there’s any requirement on receiving money. 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 want them to keep having that easy UX where receiving payments just works, but it actually costs something. So we don’t know if users are going to be ready to, 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 really makes a lot of sense because you’re going to be able to tell the whole network, I am selling my liquidity. If you want to buy it, here is my price, just connect to me and ask me for inbound liquidity and I’ll give it to you. And this is a new way to generate yield on top of a normal routing fees that nodes are used to.

Stephan (33:20.086)
Great. And so, yeah, let’s see if there’s more progress on liquidity ads on other implementations. I know Lisa Nugget, previously at Blockstream, now at Base58, was obviously a big proponent of that idea. And so you’ve also mentioned in the blog post some future ideas on things that you and the team would like to work on, things like BOLT 12 and asynchronous payments. So can we get into some of those? Maybe if we could start with your thoughts on BOLT 12.

And what would that look like if it’s brought into the Phoenix app?

Bastien (33:53.734)
Yeah, so Boltwell is great, but Boltwell took a lot of time to develop because the first time Rusty presented it was actually in 2019 at the Berlin Lightning Gondf. This is really a long time ago, but the use case is really simple. When you are used to using Bitcoin, you are used to having 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, are single use, and 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 dox your privacy. So using Vault12 is a way to get back to that normal Bitcoin use case where you just have a single static QR code, single static offer that you can put anywhere and it actually

generate, get invoices on the fly whenever they want to pay you, which is really nice, but it requires a lot of changes to the protocol, a lot of complex changes, because we need a way to do messaging on Lightning, non-paid messaging that had to be really efficient to protect against us. 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 this part is done. It also requires 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 LND 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 do Vault 12 and it is quite 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’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.

Bastien (36:18.266)
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 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 Ball 12, 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 want to see that. They want to see that happen in many wallets. And we’re gonna be able to do it soon.

Stephan (36:52.958)
Yeah, that’s really cool to hear because 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 and have an actual web server running to take donations. 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 12 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 could also be interesting from a contact list perspective. Like let’s say we had a contact list in our lightning wallets, lightning apps. And you know, I want to donate whatever, I want to make a quick payment to Bastion and here’s his bolt 12 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, if they’ve got whatever, Cash App, Venmo, PayPal, whatever, they might have a contact list and say, oh, just pay $100 or pay $50 to this person for that. 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.

Bastien (38:27.93)
Yeah, because that is really convenient. That’s really how you want to use any payment app. You have your phone, you have your list of contacts. Those are people that you know and trust. You have seen them, you know their mobile phone number, 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 want to 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 will pay it.

So really having 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 level to be able to do it right. But soon we’re gonna be able to do it right.

Stephan (39:07.754)
Yeah. One other thing to add there. I’m just thinking out loud that 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 your 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 Bastien’s email. Send him an email. Maybe that’s going to be the future with Bitcoin as well. It’ll be like, Hey, you’re signing up with us and if we need to make a payout,

post here your BOLT 12 or your Lightning address. And when we need to make payouts to you, boom. Or if we need to do a refund, boom, straight to your Lightning address. So maybe that’s, or your BOLT 12 in this case. And so maybe that’s another way that online commerce could actually be revolutionized with Bitcoin, right? This idea that you don’t have to do this manual dance back and forward of, oh, hey, send me an invoice for 50,000 Sats and I’ll send you that. It might just be more like, no.

paste your Bolt 12 and whenever we need to make a payout, boom, out it goes.

Bastien (40:09.242)
Yeah exactly and that is it too. The other thing that we need to fix is that you need to be able to receive somewhat offline. You don’t… 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 going to 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 be that way, or at least 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 cannot recreate exactly that same experience. We need people.

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 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 it back to the initial sender, which will keep the HTLC 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, send notifications to make sure that the phone comes back online. And when the phone comes back online, the receiver’s LSP can send the 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 payment was complete. But all of this can 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 want to do it…

Bastien (42:34.93)
Very correctly, we need PTLCs. We need TrampleIn 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 know basically most of the building blocks that we need to have. We just need some time to actually implement them.

Stephan (43:02.414)
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?

Bastien (43:28.998)
Yeah, Taproot Channels is the first step towards PTLC. Taproot Channels just makes you use Taproot for the funding transactions, the transactions that create lighting channels, but doesn’t use Taproot yet for the payments themselves. PTLC is the next step where we actually use Taproot for the payments and Music2 and adapter signatures and all of 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 privacy gains on the payments. But it’s going to take a while because we don’t even have a security proof on the cryptographic building blocks that we’re using. For example, adapter signatures with Music 2, there’s no cryptographic proof that this is secure. We… It really looks secure. 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 one is really using 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 want to make sure are properly implemented and are secure so we don’t want to rush them at all. And PTLC is also a very large change to the Lightning code basis because it’s basically changing almost everything.

new extensions to existing messages, we’re gonna need new messages, we’re gonna need to be using music to everywhere, which means we have to deal with complex cryptographic nonces 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 PTRCs. It’s a lot of internal details that the users don’t have to see, but require a lot of protocol changes.

So we’ll take a lot of time. 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.

Stephan (45:28.59)
Gotcha. And when it comes to the other aspect that I think some users may have 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?

Is there a background watching in the app that stops the user being stolen from, let’s say?

Bastien (46:00.582)
Okay, so 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 receive those funds, you want to use them. So…

You want to be watching the chain, but if we double spend, you actually cannot do anything about it. It’s too late, 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 trust worthy. But there is trust with zero count. With zero count, there’s always going to be trust where one side needs to trust that the other is not going to 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 12, because we blinded paths that is gonna change. We’re not gonna be able to see the destinations of your payments anymore, which is a good thing. So that is really one of the big improvements with BOLT 12. Unless you are paying Phoenix to Phoenix, because if you pay Phoenix to Phoenix, then obviously we see everything. But yeah, for other payments, when you are paying someone who is not on Phoenix, you’re gonna be able to get back a receiver.

good privacy, which is something we… That’s why I’ve been working on the blinded path specification. That’s why I have pushed for that for three years because this was fixing this use case. And I’m really happy that 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 recipients of the payment they are helping send.

Stephan (47:52.974)
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 you are using zero confirmation just in time channels. Of course, the user can disable that and just say, no, I’m just going to wait for everything before relying on these amounts and doing payments. Are they also reliant just in other ways? Or, 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, you know, 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.

Bastien (48:37.054)
Because the Defenix wallet is 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 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 do not 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 come online at least once, I think it’s every two weeks, but I think it’s two weeks, the timeout that we put. If you come online once every two weeks 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, due to penalty transactions to get all the money from the channels back because it just acts.

as a full node on your phone.

Stephan (49:37.698)
Gotcha. So just to summarize, as you said, Phoenix app on your phone currently calls out to an electronic 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? It’s 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

Bastien (49:57.201)
Exactly.

Stephan (50:06.938)
you might lose funds that way. And all the users out there on their Phoenix wallet are gonna see that because the Electron 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 async would lose money. I guess that’s kind of the short answer because I’ve heard, and the reason, obviously I have some base awareness of this, but I wanted to ask this just because I think some users or maybe some people out there are sort of trying to assert that it’s

Bastien (50:18.218)
Mm-hmm.

Stephan (50:36.486)
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?

Bastien (50:42.813)
on.

Bastien (50:50.914)
Exactly, 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 friends are really safe and even 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 cannot 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 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 asymmetric 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.

Stephan (51:53.718)
Gotcha. And so when it comes to running a big node, obviously you are running, well, it’s probably the biggest lightning node on the network, at least public wise, is over 529 BTC last I checked. So what has 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 disclose, but obviously the reason, let me just contextualize this. The reason I’m asking this is because some people say,

Lightning requires hot 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?

Bastien (52:37.45)
Okay, we actually published a very long blog post about that on our blog, so I think readers should go there because this is really technical. The way we approach that is that five years ago, we started working… People when they… Lightning is a hot wallet, so it means you have to be constantly signing. So this is really different from Unchain 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 some people may have access to the machine, you think, 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 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 only signs.

transactions that do not 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 point after I think two or even three years working on that adding all those policies adding 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

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 code base and run that entirely inside an HSM. And there are a lot of cloud providers that have been working on that trusted computing thing where yet they wouldn’t see what you are running, they would not 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 their custom hardware called Nitro that is built for efficient virtualization basically and this also let them build a secure version of that where they disable 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

Bastien (54:57.854)
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 the way we protect our node today.

Stephan (55:10.154)
Right, and so kind of related, I know there’s a project out there called VLS, Validating Lightning Sign-off. 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 trying to fix that, but can 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?

Bastien (55:51.13)
I hope it won’t, that’s why we are fighting hard to create a wallet that is non-custodial and 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 going to be easier than building a non-custodial one, so there’s always going to be a small trade-off between how much you pay and what UX you get, but we are trying to make sure 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 those use cases of having very small amount of money where it doesn’t make sense to make the actual unchange transaction, then you cannot do anything and a custodial will win. And there are models where people could, where wallet providers could be…

Custodial when your amounts are small and become non-custodial when the amount gets bigger, but that is really hard from From a legal 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 build that kind of thing, but we really hope that we can make the non-custodial experience as Good, but potentially a bit more Expensive but at least as good as custodial

so that people really have an incentive to move to the non-custodial thing. And I really hope that all of the things we are learning with Phoenix, all of those protocols that we are building to make wallet users’ lives 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. There are wallets that are custom, 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 lighting wallets that work well, that have all the services that a user may need to be able to have a good UX and are not too expensive compared to custodial ones.

Bastien (58:12.85)
Because always, if everyone is using Custodial Lightning, then it’s not really Lightning and it’s not really Bitcoin. It’s not your keys and you’re always in danger of the other guy just running away with the money. And that’s not something we want to encourage.

Stephan (58:29.362)
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’m probably more on the side that I think fees will rise over time. Who knows when, but what typically happens is you get these big bull runs and maybe Bitcoin goes five or 10x the price and the fees rise at the same time. And so in that scenario, do you think Phoenix and…

Well, do you think Phoenix can sort of handle that case where, let’s say, I mean, just to pick numbers, let’s say, you know, to go on chain, it costs, you know, $20 or whatever that is, maybe 70,000 sats or something like that. Would that be, 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?

Bastien (59:30.634)
Okay, so what happens to Lightning when the on-chain fees are consistently high is really complex because the issue is that if something is not… If you have a 10,000 SAT HTLC and the on-chain fees are 70,000 SATs, it doesn’t even make sense to claim that on-chain. So if you have to force-close and go on-chain, then nobody has any incentive to claim that.

you would just let it go to the miners or wait for the onchain 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…

Bastien (01:00:12.538)
Yeah, I don’t think there’s a word for that, but you’re not trusting your other peer not to cheat, but nobody has an incentive to go on chain because everyone loses potentially. And things, and most HLCs just end up being trimmed and just go to the miners if they are unused, and everything goes to on-chain fees. So 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 kind of things happen and that’s why it’s really tough because lightning wants to abstract away from the on chain 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 really get your funds back or you implement some kind of scorched earth scenario to make sure that people, if they try to grief 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 on-chain fee rate is gonna be fluid.

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

Stephan (01:01:49.238)
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, AnyProvOut. I know a lot of Lightning developers, especially protocol developers, are really interested in this. Wanted to get your take on APO. And are you pro-APO? What do you see as the benefits? Why should people think about APO?

Bastien (01:02:18.566)
Yeah, I am pro anything that would let us have a better lightning, a better, more efficient way, and more simpler way of doing layer 2 protocols on top of Bitcoin. So we know that we need some form of covenant there. We are eventually going to need that. And I think most people agree that at some point we need one. It’s just 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 is kind of open-ended where you don’t know exactly all the things that you’re going to 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, uh, Tabscript trees.

potentially in ways that you didn’t expect. But covenants 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, basically. So I’m really pro-APO, but I would be happy with anything else that would let us build something like L2.

and that would let also other layer 2 developers or other people who work on coin pools or any other kind of layer 2 thing that helps Bitcoin scalability, whatever works for all those use cases, I’d be happy with if we get one. And I hope that we make progress on some soft fork coming in the future that adds some kind of covenant. And many people are pushing for that. I am pro…

that effort but yeah my voice doesn’t count in any way but I still support that and I think it’s gonna be useful for Bitcoin as a whole.

Stephan (01:04:25.706)
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 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?

Bastien (01:04:47.11)
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 security issues.

It’s also very complex to build on top of 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, it really simplifies the protocol. It makes it, it makes it also cleaner from an architectural point of view. So it’s going to be easier to build a PTC related things on top of L2 as well than on top of current LN.

asymmetric protocol. So really towards getting a cleaner protocol, easier to understand, more secure, more efficient, it’s a lot of gains.

Stephan (01:05:43.63)
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.

Bastien (01:06:01.13)
I think we’re in a good state where it’s becoming easier and easier and the abstractions are getting better, the protocol is getting better so that people can start building reliably on top of it. I think that the main issue for Bitcoin and Lightning development is funding. It’s getting a business model that lets you get funding to actually build that product because all of those things that we build in this open source fashion, in a pure open and decentralized network,

We’re building them so that there’s no lock-in. So this is not something that VCs, you tend to like lock-in because if you tell your VCs, 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 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 able to operate without losing money. But it still makes it 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 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 when you’re ready to get it into the hands of end users. So that’s in my opinion 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.

Stephan (01:07:46.954)
Gotcha. And so just to finish off, is there anything on a positive note you want to mention about where things are going Bitcoin or Lightning wise? What makes you excited about building in Lightning?

Bastien (01:07:57.862)
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 and complex dual funding, splicing, ball 12, taproot, ptlcs, all of those things we’ve been talking about them for some of them 5-6 years and this is actually really… 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 1 developers to make sure that the mempool 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 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 secure, easier to use. So it’s really exciting to see all of those things actually happening.

Stephan (01:09:17.45)
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 want to think about on-chain or off-chain, Phoenix 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, I hope you, I hope you guys keep doing well and I hope people out there actually think about giving a, giving it a go and yeah, that’s pretty much a good spot to finish up there. So Bastien, thank you for joining me today.

Bastien (01:09:58.794)
Thanks for having me, that was really great.