support dispatch: https://citadeldispatch.com/donate
EPISODE: 123
BLOCK: 837415
PRICE: 1530 sats per dollar
TOPICS: self custody lightning, tradeoffs, fee burden education, full stack integration, bolt12, future plans
project website: https://phoenix.acinq.co/
website: https://citadeldispatch.com
nostr live chat: https://citadeldispatch.com/stream
nostr account: https://primal.net/odell
youtube: https://www.youtube.com/@citadeldispatch
stream sats to the show: https://www.fountain.fm/
(00:00:02) CNBC Intro
(00:02:08) Introduction to Citadel Dispatch podcast
(00:49:43) Nostr Wallet Connect
(00:51:52) Using Nostr Wallet Connect for subscriptions and setting up payment thresholds
(00:52:23) Bolt12 and its major milestone in creating a static address for receiving lightning payments
(00:57:13) Phoenix Server and its ease of use for developers to build lightning-connected services
(01:09:41) What happens if the Phoenix node goes offline and how users can recover their funds
(01:14:18) Future features of Phoenix Wallet
[00:00:02]
Unknown:
You say gold was in a, consolidation
[00:00:06] Unknown:
phase for the years? Multi years. You know, multi year. Yeah. Something close to that. So what could where where could we go? Yeah. You know, the breakout above that 2063 threshold was a big deal for us, and it allowed us to arrive at an objective intermediate term of about 22.80, that's not too far off, but longer term of about 25100 for the price of gold. Think it'll be sort of a slow moving ship that direction, but the momentum is there. And even right now, as of yesterday, we have what looks like we call it a flag breakout on the charts. It's when you have a sharp up move, consolidation, and then a a short term breakout. So In a similar vein, I guess, if you believe it if you believe that it's digital property, Bitcoin is also NA for for an upside objective. Isn't that true. Yeah. New all time highs. That's what happens. And, I mean, I believe in the uptrend at least. It it has very good momentum.
The pullback that we saw, it looks like nothing on the chart. It's pretty remarkable because it was 17, 18 percent of downside, but it looks like a lift. Nothing for you. It is. It really is. And, now, of course, within, like, you know, days, we've had a resumption higher. So I feel pretty good about the trend there as well. The breakout creates a a long term catalyst for Bitcoin too. It's always going to be higher beta, you know, the spread to the 50 day moving average. I looked at it this morning. It was something like 13, 14% versus the S and P, which is about 4%. So those are initial support readings.
But that's just the risk that you take by Commodities in
[00:02:08] ODELL:
Happy Bitcoin Tuesday, freaks. It's your host, Odell, here for another Citadel Dispatch, the interactive live show focused on actionable Bitcoin and Freedom Tech discussion. That clip in the beginning has absolutely nothing to do with the chat we're gonna have today. I just thought it was kinda funny having a suit on CNBC doing Bitcoin TA. Every suit is now a Bitcoin influencer. I have a great chat, lined up for us. We have, Pierre here. Who's this? How's it going, Pierre? He is the CEO of Async, which is the company behind the Async lightning implementation.
He's behind Phoenix Wallet and recently Phoenix Server. This is awesome. I I I just wanna start off the conversation by saying, Pierre, thank you for what you and your team have been building. I mean, Phoenix Wallet is absolutely amazing. It's incredibly easy to use. It's the main wallet I onboard people with now, if they're just getting started with Bitcoin and they wanna make payments very easily. So thank you.
[00:03:17] Pierre:
Thanks for having me. Yeah. Well, we see Phoenix as a demonstrator of what what Lightning can offer. So, I like to think that what you see in Phoenix, you will be able to see that in many other implementations in the future. Maybe done better, maybe a little bit different. So it's like when we started phonics, it was the world of the future. We meant it as we're gonna try out the latest, of what you can do with lightning. And so it's it's a very it's a very good project to to work on. I'm I'm glad you like it.
[00:03:58] ODELL:
Yeah. I mean so, I mean, there's a lot of there's a lot of places we can go here. Yes. I think, first off, like, I I think it's really cool. So there's there's, there's 3 main, lightning implementations. Right? There's lnd there's 4, I guess. There's lnd. There's core lightning. There's LDK, and then there's async. And async, you guys, are are a little bit unique in the lightning implementation space because you're actually building out this lightning implementation purpose built for powering Phoenix Wallet. So how do you think about that, you know, when you when you think about what you're building compared to what many of the other Lightning developers are building out in the space? Yeah. We have 2, actually. We have 2 separate Lightning implementations,
[00:04:52] Pierre:
little known fact. The first one is Eclair, which is the one we started working on in 2015, and the goal of Eclair was to power large scale routing node. Because since the beginning, we were convinced that we didn't really believe in, everybody running a small writing at home for obvious reasons related to liquidity and security management and a lot of stuff. So we don't think it made sense economically to run a small, routing node. So since the the very first commit on a eclair, it was designed to handle a lot of channels to be maybe not very, maybe not with a lot of features, maybe not with the, all the bells and whistles, No fancy interface and all that, but very reliable, very scalable and and that's the, if if I would, if if you wanted to character characterize, our implementation compared to c lightning, LND, that would be it.
And, so we did this between 2015 and 2018, I think. And at that point, we realized that it was quite easy to make this software run on Android. That's when Eclair Mobile started. And, Eklamaobile is the ancestor of Phoenix. But then we wanted to to have this wallet run on iOS 2. And at this point, we make a we we created a new implementation from scratch. So it's inspired from Eclair, but it's it's a separate implementation. It's in it's written in Kotlin. And, and this one is focused on very lightweight, very, lightweight implementation, workforce efficient. It does not scale to a 100000 channels, but, but it's very portable. You run it on Android, you can run it on iOS.
And it turns out you can also run it on a server, which is what we did with Phoenix. So we already have 2 implementations, each with their characteristics. And and we, like, if you take a look at at what we worked on since, we started, we have basically never changed, direction and and, like, have always followed the linear path. And so everything, like, every pieces that we put together, was towards this goal, which is why sometimes, like, from the outside, you could wonder why do they, you know, spend the time and energy building aclare? Why don't they use another implementations? Well, the reason is that we had to it was purpose built for what we have what we had in mind. And we didn't want to to depend on other teams to build it.
I'm just trying to, you know, I'm going a little bit besides the the original point, but to explain why we do what what we do and why we do it that way. Is that when you work on a technology like lightning, which is evolving very fast, and you you won't want to to depend on the upstream, implementers because if if you're stuck behind someone developing, some feature that you need, then you're gonna have a hard time. You're gonna have to wait. It's gonna be frustrating. Maybe they're gonna have different priorities and all that. Our approach and with specificity of our approach is that we control the whole stack.
Right. Even before the implementation, like, down to the protocol design. And this allows us to move very fast. But it means that we have to work on all the different pieces, that we need.
[00:09:23] ODELL:
Right. I mean, I think that's key that's key to a lot of your success and key to one of the reasons that the UX is is so much better than so many other self custody lightning wallets in the space. And a perfect example of that is, like so, like, if you're an end user. Right? If you're an end user and, maybe you're new to Bitcoin. You're you're new to Bitcoin, and you you launch Phoenix Wallet for the first time, and and you buy some Bitcoin or you receive Bitcoin from a friend, and you receive that payment as an on chain payment, Phoenix is immediately creating a lightning channel for you. And then if you if you receive more money on chain going forward, that that payment is that on chain payment is automatically then spliced into your existing lightning channel. And I believe in practice, it's it's the only it's the only mobile self custody wallet that supports splicing right now, and because you guys control the entire stack. Yeah. Well,
[00:10:24] Pierre:
it's also be you know, there are there are different kind of features, and but features like splicing, they only operate at the peer level, which means that if we control both the mobile and the routing node, then we can, we we can do stuff. Some other features, for example, privacy features, network wide features, we need to wait for the protocol to be mature enough. That's why that's why it takes more time. It's not that it's less prioritized. It's just that it's much more difficult to to to deploy because, we depend on others. And, and that's more difficult. It takes more time.
[00:11:08] ODELL:
But, yeah. So am I correct that so so when when you're using Phoenix Wallet, right, there's there's one implementation's running on the phone, and then the routing the routing node is running a clear? Yep. So it's actually 2 different implementations.
[00:11:24] Pierre:
Yes. They they they share some similarities because of the same people worked on them. Right. But but they are different. So, basically, that means that when we ship something like splicing, we actually implement it twice. One more complete part on, eclair and the more specific limited part on, on the library that underpins Phoenix, which is called lightning k a m p. So that's how it works. Yeah.
[00:11:59] ODELL:
Okay. So let's, for the sake of this conversation, let's start with the wallet, and then we can talk about we can go deeper on the implementations and, like and how how you're how you're thinking about protocol development. And we can talk about Phoenix Server. I think Phoenix Server is is absolutely massive, and it's it's relatively new newly announced. It was announced last week. People seem to like it. We will I'm I'm really looking forward to see what, what is going to be built on top of it. But let's start with the wallet. Let's start with the wallet. Sure. One one of the things I like about you guys is your website is is is very clear on, like, the trade offs you make with the wallet.
You don't try and, like, hide things from the users. You you make you make specific trade offs, and and you do it intentionally. And and so so when you're talking when you're thinking about the actual Phoenix Wallet, Phoenix Wallet at red by default, all your funds are in a essentially a single lightning channel. Yeah. Do you think so? So if a user wants to make if a user wants to make a a on chain payment, they're actually doing a swap to pull it out of out of the lightning channel. Correct?
[00:13:18] Pierre:
Yes. But, you know, since the the splicing update, it has been a major change in in how we see on chain and off chain, because before splicing, like, you would be either on chain or on Lightning. And it was kind of fixed and really separate. But with splicing, the the difference between the these two layers, it's it's really, really thin, which means that you can actually spend a channel is just a UTXO. Right? It's a UTXO, an unspent transaction output. And it's it can be spent by a transaction that gives some funds to the LSP us and some funds to you, and this transaction is left unpublished. That's what the channel is. It's just a UTXO.
[00:14:15] ODELL:
Right.
[00:14:17] Pierre:
But you can spend this, UTXO directly when you in Phoenix. It's just gonna create a new channel at the same time. So you're not really, like yes. Logically, you're swapping funds, but you're actually spending the same Bitcoins that are in your channel. It is the same. And
[00:14:36] ODELL:
It's still just one Bitcoin payment now that splicing exists. It used to be 2 Bitcoin payments, basically. Right?
[00:14:43] Pierre:
No. In the previous version of Phoenix, it was simply trusted. You would send us. You would pay us over lightning, and we would make the swap. It was trusted. It was very basic, extremely basic. It was, it was, like, quite primitive, really. And, so in this, with splicing, you just span your outputs and, create a new channel at the same time. And but the thing is, I don't I don't know if you remember, but a few years back, there were a lot of ideas putting forward and people were imagining what lightning could become. A lot of them were unrealistic turns out, but some of them one of them was every unchained transaction will be a lightning channel.
And at that time, most of this idea that we are floating around, I was I was like, no. It's totally it's not gonna happen. It's totally unrealistic. This one, I was also thinking, that sounds a little bit, unreasonable, but it done that. It's ex exactly what splicing is. When you with splicing, you create a new channel with every transaction that you make. And there is no, basically no overhead when you do an on chain payment versus a lightning payment. So it's you could even describe Phoenix as an an on chain wallet with a single UTXO, so all your funds are always consolidated. That's a trigger that we we could address. Right. But, basically, you could see it as, an on share wallet with the option to spend your funds over lightning.
It's it's, it will be a fair characterization.
[00:16:34] ODELL:
Yeah. No. I mean, once you once you added splicing, it really changed the game. I mean, in terms of fee burden too, it it really changed the game. Yeah. Yeah. Okay. So let's let's talk about the trade offs a little bit. The the first thing I wanna talk about is how how you think about on chain fees. We recently had, on chain fees spike with with the different inscription, pressure and and, you know, mempools filled up, and and and we had on chain fees go up high. And as a result, your users specifically, I I assume your support request went up tremendously. And there's, like, new settings now in the wallet in terms of maximum fee and stuff like that. How do you how do you think about that? I mean, this is obviously a as someone who onboards a lot of people to Bitcoin, it's a hard thing for me to translate to a new user.
That, you know, when they receive their first payment, the Lightning channel needs to be open. They're gonna pay an on chain fee. And then going forward, if they're if they're if they're paying via lightning, they're gonna have a much lower fee. If they pay via on chain, they're going to have a much higher fee. If they don't have inbound liquidity, inbound liquidity is another piece there. Then they're going to have to do another on chain transaction. Yeah. Increased. How do you think about this? I mean, it's not an easy problem.
[00:18:07] Pierre:
No. It it's definitely not easy. So the first thing is, so during the past 6, 9 months, the fees have have been very volatile. And so it it creates issues, but it's also another an environment for which, which is pretty positive for our service. You know, there are 22 situations where, as a Lightning Wallet, you're gonna have trouble expanding your, your value to users as an LSP is if the fees are always very low, which is why during the past years, Moon Moon Wallet was a very attractive choice. Right. Because we because why not? When it's very cheap, it seems simpler. The other situation is when fees are always very high.
And then it's a problem for for the LSP because, everything is is, more expensive all the time. The intermediate situation where we are, we have been, in the past months is actually the one which is the most favorable for our business because when when fees are volatile, the service that we offer to the users is just to, like, absorb this, volatility by offering liquidity. So it's not a bad thing for us. It's it's hard to explain and to guide users, for them to navigate this environment, but it's actually the situation that is the more the most positive for, an LSP.
I don't know if that makes sense, but so it allows us basically to to tell users, okay, you're gonna have one mining fee. If you manage your requite, you're right, you're gonna save a lot of ancient transactions. And then on our side, if the money fees are volatile, that it means that sometime in the future, maybe in a few months, the fees are going to be low and then we can claim back, unused liquidity. So it's essential that that fees don't stay consistently low or consist consistently high. My my my gut feeling is that this is going to be like that in the future. A little bit like the price. It's always volatile.
[00:20:36] ODELL:
But you don't think we're gonna be consistently high in the future. Right? I don't think so. I mean, I still think it'll be volatile. Yeah. It's gonna be volatile. It's a free market. It's a truly free market. So free markets are volatile. Yeah. Exactly. Exactly. But higher than the current volatile free market Yes. In my opinion. Like, 8 like, right now, we're looking we have mempool dot I always have mempool dot space up during the live streams. And, like, next block fee is 19 sats per byte. Like, we could be in a situation where instead of it ranging from a 100 sats per byte to 5 sats per byte, it's ranging from 400 sats to byte to a 100 sats per byte, something like that. You know? Yeah. It's it could
[00:21:22] Pierre:
be. But the thing is as long as every now and then the fees go down, then it's good for us. And if they if every now and then it goes high, then it gives a very good reasons for users to to, to use a word like Phoenix or any other liking wallet. And, you know what's funny is that, so on one hand, during, at the end of the previous year, we were busy migrating our users from the previous version of Phoenix. So Right. Yeah. We had to pay for those fees. So on one hand, it was not very nice, but on the other hand, it it showcased, the, advantage of being relating to a lot of user.
And one funny thing too is, you know, so it's a small team at AC. We're just 10 people.
[00:22:15] ODELL:
Amazing. It's amazing what you guys have built with such small team. And we're doing everything including the support,
[00:22:21] Pierre:
which means that first, we are very well aware of the issues that our users have because we we do it directly. And most of the customer support that we had to do, at the end of, previous year was not related to Lightning. It's actually related to people having trouble with block time and confirmation time. Right. So that's interesting. So whenever you, somebody somebody says, you know, like, it's too difficult. It's too complicated. That's not what we experience. I think it's because since failures on Lightning tend to be, immediate, like, maybe you're not gonna found find a route, to make a payment, but that's the kind of error that the users can understand. And, they are they, they can deal with that. But having a transaction and transaction linger for weeks, they don't like it at all. And they don't understand why, why, why it could happen. It's confusing.
Yeah. It's confusing. And, so, those those volatile manifest times, it's quite interesting to to to live. So,
[00:23:32] ODELL:
yeah. I mean, I think it's it's really I mean, like, so I personally run, 5 lightning, you know, full nodes. And then I also I I have, you know, like, my my I I do use Phoenix Wallet. Like, Phoenix Wallet is awesome. I, you know, I might have been in the beginning. I might have been in the camp where, like, I thought a lot more people were gonna be managing liquidity themselves, running routing nodes, doing all these things. But I think it's kinda interesting with Phoenix Wallet is is there there's, like, an argument for a, like, more like, even even a more technical user to just send, like, a large amount, like, a large UTXO in and then just, like, use that as their spending wallet and not have to deal with any channel management or anything. Yeah. And in in that situation, like, the on chain fee burden doesn't really matter to them. You know, like, let's say they're they're sending in, you know, $3,000 or $4,000.
Like, what the on chain fee burden is fucking negligible in that situation.
[00:24:41] Pierre:
I think most users, most Phoenix users do not realize that, the splicing feature and the fact that their funds are consolidating into a single q UTXO, which is, again, a privacy trade off that we can discuss, they're gonna be very happy with that once Right. The average money fee is going to be higher. Like and that's a major difference. That's why that's why, splicing really is was fundamental change is that before that, some users had literally hundreds of channels, and they they were not even aware of it because a lot of users don't don't understand how it works at all. And, this was this was a real issue for them going forward. So now it's, it's future proof in a in a sense. So so that that's that's why it was a really, very, important.
[00:25:37] ODELL:
But where I was going with that is, I wanna go a little bit into, like, how you guys are so, like, I I think it was a little bit you probably were getting a ton of support requests on on large fee amounts. And then you added this, like, the fees section in settings, like, the channel management, where it's like a max fee amount. Like, is that do you think that is, like, a a temporary stop gap solution? Because it's a little bit hard. It's a little bit confusing. Like, they receive their first lightning payment. The thing is And, like, what if I'm sending them if I send them a large lightning fee payment, a lightning payment, and they have to open their first, you know, they have to open the channel, and fees are high on chain.
It's like an absolute amount. Like, how do you how do you think about that? Do you know what I do you know what I mean? Yeah. Yeah. I mean,
[00:26:31] Pierre:
we wish we could do it better. Before we introduced this, we had a fixed 1% fee on receive Right. Plus 3,000 sets. And, this had the advantage of simplicity, but You were getting killed on on chain fees. Yeah. It's it's just a risk. It's just a risk. I mean, we were doing great when fees were low, but it's just a risk. And the the the main change that we made was to just push the money fee to the users. To us, it's just a matter of managing, risk. And once once you do that, you you cannot just, exchange Auto charge them. Yeah. It's it's it's very difficult to, to to put to put in in one sentence what's the cost is going to be.
And so, obviously, we are, you know, trying to to the the the way it is done currently is not final. We are we are we are thinking about it every day, but, the goal was to offer, more advanced users a way to fine tune, their fees to the very minimal, which is why, you know, you're gonna have Phoenix users who say, it's too expensive. I'm getting killed by fees. It's, it's nonsense. And you're gonna have all that who gotta say, it's awesome. It's almost cost me nothing. So our our because they're using it the correct way. And our goal is to find a way in the UX to make the users understand how it works and But there is a level of, understanding that you need to have, which by the way, you must have the same kind of level of understanding at the on chain level 2 if you don't know what's a new tool. You're gonna have issues with, with mining fees. You can get killed a bit in the same way.
So it's a very difficult problem.
[00:28:24] ODELL:
But Especially since I mean, so many people have been, like, conditioned on custodial wallets, especially newcomers. Like, I I like when I try and transfer someone over from, like, Wallet Satoshi or something, they're like, I'm getting charged so much more fees. And it's like, yeah. Well, you know, you actually have a lightning channel. Like, you're actually holding self custody of your funds. Well, you know what? If you look into the fees, it's not like try to make an unchanged transaction from White Ops Satoshis and compare to the costs we sell. I know. I'm aware. I'm saying, like, the educational it's, like, it's just hard to translate that to the user, especially if they're a new user. Yeah. And it's a difficult problem.
[00:29:00] Pierre:
But, no, on the unchain feeds, when you make unchain transactions, it's actually interesting how Phoenix is more efficient. It's not less expensive in Phoenix because we made a particular effort on fees. No, it's just because if you pay for UTXO, then it's easy for you to spend it. Whereas if you have a custodial wallet, they're gonna have to manage the hot wallet, and it's it's really, really difficult to manage your hot wallet and let users spend from your wallet. It's very, very difficult. That's why it's expensive. Yeah. I,
[00:29:31] ODELL:
yeah. I I I so, the reason I bring it up is because, yeah, it I was just gonna be and when you first implemented the feature, it was like the default was a certain amount. It was, like, an absolute fixed amount.
[00:29:48] Pierre:
It is for it's I think by default, it's 5,000 satoshis.
[00:29:52] ODELL:
Which, like, what is that what is that sat per byte rate where that gets hit? Do you know? It it's it's an absolute in, satoshis,
[00:30:02] Pierre:
because,
[00:30:03] ODELL:
But shouldn't it be percentage?
[00:30:07] Pierre:
You you have both, actually. There is I mean, the fact is the the real cost is absolute. It's an unchain fee, so the real cost is absolute. So it doesn't make sense to to put it, to have the main setting be relative, but you could, put a very high amount and there is also a relative in the advanced setting somewhere. There is also a relative check. Yeah. I see advanced percentages. Our approach to it is there are so many, you know, side effects, and so many stuff going on that you don't want to be too far from the reality. And the reality is the cost is independent of the amount. So if we if we don't want to have too many headaches, that's the easiest way.
[00:30:55] ODELL:
Fair enough. I just know when I was onboarding in the higher fee environment, I was just literally I before I would have them send into the wallet, I would go into settings and just jack up that. Yeah. It was like an it was they were like, what are you doing? I was like, you gotta go into settings. You gotta you gotta increase this amount, and there was but there's no easy answer. I don't pretend there's an easy answer. Well, it's,
[00:31:19] Pierre:
we we we have introduced a feature related to that in in the phoenix, release. Maybe we'll talk about it later, but it's related to that. It's bay it's it's the feed credit. Is it's a way for for to to aggregate amounts, before you open the channel. You know, like you cannot onboard a user by sending him a 1,000 sats if it costs a 1,000 sats, in mining fee. So the idea is to say, okay. But what what you're actually going to do is you're gonna pay for WAN and you're gonna pay in advance the LSP to just put the amount aside and take it from your future mining fee. And it's a bit like custodial without being custodial. You trust us because you're paying advance, but those are not your fans.
So it's kind of a gray gray area in in a regulation from a regulation point of view, but I think it works that
[00:32:19] ODELL:
way. Yeah. That makes sense. Okay. So let's talk about continuing the trade offs. The major trade off with Phoenix right now is privacy trade off, and you're very clear on your website. But you wanna just discuss, like, what what kind of information can Phoenix see if I'm a Phoenix user?
[00:32:39] Pierre:
So we can see if you if you don't use store, we can see your, your IP address because you're connecting directly to our node. Right. We can correlate since you are we are the only node that you're connected to, we can correlate your transactions, obviously. I mean, we we see how much beacon you have in your wallet because they are on the other side of the channel. Right. But that would be this is not a specific trade off of Phoenix. It's a specific trade off when you're connected to a single node.
[00:33:22] ODELL:
Are you keeping track of, like, so, like, if I if I open Phoenix and I pay a lightning address, right, you can pay 2 lightning addresses, and I pay, like, Odell at at voltage. Are you keeping track of those, which lightning addresses you're paying? Are you keeping track of the memos of those addresses? Like, the memos of those transactions?
[00:33:51] Pierre:
We don't have access to that because the resolution is done on the mobile.
[00:33:55] ODELL:
But we keep track of the the payments. Like, with the endpoint, where it goes, which node it it ends up. So
[00:34:05] Pierre:
what what we need to do as, routing node is we need to allocate our fans. We need to know where to allocate them. Right. So it's very so we have to to see where, we should put our funds so that it's it's more reliable. One important thing, in Phoenix is that, it implements trampoline routing. Trampoline routing so the the default routing, in, lightning is called onion routing and it's just the the source when you make a payment from a to d, the source computes the route from a to b to b to c to c to d. And then makes an onion and intermediate routing node. In my example, it would be b and c. They don't know where the payment is going. They just forward it from the previous node to the next node.
The idea of the temporary routing was to do just that, just the same. It's a nonlinear routing too, but, like, if you want to pay from a to z, the source of the payment, they would not have to find the whole route because this requires them to know the whole network table which changes constantly and is a pain to to sync and all that. It slows down the UX of the transaction. Exactly. So the the goal they they only need to to select a few intermediate nodes. Like, they would say, okay. I want to, I'm gonna use a route, I don't know, f, n, and p.
And, and then this intermediate node, this trampoline node, that's up to them to find the route between themselves. So it's the same, it's very similar but at a higher level. And so we came up with this idea of taupelyn routing a few years back and, we we we thought it was a really good way to offer privacy for mobile lightning wallets without having them sync and be aware of the, whole network table all the time. That's where the the I'm just saying that to explain where the current, state comes from. And but as about as I mentioned earlier, some, protocol features involve the whole network, and that's the case for trampoline.
The whole I mean, a lot of the nodes in the network need to be trampoline. They need to understand this protocol for this to work. And when we started, we were pushing this feature and only us were supporting this. So what what Phoenix does generally is a trampoline routing, but with only 1 trampoline node. So the destination is always known to us because we know they're not gonna do any more hops. And was that the LSP? Yeah. So that's, that's why currently we know the final destination of, all payments.
[00:37:03] ODELL:
The idea was this to be a first step to work. But if other routing nodes add trampoline routing, then you won't know the final destination.
[00:37:11] Pierre:
No. They don't. Because between between property nodes or between the last property node and the destination, which is the case in Phoenix because the first property node is the last property node, it's normal Lightning payments. So so yeah. This is going to be majorly improved, very soon with the introduction of the daily path. That's a more technical feature. I don't know if you want to address right now or later. But, We but we're on the topic. Let's talk about blind Alright. So blind blind blind blind blind blind blind blind blind blind blind blind blind is is a way for the recipient to to to to give, the end of the route or a few sets of routes, the last part of the routes to to pay them, which means So it's in the invoice? Yeah. It's the it's it's in the invoice. So from Phoenix, if you would pay I don't know. You would you want to send your money to to any any place. You wouldn't you would not to Bob, say. You would not send the destination bob to our node. You would say you would send an entry node, which is a few nodes before bobs. And our job would just be to route the payment the payment to this entry node, and then the last remaining hops, are already computed.
And so it's it's base it's it's resembles, what we wanted to achieve with the original temporary
[00:38:52] ODELL:
payments. So is LND implementing this?
[00:38:55] Pierre:
I oh, you will have to ask, Bastian for the exact, but I think yes. So this is this is related to, to bolt, 12.
[00:39:06] ODELL:
Oh, so l and d isn't implementing. Yeah. Yeah. I don't know exactly how how far they are, but, yes, they are more important. Okay. Well, I definitely wanna talk about vault 12, but let's continue on the wallet just real quick here because, I just wanna go through the trade offs on the wallet. Sure. So, I mean, right now, that that main trade off, then you know the end the real the the key reason for the end user for that privacy trade off is that Phoenix payments are almost instant. And if you use, like, a Zeus wallet, where where they're computing the whole path locally, is when is when you kinda sit there and you make the joke. You're like, oh, look. The future of finance. And you're, like, sitting there for, like, 15, 20 seconds while your payment goes through. Yeah.
And and so Phoenix makes that trade off so that
[00:39:55] Pierre:
so that the the payments are just like it's it's literally just like a snap of finger. It's it's crazy how quick it goes. It's also more reliable because you could, like, try some routes, but it changes all the time. The availability of routes, the the amount of events available in each channel and so on, it changes all the time. So our point of view in this is okay, yeah, we know the destination, but let first, comparing to making a simple on chain payment, is still in my opinion, it's still much better. Right. And
[00:40:31] ODELL:
and also it's so easy I mean, if it's an on chain payment, you would know the I mean Yeah. I mean, everybody would have that that information, basically. Everyone has a destination.
[00:40:40] Pierre:
And, and also, there is there are no KYC, no subscription. So you can open a new wallet as you want. So what does this really mean for us to know the destination where you can change your identity whenever you want? It's it's not as valuable as, as, like, having, the user stuck in 1 user ID or user account, and then you can correlate everything that's related to it. And, and also what what it allows us, and it's very important for UX, is a predictable fee for sending. Because one of the critics that we had in our, previous, iteration of the wallet was. I don't know how it's going to how much it's going to cost me when I send the payments.
And
[00:41:31] ODELL:
Oh, yeah. It's great. It shows the fee ahead of time. Exactly. And that's, that's that's important. Okay. So the next thing I've I've gotten you know, I just love Bitcoin, and, I want Bitcoin to be as useful to people as possible and wide variety of users. And I live in the heavy technical world of bitcoin a lot, but I also live in the the the newcomer world a lot. I have a lot of exposure with people that are are relatively new to Bitcoin. And one thing I've gotten a little bit of heat for lately is I really like the fact that you can back up your iOS Phoenix wallet to Icloud, which is just I mean, if you asked me 5 years ago, 4 years ago, I would have been like, fucking hell no.
But it's it's a very easy way for a new user to back back up their wallet without dealing with seed phrases, without dealing with actually storing the seed phrases securely, with making sure that they're still there. If they lose their iPhone, they can just easily log back in and and have their wallet. Now when you one of the cool things you guys do is when you go to initiate iCloud backup, you give, like, really clear scary warnings, as you enable it. What are the real risks there in terms of a user that is, like, using the iCloud backup feature?
[00:43:04] Pierre:
Well, on the top of my head, but, I would need to double check with our iOS guys. The main trade off is that if your Icloud account is compromised, then it's not good for you. Whereas if, like, on on Android, you there is no Google Drive backup, Right. Then you're safe from that. So
[00:43:30] ODELL:
So, like, if you're if you're storing, like, nude pictures of yourself in Icloud, like, there's probably you're probably cool with with with storing your wallet in Icloud. Right? Like, I mean, like, it's I when I read the when I read the things, it's like Apple might compromise you.
[00:43:46] Pierre:
Yes.
[00:43:47] ODELL:
But it's encrypt it's technically encrypted, the backup. Yes. But
[00:43:53] Pierre:
if you have access to your if somebody has access to your hack like if because if you have a very weak, password, if you have a very weak hack like that password, And people are usually terrible at passwords. So, that's the trade off. Yeah. I mean,
[00:44:10] ODELL:
the warnings are, like, very I mean, they should be. I I applaud you for putting scary warnings there. But I think it's very compelling for a lot of people. I mean, I think,
[00:44:23] Pierre:
The the reason we did it on the iCloud and on the Apple and not on on, Android is that on Android, we by default, you don't have access to Google Drive. So this would require, to ask for permission, and that's, some people don't like Google Drive. So
[00:44:43] ODELL:
this feature is only available on, on Apple for now. Yeah. Well, I mean, what I see with most people is, like, most people are more likely to lose their money than have someone steal their money, and most people are are unlikely to be, like, a high value target that, like, Apple would presumably, like, try and attack. And Apple takes pretty decent lengths to protect Icloud from, you know, general attackers because of the fapping that happened when all the celebrities nude photos all got out, which is not good for Apple's business. Like, they don't want nude photos getting out. So the protection they provide for the nude photos, they're kind of providing for the phoenix backup. And for me, like, that flow, that process of getting someone new to Bitcoin, and I don't want them to use a custodial wallet, I onboard them on a Phoenix wallet. I have them enable iCloud backups and make sure they read the warnings. And I explain to them, like, you know, make sure your iCloud password is is secure password.
They also have some, like, ridiculous two factor that is, like, very opaque and hard to understand, but apparently works reasonably well. I I it just seems like a good trade off balance. Like, I I've I've known so many people who've lost seed phrases, particularly for their first for their first wallet, and and and I I think it's a a a a good UX flow. Awesome. Okay. I think we got through
[00:46:18] Pierre:
the wallet trade offs. Yeah. There is one trade off that you have not mentioned, but it's a recurring question for us is why don't we allow, users to connect to different nodes? I know. Why not? It's funny because most people think that it's because we want to capture all the all the payment fees, which is not the result it's not the reason at all. The reason is that. There are 2 reasons. The problem are incentives. That's the main reason. You don't want to develop software and put software out for users to to use and then have users connecting to random lightning nodes. So if they're using your software, you're not part of it. You're just providing the software, and then you have to, and then they're gonna do whatever they want and connect to nodes as unreliable as possible.
When they're going to encounter issues, who are they going to turn to turn to is going to be to you because you're the most sales actor in this in this message. Why are my payments failing? Exactly. So we don't want to be stuck doing support for user of the tile using, nodes that we have no power over, no control over because it's just a nightmare. You don't want to do that. It's just going to be wasting a lot of time and a lot of effort. So that's the main reason. If if users were competent and, like, we could we could do as many warnings as we could. It just doesn't work. We we we actually did this before with Xtra Mobile. You could correct me. So we know what that is, and we don't want to do that.
It's not about the physical. The the the,
[00:48:03] ODELL:
yeah, sorry. That's what I was about. It's about the user experience. You wanna be able to provide a good
[00:48:10] Pierre:
reliable user experiences. Yeah. I mean, we don't want to be stuck because this is complex tech, and you don't want to be to be stuck in the middle. It's just a problem with incentives. Yeah. I mean, I I yeah. Yeah. Go on. The other very important reason is that one of the the main service that we provide is, is, liquidity and specifically on the flight channels. And, I I discussed it with the, Blockstream guys when they were working on Greenlight is. How do you know how can you tell if the users is lacking liquidity if you don't have the total view of their channels?
You know? Maybe you cannot receive the payment, using the channel that you have with async, but maybe your Phoenix has another channel that you're not aware about. So why would we charge the user something if it could can go to the to the to, another direction? So to me, we can we cannot offer both connecting to, many nodes and on the file liquidity. I don't see how that can possibly work. It's going to to be very hard to explain. So those are the actual reasons.
[00:49:26] ODELL:
Yep. That makes sense to me. Okay. So, I guess before we leave the wallet, I have two questions relating to Gnoster. How how, attentive are you to the Gnoster ecosystem? Are you familiar with Gnoster Wallet Connect? No.
[00:49:44] Pierre:
No. I I know that, some people want us to do something with that,
[00:49:51] ODELL:
But, I don't know exactly what that is. And Okay. So Nasr Wallet Connect is, like, in Nasr. Right? We have the ability to send Zaps. Right? And, you know, lightning payments to users within within a Nostra app. Right? And nostril WalletConnect, basically uses nostril, as a communication protocol back to your LSP that says, like, I wanna make these payments. So, like, right now, if I'm using Phoenix to send a Zap, I have to I have to leave the Nostra app. I have to go back into Phoenix. It, like, automatically opens in Phoenix, and then I have to approve the payment in Phoenix. But if you use Nasr WalletConnect, those payments all get queued. And next time I open Phoenix, Phoenix can have, like, a threshold where it automatically makes the payment, or it can ask me, do I wanna make the payment at that moment?
So it basically just uses nostr as a communication as a communication protocol, which that is what nostr is, a secure communication protocol, to to allow you to queue payments for all sorts of things. And now people are using it for subscriptions. So like Geyser Geyser Fund, you can like you can set up, like, almost like a Patreon level subscription where I wanna, like, I wanna send 5,000 sats every month. And, basically, guys are sending this Noster event to to Phoenix. And then when I open Phoenix, it's like you have these subscriptions, and I can, like, immunity wallet has kind of been ahead of the game on that. And, like, so they Yeah. So You can set, like, a threshold. You know? You can set a threshold. Like, every day, I wanna auto approve, a certain amount, for this one app so that I when I open up Phoenix, it just automatically makes those payments, essentially. Okay.
[00:51:42] Pierre:
So it's essentially just, Phoenix embeds the Northstar client. Right?
[00:51:47] ODELL:
And reads Into the LSP. Yeah. Okay. Look into it. Cool. And then the other thing is using, like, Nostra contact lists for like, so you can have, like, a I don't know if I mean, you're in France. I don't know if you know, like, Venmo or I I assume, like, Revolut and, like, the European based ones have it. But, like, basically, I can just, like, open it up and be like, I wanna pay Marty, and Marty's already my Noster contact. So he has a Lightning address set up, you know, so I it linked to his Noster account so I can just, like, easily import my Noster contacts to pay people. Those are two
[00:52:24] Pierre:
different things. On the on the more general payment front, our immediate focus is bolt 12, which is a
[00:52:32] ODELL:
major milestone. Perfect. Let's talk about block 12. Yeah. So, I mean,
[00:52:37] Pierre:
these these features that you're mentioning to me is, like the cherry on the cake once we have the big infrastructure working. So
[00:52:48] ODELL:
Well, let's talk about Bolt 12. Like, where are we on Bolt 12? How are you thinking about it?
[00:52:53] Pierre:
So Bolt 12, we have as for everything, we have to implement it twice. Remember, once in a clear, once in the lightning KMP. So Right. We have done it in a clear a few months ago, and we are currently doing it in the Lightning KMP, so in the Phoenix. I think it's a matter of weeks, months. Let's say more of a matter of a few months. And the so the the what it offers you basically, it's a static address. It's like your old beacon address that you can put everywhere on your, wherever you want, and it doesn't change, and it allows you to receive lightning payments. And, it's it would make the Phoenix server demo even more nice because basically you just start the daemon, it just prints, an address and then you can put this and like for, to receive donations, like, donations on the on on wherever, it's so simple. You just put your Finnish server somewhere on your node. You don't even need to to to, to bother with firewall or whatever. It just sits somewhere and connects to the Internet, and then you can paste your your static address and receive, receive it.
It's it's the same UX basically as a regular beacon address. The thing is and it's it uses a lot of tech because what it does essentially when you pay a static address like this, your your the sending wallet is going to ask is going to go through the Lightning Network. It sends a message. It's not a payment. It's a message to to reach the destination node and ask for an invoice, and then it's gonna pay the invoice. So there are 2 round trips, which also had the added benefits that it's kind of like a probing, like you can check whether the destination is whichever before asking the invoice. A lot of, lightning products currently do actually manual probing.
This allows us to wake up the mobile in the case of Phoenix because we know that the payment is going to happen. Like, so there are a lot of
[00:55:17] ODELL:
Right. So does that mean I can receive if I don't have the app open?
[00:55:22] Pierre:
It's already the case. You know? You can try to turn off Phoenix. I mean, to generate an invoice, to share an invoice and then turn off Phoenix. It's gonna wake up just in time Got it. To receive the payment. But the problem is that you still have to generate an invoice for that payment. Right. Every time I gotta generate I gotta open that, generate an invoice, send it. So in the case of Phoenix, we're gonna wake it up, just in time, to to create the invoice. This is going to to happen automatically. You won't be, no interaction necessary at that point, and then, the payment was going to go through.
So yeah. The goal is to have a very, very similar experience to, to receiving a bunch of payments.
[00:56:07] ODELL:
So, like, I mean okay. So I'm, like, I've been excited about Bold 12 for many years now. Like, how close are we from that experience actually happening?
[00:56:22] Pierre:
Oh, yeah. We are close. I mean, we are if I mean, we well, we we don't we don't have the habit to make announcements of announcements, but, that's what we are working on currently. That's our main next main, raise feature. The the only thing is that this is network wide. So just because Phoenix supports it doesn't mean that you can do We need the sender to support it and the routing We need everyone to support it. We need everyone to support it. Like, I don't know if you have been using, Kraken with auto lightning feature, but you have to to to input a new invoice every time you want to make, to send parents of our lightning.
That's really that's great. So Yeah. Yeah. We would need them to implement that too and all the exchanging on that. So that takes time. Like, specifically, the sender side needs to be able to support. Yeah. I mean, the sender side, but also the network because, you know, it's it's, it uses onion messages. So messages has to be have to be routed in the network. We can skip some nodes. Not everyone has to update, but it's it's better if, you know a large amount, a decent amount for reliability reasons.
[00:57:41] ODELL:
Okay. So Phoenix server is this idea of taking the ease of use of Phoenix Wallet and putting it in an always on server environment. Yeah. Let's chat about I mean, because you released this last week. I mean, on the surface, it seems, absolutely massive, incredibly useful to a lot of people, particularly, you know, this idea that you don't have to worry about inbound liquidity, that that you guys handle that automatically, for the end user. Like, what's the quick what's the quick pitch on Phoenix Server? Like, how do you how do you think this is gonna affect kind of the the Bitcoin landscape?
[00:58:22] Pierre:
So basically, it's just, it's exactly like Phoenix mobile except that you interact with it not with pushing buttons on the on the on screen, but just sending HTTP codes. So it's it just bring the ease of use of, Phoenix wallet, but for developers who can build any lightning connected, services. And we have added a few features, around because a lot of these potential applications involve receiving. It's it's often receiving more than, like, from merchants receiving more funds than sending. It can be both, but so we added some a few features to make it really completely transparent. So you for for developers, it allows you to interact with lightning with absolutely no headache. It's like exactly like you would if you if you build a traditional merchant website, you would plug into Stripe and then I like so like 2 ifttp calls and and and one callback.
It's exactly the same and in an in a cost effective way. So we made like for Phoenix, so what if we make all the trade offs except the one that is self custody. So we allow ourselves to to to to to do some trust, but we put the limit at self custody.
[00:59:56] ODELL:
So, like, a new merchant could could run this, and they just start immediately receiving lightning payments. They pay you 1% as the LSP, and that's that. Exactly. So not only is it easy,
[01:00:07] Pierre:
from an integration point of view, but you also benefit from the well known reliability that Phoenix offers. So when you when you use, Phoenix server to receive payments as a merchant, you your your inbound liquidity is the inbound liquidity of the async like node. So you can you're not gonna have any issues, around that. I mean, so it's a great burden to remove off your shoulders if you want to receive funds on anything. Wait. So right now with Phoenix Wallet,
[01:00:38] ODELL:
I let I let's say I put I put 10,000,000 sats into Phoenix Wallet, and I have 10,000,000 stats of outbound liquidity. But for inbound liquidity, I have to pay an on chain fee when I need to increase my inbound liquidity. How is that handled on Phoenix server? Like, am I not in that situation? Am I not, am I not paying that on chain fee?
[01:00:59] Pierre:
So on Phoenix server, let let's let's do the the actual steps. What's going to happen if you start with not with a brand new wallet. Okay. Brand new wallet. I'm a merchant. I have no Bitcoin. I won't accept Bitcoin. So you just you start the daemon. Okay. Then you're gonna use the API to create an invoice. Then a payment is going to arrive. At that point, if the payment is, more than the mining fees required to create the channel, then a create a channel is going to be created and, the mining fees are going to be are going to be deducted from the amount you receive. Okay. But and in the same operation, we are going to also add inbound liquidity, with the default of 2,000,000 SATs, with a 1% fee.
Okay. Okay. So this, we are gonna do 1 unchain transaction. It's going to create a channel. It's gonna give you a lot of inbound and that's it. That's the easy scenario. Now another scenario where
[01:02:07] ODELL:
What if my next so then okay so that happens, and then someone walks into my store or goes online to my store and then pay tries to pay me 4,000,000 sats, Right? More than my inbound liquidity. What happens in that situation?
[01:02:20] Pierre:
Well, in that situation, it's gonna be the channel is going to be too small. So another on chain selection is going to be required. You're gonna receive the 4,000,000 in that, operation, and you're gonna have add also 2,000,000¢. So the merge the merchant's still paying that on chain fee, though. Right? Yeah. They have to pay it. But the thing is so if your average, if your the average invoice that your customers pay is 2 or 4,000,000 SATs, you will then want to increase the default liquidity amount to be much larger than that. Otherwise, it doesn't make sense. You're gonna have to pay on chain fees all the time. On the other hand, if you receive that amount, the the weight of the on chain fees is quite low in relative terms.
[01:03:04] ODELL:
So Right. It's up to you. But basically So in practice, it works very similar to the actual wallet does?
[01:03:10] Pierre:
No. Because I mean, yes. It's similar, but it's not exactly the same because on Phoenix, you wouldn't you you are not currently able to request invalid query at the same time as, creating a channel or a splice. So it requires 2 transactions. That's a major difference. And the other major difference is that let's suppose now that so you start from nothing and you you try to receive only a 1000 sats. It's not enough to cover for the unchanged production. On the Phoenix mobile, we would simply reject the payments because it's too expensive. Like, it we it's, the main fee is too expensive. You cannot cover the cost with this payment.
On the Phoenix server, this amount goes to your, what we call a fee credit. It's gonna be used to pay future money fees. That means that if you're if like, typically, I guess that on NoStar, the typical tip is not going to be 2,000,000 sat. It's gonna be much smaller than that. Right. In this situation, then all the small tips would aggregate. And as soon as you reach the amount needed to open a channel with 2,000,000 sat inbound liquidity by default or possibly more if you configure them differently, then you're gonna end up with a big channel and receive all the future tips in this channel.
[01:04:27] ODELL:
And you would have And then you take out the fee credit at that point.
[01:04:31] Pierre:
Exactly. And so the the all the small tips that, would have been rejected on Phoenix mobile, They are taken and they are used to pay the mining fees. So, every single Satoshi that you receive, it's not lost because it's it's going to pay to contribute to paying this the fee for your channel. That's a major difference because it means that you don't have to worry about, you know, threshold effects. Everything appears to be linear. So you can, as a merchant, you don't have to to pay attention to these details at all. You just have to to think in terms of relative fee total fee. And our goal is to bring it as close as 1% overall as possible. And it's you can see the the the calculations in our website. But basically, it's it's between 1 2% depending on your settings and the
[01:05:27] ODELL:
mining fees. Got it. Now am I correct to assume with the focus on bolt 12 that that is there any priority now with this with this Phoenix server, is there any priority to add lightning address support to that?
[01:05:46] Pierre:
We want to add something that's I don't know if you, came across the, the, the DNS proposal, from Bastian that, he put together. I think it's end of 2023. Basically, we want to offer something functionally equivalent to, to add an address, but much more private. The problem with lightning address, it from a functional point of view is great, but it leaks a lot of information about the sender and the recipient. Because you're asking your server and you the sender, when like, if you're an LSP like us, if you if we run a lightning address service for our Phoenix users, then whoever wants to send the payment to a Phoenix users for to a Phoenix user using their lightning address would reveal their IP to us, the IP address to us because they would have to contact our service.
And they would and yep. So that's a big problem. And so there are privacy issues with that, and we believe that, leveraging bot 12 and static addresses, we can match make much, much, much, better, technical solution, which is also exactly as easy to integrate for, for everybody who wants to to play with that because it's just a static information. So you just have to resolve it using DNS or using whatever you want and, it does exactly the same. So that that's the reason why we haven't, supported lightning address. It's not related to not being able to wake up Phoenix because we already do it when we do a regular lighting payment specifically because of, privacy concerns.
And Right. Because right now in Phoenix, well, I can send a lightning address. I can't receive to it. You can send because if you want to send, that's your problem. We, your Phoenix is going to contact the, the whoever is the server. The web server. Yeah. So you're responsible request an invoice. Exactly. But we don't want to have that information ourselves. So that's why we don't offer this feature.
[01:07:59] ODELL:
And if I have Tor enabled on Phoenix Wallet and I'm paying a
[01:08:04] Pierre:
lightning address, then it's going through Tor when it requests that. I believe, yes. At at the very least, if you have all bot on your phone, yes. I will have to double check, but I I believe it's
[01:08:15] ODELL:
Okay. That makes sense to me. Bolt 12. Hopefully I mean, I had Steve Lee on the show a couple weeks ago, and he's quite optimistic about bolt 12, from the LDK side. So Yeah. Yeah. They are
[01:08:30] Pierre:
definitely moving forward with this.
[01:08:33] ODELL:
Awesome. Yeah. I mean, I think this has been a great chat. I mean, we're a little bit over the hour mark now. I think, I think Phoenix d like, this Phoenix server idea could be quite it seems quite compelling. It's like, for the donation use case, for the merchant use case, I can see it being implemented in BTC pay server to make it quite easy for people. That that would be the perfect use case. I mean, that definitely
[01:09:03] Pierre:
really for to as a way to to just try out, recently letting payments, for not a reasonably sized business, let's say. I think it's really, really, very, compelling, offering.
[01:09:26] ODELL:
Awesome. I have I have one last question for you, actually. And I was like Yep. Going back to I guess it's it's it's relevant to both Phoenix Wallet and Phoenix server. So let's say, like, worst case scenario it goes back to trade offs. Worst case scenario, the phoenix the phoenix node goes offline, for whatever reason. We don't have to speculate for for why it happened. But everyone, you know, they they have a channel open with this with this node. How does the end user you know, I have Phoenix Wallet. I have 10,000,000 sats there. It's in a channel with the Phoenix LSP node. That node goes down. How does that look for the end user? Okay.
[01:10:09] Pierre:
So firstly, before that, that everybody needs to be aware is in the security model of Phoenix, you need to have Phoenix installed on your mobile or one mobile that you own with connecting with access to the Internet all the time. It's not a code storage wallet. It has to be able to to, access the blockchain once every 2 weeks. That's very, very important because, so as long as you have this, then you're safe.
[01:10:41] ODELL:
Otherwise, you could broadcast an old state and take the money. Yeah. Or anyone who has access to the node. Yeah. Exactly. And, and also, this means that you have the
[01:10:51] Pierre:
the you you can first close the channel whenever you want. Maybe we're offline or maybe we are I don't know. We have been compromised or whatever. For some reason, you want to to just it's a way for you to fire us basically as an LSP and just take your money back. So so the way I see it so let's say one day we we go down or we we just go offline and don't respond any anymore. Business goes out of business. Yeah. Exactly. If, I I would imagine it's a more problematic situation because if we just go go out of business, we would prepare it. Right? Right. So this is just And I could be assholes about it. Exactly. So let's say we're just, we do just disappear from the from, from the Internet. Right.
As long as you have your mobile with finish install, you're safe. You you you don't have to panic. You you you you're gonna have to force close your channel at some point. It works like just a normal force close? Exactly. You don't have to do it right away. I imagine that some people would take over or fork our code and, make a nice tool to to help. I don't know exactly, but there is no rush. There is no need to there is no, like, delay that you need to count before money is lost or whatever. Because what Phoenix shows you and and you every user should, if you want to, understand how this works, go to the channel details, and you're gonna see your UTXO, and it's yours. And in your channel data, you can see the commit plan transaction. It's it's the transaction that if you publish, it's going to spend this UTXO and give you money back to your wallet. As long as you see this UTXO, you see this transaction, and you know you can publish it, you're fine. So,
[01:12:40] ODELL:
So if I if I go into the payment channel settings on Phoenix and I press the close all button or the force close all button,
[01:12:49] Pierre:
what happens next? I haven't pressed that button yet. If you if you press the close button Yeah.
[01:12:55] ODELL:
It's just going to be a mutual close, which is What where what on chain address does that go to? Because every time I send to an on chain address in Phoenix, it just automatically splices in. So Yeah. It's going to be,
[01:13:09] Pierre:
an on chain address derived from your seed following, BIP 84. Okay? So you just, use any normal standard on January, you're gonna find your fans in there. Got it. If you first I used to, like, import it into Sparrow at that point, and it'll be in Sparrow. Exactly. Yeah. Exactly. If you first close your channel, that then it's not going to go directly to your on channel address because you have there has there is a delay. The same delay 2 weeks delay that we have on our side, to protect, users from fraud from our part, there is the same delay for Phoenix. It's it's smaller. It's just 5 days instead of 2 weeks. But for the same reason, we need to protect ourselves against our users too. So you're you're gonna have to wait for 5 days before the funds go to the wallet. And during these 5 days, the Phoenix needs to be installed because it it it needs to be able to publish the transaction that that finally sends the funds to your personal wallet. So basically, never uninstall Phoenix as long as you have not recovered all the funds, and you'll be fine.
[01:14:18] ODELL:
Got it. Okay. That seems pretty straightforward. Pierre, this was this was a great chat. I really enjoyed it. I really appreciate what you and your team have been building. I mean, there's a lot of us there's a lot of us out here that that rely on on what you guys are building, and and you guys have really pushed the industry forward. Thank you. Do you have any final thoughts before we wrap?
[01:14:43] Pierre:
I I think, you know, without being a lot of changes, in, Lightning and Infinix over the past year. Bolt 12 is going to be a huge milestone. Now one of the, updates coming up, it's related to Taproot. We have done one part with, the swaps, but the channel, transactions are going to be taboot taboot 2, which means that footprint of, your wallet is going to be it's not going to stand out on the blockchain as much as it does currently. So the technology is maturing. Phoenix is maturing. And Like right now, it's pretty obvious that it's a Phoenix wallet. Right? It used to be obvious that it's Phoenix. Now it's obvious that it's a Lightning wallet.
And after that, it's just going to look like, like a a stand out p 2 p 2 tr wallet. It's not particularly private, but it doesn't stand out. So it's a huge all the privacy features that we unfortunately, that those are the most difficult to do. So they they come at the end, but they are they are finally, yeah, definitely coming.
[01:15:57] ODELL:
Awesome. Well, thank you again. And, you have my contact information now. If I can help in any way, don't hesitate to reach out. Cool. And,
[01:16:08] Pierre:
it was a pleasure. Thank you for having me. Bye.
[01:16:11] ODELL:
Awesome. Thank you, Pierre. I wanna do a huge shout out to the freaks who joined us in, the live chat. You guys make the show unique. You guys make this show special. Thank you. And a huge shout out to all the freaks who continue to support the show. We're ad free, sponsor free, and, your donations your donations really do help. So thank you for sending your hard earned sets to dispatch and and and keep us going. We have, the top three supporters this week was Eric 99 with a 100,000 sets, 8 Myth Randur with 15,000 stats, and TKC TV with 10,000 stats. That includes podcasting 2 point o and Zaps that come into this to the live stream. I I combine them now, into one shout out. And next week, same time, same day, Tuesday, 1700 UTC. We're gonna have Tony from Unity Wallet, joining us. So definitely come join us for that.
And, I appreciate you all. Thanks, Pierre.
[01:17:14] Pierre:
Bye.
[01:20:36] ODELL:
That track was Life's a Beach by Django Django. Love you freaks. Hope you enjoyed this rip, and I'll see you next week. Stay humble stack sets.
You say gold was in a, consolidation
[00:00:06] Unknown:
phase for the years? Multi years. You know, multi year. Yeah. Something close to that. So what could where where could we go? Yeah. You know, the breakout above that 2063 threshold was a big deal for us, and it allowed us to arrive at an objective intermediate term of about 22.80, that's not too far off, but longer term of about 25100 for the price of gold. Think it'll be sort of a slow moving ship that direction, but the momentum is there. And even right now, as of yesterday, we have what looks like we call it a flag breakout on the charts. It's when you have a sharp up move, consolidation, and then a a short term breakout. So In a similar vein, I guess, if you believe it if you believe that it's digital property, Bitcoin is also NA for for an upside objective. Isn't that true. Yeah. New all time highs. That's what happens. And, I mean, I believe in the uptrend at least. It it has very good momentum.
The pullback that we saw, it looks like nothing on the chart. It's pretty remarkable because it was 17, 18 percent of downside, but it looks like a lift. Nothing for you. It is. It really is. And, now, of course, within, like, you know, days, we've had a resumption higher. So I feel pretty good about the trend there as well. The breakout creates a a long term catalyst for Bitcoin too. It's always going to be higher beta, you know, the spread to the 50 day moving average. I looked at it this morning. It was something like 13, 14% versus the S and P, which is about 4%. So those are initial support readings.
But that's just the risk that you take by Commodities in
[00:02:08] ODELL:
Happy Bitcoin Tuesday, freaks. It's your host, Odell, here for another Citadel Dispatch, the interactive live show focused on actionable Bitcoin and Freedom Tech discussion. That clip in the beginning has absolutely nothing to do with the chat we're gonna have today. I just thought it was kinda funny having a suit on CNBC doing Bitcoin TA. Every suit is now a Bitcoin influencer. I have a great chat, lined up for us. We have, Pierre here. Who's this? How's it going, Pierre? He is the CEO of Async, which is the company behind the Async lightning implementation.
He's behind Phoenix Wallet and recently Phoenix Server. This is awesome. I I I just wanna start off the conversation by saying, Pierre, thank you for what you and your team have been building. I mean, Phoenix Wallet is absolutely amazing. It's incredibly easy to use. It's the main wallet I onboard people with now, if they're just getting started with Bitcoin and they wanna make payments very easily. So thank you.
[00:03:17] Pierre:
Thanks for having me. Yeah. Well, we see Phoenix as a demonstrator of what what Lightning can offer. So, I like to think that what you see in Phoenix, you will be able to see that in many other implementations in the future. Maybe done better, maybe a little bit different. So it's like when we started phonics, it was the world of the future. We meant it as we're gonna try out the latest, of what you can do with lightning. And so it's it's a very it's a very good project to to work on. I'm I'm glad you like it.
[00:03:58] ODELL:
Yeah. I mean so, I mean, there's a lot of there's a lot of places we can go here. Yes. I think, first off, like, I I think it's really cool. So there's there's, there's 3 main, lightning implementations. Right? There's lnd there's 4, I guess. There's lnd. There's core lightning. There's LDK, and then there's async. And async, you guys, are are a little bit unique in the lightning implementation space because you're actually building out this lightning implementation purpose built for powering Phoenix Wallet. So how do you think about that, you know, when you when you think about what you're building compared to what many of the other Lightning developers are building out in the space? Yeah. We have 2, actually. We have 2 separate Lightning implementations,
[00:04:52] Pierre:
little known fact. The first one is Eclair, which is the one we started working on in 2015, and the goal of Eclair was to power large scale routing node. Because since the beginning, we were convinced that we didn't really believe in, everybody running a small writing at home for obvious reasons related to liquidity and security management and a lot of stuff. So we don't think it made sense economically to run a small, routing node. So since the the very first commit on a eclair, it was designed to handle a lot of channels to be maybe not very, maybe not with a lot of features, maybe not with the, all the bells and whistles, No fancy interface and all that, but very reliable, very scalable and and that's the, if if I would, if if you wanted to character characterize, our implementation compared to c lightning, LND, that would be it.
And, so we did this between 2015 and 2018, I think. And at that point, we realized that it was quite easy to make this software run on Android. That's when Eclair Mobile started. And, Eklamaobile is the ancestor of Phoenix. But then we wanted to to have this wallet run on iOS 2. And at this point, we make a we we created a new implementation from scratch. So it's inspired from Eclair, but it's it's a separate implementation. It's in it's written in Kotlin. And, and this one is focused on very lightweight, very, lightweight implementation, workforce efficient. It does not scale to a 100000 channels, but, but it's very portable. You run it on Android, you can run it on iOS.
And it turns out you can also run it on a server, which is what we did with Phoenix. So we already have 2 implementations, each with their characteristics. And and we, like, if you take a look at at what we worked on since, we started, we have basically never changed, direction and and, like, have always followed the linear path. And so everything, like, every pieces that we put together, was towards this goal, which is why sometimes, like, from the outside, you could wonder why do they, you know, spend the time and energy building aclare? Why don't they use another implementations? Well, the reason is that we had to it was purpose built for what we have what we had in mind. And we didn't want to to depend on other teams to build it.
I'm just trying to, you know, I'm going a little bit besides the the original point, but to explain why we do what what we do and why we do it that way. Is that when you work on a technology like lightning, which is evolving very fast, and you you won't want to to depend on the upstream, implementers because if if you're stuck behind someone developing, some feature that you need, then you're gonna have a hard time. You're gonna have to wait. It's gonna be frustrating. Maybe they're gonna have different priorities and all that. Our approach and with specificity of our approach is that we control the whole stack.
Right. Even before the implementation, like, down to the protocol design. And this allows us to move very fast. But it means that we have to work on all the different pieces, that we need.
[00:09:23] ODELL:
Right. I mean, I think that's key that's key to a lot of your success and key to one of the reasons that the UX is is so much better than so many other self custody lightning wallets in the space. And a perfect example of that is, like so, like, if you're an end user. Right? If you're an end user and, maybe you're new to Bitcoin. You're you're new to Bitcoin, and you you launch Phoenix Wallet for the first time, and and you buy some Bitcoin or you receive Bitcoin from a friend, and you receive that payment as an on chain payment, Phoenix is immediately creating a lightning channel for you. And then if you if you receive more money on chain going forward, that that payment is that on chain payment is automatically then spliced into your existing lightning channel. And I believe in practice, it's it's the only it's the only mobile self custody wallet that supports splicing right now, and because you guys control the entire stack. Yeah. Well,
[00:10:24] Pierre:
it's also be you know, there are there are different kind of features, and but features like splicing, they only operate at the peer level, which means that if we control both the mobile and the routing node, then we can, we we can do stuff. Some other features, for example, privacy features, network wide features, we need to wait for the protocol to be mature enough. That's why that's why it takes more time. It's not that it's less prioritized. It's just that it's much more difficult to to to deploy because, we depend on others. And, and that's more difficult. It takes more time.
[00:11:08] ODELL:
But, yeah. So am I correct that so so when when you're using Phoenix Wallet, right, there's there's one implementation's running on the phone, and then the routing the routing node is running a clear? Yep. So it's actually 2 different implementations.
[00:11:24] Pierre:
Yes. They they they share some similarities because of the same people worked on them. Right. But but they are different. So, basically, that means that when we ship something like splicing, we actually implement it twice. One more complete part on, eclair and the more specific limited part on, on the library that underpins Phoenix, which is called lightning k a m p. So that's how it works. Yeah.
[00:11:59] ODELL:
Okay. So let's, for the sake of this conversation, let's start with the wallet, and then we can talk about we can go deeper on the implementations and, like and how how you're how you're thinking about protocol development. And we can talk about Phoenix Server. I think Phoenix Server is is absolutely massive, and it's it's relatively new newly announced. It was announced last week. People seem to like it. We will I'm I'm really looking forward to see what, what is going to be built on top of it. But let's start with the wallet. Let's start with the wallet. Sure. One one of the things I like about you guys is your website is is is very clear on, like, the trade offs you make with the wallet.
You don't try and, like, hide things from the users. You you make you make specific trade offs, and and you do it intentionally. And and so so when you're talking when you're thinking about the actual Phoenix Wallet, Phoenix Wallet at red by default, all your funds are in a essentially a single lightning channel. Yeah. Do you think so? So if a user wants to make if a user wants to make a a on chain payment, they're actually doing a swap to pull it out of out of the lightning channel. Correct?
[00:13:18] Pierre:
Yes. But, you know, since the the splicing update, it has been a major change in in how we see on chain and off chain, because before splicing, like, you would be either on chain or on Lightning. And it was kind of fixed and really separate. But with splicing, the the difference between the these two layers, it's it's really, really thin, which means that you can actually spend a channel is just a UTXO. Right? It's a UTXO, an unspent transaction output. And it's it can be spent by a transaction that gives some funds to the LSP us and some funds to you, and this transaction is left unpublished. That's what the channel is. It's just a UTXO.
[00:14:15] ODELL:
Right.
[00:14:17] Pierre:
But you can spend this, UTXO directly when you in Phoenix. It's just gonna create a new channel at the same time. So you're not really, like yes. Logically, you're swapping funds, but you're actually spending the same Bitcoins that are in your channel. It is the same. And
[00:14:36] ODELL:
It's still just one Bitcoin payment now that splicing exists. It used to be 2 Bitcoin payments, basically. Right?
[00:14:43] Pierre:
No. In the previous version of Phoenix, it was simply trusted. You would send us. You would pay us over lightning, and we would make the swap. It was trusted. It was very basic, extremely basic. It was, it was, like, quite primitive, really. And, so in this, with splicing, you just span your outputs and, create a new channel at the same time. And but the thing is, I don't I don't know if you remember, but a few years back, there were a lot of ideas putting forward and people were imagining what lightning could become. A lot of them were unrealistic turns out, but some of them one of them was every unchained transaction will be a lightning channel.
And at that time, most of this idea that we are floating around, I was I was like, no. It's totally it's not gonna happen. It's totally unrealistic. This one, I was also thinking, that sounds a little bit, unreasonable, but it done that. It's ex exactly what splicing is. When you with splicing, you create a new channel with every transaction that you make. And there is no, basically no overhead when you do an on chain payment versus a lightning payment. So it's you could even describe Phoenix as an an on chain wallet with a single UTXO, so all your funds are always consolidated. That's a trigger that we we could address. Right. But, basically, you could see it as, an on share wallet with the option to spend your funds over lightning.
It's it's, it will be a fair characterization.
[00:16:34] ODELL:
Yeah. No. I mean, once you once you added splicing, it really changed the game. I mean, in terms of fee burden too, it it really changed the game. Yeah. Yeah. Okay. So let's let's talk about the trade offs a little bit. The the first thing I wanna talk about is how how you think about on chain fees. We recently had, on chain fees spike with with the different inscription, pressure and and, you know, mempools filled up, and and and we had on chain fees go up high. And as a result, your users specifically, I I assume your support request went up tremendously. And there's, like, new settings now in the wallet in terms of maximum fee and stuff like that. How do you how do you think about that? I mean, this is obviously a as someone who onboards a lot of people to Bitcoin, it's a hard thing for me to translate to a new user.
That, you know, when they receive their first payment, the Lightning channel needs to be open. They're gonna pay an on chain fee. And then going forward, if they're if they're if they're paying via lightning, they're gonna have a much lower fee. If they pay via on chain, they're going to have a much higher fee. If they don't have inbound liquidity, inbound liquidity is another piece there. Then they're going to have to do another on chain transaction. Yeah. Increased. How do you think about this? I mean, it's not an easy problem.
[00:18:07] Pierre:
No. It it's definitely not easy. So the first thing is, so during the past 6, 9 months, the fees have have been very volatile. And so it it creates issues, but it's also another an environment for which, which is pretty positive for our service. You know, there are 22 situations where, as a Lightning Wallet, you're gonna have trouble expanding your, your value to users as an LSP is if the fees are always very low, which is why during the past years, Moon Moon Wallet was a very attractive choice. Right. Because we because why not? When it's very cheap, it seems simpler. The other situation is when fees are always very high.
And then it's a problem for for the LSP because, everything is is, more expensive all the time. The intermediate situation where we are, we have been, in the past months is actually the one which is the most favorable for our business because when when fees are volatile, the service that we offer to the users is just to, like, absorb this, volatility by offering liquidity. So it's not a bad thing for us. It's it's hard to explain and to guide users, for them to navigate this environment, but it's actually the situation that is the more the most positive for, an LSP.
I don't know if that makes sense, but so it allows us basically to to tell users, okay, you're gonna have one mining fee. If you manage your requite, you're right, you're gonna save a lot of ancient transactions. And then on our side, if the money fees are volatile, that it means that sometime in the future, maybe in a few months, the fees are going to be low and then we can claim back, unused liquidity. So it's essential that that fees don't stay consistently low or consist consistently high. My my my gut feeling is that this is going to be like that in the future. A little bit like the price. It's always volatile.
[00:20:36] ODELL:
But you don't think we're gonna be consistently high in the future. Right? I don't think so. I mean, I still think it'll be volatile. Yeah. It's gonna be volatile. It's a free market. It's a truly free market. So free markets are volatile. Yeah. Exactly. Exactly. But higher than the current volatile free market Yes. In my opinion. Like, 8 like, right now, we're looking we have mempool dot I always have mempool dot space up during the live streams. And, like, next block fee is 19 sats per byte. Like, we could be in a situation where instead of it ranging from a 100 sats per byte to 5 sats per byte, it's ranging from 400 sats to byte to a 100 sats per byte, something like that. You know? Yeah. It's it could
[00:21:22] Pierre:
be. But the thing is as long as every now and then the fees go down, then it's good for us. And if they if every now and then it goes high, then it gives a very good reasons for users to to, to use a word like Phoenix or any other liking wallet. And, you know what's funny is that, so on one hand, during, at the end of the previous year, we were busy migrating our users from the previous version of Phoenix. So Right. Yeah. We had to pay for those fees. So on one hand, it was not very nice, but on the other hand, it it showcased, the, advantage of being relating to a lot of user.
And one funny thing too is, you know, so it's a small team at AC. We're just 10 people.
[00:22:15] ODELL:
Amazing. It's amazing what you guys have built with such small team. And we're doing everything including the support,
[00:22:21] Pierre:
which means that first, we are very well aware of the issues that our users have because we we do it directly. And most of the customer support that we had to do, at the end of, previous year was not related to Lightning. It's actually related to people having trouble with block time and confirmation time. Right. So that's interesting. So whenever you, somebody somebody says, you know, like, it's too difficult. It's too complicated. That's not what we experience. I think it's because since failures on Lightning tend to be, immediate, like, maybe you're not gonna found find a route, to make a payment, but that's the kind of error that the users can understand. And, they are they, they can deal with that. But having a transaction and transaction linger for weeks, they don't like it at all. And they don't understand why, why, why it could happen. It's confusing.
Yeah. It's confusing. And, so, those those volatile manifest times, it's quite interesting to to to live. So,
[00:23:32] ODELL:
yeah. I mean, I think it's it's really I mean, like, so I personally run, 5 lightning, you know, full nodes. And then I also I I have, you know, like, my my I I do use Phoenix Wallet. Like, Phoenix Wallet is awesome. I, you know, I might have been in the beginning. I might have been in the camp where, like, I thought a lot more people were gonna be managing liquidity themselves, running routing nodes, doing all these things. But I think it's kinda interesting with Phoenix Wallet is is there there's, like, an argument for a, like, more like, even even a more technical user to just send, like, a large amount, like, a large UTXO in and then just, like, use that as their spending wallet and not have to deal with any channel management or anything. Yeah. And in in that situation, like, the on chain fee burden doesn't really matter to them. You know, like, let's say they're they're sending in, you know, $3,000 or $4,000.
Like, what the on chain fee burden is fucking negligible in that situation.
[00:24:41] Pierre:
I think most users, most Phoenix users do not realize that, the splicing feature and the fact that their funds are consolidating into a single q UTXO, which is, again, a privacy trade off that we can discuss, they're gonna be very happy with that once Right. The average money fee is going to be higher. Like and that's a major difference. That's why that's why, splicing really is was fundamental change is that before that, some users had literally hundreds of channels, and they they were not even aware of it because a lot of users don't don't understand how it works at all. And, this was this was a real issue for them going forward. So now it's, it's future proof in a in a sense. So so that that's that's why it was a really, very, important.
[00:25:37] ODELL:
But where I was going with that is, I wanna go a little bit into, like, how you guys are so, like, I I think it was a little bit you probably were getting a ton of support requests on on large fee amounts. And then you added this, like, the fees section in settings, like, the channel management, where it's like a max fee amount. Like, is that do you think that is, like, a a temporary stop gap solution? Because it's a little bit hard. It's a little bit confusing. Like, they receive their first lightning payment. The thing is And, like, what if I'm sending them if I send them a large lightning fee payment, a lightning payment, and they have to open their first, you know, they have to open the channel, and fees are high on chain.
It's like an absolute amount. Like, how do you how do you think about that? Do you know what I do you know what I mean? Yeah. Yeah. I mean,
[00:26:31] Pierre:
we wish we could do it better. Before we introduced this, we had a fixed 1% fee on receive Right. Plus 3,000 sets. And, this had the advantage of simplicity, but You were getting killed on on chain fees. Yeah. It's it's just a risk. It's just a risk. I mean, we were doing great when fees were low, but it's just a risk. And the the the main change that we made was to just push the money fee to the users. To us, it's just a matter of managing, risk. And once once you do that, you you cannot just, exchange Auto charge them. Yeah. It's it's it's very difficult to, to to put to put in in one sentence what's the cost is going to be.
And so, obviously, we are, you know, trying to to the the the way it is done currently is not final. We are we are we are thinking about it every day, but, the goal was to offer, more advanced users a way to fine tune, their fees to the very minimal, which is why, you know, you're gonna have Phoenix users who say, it's too expensive. I'm getting killed by fees. It's, it's nonsense. And you're gonna have all that who gotta say, it's awesome. It's almost cost me nothing. So our our because they're using it the correct way. And our goal is to find a way in the UX to make the users understand how it works and But there is a level of, understanding that you need to have, which by the way, you must have the same kind of level of understanding at the on chain level 2 if you don't know what's a new tool. You're gonna have issues with, with mining fees. You can get killed a bit in the same way.
So it's a very difficult problem.
[00:28:24] ODELL:
But Especially since I mean, so many people have been, like, conditioned on custodial wallets, especially newcomers. Like, I I like when I try and transfer someone over from, like, Wallet Satoshi or something, they're like, I'm getting charged so much more fees. And it's like, yeah. Well, you know, you actually have a lightning channel. Like, you're actually holding self custody of your funds. Well, you know what? If you look into the fees, it's not like try to make an unchanged transaction from White Ops Satoshis and compare to the costs we sell. I know. I'm aware. I'm saying, like, the educational it's, like, it's just hard to translate that to the user, especially if they're a new user. Yeah. And it's a difficult problem.
[00:29:00] Pierre:
But, no, on the unchain feeds, when you make unchain transactions, it's actually interesting how Phoenix is more efficient. It's not less expensive in Phoenix because we made a particular effort on fees. No, it's just because if you pay for UTXO, then it's easy for you to spend it. Whereas if you have a custodial wallet, they're gonna have to manage the hot wallet, and it's it's really, really difficult to manage your hot wallet and let users spend from your wallet. It's very, very difficult. That's why it's expensive. Yeah. I,
[00:29:31] ODELL:
yeah. I I I so, the reason I bring it up is because, yeah, it I was just gonna be and when you first implemented the feature, it was like the default was a certain amount. It was, like, an absolute fixed amount.
[00:29:48] Pierre:
It is for it's I think by default, it's 5,000 satoshis.
[00:29:52] ODELL:
Which, like, what is that what is that sat per byte rate where that gets hit? Do you know? It it's it's an absolute in, satoshis,
[00:30:02] Pierre:
because,
[00:30:03] ODELL:
But shouldn't it be percentage?
[00:30:07] Pierre:
You you have both, actually. There is I mean, the fact is the the real cost is absolute. It's an unchain fee, so the real cost is absolute. So it doesn't make sense to to put it, to have the main setting be relative, but you could, put a very high amount and there is also a relative in the advanced setting somewhere. There is also a relative check. Yeah. I see advanced percentages. Our approach to it is there are so many, you know, side effects, and so many stuff going on that you don't want to be too far from the reality. And the reality is the cost is independent of the amount. So if we if we don't want to have too many headaches, that's the easiest way.
[00:30:55] ODELL:
Fair enough. I just know when I was onboarding in the higher fee environment, I was just literally I before I would have them send into the wallet, I would go into settings and just jack up that. Yeah. It was like an it was they were like, what are you doing? I was like, you gotta go into settings. You gotta you gotta increase this amount, and there was but there's no easy answer. I don't pretend there's an easy answer. Well, it's,
[00:31:19] Pierre:
we we we have introduced a feature related to that in in the phoenix, release. Maybe we'll talk about it later, but it's related to that. It's bay it's it's the feed credit. Is it's a way for for to to aggregate amounts, before you open the channel. You know, like you cannot onboard a user by sending him a 1,000 sats if it costs a 1,000 sats, in mining fee. So the idea is to say, okay. But what what you're actually going to do is you're gonna pay for WAN and you're gonna pay in advance the LSP to just put the amount aside and take it from your future mining fee. And it's a bit like custodial without being custodial. You trust us because you're paying advance, but those are not your fans.
So it's kind of a gray gray area in in a regulation from a regulation point of view, but I think it works that
[00:32:19] ODELL:
way. Yeah. That makes sense. Okay. So let's talk about continuing the trade offs. The major trade off with Phoenix right now is privacy trade off, and you're very clear on your website. But you wanna just discuss, like, what what kind of information can Phoenix see if I'm a Phoenix user?
[00:32:39] Pierre:
So we can see if you if you don't use store, we can see your, your IP address because you're connecting directly to our node. Right. We can correlate since you are we are the only node that you're connected to, we can correlate your transactions, obviously. I mean, we we see how much beacon you have in your wallet because they are on the other side of the channel. Right. But that would be this is not a specific trade off of Phoenix. It's a specific trade off when you're connected to a single node.
[00:33:22] ODELL:
Are you keeping track of, like, so, like, if I if I open Phoenix and I pay a lightning address, right, you can pay 2 lightning addresses, and I pay, like, Odell at at voltage. Are you keeping track of those, which lightning addresses you're paying? Are you keeping track of the memos of those addresses? Like, the memos of those transactions?
[00:33:51] Pierre:
We don't have access to that because the resolution is done on the mobile.
[00:33:55] ODELL:
But we keep track of the the payments. Like, with the endpoint, where it goes, which node it it ends up. So
[00:34:05] Pierre:
what what we need to do as, routing node is we need to allocate our fans. We need to know where to allocate them. Right. So it's very so we have to to see where, we should put our funds so that it's it's more reliable. One important thing, in Phoenix is that, it implements trampoline routing. Trampoline routing so the the default routing, in, lightning is called onion routing and it's just the the source when you make a payment from a to d, the source computes the route from a to b to b to c to c to d. And then makes an onion and intermediate routing node. In my example, it would be b and c. They don't know where the payment is going. They just forward it from the previous node to the next node.
The idea of the temporary routing was to do just that, just the same. It's a nonlinear routing too, but, like, if you want to pay from a to z, the source of the payment, they would not have to find the whole route because this requires them to know the whole network table which changes constantly and is a pain to to sync and all that. It slows down the UX of the transaction. Exactly. So the the goal they they only need to to select a few intermediate nodes. Like, they would say, okay. I want to, I'm gonna use a route, I don't know, f, n, and p.
And, and then this intermediate node, this trampoline node, that's up to them to find the route between themselves. So it's the same, it's very similar but at a higher level. And so we came up with this idea of taupelyn routing a few years back and, we we we thought it was a really good way to offer privacy for mobile lightning wallets without having them sync and be aware of the, whole network table all the time. That's where the the I'm just saying that to explain where the current, state comes from. And but as about as I mentioned earlier, some, protocol features involve the whole network, and that's the case for trampoline.
The whole I mean, a lot of the nodes in the network need to be trampoline. They need to understand this protocol for this to work. And when we started, we were pushing this feature and only us were supporting this. So what what Phoenix does generally is a trampoline routing, but with only 1 trampoline node. So the destination is always known to us because we know they're not gonna do any more hops. And was that the LSP? Yeah. So that's, that's why currently we know the final destination of, all payments.
[00:37:03] ODELL:
The idea was this to be a first step to work. But if other routing nodes add trampoline routing, then you won't know the final destination.
[00:37:11] Pierre:
No. They don't. Because between between property nodes or between the last property node and the destination, which is the case in Phoenix because the first property node is the last property node, it's normal Lightning payments. So so yeah. This is going to be majorly improved, very soon with the introduction of the daily path. That's a more technical feature. I don't know if you want to address right now or later. But, We but we're on the topic. Let's talk about blind Alright. So blind blind blind blind blind blind blind blind blind blind blind blind blind is is a way for the recipient to to to to give, the end of the route or a few sets of routes, the last part of the routes to to pay them, which means So it's in the invoice? Yeah. It's the it's it's in the invoice. So from Phoenix, if you would pay I don't know. You would you want to send your money to to any any place. You wouldn't you would not to Bob, say. You would not send the destination bob to our node. You would say you would send an entry node, which is a few nodes before bobs. And our job would just be to route the payment the payment to this entry node, and then the last remaining hops, are already computed.
And so it's it's base it's it's resembles, what we wanted to achieve with the original temporary
[00:38:52] ODELL:
payments. So is LND implementing this?
[00:38:55] Pierre:
I oh, you will have to ask, Bastian for the exact, but I think yes. So this is this is related to, to bolt, 12.
[00:39:06] ODELL:
Oh, so l and d isn't implementing. Yeah. Yeah. I don't know exactly how how far they are, but, yes, they are more important. Okay. Well, I definitely wanna talk about vault 12, but let's continue on the wallet just real quick here because, I just wanna go through the trade offs on the wallet. Sure. So, I mean, right now, that that main trade off, then you know the end the real the the key reason for the end user for that privacy trade off is that Phoenix payments are almost instant. And if you use, like, a Zeus wallet, where where they're computing the whole path locally, is when is when you kinda sit there and you make the joke. You're like, oh, look. The future of finance. And you're, like, sitting there for, like, 15, 20 seconds while your payment goes through. Yeah.
And and so Phoenix makes that trade off so that
[00:39:55] Pierre:
so that the the payments are just like it's it's literally just like a snap of finger. It's it's crazy how quick it goes. It's also more reliable because you could, like, try some routes, but it changes all the time. The availability of routes, the the amount of events available in each channel and so on, it changes all the time. So our point of view in this is okay, yeah, we know the destination, but let first, comparing to making a simple on chain payment, is still in my opinion, it's still much better. Right. And
[00:40:31] ODELL:
and also it's so easy I mean, if it's an on chain payment, you would know the I mean Yeah. I mean, everybody would have that that information, basically. Everyone has a destination.
[00:40:40] Pierre:
And, and also, there is there are no KYC, no subscription. So you can open a new wallet as you want. So what does this really mean for us to know the destination where you can change your identity whenever you want? It's it's not as valuable as, as, like, having, the user stuck in 1 user ID or user account, and then you can correlate everything that's related to it. And, and also what what it allows us, and it's very important for UX, is a predictable fee for sending. Because one of the critics that we had in our, previous, iteration of the wallet was. I don't know how it's going to how much it's going to cost me when I send the payments.
And
[00:41:31] ODELL:
Oh, yeah. It's great. It shows the fee ahead of time. Exactly. And that's, that's that's important. Okay. So the next thing I've I've gotten you know, I just love Bitcoin, and, I want Bitcoin to be as useful to people as possible and wide variety of users. And I live in the heavy technical world of bitcoin a lot, but I also live in the the the newcomer world a lot. I have a lot of exposure with people that are are relatively new to Bitcoin. And one thing I've gotten a little bit of heat for lately is I really like the fact that you can back up your iOS Phoenix wallet to Icloud, which is just I mean, if you asked me 5 years ago, 4 years ago, I would have been like, fucking hell no.
But it's it's a very easy way for a new user to back back up their wallet without dealing with seed phrases, without dealing with actually storing the seed phrases securely, with making sure that they're still there. If they lose their iPhone, they can just easily log back in and and have their wallet. Now when you one of the cool things you guys do is when you go to initiate iCloud backup, you give, like, really clear scary warnings, as you enable it. What are the real risks there in terms of a user that is, like, using the iCloud backup feature?
[00:43:04] Pierre:
Well, on the top of my head, but, I would need to double check with our iOS guys. The main trade off is that if your Icloud account is compromised, then it's not good for you. Whereas if, like, on on Android, you there is no Google Drive backup, Right. Then you're safe from that. So
[00:43:30] ODELL:
So, like, if you're if you're storing, like, nude pictures of yourself in Icloud, like, there's probably you're probably cool with with with storing your wallet in Icloud. Right? Like, I mean, like, it's I when I read the when I read the things, it's like Apple might compromise you.
[00:43:46] Pierre:
Yes.
[00:43:47] ODELL:
But it's encrypt it's technically encrypted, the backup. Yes. But
[00:43:53] Pierre:
if you have access to your if somebody has access to your hack like if because if you have a very weak, password, if you have a very weak hack like that password, And people are usually terrible at passwords. So, that's the trade off. Yeah. I mean,
[00:44:10] ODELL:
the warnings are, like, very I mean, they should be. I I applaud you for putting scary warnings there. But I think it's very compelling for a lot of people. I mean, I think,
[00:44:23] Pierre:
The the reason we did it on the iCloud and on the Apple and not on on, Android is that on Android, we by default, you don't have access to Google Drive. So this would require, to ask for permission, and that's, some people don't like Google Drive. So
[00:44:43] ODELL:
this feature is only available on, on Apple for now. Yeah. Well, I mean, what I see with most people is, like, most people are more likely to lose their money than have someone steal their money, and most people are are unlikely to be, like, a high value target that, like, Apple would presumably, like, try and attack. And Apple takes pretty decent lengths to protect Icloud from, you know, general attackers because of the fapping that happened when all the celebrities nude photos all got out, which is not good for Apple's business. Like, they don't want nude photos getting out. So the protection they provide for the nude photos, they're kind of providing for the phoenix backup. And for me, like, that flow, that process of getting someone new to Bitcoin, and I don't want them to use a custodial wallet, I onboard them on a Phoenix wallet. I have them enable iCloud backups and make sure they read the warnings. And I explain to them, like, you know, make sure your iCloud password is is secure password.
They also have some, like, ridiculous two factor that is, like, very opaque and hard to understand, but apparently works reasonably well. I I it just seems like a good trade off balance. Like, I I've I've known so many people who've lost seed phrases, particularly for their first for their first wallet, and and and I I think it's a a a a good UX flow. Awesome. Okay. I think we got through
[00:46:18] Pierre:
the wallet trade offs. Yeah. There is one trade off that you have not mentioned, but it's a recurring question for us is why don't we allow, users to connect to different nodes? I know. Why not? It's funny because most people think that it's because we want to capture all the all the payment fees, which is not the result it's not the reason at all. The reason is that. There are 2 reasons. The problem are incentives. That's the main reason. You don't want to develop software and put software out for users to to use and then have users connecting to random lightning nodes. So if they're using your software, you're not part of it. You're just providing the software, and then you have to, and then they're gonna do whatever they want and connect to nodes as unreliable as possible.
When they're going to encounter issues, who are they going to turn to turn to is going to be to you because you're the most sales actor in this in this message. Why are my payments failing? Exactly. So we don't want to be stuck doing support for user of the tile using, nodes that we have no power over, no control over because it's just a nightmare. You don't want to do that. It's just going to be wasting a lot of time and a lot of effort. So that's the main reason. If if users were competent and, like, we could we could do as many warnings as we could. It just doesn't work. We we we actually did this before with Xtra Mobile. You could correct me. So we know what that is, and we don't want to do that.
It's not about the physical. The the the,
[00:48:03] ODELL:
yeah, sorry. That's what I was about. It's about the user experience. You wanna be able to provide a good
[00:48:10] Pierre:
reliable user experiences. Yeah. I mean, we don't want to be stuck because this is complex tech, and you don't want to be to be stuck in the middle. It's just a problem with incentives. Yeah. I mean, I I yeah. Yeah. Go on. The other very important reason is that one of the the main service that we provide is, is, liquidity and specifically on the flight channels. And, I I discussed it with the, Blockstream guys when they were working on Greenlight is. How do you know how can you tell if the users is lacking liquidity if you don't have the total view of their channels?
You know? Maybe you cannot receive the payment, using the channel that you have with async, but maybe your Phoenix has another channel that you're not aware about. So why would we charge the user something if it could can go to the to the to, another direction? So to me, we can we cannot offer both connecting to, many nodes and on the file liquidity. I don't see how that can possibly work. It's going to to be very hard to explain. So those are the actual reasons.
[00:49:26] ODELL:
Yep. That makes sense to me. Okay. So, I guess before we leave the wallet, I have two questions relating to Gnoster. How how, attentive are you to the Gnoster ecosystem? Are you familiar with Gnoster Wallet Connect? No.
[00:49:44] Pierre:
No. I I know that, some people want us to do something with that,
[00:49:51] ODELL:
But, I don't know exactly what that is. And Okay. So Nasr Wallet Connect is, like, in Nasr. Right? We have the ability to send Zaps. Right? And, you know, lightning payments to users within within a Nostra app. Right? And nostril WalletConnect, basically uses nostril, as a communication protocol back to your LSP that says, like, I wanna make these payments. So, like, right now, if I'm using Phoenix to send a Zap, I have to I have to leave the Nostra app. I have to go back into Phoenix. It, like, automatically opens in Phoenix, and then I have to approve the payment in Phoenix. But if you use Nasr WalletConnect, those payments all get queued. And next time I open Phoenix, Phoenix can have, like, a threshold where it automatically makes the payment, or it can ask me, do I wanna make the payment at that moment?
So it basically just uses nostr as a communication as a communication protocol, which that is what nostr is, a secure communication protocol, to to allow you to queue payments for all sorts of things. And now people are using it for subscriptions. So like Geyser Geyser Fund, you can like you can set up, like, almost like a Patreon level subscription where I wanna, like, I wanna send 5,000 sats every month. And, basically, guys are sending this Noster event to to Phoenix. And then when I open Phoenix, it's like you have these subscriptions, and I can, like, immunity wallet has kind of been ahead of the game on that. And, like, so they Yeah. So You can set, like, a threshold. You know? You can set a threshold. Like, every day, I wanna auto approve, a certain amount, for this one app so that I when I open up Phoenix, it just automatically makes those payments, essentially. Okay.
[00:51:42] Pierre:
So it's essentially just, Phoenix embeds the Northstar client. Right?
[00:51:47] ODELL:
And reads Into the LSP. Yeah. Okay. Look into it. Cool. And then the other thing is using, like, Nostra contact lists for like, so you can have, like, a I don't know if I mean, you're in France. I don't know if you know, like, Venmo or I I assume, like, Revolut and, like, the European based ones have it. But, like, basically, I can just, like, open it up and be like, I wanna pay Marty, and Marty's already my Noster contact. So he has a Lightning address set up, you know, so I it linked to his Noster account so I can just, like, easily import my Noster contacts to pay people. Those are two
[00:52:24] Pierre:
different things. On the on the more general payment front, our immediate focus is bolt 12, which is a
[00:52:32] ODELL:
major milestone. Perfect. Let's talk about block 12. Yeah. So, I mean,
[00:52:37] Pierre:
these these features that you're mentioning to me is, like the cherry on the cake once we have the big infrastructure working. So
[00:52:48] ODELL:
Well, let's talk about Bolt 12. Like, where are we on Bolt 12? How are you thinking about it?
[00:52:53] Pierre:
So Bolt 12, we have as for everything, we have to implement it twice. Remember, once in a clear, once in the lightning KMP. So Right. We have done it in a clear a few months ago, and we are currently doing it in the Lightning KMP, so in the Phoenix. I think it's a matter of weeks, months. Let's say more of a matter of a few months. And the so the the what it offers you basically, it's a static address. It's like your old beacon address that you can put everywhere on your, wherever you want, and it doesn't change, and it allows you to receive lightning payments. And, it's it would make the Phoenix server demo even more nice because basically you just start the daemon, it just prints, an address and then you can put this and like for, to receive donations, like, donations on the on on wherever, it's so simple. You just put your Finnish server somewhere on your node. You don't even need to to to, to bother with firewall or whatever. It just sits somewhere and connects to the Internet, and then you can paste your your static address and receive, receive it.
It's it's the same UX basically as a regular beacon address. The thing is and it's it uses a lot of tech because what it does essentially when you pay a static address like this, your your the sending wallet is going to ask is going to go through the Lightning Network. It sends a message. It's not a payment. It's a message to to reach the destination node and ask for an invoice, and then it's gonna pay the invoice. So there are 2 round trips, which also had the added benefits that it's kind of like a probing, like you can check whether the destination is whichever before asking the invoice. A lot of, lightning products currently do actually manual probing.
This allows us to wake up the mobile in the case of Phoenix because we know that the payment is going to happen. Like, so there are a lot of
[00:55:17] ODELL:
Right. So does that mean I can receive if I don't have the app open?
[00:55:22] Pierre:
It's already the case. You know? You can try to turn off Phoenix. I mean, to generate an invoice, to share an invoice and then turn off Phoenix. It's gonna wake up just in time Got it. To receive the payment. But the problem is that you still have to generate an invoice for that payment. Right. Every time I gotta generate I gotta open that, generate an invoice, send it. So in the case of Phoenix, we're gonna wake it up, just in time, to to create the invoice. This is going to to happen automatically. You won't be, no interaction necessary at that point, and then, the payment was going to go through.
So yeah. The goal is to have a very, very similar experience to, to receiving a bunch of payments.
[00:56:07] ODELL:
So, like, I mean okay. So I'm, like, I've been excited about Bold 12 for many years now. Like, how close are we from that experience actually happening?
[00:56:22] Pierre:
Oh, yeah. We are close. I mean, we are if I mean, we well, we we don't we don't have the habit to make announcements of announcements, but, that's what we are working on currently. That's our main next main, raise feature. The the only thing is that this is network wide. So just because Phoenix supports it doesn't mean that you can do We need the sender to support it and the routing We need everyone to support it. We need everyone to support it. Like, I don't know if you have been using, Kraken with auto lightning feature, but you have to to to input a new invoice every time you want to make, to send parents of our lightning.
That's really that's great. So Yeah. Yeah. We would need them to implement that too and all the exchanging on that. So that takes time. Like, specifically, the sender side needs to be able to support. Yeah. I mean, the sender side, but also the network because, you know, it's it's, it uses onion messages. So messages has to be have to be routed in the network. We can skip some nodes. Not everyone has to update, but it's it's better if, you know a large amount, a decent amount for reliability reasons.
[00:57:41] ODELL:
Okay. So Phoenix server is this idea of taking the ease of use of Phoenix Wallet and putting it in an always on server environment. Yeah. Let's chat about I mean, because you released this last week. I mean, on the surface, it seems, absolutely massive, incredibly useful to a lot of people, particularly, you know, this idea that you don't have to worry about inbound liquidity, that that you guys handle that automatically, for the end user. Like, what's the quick what's the quick pitch on Phoenix Server? Like, how do you how do you think this is gonna affect kind of the the Bitcoin landscape?
[00:58:22] Pierre:
So basically, it's just, it's exactly like Phoenix mobile except that you interact with it not with pushing buttons on the on the on screen, but just sending HTTP codes. So it's it just bring the ease of use of, Phoenix wallet, but for developers who can build any lightning connected, services. And we have added a few features, around because a lot of these potential applications involve receiving. It's it's often receiving more than, like, from merchants receiving more funds than sending. It can be both, but so we added some a few features to make it really completely transparent. So you for for developers, it allows you to interact with lightning with absolutely no headache. It's like exactly like you would if you if you build a traditional merchant website, you would plug into Stripe and then I like so like 2 ifttp calls and and and one callback.
It's exactly the same and in an in a cost effective way. So we made like for Phoenix, so what if we make all the trade offs except the one that is self custody. So we allow ourselves to to to to to do some trust, but we put the limit at self custody.
[00:59:56] ODELL:
So, like, a new merchant could could run this, and they just start immediately receiving lightning payments. They pay you 1% as the LSP, and that's that. Exactly. So not only is it easy,
[01:00:07] Pierre:
from an integration point of view, but you also benefit from the well known reliability that Phoenix offers. So when you when you use, Phoenix server to receive payments as a merchant, you your your inbound liquidity is the inbound liquidity of the async like node. So you can you're not gonna have any issues, around that. I mean, so it's a great burden to remove off your shoulders if you want to receive funds on anything. Wait. So right now with Phoenix Wallet,
[01:00:38] ODELL:
I let I let's say I put I put 10,000,000 sats into Phoenix Wallet, and I have 10,000,000 stats of outbound liquidity. But for inbound liquidity, I have to pay an on chain fee when I need to increase my inbound liquidity. How is that handled on Phoenix server? Like, am I not in that situation? Am I not, am I not paying that on chain fee?
[01:00:59] Pierre:
So on Phoenix server, let let's let's do the the actual steps. What's going to happen if you start with not with a brand new wallet. Okay. Brand new wallet. I'm a merchant. I have no Bitcoin. I won't accept Bitcoin. So you just you start the daemon. Okay. Then you're gonna use the API to create an invoice. Then a payment is going to arrive. At that point, if the payment is, more than the mining fees required to create the channel, then a create a channel is going to be created and, the mining fees are going to be are going to be deducted from the amount you receive. Okay. But and in the same operation, we are going to also add inbound liquidity, with the default of 2,000,000 SATs, with a 1% fee.
Okay. Okay. So this, we are gonna do 1 unchain transaction. It's going to create a channel. It's gonna give you a lot of inbound and that's it. That's the easy scenario. Now another scenario where
[01:02:07] ODELL:
What if my next so then okay so that happens, and then someone walks into my store or goes online to my store and then pay tries to pay me 4,000,000 sats, Right? More than my inbound liquidity. What happens in that situation?
[01:02:20] Pierre:
Well, in that situation, it's gonna be the channel is going to be too small. So another on chain selection is going to be required. You're gonna receive the 4,000,000 in that, operation, and you're gonna have add also 2,000,000¢. So the merge the merchant's still paying that on chain fee, though. Right? Yeah. They have to pay it. But the thing is so if your average, if your the average invoice that your customers pay is 2 or 4,000,000 SATs, you will then want to increase the default liquidity amount to be much larger than that. Otherwise, it doesn't make sense. You're gonna have to pay on chain fees all the time. On the other hand, if you receive that amount, the the weight of the on chain fees is quite low in relative terms.
[01:03:04] ODELL:
So Right. It's up to you. But basically So in practice, it works very similar to the actual wallet does?
[01:03:10] Pierre:
No. Because I mean, yes. It's similar, but it's not exactly the same because on Phoenix, you wouldn't you you are not currently able to request invalid query at the same time as, creating a channel or a splice. So it requires 2 transactions. That's a major difference. And the other major difference is that let's suppose now that so you start from nothing and you you try to receive only a 1000 sats. It's not enough to cover for the unchanged production. On the Phoenix mobile, we would simply reject the payments because it's too expensive. Like, it we it's, the main fee is too expensive. You cannot cover the cost with this payment.
On the Phoenix server, this amount goes to your, what we call a fee credit. It's gonna be used to pay future money fees. That means that if you're if like, typically, I guess that on NoStar, the typical tip is not going to be 2,000,000 sat. It's gonna be much smaller than that. Right. In this situation, then all the small tips would aggregate. And as soon as you reach the amount needed to open a channel with 2,000,000 sat inbound liquidity by default or possibly more if you configure them differently, then you're gonna end up with a big channel and receive all the future tips in this channel.
[01:04:27] ODELL:
And you would have And then you take out the fee credit at that point.
[01:04:31] Pierre:
Exactly. And so the the all the small tips that, would have been rejected on Phoenix mobile, They are taken and they are used to pay the mining fees. So, every single Satoshi that you receive, it's not lost because it's it's going to pay to contribute to paying this the fee for your channel. That's a major difference because it means that you don't have to worry about, you know, threshold effects. Everything appears to be linear. So you can, as a merchant, you don't have to to pay attention to these details at all. You just have to to think in terms of relative fee total fee. And our goal is to bring it as close as 1% overall as possible. And it's you can see the the the calculations in our website. But basically, it's it's between 1 2% depending on your settings and the
[01:05:27] ODELL:
mining fees. Got it. Now am I correct to assume with the focus on bolt 12 that that is there any priority now with this with this Phoenix server, is there any priority to add lightning address support to that?
[01:05:46] Pierre:
We want to add something that's I don't know if you, came across the, the, the DNS proposal, from Bastian that, he put together. I think it's end of 2023. Basically, we want to offer something functionally equivalent to, to add an address, but much more private. The problem with lightning address, it from a functional point of view is great, but it leaks a lot of information about the sender and the recipient. Because you're asking your server and you the sender, when like, if you're an LSP like us, if you if we run a lightning address service for our Phoenix users, then whoever wants to send the payment to a Phoenix users for to a Phoenix user using their lightning address would reveal their IP to us, the IP address to us because they would have to contact our service.
And they would and yep. So that's a big problem. And so there are privacy issues with that, and we believe that, leveraging bot 12 and static addresses, we can match make much, much, much, better, technical solution, which is also exactly as easy to integrate for, for everybody who wants to to play with that because it's just a static information. So you just have to resolve it using DNS or using whatever you want and, it does exactly the same. So that that's the reason why we haven't, supported lightning address. It's not related to not being able to wake up Phoenix because we already do it when we do a regular lighting payment specifically because of, privacy concerns.
And Right. Because right now in Phoenix, well, I can send a lightning address. I can't receive to it. You can send because if you want to send, that's your problem. We, your Phoenix is going to contact the, the whoever is the server. The web server. Yeah. So you're responsible request an invoice. Exactly. But we don't want to have that information ourselves. So that's why we don't offer this feature.
[01:07:59] ODELL:
And if I have Tor enabled on Phoenix Wallet and I'm paying a
[01:08:04] Pierre:
lightning address, then it's going through Tor when it requests that. I believe, yes. At at the very least, if you have all bot on your phone, yes. I will have to double check, but I I believe it's
[01:08:15] ODELL:
Okay. That makes sense to me. Bolt 12. Hopefully I mean, I had Steve Lee on the show a couple weeks ago, and he's quite optimistic about bolt 12, from the LDK side. So Yeah. Yeah. They are
[01:08:30] Pierre:
definitely moving forward with this.
[01:08:33] ODELL:
Awesome. Yeah. I mean, I think this has been a great chat. I mean, we're a little bit over the hour mark now. I think, I think Phoenix d like, this Phoenix server idea could be quite it seems quite compelling. It's like, for the donation use case, for the merchant use case, I can see it being implemented in BTC pay server to make it quite easy for people. That that would be the perfect use case. I mean, that definitely
[01:09:03] Pierre:
really for to as a way to to just try out, recently letting payments, for not a reasonably sized business, let's say. I think it's really, really, very, compelling, offering.
[01:09:26] ODELL:
Awesome. I have I have one last question for you, actually. And I was like Yep. Going back to I guess it's it's it's relevant to both Phoenix Wallet and Phoenix server. So let's say, like, worst case scenario it goes back to trade offs. Worst case scenario, the phoenix the phoenix node goes offline, for whatever reason. We don't have to speculate for for why it happened. But everyone, you know, they they have a channel open with this with this node. How does the end user you know, I have Phoenix Wallet. I have 10,000,000 sats there. It's in a channel with the Phoenix LSP node. That node goes down. How does that look for the end user? Okay.
[01:10:09] Pierre:
So firstly, before that, that everybody needs to be aware is in the security model of Phoenix, you need to have Phoenix installed on your mobile or one mobile that you own with connecting with access to the Internet all the time. It's not a code storage wallet. It has to be able to to, access the blockchain once every 2 weeks. That's very, very important because, so as long as you have this, then you're safe.
[01:10:41] ODELL:
Otherwise, you could broadcast an old state and take the money. Yeah. Or anyone who has access to the node. Yeah. Exactly. And, and also, this means that you have the
[01:10:51] Pierre:
the you you can first close the channel whenever you want. Maybe we're offline or maybe we are I don't know. We have been compromised or whatever. For some reason, you want to to just it's a way for you to fire us basically as an LSP and just take your money back. So so the way I see it so let's say one day we we go down or we we just go offline and don't respond any anymore. Business goes out of business. Yeah. Exactly. If, I I would imagine it's a more problematic situation because if we just go go out of business, we would prepare it. Right? Right. So this is just And I could be assholes about it. Exactly. So let's say we're just, we do just disappear from the from, from the Internet. Right.
As long as you have your mobile with finish install, you're safe. You you you don't have to panic. You you you you're gonna have to force close your channel at some point. It works like just a normal force close? Exactly. You don't have to do it right away. I imagine that some people would take over or fork our code and, make a nice tool to to help. I don't know exactly, but there is no rush. There is no need to there is no, like, delay that you need to count before money is lost or whatever. Because what Phoenix shows you and and you every user should, if you want to, understand how this works, go to the channel details, and you're gonna see your UTXO, and it's yours. And in your channel data, you can see the commit plan transaction. It's it's the transaction that if you publish, it's going to spend this UTXO and give you money back to your wallet. As long as you see this UTXO, you see this transaction, and you know you can publish it, you're fine. So,
[01:12:40] ODELL:
So if I if I go into the payment channel settings on Phoenix and I press the close all button or the force close all button,
[01:12:49] Pierre:
what happens next? I haven't pressed that button yet. If you if you press the close button Yeah.
[01:12:55] ODELL:
It's just going to be a mutual close, which is What where what on chain address does that go to? Because every time I send to an on chain address in Phoenix, it just automatically splices in. So Yeah. It's going to be,
[01:13:09] Pierre:
an on chain address derived from your seed following, BIP 84. Okay? So you just, use any normal standard on January, you're gonna find your fans in there. Got it. If you first I used to, like, import it into Sparrow at that point, and it'll be in Sparrow. Exactly. Yeah. Exactly. If you first close your channel, that then it's not going to go directly to your on channel address because you have there has there is a delay. The same delay 2 weeks delay that we have on our side, to protect, users from fraud from our part, there is the same delay for Phoenix. It's it's smaller. It's just 5 days instead of 2 weeks. But for the same reason, we need to protect ourselves against our users too. So you're you're gonna have to wait for 5 days before the funds go to the wallet. And during these 5 days, the Phoenix needs to be installed because it it it needs to be able to publish the transaction that that finally sends the funds to your personal wallet. So basically, never uninstall Phoenix as long as you have not recovered all the funds, and you'll be fine.
[01:14:18] ODELL:
Got it. Okay. That seems pretty straightforward. Pierre, this was this was a great chat. I really enjoyed it. I really appreciate what you and your team have been building. I mean, there's a lot of us there's a lot of us out here that that rely on on what you guys are building, and and you guys have really pushed the industry forward. Thank you. Do you have any final thoughts before we wrap?
[01:14:43] Pierre:
I I think, you know, without being a lot of changes, in, Lightning and Infinix over the past year. Bolt 12 is going to be a huge milestone. Now one of the, updates coming up, it's related to Taproot. We have done one part with, the swaps, but the channel, transactions are going to be taboot taboot 2, which means that footprint of, your wallet is going to be it's not going to stand out on the blockchain as much as it does currently. So the technology is maturing. Phoenix is maturing. And Like right now, it's pretty obvious that it's a Phoenix wallet. Right? It used to be obvious that it's Phoenix. Now it's obvious that it's a Lightning wallet.
And after that, it's just going to look like, like a a stand out p 2 p 2 tr wallet. It's not particularly private, but it doesn't stand out. So it's a huge all the privacy features that we unfortunately, that those are the most difficult to do. So they they come at the end, but they are they are finally, yeah, definitely coming.
[01:15:57] ODELL:
Awesome. Well, thank you again. And, you have my contact information now. If I can help in any way, don't hesitate to reach out. Cool. And,
[01:16:08] Pierre:
it was a pleasure. Thank you for having me. Bye.
[01:16:11] ODELL:
Awesome. Thank you, Pierre. I wanna do a huge shout out to the freaks who joined us in, the live chat. You guys make the show unique. You guys make this show special. Thank you. And a huge shout out to all the freaks who continue to support the show. We're ad free, sponsor free, and, your donations your donations really do help. So thank you for sending your hard earned sets to dispatch and and and keep us going. We have, the top three supporters this week was Eric 99 with a 100,000 sets, 8 Myth Randur with 15,000 stats, and TKC TV with 10,000 stats. That includes podcasting 2 point o and Zaps that come into this to the live stream. I I combine them now, into one shout out. And next week, same time, same day, Tuesday, 1700 UTC. We're gonna have Tony from Unity Wallet, joining us. So definitely come join us for that.
And, I appreciate you all. Thanks, Pierre.
[01:17:14] Pierre:
Bye.
[01:20:36] ODELL:
That track was Life's a Beach by Django Django. Love you freaks. Hope you enjoyed this rip, and I'll see you next week. Stay humble stack sets.
CNBC Intro
Introduction to Citadel Dispatch podcast
Nostr Wallet Connect
Using Nostr Wallet Connect for subscriptions and setting up payment thresholds
Bolt12 and its major milestone in creating a static address for receiving lightning payments
Phoenix Server and its ease of use for developers to build lightning-connected services
What happens if the Phoenix node goes offline and how users can recover their funds
Future features of Phoenix Wallet
