0:02

You say gold was in a,

0:04

consolidation

0:05

phase for the years? Multi years.

0:08

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

0:15

threshold was a big deal for us, and it allowed us to arrive at an objective

0:19

intermediate term of about 22.80, that's not too far off, but longer term of about 25100

0:25

for the price of gold. Think it'll be sort of a slow moving ship that direction,

0:30

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,

0:47

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.

0:58

The pullback that we saw, it looks like nothing on the chart. It's pretty remarkable because it was 17, 18 percent of downside,

1:05

but it looks like a lift. Nothing for you. It is. It really is.

1:08

And, now, of course, within, like, you know, days, we've had a resumption

1:13

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%

1:26

versus the S and P, which is about 4%. So those are initial support readings.

1:31

But that's just the risk that you take by Commodities in

2:08

Happy Bitcoin Tuesday, freaks. It's your host, Odell, here for another Citadel Dispatch,

2:13

the interactive live show focused on actionable Bitcoin and Freedom Tech discussion.

2:20

That clip in the beginning has absolutely nothing to do with the chat we're gonna have today.

2:26

I just thought it was kinda funny having a suit on CNBC doing Bitcoin TA. Every suit is now a Bitcoin influencer.

2:34

I have a great chat, lined up for us. We have, Pierre here. Who's this?

2:40

How's it going, Pierre? He is the CEO of Async,

2:44

which is the company behind the Async lightning implementation.

2:49

He's behind Phoenix Wallet and recently Phoenix Server.

2:54

This is awesome. I I I just wanna start off the conversation by saying, Pierre,

2:59

thank you for what you and your team have been building. I mean, Phoenix Wallet

3:03

is absolutely amazing. It's incredibly easy to use.

3:07

It's the main wallet I onboard people with now,

3:10

if they're just getting started with Bitcoin and they wanna make payments very easily.

3:15

So thank you.

3:16

Thanks for having me. Yeah.

3:19

Well, we see Phoenix as a demonstrator of what

3:23

what Lightning can offer. So,

3:28

I like to think that what you see in Phoenix, you will be able to see that in many other

3:33

implementations in the future. Maybe done better, maybe a little bit different.

3:39

So it's like when we started phonics, it was the world of the future. We meant it as

3:45

we're gonna try out the latest,

3:49

of what you can do with lightning. And

3:52

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.

3:58

Yeah. I mean

3:59

so, I mean, there's a lot of there's a lot of places we can go here. Yes. I think,

4:06

first off, like, I I think it's really cool. So there's there's,

4:10

there's 3 main, lightning implementations.

4:15

Right? There's lnd there's 4, I guess. There's lnd.

4:18

There's core lightning. There's LDK,

4:22

and then there's async. And async,

4:25

you guys, are are a little bit unique in the lightning implementation space because you're actually building out this lightning implementation

4:35

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

4:43

what many of the other Lightning developers are building out in the space? Yeah. We have 2, actually. We have 2 separate Lightning implementations,

4:51

little known fact.

4:53

The first one is Eclair, which is the one we started working on in 2015,

5:00

and the goal of Eclair was to power large scale routing node.

5:06

Because since the beginning, we were convinced that

5:11

we didn't really believe in, everybody running

5:14

a small writing at home for obvious reasons related to

5:20

liquidity and security management and a lot of stuff.

5:23

So we don't think it made sense economically to run a small,

5:29

routing node. So since the the very first

5:34

commit on a eclair, it was designed to handle

5:38

a lot of channels to be maybe not very,

5:43

maybe not with a lot of features, maybe not with the,

5:48

all the bells and whistles, No fancy interface

5:52

and all that, but very reliable,

5:56

very scalable and and that's

6:01

the, if if I would,

6:06

if if you wanted to character characterize,

6:09

our implementation compared to c

6:13

lightning, LND, that would be it.

6:16

And, so we did this between 2015 and 2018,

6:20

I think. And at that point, we realized that it was quite easy to make this software run on Android.

6:29

That's when Eclair Mobile started.

6:32

And, Eklamaobile is the ancestor of Phoenix.

6:37

But then we wanted to to have this wallet run on iOS 2.

6:44

And at this point, we make a we we created a new implementation from scratch. So it's

6:51

inspired from Eclair, but it's it's a separate implementation.

6:55

It's in it's written in Kotlin. And,

6:58

and this one is focused on

7:02

very lightweight, very, lightweight implementation,

7:06

workforce efficient. It does not scale to a 100000 channels,

7:10

but, but it's very portable. You run it on Android, you can run it on iOS.

7:16

And it turns out you can also run it on a server, which is what we did with Phoenix.

7:21

So we already have 2 implementations, each with

7:26

their characteristics. And

7:31

and we, like,

7:36

if you take a look at at what we worked on since, we started,

7:40

we have basically never changed,

7:43

direction and and, like, have always followed the linear path. And so everything, like, every pieces that we put together,

7:53

was towards this goal, which is why sometimes,

7:56

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?

8:05

Well, the reason is that we had to

8:09

it was purpose built for what we have what we had in mind. And

8:14

we didn't want to to depend on

8:18

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

8:28

why we do what what we do and why we do it that way.

8:33

Is that when you work on a technology like lightning, which is evolving very fast,

8:38

and you you won't want to to depend

8:42

on the upstream, implementers

8:46

because if if you're stuck behind someone developing,

8:53

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.

9:01

Our approach and with specificity of our approach is that we control the whole stack.

9:07

Right. Even before the implementation,

9:09

like, down to the protocol design.

9:12

And this allows us to move very fast.

9:16

But it means that we have to work on

9:20

all the different pieces, that we need.

9:23

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

9:30

is so much better than so many other self custody lightning wallets in the space.

9:37

And a perfect example of that is, like so, like, if you're an end user. Right? If you're an end user and,

9:42

maybe you're new to Bitcoin. You're you're new to Bitcoin, and you you launch Phoenix Wallet for the first time,

9:48

and and you buy some Bitcoin or you receive Bitcoin from a friend, and you receive that payment as an on chain payment,

9:56

Phoenix is immediately creating a lightning channel for you. And then if you if you

10:02

receive more money on chain going forward,

10:06

that that payment is that on chain payment is automatically then spliced into your existing lightning channel. And I believe in practice,

10:14

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,

10:23

it's also be you know, there are there are different kind of features,

10:27

and but features like splicing,

10:31

they only operate at the peer level, which means that if we control both the mobile and the

10:39

routing node, then we can, we we can do stuff.

10:45

Some other features, for example,

10:48

privacy features, network wide features,

10:51

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.

10:59

It's just that it's much more difficult to to to deploy because, we depend on others.

11:04

And, and that's more difficult. It takes more time.

11:08

But, yeah. So am I correct that so so when when you're using Phoenix Wallet, right, there's

11:14

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.

11:23

Yes.

11:24

They they they share some similarities because of the same people

11:28

worked on them. Right. But but they are different.

11:33

So, basically, that means that when we ship something like splicing, we actually implement it twice.

11:41

One more complete part on, eclair and the more specific limited part on, on

11:49

the library that underpins Phoenix, which is called lightning k a m p.

11:55

So that's how it works. Yeah.

11:58

Okay. So let's,

12:00

for the sake of this conversation, let's start with the wallet,

12:04

and then we can talk about we can go deeper on the implementations

12:08

and, like and how how you're how you're thinking about protocol development.

12:12

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

12:23

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

12:32

you guys is your website is is is very clear on, like, the trade offs you make with the wallet.

12:40

You don't try and, like, hide things from the users.

12:42

You you make you make specific trade offs, and and you do it intentionally.

12:47

And and so so when you're talking when you're thinking about the actual Phoenix Wallet,

12:53

Phoenix Wallet at red by default,

12:57

all your funds are in a essentially a single lightning channel. Yeah.

13:02

Do you think so? So if a user wants to make if a user wants to make a a on chain payment,

13:10

they're actually doing a swap to pull it out of out of the lightning channel. Correct?

13:17

Yes. But,

13:19

you know, since the the splicing update, it has been a major change in

13:27

in how we see

13:30

on chain and off chain, because before splicing,

13:33

like, you would be either on chain or on Lightning.

13:40

And it was kind of fixed and really separate.

13:45

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

13:55

a channel is just a UTXO. Right? It's a UTXO, an unspent transaction output.

14:01

And it's it can be spent by a transaction that

14:06

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.

14:14

Right.

14:16

But you can spend this,

14:18

UTXO directly when you in Phoenix. It's just gonna create a new channel at the same time.

14:25

So you're not really, like yes. Logically, you're swapping funds, but you're actually spending

14:31

the same Bitcoins that are in your channel.

14:34

It is the same. And

14:36

It's still just one Bitcoin payment now that splicing exists. It used to be 2 Bitcoin payments, basically. Right?

14:43

No. In the previous version of Phoenix, it was simply trusted. You would send us.

14:47

You would pay us over lightning, and we would make the swap. It was trusted. It was very basic, extremely basic. It was,

14:55

it was, like, quite primitive, really. And,

14:59

so in this, with splicing, you just span your outputs

15:04

and, create a new channel at the same time. And

15:09

but the thing is, I don't I don't know if you remember, but a few years back,

15:15

there were a lot of ideas putting forward and

15:20

people were imagining what lightning could become.

15:24

A lot of them were unrealistic turns out,

15:26

but some of them one of them was

15:30

every unchained transaction will be a lightning channel.

15:34

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.

15:43

This one, I was also thinking,

15:46

that sounds a little bit, unreasonable,

15:50

but it done that. It's ex exactly what splicing is. When you

15:55

with splicing, you create a new channel

15:58

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

16:08

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.

16:18

Right. But, basically, you could see it as,

16:21

an on share wallet with the option to spend your funds over lightning.

16:28

It's it's, it will be a fair characterization.

16:33

Yeah. No. I mean, once you once you added splicing,

16:37

it really changed the game. I mean, in terms of fee burden too, it it really changed the game. Yeah. Yeah.

16:43

Okay. So let's let's talk about the trade offs a little bit.

16:47

The the first thing I wanna talk about is

16:52

how how you think about on chain fees. We recently had,

16:58

on chain fees spike with with the different inscription,

17:02

pressure and and, you know, mempools

17:06

filled up, and and and we had on chain fees go up high.

17:10

And as a result, your users specifically, I I assume your support request went up tremendously.

17:18

And there's, like, new settings now in the wallet in terms of

17:23

maximum fee and stuff like that. How do you how do you think about that? I mean, this is obviously a

17:30

as someone who onboards a lot of people to Bitcoin,

17:34

it's a hard thing for me to

17:36

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,

17:46

if they're if they're if they're paying via lightning,

17:50

they're gonna have a much lower fee.

17:52

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.

18:02

Yeah. Increased. How do you think about this? I mean, it's not an easy problem.

18:07

No. It it's definitely not easy. So

18:10

the first thing is, so during the past

18:16

6, 9 months, the fees have have been very volatile.

18:21

And so it it creates issues,

18:24

but it's also another an environment for which,

18:28

which is pretty positive for our service.

18:32

You know, there are 22 situations where,

18:36

as a Lightning Wallet, you're gonna have trouble

18:40

expanding your, your value to users

18:43

as an LSP is if the fees are always

18:48

very low, which is why during the

18:51

past years, Moon

18:54

Moon Wallet was a very attractive choice. Right. Because we because why not? When it's very cheap, it seems simpler.

19:02

The other situation is when fees are always very high.

19:06

And then it's a problem for for the LSP because,

19:10

everything is is, more expensive all the time.

19:15

The intermediate situation where we are, we have been,

19:18

in the past months is actually the one which is the most favorable for our business because

19:24

when when fees are volatile, the service that we offer to the users

19:28

is just to, like, absorb this,

19:32

volatility by offering liquidity. So it's not a bad thing for us. It's it's hard to explain and to guide users,

19:42

for them to navigate this environment, but it's actually

19:47

the situation that is the more the most positive for, an LSP.

19:52

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.

20:00

If you manage your requite, you're right, you're gonna save a lot of

20:06

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,

20:15

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

20:24

low or consist consistently high.

20:27

My my my gut feeling is that

20:30

this is going to be like that in the future. A little bit like the price. It's always volatile.

20:35

But you don't think we're gonna be consistently high in the future. Right?

20:39

I don't think so. I mean, I still think it'll be volatile.

20:43

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

20:51

the current volatile free market

20:55

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.

21:01

And, like, next block fee is 19 sats per byte.

21:05

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

21:22

be. But the thing is

21:24

as long as every now and then the fees go down,

21:28

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,

21:39

to use a word like Phoenix or any other liking wallet.

21:42

And, you know what's funny is that, so on one hand,

21:47

during, at the end of the previous year, we were busy migrating our users

21:52

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,

21:59

it it showcased,

22:03

the, advantage of being relating to a lot of user.

22:06

And one funny thing too is,

22:09

you know, so it's a small team at AC. We're just 10 people.

22:14

Amazing. It's amazing what you guys have built with such small team. And we're doing everything including the support,

22:20

which means that first, we are very well aware of the issues that our users have because we we do it directly.

22:27

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.

22:39

So whenever you, somebody somebody says, you know, like, it's too difficult. It's too complicated. That's not what we experience.

22:49

I think it's because since

22:51

failures on Lightning tend to be, immediate, like, maybe you're not gonna found find a route,

22:58

to make a payment, but that's the kind of error

23:01

that the users can understand. And,

23:04

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.

23:15

Yeah. It's confusing. And, so,

23:20

those those volatile

23:23

manifest times, it's quite interesting to

23:27

to to live. So,

23:32

yeah. I mean, I think it's it's really I mean, like, so I personally run,

23:37

5 lightning, you know, full nodes.

23:41

And then I also I I have,

23:44

you know, like, my my I I do use Phoenix Wallet. Like, Phoenix Wallet is awesome.

23:50

I, you know, I might have been in the beginning. I might have been in the camp where, like, I thought

23:57

a lot more people were gonna be managing liquidity themselves,

24:02

running routing nodes, doing all these things.

24:05

But I think it's kinda interesting with Phoenix Wallet is is

24:08

there there's, like, an argument for a, like, more

24:13

like, even even a more technical user to just send, like, a large amount, like, a large UTXO in

24:20

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,

24:27

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,

24:34

$3,000 or $4,000. Like, what the on chain fee burden is fucking negligible in that situation.

24:41

I think most users,

24:43

most Phoenix users do not realize that,

24:47

the splicing feature and the fact that their funds are consolidating

24:51

into a single q UTXO, which is, again, a privacy trade off that we can discuss,

24:57

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

25:07

really is was fundamental change is that before that,

25:11

some users had literally hundreds of channels,

25:13

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

25:22

issue for them going forward. So now it's,

25:27

it's future proof in a in a sense. So so

25:33

that that's that's why it was a really, very, important.

25:36

But where I was going with that is,

25:40

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.

25:51

And then you added this, like, the fees section in settings, like, the channel management,

25:57

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,

26:17

and they have to open their first, you know, they have to open the channel,

26:21

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,

26:30

we wish we could do it better.

26:34

Before we introduced this, we had a fixed 1%

26:38

fee on receive Right. Plus 3,000 sets.

26:42

And, this had the advantage of simplicity,

26:46

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

26:57

change that we made was to just push the money fee to the users.

27:02

To us, it's just a matter of managing,

27:05

risk. And once once you do

27:08

that, you you cannot just, exchange Auto charge them. Yeah. It's it's it's very difficult to, to

27:17

to put to put in in one sentence what's the cost is going to be.

27:21

And so, obviously, we are, you know, trying to to

27:25

the the the way it is done currently is not final.

27:28

We are we are we are thinking about it every day, but,

27:30

the goal was to offer, more advanced users

27:35

a way to fine tune, their fees to the very minimal,

27:39

which is why, you know, you're gonna have Phoenix users who say,

27:45

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.

27:54

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,

28:06

which by the way, you must have the same

28:09

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.

28:20

So it's a very difficult problem.

28:23

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,

28:34

they're like, I'm getting charged so much more fees.

28:37

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

28:46

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.

28:59

But, no, on the unchain feeds, when you make unchain transactions, it's actually interesting how

29:06

Phoenix is more efficient. It's not less expensive in Phoenix because we made a particular effort on fees. No, it's just because

29:13

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.

29:29

Yeah. I,

29:30

yeah. I I I so, the reason I bring it up is because,

29:37

yeah, it I was just gonna be and when you first implemented the feature, it was like the default was a certain amount.

29:44

It was, like, an absolute fixed amount.

29:48

It is for it's I think by default, it's 5,000 satoshis.

29:52

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,

30:01

because,

30:03

But shouldn't it be percentage?

30:06

You you have both, actually.

30:08

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,

30:17

to have the main setting be relative, but you could,

30:22

put a very high amount and there is also a relative

30:26

in the advanced setting somewhere. There is also a relative check. Yeah. I see advanced percentages.

30:32

Our approach to it is there are so many,

30:36

you know, side effects,

30:42

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

30:48

independent of the amount. So if we if we don't want to have too many headaches,

30:52

that's the easiest way.

30:55

Fair enough.

30:56

I just know when I was onboarding in the higher fee environment, I was just literally

31:00

I before I would have them send into the wallet, I would go into settings and just jack up that.

31:07

Yeah. It was like an it was they were like, what are you doing? I was like, you gotta go into settings.

31:11

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,

31:19

we we

31:20

we have introduced a feature related to that in in the phoenix,

31:25

release. Maybe we'll talk about it later, but it's related to that. It's

31:29

bay it's it's the feed credit. Is it's a way for for

31:34

to to aggregate amounts,

31:37

before you open the channel. You know, like you cannot onboard

31:42

a user by sending him a 1,000 sats if it costs a 1,000 sats,

31:47

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

31:56

pay in advance the LSP to just put the amount aside

32:00

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.

32:11

So it's kind of a gray gray area in

32:15

in a regulation from a regulation point of view, but I think it works that

32:19

way. Yeah. That makes sense.

32:21

Okay. So let's talk about continuing the trade offs.

32:25

The major trade off with Phoenix right now is privacy trade off, and you're very clear on your website.

32:30

But you wanna just discuss, like, what

32:33

what kind of information can Phoenix see if I'm a Phoenix user?

32:38

So we can see

32:41

if you if you don't use store, we can see your, your IP address because you're connecting directly to our node. Right.

32:50

We can correlate since you are we are the only node that you're connected to, we can correlate your transactions,

32:59

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.

33:09

But that would be this is not a specific

33:15

trade off of Phoenix. It's a specific trade off when you're connected to a single node.

33:22

Are you keeping track of, like,

33:25

so, like, if I if I open Phoenix

33:28

and I pay a lightning address, right, you can pay 2 lightning addresses,

33:34

and I pay, like, Odell at at voltage.

33:38

Are you keeping track of those,

33:43

which lightning addresses you're paying? Are you keeping track of the memos

33:47

of those addresses? Like, the memos of those transactions?

33:50

We don't have access to that because the resolution is done on the mobile.

33:54

But we keep track of the the payments. Like, with the endpoint, where it goes, which node it it ends up. So

34:05

what what we need to do as,

34:07

routing node is we need to allocate our fans.

34:10

We need to know where to allocate them. Right. So

34:13

it's very so we have to to see where,

34:17

we should put our funds so that it's it's more reliable.

34:22

One important thing, in Phoenix is that,

34:27

it implements trampoline routing. Trampoline routing

34:31

so the the default routing, in, lightning is called onion routing and it's just

34:39

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.

34:48

And then makes an onion and intermediate

34:50

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

34:57

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,

35:07

but, like, if you want to pay from a to z,

35:12

the source of the payment, they would not have to find the whole route because this

35:18

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

35:31

to select a few intermediate nodes. Like, they would say, okay. I want to,

35:35

I'm gonna use a route, I don't know, f, n,

35:39

and p. And,

35:42

and then this intermediate node, this trampoline node, that's up to them to find the route between themselves. So it's the same,

35:50

it's very similar but at a higher level.

35:53

And so we came up with this idea

35:56

of taupelyn routing a few years back and,

35:59

we we we thought it was a really good way

36:02

to offer privacy for mobile

36:06

lightning wallets without having them sync and be aware of the,

36:10

whole network table all the time.

36:13

That's where the the I'm just saying that to explain where the current,

36:19

state comes from. And but as about as I mentioned earlier,

36:25

some, protocol features involve the whole network, and that's the case for trampoline.

36:30

The whole I mean, a lot of the nodes in the network

36:33

need to be trampoline. They need to understand this protocol for this to work. And when we started,

36:39

we were pushing this feature and only us were supporting

36:43

this. So what what Phoenix does generally is a trampoline routing,

36:47

but with only 1 trampoline node. So the destination

36:50

is always known to us because we know they're not gonna do any more hops. And was that the LSP?

36:56

Yeah. So that's, that's why currently we know the final destination of, all payments.

37:03

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.

37:11

No. They don't. Because between

37:13

between property nodes or between the last property node and the destination,

37:17

which is the case in Phoenix because the first property node is the last property node, it's normal Lightning payments.

37:23

So so yeah.

37:28

This is going to be majorly improved,

37:34

very soon with the introduction of the daily path.

37:38

That's a more technical feature. I don't know if you want to address right now or later. But,

37:43

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

37:50

is a way for the recipient to

37:53

to to to give, the end of the route

37:58

or a few sets of routes, the

38:01

last part of the routes to to pay them,

38:04

which means So it's in the invoice? Yeah. It's the it's it's in the invoice. So

38:10

from Phoenix, if you would pay I don't know. You would you want to send your money to

38:17

to any any place. You wouldn't you would not to Bob, say. You would not

38:23

send the destination bob to our node. You would say you would send

38:28

an entry node, which is a few nodes

38:32

before bobs. And our job would just be to route the payment the payment to this entry node, and then the last

38:40

remaining hops, are already computed.

38:44

And so it's it's base it's it's resembles,

38:48

what we wanted to achieve with the original temporary

38:52

payments. So is LND implementing this?

38:55

I oh, you will have to ask, Bastian for the exact,

38:59

but I think yes. So this is this is related to, to bolt,

39:04

12.

39:05

Oh, so l and d isn't implementing. Yeah. Yeah.

39:09

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,

39:18

I just wanna go through the trade offs on the wallet. Sure.

39:21

So, I mean, right now, that that main trade off, then you know the end

39:25

the real the the key reason for the end user

39:29

for that privacy trade off is that Phoenix payments are almost instant.

39:33

And if you use, like, a Zeus wallet,

39:37

where where they're computing the whole path locally,

39:41

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.

39:51

And and so Phoenix makes that trade off so that

39:54

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,

40:13

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,

40:26

is still in my opinion, it's still much better. Right.

40:29

And

40:30

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.

40:39

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

40:49

where you can change your identity whenever you want? It's it's not as valuable as,

40:59

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,

41:09

and also what what it allows us, and it's very important for UX, is a predictable fee for sending.

41:16

Because one of the critics that we had in our,

41:20

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.

41:28

And

41:30

Oh, yeah. It's great. It shows the fee ahead of time. Exactly. And that's, that's that's important.

41:37

Okay. So the next thing I've I've gotten

41:42

you know, I just love Bitcoin, and,

41:44

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,

41:55

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.

42:04

And one thing I've gotten a little bit of heat for lately is

42:08

I really like the fact that you can

42:12

back up your iOS Phoenix wallet to Icloud,

42:17

which is just I mean, if you asked me 5 years ago, 4 years ago, I would have been like,

42:22

fucking hell no. But it's it's a very easy way for a new user to back back up their wallet

42:31

without dealing with seed phrases, without dealing

42:34

with actually storing the seed phrases securely, with making sure that they're still there. If they lose their iPhone, they can just

42:40

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,

42:49

you give, like, really clear scary warnings,

42:53

as you enable it. What are the real risks there in terms of a user that is, like, using the iCloud backup feature?

43:03

Well,

43:06

on the top of my head, but, I would need to double check with

43:10

our iOS guys. The main trade off is that if your Icloud account is compromised,

43:17

then it's not good for you. Whereas

43:20

if, like, on on Android, you there is no Google Drive backup,

43:25

Right. Then you're safe from

43:27

that. So

43:29

So, like, if you're if you're storing, like, nude pictures of yourself in Icloud, like, there's

43:35

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.

43:45

Yes.

43:47

But it's encrypt it's

43:48

technically encrypted, the backup.

43:51

Yes. But

43:53

if you have access

43:54

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,

44:03

And people are usually terrible at passwords. So,

44:07

that's the trade off. Yeah. I mean,

44:10

the warnings are, like, very

44:12

I mean, they should be. I I applaud you for putting scary warnings there.

44:17

But I think it's very compelling for a lot of people. I mean, I think,

44:23

The the reason we did it on the iCloud and on the Apple and not on on, Android is that on Android, we

44:29

by default, you don't have access to Google Drive. So this would require,

44:34

to ask for permission, and that's,

44:38

some people don't like Google Drive. So

44:42

this feature is only available on, on Apple for now. Yeah. Well, I mean, what I see with most people is,

44:49

like, most people are more likely to lose their money

44:53

than have someone steal their money, and most people

44:57

are are unlikely to be, like, a high value target that, like, Apple would presumably, like, try and attack.

45:04

And Apple takes pretty decent lengths to protect

45:08

Icloud from, you know, general attackers

45:13

because of the fapping that happened when all the celebrities nude photos all got out,

45:18

which is not good for Apple's business. Like, they don't want nude photos getting out. So

45:22

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

45:30

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

45:39

and make sure they read the warnings. And I explain to them, like,

45:43

you know, make sure your iCloud password is is secure password.

45:47

They also have some, like, ridiculous two factor that is, like, very opaque and hard to understand, but

45:54

apparently works reasonably well.

45:57

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,

46:04

particularly for their first for their first wallet, and

46:07

and and I I think it's a a a a good UX flow.

46:14

Awesome. Okay. I think we got through

46:17

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,

46:25

users to connect to different nodes? I know. Why not?

46:29

It's funny because most people think that it's because we want to capture all the all the payment fees,

46:35

which is not the result it's not the reason at all. The reason is that.

46:39

There are 2 reasons. The problem are incentives. That's the main reason.

46:47

You don't want to develop software

46:50

and put software out for users to to use

46:53

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,

47:03

and then they're gonna do whatever they want and connect to

47:06

nodes as unreliable as possible.

47:09

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

47:17

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,

47:25

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

47:32

wasting a lot of time and a lot of effort. So that's the main reason.

47:37

If if users were competent and, like, we could we could do as many warnings as we could.

47:43

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.

47:52

It's not about the physical. The the

47:56

the,

48:02

yeah, sorry. That's what I was about. It's about the user experience. You wanna be able to provide a good

48:09

reliable user experiences. Yeah. I mean, we don't want to be stuck because

48:13

this is complex tech, and you don't want to be to be stuck in the middle. It's just a problem with incentives.

48:20

Yeah. I mean, I I yeah. Yeah. Go on. The other very important reason is that

48:25

one of the the main service that we provide is,

48:28

is, liquidity and specifically on the flight channels.

48:33

And, I I discussed it with the,

48:39

Blockstream guys when they were working on Greenlight is. How do you know

48:44

how can you tell if the users is lacking

48:46

liquidity if you don't have the total view of their channels?

48:51

You know? Maybe you cannot receive the payment,

48:55

using the channel that you have with async, but maybe your Phoenix has another channel that you're not aware about.

49:02

So why would we charge the user something if it could can go to the to the to, another direction? So to

49:09

me, we can we cannot offer both connecting to,

49:13

many nodes and on the file liquidity. I don't see how that can possibly work. It's going to

49:19

to be very hard to explain. So

49:22

those are the actual reasons.

49:25

Yep. That makes sense to me.

49:29

Okay. So, I guess before we leave the wallet, I have two questions

49:34

relating to Gnoster. How how,

49:38

attentive are you to the Gnoster ecosystem? Are you familiar with Gnoster Wallet Connect? No.

49:43

No. I I know that,

49:46

some people want us to do something with that,

49:50

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,

50:00

you know, lightning payments to users

50:03

within within a Nostra app. Right?

50:06

And nostril WalletConnect, basically uses nostril,

50:12

as a communication protocol back to your LSP

50:16

that says, like, I wanna make these payments. So, like, right now, if I'm using Phoenix to send a Zap,

50:22

I have to I have to leave the Nostra app. I have to go back into Phoenix.

50:27

It, like, automatically opens in Phoenix, and then I have to approve the payment in Phoenix. But if you use Nasr WalletConnect,

50:34

those payments all get queued. And next time I open Phoenix,

50:38

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?

50:45

So it basically just uses nostr as a communication

50:49

as a communication protocol, which that is what nostr is, a secure communication protocol,

50:55

to to allow you to queue payments for all sorts of things. And now people are using it for

51:01

subscriptions. So like Geyser Geyser Fund,

51:05

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.

51:13

And, basically, guys are sending this Noster event

51:17

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.

51:26

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

51:33

approve, a certain amount, for this one app so that I when I open up Phoenix, it just automatically makes those payments, essentially. Okay.

51:42

So it's essentially just,

51:43

Phoenix embeds the Northstar client. Right?

51:47

And reads Into the LSP. Yeah. Okay.

51:51

Look into it. Cool. And then the other thing is

51:54

using, like, Nostra contact lists

51:57

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.

52:13

So he has a Lightning address set up, you know, so I it linked to his Noster account so I can just, like, easily

52:20

import my Noster contacts to pay people. Those are two

52:23

different things. On the on the

52:25

more general payment front,

52:28

our immediate focus is bolt 12, which is a

52:32

major milestone. Perfect. Let's talk about block 12. Yeah. So, I mean,

52:36

these these features that you're mentioning to me is,

52:39

like the cherry on the cake once we have the big

52:43

infrastructure working. So

52:47

Well, let's talk about Bolt 12. Like, where are we on Bolt 12? How are you thinking about it?

52:52

So Bolt 12, we have

52:56

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.

53:11

I think it's a matter of weeks, months. Let's say more of a matter of a few months.

53:18

And the so the the what it offers you basically, it's a static address. It's like your

53:24

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.

53:33

And, it's it would make the Phoenix server

53:37

demo even more nice because basically you just start the daemon, it just prints,

53:43

an address and then you can put this

53:45

and like for, to receive donations,

53:50

like, donations on the on on wherever,

53:54

it's so simple. You just put your Finnish server

53:58

somewhere on your node. You don't even need to to to,

54:01

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.

54:11

It's it's the same UX basically as a regular

54:15

beacon address. The thing is and it's

54:20

it uses a lot of tech because

54:25

what it does essentially when you pay

54:28

a static address like this, your your the sending wallet is going to ask is going to go through the Lightning Network.

54:37

It sends a message. It's not a payment. It's a message

54:40

to to reach the destination node and ask for an invoice, and then it's gonna pay the invoice.

54:45

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.

54:56

A lot of, lightning products currently do actually

55:02

manual probing. This allows

55:07

us to wake up the mobile in the case of Phoenix because we know that the payment is going to happen.

55:14

Like, so there are a lot of

55:16

Right. So does that mean I can receive if I don't have the app open?

55:21

It's already the case. You know?

55:24

You can try to turn off Phoenix.

55:26

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,

55:43

we're gonna wake it up, just in time,

55:48

to to create the invoice. This is going to to happen automatically. You won't be,

55:53

no interaction necessary at that point, and then,

55:56

the payment was going to go through. So

56:00

yeah. The goal is to have a very, very similar experience to, to receiving a bunch of payments.

56:06

So,

56:08

like, I mean okay. So I'm, like, I've been excited about Bold 12 for

56:14

many years now. Like, how close are we from that experience actually happening?

56:21

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,

56:30

but, that's what we are working on currently. That's our main

56:34

next main, raise feature.

56:39

The the only thing is that this is network wide.

56:44

So just because Phoenix supports it

56:46

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.

56:56

Like, I don't know if you have been using, Kraken

56:59

with auto lightning feature, but you have to

57:03

to to input a new invoice every time you want to make, to send parents of our lightning.

57:08

That's really that's great.

57:11

So Yeah. Yeah. We would need them to implement that too and all the exchanging on that. So that takes time.

57:19

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,

57:26

it uses onion messages. So messages has to be have to be routed in the network.

57:32

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.

57:40

Okay. So Phoenix server

57:42

is this idea of taking the ease of use

57:45

of Phoenix Wallet and putting it in an always on server environment. Yeah.

57:51

Let's chat about I mean, because you released this last week. I mean, on the surface, it

57:56

seems, absolutely massive, incredibly useful to a lot of people,

58:01

particularly, you know, this idea that you don't have to worry about inbound liquidity,

58:07

that that you guys handle that automatically,

58:10

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

58:17

is gonna affect kind of the the Bitcoin landscape?

58:21

So

58:24

basically, it's just, it's exactly like Phoenix mobile

58:27

except that you interact with it not with pushing buttons on the

58:32

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,

58:46

services. And we have added a few features,

58:50

around because a lot of these potential applications

58:54

involve receiving.

58:58

It's it's often receiving more than, like, from merchants receiving more funds than sending.

59:03

It can be both, but so we added some a few features to make it really completely transparent.

59:09

So you for for developers, it allows you to

59:14

interact with lightning with absolutely no headache. It's like exactly like you would

59:19

if you if you build a traditional merchant website, you would plug into Stripe and then I like so like 2 ifttp calls and

59:27

and and one callback. It's exactly the same

59:31

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

59:44

to to to do some trust,

59:50

but we put the limit at self custody.

59:55

So, like, a new merchant could

59:57

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,

1:00:07

from an integration point of view, but you also benefit from the well known reliability that Phoenix offers.

1:00:13

So when you when you use,

1:00:16

Phoenix server to receive payments as a merchant,

1:00:19

you your your inbound liquidity is the inbound liquidity of the async like node. So you can you're not gonna have any issues,

1:00:28

around that. I mean, so it's a great burden to remove off your shoulders

1:00:33

if you want to receive funds on anything. Wait. So right now with Phoenix Wallet,

1:00:37

I let I let's say I put I put 10,000,000 sats into Phoenix Wallet, and I have 10,000,000 stats

1:00:43

of outbound liquidity. But for inbound liquidity,

1:00:46

I have to pay an on chain fee when I need to increase my inbound liquidity.

1:00:50

How is that handled on Phoenix server? Like, am I not in that situation? Am I not,

1:00:56

am I not paying that on chain fee?

1:00:59

So on Phoenix server,

1:01:03

let let's let's do the the actual steps.

1:01:06

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.

1:01:16

Okay. Then you're gonna use the API to create an invoice.

1:01:20

Then a payment is going to arrive.

1:01:24

At that point, if the payment is,

1:01:29

more than the mining fees required to create the channel, then a create a channel is going to be created

1:01:35

and, the mining fees are going to be are going to be deducted from the amount you receive.

1:01:40

Okay. But and in the same operation, we are going to also add

1:01:45

inbound liquidity, with the default of 2,000,000 SATs,

1:01:50

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

1:01:58

a lot of inbound and that's

1:02:01

it. That's the easy scenario. Now another scenario where

1:02:06

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?

1:02:19

Well, in that situation, it's gonna be

1:02:22

the channel is going to be too small. So another on chain selection is going to be required.

1:02:27

You're gonna receive the 4,000,000 in that, operation, and you're gonna have add also 2,000,000¢.

1:02:33

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,

1:02:42

if your the average invoice that your customers pay is 2 or 4,000,000 SATs, you will then want to increase the

1:02:49

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.

1:02:56

On the other hand, if you receive that amount, the the weight of the on chain fees is quite low in relative terms.

1:03:03

So Right. It's up to you. But basically So in practice, it works very similar to the actual wallet does?

1:03:10

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,

1:03:21

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.

1:03:33

It's not enough to cover for the unchanged production.

1:03:36

On the Phoenix mobile, we would simply reject the payments because it's too expensive.

1:03:41

Like, it we it's, the main fee is too expensive. You cannot cover the cost with this payment.

1:03:46

On the Phoenix server, this amount goes to your, what we call a fee credit. It's gonna be

1:03:53

used to pay future money fees.

1:03:55

That means that if you're if

1:03:58

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.

1:04:07

In this situation, then all the small tips would aggregate.

1:04:12

And as soon as you reach the amount needed to open a channel with

1:04:16

2,000,000 sat inbound liquidity by default or possibly more if you configure them differently,

1:04:21

then you're gonna end up with a big channel and receive all the future tips in this channel.

1:04:27

And you would have And then you take out the fee credit at that point.

1:04:30

Exactly. And so the

1:04:33

the all the small tips that,

1:04:36

would have been rejected on Phoenix mobile,

1:04:38

They are taken and they are used to pay the mining fees. So, every single Satoshi that you receive,

1:04:44

it's not lost because it's it's going to pay to contribute to paying this the fee for your channel.

1:04:50

That's a major difference because it means that you don't have to worry about,

1:04:54

you know, threshold effects.

1:04:57

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

1:05:11

relative fee total fee. And our goal is to bring it as close as 1% overall as possible. And it's

1:05:18

you can see the the the calculations in our website. But basically, it's it's between 1 2%

1:05:24

depending on your settings and the

1:05:27

mining fees. Got it. Now am I correct to assume with the focus on bolt 12 that

1:05:35

that is there any priority now with this with this Phoenix server, is there any priority to add lightning address support to that?

1:05:45

We want to add something

1:05:48

that's I don't know if you, came across the,

1:05:52

the, the DNS proposal,

1:05:56

from Bastian that, he put together. I think it's end of 2023.

1:06:02

Basically, we want to offer something functionally equivalent to,

1:06:07

to add an address, but much more private.

1:06:10

The problem with lightning address, it from a

1:06:14

functional point of view is great, but

1:06:17

it leaks a lot of information about the sender and the recipient. Because you're asking your server and you the sender,

1:06:26

when like, if you're an LSP like us, if you if we run

1:06:32

a lightning address service for our Phoenix users,

1:06:34

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.

1:06:48

And they would and yep. So that's a big problem. And so there are privacy issues with that,

1:06:53

and we believe that, leveraging bot 12 and static addresses, we can match make much, much, much,

1:07:01

better, technical solution,

1:07:04

which is also exactly as easy to integrate

1:07:07

for, for everybody who wants to to play with that

1:07:12

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.

1:07:22

So that that's the reason why we haven't,

1:07:25

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

1:07:33

specifically because of, privacy concerns.

1:07:36

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,

1:07:48

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.

1:07:59

And if I have Tor enabled on Phoenix Wallet and I'm paying a

1:08:03

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,

1:08:10

yes. I will have to double check, but I I believe it's

1:08:14

Okay. That makes sense to me.

1:08:17

Bolt 12. Hopefully I mean, I had Steve Lee on the show a couple weeks ago, and he's quite optimistic about bolt 12,

1:08:25

from the LDK side. So Yeah. Yeah. They are

1:08:29

definitely moving forward with this.

1:08:32

Awesome.

1:08:35

Yeah. I mean, I think this has been a great chat. I mean, we're a little bit over the hour mark now.

1:08:41

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,

1:08:54

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

1:09:02

really for

1:09:06

to as a way to

1:09:09

to just try out,

1:09:11

recently letting payments, for

1:09:17

not a reasonably sized business, let's say.

1:09:20

I think it's really, really, very, compelling,

1:09:24

offering.

1:09:26

Awesome.

1:09:27

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.

1:09:36

So let's say, like, worst case scenario

1:09:39

it goes back to trade offs. Worst case scenario,

1:09:43

the phoenix the phoenix node goes offline,

1:09:47

for whatever reason. We don't have to speculate for for why it happened.

1:09:52

But everyone, you know, they they have a channel open with this with this node. How does the end user

1:09:58

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.

1:10:08

So firstly, before that,

1:10:11

that everybody needs to be aware is in the

1:10:15

security model of Phoenix, you need to have Phoenix

1:10:18

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

1:10:29

to, access the blockchain once every 2 weeks. That's very, very important because,

1:10:35

so as long as you have this,

1:10:39

then you're safe.

1:10:41

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

1:10:51

the you you can first close the channel

1:10:54

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

1:11:05

and just take your money back. So

1:11:09

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.

1:11:20

If, I I would imagine it's a more

1:11:25

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.

1:11:33

So let's say we're just, we do just disappear from the

1:11:37

from, from the Internet. Right.

1:11:40

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.

1:11:53

I imagine that some people would take over

1:11:56

or fork our code and,

1:11:59

make a nice tool to to help. I don't know exactly, but there is no rush. There is no need to

1:12:05

there is no, like, delay that you need to count before money is lost or whatever. Because

1:12:12

what Phoenix shows you and and you every user should,

1:12:15

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,

1:12:40

So if I if I go into the payment channel settings

1:12:43

on Phoenix and I press the close all button or the force close all button,

1:12:48

what happens next? I haven't pressed that button yet. If you if you press the close button Yeah.

1:12:55

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,

1:13:09

an on chain address derived from your seed following, BIP 84.

1:13:13

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,

1:13:39

to protect, users from

1:13:41

fraud from our part, there is the same delay

1:13:45

for Phoenix. It's it's smaller. It's just 5 days instead of 2 weeks. But for the same reason,

1:13:51

we need to protect ourselves against our users too. So you're you're gonna have to wait for 5 days before the funds

1:13:59

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

1:14:06

the transaction that that finally sends the funds to your personal wallet. So basically,

1:14:11

never uninstall Phoenix as long as you have not recovered all the funds, and you'll be fine.

1:14:18

Got it. Okay. That seems pretty straightforward.

1:14:21

Pierre, this was this was a great chat. I really enjoyed it. I really appreciate

1:14:26

what you and your team have been building. I mean,

1:14:31

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.

1:14:39

Do you have any final thoughts before we wrap?

1:14:43

I I think,

1:14:45

you know, without being a lot of changes, in, Lightning and Infinix over the past year.

1:14:51

Bolt 12 is going to be a huge milestone.

1:14:55

Now one of the, updates

1:15:00

coming up, it's related to Taproot. We have done one part with, the swaps, but the channel,

1:15:06

transactions are going to be taboot taboot 2, which means that footprint

1:15:11

of, your wallet is going to be

1:15:15

it's not going to stand out on the blockchain as much as it does currently.

1:15:19

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.

1:15:29

Now it's obvious that it's a Lightning wallet.

1:15:32

And after that, it's just going to look like,

1:15:36

like a a stand out p 2 p 2 tr wallet.

1:15:41

It's not particularly private, but it doesn't stand out.

1:15:44

So it's a huge all the privacy features that we

1:15:48

unfortunately, that those are the most difficult to do. So they they come at the end, but they are they are finally,

1:15:54

yeah, definitely coming.

1:15:57

Awesome. Well, thank you again.

1:16:00

And, you have my contact information now. If I can help in any way, don't hesitate to reach out. Cool. And,

1:16:07

it was a pleasure. Thank you for having me. Bye.

1:16:10

Awesome. Thank you, Pierre.

1:16:12

I wanna do a huge shout out to the freaks who joined us in,

1:16:16

the live chat. You guys make the show unique. You guys make this show special. Thank you.

1:16:22

And a huge shout out to all the freaks who continue to support the show.

1:16:27

We're ad free, sponsor free, and,

1:16:31

your donations your donations really do help. So thank you for sending your hard earned sets

1:16:38

to dispatch and and and keep us going. We have,

1:16:42

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.

1:16:52

That includes podcasting 2 point o and Zaps that come into this to the live stream. I I combine them now,

1:16:59

into one shout out. And next week, same time, same day, Tuesday, 1700 UTC. We're gonna have Tony from Unity Wallet,

1:17:07

joining us. So definitely come join us for that.

1:17:11

And, I appreciate you all. Thanks, Pierre.

1:17:13

Bye.

1:20:36

That track was Life's a Beach by Django Django. Love you freaks. Hope you enjoyed

1:20:41

this rip, and I'll see you next week. Stay humble stack sets.