1
00:00:18,280 --> 00:00:20,600
Life from interest.
This is Bitcoin.
2
00:00:20,720 --> 00:00:23,920
Explained.
Sure, I have a problem.
3
00:00:24,720 --> 00:00:26,880
I have.
I have bitcoins laying around
4
00:00:26,880 --> 00:00:30,080
everywhere, Bitcoins on
exchanges, bitcoins in hot
5
00:00:30,080 --> 00:00:32,400
wallets, bitcoins in paper
wallets.
6
00:00:32,400 --> 00:00:36,160
Bitcoins in ETFs.
Is there a safe place to store
7
00:00:36,160 --> 00:00:38,920
my Bitcoin shorts?
There might be because we have a
8
00:00:38,920 --> 00:00:41,600
sponsor and they're called coin
kite.
9
00:00:42,640 --> 00:00:46,480
And they produce the cold card.
I heard that's right, a hardware
10
00:00:46,480 --> 00:00:52,200
wallet for your bitcoins.
And it supports PSPT partially
11
00:00:52,200 --> 00:00:54,960
signed Bitcoin transactions.
Great.
12
00:00:55,600 --> 00:01:00,800
OK, short and dear listener.
So we've been getting requests
13
00:01:00,800 --> 00:01:05,840
over the past years basically to
sometimes make more lightning
14
00:01:05,840 --> 00:01:09,360
specific episodes.
Indeed, although we know that
15
00:01:09,600 --> 00:01:12,200
lightning is dead.
Is it?
16
00:01:12,840 --> 00:01:15,440
That's what Twitter says.
What did they say?
17
00:01:15,720 --> 00:01:17,800
Why is it that?
I don't know.
18
00:01:19,480 --> 00:01:21,320
I used it today.
It worked.
19
00:01:21,480 --> 00:01:23,960
It worked for me.
OK.
20
00:01:24,960 --> 00:01:28,400
Good.
So we're making the the request
21
00:01:28,400 --> 00:01:29,960
is to make Lightning specific
episodes.
22
00:01:29,960 --> 00:01:34,600
Sometimes, however short and I
both kind of feel out of our
23
00:01:34,600 --> 00:01:38,960
depth when it comes to at least
more advanced Lightning topics.
24
00:01:39,760 --> 00:01:42,240
We've discussed this in the
episode before where you can
25
00:01:42,240 --> 00:01:45,440
really sort of see that the
development communities of
26
00:01:45,440 --> 00:01:49,120
Bitcoin and Lightning are kind
of starting to separate a bit,
27
00:01:49,120 --> 00:01:52,000
specialized a bit.
There's overlap, obviously, but
28
00:01:52,000 --> 00:01:56,640
there's definitely sort of more
Bitcoin focused, you know,
29
00:01:56,640 --> 00:01:59,840
technological experts and
developers and those that focus
30
00:01:59,840 --> 00:02:03,320
more on lightning.
But we do want to incorporate
31
00:02:03,320 --> 00:02:05,280
more lightning topics in our
episodes.
32
00:02:05,760 --> 00:02:09,240
So we're happy that today we
have a special guest.
33
00:02:10,440 --> 00:02:12,440
Yes, Sir.
Good to be here.
34
00:02:12,480 --> 00:02:13,320
How are you?
Yes, Sir.
35
00:02:14,200 --> 00:02:15,320
Good.
Good.
36
00:02:15,400 --> 00:02:16,160
Now, who are you?
Who?
37
00:02:16,680 --> 00:02:19,880
Am I?
I'm a Lightning developer and I
38
00:02:19,880 --> 00:02:22,440
work for Breeze.
My name is Yessa David.
39
00:02:23,200 --> 00:02:25,000
Jesse the White.
Jesse the Wit.
40
00:02:26,240 --> 00:02:29,680
It's an impossible name to
pronounce in English and.
41
00:02:30,280 --> 00:02:33,080
I just did pronounce it in
English anyways, never mind,
42
00:02:33,440 --> 00:02:37,720
move on.
OK yeah so I I work on Lightning
43
00:02:37,720 --> 00:02:41,680
for Breeze, mostly working on
Lightning service provider stuff
44
00:02:42,080 --> 00:02:46,120
and also Breeze SDK.
And yeah, I'm quite well read
45
00:02:46,120 --> 00:02:48,560
into the Lightning specifics
these days.
46
00:02:48,760 --> 00:02:49,200
Awesome.
Yeah.
47
00:02:49,200 --> 00:02:53,680
So thanks a lot for coming on.
So yeah, we had sort of a list
48
00:02:53,680 --> 00:02:57,000
of lighting topics that that we
wanted to cover at some point.
49
00:02:57,240 --> 00:03:01,320
And earlier this week we read
this list to you and the one
50
00:03:01,320 --> 00:03:04,760
that sort of sprung out for you
to cover is asynchronous
51
00:03:04,760 --> 00:03:06,000
payments.
Exactly.
52
00:03:06,320 --> 00:03:11,320
And the nice thing about that is
you mentioned if we cover
53
00:03:11,320 --> 00:03:14,200
asynchronous payments, then we
sort of at the same time also
54
00:03:14,200 --> 00:03:17,480
tackle two other topics that
were already on our list that we
55
00:03:17,480 --> 00:03:21,440
can sort of all wrap into one
episode basically because it, it
56
00:03:21,440 --> 00:03:23,160
sort of supports each other,
right?
57
00:03:23,640 --> 00:03:25,120
So.
Yes, yeah.
58
00:03:25,120 --> 00:03:28,280
And we will, we'll touch on the
topics later on, I suppose when
59
00:03:28,280 --> 00:03:30,400
we cover async payments.
Yeah.
60
00:03:30,400 --> 00:03:32,880
Well, I'll, I'll spoil this.
So the other two that we're sort
61
00:03:32,880 --> 00:03:37,320
of going to touch on are PTLCS
and trampoline payments are also
62
00:03:37,320 --> 00:03:38,960
going.
To yes, we'll touch on them
63
00:03:39,240 --> 00:03:41,560
briefly.
We'll not go into depth like
64
00:03:41,560 --> 00:03:44,720
exactly how they work, but yeah,
they definitely are necessary
65
00:03:44,720 --> 00:03:47,240
for asynchronous payments.
OK, awesome.
66
00:03:47,680 --> 00:03:52,080
So asynchronous payments, I
guess the first the starting
67
00:03:52,080 --> 00:03:55,680
point is what is it or maybe why
is it needed?
68
00:03:55,680 --> 00:03:58,360
Like what are we talking about?
Yeah, so in the Lightning
69
00:03:58,360 --> 00:04:04,040
network, if Alice is trying to
pay Bob, they both have to be
70
00:04:04,040 --> 00:04:06,520
online at the same time in order
for a lightning payment to
71
00:04:06,520 --> 00:04:09,600
settle.
And the people users are just
72
00:04:09,760 --> 00:04:11,400
not using that these days
anymore, right?
73
00:04:11,400 --> 00:04:15,760
So people use texts and every
communication now happens
74
00:04:15,760 --> 00:04:18,760
asynchronously.
So in Lightning Payments, users
75
00:04:18,760 --> 00:04:21,640
just expect it to work
asynchronously as well.
76
00:04:22,040 --> 00:04:25,040
And in Bitcoin, so you're also
used to payments being
77
00:04:25,040 --> 00:04:26,480
asynchronous, right?
You have an address.
78
00:04:26,480 --> 00:04:28,840
You sent some money to it
whenever you want.
79
00:04:28,920 --> 00:04:31,440
Exactly, Yeah.
So you don't have to be online
80
00:04:31,440 --> 00:04:35,000
at the same time for that.
Yeah, So to give a very concrete
81
00:04:35,000 --> 00:04:37,760
example of something that
happened to me this week and
82
00:04:37,760 --> 00:04:40,440
also allows me one more option
to show my book.
83
00:04:41,120 --> 00:04:42,360
That's all right.
It's yeah.
84
00:04:42,360 --> 00:04:44,960
So someone wanted to buy the
Genesis book from me, like an
85
00:04:44,960 --> 00:04:47,480
autograph version.
And then he emailed me and he
86
00:04:47,480 --> 00:04:50,520
wanted to pay in Lightning and I
said, yeah, sure, that's fine.
87
00:04:50,960 --> 00:04:53,440
And then sent him back.
You know, using the Breeze wall
88
00:04:53,440 --> 00:04:56,680
is actually a Lightning address.
But obviously then I have to
89
00:04:56,680 --> 00:04:59,560
like keep my wallet open and I
don't know for how long because
90
00:04:59,600 --> 00:05:01,960
before it's going to make the
payment.
91
00:05:01,960 --> 00:05:04,600
So that kind of stuff is just
very complicated with Lightning.
92
00:05:04,600 --> 00:05:07,880
So in the end I sent him an on
chain address because that way
93
00:05:08,040 --> 00:05:09,440
you can just send whenever he
wants.
94
00:05:09,920 --> 00:05:15,000
So essentially that is what we,
you lightning developers are
95
00:05:15,000 --> 00:05:19,480
trying to achieve with lightning
as well.
96
00:05:19,480 --> 00:05:23,240
You can send a invoice that can
be paid at any point.
97
00:05:23,240 --> 00:05:24,680
Is that even the right way of
framing?
98
00:05:24,680 --> 00:05:26,600
It yeah.
So maybe you can walk into the
99
00:05:26,600 --> 00:05:30,600
problem that you had first
because well, first of all, your
100
00:05:30,600 --> 00:05:34,200
app has to be running.
It needs CPU time in order to
101
00:05:34,920 --> 00:05:38,000
sign messages for receiving the
lightning payment.
102
00:05:38,600 --> 00:05:40,480
And it needs to receive data,
right?
103
00:05:40,720 --> 00:05:43,800
Yeah, it needs to receive data
and it needs to sign messages.
104
00:05:44,000 --> 00:05:45,640
Exactly.
So.
105
00:05:46,480 --> 00:05:48,920
So if you're not online, well,
you won't be able to do that.
106
00:05:49,000 --> 00:05:50,880
And so you won't be able to
receive the payment.
107
00:05:51,280 --> 00:05:57,200
But if you, if Bob, if let's say
Alice is trying to send a
108
00:05:57,200 --> 00:06:02,000
payment and she's sending it to
you, then Alice is going to find
109
00:06:02,000 --> 00:06:03,400
a route over the Lightning
network.
110
00:06:03,600 --> 00:06:08,240
And a naive thing you would what
could try to do is just the last
111
00:06:08,240 --> 00:06:11,160
hop which is for you was the
Breeze LSB.
112
00:06:11,360 --> 00:06:14,240
Breeze Lightning service
provider, which is the node that
113
00:06:14,240 --> 00:06:19,800
you are connected to, could hold
the payment until you come
114
00:06:19,800 --> 00:06:22,680
online and then forward the
payment to you.
115
00:06:24,040 --> 00:06:27,400
There will be a naive approach
in trying to solve that Alice,
116
00:06:27,800 --> 00:06:30,000
and you don't have to be online
at the same time.
117
00:06:30,440 --> 00:06:33,520
And it's naive, I would assume,
because in that case Breeze can
118
00:06:33,560 --> 00:06:35,840
steal my money.
No, they definitely can steal
119
00:06:35,840 --> 00:06:38,240
your money.
But the problem is we're locking
120
00:06:38,240 --> 00:06:41,720
liquidity in the network right
now if we do this.
121
00:06:42,280 --> 00:06:47,320
So because Alice is Alice's
repayment, maybe we can explain
122
00:06:47,320 --> 00:06:49,680
a little bit what a lightning
payment is first.
123
00:06:50,120 --> 00:06:53,760
So first you allocate, you find
a route through the network.
124
00:06:54,000 --> 00:06:59,880
So you go, yeah, you you find a
path over different nodes, over
125
00:06:59,880 --> 00:07:03,600
different channels and then
you're when sending a payment,
126
00:07:03,800 --> 00:07:06,520
first you're going to allocate
liquidity in each of these
127
00:07:06,520 --> 00:07:14,840
channels that will be that's
sort of locked until you get the
128
00:07:14,840 --> 00:07:19,080
pre image back that comes from
from you when whenever you
129
00:07:19,080 --> 00:07:22,440
settle the payment pre image
comes back to Alice and only
130
00:07:22,440 --> 00:07:24,800
then are the funds released.
Yeah.
131
00:07:24,800 --> 00:07:27,760
So I guess another way to
describe is there's, there's a
132
00:07:27,760 --> 00:07:30,080
secret at the end of the tunnel
essentially right there.
133
00:07:30,080 --> 00:07:33,400
So that the payee, no the, yeah,
the payee, the person receiving
134
00:07:33,400 --> 00:07:39,400
the payment has a secret and the
person making the payment has to
135
00:07:40,240 --> 00:07:43,480
allocate liquidity and then like
every hop does the same thing
136
00:07:43,600 --> 00:07:47,080
and then the last hop gets the
secret and then sends it back to
137
00:07:47,080 --> 00:07:49,440
the payer.
So there there's information
138
00:07:49,440 --> 00:07:52,600
that goes towards the from the
from the sender to the
139
00:07:52,600 --> 00:07:54,320
recipient, and then there's
information that has to go back
140
00:07:54,320 --> 00:07:56,320
from the recipient to the
sender.
141
00:07:56,800 --> 00:07:59,800
And as long as that information
has not made the full return
142
00:07:59,800 --> 00:08:03,320
trip, the liquidity is locked up
all over the channel.
143
00:08:03,560 --> 00:08:05,160
Yeah.
So all over the network the
144
00:08:06,040 --> 00:08:09,640
liquidity will be locked and
well that's that's something we
145
00:08:09,640 --> 00:08:12,720
don't want into Lighting network
was usually when a payment is is
146
00:08:12,720 --> 00:08:15,760
happy with in a happy flow,
these payments settle within a
147
00:08:15,760 --> 00:08:19,840
second, right.
But if you just turn your phone
148
00:08:19,840 --> 00:08:23,160
off for a day, then liquidity is
suddenly locked for for an
149
00:08:23,160 --> 00:08:26,000
entire day.
Why is this a problem?
150
00:08:26,680 --> 00:08:29,520
Yeah, it's a problem because of
that feature that I just
151
00:08:29,520 --> 00:08:32,559
described.
Yeah, you would expect the
152
00:08:32,760 --> 00:08:36,200
liquidity to settle very quickly
over the Lightning Network.
153
00:08:36,440 --> 00:08:41,080
So if you lock this liquidity
for a long time, you're locking
154
00:08:41,080 --> 00:08:44,640
it in multiple channels as well.
So the amount of your payment is
155
00:08:44,640 --> 00:08:49,840
locked over multiple channels,
so you exponentially degrade the
156
00:08:50,640 --> 00:08:53,520
the ability of the lightning
network to be able to forward
157
00:08:53,520 --> 00:08:55,640
payments this way it.
Basically means you need bigger
158
00:08:55,640 --> 00:08:59,040
channels, right?
Because if you're only using
159
00:08:59,040 --> 00:09:02,800
channels one second at a time,
then maybe a one Bitcoin channel
160
00:09:02,800 --> 00:09:06,000
is enough.
But if the you know, if that one
161
00:09:06,000 --> 00:09:08,960
Bitcoin is just locked up for
two weeks, then you need a much
162
00:09:08,960 --> 00:09:11,000
bigger channel.
OK, and just for my
163
00:09:11,000 --> 00:09:14,520
understanding, is this the only
problem we're trying to solve
164
00:09:14,520 --> 00:09:17,760
like is let's say we would all
use bigger channels, would that
165
00:09:17,760 --> 00:09:20,120
just sort of also solve the
problem in that sense?
166
00:09:20,480 --> 00:09:22,360
No, no.
If if people start sending more
167
00:09:22,360 --> 00:09:25,800
payments, then bigger channels
are no longer an option anymore
168
00:09:26,480 --> 00:09:29,400
or don't no longer work.
Yeah, OK.
169
00:09:29,400 --> 00:09:33,360
And is this is this the problem
we're trying to solve, or is
170
00:09:33,360 --> 00:09:35,720
there are other problems
involved as well?
171
00:09:36,240 --> 00:09:38,680
Yeah.
So the main, so there's two
172
00:09:38,800 --> 00:09:40,720
aspects of this.
There's one of them is that we
173
00:09:40,720 --> 00:09:43,320
don't want to look lock this
liquidity in the network while
174
00:09:43,320 --> 00:09:47,920
the payment is in flight.
And the other one is also has to
175
00:09:47,920 --> 00:09:53,120
do with the invoice generation.
So because Alice and Bob
176
00:09:53,960 --> 00:09:56,800
presumably are not online at the
same time, they won't maybe
177
00:09:56,800 --> 00:10:01,120
won't exchange an invoice.
So Alice needs a way to
178
00:10:01,120 --> 00:10:04,880
statically create an invoice.
Because an example of your book,
179
00:10:04,880 --> 00:10:08,720
you created an invoice, but only
once you saw the e-mail.
180
00:10:09,280 --> 00:10:12,240
So yeah, whoever wanted to buy
the book had to wait for you to
181
00:10:12,240 --> 00:10:14,760
do that.
And it'd be better if the person
182
00:10:14,760 --> 00:10:16,920
who wants to buy the book does
not have to wait for you to make
183
00:10:16,920 --> 00:10:19,120
an invoice.
But then the problem is that
184
00:10:19,240 --> 00:10:24,160
standard lightning invoices, the
Bolt 11 format, you can pay them
185
00:10:24,160 --> 00:10:26,920
once, right?
So, So you can make an invoice
186
00:10:26,920 --> 00:10:29,280
and say, well, whoever is the
first person to buy my book, pay
187
00:10:29,280 --> 00:10:31,960
this invoice.
But now if you want to scale
188
00:10:31,960 --> 00:10:33,640
that and you want to sell
multiple books, well you'd
189
00:10:33,640 --> 00:10:36,440
probably have to make multiple
invoices and put them on your
190
00:10:36,440 --> 00:10:39,720
website and tell people to pick
which one.
191
00:10:39,720 --> 00:10:42,360
I don't know.
OK, so let's cover that problem
192
00:10:42,360 --> 00:10:44,800
first.
I I need a way to sort of
193
00:10:44,800 --> 00:10:47,920
automatically generate invoices
even though my phone is switched
194
00:10:47,960 --> 00:10:49,160
off I guess.
Right.
195
00:10:50,000 --> 00:10:52,600
Yeah.
So yeah, so if you would
196
00:10:52,720 --> 00:10:55,840
currently create a BOLT 11
invoice, which is the invoice
197
00:10:55,840 --> 00:10:57,480
format we use on a lighting
network today.
198
00:10:59,000 --> 00:11:02,400
If you get that invoice paid,
then you release the the pre
199
00:11:02,400 --> 00:11:06,920
image which is your secret,
which is the payment secret and
200
00:11:08,480 --> 00:11:10,960
so nobody else will be able to
pay that again because an
201
00:11:10,960 --> 00:11:15,400
intermediate node would be able
to intercept your payment and
202
00:11:15,400 --> 00:11:18,360
settle the payment without the
payment ever arriving to you
203
00:11:18,360 --> 00:11:19,960
because he already knows the
secret.
204
00:11:20,320 --> 00:11:23,440
Yeah, the secrets can only be
used once for a for a one
205
00:11:23,440 --> 00:11:26,040
payment flow essentially.
Yeah, so the secret can only be
206
00:11:26,040 --> 00:11:28,320
used once, which means the
invoice can only be used.
207
00:11:28,320 --> 00:11:32,480
And this is a secret that I'm
generating on my Breeze Bullet
208
00:11:32,480 --> 00:11:34,000
app.
Basically a random number.
209
00:11:34,320 --> 00:11:38,440
Yeah yeah, so.
So first we need to tackle that
210
00:11:38,440 --> 00:11:41,720
and the the best way to do that
is to create an actually a
211
00:11:41,760 --> 00:11:44,360
static invoice which would be
reusable.
212
00:11:45,800 --> 00:11:48,120
So you could just post that on
your website.
213
00:11:48,120 --> 00:11:52,640
Say well a book costs this and
this cost money and senders
214
00:11:52,640 --> 00:11:56,200
would be able to pay to this
invoice an infinite amount of
215
00:11:56,200 --> 00:12:00,240
times.
And for that we we need a
216
00:12:00,240 --> 00:12:03,000
different model.
And this different model works
217
00:12:03,000 --> 00:12:05,840
with PTLCS.
So currently the way we
218
00:12:05,840 --> 00:12:11,480
described, you've got a secret,
and this secret is hashed into
219
00:12:11,480 --> 00:12:16,840
the invoice, which and then and
then HCLCS are sent over the
220
00:12:16,840 --> 00:12:18,640
lightning network.
I think you've covered this in
221
00:12:18,640 --> 00:12:21,520
Lightning episodes.
We've previously tried to
222
00:12:21,520 --> 00:12:25,960
explain what we generally also
explain what hashes are.
223
00:12:27,440 --> 00:12:30,480
So we definitely had like a
basic Lightner lightning
224
00:12:30,480 --> 00:12:32,920
explainer episode at one point,
and I'm sure we must have
225
00:12:32,920 --> 00:12:34,960
covered this.
Yeah, It's a couple of years
226
00:12:34,960 --> 00:12:37,520
ago, so I don't remember
exactly, but presumably yes.
227
00:12:37,840 --> 00:12:39,520
But the hash, it's the hash of
the secret.
228
00:12:39,760 --> 00:12:41,440
That's what you're sending to
the other side.
229
00:12:41,440 --> 00:12:43,440
And the other side says, if,
please give me the secret that
230
00:12:43,440 --> 00:12:45,680
belongs to this hash.
And that's really the message
231
00:12:45,680 --> 00:12:47,520
you're forwarding along all
these channels.
232
00:12:49,160 --> 00:12:50,840
Right.
So that's called an HTLC.
233
00:12:50,840 --> 00:12:54,080
So what is a PTLC?
Yeah, and it's basically sort of
234
00:12:54,080 --> 00:12:58,560
the same construct, only instead
of having a pre image and a
235
00:12:58,560 --> 00:13:02,960
hash, you have a private key and
a public key which is called a
236
00:13:02,960 --> 00:13:05,840
payment point.
And that's why it's called a
237
00:13:05,840 --> 00:13:08,640
point time lock contract.
So it's not a hash time lock
238
00:13:08,640 --> 00:13:10,440
contract, but a point time lock
contract.
239
00:13:11,240 --> 00:13:15,640
And the trick with these public
keys is you can tweak them,
240
00:13:17,120 --> 00:13:20,840
which make them so, and you can
basically derive as much keys as
241
00:13:20,840 --> 00:13:25,280
you want from a single public
key which make them yeah, you
242
00:13:25,280 --> 00:13:28,080
can make an infinite amount of
secrets from.
243
00:13:28,400 --> 00:13:31,200
Yeah, one of our very first
episodes talked about taproot
244
00:13:31,280 --> 00:13:34,480
and why taproot is so cool.
And one of the aspects of it
245
00:13:34,480 --> 00:13:38,840
said it's very easy to add add a
number to a private key and then
246
00:13:38,840 --> 00:13:43,600
add essentially the same number
to the public key and then well.
247
00:13:43,600 --> 00:13:45,160
That's snore, basically, right?
But yeah.
248
00:13:45,160 --> 00:13:48,280
Yes, and that's that's already
possible with ECDH, but it's
249
00:13:48,280 --> 00:13:50,720
just much, much easier with
Schnorr.
250
00:13:51,280 --> 00:13:54,880
And this PTLC construct makes
use of that, right?
251
00:13:54,880 --> 00:13:59,840
But the ability to add some
random number to A to a private
252
00:13:59,840 --> 00:14:02,240
key, and the other side can do
that to the public key.
253
00:14:02,600 --> 00:14:04,320
So even if you don't have the
public key, you know how to
254
00:14:04,320 --> 00:14:05,840
tweak it.
And you cannot do that with
255
00:14:05,840 --> 00:14:09,240
hashes, because if it hashes, if
you take the number, if you take
256
00:14:09,240 --> 00:14:12,360
the letter A for example, and
you hash it, you get some large
257
00:14:12,360 --> 00:14:14,360
number.
Then if you say, oh, I'm just
258
00:14:14,360 --> 00:14:17,920
going to change A to B, well the
other side has no idea, Like you
259
00:14:17,920 --> 00:14:20,560
cannot just take the hash of A
and then take the hash of B and
260
00:14:20,560 --> 00:14:22,040
add them together.
That's not going to give you the
261
00:14:22,040 --> 00:14:25,320
same result.
Yeah, Yeah.
262
00:14:25,320 --> 00:14:28,800
So and so it is.
It does work with with points,
263
00:14:28,800 --> 00:14:31,880
what with payment points.
And So what a sender can do is
264
00:14:31,960 --> 00:14:36,040
is going to, for each
intermediate hub, generate a
265
00:14:36,040 --> 00:14:38,920
different secret basically.
So each intermediate hub is
266
00:14:38,920 --> 00:14:44,600
going to think that the that
it's a different secret than the
267
00:14:44,600 --> 00:14:47,360
1 the recipient actually
created, and so each
268
00:14:47,360 --> 00:14:54,040
intermediate hub won't ever
learn the actual secret from the
269
00:14:54,040 --> 00:14:56,480
PE.
But how does how does that work
270
00:14:56,480 --> 00:14:59,320
if you're making two payments to
the same route?
271
00:15:00,000 --> 00:15:01,960
Because what's what?
What is it that makes a second
272
00:15:02,000 --> 00:15:03,400
payment different from the first
payment?
273
00:15:04,160 --> 00:15:08,920
So the trick is that Alice,
which is the sender, she
274
00:15:09,560 --> 00:15:13,280
generates a random number as
well, which tweaks tweaks the
275
00:15:14,000 --> 00:15:19,800
the public key and the
intermediate notes they use.
276
00:15:19,800 --> 00:15:25,800
This tweaks public key as as the
the for the in order to in order
277
00:15:25,800 --> 00:15:28,880
to learn the secret basically.
Yeah, so it's never the same
278
00:15:28,880 --> 00:15:30,680
secret.
It's never the same secret, and
279
00:15:30,680 --> 00:15:32,960
not for any intermediate hub as
well, yeah.
280
00:15:33,600 --> 00:15:36,320
So even if two different people
make a payment, they both the
281
00:15:36,440 --> 00:15:39,360
the sender picks the random
number, so the recipient doesn't
282
00:15:39,360 --> 00:15:41,840
have to do anything.
As long as each sender picks a
283
00:15:41,840 --> 00:15:44,080
random number, they cannot reuse
the same secret.
284
00:15:44,760 --> 00:15:47,760
Yeah, and it's in the best
interest of the sender to pick a
285
00:15:47,800 --> 00:15:51,760
random number then, because it's
his payment that will be stolen
286
00:15:51,800 --> 00:15:57,280
otherwise.
OK, so in this case, you know
287
00:15:57,280 --> 00:16:00,560
I'm trying to sell the Genesis
book to someone, so I got to
288
00:16:00,880 --> 00:16:04,280
generate an invoice.
Who's generating?
289
00:16:04,760 --> 00:16:07,760
Why does this generation happen?
What happens exactly?
290
00:16:07,760 --> 00:16:11,800
Yeah, so you create an invoice
and it's got a payment point
291
00:16:11,800 --> 00:16:14,720
inside inside of your invoice,
and you just put that up on your
292
00:16:14,720 --> 00:16:17,400
website.
I'm a sender, I scan your
293
00:16:17,400 --> 00:16:22,120
invoice and I'm going to tweak
your payment points with random
294
00:16:22,120 --> 00:16:25,760
numbers right along the route,
right?
295
00:16:25,760 --> 00:16:28,480
So nobody learns about the
actual secret when the secret
296
00:16:28,480 --> 00:16:30,880
comes back to to the sender,
right?
297
00:16:31,200 --> 00:16:33,560
OK, got it.
That that part makes sense to
298
00:16:33,560 --> 00:16:35,360
me.
So that removes the
299
00:16:35,360 --> 00:16:38,240
interactivity from you having to
make an invoice.
300
00:16:38,480 --> 00:16:41,560
But in this scenario, you're
still online because you are
301
00:16:41,560 --> 00:16:45,760
clearly perceiving the payment
and sending back to secret every
302
00:16:45,760 --> 00:16:47,200
time somebody makes a payment.
Yeah.
303
00:16:47,200 --> 00:16:50,120
So that was the second part of
the problem I think we're trying
304
00:16:50,120 --> 00:16:53,120
to solve right now.
My phone is, you know, I emailed
305
00:16:53,360 --> 00:16:55,680
this guy back or whatever.
My phone is switched off and now
306
00:16:55,680 --> 00:16:59,080
I still need to receive the
payment without locking these
307
00:16:59,080 --> 00:17:02,120
funds along all these channels.
Because that's, yeah, so.
308
00:17:02,120 --> 00:17:04,160
Your friend has downloaded the
invoice from your website
309
00:17:04,160 --> 00:17:05,680
instead of having to send you an
e-mail.
310
00:17:06,359 --> 00:17:09,599
But in this so far we've we've
still reached the point where,
311
00:17:09,599 --> 00:17:12,000
OK, they don't have to e-mail
you anymore, they just make the
312
00:17:12,000 --> 00:17:13,480
payment.
But your wallet still needs to
313
00:17:13,480 --> 00:17:14,640
be online to receive the
payment.
314
00:17:14,720 --> 00:17:16,960
Yes.
OK, so how do we solve this
315
00:17:16,960 --> 00:17:17,640
problem?
Yes, Sir.
316
00:17:17,720 --> 00:17:20,480
OK, let's go over how async
payments works then.
317
00:17:21,240 --> 00:17:27,560
So Alice is going to pay Bob and
Alice is going to be connected
318
00:17:27,560 --> 00:17:31,920
to the Lightning network through
a Lightning Service Provider and
319
00:17:31,920 --> 00:17:34,520
Bob is going to be connected to
the lightning network through a
320
00:17:34,520 --> 00:17:38,320
a lightning service provider.
Where alert Lightning service
321
00:17:38,320 --> 00:17:43,320
provider is basically just a
node that that you're connected
322
00:17:43,320 --> 00:17:47,840
to to the lightning network and
this node is well connected to
323
00:17:47,840 --> 00:17:50,120
the lightning network.
Yeah so the concrete example
324
00:17:50,120 --> 00:17:52,600
here would be for example breeze
I think right?
325
00:17:52,600 --> 00:17:56,560
Like my wallet is not a full
node, it just connects to
326
00:17:57,080 --> 00:17:58,800
breezes full nodes.
Yeah.
327
00:17:59,080 --> 00:18:04,080
And and Breeze's full node is
tolerant of you being offline a
328
00:18:04,080 --> 00:18:07,200
lot, which is why we call this a
Lightning service provider.
329
00:18:07,200 --> 00:18:09,680
But it could basically be any
node that's tolerant to that.
330
00:18:11,840 --> 00:18:18,840
And what Alice is going to do is
going to is going to send the
331
00:18:18,840 --> 00:18:26,200
payment to Bob, but it's going
to tell her LSP, please hold
332
00:18:26,200 --> 00:18:30,720
this payment until you receive a
message that you can release it.
333
00:18:30,920 --> 00:18:33,960
That she's telling her own LSP.
That she's telling her own LSP
334
00:18:33,960 --> 00:18:37,880
that and the reason she doesn't.
Otherwise, it's a regular
335
00:18:37,880 --> 00:18:40,920
lighting payment with a PTLC,
then it's a regular.
336
00:18:40,920 --> 00:18:44,000
It's normal, she just says to
her own service provider.
337
00:18:44,000 --> 00:18:46,240
Don't send this yet.
Yeah, exactly.
338
00:18:46,240 --> 00:18:47,760
Yeah.
And this message is inside the
339
00:18:47,760 --> 00:18:51,960
payment itself, but so basically
it's a regular Lighting payment.
340
00:18:52,560 --> 00:18:55,880
And so at this point the Alice's
LSP cannot steal the money,
341
00:18:55,880 --> 00:18:57,200
right?
It's not that she's making a
342
00:18:57,200 --> 00:19:01,640
payment to her LSP, she is doing
the first step of the payment,
343
00:19:01,840 --> 00:19:05,120
which is giving the pre image.
No, not the payment, It's giving
344
00:19:05,120 --> 00:19:11,040
the the point, the basically the
the public thing of the secret
345
00:19:11,680 --> 00:19:16,080
to her payment provider who
cannot take the money unless
346
00:19:16,400 --> 00:19:18,600
they get the secret.
And in order to get the secret
347
00:19:18,600 --> 00:19:21,040
they have to forward it.
But all Alice is doing is
348
00:19:21,040 --> 00:19:24,240
saying, oh wait a minute, don't
forward it just yet because Bob
349
00:19:24,240 --> 00:19:26,000
might not be online.
Exactly.
350
00:19:26,000 --> 00:19:28,040
Yeah.
So we know the reason why she
351
00:19:28,120 --> 00:19:33,200
why the LSP is not forwarding,
forwarding it, and what Alice is
352
00:19:33,200 --> 00:19:36,600
going to do as well.
She's going to send an onion
353
00:19:36,600 --> 00:19:41,640
message to Bob saying, hey,
there's a pending payment here.
354
00:19:42,560 --> 00:19:47,360
If you want to release that
whenever you're online, send a
355
00:19:47,360 --> 00:19:49,360
message back along this path
over here.
356
00:19:49,360 --> 00:19:52,360
And there's an encrypted path
inside this message as well.
357
00:19:52,600 --> 00:19:55,040
When you say onion message, what
do you mean by that?
358
00:19:55,280 --> 00:19:59,440
An onion message is so over the
lighting network we route
359
00:19:59,440 --> 00:20:03,640
payments over onions as well,
basically meaning that every hop
360
00:20:05,320 --> 00:20:09,760
where this message is routed
over is encrypted, so it sort of
361
00:20:09,760 --> 00:20:13,640
gets becomes an onion of
encryption where onions have
362
00:20:13,640 --> 00:20:16,400
layers.
So every every point in a route
363
00:20:16,640 --> 00:20:20,520
can only see which point is
coming next, or which node is
364
00:20:20,520 --> 00:20:23,240
coming next and which node came
before it, but cannot see
365
00:20:23,240 --> 00:20:27,400
further in either direction,
which we claimed a bit in our
366
00:20:27,400 --> 00:20:30,600
episode about Bold 12.
Yeah, and you can basically send
367
00:20:30,640 --> 00:20:34,040
arbitrary messages over this
construction over the liking
368
00:20:34,040 --> 00:20:38,200
network then, right?
And she's going to send this to
369
00:20:38,200 --> 00:20:41,240
Bob and with a reply path then
to her LSP.
370
00:20:42,760 --> 00:20:46,160
So Bob will be able to unlock
the the payment.
371
00:20:46,160 --> 00:20:49,320
So it's it actually becomes
forwarded, but Bob is offline of
372
00:20:49,320 --> 00:20:52,920
course.
So the LSP is of Bob will hold
373
00:20:52,920 --> 00:20:56,960
this on your message until Bob
is online, right, Because the
374
00:20:56,960 --> 00:20:59,960
LSP knows well I have to forward
this to Bob, Bob is not there.
375
00:21:00,320 --> 00:21:02,320
So I'm just going to wait until
Bob is online.
376
00:21:02,440 --> 00:21:04,840
Right and.
The LSP cannot read what is in
377
00:21:04,840 --> 00:21:07,080
the message, just knows like I
have a message for Bob.
378
00:21:07,080 --> 00:21:09,600
I don't know where it came from,
but I'll give it to Bob when Bob
379
00:21:09,600 --> 00:21:11,080
is online.
Yeah.
380
00:21:11,080 --> 00:21:13,720
And in this case, it's obviously
not a problem because no funds
381
00:21:13,720 --> 00:21:15,440
are being locked up.
It's just a message.
382
00:21:15,640 --> 00:21:18,600
Yeah, yeah.
OK, so that's the onion message
383
00:21:18,600 --> 00:21:22,760
goes first to Bob's service
provider and he will forward
384
00:21:22,760 --> 00:21:24,360
that to Bob or Bob's going
online.
385
00:21:24,360 --> 00:21:25,920
Bob.
Bob comes online, turns his
386
00:21:25,920 --> 00:21:29,520
photos on or as you know, Breeze
app or whatever Lightning app he
387
00:21:29,560 --> 00:21:32,040
has sees this message, or
probably as well.
388
00:21:32,040 --> 00:21:33,880
It just responds to the message
I would assume.
389
00:21:33,960 --> 00:21:35,840
Yeah, yeah, yeah.
He doesn't have to actually see
390
00:21:35,840 --> 00:21:36,880
it.
Yeah, it just all goes
391
00:21:36,880 --> 00:21:39,400
automatic.
But we will say that he that his
392
00:21:39,400 --> 00:21:42,400
wallet sees the message and then
he's going to reply over the
393
00:21:42,400 --> 00:21:44,520
reply path.
So he doesn't really know where
394
00:21:44,520 --> 00:21:46,240
the where the message is coming
from.
395
00:21:46,560 --> 00:21:49,040
He just knows that he has to
send an onion message there in
396
00:21:49,040 --> 00:21:54,920
order to unlock it and then.
So Alice's LSP, who is still
397
00:21:54,920 --> 00:22:01,440
holding that payment right now?
By the way, Alice, after she
398
00:22:01,440 --> 00:22:05,160
sent the onion lessons to Bob,
was able to go offline, right?
399
00:22:05,160 --> 00:22:07,320
She could put her phone back in
her pocket.
400
00:22:07,320 --> 00:22:09,960
So important part that they
don't have to be online at the
401
00:22:09,960 --> 00:22:15,880
same time, yeah.
Because Alice's LSP now has the
402
00:22:15,880 --> 00:22:18,000
money, in a way.
Yeah, has the money in a way.
403
00:22:18,560 --> 00:22:22,440
And now, so we're now at the
point where Alice's LSP received
404
00:22:22,440 --> 00:22:25,360
the onion message from Bob
saying please forward this
405
00:22:25,360 --> 00:22:27,800
payment.
Then the LSP forwards the
406
00:22:27,800 --> 00:22:31,440
payment to Bob, and Bob is
online now, so he's able to
407
00:22:32,200 --> 00:22:36,120
settle the payment.
So he's going to release the pre
408
00:22:36,120 --> 00:22:41,840
image and the pre image goes
back all the way to to Alice's
409
00:22:41,840 --> 00:22:46,360
LSP.
And Alice's LSP, whenever Alice
410
00:22:46,360 --> 00:22:50,200
comes online, is able to settle
the last piece between her and
411
00:22:50,200 --> 00:22:53,920
Alice, because only her channel
with Alice is now still in a
412
00:22:53,920 --> 00:22:56,960
state where funds are in limbo.
Right.
413
00:22:57,000 --> 00:22:58,520
Yeah.
So the, I guess the only player
414
00:22:58,520 --> 00:23:02,160
in this story that needs to hold
funds in, in limbo in a channel
415
00:23:02,160 --> 00:23:05,720
longer than you'd normally want
to do is the channel between
416
00:23:05,720 --> 00:23:08,160
Alice and her lightning service
provider.
417
00:23:08,160 --> 00:23:11,200
So obviously the Lightning
service provider will want to be
418
00:23:11,200 --> 00:23:15,600
compensated for that in a way.
But if Alice is a mobile node,
419
00:23:15,600 --> 00:23:18,760
then that money is probably
going to be stuck kind of stuck
420
00:23:18,760 --> 00:23:21,280
anyway, because if she's not
online, they can route through
421
00:23:21,280 --> 00:23:24,000
it and she probably doesn't have
any other channels.
422
00:23:24,000 --> 00:23:26,080
So yeah, it's not a routing node
anyway.
423
00:23:26,160 --> 00:23:30,600
And LSP will already allocate
liquidity towards these users.
424
00:23:31,920 --> 00:23:35,000
So I don't think there will be
any specific compensation for
425
00:23:35,000 --> 00:23:37,760
this, just probably for the fact
of being a liking service
426
00:23:37,760 --> 00:23:39,440
provider and allocating
liquidity.
427
00:23:39,880 --> 00:23:41,600
Maybe you'll pay something for
that, yeah?
428
00:23:42,600 --> 00:23:45,680
We promised, or I promised that
we would also cover trampling
429
00:23:45,680 --> 00:23:46,440
payments.
Where?
430
00:23:46,440 --> 00:23:48,720
Where does this come in?
So there's this in.
431
00:23:48,720 --> 00:23:51,200
In some situations it would just
work this way, right?
432
00:23:51,520 --> 00:23:54,520
In some situations it would just
work, but there is actually a
433
00:23:54,520 --> 00:23:59,240
problem because if Alice finds a
route for this payment over the
434
00:23:59,240 --> 00:24:03,920
lighting network to Bob, usually
in Lightning what happens is you
435
00:24:03,920 --> 00:24:07,400
find a route, you try the route
and then somewhere along the
436
00:24:07,400 --> 00:24:11,480
route either notice offline or
doesn't have enough liquidity or
437
00:24:12,520 --> 00:24:15,320
and this route fails and what
you know is going to do is going
438
00:24:15,320 --> 00:24:17,840
to find another route.
And this is also, by the way,
439
00:24:17,840 --> 00:24:21,080
where I'd like to shield the
episode with Renee Picard we did
440
00:24:21,080 --> 00:24:28,440
a few years ago explaining sort
of his his pathfinding, optimal
441
00:24:28,800 --> 00:24:31,240
way of making payments.
But it also involves lots of
442
00:24:31,240 --> 00:24:35,000
attempts.
Yeah, quite quite a few attempts
443
00:24:35,000 --> 00:24:38,040
to get a payment through.
It's by designed as some privacy
444
00:24:38,040 --> 00:24:41,200
in the Lightning protocol.
So you don't know exactly how
445
00:24:41,200 --> 00:24:43,560
much room there is in all the
channels along the route.
446
00:24:44,640 --> 00:24:48,240
You you know how big the channel
is, but you don't know where the
447
00:24:48,240 --> 00:24:50,040
money is in that Channel, so you
don't know how much you can
448
00:24:50,040 --> 00:24:52,640
actually send through it.
And this changes every time as
449
00:24:52,640 --> 00:24:55,480
well.
Yeah, that was, that was a short
450
00:24:55,480 --> 00:24:57,440
special, I believe, right?
Yes.
451
00:24:58,560 --> 00:25:00,440
But you don't know the episode,
I'm sure, no.
452
00:25:00,640 --> 00:25:01,920
OK.
OK.
453
00:25:01,960 --> 00:25:05,040
Yes, Sir.
Yeah, so Alice, if she created
454
00:25:05,040 --> 00:25:08,360
this first route and this route
fails, that would mean that she
455
00:25:08,360 --> 00:25:10,840
would only retry whenever she
comes back online again.
456
00:25:10,840 --> 00:25:14,360
You don't know when that is.
So what Alice can do is she can
457
00:25:14,520 --> 00:25:18,160
delegate the path finding to
another node.
458
00:25:19,520 --> 00:25:22,720
And this is a feature in the
Lightning Network that's being
459
00:25:22,720 --> 00:25:26,560
implemented in in several Node
implementations.
460
00:25:27,200 --> 00:25:30,240
Asank already uses it and it's
called Trampoline Payments.
461
00:25:31,120 --> 00:25:36,000
So basically Alice is going to
ask her LSB please, I want to
462
00:25:36,280 --> 00:25:39,840
forward this payment to this
direction please.
463
00:25:39,840 --> 00:25:42,120
Do you find the best path over
the light network?
464
00:25:42,120 --> 00:25:44,920
And I'm I'm just going to chill
and go offline now.
465
00:25:45,360 --> 00:25:46,960
Yeah.
And and so this works by
466
00:25:46,960 --> 00:25:49,840
providing A carte blanche in
terms of fees, right?
467
00:25:49,840 --> 00:25:52,560
Because normally when you
establish the route, you know
468
00:25:52,560 --> 00:25:54,920
exactly how much fees you need
to pay at every hop.
469
00:25:54,920 --> 00:25:57,280
But because you're not
establishing the route, you're
470
00:25:57,280 --> 00:26:00,680
just going to say, well, here's
a hundred sets, you figure it
471
00:26:00,680 --> 00:26:03,200
out and if you find a cheaper
route, you get the you keep the
472
00:26:03,200 --> 00:26:04,680
change.
Exactly.
473
00:26:04,720 --> 00:26:05,440
Yeah.
Yeah.
474
00:26:05,440 --> 00:26:08,840
So you give them some kind of
margin and this could be a
475
00:26:08,840 --> 00:26:12,920
competition for trampoline notes
as well to say, well, I'm the
476
00:26:12,920 --> 00:26:15,760
cheapest because I know how to
find the best routes in the
477
00:26:15,760 --> 00:26:17,800
network.
Exactly like the like the London
478
00:26:17,800 --> 00:26:21,160
taxi drivers that have the
knowledge and they they can find
479
00:26:21,160 --> 00:26:24,120
the shortest route through
London without AGPS and they
480
00:26:24,120 --> 00:26:26,720
usually are actually faster than
the Uber drivers that just
481
00:26:26,920 --> 00:26:29,160
follow Google Maps, according to
legend.
482
00:26:31,680 --> 00:26:35,560
And now, so Alice's Alice.
Alice's Alice B is now able to
483
00:26:36,000 --> 00:26:40,160
retry this payment, so whenever
it fails, and so would be able
484
00:26:40,160 --> 00:26:44,200
to reach Bob, hopefully in a
timely manner, before Bob goes
485
00:26:44,200 --> 00:26:46,320
offline again.
And so this ingredient is
486
00:26:46,320 --> 00:26:48,040
useful.
Like we said, because the
487
00:26:48,040 --> 00:26:49,840
Lightning network changes all
the time, you need to do
488
00:26:49,840 --> 00:26:56,120
multiple attempts and so this
trample line router, this can
489
00:26:56,120 --> 00:26:58,720
just try it multiple times
basically, yeah.
490
00:26:58,720 --> 00:27:02,000
The downside, of course, is
privacy, because the trampoline
491
00:27:02,000 --> 00:27:03,520
now knows where the payment is
going.
492
00:27:04,440 --> 00:27:08,520
Yes.
So the first part of this is Bob
493
00:27:09,320 --> 00:27:12,960
in his invoice could have
created a blinded path.
494
00:27:14,680 --> 00:27:17,520
So that's one part of this where
you would not actually, where
495
00:27:17,520 --> 00:27:20,800
the intermediate node would not
actually find the destination,
496
00:27:20,800 --> 00:27:22,040
right?
The trampoline node would not
497
00:27:22,040 --> 00:27:27,640
find the destination, and
another way to deal with this is
498
00:27:27,640 --> 00:27:32,760
to select multiple trampoline
hops in your route.
499
00:27:32,760 --> 00:27:36,440
So we're now using one
trampoline node.
500
00:27:37,400 --> 00:27:40,160
So Alice's LSP is going to find
different routes.
501
00:27:40,440 --> 00:27:44,960
But you could tell Alice's LSP.
So first find a route to this
502
00:27:44,960 --> 00:27:47,760
random trampoline node, then
find a route, and then that
503
00:27:47,760 --> 00:27:50,800
trampoline node has to find a
route to that random trampoline
504
00:27:50,800 --> 00:27:53,320
node.
So you could, if you value your
505
00:27:53,320 --> 00:27:58,320
privacy, you could diffuse the
path finding a little bit that
506
00:27:58,320 --> 00:27:59,200
way.
Right.
507
00:27:59,560 --> 00:28:03,440
OK.
I guess one maybe concern that
508
00:28:03,440 --> 00:28:07,360
sort of comes to my mind, but
I'll let you address that is it
509
00:28:07,360 --> 00:28:13,040
sort of sounds like this would
make Lightning users very
510
00:28:13,040 --> 00:28:16,520
dependent on service providers.
Sure.
511
00:28:16,760 --> 00:28:22,640
Mentioned they're also more
general risk and I'm asked works
512
00:28:22,640 --> 00:28:24,120
for a Lightning service
provider.
513
00:28:24,120 --> 00:28:27,720
But, you know, is this a
reasonable concern in your view?
514
00:28:27,720 --> 00:28:30,960
Or is your view maybe.
But let's hear from Yassa first.
515
00:28:31,440 --> 00:28:33,440
Yeah, from my point of view, it
depends on how.
516
00:28:34,320 --> 00:28:37,320
Sure, I said.
Let's hear from Yassa first.
517
00:28:38,440 --> 00:28:38,920
OK.
OK.
518
00:28:39,000 --> 00:28:41,840
Well, OK.
So there's a user that
519
00:28:41,840 --> 00:28:46,920
apparently online lightning
node, right?
520
00:28:46,920 --> 00:28:49,520
So he wants to run a lightning
node in his pocket.
521
00:28:50,680 --> 00:28:55,880
So that means there's no other
way the network through nodes
522
00:28:55,880 --> 00:29:02,120
that are willing to accept that.
And as a reminder why there's
523
00:29:02,480 --> 00:29:07,240
William involved here, if if you
have a channel but you're
524
00:29:07,240 --> 00:29:11,760
offline all the time.
Now if channel and all the money
525
00:29:12,240 --> 00:29:14,840
in the channel is on your own
side, then the other side is not
526
00:29:14,840 --> 00:29:18,040
going to care.
But if you have made like lots
527
00:29:18,040 --> 00:29:20,720
and lots of payments through the
channel, now all the money's on
528
00:29:20,720 --> 00:29:22,720
the other side.
The other side is going to be
529
00:29:22,720 --> 00:29:26,960
annoyed by this because when
you're offline, they cannot
530
00:29:27,200 --> 00:29:30,760
access that money at all.
They can't, but they have to
531
00:29:30,760 --> 00:29:32,280
force close it, which is
expensive.
532
00:29:32,720 --> 00:29:34,720
They can't route anything
through it because you're
533
00:29:34,720 --> 00:29:35,960
offline.
You're not a routing node.
534
00:29:36,240 --> 00:29:39,520
So that money is just they own
it, but they're forced huddling
535
00:29:39,520 --> 00:29:42,520
it essentially.
And so there is not, not
536
00:29:42,520 --> 00:29:45,080
everybody's going to be willing
to just allow you to open a
537
00:29:45,080 --> 00:29:48,280
channel and behave like that.
I think right now many nodes
538
00:29:48,280 --> 00:29:51,680
don't care, but they might close
the channel on you saying, hey,
539
00:29:51,720 --> 00:29:52,960
this is not making me enough
money.
540
00:29:53,280 --> 00:29:55,720
So a Lightning service provider,
in the very broad sense, is
541
00:29:55,720 --> 00:30:00,000
anyone who's willing to just put
up with a peer that's not online
542
00:30:00,000 --> 00:30:02,240
all the time, probably by
charging.
543
00:30:02,680 --> 00:30:08,080
Yeah, how far is this?
So there's there's a lot of
544
00:30:08,080 --> 00:30:13,320
prerequisites.
So first of all, we need to
545
00:30:13,640 --> 00:30:19,320
taproot channels in order to TEP
root channels.
546
00:30:19,320 --> 00:30:24,200
Are L&D implemented the simple
TEP root channels protocol which
547
00:30:24,200 --> 00:30:27,320
sort of works with private
channels right now, but not with
548
00:30:27,320 --> 00:30:29,480
public?
OK, it's.
549
00:30:33,400 --> 00:30:36,560
Basically the the transit.
So lightning channels are
550
00:30:36,560 --> 00:30:40,080
basically just commitment
transaction, transactions on
551
00:30:40,080 --> 00:30:42,880
chain, right.
But you update them locally and
552
00:30:43,000 --> 00:30:46,760
you broadcast don't broadcast
many of these that you sign in
553
00:30:46,760 --> 00:30:49,480
between in your channel and
these transactions are tap
554
00:30:50,360 --> 00:30:51,760
actions.
So that's basically what a
555
00:30:52,240 --> 00:30:53,640
taproot channel is.
OK.
556
00:30:55,040 --> 00:30:56,960
So, so it's pretty much what it
sounds like.
557
00:30:57,120 --> 00:30:59,400
And that's just, that's just the
main transaction.
558
00:30:59,400 --> 00:31:02,320
But then there's the HTLCS, the
things that fly over the channel
559
00:31:02,320 --> 00:31:06,760
when you're making a payment,
those to make those PTLC another
560
00:31:06,760 --> 00:31:08,640
change, right?
You can have taproot channels
561
00:31:08,640 --> 00:31:11,840
that still use locks for the
payments.
562
00:31:12,480 --> 00:31:16,800
Yeah and so and also if you use
step root channels, you need to
563
00:31:16,800 --> 00:31:18,920
gossip your channel.
So you need to tell the rest of
564
00:31:18,920 --> 00:31:26,520
the network like these are the
channels that I have and this
565
00:31:26,520 --> 00:31:31,440
also does not exist yet.
So, so there's some
566
00:31:31,440 --> 00:31:39,080
prerequisites there on side.
And then there is a proposal now
567
00:31:39,080 --> 00:31:43,600
for holding the payment, which
is one part of ASYNC payments
568
00:31:44,320 --> 00:31:48,160
where the LSP holds the payment
until a message is sent when
569
00:31:48,160 --> 00:31:51,040
it's released.
And this standard is within the
570
00:31:51,040 --> 00:31:53,800
protocol itself.
So it's not like some custom API
571
00:31:53,800 --> 00:31:56,160
of the Lightning service
provider, It's really just part
572
00:31:56,160 --> 00:31:58,560
of the Lightning protocol.
Anybody who speaks to Lighting
573
00:31:58,560 --> 00:32:01,200
protocol could hold a payment.
Yeah.
574
00:32:01,200 --> 00:32:03,840
So there it would be the
question where this ends up
575
00:32:03,840 --> 00:32:12,720
exactly in Bolts, which is is a
Lightning Improvement Proposal.
576
00:32:13,640 --> 00:32:15,680
But blips can also be
implemented by any node
577
00:32:15,840 --> 00:32:21,440
basically.
So there's that part, which is
578
00:32:26,080 --> 00:32:34,440
are currently only supported by
CLN in order to be able.
579
00:32:36,480 --> 00:32:40,400
Because on your messages of Bolt
12, right, we just made, we did
580
00:32:40,400 --> 00:32:43,400
a whole episode about BOLT 12.
We explained how on your
581
00:32:43,400 --> 00:32:45,560
messages are kind of useful in
that scheme.
582
00:32:46,000 --> 00:32:50,680
But BOLT 12 is mostly being
pushed by core Lightning and I
583
00:32:50,680 --> 00:32:54,520
guess LDK now.
And so you have to wait for I
584
00:32:54,520 --> 00:32:56,080
guess you just need 2
implementations.
585
00:32:56,080 --> 00:32:58,120
But in order for it to be
useful, it's nice if LMD
586
00:32:58,120 --> 00:33:00,800
supports it, because like a
whole bunch of nodes are
587
00:33:01,280 --> 00:33:04,880
running, LMD in the onion
message needs to go from A to B
588
00:33:04,880 --> 00:33:09,720
through all these hops.
So if you know I, I think onion
589
00:33:09,720 --> 00:33:11,600
messages can follow any route
you like, right?
590
00:33:11,600 --> 00:33:14,720
They don't have to follow any
channels that exist, they can
591
00:33:14,720 --> 00:33:16,560
just go through any way through
the network.
592
00:33:16,920 --> 00:33:18,760
Yeah, I guess, yeah, they sort
of could.
593
00:33:18,760 --> 00:33:21,760
But you only know that people
are connected through their
594
00:33:21,760 --> 00:33:23,600
channels usually.
Right.
595
00:33:23,600 --> 00:33:26,000
Yeah, yeah, yeah.
So so it has to follow some
596
00:33:26,000 --> 00:33:28,880
bunch of channels and and if all
these nodes are running LED in
597
00:33:28,880 --> 00:33:31,760
the middle, then you just don't
have a way to get your message
598
00:33:31,760 --> 00:33:34,080
to the other side.
Yeah.
599
00:33:35,600 --> 00:33:39,080
So I think we probably talked
about most of the prerequisites.
600
00:33:39,080 --> 00:33:40,240
Trampoline.
Yeah.
601
00:33:40,240 --> 00:33:41,680
So trampoline.
Yeah, exactly.
602
00:33:41,760 --> 00:33:45,080
That's done by the assigned
people that's used by Phoenix,
603
00:33:45,080 --> 00:33:46,440
but is.
It yeah, by the assigned people
604
00:33:46,480 --> 00:33:52,200
now and there's so LDK also
implemented parts of it.
605
00:33:52,200 --> 00:33:55,320
I don't think they completed
trampoline payments completely.
606
00:33:55,320 --> 00:33:56,840
Please correct me if I'm wrong
there.
607
00:33:58,520 --> 00:34:00,640
So that's also not part of the
Bolt spec yet.
608
00:34:00,680 --> 00:34:02,280
It's not merged into the spec
yet.
609
00:34:02,400 --> 00:34:05,680
OK, so basically there's still a
bunch of building blocks that
610
00:34:05,680 --> 00:34:09,040
need to be in place before this
can work, and different
611
00:34:09,040 --> 00:34:12,159
implementations are in different
stages of completing these
612
00:34:12,159 --> 00:34:13,440
building blocks.
Yeah.
613
00:34:13,600 --> 00:34:16,480
So it's basically almost every
improvement to the Lighting
614
00:34:16,480 --> 00:34:20,080
Network that we want to have is
sort of a prerequisite for async
615
00:34:20,080 --> 00:34:22,040
payments.
Sounds easy.
616
00:34:22,040 --> 00:34:23,280
Two weeks.
Yeah.
617
00:34:23,600 --> 00:34:27,080
No, it's not going to be two
weeks, but and more like several
618
00:34:27,080 --> 00:34:29,480
severally.
Is anyone against this?
619
00:34:32,239 --> 00:34:34,040
Is jungle for all against async
payments.
620
00:34:34,800 --> 00:34:38,159
He's against everything.
So I'm assuming what?
621
00:34:38,159 --> 00:34:40,400
Why are there people against
this?
622
00:34:41,480 --> 00:34:44,360
Is this, is this like in any way
controversial or are there
623
00:34:44,360 --> 00:34:47,920
concerns about this?
Or maybe there are people that
624
00:34:47,920 --> 00:34:50,280
have, you know, developers that
have different preferences?
625
00:34:50,280 --> 00:34:54,880
Or is there?
People may be against some parts
626
00:34:54,880 --> 00:35:04,480
of the upgrades, yeah, so maybe
I I'm not exactly sure about
627
00:35:04,480 --> 00:35:09,080
their reasoning, but one reason
I can come up with is that well
628
00:35:09,080 --> 00:35:12,040
on your messages they can also
be a DOS factor.
629
00:35:13,600 --> 00:35:15,800
So just, I said.
Lalo basically came up with
630
00:35:15,800 --> 00:35:16,440
that.
They said.
631
00:35:16,480 --> 00:35:21,320
Just am I misremembering that?
I I don't know about this.
632
00:35:21,320 --> 00:35:22,400
Exactly.
Oh, never mind.
633
00:35:23,520 --> 00:35:27,760
OK, so they they might be
against onion messages.
634
00:35:27,760 --> 00:35:29,520
Or are they against onion
messages?
635
00:35:29,520 --> 00:35:31,040
Yeah, you you think?
So, well, they're not
636
00:35:31,040 --> 00:35:38,640
implementing it.
They they do have so, so LNDK
637
00:35:39,120 --> 00:35:41,720
which is sort of like an
extension to L&D which does
638
00:35:41,720 --> 00:35:43,880
support all your messages and.
Yeah.
639
00:35:43,880 --> 00:35:46,840
I mean, sometimes, most of the
time when somebody doesn't
640
00:35:46,840 --> 00:35:48,920
implement something, it's just
because they don't have time for
641
00:35:48,920 --> 00:35:51,280
it because they're working on
6000 other things that have that
642
00:35:51,280 --> 00:35:53,000
priority.
It's not that they're opposed to
643
00:35:53,000 --> 00:35:54,320
it.
Right.
644
00:35:54,880 --> 00:35:56,200
OK.
So as far as you know, there's
645
00:35:56,200 --> 00:36:00,400
not necessarily any opposition
to asynchronous payments I.
646
00:36:00,400 --> 00:36:03,200
Don't.
I think this is just a great.
647
00:36:03,360 --> 00:36:04,800
Yeah.
And and it's also a bit of a
648
00:36:04,800 --> 00:36:08,520
harm, harm reduction thing
because people like this ability
649
00:36:08,520 --> 00:36:12,280
to pay to a mobile.
So there are already solutions
650
00:36:12,320 --> 00:36:14,880
out there that will just lock up
all the liquidity.
651
00:36:16,200 --> 00:36:18,040
Yeah, and that's evil.
Lots of problems.
652
00:36:18,040 --> 00:36:20,920
So it's one of those things
where it's might be better to
653
00:36:20,920 --> 00:36:23,080
implement it because the
alternative is worse.
654
00:36:24,000 --> 00:36:26,960
Right, OK.
Does that cover it?
655
00:36:27,200 --> 00:36:28,000
I think so.
You got it.
656
00:36:30,080 --> 00:36:33,280
And if you want to shell.
Where should people find you?
657
00:36:33,320 --> 00:36:35,720
Yeah, that's a good Should
people find you people?
658
00:36:35,720 --> 00:36:38,920
Can find me on Twitter at With
the Jesse.
659
00:36:41,720 --> 00:36:46,960
In that case.
For a choice.
660
00:36:46,960 --> 00:36:48,480
Indeed.
Thank you for listening to
661
00:36:48,480 --> 00:36:49,800
Bitcoin.
Explained.
00:00:18,280 --> 00:00:20,600
Life from interest.
This is Bitcoin.
2
00:00:20,720 --> 00:00:23,920
Explained.
Sure, I have a problem.
3
00:00:24,720 --> 00:00:26,880
I have.
I have bitcoins laying around
4
00:00:26,880 --> 00:00:30,080
everywhere, Bitcoins on
exchanges, bitcoins in hot
5
00:00:30,080 --> 00:00:32,400
wallets, bitcoins in paper
wallets.
6
00:00:32,400 --> 00:00:36,160
Bitcoins in ETFs.
Is there a safe place to store
7
00:00:36,160 --> 00:00:38,920
my Bitcoin shorts?
There might be because we have a
8
00:00:38,920 --> 00:00:41,600
sponsor and they're called coin
kite.
9
00:00:42,640 --> 00:00:46,480
And they produce the cold card.
I heard that's right, a hardware
10
00:00:46,480 --> 00:00:52,200
wallet for your bitcoins.
And it supports PSPT partially
11
00:00:52,200 --> 00:00:54,960
signed Bitcoin transactions.
Great.
12
00:00:55,600 --> 00:01:00,800
OK, short and dear listener.
So we've been getting requests
13
00:01:00,800 --> 00:01:05,840
over the past years basically to
sometimes make more lightning
14
00:01:05,840 --> 00:01:09,360
specific episodes.
Indeed, although we know that
15
00:01:09,600 --> 00:01:12,200
lightning is dead.
Is it?
16
00:01:12,840 --> 00:01:15,440
That's what Twitter says.
What did they say?
17
00:01:15,720 --> 00:01:17,800
Why is it that?
I don't know.
18
00:01:19,480 --> 00:01:21,320
I used it today.
It worked.
19
00:01:21,480 --> 00:01:23,960
It worked for me.
OK.
20
00:01:24,960 --> 00:01:28,400
Good.
So we're making the the request
21
00:01:28,400 --> 00:01:29,960
is to make Lightning specific
episodes.
22
00:01:29,960 --> 00:01:34,600
Sometimes, however short and I
both kind of feel out of our
23
00:01:34,600 --> 00:01:38,960
depth when it comes to at least
more advanced Lightning topics.
24
00:01:39,760 --> 00:01:42,240
We've discussed this in the
episode before where you can
25
00:01:42,240 --> 00:01:45,440
really sort of see that the
development communities of
26
00:01:45,440 --> 00:01:49,120
Bitcoin and Lightning are kind
of starting to separate a bit,
27
00:01:49,120 --> 00:01:52,000
specialized a bit.
There's overlap, obviously, but
28
00:01:52,000 --> 00:01:56,640
there's definitely sort of more
Bitcoin focused, you know,
29
00:01:56,640 --> 00:01:59,840
technological experts and
developers and those that focus
30
00:01:59,840 --> 00:02:03,320
more on lightning.
But we do want to incorporate
31
00:02:03,320 --> 00:02:05,280
more lightning topics in our
episodes.
32
00:02:05,760 --> 00:02:09,240
So we're happy that today we
have a special guest.
33
00:02:10,440 --> 00:02:12,440
Yes, Sir.
Good to be here.
34
00:02:12,480 --> 00:02:13,320
How are you?
Yes, Sir.
35
00:02:14,200 --> 00:02:15,320
Good.
Good.
36
00:02:15,400 --> 00:02:16,160
Now, who are you?
Who?
37
00:02:16,680 --> 00:02:19,880
Am I?
I'm a Lightning developer and I
38
00:02:19,880 --> 00:02:22,440
work for Breeze.
My name is Yessa David.
39
00:02:23,200 --> 00:02:25,000
Jesse the White.
Jesse the Wit.
40
00:02:26,240 --> 00:02:29,680
It's an impossible name to
pronounce in English and.
41
00:02:30,280 --> 00:02:33,080
I just did pronounce it in
English anyways, never mind,
42
00:02:33,440 --> 00:02:37,720
move on.
OK yeah so I I work on Lightning
43
00:02:37,720 --> 00:02:41,680
for Breeze, mostly working on
Lightning service provider stuff
44
00:02:42,080 --> 00:02:46,120
and also Breeze SDK.
And yeah, I'm quite well read
45
00:02:46,120 --> 00:02:48,560
into the Lightning specifics
these days.
46
00:02:48,760 --> 00:02:49,200
Awesome.
Yeah.
47
00:02:49,200 --> 00:02:53,680
So thanks a lot for coming on.
So yeah, we had sort of a list
48
00:02:53,680 --> 00:02:57,000
of lighting topics that that we
wanted to cover at some point.
49
00:02:57,240 --> 00:03:01,320
And earlier this week we read
this list to you and the one
50
00:03:01,320 --> 00:03:04,760
that sort of sprung out for you
to cover is asynchronous
51
00:03:04,760 --> 00:03:06,000
payments.
Exactly.
52
00:03:06,320 --> 00:03:11,320
And the nice thing about that is
you mentioned if we cover
53
00:03:11,320 --> 00:03:14,200
asynchronous payments, then we
sort of at the same time also
54
00:03:14,200 --> 00:03:17,480
tackle two other topics that
were already on our list that we
55
00:03:17,480 --> 00:03:21,440
can sort of all wrap into one
episode basically because it, it
56
00:03:21,440 --> 00:03:23,160
sort of supports each other,
right?
57
00:03:23,640 --> 00:03:25,120
So.
Yes, yeah.
58
00:03:25,120 --> 00:03:28,280
And we will, we'll touch on the
topics later on, I suppose when
59
00:03:28,280 --> 00:03:30,400
we cover async payments.
Yeah.
60
00:03:30,400 --> 00:03:32,880
Well, I'll, I'll spoil this.
So the other two that we're sort
61
00:03:32,880 --> 00:03:37,320
of going to touch on are PTLCS
and trampoline payments are also
62
00:03:37,320 --> 00:03:38,960
going.
To yes, we'll touch on them
63
00:03:39,240 --> 00:03:41,560
briefly.
We'll not go into depth like
64
00:03:41,560 --> 00:03:44,720
exactly how they work, but yeah,
they definitely are necessary
65
00:03:44,720 --> 00:03:47,240
for asynchronous payments.
OK, awesome.
66
00:03:47,680 --> 00:03:52,080
So asynchronous payments, I
guess the first the starting
67
00:03:52,080 --> 00:03:55,680
point is what is it or maybe why
is it needed?
68
00:03:55,680 --> 00:03:58,360
Like what are we talking about?
Yeah, so in the Lightning
69
00:03:58,360 --> 00:04:04,040
network, if Alice is trying to
pay Bob, they both have to be
70
00:04:04,040 --> 00:04:06,520
online at the same time in order
for a lightning payment to
71
00:04:06,520 --> 00:04:09,600
settle.
And the people users are just
72
00:04:09,760 --> 00:04:11,400
not using that these days
anymore, right?
73
00:04:11,400 --> 00:04:15,760
So people use texts and every
communication now happens
74
00:04:15,760 --> 00:04:18,760
asynchronously.
So in Lightning Payments, users
75
00:04:18,760 --> 00:04:21,640
just expect it to work
asynchronously as well.
76
00:04:22,040 --> 00:04:25,040
And in Bitcoin, so you're also
used to payments being
77
00:04:25,040 --> 00:04:26,480
asynchronous, right?
You have an address.
78
00:04:26,480 --> 00:04:28,840
You sent some money to it
whenever you want.
79
00:04:28,920 --> 00:04:31,440
Exactly, Yeah.
So you don't have to be online
80
00:04:31,440 --> 00:04:35,000
at the same time for that.
Yeah, So to give a very concrete
81
00:04:35,000 --> 00:04:37,760
example of something that
happened to me this week and
82
00:04:37,760 --> 00:04:40,440
also allows me one more option
to show my book.
83
00:04:41,120 --> 00:04:42,360
That's all right.
It's yeah.
84
00:04:42,360 --> 00:04:44,960
So someone wanted to buy the
Genesis book from me, like an
85
00:04:44,960 --> 00:04:47,480
autograph version.
And then he emailed me and he
86
00:04:47,480 --> 00:04:50,520
wanted to pay in Lightning and I
said, yeah, sure, that's fine.
87
00:04:50,960 --> 00:04:53,440
And then sent him back.
You know, using the Breeze wall
88
00:04:53,440 --> 00:04:56,680
is actually a Lightning address.
But obviously then I have to
89
00:04:56,680 --> 00:04:59,560
like keep my wallet open and I
don't know for how long because
90
00:04:59,600 --> 00:05:01,960
before it's going to make the
payment.
91
00:05:01,960 --> 00:05:04,600
So that kind of stuff is just
very complicated with Lightning.
92
00:05:04,600 --> 00:05:07,880
So in the end I sent him an on
chain address because that way
93
00:05:08,040 --> 00:05:09,440
you can just send whenever he
wants.
94
00:05:09,920 --> 00:05:15,000
So essentially that is what we,
you lightning developers are
95
00:05:15,000 --> 00:05:19,480
trying to achieve with lightning
as well.
96
00:05:19,480 --> 00:05:23,240
You can send a invoice that can
be paid at any point.
97
00:05:23,240 --> 00:05:24,680
Is that even the right way of
framing?
98
00:05:24,680 --> 00:05:26,600
It yeah.
So maybe you can walk into the
99
00:05:26,600 --> 00:05:30,600
problem that you had first
because well, first of all, your
100
00:05:30,600 --> 00:05:34,200
app has to be running.
It needs CPU time in order to
101
00:05:34,920 --> 00:05:38,000
sign messages for receiving the
lightning payment.
102
00:05:38,600 --> 00:05:40,480
And it needs to receive data,
right?
103
00:05:40,720 --> 00:05:43,800
Yeah, it needs to receive data
and it needs to sign messages.
104
00:05:44,000 --> 00:05:45,640
Exactly.
So.
105
00:05:46,480 --> 00:05:48,920
So if you're not online, well,
you won't be able to do that.
106
00:05:49,000 --> 00:05:50,880
And so you won't be able to
receive the payment.
107
00:05:51,280 --> 00:05:57,200
But if you, if Bob, if let's say
Alice is trying to send a
108
00:05:57,200 --> 00:06:02,000
payment and she's sending it to
you, then Alice is going to find
109
00:06:02,000 --> 00:06:03,400
a route over the Lightning
network.
110
00:06:03,600 --> 00:06:08,240
And a naive thing you would what
could try to do is just the last
111
00:06:08,240 --> 00:06:11,160
hop which is for you was the
Breeze LSB.
112
00:06:11,360 --> 00:06:14,240
Breeze Lightning service
provider, which is the node that
113
00:06:14,240 --> 00:06:19,800
you are connected to, could hold
the payment until you come
114
00:06:19,800 --> 00:06:22,680
online and then forward the
payment to you.
115
00:06:24,040 --> 00:06:27,400
There will be a naive approach
in trying to solve that Alice,
116
00:06:27,800 --> 00:06:30,000
and you don't have to be online
at the same time.
117
00:06:30,440 --> 00:06:33,520
And it's naive, I would assume,
because in that case Breeze can
118
00:06:33,560 --> 00:06:35,840
steal my money.
No, they definitely can steal
119
00:06:35,840 --> 00:06:38,240
your money.
But the problem is we're locking
120
00:06:38,240 --> 00:06:41,720
liquidity in the network right
now if we do this.
121
00:06:42,280 --> 00:06:47,320
So because Alice is Alice's
repayment, maybe we can explain
122
00:06:47,320 --> 00:06:49,680
a little bit what a lightning
payment is first.
123
00:06:50,120 --> 00:06:53,760
So first you allocate, you find
a route through the network.
124
00:06:54,000 --> 00:06:59,880
So you go, yeah, you you find a
path over different nodes, over
125
00:06:59,880 --> 00:07:03,600
different channels and then
you're when sending a payment,
126
00:07:03,800 --> 00:07:06,520
first you're going to allocate
liquidity in each of these
127
00:07:06,520 --> 00:07:14,840
channels that will be that's
sort of locked until you get the
128
00:07:14,840 --> 00:07:19,080
pre image back that comes from
from you when whenever you
129
00:07:19,080 --> 00:07:22,440
settle the payment pre image
comes back to Alice and only
130
00:07:22,440 --> 00:07:24,800
then are the funds released.
Yeah.
131
00:07:24,800 --> 00:07:27,760
So I guess another way to
describe is there's, there's a
132
00:07:27,760 --> 00:07:30,080
secret at the end of the tunnel
essentially right there.
133
00:07:30,080 --> 00:07:33,400
So that the payee, no the, yeah,
the payee, the person receiving
134
00:07:33,400 --> 00:07:39,400
the payment has a secret and the
person making the payment has to
135
00:07:40,240 --> 00:07:43,480
allocate liquidity and then like
every hop does the same thing
136
00:07:43,600 --> 00:07:47,080
and then the last hop gets the
secret and then sends it back to
137
00:07:47,080 --> 00:07:49,440
the payer.
So there there's information
138
00:07:49,440 --> 00:07:52,600
that goes towards the from the
from the sender to the
139
00:07:52,600 --> 00:07:54,320
recipient, and then there's
information that has to go back
140
00:07:54,320 --> 00:07:56,320
from the recipient to the
sender.
141
00:07:56,800 --> 00:07:59,800
And as long as that information
has not made the full return
142
00:07:59,800 --> 00:08:03,320
trip, the liquidity is locked up
all over the channel.
143
00:08:03,560 --> 00:08:05,160
Yeah.
So all over the network the
144
00:08:06,040 --> 00:08:09,640
liquidity will be locked and
well that's that's something we
145
00:08:09,640 --> 00:08:12,720
don't want into Lighting network
was usually when a payment is is
146
00:08:12,720 --> 00:08:15,760
happy with in a happy flow,
these payments settle within a
147
00:08:15,760 --> 00:08:19,840
second, right.
But if you just turn your phone
148
00:08:19,840 --> 00:08:23,160
off for a day, then liquidity is
suddenly locked for for an
149
00:08:23,160 --> 00:08:26,000
entire day.
Why is this a problem?
150
00:08:26,680 --> 00:08:29,520
Yeah, it's a problem because of
that feature that I just
151
00:08:29,520 --> 00:08:32,559
described.
Yeah, you would expect the
152
00:08:32,760 --> 00:08:36,200
liquidity to settle very quickly
over the Lightning Network.
153
00:08:36,440 --> 00:08:41,080
So if you lock this liquidity
for a long time, you're locking
154
00:08:41,080 --> 00:08:44,640
it in multiple channels as well.
So the amount of your payment is
155
00:08:44,640 --> 00:08:49,840
locked over multiple channels,
so you exponentially degrade the
156
00:08:50,640 --> 00:08:53,520
the ability of the lightning
network to be able to forward
157
00:08:53,520 --> 00:08:55,640
payments this way it.
Basically means you need bigger
158
00:08:55,640 --> 00:08:59,040
channels, right?
Because if you're only using
159
00:08:59,040 --> 00:09:02,800
channels one second at a time,
then maybe a one Bitcoin channel
160
00:09:02,800 --> 00:09:06,000
is enough.
But if the you know, if that one
161
00:09:06,000 --> 00:09:08,960
Bitcoin is just locked up for
two weeks, then you need a much
162
00:09:08,960 --> 00:09:11,000
bigger channel.
OK, and just for my
163
00:09:11,000 --> 00:09:14,520
understanding, is this the only
problem we're trying to solve
164
00:09:14,520 --> 00:09:17,760
like is let's say we would all
use bigger channels, would that
165
00:09:17,760 --> 00:09:20,120
just sort of also solve the
problem in that sense?
166
00:09:20,480 --> 00:09:22,360
No, no.
If if people start sending more
167
00:09:22,360 --> 00:09:25,800
payments, then bigger channels
are no longer an option anymore
168
00:09:26,480 --> 00:09:29,400
or don't no longer work.
Yeah, OK.
169
00:09:29,400 --> 00:09:33,360
And is this is this the problem
we're trying to solve, or is
170
00:09:33,360 --> 00:09:35,720
there are other problems
involved as well?
171
00:09:36,240 --> 00:09:38,680
Yeah.
So the main, so there's two
172
00:09:38,800 --> 00:09:40,720
aspects of this.
There's one of them is that we
173
00:09:40,720 --> 00:09:43,320
don't want to look lock this
liquidity in the network while
174
00:09:43,320 --> 00:09:47,920
the payment is in flight.
And the other one is also has to
175
00:09:47,920 --> 00:09:53,120
do with the invoice generation.
So because Alice and Bob
176
00:09:53,960 --> 00:09:56,800
presumably are not online at the
same time, they won't maybe
177
00:09:56,800 --> 00:10:01,120
won't exchange an invoice.
So Alice needs a way to
178
00:10:01,120 --> 00:10:04,880
statically create an invoice.
Because an example of your book,
179
00:10:04,880 --> 00:10:08,720
you created an invoice, but only
once you saw the e-mail.
180
00:10:09,280 --> 00:10:12,240
So yeah, whoever wanted to buy
the book had to wait for you to
181
00:10:12,240 --> 00:10:14,760
do that.
And it'd be better if the person
182
00:10:14,760 --> 00:10:16,920
who wants to buy the book does
not have to wait for you to make
183
00:10:16,920 --> 00:10:19,120
an invoice.
But then the problem is that
184
00:10:19,240 --> 00:10:24,160
standard lightning invoices, the
Bolt 11 format, you can pay them
185
00:10:24,160 --> 00:10:26,920
once, right?
So, So you can make an invoice
186
00:10:26,920 --> 00:10:29,280
and say, well, whoever is the
first person to buy my book, pay
187
00:10:29,280 --> 00:10:31,960
this invoice.
But now if you want to scale
188
00:10:31,960 --> 00:10:33,640
that and you want to sell
multiple books, well you'd
189
00:10:33,640 --> 00:10:36,440
probably have to make multiple
invoices and put them on your
190
00:10:36,440 --> 00:10:39,720
website and tell people to pick
which one.
191
00:10:39,720 --> 00:10:42,360
I don't know.
OK, so let's cover that problem
192
00:10:42,360 --> 00:10:44,800
first.
I I need a way to sort of
193
00:10:44,800 --> 00:10:47,920
automatically generate invoices
even though my phone is switched
194
00:10:47,960 --> 00:10:49,160
off I guess.
Right.
195
00:10:50,000 --> 00:10:52,600
Yeah.
So yeah, so if you would
196
00:10:52,720 --> 00:10:55,840
currently create a BOLT 11
invoice, which is the invoice
197
00:10:55,840 --> 00:10:57,480
format we use on a lighting
network today.
198
00:10:59,000 --> 00:11:02,400
If you get that invoice paid,
then you release the the pre
199
00:11:02,400 --> 00:11:06,920
image which is your secret,
which is the payment secret and
200
00:11:08,480 --> 00:11:10,960
so nobody else will be able to
pay that again because an
201
00:11:10,960 --> 00:11:15,400
intermediate node would be able
to intercept your payment and
202
00:11:15,400 --> 00:11:18,360
settle the payment without the
payment ever arriving to you
203
00:11:18,360 --> 00:11:19,960
because he already knows the
secret.
204
00:11:20,320 --> 00:11:23,440
Yeah, the secrets can only be
used once for a for a one
205
00:11:23,440 --> 00:11:26,040
payment flow essentially.
Yeah, so the secret can only be
206
00:11:26,040 --> 00:11:28,320
used once, which means the
invoice can only be used.
207
00:11:28,320 --> 00:11:32,480
And this is a secret that I'm
generating on my Breeze Bullet
208
00:11:32,480 --> 00:11:34,000
app.
Basically a random number.
209
00:11:34,320 --> 00:11:38,440
Yeah yeah, so.
So first we need to tackle that
210
00:11:38,440 --> 00:11:41,720
and the the best way to do that
is to create an actually a
211
00:11:41,760 --> 00:11:44,360
static invoice which would be
reusable.
212
00:11:45,800 --> 00:11:48,120
So you could just post that on
your website.
213
00:11:48,120 --> 00:11:52,640
Say well a book costs this and
this cost money and senders
214
00:11:52,640 --> 00:11:56,200
would be able to pay to this
invoice an infinite amount of
215
00:11:56,200 --> 00:12:00,240
times.
And for that we we need a
216
00:12:00,240 --> 00:12:03,000
different model.
And this different model works
217
00:12:03,000 --> 00:12:05,840
with PTLCS.
So currently the way we
218
00:12:05,840 --> 00:12:11,480
described, you've got a secret,
and this secret is hashed into
219
00:12:11,480 --> 00:12:16,840
the invoice, which and then and
then HCLCS are sent over the
220
00:12:16,840 --> 00:12:18,640
lightning network.
I think you've covered this in
221
00:12:18,640 --> 00:12:21,520
Lightning episodes.
We've previously tried to
222
00:12:21,520 --> 00:12:25,960
explain what we generally also
explain what hashes are.
223
00:12:27,440 --> 00:12:30,480
So we definitely had like a
basic Lightner lightning
224
00:12:30,480 --> 00:12:32,920
explainer episode at one point,
and I'm sure we must have
225
00:12:32,920 --> 00:12:34,960
covered this.
Yeah, It's a couple of years
226
00:12:34,960 --> 00:12:37,520
ago, so I don't remember
exactly, but presumably yes.
227
00:12:37,840 --> 00:12:39,520
But the hash, it's the hash of
the secret.
228
00:12:39,760 --> 00:12:41,440
That's what you're sending to
the other side.
229
00:12:41,440 --> 00:12:43,440
And the other side says, if,
please give me the secret that
230
00:12:43,440 --> 00:12:45,680
belongs to this hash.
And that's really the message
231
00:12:45,680 --> 00:12:47,520
you're forwarding along all
these channels.
232
00:12:49,160 --> 00:12:50,840
Right.
So that's called an HTLC.
233
00:12:50,840 --> 00:12:54,080
So what is a PTLC?
Yeah, and it's basically sort of
234
00:12:54,080 --> 00:12:58,560
the same construct, only instead
of having a pre image and a
235
00:12:58,560 --> 00:13:02,960
hash, you have a private key and
a public key which is called a
236
00:13:02,960 --> 00:13:05,840
payment point.
And that's why it's called a
237
00:13:05,840 --> 00:13:08,640
point time lock contract.
So it's not a hash time lock
238
00:13:08,640 --> 00:13:10,440
contract, but a point time lock
contract.
239
00:13:11,240 --> 00:13:15,640
And the trick with these public
keys is you can tweak them,
240
00:13:17,120 --> 00:13:20,840
which make them so, and you can
basically derive as much keys as
241
00:13:20,840 --> 00:13:25,280
you want from a single public
key which make them yeah, you
242
00:13:25,280 --> 00:13:28,080
can make an infinite amount of
secrets from.
243
00:13:28,400 --> 00:13:31,200
Yeah, one of our very first
episodes talked about taproot
244
00:13:31,280 --> 00:13:34,480
and why taproot is so cool.
And one of the aspects of it
245
00:13:34,480 --> 00:13:38,840
said it's very easy to add add a
number to a private key and then
246
00:13:38,840 --> 00:13:43,600
add essentially the same number
to the public key and then well.
247
00:13:43,600 --> 00:13:45,160
That's snore, basically, right?
But yeah.
248
00:13:45,160 --> 00:13:48,280
Yes, and that's that's already
possible with ECDH, but it's
249
00:13:48,280 --> 00:13:50,720
just much, much easier with
Schnorr.
250
00:13:51,280 --> 00:13:54,880
And this PTLC construct makes
use of that, right?
251
00:13:54,880 --> 00:13:59,840
But the ability to add some
random number to A to a private
252
00:13:59,840 --> 00:14:02,240
key, and the other side can do
that to the public key.
253
00:14:02,600 --> 00:14:04,320
So even if you don't have the
public key, you know how to
254
00:14:04,320 --> 00:14:05,840
tweak it.
And you cannot do that with
255
00:14:05,840 --> 00:14:09,240
hashes, because if it hashes, if
you take the number, if you take
256
00:14:09,240 --> 00:14:12,360
the letter A for example, and
you hash it, you get some large
257
00:14:12,360 --> 00:14:14,360
number.
Then if you say, oh, I'm just
258
00:14:14,360 --> 00:14:17,920
going to change A to B, well the
other side has no idea, Like you
259
00:14:17,920 --> 00:14:20,560
cannot just take the hash of A
and then take the hash of B and
260
00:14:20,560 --> 00:14:22,040
add them together.
That's not going to give you the
261
00:14:22,040 --> 00:14:25,320
same result.
Yeah, Yeah.
262
00:14:25,320 --> 00:14:28,800
So and so it is.
It does work with with points,
263
00:14:28,800 --> 00:14:31,880
what with payment points.
And So what a sender can do is
264
00:14:31,960 --> 00:14:36,040
is going to, for each
intermediate hub, generate a
265
00:14:36,040 --> 00:14:38,920
different secret basically.
So each intermediate hub is
266
00:14:38,920 --> 00:14:44,600
going to think that the that
it's a different secret than the
267
00:14:44,600 --> 00:14:47,360
1 the recipient actually
created, and so each
268
00:14:47,360 --> 00:14:54,040
intermediate hub won't ever
learn the actual secret from the
269
00:14:54,040 --> 00:14:56,480
PE.
But how does how does that work
270
00:14:56,480 --> 00:14:59,320
if you're making two payments to
the same route?
271
00:15:00,000 --> 00:15:01,960
Because what's what?
What is it that makes a second
272
00:15:02,000 --> 00:15:03,400
payment different from the first
payment?
273
00:15:04,160 --> 00:15:08,920
So the trick is that Alice,
which is the sender, she
274
00:15:09,560 --> 00:15:13,280
generates a random number as
well, which tweaks tweaks the
275
00:15:14,000 --> 00:15:19,800
the public key and the
intermediate notes they use.
276
00:15:19,800 --> 00:15:25,800
This tweaks public key as as the
the for the in order to in order
277
00:15:25,800 --> 00:15:28,880
to learn the secret basically.
Yeah, so it's never the same
278
00:15:28,880 --> 00:15:30,680
secret.
It's never the same secret, and
279
00:15:30,680 --> 00:15:32,960
not for any intermediate hub as
well, yeah.
280
00:15:33,600 --> 00:15:36,320
So even if two different people
make a payment, they both the
281
00:15:36,440 --> 00:15:39,360
the sender picks the random
number, so the recipient doesn't
282
00:15:39,360 --> 00:15:41,840
have to do anything.
As long as each sender picks a
283
00:15:41,840 --> 00:15:44,080
random number, they cannot reuse
the same secret.
284
00:15:44,760 --> 00:15:47,760
Yeah, and it's in the best
interest of the sender to pick a
285
00:15:47,800 --> 00:15:51,760
random number then, because it's
his payment that will be stolen
286
00:15:51,800 --> 00:15:57,280
otherwise.
OK, so in this case, you know
287
00:15:57,280 --> 00:16:00,560
I'm trying to sell the Genesis
book to someone, so I got to
288
00:16:00,880 --> 00:16:04,280
generate an invoice.
Who's generating?
289
00:16:04,760 --> 00:16:07,760
Why does this generation happen?
What happens exactly?
290
00:16:07,760 --> 00:16:11,800
Yeah, so you create an invoice
and it's got a payment point
291
00:16:11,800 --> 00:16:14,720
inside inside of your invoice,
and you just put that up on your
292
00:16:14,720 --> 00:16:17,400
website.
I'm a sender, I scan your
293
00:16:17,400 --> 00:16:22,120
invoice and I'm going to tweak
your payment points with random
294
00:16:22,120 --> 00:16:25,760
numbers right along the route,
right?
295
00:16:25,760 --> 00:16:28,480
So nobody learns about the
actual secret when the secret
296
00:16:28,480 --> 00:16:30,880
comes back to to the sender,
right?
297
00:16:31,200 --> 00:16:33,560
OK, got it.
That that part makes sense to
298
00:16:33,560 --> 00:16:35,360
me.
So that removes the
299
00:16:35,360 --> 00:16:38,240
interactivity from you having to
make an invoice.
300
00:16:38,480 --> 00:16:41,560
But in this scenario, you're
still online because you are
301
00:16:41,560 --> 00:16:45,760
clearly perceiving the payment
and sending back to secret every
302
00:16:45,760 --> 00:16:47,200
time somebody makes a payment.
Yeah.
303
00:16:47,200 --> 00:16:50,120
So that was the second part of
the problem I think we're trying
304
00:16:50,120 --> 00:16:53,120
to solve right now.
My phone is, you know, I emailed
305
00:16:53,360 --> 00:16:55,680
this guy back or whatever.
My phone is switched off and now
306
00:16:55,680 --> 00:16:59,080
I still need to receive the
payment without locking these
307
00:16:59,080 --> 00:17:02,120
funds along all these channels.
Because that's, yeah, so.
308
00:17:02,120 --> 00:17:04,160
Your friend has downloaded the
invoice from your website
309
00:17:04,160 --> 00:17:05,680
instead of having to send you an
e-mail.
310
00:17:06,359 --> 00:17:09,599
But in this so far we've we've
still reached the point where,
311
00:17:09,599 --> 00:17:12,000
OK, they don't have to e-mail
you anymore, they just make the
312
00:17:12,000 --> 00:17:13,480
payment.
But your wallet still needs to
313
00:17:13,480 --> 00:17:14,640
be online to receive the
payment.
314
00:17:14,720 --> 00:17:16,960
Yes.
OK, so how do we solve this
315
00:17:16,960 --> 00:17:17,640
problem?
Yes, Sir.
316
00:17:17,720 --> 00:17:20,480
OK, let's go over how async
payments works then.
317
00:17:21,240 --> 00:17:27,560
So Alice is going to pay Bob and
Alice is going to be connected
318
00:17:27,560 --> 00:17:31,920
to the Lightning network through
a Lightning Service Provider and
319
00:17:31,920 --> 00:17:34,520
Bob is going to be connected to
the lightning network through a
320
00:17:34,520 --> 00:17:38,320
a lightning service provider.
Where alert Lightning service
321
00:17:38,320 --> 00:17:43,320
provider is basically just a
node that that you're connected
322
00:17:43,320 --> 00:17:47,840
to to the lightning network and
this node is well connected to
323
00:17:47,840 --> 00:17:50,120
the lightning network.
Yeah so the concrete example
324
00:17:50,120 --> 00:17:52,600
here would be for example breeze
I think right?
325
00:17:52,600 --> 00:17:56,560
Like my wallet is not a full
node, it just connects to
326
00:17:57,080 --> 00:17:58,800
breezes full nodes.
Yeah.
327
00:17:59,080 --> 00:18:04,080
And and Breeze's full node is
tolerant of you being offline a
328
00:18:04,080 --> 00:18:07,200
lot, which is why we call this a
Lightning service provider.
329
00:18:07,200 --> 00:18:09,680
But it could basically be any
node that's tolerant to that.
330
00:18:11,840 --> 00:18:18,840
And what Alice is going to do is
going to is going to send the
331
00:18:18,840 --> 00:18:26,200
payment to Bob, but it's going
to tell her LSP, please hold
332
00:18:26,200 --> 00:18:30,720
this payment until you receive a
message that you can release it.
333
00:18:30,920 --> 00:18:33,960
That she's telling her own LSP.
That she's telling her own LSP
334
00:18:33,960 --> 00:18:37,880
that and the reason she doesn't.
Otherwise, it's a regular
335
00:18:37,880 --> 00:18:40,920
lighting payment with a PTLC,
then it's a regular.
336
00:18:40,920 --> 00:18:44,000
It's normal, she just says to
her own service provider.
337
00:18:44,000 --> 00:18:46,240
Don't send this yet.
Yeah, exactly.
338
00:18:46,240 --> 00:18:47,760
Yeah.
And this message is inside the
339
00:18:47,760 --> 00:18:51,960
payment itself, but so basically
it's a regular Lighting payment.
340
00:18:52,560 --> 00:18:55,880
And so at this point the Alice's
LSP cannot steal the money,
341
00:18:55,880 --> 00:18:57,200
right?
It's not that she's making a
342
00:18:57,200 --> 00:19:01,640
payment to her LSP, she is doing
the first step of the payment,
343
00:19:01,840 --> 00:19:05,120
which is giving the pre image.
No, not the payment, It's giving
344
00:19:05,120 --> 00:19:11,040
the the point, the basically the
the public thing of the secret
345
00:19:11,680 --> 00:19:16,080
to her payment provider who
cannot take the money unless
346
00:19:16,400 --> 00:19:18,600
they get the secret.
And in order to get the secret
347
00:19:18,600 --> 00:19:21,040
they have to forward it.
But all Alice is doing is
348
00:19:21,040 --> 00:19:24,240
saying, oh wait a minute, don't
forward it just yet because Bob
349
00:19:24,240 --> 00:19:26,000
might not be online.
Exactly.
350
00:19:26,000 --> 00:19:28,040
Yeah.
So we know the reason why she
351
00:19:28,120 --> 00:19:33,200
why the LSP is not forwarding,
forwarding it, and what Alice is
352
00:19:33,200 --> 00:19:36,600
going to do as well.
She's going to send an onion
353
00:19:36,600 --> 00:19:41,640
message to Bob saying, hey,
there's a pending payment here.
354
00:19:42,560 --> 00:19:47,360
If you want to release that
whenever you're online, send a
355
00:19:47,360 --> 00:19:49,360
message back along this path
over here.
356
00:19:49,360 --> 00:19:52,360
And there's an encrypted path
inside this message as well.
357
00:19:52,600 --> 00:19:55,040
When you say onion message, what
do you mean by that?
358
00:19:55,280 --> 00:19:59,440
An onion message is so over the
lighting network we route
359
00:19:59,440 --> 00:20:03,640
payments over onions as well,
basically meaning that every hop
360
00:20:05,320 --> 00:20:09,760
where this message is routed
over is encrypted, so it sort of
361
00:20:09,760 --> 00:20:13,640
gets becomes an onion of
encryption where onions have
362
00:20:13,640 --> 00:20:16,400
layers.
So every every point in a route
363
00:20:16,640 --> 00:20:20,520
can only see which point is
coming next, or which node is
364
00:20:20,520 --> 00:20:23,240
coming next and which node came
before it, but cannot see
365
00:20:23,240 --> 00:20:27,400
further in either direction,
which we claimed a bit in our
366
00:20:27,400 --> 00:20:30,600
episode about Bold 12.
Yeah, and you can basically send
367
00:20:30,640 --> 00:20:34,040
arbitrary messages over this
construction over the liking
368
00:20:34,040 --> 00:20:38,200
network then, right?
And she's going to send this to
369
00:20:38,200 --> 00:20:41,240
Bob and with a reply path then
to her LSP.
370
00:20:42,760 --> 00:20:46,160
So Bob will be able to unlock
the the payment.
371
00:20:46,160 --> 00:20:49,320
So it's it actually becomes
forwarded, but Bob is offline of
372
00:20:49,320 --> 00:20:52,920
course.
So the LSP is of Bob will hold
373
00:20:52,920 --> 00:20:56,960
this on your message until Bob
is online, right, Because the
374
00:20:56,960 --> 00:20:59,960
LSP knows well I have to forward
this to Bob, Bob is not there.
375
00:21:00,320 --> 00:21:02,320
So I'm just going to wait until
Bob is online.
376
00:21:02,440 --> 00:21:04,840
Right and.
The LSP cannot read what is in
377
00:21:04,840 --> 00:21:07,080
the message, just knows like I
have a message for Bob.
378
00:21:07,080 --> 00:21:09,600
I don't know where it came from,
but I'll give it to Bob when Bob
379
00:21:09,600 --> 00:21:11,080
is online.
Yeah.
380
00:21:11,080 --> 00:21:13,720
And in this case, it's obviously
not a problem because no funds
381
00:21:13,720 --> 00:21:15,440
are being locked up.
It's just a message.
382
00:21:15,640 --> 00:21:18,600
Yeah, yeah.
OK, so that's the onion message
383
00:21:18,600 --> 00:21:22,760
goes first to Bob's service
provider and he will forward
384
00:21:22,760 --> 00:21:24,360
that to Bob or Bob's going
online.
385
00:21:24,360 --> 00:21:25,920
Bob.
Bob comes online, turns his
386
00:21:25,920 --> 00:21:29,520
photos on or as you know, Breeze
app or whatever Lightning app he
387
00:21:29,560 --> 00:21:32,040
has sees this message, or
probably as well.
388
00:21:32,040 --> 00:21:33,880
It just responds to the message
I would assume.
389
00:21:33,960 --> 00:21:35,840
Yeah, yeah, yeah.
He doesn't have to actually see
390
00:21:35,840 --> 00:21:36,880
it.
Yeah, it just all goes
391
00:21:36,880 --> 00:21:39,400
automatic.
But we will say that he that his
392
00:21:39,400 --> 00:21:42,400
wallet sees the message and then
he's going to reply over the
393
00:21:42,400 --> 00:21:44,520
reply path.
So he doesn't really know where
394
00:21:44,520 --> 00:21:46,240
the where the message is coming
from.
395
00:21:46,560 --> 00:21:49,040
He just knows that he has to
send an onion message there in
396
00:21:49,040 --> 00:21:54,920
order to unlock it and then.
So Alice's LSP, who is still
397
00:21:54,920 --> 00:22:01,440
holding that payment right now?
By the way, Alice, after she
398
00:22:01,440 --> 00:22:05,160
sent the onion lessons to Bob,
was able to go offline, right?
399
00:22:05,160 --> 00:22:07,320
She could put her phone back in
her pocket.
400
00:22:07,320 --> 00:22:09,960
So important part that they
don't have to be online at the
401
00:22:09,960 --> 00:22:15,880
same time, yeah.
Because Alice's LSP now has the
402
00:22:15,880 --> 00:22:18,000
money, in a way.
Yeah, has the money in a way.
403
00:22:18,560 --> 00:22:22,440
And now, so we're now at the
point where Alice's LSP received
404
00:22:22,440 --> 00:22:25,360
the onion message from Bob
saying please forward this
405
00:22:25,360 --> 00:22:27,800
payment.
Then the LSP forwards the
406
00:22:27,800 --> 00:22:31,440
payment to Bob, and Bob is
online now, so he's able to
407
00:22:32,200 --> 00:22:36,120
settle the payment.
So he's going to release the pre
408
00:22:36,120 --> 00:22:41,840
image and the pre image goes
back all the way to to Alice's
409
00:22:41,840 --> 00:22:46,360
LSP.
And Alice's LSP, whenever Alice
410
00:22:46,360 --> 00:22:50,200
comes online, is able to settle
the last piece between her and
411
00:22:50,200 --> 00:22:53,920
Alice, because only her channel
with Alice is now still in a
412
00:22:53,920 --> 00:22:56,960
state where funds are in limbo.
Right.
413
00:22:57,000 --> 00:22:58,520
Yeah.
So the, I guess the only player
414
00:22:58,520 --> 00:23:02,160
in this story that needs to hold
funds in, in limbo in a channel
415
00:23:02,160 --> 00:23:05,720
longer than you'd normally want
to do is the channel between
416
00:23:05,720 --> 00:23:08,160
Alice and her lightning service
provider.
417
00:23:08,160 --> 00:23:11,200
So obviously the Lightning
service provider will want to be
418
00:23:11,200 --> 00:23:15,600
compensated for that in a way.
But if Alice is a mobile node,
419
00:23:15,600 --> 00:23:18,760
then that money is probably
going to be stuck kind of stuck
420
00:23:18,760 --> 00:23:21,280
anyway, because if she's not
online, they can route through
421
00:23:21,280 --> 00:23:24,000
it and she probably doesn't have
any other channels.
422
00:23:24,000 --> 00:23:26,080
So yeah, it's not a routing node
anyway.
423
00:23:26,160 --> 00:23:30,600
And LSP will already allocate
liquidity towards these users.
424
00:23:31,920 --> 00:23:35,000
So I don't think there will be
any specific compensation for
425
00:23:35,000 --> 00:23:37,760
this, just probably for the fact
of being a liking service
426
00:23:37,760 --> 00:23:39,440
provider and allocating
liquidity.
427
00:23:39,880 --> 00:23:41,600
Maybe you'll pay something for
that, yeah?
428
00:23:42,600 --> 00:23:45,680
We promised, or I promised that
we would also cover trampling
429
00:23:45,680 --> 00:23:46,440
payments.
Where?
430
00:23:46,440 --> 00:23:48,720
Where does this come in?
So there's this in.
431
00:23:48,720 --> 00:23:51,200
In some situations it would just
work this way, right?
432
00:23:51,520 --> 00:23:54,520
In some situations it would just
work, but there is actually a
433
00:23:54,520 --> 00:23:59,240
problem because if Alice finds a
route for this payment over the
434
00:23:59,240 --> 00:24:03,920
lighting network to Bob, usually
in Lightning what happens is you
435
00:24:03,920 --> 00:24:07,400
find a route, you try the route
and then somewhere along the
436
00:24:07,400 --> 00:24:11,480
route either notice offline or
doesn't have enough liquidity or
437
00:24:12,520 --> 00:24:15,320
and this route fails and what
you know is going to do is going
438
00:24:15,320 --> 00:24:17,840
to find another route.
And this is also, by the way,
439
00:24:17,840 --> 00:24:21,080
where I'd like to shield the
episode with Renee Picard we did
440
00:24:21,080 --> 00:24:28,440
a few years ago explaining sort
of his his pathfinding, optimal
441
00:24:28,800 --> 00:24:31,240
way of making payments.
But it also involves lots of
442
00:24:31,240 --> 00:24:35,000
attempts.
Yeah, quite quite a few attempts
443
00:24:35,000 --> 00:24:38,040
to get a payment through.
It's by designed as some privacy
444
00:24:38,040 --> 00:24:41,200
in the Lightning protocol.
So you don't know exactly how
445
00:24:41,200 --> 00:24:43,560
much room there is in all the
channels along the route.
446
00:24:44,640 --> 00:24:48,240
You you know how big the channel
is, but you don't know where the
447
00:24:48,240 --> 00:24:50,040
money is in that Channel, so you
don't know how much you can
448
00:24:50,040 --> 00:24:52,640
actually send through it.
And this changes every time as
449
00:24:52,640 --> 00:24:55,480
well.
Yeah, that was, that was a short
450
00:24:55,480 --> 00:24:57,440
special, I believe, right?
Yes.
451
00:24:58,560 --> 00:25:00,440
But you don't know the episode,
I'm sure, no.
452
00:25:00,640 --> 00:25:01,920
OK.
OK.
453
00:25:01,960 --> 00:25:05,040
Yes, Sir.
Yeah, so Alice, if she created
454
00:25:05,040 --> 00:25:08,360
this first route and this route
fails, that would mean that she
455
00:25:08,360 --> 00:25:10,840
would only retry whenever she
comes back online again.
456
00:25:10,840 --> 00:25:14,360
You don't know when that is.
So what Alice can do is she can
457
00:25:14,520 --> 00:25:18,160
delegate the path finding to
another node.
458
00:25:19,520 --> 00:25:22,720
And this is a feature in the
Lightning Network that's being
459
00:25:22,720 --> 00:25:26,560
implemented in in several Node
implementations.
460
00:25:27,200 --> 00:25:30,240
Asank already uses it and it's
called Trampoline Payments.
461
00:25:31,120 --> 00:25:36,000
So basically Alice is going to
ask her LSB please, I want to
462
00:25:36,280 --> 00:25:39,840
forward this payment to this
direction please.
463
00:25:39,840 --> 00:25:42,120
Do you find the best path over
the light network?
464
00:25:42,120 --> 00:25:44,920
And I'm I'm just going to chill
and go offline now.
465
00:25:45,360 --> 00:25:46,960
Yeah.
And and so this works by
466
00:25:46,960 --> 00:25:49,840
providing A carte blanche in
terms of fees, right?
467
00:25:49,840 --> 00:25:52,560
Because normally when you
establish the route, you know
468
00:25:52,560 --> 00:25:54,920
exactly how much fees you need
to pay at every hop.
469
00:25:54,920 --> 00:25:57,280
But because you're not
establishing the route, you're
470
00:25:57,280 --> 00:26:00,680
just going to say, well, here's
a hundred sets, you figure it
471
00:26:00,680 --> 00:26:03,200
out and if you find a cheaper
route, you get the you keep the
472
00:26:03,200 --> 00:26:04,680
change.
Exactly.
473
00:26:04,720 --> 00:26:05,440
Yeah.
Yeah.
474
00:26:05,440 --> 00:26:08,840
So you give them some kind of
margin and this could be a
475
00:26:08,840 --> 00:26:12,920
competition for trampoline notes
as well to say, well, I'm the
476
00:26:12,920 --> 00:26:15,760
cheapest because I know how to
find the best routes in the
477
00:26:15,760 --> 00:26:17,800
network.
Exactly like the like the London
478
00:26:17,800 --> 00:26:21,160
taxi drivers that have the
knowledge and they they can find
479
00:26:21,160 --> 00:26:24,120
the shortest route through
London without AGPS and they
480
00:26:24,120 --> 00:26:26,720
usually are actually faster than
the Uber drivers that just
481
00:26:26,920 --> 00:26:29,160
follow Google Maps, according to
legend.
482
00:26:31,680 --> 00:26:35,560
And now, so Alice's Alice.
Alice's Alice B is now able to
483
00:26:36,000 --> 00:26:40,160
retry this payment, so whenever
it fails, and so would be able
484
00:26:40,160 --> 00:26:44,200
to reach Bob, hopefully in a
timely manner, before Bob goes
485
00:26:44,200 --> 00:26:46,320
offline again.
And so this ingredient is
486
00:26:46,320 --> 00:26:48,040
useful.
Like we said, because the
487
00:26:48,040 --> 00:26:49,840
Lightning network changes all
the time, you need to do
488
00:26:49,840 --> 00:26:56,120
multiple attempts and so this
trample line router, this can
489
00:26:56,120 --> 00:26:58,720
just try it multiple times
basically, yeah.
490
00:26:58,720 --> 00:27:02,000
The downside, of course, is
privacy, because the trampoline
491
00:27:02,000 --> 00:27:03,520
now knows where the payment is
going.
492
00:27:04,440 --> 00:27:08,520
Yes.
So the first part of this is Bob
493
00:27:09,320 --> 00:27:12,960
in his invoice could have
created a blinded path.
494
00:27:14,680 --> 00:27:17,520
So that's one part of this where
you would not actually, where
495
00:27:17,520 --> 00:27:20,800
the intermediate node would not
actually find the destination,
496
00:27:20,800 --> 00:27:22,040
right?
The trampoline node would not
497
00:27:22,040 --> 00:27:27,640
find the destination, and
another way to deal with this is
498
00:27:27,640 --> 00:27:32,760
to select multiple trampoline
hops in your route.
499
00:27:32,760 --> 00:27:36,440
So we're now using one
trampoline node.
500
00:27:37,400 --> 00:27:40,160
So Alice's LSP is going to find
different routes.
501
00:27:40,440 --> 00:27:44,960
But you could tell Alice's LSP.
So first find a route to this
502
00:27:44,960 --> 00:27:47,760
random trampoline node, then
find a route, and then that
503
00:27:47,760 --> 00:27:50,800
trampoline node has to find a
route to that random trampoline
504
00:27:50,800 --> 00:27:53,320
node.
So you could, if you value your
505
00:27:53,320 --> 00:27:58,320
privacy, you could diffuse the
path finding a little bit that
506
00:27:58,320 --> 00:27:59,200
way.
Right.
507
00:27:59,560 --> 00:28:03,440
OK.
I guess one maybe concern that
508
00:28:03,440 --> 00:28:07,360
sort of comes to my mind, but
I'll let you address that is it
509
00:28:07,360 --> 00:28:13,040
sort of sounds like this would
make Lightning users very
510
00:28:13,040 --> 00:28:16,520
dependent on service providers.
Sure.
511
00:28:16,760 --> 00:28:22,640
Mentioned they're also more
general risk and I'm asked works
512
00:28:22,640 --> 00:28:24,120
for a Lightning service
provider.
513
00:28:24,120 --> 00:28:27,720
But, you know, is this a
reasonable concern in your view?
514
00:28:27,720 --> 00:28:30,960
Or is your view maybe.
But let's hear from Yassa first.
515
00:28:31,440 --> 00:28:33,440
Yeah, from my point of view, it
depends on how.
516
00:28:34,320 --> 00:28:37,320
Sure, I said.
Let's hear from Yassa first.
517
00:28:38,440 --> 00:28:38,920
OK.
OK.
518
00:28:39,000 --> 00:28:41,840
Well, OK.
So there's a user that
519
00:28:41,840 --> 00:28:46,920
apparently online lightning
node, right?
520
00:28:46,920 --> 00:28:49,520
So he wants to run a lightning
node in his pocket.
521
00:28:50,680 --> 00:28:55,880
So that means there's no other
way the network through nodes
522
00:28:55,880 --> 00:29:02,120
that are willing to accept that.
And as a reminder why there's
523
00:29:02,480 --> 00:29:07,240
William involved here, if if you
have a channel but you're
524
00:29:07,240 --> 00:29:11,760
offline all the time.
Now if channel and all the money
525
00:29:12,240 --> 00:29:14,840
in the channel is on your own
side, then the other side is not
526
00:29:14,840 --> 00:29:18,040
going to care.
But if you have made like lots
527
00:29:18,040 --> 00:29:20,720
and lots of payments through the
channel, now all the money's on
528
00:29:20,720 --> 00:29:22,720
the other side.
The other side is going to be
529
00:29:22,720 --> 00:29:26,960
annoyed by this because when
you're offline, they cannot
530
00:29:27,200 --> 00:29:30,760
access that money at all.
They can't, but they have to
531
00:29:30,760 --> 00:29:32,280
force close it, which is
expensive.
532
00:29:32,720 --> 00:29:34,720
They can't route anything
through it because you're
533
00:29:34,720 --> 00:29:35,960
offline.
You're not a routing node.
534
00:29:36,240 --> 00:29:39,520
So that money is just they own
it, but they're forced huddling
535
00:29:39,520 --> 00:29:42,520
it essentially.
And so there is not, not
536
00:29:42,520 --> 00:29:45,080
everybody's going to be willing
to just allow you to open a
537
00:29:45,080 --> 00:29:48,280
channel and behave like that.
I think right now many nodes
538
00:29:48,280 --> 00:29:51,680
don't care, but they might close
the channel on you saying, hey,
539
00:29:51,720 --> 00:29:52,960
this is not making me enough
money.
540
00:29:53,280 --> 00:29:55,720
So a Lightning service provider,
in the very broad sense, is
541
00:29:55,720 --> 00:30:00,000
anyone who's willing to just put
up with a peer that's not online
542
00:30:00,000 --> 00:30:02,240
all the time, probably by
charging.
543
00:30:02,680 --> 00:30:08,080
Yeah, how far is this?
So there's there's a lot of
544
00:30:08,080 --> 00:30:13,320
prerequisites.
So first of all, we need to
545
00:30:13,640 --> 00:30:19,320
taproot channels in order to TEP
root channels.
546
00:30:19,320 --> 00:30:24,200
Are L&D implemented the simple
TEP root channels protocol which
547
00:30:24,200 --> 00:30:27,320
sort of works with private
channels right now, but not with
548
00:30:27,320 --> 00:30:29,480
public?
OK, it's.
549
00:30:33,400 --> 00:30:36,560
Basically the the transit.
So lightning channels are
550
00:30:36,560 --> 00:30:40,080
basically just commitment
transaction, transactions on
551
00:30:40,080 --> 00:30:42,880
chain, right.
But you update them locally and
552
00:30:43,000 --> 00:30:46,760
you broadcast don't broadcast
many of these that you sign in
553
00:30:46,760 --> 00:30:49,480
between in your channel and
these transactions are tap
554
00:30:50,360 --> 00:30:51,760
actions.
So that's basically what a
555
00:30:52,240 --> 00:30:53,640
taproot channel is.
OK.
556
00:30:55,040 --> 00:30:56,960
So, so it's pretty much what it
sounds like.
557
00:30:57,120 --> 00:30:59,400
And that's just, that's just the
main transaction.
558
00:30:59,400 --> 00:31:02,320
But then there's the HTLCS, the
things that fly over the channel
559
00:31:02,320 --> 00:31:06,760
when you're making a payment,
those to make those PTLC another
560
00:31:06,760 --> 00:31:08,640
change, right?
You can have taproot channels
561
00:31:08,640 --> 00:31:11,840
that still use locks for the
payments.
562
00:31:12,480 --> 00:31:16,800
Yeah and so and also if you use
step root channels, you need to
563
00:31:16,800 --> 00:31:18,920
gossip your channel.
So you need to tell the rest of
564
00:31:18,920 --> 00:31:26,520
the network like these are the
channels that I have and this
565
00:31:26,520 --> 00:31:31,440
also does not exist yet.
So, so there's some
566
00:31:31,440 --> 00:31:39,080
prerequisites there on side.
And then there is a proposal now
567
00:31:39,080 --> 00:31:43,600
for holding the payment, which
is one part of ASYNC payments
568
00:31:44,320 --> 00:31:48,160
where the LSP holds the payment
until a message is sent when
569
00:31:48,160 --> 00:31:51,040
it's released.
And this standard is within the
570
00:31:51,040 --> 00:31:53,800
protocol itself.
So it's not like some custom API
571
00:31:53,800 --> 00:31:56,160
of the Lightning service
provider, It's really just part
572
00:31:56,160 --> 00:31:58,560
of the Lightning protocol.
Anybody who speaks to Lighting
573
00:31:58,560 --> 00:32:01,200
protocol could hold a payment.
Yeah.
574
00:32:01,200 --> 00:32:03,840
So there it would be the
question where this ends up
575
00:32:03,840 --> 00:32:12,720
exactly in Bolts, which is is a
Lightning Improvement Proposal.
576
00:32:13,640 --> 00:32:15,680
But blips can also be
implemented by any node
577
00:32:15,840 --> 00:32:21,440
basically.
So there's that part, which is
578
00:32:26,080 --> 00:32:34,440
are currently only supported by
CLN in order to be able.
579
00:32:36,480 --> 00:32:40,400
Because on your messages of Bolt
12, right, we just made, we did
580
00:32:40,400 --> 00:32:43,400
a whole episode about BOLT 12.
We explained how on your
581
00:32:43,400 --> 00:32:45,560
messages are kind of useful in
that scheme.
582
00:32:46,000 --> 00:32:50,680
But BOLT 12 is mostly being
pushed by core Lightning and I
583
00:32:50,680 --> 00:32:54,520
guess LDK now.
And so you have to wait for I
584
00:32:54,520 --> 00:32:56,080
guess you just need 2
implementations.
585
00:32:56,080 --> 00:32:58,120
But in order for it to be
useful, it's nice if LMD
586
00:32:58,120 --> 00:33:00,800
supports it, because like a
whole bunch of nodes are
587
00:33:01,280 --> 00:33:04,880
running, LMD in the onion
message needs to go from A to B
588
00:33:04,880 --> 00:33:09,720
through all these hops.
So if you know I, I think onion
589
00:33:09,720 --> 00:33:11,600
messages can follow any route
you like, right?
590
00:33:11,600 --> 00:33:14,720
They don't have to follow any
channels that exist, they can
591
00:33:14,720 --> 00:33:16,560
just go through any way through
the network.
592
00:33:16,920 --> 00:33:18,760
Yeah, I guess, yeah, they sort
of could.
593
00:33:18,760 --> 00:33:21,760
But you only know that people
are connected through their
594
00:33:21,760 --> 00:33:23,600
channels usually.
Right.
595
00:33:23,600 --> 00:33:26,000
Yeah, yeah, yeah.
So so it has to follow some
596
00:33:26,000 --> 00:33:28,880
bunch of channels and and if all
these nodes are running LED in
597
00:33:28,880 --> 00:33:31,760
the middle, then you just don't
have a way to get your message
598
00:33:31,760 --> 00:33:34,080
to the other side.
Yeah.
599
00:33:35,600 --> 00:33:39,080
So I think we probably talked
about most of the prerequisites.
600
00:33:39,080 --> 00:33:40,240
Trampoline.
Yeah.
601
00:33:40,240 --> 00:33:41,680
So trampoline.
Yeah, exactly.
602
00:33:41,760 --> 00:33:45,080
That's done by the assigned
people that's used by Phoenix,
603
00:33:45,080 --> 00:33:46,440
but is.
It yeah, by the assigned people
604
00:33:46,480 --> 00:33:52,200
now and there's so LDK also
implemented parts of it.
605
00:33:52,200 --> 00:33:55,320
I don't think they completed
trampoline payments completely.
606
00:33:55,320 --> 00:33:56,840
Please correct me if I'm wrong
there.
607
00:33:58,520 --> 00:34:00,640
So that's also not part of the
Bolt spec yet.
608
00:34:00,680 --> 00:34:02,280
It's not merged into the spec
yet.
609
00:34:02,400 --> 00:34:05,680
OK, so basically there's still a
bunch of building blocks that
610
00:34:05,680 --> 00:34:09,040
need to be in place before this
can work, and different
611
00:34:09,040 --> 00:34:12,159
implementations are in different
stages of completing these
612
00:34:12,159 --> 00:34:13,440
building blocks.
Yeah.
613
00:34:13,600 --> 00:34:16,480
So it's basically almost every
improvement to the Lighting
614
00:34:16,480 --> 00:34:20,080
Network that we want to have is
sort of a prerequisite for async
615
00:34:20,080 --> 00:34:22,040
payments.
Sounds easy.
616
00:34:22,040 --> 00:34:23,280
Two weeks.
Yeah.
617
00:34:23,600 --> 00:34:27,080
No, it's not going to be two
weeks, but and more like several
618
00:34:27,080 --> 00:34:29,480
severally.
Is anyone against this?
619
00:34:32,239 --> 00:34:34,040
Is jungle for all against async
payments.
620
00:34:34,800 --> 00:34:38,159
He's against everything.
So I'm assuming what?
621
00:34:38,159 --> 00:34:40,400
Why are there people against
this?
622
00:34:41,480 --> 00:34:44,360
Is this, is this like in any way
controversial or are there
623
00:34:44,360 --> 00:34:47,920
concerns about this?
Or maybe there are people that
624
00:34:47,920 --> 00:34:50,280
have, you know, developers that
have different preferences?
625
00:34:50,280 --> 00:34:54,880
Or is there?
People may be against some parts
626
00:34:54,880 --> 00:35:04,480
of the upgrades, yeah, so maybe
I I'm not exactly sure about
627
00:35:04,480 --> 00:35:09,080
their reasoning, but one reason
I can come up with is that well
628
00:35:09,080 --> 00:35:12,040
on your messages they can also
be a DOS factor.
629
00:35:13,600 --> 00:35:15,800
So just, I said.
Lalo basically came up with
630
00:35:15,800 --> 00:35:16,440
that.
They said.
631
00:35:16,480 --> 00:35:21,320
Just am I misremembering that?
I I don't know about this.
632
00:35:21,320 --> 00:35:22,400
Exactly.
Oh, never mind.
633
00:35:23,520 --> 00:35:27,760
OK, so they they might be
against onion messages.
634
00:35:27,760 --> 00:35:29,520
Or are they against onion
messages?
635
00:35:29,520 --> 00:35:31,040
Yeah, you you think?
So, well, they're not
636
00:35:31,040 --> 00:35:38,640
implementing it.
They they do have so, so LNDK
637
00:35:39,120 --> 00:35:41,720
which is sort of like an
extension to L&D which does
638
00:35:41,720 --> 00:35:43,880
support all your messages and.
Yeah.
639
00:35:43,880 --> 00:35:46,840
I mean, sometimes, most of the
time when somebody doesn't
640
00:35:46,840 --> 00:35:48,920
implement something, it's just
because they don't have time for
641
00:35:48,920 --> 00:35:51,280
it because they're working on
6000 other things that have that
642
00:35:51,280 --> 00:35:53,000
priority.
It's not that they're opposed to
643
00:35:53,000 --> 00:35:54,320
it.
Right.
644
00:35:54,880 --> 00:35:56,200
OK.
So as far as you know, there's
645
00:35:56,200 --> 00:36:00,400
not necessarily any opposition
to asynchronous payments I.
646
00:36:00,400 --> 00:36:03,200
Don't.
I think this is just a great.
647
00:36:03,360 --> 00:36:04,800
Yeah.
And and it's also a bit of a
648
00:36:04,800 --> 00:36:08,520
harm, harm reduction thing
because people like this ability
649
00:36:08,520 --> 00:36:12,280
to pay to a mobile.
So there are already solutions
650
00:36:12,320 --> 00:36:14,880
out there that will just lock up
all the liquidity.
651
00:36:16,200 --> 00:36:18,040
Yeah, and that's evil.
Lots of problems.
652
00:36:18,040 --> 00:36:20,920
So it's one of those things
where it's might be better to
653
00:36:20,920 --> 00:36:23,080
implement it because the
alternative is worse.
654
00:36:24,000 --> 00:36:26,960
Right, OK.
Does that cover it?
655
00:36:27,200 --> 00:36:28,000
I think so.
You got it.
656
00:36:30,080 --> 00:36:33,280
And if you want to shell.
Where should people find you?
657
00:36:33,320 --> 00:36:35,720
Yeah, that's a good Should
people find you people?
658
00:36:35,720 --> 00:36:38,920
Can find me on Twitter at With
the Jesse.
659
00:36:41,720 --> 00:36:46,960
In that case.
For a choice.
660
00:36:46,960 --> 00:36:48,480
Indeed.
Thank you for listening to
661
00:36:48,480 --> 00:36:49,800
Bitcoin.
Explained.
