Episode 91: Splicing

1
00:00:17,640 --> 00:00:21,560
Life from its rest, this is
Bitcoin, explained.
2
00:00:21,680 --> 00:00:26,400
Hey shots, Hello.
First of all, I want to thank
3
00:00:26,400 --> 00:00:31,080
Cold Card No Coin Kite, the
sponsor of our show, for
4
00:00:31,080 --> 00:00:35,600
producing a beautiful cold card
cue which Josh just passed me in
5
00:00:35,600 --> 00:00:37,440
my hands.
Josh, what is this?
6
00:00:37,440 --> 00:00:40,280
I see it has a full QWERTY
keyboard.
7
00:00:40,720 --> 00:00:44,600
I see it's a ECC calculator.
An elliptic curve cryptography
8
00:00:44,600 --> 00:00:45,720
calculator.
It is.
9
00:00:45,720 --> 00:00:48,480
It is a beautiful device.
It's unfortunate we don't have a
10
00:00:48,480 --> 00:00:50,680
video for our podcast.
Essentially it looks like a
11
00:00:50,680 --> 00:00:54,520
Nintendo I guess, but.
For you mean a Game Boy?
12
00:00:55,040 --> 00:00:57,920
Or a Game Boy.
See, I did not play that many
13
00:00:57,920 --> 00:01:01,240
computer games clearly.
Well, I played PC games anyhow.
14
00:01:01,600 --> 00:01:03,960
So this is a hardware wallet.
Yeah, it's.
15
00:01:03,960 --> 00:01:08,160
I believe it's essentially the
same as their other cold cart
16
00:01:08,200 --> 00:01:09,600
wallets.
It's just bigger.
17
00:01:09,920 --> 00:01:11,640
Yeah, bigger screen, bigger
everything.
18
00:01:11,840 --> 00:01:13,040
Yeah.
But my understanding is that
19
00:01:13,040 --> 00:01:15,880
fundamentally it's it's very
similar, so that it's not like
20
00:01:15,880 --> 00:01:19,400
they're introducing completely
new security assumptions.
21
00:01:20,120 --> 00:01:21,560
Right.
Did you buy this or did you get
22
00:01:21,560 --> 00:01:22,520
this?
No, I got this one.
23
00:01:22,520 --> 00:01:24,480
For sponsored.
I don't think we got it because
24
00:01:24,480 --> 00:01:26,480
we're sponsored.
I I always get them because I
25
00:01:26,480 --> 00:01:28,720
test them as a developer.
Fair enough.
26
00:01:29,160 --> 00:01:31,320
All right, well, that's our
sponsor, Goldkart.
27
00:01:31,480 --> 00:01:34,440
They got AQ device.
You can buy this right online.
28
00:01:34,440 --> 00:01:38,120
Go to coldkart.com, coykart.com,
probably go shares, something
29
00:01:38,120 --> 00:01:39,400
like that.
All right.
30
00:01:40,120 --> 00:01:43,320
So today, actually, we have
another guest.
31
00:01:44,200 --> 00:01:47,040
Hello, Jesse the White.
He's back.
32
00:01:47,480 --> 00:01:50,560
Here I am again, yeah.
Maybe for those that didn't
33
00:01:50,560 --> 00:01:54,560
listen to the previous episodes,
you can repeat a small
34
00:01:54,560 --> 00:01:57,120
introduction of yourself.
Yeah, a small introduction
35
00:01:57,480 --> 00:01:59,720
yesterday, David.
I'm a Lightning developer
36
00:01:59,720 --> 00:02:01,600
working for Breeze.
Right.
37
00:02:01,840 --> 00:02:06,320
So we we got you in last episode
because we've been getting some
38
00:02:06,320 --> 00:02:09,400
requests to do lightning
episodes and Shosh and I are
39
00:02:09,400 --> 00:02:12,280
sort of getting out of our depth
with like advanced lighting
40
00:02:12,280 --> 00:02:14,840
topics.
So very thankful that you came
41
00:02:14,840 --> 00:02:16,360
back.
We're going to do another
42
00:02:16,360 --> 00:02:20,080
Lightning episode.
This time we're going to discuss
43
00:02:20,080 --> 00:02:22,560
splicing.
But before we get.
44
00:02:22,560 --> 00:02:23,560
Oh, wait, wait.
There's wind.
45
00:02:23,560 --> 00:02:25,600
Yeah.
Yeah, there's something else we
46
00:02:25,600 --> 00:02:26,760
want to discuss real quick.
Right.
47
00:02:26,760 --> 00:02:27,720
Yours.
That's right.
48
00:02:27,960 --> 00:02:31,360
We made an episode on the
tornado cache trial at some
49
00:02:31,360 --> 00:02:36,400
point this was episode 69.
And the trial well that the
50
00:02:36,400 --> 00:02:39,880
trial actually happened this
week prior in previously were
51
00:02:39,880 --> 00:02:44,120
like hearings there were yeah.
Previously there were just like
52
00:02:44,120 --> 00:02:47,040
5 or so over the last two years
meta hearings.
53
00:02:47,040 --> 00:02:51,600
So they were about his pretrial
detention, about which documents
54
00:02:51,600 --> 00:02:54,360
the defense wants, that sort of
stuff.
55
00:02:55,480 --> 00:02:57,920
And today, no, sorry.
This week there was 2 days of
56
00:02:57,920 --> 00:03:02,640
the actual trial in dembos with
extremely uncomfortable seats.
57
00:03:02,920 --> 00:03:04,560
Well, I mean, the seats are
fine.
58
00:03:04,560 --> 00:03:06,520
They have little pillows, but if
you have to sit on them for
59
00:03:06,520 --> 00:03:08,200
eight hours, it's very
uncomfortable.
60
00:03:10,040 --> 00:03:13,800
There was quite a few people in
attendance, like multiple
61
00:03:13,800 --> 00:03:18,880
journalists, even from the
mainstream media, and lots of,
62
00:03:18,880 --> 00:03:20,200
you know, some of his
supporters.
63
00:03:20,680 --> 00:03:25,600
Probably also half the FBII
wouldn't know, but some people
64
00:03:25,600 --> 00:03:28,240
in suits.
That that spoke American.
65
00:03:29,360 --> 00:03:30,720
Maybe.
At least they, you know.
66
00:03:32,360 --> 00:03:36,720
So you attended.
And so I what I recall, I mean I
67
00:03:36,720 --> 00:03:40,560
was at the hearing center, I was
either trial briefly but not not
68
00:03:40,560 --> 00:03:44,840
for the full 2 days like you.
And what I recall from the
69
00:03:44,840 --> 00:03:47,600
hearings at least was that they
revealed it.
70
00:03:47,600 --> 00:03:51,680
It really seemed like the case
was going to boil down to shoot
71
00:03:51,680 --> 00:03:56,880
a Dow, be considered like a
company that was like no.
72
00:03:57,080 --> 00:03:58,440
Oh.
It goes beyond that.
73
00:03:58,440 --> 00:04:01,360
They're basically saying the
whole Dow is just a just a
74
00:04:01,360 --> 00:04:05,640
little fantasy and really the
three people were in control of
75
00:04:05,640 --> 00:04:07,320
everything.
I mean, that's kind of what I
76
00:04:07,320 --> 00:04:09,560
mean.
Yeah, like it's not really
77
00:04:09,800 --> 00:04:12,280
decentralized in any they.
Don't really care what the
78
00:04:12,280 --> 00:04:14,560
company is.
They're saying that tornado
79
00:04:14,560 --> 00:04:17,680
cash, whatever that is, whether
that's a company or an entity or
80
00:04:17,680 --> 00:04:22,040
just a group of people, is like
a business in the way it's
81
00:04:22,040 --> 00:04:25,680
operated, you know, as, as they
would like if they were
82
00:04:25,680 --> 00:04:27,280
prosecuting, say, a criminal
organization.
83
00:04:27,280 --> 00:04:29,960
They don't care that it's, you
know, Mafia Incorporated doesn't
84
00:04:29,960 --> 00:04:32,040
exist, right?
So in that sense, they're
85
00:04:32,040 --> 00:04:35,120
arguing it's just a business and
they're doing things for profit.
86
00:04:35,120 --> 00:04:39,200
And the profit came from pumping
the token if I translate it.
87
00:04:39,440 --> 00:04:42,040
Yeah, the tornado token.
Because it's very clear that
88
00:04:42,040 --> 00:04:46,080
there was no money coming
directly from the from the
89
00:04:46,080 --> 00:04:48,600
transactions on the mixer in the
way it's designed.
90
00:04:48,600 --> 00:04:52,480
We explained that in episode 69,
but they said even though
91
00:04:52,480 --> 00:04:56,160
there's no direct flow of money,
they're still profiting from it.
92
00:04:56,200 --> 00:04:58,400
But even I guess even if they
weren't profiting from it,
93
00:04:58,400 --> 00:05:02,000
they're still allowing mixing to
happen and that itself is
94
00:05:02,000 --> 00:05:04,320
enough.
So it's a it's a pretty
95
00:05:04,320 --> 00:05:06,760
fundamental case.
I would say like at in the
96
00:05:06,760 --> 00:05:09,440
beginning we didn't know if
maybe there was some gotcha, you
97
00:05:09,440 --> 00:05:13,280
know, like something really
different that would have made
98
00:05:13,280 --> 00:05:16,240
the case.
So, for example, they were not
99
00:05:16,240 --> 00:05:19,200
running relayers themselves, any
of that stuff.
100
00:05:19,400 --> 00:05:22,840
The original concern at least
was, you know, writing open
101
00:05:22,840 --> 00:05:24,760
source code should not be
illegal.
102
00:05:24,760 --> 00:05:27,440
Basically what whatever people
use it for.
103
00:05:27,800 --> 00:05:31,440
Yeah, so the prosecutor keeps
saying that writing open source
104
00:05:31,440 --> 00:05:33,480
is fine.
It's great, We love it.
105
00:05:34,240 --> 00:05:38,800
But if you want to make money
with it in any way, I guess then
106
00:05:38,800 --> 00:05:41,640
you can't do it.
So it's it's like, you know,
107
00:05:41,640 --> 00:05:44,560
privacy is legal, but if you
make any money offering it, it's
108
00:05:44,560 --> 00:05:46,920
not legal.
That's sort of my take away from
109
00:05:46,920 --> 00:05:48,040
it.
And they're trying to make the
110
00:05:48,040 --> 00:05:53,000
distinction between VPN privacy,
which is or like communications,
111
00:05:53,000 --> 00:05:57,440
and money privacy, which are
objects, or, or money, which is
112
00:05:57,440 --> 00:06:00,560
treated differently.
Was there were there any, like
113
00:06:00,560 --> 00:06:05,680
new insights did this week as
far as you could say or compared
114
00:06:05,680 --> 00:06:08,840
to the hearings that I attended,
was it kind of the same thing,
115
00:06:08,840 --> 00:06:10,000
just a bit?
More Well, the hearings you
116
00:06:10,000 --> 00:06:12,240
attended were not supposed to be
about the case itself.
117
00:06:12,240 --> 00:06:13,760
I mean, I know, but they kind of
were.
118
00:06:13,760 --> 00:06:16,080
Yeah, yeah, they were exactly.
Because there's lots of media
119
00:06:16,080 --> 00:06:19,400
present.
I don't know.
120
00:06:19,400 --> 00:06:21,760
I don't really think so.
It felt to me like it was
121
00:06:21,760 --> 00:06:24,680
roughly just, you know, going
into more detail explaining
122
00:06:24,680 --> 00:06:27,320
which law articles, you know,
the prosecution would explain,
123
00:06:27,320 --> 00:06:30,640
OK, you know, this, this money
laundering, different articles.
124
00:06:30,640 --> 00:06:32,640
And we're we're not talking
about Article A, but we're
125
00:06:32,640 --> 00:06:35,840
talking about Article B, that
sort of clarification.
126
00:06:35,840 --> 00:06:39,200
So I took a lot of notes, but I
really have to take my notes and
127
00:06:39,200 --> 00:06:43,040
go talk to an actual legal
expert to understand the meaning
128
00:06:43,680 --> 00:06:46,200
of exactly what was said.
And then the prosecution always
129
00:06:46,200 --> 00:06:48,000
has the advantage.
They can paint a very nice
130
00:06:48,000 --> 00:06:53,080
narrative, a story, but the
defense does not have that,
131
00:06:53,120 --> 00:06:55,040
isn't it's not so easy.
I mean, they of course, they try
132
00:06:55,040 --> 00:06:58,960
to explain how open source
works, and the decentralization
133
00:06:58,960 --> 00:07:00,640
is a good thing.
Privacy is important.
134
00:07:00,640 --> 00:07:04,240
That's that sort of stuff.
But a lot of the time they just
135
00:07:04,240 --> 00:07:07,880
have to spend shooting holes at
individual arguments of the
136
00:07:07,880 --> 00:07:09,640
prosecution.
So they have to say, well, if
137
00:07:09,640 --> 00:07:14,320
you look at Article 64 B, you
know the word holding means you
138
00:07:14,320 --> 00:07:15,760
know this and it doesn't mean
that.
139
00:07:15,760 --> 00:07:20,440
And they also have to try 15
different arguments just to see
140
00:07:20,440 --> 00:07:23,000
if one of the 15 works.
And that makes it as it as the
141
00:07:23,000 --> 00:07:24,680
audience makes it more difficult
to understand.
142
00:07:24,680 --> 00:07:28,080
And especially if you're not a
lawyer yourself, it's hard to
143
00:07:28,080 --> 00:07:31,000
estimate whether you know.
Just because he says it with
144
00:07:31,000 --> 00:07:32,280
conviction doesn't mean it
works.
145
00:07:32,840 --> 00:07:35,920
And it's important to know that
we don't have jury trials.
146
00:07:36,360 --> 00:07:41,600
So the goal is not to explain
things and to convince a a jury
147
00:07:41,600 --> 00:07:44,480
of of non legal people like in
the US.
148
00:07:44,960 --> 00:07:46,760
It is merely to convince the
judges.
149
00:07:46,800 --> 00:07:49,560
And the judges have already
received, I don't know, a
150
00:07:49,560 --> 00:07:51,960
million pages of documents and
reports and they've all read it.
151
00:07:52,480 --> 00:07:56,000
So they also, they also already
know the arguments that both
152
00:07:56,000 --> 00:07:58,400
sides are going to make.
So it's kind of a performative
153
00:07:58,400 --> 00:08:01,400
thing almost where you have to
say it out loud so people can
154
00:08:01,840 --> 00:08:04,120
listen to it.
But the judges are kind of like
155
00:08:04,120 --> 00:08:06,080
just, you know, behind the
screen and they're listening and
156
00:08:06,080 --> 00:08:11,200
they, yeah.
And the verdicts will come in.
157
00:08:11,320 --> 00:08:14,000
May 14th.
May 14th.
158
00:08:14,000 --> 00:08:16,800
All right, last question.
So what's?
159
00:08:18,120 --> 00:08:21,320
I guess we discussed this in the
actual episode Episode 69, so we
160
00:08:21,320 --> 00:08:24,640
don't have to get into it, but
the reason you attended is it
161
00:08:24,640 --> 00:08:27,640
could have relevance for Bitcoin
development as well potentially.
162
00:08:27,640 --> 00:08:29,960
In the long run, it will, I'm
pretty sure about that because
163
00:08:29,960 --> 00:08:33,960
it's it's kind of a moving game
where you know the the frontline
164
00:08:33,960 --> 00:08:36,320
is moving and maybe you could
say, oh, the frontline is in
165
00:08:36,320 --> 00:08:38,520
shit coin land.
But if you read some of the
166
00:08:38,520 --> 00:08:41,600
arguments that the prosecutor is
making, the really generic
167
00:08:41,600 --> 00:08:45,160
arguments, like if you make
something that is decentralized,
168
00:08:45,160 --> 00:08:47,920
the fact that you could have
made it centralized but you made
169
00:08:47,920 --> 00:08:51,200
it decentralized already means
you deliberately did something
170
00:08:51,400 --> 00:08:55,720
to aid money laundering.
So if that argument stands, then
171
00:08:55,720 --> 00:08:58,640
you know, basically Satoshi
would be screwed, right?
172
00:09:00,360 --> 00:09:02,480
Satoshi could have made a
centralized system, right?
173
00:09:02,480 --> 00:09:03,960
And he didn't.
And he made money.
174
00:09:04,320 --> 00:09:06,200
Arguably, we don't know if he
has any money.
175
00:09:07,400 --> 00:09:10,800
I mean, he still had to earn it
as well, right?
176
00:09:12,920 --> 00:09:16,400
He still had to mine it.
Yeah, but he was.
177
00:09:16,400 --> 00:09:18,320
He wouldn't have been able to
mine it if it didn't exist.
178
00:09:18,960 --> 00:09:21,040
I don't know what kind of
argument would be made there.
179
00:09:21,360 --> 00:09:23,120
Anyways, thanks for your
sacrifice.
180
00:09:23,120 --> 00:09:28,120
I I'm impressed to hear about
the the cushion situation and
181
00:09:28,120 --> 00:09:30,960
that you pulled through anyways.
I found out if you just pile
182
00:09:30,960 --> 00:09:33,200
some jackets and stuff and it's
a little bit more comfortable.
183
00:09:33,200 --> 00:09:36,200
Got it all figured out.
All right, one more quick note.
184
00:09:36,200 --> 00:09:39,920
Before we actually get to
splicing, you wanted to mention
185
00:09:39,920 --> 00:09:42,640
something about Mara pool.
Mara did this thing with the
186
00:09:42,640 --> 00:09:45,960
block thing, which you could see
a mample space.
187
00:09:45,960 --> 00:09:47,080
That's what this is about,
right?
188
00:09:47,080 --> 00:09:49,880
Yeah, if if you are into
nonsense then you may have
189
00:09:49,880 --> 00:09:53,520
noticed that Mara pool mined a
block that if you look at it on
190
00:09:53,520 --> 00:09:58,240
mample dot space it looks like a
picture of an M just because of
191
00:09:58,240 --> 00:10:00,560
the way mample dot space.
Visualized that logo, yeah.
192
00:10:00,560 --> 00:10:02,640
If you go to any other website,
it won't look like bad.
193
00:10:04,160 --> 00:10:07,360
Point is they achieve this by
putting transactions in a very
194
00:10:07,360 --> 00:10:09,760
specific order.
All these transactions are
195
00:10:09,760 --> 00:10:11,360
nonsensical Operator in
transactions.
196
00:10:11,960 --> 00:10:13,440
All of them.
Not all of them, right?
197
00:10:13,440 --> 00:10:14,600
As far as I know, the whole
block.
198
00:10:14,640 --> 00:10:16,400
Yeah, the whole block was
nonsense.
199
00:10:16,400 --> 00:10:22,560
Yeah, I'll get to that.
So basically, we had episode 84
200
00:10:22,560 --> 00:10:25,560
where we talked about about six
months ago, Maripool mined an
201
00:10:25,560 --> 00:10:27,800
invalid block.
And the reason they mined an
202
00:10:27,800 --> 00:10:30,760
invalid block was because they
were putting transactions in the
203
00:10:30,760 --> 00:10:34,440
wrong order.
So if transaction A is created
204
00:10:34,440 --> 00:10:38,040
and transaction B spends
transaction A, they must appear
205
00:10:38,040 --> 00:10:40,680
in that block in that order.
So transaction A first,
206
00:10:40,680 --> 00:10:43,840
transaction B next, and they
just sort at them all by, I
207
00:10:43,840 --> 00:10:45,480
don't know, by name or something
crazy.
208
00:10:45,920 --> 00:10:48,360
And so the the order was wrong
and the block was invalid and
209
00:10:48,360 --> 00:10:52,920
they lost a couple $100,000.
But now looking back that they
210
00:10:52,920 --> 00:10:57,240
have created this this graffiti
block I guess where the order of
211
00:10:57,240 --> 00:10:59,080
the transaction is used as a
feature.
212
00:10:59,080 --> 00:11:01,920
My guess is that's what they
were sort of trying to get to.
213
00:11:02,760 --> 00:11:05,240
That still does not explain why
they tested that on mainnet
214
00:11:05,240 --> 00:11:08,600
instead of on testnet.
They were.
215
00:11:08,640 --> 00:11:11,720
They were experimenting back.
Then, but the reason I guess why
216
00:11:11,720 --> 00:11:13,600
they picked up return
transactions this time is
217
00:11:13,600 --> 00:11:18,200
because you can just make them
all independent and the order,
218
00:11:18,240 --> 00:11:20,560
you know, it doesn't matter, you
don't get an invalid order.
219
00:11:21,160 --> 00:11:23,960
But it would be more, you know,
if they want to continue this,
220
00:11:23,960 --> 00:11:27,960
this artistic career of theirs,
I think it would be better to
221
00:11:27,960 --> 00:11:30,720
mine real transactions that are
actually paying, you know,
222
00:11:30,720 --> 00:11:33,400
roughly the maximum fee that you
wouldn't mind, maybe slightly
223
00:11:33,400 --> 00:11:37,240
less, and then order those in a
visual pattern so you do not
224
00:11:37,240 --> 00:11:38,920
know in advance what the block
is going to look like.
225
00:11:38,920 --> 00:11:41,280
Your algorithm just has to
figure out how to take whatever
226
00:11:41,280 --> 00:11:46,600
is in the manpool and and write
copyright shorts on it.
227
00:11:46,840 --> 00:11:49,920
You just got to make sure that
the order is still not invalid.
228
00:11:49,920 --> 00:11:52,000
Exactly so.
So you have to exactly.
229
00:11:52,160 --> 00:11:54,280
So it's it's much more.
It would require significantly
230
00:11:54,280 --> 00:11:56,640
more skill.
I do not believe it is a good
231
00:11:56,640 --> 00:11:59,200
use of anyone's time, but if you
are into this, please do it
232
00:11:59,200 --> 00:12:00,960
well.
Right.
233
00:12:01,000 --> 00:12:02,840
OK.
So that that sort of explains
234
00:12:02,840 --> 00:12:06,880
for us maybe, probably, possibly
going on in episode 84.
235
00:12:07,200 --> 00:12:09,680
So that was a second call back
to an earlier episode.
236
00:12:09,960 --> 00:12:11,800
Now let's make a new episode
yours.
237
00:12:12,280 --> 00:12:13,600
Yes, good idea.
Yes, Sir.
238
00:12:14,080 --> 00:12:16,160
You're you're you're down to
make a new episode.
239
00:12:16,160 --> 00:12:18,760
Let's make a new episode.
Let's make one about splicing.
240
00:12:20,400 --> 00:12:24,560
OK, so splicing is a concept
that exists in lightning.
241
00:12:24,560 --> 00:12:26,280
First, yes.
What is it?
242
00:12:26,400 --> 00:12:29,800
Let's start with a very basic,
one sentence explanation.
243
00:12:29,800 --> 00:12:32,960
What is splicing?
Splicing is basically giving you
244
00:12:32,960 --> 00:12:36,600
the capability to change the
capacity of an existing channel.
245
00:12:37,440 --> 00:12:39,040
So.
OK, so I have a channel with
246
00:12:39,040 --> 00:12:42,720
shorts say there's, I don't
know, let's say one Bitcoin in
247
00:12:42,720 --> 00:12:46,800
that Channel and we can increase
that to two Bitcoin or half
248
00:12:46,800 --> 00:12:49,080
Bitcoin increase or decrease.
That's or decrease, yeah.
249
00:12:49,120 --> 00:12:50,800
Yeah, that's what.
That's what splicing is.
250
00:12:51,360 --> 00:12:56,000
And why?
Why would anyone want to do
251
00:12:56,000 --> 00:12:57,520
this?
Maybe that's a good follow.
252
00:12:57,560 --> 00:13:01,480
What's the actual benefit here?
So why not just open a new
253
00:13:01,480 --> 00:13:02,880
channel?
Or why not?
254
00:13:02,880 --> 00:13:05,760
I don't know.
Receive coins in the channel or
255
00:13:05,760 --> 00:13:07,400
what, Yeah.
Yeah, yeah.
256
00:13:07,400 --> 00:13:11,440
So a lightning channel, you want
basically want the lifetime of
257
00:13:11,440 --> 00:13:16,040
lightning channel to be very
long and you want to during the
258
00:13:16,040 --> 00:13:18,120
lifetime with the channel you
want it to be operational.
259
00:13:18,120 --> 00:13:21,960
And then definitely as a routing
node, for example, if you want
260
00:13:21,960 --> 00:13:25,120
to increase the capacity of your
channel as a routing node, you
261
00:13:25,120 --> 00:13:28,800
want your channel to always be
available because otherwise
262
00:13:28,800 --> 00:13:31,480
people won't be able to route
payments over it and you won't
263
00:13:31,480 --> 00:13:36,640
make any fees.
The alternative would be closing
264
00:13:36,640 --> 00:13:39,840
and opening a channel or opening
an additional channel for
265
00:13:39,840 --> 00:13:44,520
example.
But yeah, it saves a lot in
266
00:13:44,520 --> 00:13:46,840
chain fees in the end basically
as well.
267
00:13:47,280 --> 00:13:51,680
Why does it save in chain fees
versus opening an additional
268
00:13:51,680 --> 00:13:52,600
channel?
Why?
269
00:13:52,600 --> 00:13:53,360
Why?
Why?
270
00:13:53,360 --> 00:13:56,320
What's the benefit?
It's basically the closing cost
271
00:13:56,480 --> 00:14:04,080
that you don't have because,
well, you splice in this this
272
00:14:04,400 --> 00:14:07,200
channel.
So that means maybe we should
273
00:14:07,200 --> 00:14:09,680
talk a little bit about how
splicing works.
274
00:14:10,000 --> 00:14:11,000
Well, hey, I know it makes
sense.
275
00:14:11,000 --> 00:14:14,320
I mean, eventually you're going
to want to close the channels
276
00:14:14,320 --> 00:14:17,120
and if you keep opening new
channels, that means you have to
277
00:14:17,120 --> 00:14:19,600
close all these channels, while
if you replace the same channel,
278
00:14:20,120 --> 00:14:22,360
they don't, then you only have
to close one channel.
279
00:14:22,360 --> 00:14:24,520
So that's that's what you're
saving essentially, right?
280
00:14:24,800 --> 00:14:27,360
And it's half the transactions
in the long run, right?
281
00:14:27,360 --> 00:14:29,680
Because closing is 1
transaction, opening is 1
282
00:14:29,680 --> 00:14:30,920
transaction, right?
Yeah.
283
00:14:31,840 --> 00:14:37,320
Though I guess you theoretically
could combine them, I think you
284
00:14:37,320 --> 00:14:39,640
mentioned another reason why
this was good.
285
00:14:40,960 --> 00:14:46,000
Or you want it to always work
and the the fees are there's
286
00:14:46,000 --> 00:14:48,040
less fees, less, less.
Yeah, we covered the part that
287
00:14:48,040 --> 00:14:49,120
it always works.
So.
288
00:14:49,120 --> 00:14:52,120
So because if you close the
channel then nothing, nothing
289
00:14:52,120 --> 00:14:54,720
works until you've reopened it
and waited six blocks.
290
00:14:55,040 --> 00:14:56,160
Yeah, exactly.
Yeah.
291
00:14:56,200 --> 00:14:59,520
So if you would close and reopen
a channel, yeah, your channel is
292
00:14:59,520 --> 00:15:02,880
temporarily unavailable, so
nobody will be able to route
293
00:15:02,880 --> 00:15:06,280
over it with splicing and we'll
get into that.
294
00:15:07,040 --> 00:15:12,480
You'll be able to keep using the
channel while while you've spent
295
00:15:12,480 --> 00:15:15,120
your previous channel.
Basically, during the splice you
296
00:15:15,120 --> 00:15:19,280
can.
OK, why is this like a challenge
297
00:15:19,320 --> 00:15:20,880
at all?
Why is this a problem?
298
00:15:20,880 --> 00:15:22,480
What's it?
What is the challenge here?
299
00:15:22,480 --> 00:15:26,440
Why wasn't this finished in 2017
like the white Paper promised?
300
00:15:28,280 --> 00:15:29,720
Yeah.
Or just why isn't this standard?
301
00:15:29,720 --> 00:15:31,360
What's?
What's even the problem that
302
00:15:31,360 --> 00:15:35,920
we're trying to solve?
So there were many design
303
00:15:35,920 --> 00:15:39,680
decisions on how to do splicing,
like how do you increase the
304
00:15:39,680 --> 00:15:42,160
capacity of a channel because
what a channel a lightning
305
00:15:42,160 --> 00:15:47,880
channel is, it is basically a
UTXO on chain, so that has a
306
00:15:47,880 --> 00:15:49,480
certain capacity.
Right.
307
00:15:49,840 --> 00:15:52,440
It has a fixed capacity.
There's no way to add something
308
00:15:52,440 --> 00:15:54,480
to an existing UTX.
O no, no.
309
00:15:54,800 --> 00:15:56,720
Exactly.
So that's the challenge we're
310
00:15:56,720 --> 00:15:57,280
trying to.
Solve.
311
00:15:57,280 --> 00:15:59,680
So that's the challenge we're
trying to solve and multiple
312
00:15:59,680 --> 00:16:02,080
ways people were trying to do
that.
313
00:16:02,440 --> 00:16:06,520
For example, Renee Picard, he
mentioned maybe we could have
314
00:16:06,520 --> 00:16:12,040
like 2 UTXOS in the same channel
for or or there are other?
315
00:16:12,040 --> 00:16:16,000
Designers in place one at the
time, something like that, Yeah.
316
00:16:16,080 --> 00:16:18,840
I mean, this is obviously not
what we don't have to get into.
317
00:16:18,840 --> 00:16:22,280
No, But that was that would be
the general sort of, yeah idea
318
00:16:22,280 --> 00:16:22,960
there.
Yeah, OK.
319
00:16:22,960 --> 00:16:25,160
But that's not what splicing is.
That's not what splicing.
320
00:16:26,160 --> 00:16:30,680
So because with splicing what
you do is you spend the funding
321
00:16:30,680 --> 00:16:34,920
transaction.
So the funding transaction is
322
00:16:34,920 --> 00:16:36,640
the is your channel on chain
right?
323
00:16:37,000 --> 00:16:41,440
And then off chain you have a
bunch of commitment transactions
324
00:16:42,240 --> 00:16:44,680
which are the the previous
states of your lightning
325
00:16:44,680 --> 00:16:45,440
channel.
Yeah.
326
00:16:45,440 --> 00:16:48,280
Every time Shush and I update
our channel, we're getting a new
327
00:16:48,280 --> 00:16:51,400
off chain transaction expense
from the UTXO basically and
328
00:16:51,400 --> 00:16:53,080
we're not broadcasting that
initially.
329
00:16:53,080 --> 00:16:56,000
Yeah, and all these transactions
are valid transactions and you
330
00:16:56,120 --> 00:16:59,040
would be able to broadcast them
at any time, but only one of
331
00:16:59,040 --> 00:17:04,160
them is the latest and you will.
But with splicing what you do is
332
00:17:04,160 --> 00:17:10,400
you yeah, you spend the funding
transaction and with the
333
00:17:10,400 --> 00:17:15,160
transaction that spends funding
transaction you add an input to
334
00:17:15,160 --> 00:17:19,280
that if you if you want to
increase the channel capacity or
335
00:17:19,280 --> 00:17:23,040
you add an output to that if you
if you want to decrease the
336
00:17:23,040 --> 00:17:26,000
channel capacity basically.
OK, we're so we're spending
337
00:17:26,440 --> 00:17:30,440
basically all the funds from the
channel from the U2 XO to a new
338
00:17:30,520 --> 00:17:35,240
U2 XO which then becomes the
channel, I would assume, right,
339
00:17:35,240 --> 00:17:36,840
Yeah.
That then becomes the channel,
340
00:17:36,840 --> 00:17:37,520
yeah.
OK.
341
00:17:37,560 --> 00:17:39,800
So so from the outside this
would look, but we'll get to
342
00:17:39,800 --> 00:17:41,160
that.
I guess towards the end this
343
00:17:41,160 --> 00:17:43,240
looks like you're closing the
channel and you're just opening
344
00:17:43,240 --> 00:17:46,160
another channel.
But there is magic involved
345
00:17:46,360 --> 00:17:48,320
which means that the existing
channel continues.
346
00:17:48,520 --> 00:17:49,480
Yes.
Yeah.
347
00:17:49,480 --> 00:17:53,040
So let's get there because for
now it would sound like you
348
00:17:53,040 --> 00:17:58,680
can't use the new channel until
the new channel would confirm or
349
00:17:59,120 --> 00:18:01,320
kind of right.
That's that's sort of at least
350
00:18:01,320 --> 00:18:03,640
where my mind is going to when I
hear this.
351
00:18:04,320 --> 00:18:06,240
And yeah, and you're sort of
right.
352
00:18:06,240 --> 00:18:09,680
OK.
Because when we're spending this
353
00:18:09,680 --> 00:18:17,400
funding transaction, we have to
update the states every time a
354
00:18:17,400 --> 00:18:19,560
new payment will come in.
After that, we'll have to update
355
00:18:19,560 --> 00:18:22,360
the states on both of our
channels, like our old channel
356
00:18:22,640 --> 00:18:25,320
and our new channel.
We have to update the states on
357
00:18:25,600 --> 00:18:29,320
on both of them.
Because small note, of course I
358
00:18:29,320 --> 00:18:31,520
would, I would assume, but
please just confirm.
359
00:18:31,800 --> 00:18:35,480
So when you are splicing, this
has to be cooperative between
360
00:18:35,480 --> 00:18:37,600
both parties, right?
This can't be, yeah.
361
00:18:37,600 --> 00:18:39,840
OK, so that's the only way you
can do it.
362
00:18:39,840 --> 00:18:43,040
You have to both agree we're
going to update this channel and
363
00:18:43,040 --> 00:18:46,280
that's how you spend the coins
from the UTXO to the new UTXO.
364
00:18:46,320 --> 00:18:48,480
And then you have to do
duplicate bookkeeping.
365
00:18:48,520 --> 00:18:52,040
Because I guess the the question
is you just made a transaction,
366
00:18:52,200 --> 00:18:54,840
but it's in the men pool and it
may or may not confirm.
367
00:18:54,920 --> 00:18:57,520
If it doesn't confirm, then the
splice never happened.
368
00:18:58,120 --> 00:19:00,760
So you'd better have all the,
you know, all the transactions
369
00:19:00,760 --> 00:19:03,240
that keep happening while your
channel is in this phase you
370
00:19:03,240 --> 00:19:06,600
better remember all those
transactions as if the channel
371
00:19:06,600 --> 00:19:10,280
was never spliced in.
But if it does confirm, well
372
00:19:10,280 --> 00:19:12,600
then the original things didn't
happen.
373
00:19:13,120 --> 00:19:15,080
So somebody could lie, cheat you
that way.
374
00:19:15,080 --> 00:19:18,240
So you really have to to pretend
that you have two identical
375
00:19:18,240 --> 00:19:20,920
channel channels and update them
both at the same time
376
00:19:21,640 --> 00:19:24,000
atomically.
I mean, I am following, but I
377
00:19:24,000 --> 00:19:25,360
also think you're skipping
ahead.
378
00:19:25,400 --> 00:19:28,600
OK.
So let's, I mean, I think what
379
00:19:28,600 --> 00:19:33,720
you say sounds right, but let's
go back to the challenges.
380
00:19:33,720 --> 00:19:35,520
It's not confirmed yet.
Yeah.
381
00:19:35,560 --> 00:19:39,400
So how can you use an
unconfirmed UTXO as a channel
382
00:19:39,400 --> 00:19:41,800
when it's not confirmed?
Isn't that like a risk, right?
383
00:19:42,120 --> 00:19:45,640
If you hook into what source was
saying, then you had an old
384
00:19:45,720 --> 00:19:49,080
channel on chain, right.
And and this channel is on chain
385
00:19:49,120 --> 00:19:51,680
and it has these off chain
commitment transactions.
386
00:19:52,560 --> 00:19:56,560
So these off chain commitments
transactions can be broadcast at
387
00:19:56,560 --> 00:20:01,480
any time and spend our channel
and if that ever happens then
388
00:20:01,480 --> 00:20:03,960
our new spliced in channel
that's in the man pool.
389
00:20:05,080 --> 00:20:07,560
Yeah, will never be the truth.
Right.
390
00:20:07,560 --> 00:20:09,960
That could become a double spend
essentially.
391
00:20:09,960 --> 00:20:13,320
So that could be rejected if one
of the channel states is
392
00:20:13,320 --> 00:20:16,920
broadcast before the splicing
transaction is confirmed, right.
393
00:20:16,920 --> 00:20:18,240
That's that's that's what you
say.
394
00:20:18,240 --> 00:20:20,320
Yeah, OK, I get that.
Yeah, that's what I'm saying,
395
00:20:20,560 --> 00:20:23,240
right.
So that's one of the scenarios.
396
00:20:23,720 --> 00:20:28,480
And the other scenario would be
that eventually our our splicing
397
00:20:28,600 --> 00:20:34,720
transaction confirms and then
and maybe that's closed later as
398
00:20:34,720 --> 00:20:38,600
well, but let's just assume that
the that the splice transaction
399
00:20:38,760 --> 00:20:44,360
confirms.
So what you have to do?
400
00:20:44,520 --> 00:20:46,640
During this period, the problem
with that.
401
00:20:47,080 --> 00:20:50,440
And now let's say I I have you
know, before the splice all the
402
00:20:50,440 --> 00:20:53,080
money was on my side.
A while before the slice all the
403
00:20:53,080 --> 00:20:56,920
money was on my side, but then
it moved to your side and then
404
00:20:56,920 --> 00:21:00,240
we do the splice.
And if the splice then happens
405
00:21:00,240 --> 00:21:03,840
now could I just cheat and like
try to cheat with the original
406
00:21:03,840 --> 00:21:06,320
transaction?
Because all these punishment
407
00:21:06,320 --> 00:21:09,280
transactions that you have won't
work anymore because we have
408
00:21:09,280 --> 00:21:12,880
just created a new on chain
transaction so all these old
409
00:21:12,880 --> 00:21:14,400
penalty transactions don't work
anymore.
410
00:21:14,680 --> 00:21:19,920
So that needs to be solved.
So in the old, you're talking
411
00:21:19,920 --> 00:21:22,520
about the old channel or the?
Yeah, so I I would you know
412
00:21:22,520 --> 00:21:26,360
before can I still cheat with
the transactions from before the
413
00:21:26,360 --> 00:21:28,560
old channel was closed.
I know the answer, but I'm
414
00:21:28,560 --> 00:21:30,320
asking it.
You can still cheat with those,
415
00:21:30,320 --> 00:21:33,240
yes, absolutely.
But you because your peer has
416
00:21:33,280 --> 00:21:38,160
the the revocation key for these
transactions, he can he can then
417
00:21:38,160 --> 00:21:39,760
steal all your money in that
Channel.
418
00:21:40,240 --> 00:21:43,480
So in that case, if you are
stealing from like the old
419
00:21:43,800 --> 00:21:50,960
channel right, then yes, your
commitment transaction will
420
00:21:50,960 --> 00:21:53,080
confirm.
And then, because you were
421
00:21:53,080 --> 00:21:56,960
cheating, I can then spend the
funds in that Channel all for
422
00:21:56,960 --> 00:21:58,600
myself.
But if I understand correctly,
423
00:21:58,600 --> 00:22:02,440
after the splice is confirmed,
then I can no longer cheat with
424
00:22:02,440 --> 00:22:04,560
the old transactions, right?
Because those old cheat
425
00:22:04,560 --> 00:22:07,000
transactions won't work anymore.
Yeah, once.
426
00:22:07,360 --> 00:22:09,920
Yeah, exactly.
Those won't work anymore because
427
00:22:09,920 --> 00:22:13,160
UTXO is spent and.
So it's like you have a blank
428
00:22:13,160 --> 00:22:14,800
slate basically every time you
do this.
429
00:22:15,080 --> 00:22:17,760
Yeah, so once the splice
transaction confirms, you can
430
00:22:17,760 --> 00:22:22,000
actually drop all the old states
that you had in the.
431
00:22:22,200 --> 00:22:24,520
Once it confirms, yeah.
Yeah, once it's deeply
432
00:22:24,520 --> 00:22:26,440
confirmed, basically, yeah,
you're sure that it won't be
433
00:22:26,440 --> 00:22:28,960
reorged out then?
But I think the question we were
434
00:22:28,960 --> 00:22:31,600
still getting at or the answer
we were still getting at is how
435
00:22:31,600 --> 00:22:35,240
can you safely use a channel
before it's confirmed that
436
00:22:35,240 --> 00:22:37,480
that's sort of the, that's the
key question here, right?
437
00:22:37,480 --> 00:22:39,360
And that's, yeah.
And that's I guess the key
438
00:22:39,360 --> 00:22:42,920
question and the trick how we're
doing that is that we are
439
00:22:42,920 --> 00:22:45,560
actually using both channels at
the same time.
440
00:22:45,560 --> 00:22:49,920
We're using every state of day
that we do to the channel.
441
00:22:49,920 --> 00:22:52,920
We're doing them on the old
channel and on the new channel.
442
00:22:53,640 --> 00:22:56,640
So then what happens if I try to
spend more than is in the old
443
00:22:56,640 --> 00:22:57,720
channel?
Yeah.
444
00:22:57,720 --> 00:23:00,880
So that won't work.
During this period you will only
445
00:23:00,880 --> 00:23:03,760
be able to spend.
So if you added funds to the
446
00:23:03,760 --> 00:23:08,440
channel, you will only be able
to spend the the additional
447
00:23:08,440 --> 00:23:12,160
funds after the transaction is
deeply confirmed.
448
00:23:12,320 --> 00:23:16,160
OK, so basically for a while we
have like a quantum channel.
449
00:23:16,960 --> 00:23:19,280
But we have.
It could still go either way and
450
00:23:19,280 --> 00:23:23,040
therefore we're updating both to
keep keep track of each other,
451
00:23:23,040 --> 00:23:26,240
keep them in balance to.
Scare the regulators.
452
00:23:26,360 --> 00:23:29,760
It's a shadow bookkeeping, no?
No, no, it's not.
453
00:23:30,320 --> 00:23:32,360
No, no, it's not shadow
bookkeeping people.
454
00:23:34,080 --> 00:23:37,520
Anyway, so short and I if we're
updating, if we're splicing and
455
00:23:37,520 --> 00:23:40,040
then we keep transaction or
forwarding transactions, blah
456
00:23:40,040 --> 00:23:42,560
blah, we'll keep using lighting
that we're doing everything
457
00:23:42,560 --> 00:23:44,520
double.
We're just updating the old
458
00:23:44,520 --> 00:23:48,160
channel and the new channel
until the new channel is
459
00:23:48,160 --> 00:23:50,960
confirmed on the chain.
Now we can forget about the old
460
00:23:50,960 --> 00:23:52,200
channel.
Now we just have the new
461
00:23:52,200 --> 00:23:53,480
channel.
And while we're waiting, we
462
00:23:53,480 --> 00:23:56,360
cannot use the extra capacity
that was added because we have
463
00:23:56,360 --> 00:23:58,240
to take into account the
smallest of the two.
464
00:23:58,400 --> 00:23:59,640
Right.
The smallest of the two, yeah.
465
00:23:59,640 --> 00:24:01,000
OK.
Because you could also have
466
00:24:01,040 --> 00:24:04,560
removed funds and then it's
basically the the new lower
467
00:24:04,560 --> 00:24:06,360
balance that is the that's the
limit there.
468
00:24:06,520 --> 00:24:08,560
OK.
Well, that sounds actually kind
469
00:24:08,560 --> 00:24:12,400
of straightforward to me, but I
would imagine there's a lot more
470
00:24:12,560 --> 00:24:14,480
sort of nitty gritty to like.
How?
471
00:24:14,480 --> 00:24:17,120
How does the rest of the
network, for example, know that
472
00:24:17,120 --> 00:24:20,760
this is the same channel rather
than a complete new channel?
473
00:24:20,760 --> 00:24:23,960
Do they need to know they need
to have the routing information
474
00:24:23,960 --> 00:24:24,720
for example?
I would.
475
00:24:24,920 --> 00:24:27,040
I would say they need to have
the routing information, but
476
00:24:27,040 --> 00:24:30,280
they they won't know that this
is the same channel.
477
00:24:31,240 --> 00:24:34,440
OK, they'll they'll consider it
a different channel.
478
00:24:34,920 --> 00:24:37,720
They'll consider it a different
channel, but there is a there is
479
00:24:37,720 --> 00:24:41,360
a little thing there and maybe
we can skip to that now because
480
00:24:41,360 --> 00:24:46,240
in in your old channel with
gossip through the gossip
481
00:24:46,240 --> 00:24:50,920
network and like it's a sender
that wants to route through your
482
00:24:50,920 --> 00:24:56,240
channel, he has a graph of the
of the lightning network on his
483
00:24:56,240 --> 00:25:00,440
local node and he had that
Channel inside his graph, right?
484
00:25:01,040 --> 00:25:05,840
And as soon as you spend the
channel on chain, he would you
485
00:25:05,840 --> 00:25:07,520
would consider that Channel
closed.
486
00:25:08,120 --> 00:25:12,720
So now the sender wouldn't be
able to know wouldn't be able to
487
00:25:12,720 --> 00:25:15,200
use your channel because he
thinks it's closed and the the
488
00:25:15,200 --> 00:25:17,080
splice transaction hadn't
confirmed yet.
489
00:25:18,440 --> 00:25:23,880
So in the bolts there is.
A Bolt means improvement for
490
00:25:23,880 --> 00:25:26,760
lightning.
Yes, basics of lightning.
491
00:25:26,840 --> 00:25:30,200
Basis of lightning technology.
It's basically a bit for
492
00:25:30,200 --> 00:25:34,640
lightning.
Yeah, and there to say that once
493
00:25:34,640 --> 00:25:39,000
the channel closes on chain, you
should wait now for 12 blocks
494
00:25:39,160 --> 00:25:42,240
before you actually remove this
channel from your channel graph.
495
00:25:43,360 --> 00:25:47,760
And because we're doing this now
for these twelve blocks, we
496
00:25:47,760 --> 00:25:54,720
would still be able to be trying
the old channel, and after the
497
00:25:55,080 --> 00:25:59,240
the the splice transaction
confirms, gossip will probably
498
00:25:59,240 --> 00:26:04,160
reach us in time to to make us
learn about the new channel.
499
00:26:04,840 --> 00:26:06,600
Probably it will happen almost
immediately, right?
500
00:26:06,600 --> 00:26:09,840
Because the moment the the
moment the splice confirms is
501
00:26:09,840 --> 00:26:12,720
the moment that other nodes,
when they see that block, they
502
00:26:12,720 --> 00:26:18,440
all think that Channel is gone.
But at that point the gossip is
503
00:26:18,440 --> 00:26:21,720
being is being spread that there
is a new channel in town.
504
00:26:22,320 --> 00:26:24,440
And so there might be a few
seconds in between those two
505
00:26:24,440 --> 00:26:27,040
moments, but for those seconds
you don't want to think that the
506
00:26:27,040 --> 00:26:29,520
channel is gone.
But what's the benefit of
507
00:26:29,520 --> 00:26:34,000
keeping the old channel in like
memory for 12 blocks?
508
00:26:34,000 --> 00:26:38,880
Like if you if you try to use it
will these pairs themselves just
509
00:26:38,880 --> 00:26:41,560
figure, Oh well that Channel
doesn't exist, but we have a new
510
00:26:41,560 --> 00:26:43,640
one we updated.
They'll just figure it out.
511
00:26:43,680 --> 00:26:45,960
That's the way the double
bookkeeping comes in, right?
512
00:26:46,280 --> 00:26:49,320
They see a transaction for the
old channel, but they'll honor
513
00:26:49,320 --> 00:26:51,560
it for the new channel.
But I guess this is after
514
00:26:51,560 --> 00:26:54,440
confirmation, so there's another
trick for that then.
515
00:26:55,240 --> 00:26:56,160
Yes.
We're at.
516
00:26:56,160 --> 00:26:57,800
We're talking after
confirmation, yes.
517
00:26:58,000 --> 00:26:59,640
So we're talking after
confirmation.
518
00:26:59,640 --> 00:27:03,000
Peers smart enough to just
forward it anyways.
519
00:27:04,280 --> 00:27:05,720
Which peer are you talking about
right now?
520
00:27:05,720 --> 00:27:09,560
So I'm trying to pay you.
Yes Sir.
521
00:27:10,360 --> 00:27:14,040
And I see that you have a
channel with yours and you guys
522
00:27:14,040 --> 00:27:17,360
just spliced and it's confirmed
and I have a channel with yours.
523
00:27:17,760 --> 00:27:20,440
So now it's still in my memory
that you had the old one.
524
00:27:20,440 --> 00:27:22,880
So now I'm trying to send it to
you through yours.
525
00:27:23,280 --> 00:27:27,160
Is yours smart?
Is your smart enough to figure
526
00:27:27,160 --> 00:27:30,280
out that he has this channel
with you still, even though I
527
00:27:30,280 --> 00:27:32,320
was not, Yeah, sure she.
Stopped the double.
528
00:27:32,320 --> 00:27:33,440
Bookkeeping, right.
Yeah.
529
00:27:33,880 --> 00:27:36,040
Yeah, yes, shorts will be smart
enough to.
530
00:27:36,040 --> 00:27:38,640
Do that I I could have known
that shorts was smart enough for
531
00:27:38,840 --> 00:27:39,880
that.
Well done, shorts.
532
00:27:40,320 --> 00:27:41,120
Thank you.
Thank you.
533
00:27:42,240 --> 00:27:44,040
OK, that that answers that
question.
534
00:27:44,920 --> 00:27:46,720
OK.
So that's why it sticks in
535
00:27:46,720 --> 00:27:50,200
memory for essentially 1212
confirmations.
536
00:27:50,200 --> 00:27:52,960
Yeah, yeah, yeah, right.
Now I think we need to go back a
537
00:27:52,960 --> 00:27:59,240
little bit to talk about
something fundamental underway.
538
00:27:59,560 --> 00:28:01,120
Yeah, something in the
fundamental is underway.
539
00:28:01,120 --> 00:28:05,920
So the way a splice begins, we
want to make sure that there's
540
00:28:05,920 --> 00:28:09,120
no funky stuff going on in our
channel while we're doing all
541
00:28:09,120 --> 00:28:12,480
this complicated business
initiating a new splice.
542
00:28:12,520 --> 00:28:14,000
Yeah.
So it's not this, this time that
543
00:28:14,000 --> 00:28:18,000
it's confirming in the men pool.
It's really the time between we
544
00:28:18,000 --> 00:28:21,480
like the splice and the moment
we submit a transaction to the
545
00:28:21,480 --> 00:28:24,160
rest of the network.
And that that period of time is
546
00:28:24,160 --> 00:28:26,400
like a second.
Yeah, to the outside world, but
547
00:28:26,400 --> 00:28:29,600
to computers, that is an
eternity in which many, many
548
00:28:29,600 --> 00:28:32,040
things can go wrong in that in
that one very second.
549
00:28:32,040 --> 00:28:35,880
Yeah, like the funky stuff.
I meant adding ACL CS basically
550
00:28:35,880 --> 00:28:38,000
to your channel or removing ACL
CS.
551
00:28:38,000 --> 00:28:40,560
So we're in the middle of a
conversation about building a
552
00:28:40,560 --> 00:28:41,640
splice.
It's a very intense
553
00:28:41,640 --> 00:28:43,600
conversation.
And then Aaron comes in.
554
00:28:43,600 --> 00:28:44,760
It's like, please forward this
for me.
555
00:28:45,040 --> 00:28:47,800
And we're like, no, no, no, not
right now.
556
00:28:47,960 --> 00:28:50,160
Come back in.
This is complicated enough,
557
00:28:50,200 --> 00:28:53,360
isn't it?
In 1,000,000 microseconds, yeah.
558
00:28:53,760 --> 00:28:56,680
I found back at .6 seconds.
So I.
559
00:28:56,680 --> 00:28:59,120
Don't have that that type of
time source.
560
00:28:59,120 --> 00:29:01,360
No, so you would see your
transaction fail.
561
00:29:01,360 --> 00:29:04,520
Basically, I'll, I'll, I'll go
somewhere else if you don't want
562
00:29:04,520 --> 00:29:07,360
to help me within 6 seconds.
All right.
563
00:29:07,360 --> 00:29:09,360
Got it.
OK, so that's what that OK, so
564
00:29:10,240 --> 00:29:13,920
the actual time that it takes to
say, hey, do you want a splice?
565
00:29:13,920 --> 00:29:16,960
Yeah, I want a splice.
Let's splice in that time.
566
00:29:16,960 --> 00:29:19,840
You can't route that.
That's the The computers can't
567
00:29:19,840 --> 00:29:22,320
route in that.
Time the computer can route so
568
00:29:22,760 --> 00:29:26,040
and that's because we initiated
a quiescence.
569
00:29:27,600 --> 00:29:29,800
How do you pronounce that?
We googled it and we believe it
570
00:29:29,800 --> 00:29:34,200
is quiescence, quiescence or
quiescence, I guess if you're
571
00:29:34,200 --> 00:29:36,440
American.
When I read it, I thought it was
572
00:29:36,440 --> 00:29:39,080
quiescence.
But yeah, Internet says
573
00:29:39,080 --> 00:29:43,760
quiescence.
So, so you send the STFU message
574
00:29:43,760 --> 00:29:47,680
to your peer.
Is this an actual term?
575
00:29:47,680 --> 00:29:50,120
This is the actual term it says
it stands for.
576
00:29:50,120 --> 00:29:51,840
Something fundamental is
underway.
577
00:29:52,000 --> 00:29:52,480
Yes.
Do you?
578
00:29:52,600 --> 00:29:54,800
Do you have children listening?
Do not Google these letters.
579
00:29:56,320 --> 00:29:58,760
And and then your period sends
back.
580
00:29:58,760 --> 00:30:00,520
Now that doesn't that doesn't
add up.
581
00:30:00,520 --> 00:30:03,320
You said SFTU and it stands for
what?
582
00:30:03,560 --> 00:30:07,480
Something fundamental
fundamental is underway.
583
00:30:07,480 --> 00:30:09,480
Oh my God.
Something.
584
00:30:09,480 --> 00:30:10,440
Yeah.
OK.
585
00:30:10,520 --> 00:30:12,760
Yeah.
Anyways, enough.
586
00:30:14,200 --> 00:30:15,360
And keep it.
Straight what?
587
00:30:15,360 --> 00:30:17,400
What were you saying something
fundamental is on?
588
00:30:17,400 --> 00:30:20,400
The way, yeah, So what we're
saying is now we're going to
589
00:30:20,400 --> 00:30:22,680
quiescence mode and now we're
we're not going to update our
590
00:30:22,680 --> 00:30:26,960
channel until we're finished
negotiating the splice.
591
00:30:27,200 --> 00:30:29,000
OK.
Then we're going to say to
592
00:30:29,000 --> 00:30:33,720
appear like, OK, I want to do a
splice for this extra amount and
593
00:30:33,720 --> 00:30:37,040
for this fee rate.
And what we're then going to do
594
00:30:37,040 --> 00:30:39,720
is we're going to start the
interactive transaction
595
00:30:39,720 --> 00:30:43,600
construction protocol and
that's, yeah, that's a new
596
00:30:43,600 --> 00:30:48,400
protocol that's been merged into
the BOLT specs last month.
597
00:30:49,080 --> 00:30:51,680
Oh, very new.
Yeah, very new.
598
00:30:51,840 --> 00:30:55,760
So because it's merged in the
Bolt spec, that means that two
599
00:30:55,840 --> 00:30:59,360
at least two implementations
implemented that already.
600
00:31:01,840 --> 00:31:04,520
And with this, it's basically
what it does.
601
00:31:04,520 --> 00:31:08,440
It's, you say like add an output
to this transaction, add an
602
00:31:08,440 --> 00:31:11,120
input to this transaction,
remove an output, remove an
603
00:31:11,120 --> 00:31:14,320
input, and you're going to
negotiate what the new funding
604
00:31:14,320 --> 00:31:16,560
transaction will look like.
Right.
605
00:31:17,040 --> 00:31:19,520
And I guess this is different
from how things worked before,
606
00:31:19,520 --> 00:31:21,960
where one site would just say
this is going to be the
607
00:31:21,960 --> 00:31:26,040
transaction like it or or or
don't like it, just sign it.
608
00:31:26,880 --> 00:31:29,120
And now this is a more
sophisticated conversation.
609
00:31:29,200 --> 00:31:32,640
Yes, does.
It does it use PSBT?
610
00:31:32,840 --> 00:31:34,440
It uses.
PSPT Yeah, cool.
611
00:31:34,440 --> 00:31:37,520
We did an episode about that.
Long time ago.
612
00:31:39,040 --> 00:31:41,480
And so this Interactive
Transaction Transaction
613
00:31:41,800 --> 00:31:45,360
Construction Protocol is also
using a new protocol and the
614
00:31:45,360 --> 00:31:50,760
ball is called Open Channel V2,
and that's a version two of the
615
00:31:50,800 --> 00:31:55,400
Opening Channel protocol.
And that also allows for RBF,
616
00:31:57,200 --> 00:32:00,960
which means that splices also
allow for RBF.
617
00:32:01,000 --> 00:32:03,760
And so does anybody who would
use this for opening a new
618
00:32:03,760 --> 00:32:05,840
channel, because in theory you
could use it for that too, Could
619
00:32:05,840 --> 00:32:08,200
now also use RBF, right?
Yeah.
620
00:32:08,720 --> 00:32:09,360
It's not.
I don't.
621
00:32:09,480 --> 00:32:11,040
I think you said nobody's
implemented it.
622
00:32:11,120 --> 00:32:13,200
Yeah.
So I think nobody's implemented
623
00:32:13,200 --> 00:32:16,240
it for normal channel opens yet.
But I can imagine it's very
624
00:32:16,240 --> 00:32:17,920
useful for a zero confirmation
channel.
625
00:32:17,920 --> 00:32:20,840
For example, where a service
provider opens the channel to
626
00:32:20,840 --> 00:32:23,960
you, you know there's some
wallets that will give you a
627
00:32:23,960 --> 00:32:25,440
zero confirmation channel
briefly.
628
00:32:26,480 --> 00:32:29,120
That's a risk you're taking as
the recipient.
629
00:32:30,560 --> 00:32:32,960
And then they might say, well
we're just going to pay 1
630
00:32:32,960 --> 00:32:36,560
satoshi per fee byte.
And then if we start worrying as
631
00:32:36,560 --> 00:32:39,760
a service provider, then we'll
just increase the fee to make
632
00:32:39,760 --> 00:32:41,400
sure that it confirms.
Right.
633
00:32:41,400 --> 00:32:43,000
Yeah.
And and it makes sense in any
634
00:32:43,000 --> 00:32:46,280
situation to be able to RBF a
transaction and you've seen that
635
00:32:47,000 --> 00:32:51,200
in the last periods where the
fee raised were changing a lot,
636
00:32:51,200 --> 00:32:52,920
right.
So the fee raised are increasing
637
00:32:52,920 --> 00:32:54,960
a lot.
Then you definitely run into
638
00:32:54,960 --> 00:32:59,360
problems of channels not
confirming and after two weeks
639
00:32:59,520 --> 00:33:04,440
then your peer forgets about the
channel altogether and so your
640
00:33:04,440 --> 00:33:06,640
your funding transaction will be
worthless.
641
00:33:07,040 --> 00:33:08,640
Right.
So that's cool.
642
00:33:08,640 --> 00:33:11,320
Features in the in the in the
boltz pack as well.
643
00:33:11,720 --> 00:33:14,960
OK.
So now that we've negotiated the
644
00:33:14,960 --> 00:33:20,120
transaction and after
negotiating transaction, we
645
00:33:20,120 --> 00:33:23,080
exchanged signatures for this
transaction and once we've
646
00:33:23,280 --> 00:33:28,560
negotiated signatures then, then
we're out of quiescence mode.
647
00:33:28,760 --> 00:33:30,280
Yeah.
And then the double bookkeeping
648
00:33:30,280 --> 00:33:32,680
starts basically.
Then then the splice in which we
649
00:33:32,680 --> 00:33:36,360
discussed starts.
Yes, until the new transaction
650
00:33:36,360 --> 00:33:38,720
is confirmed.
Yes, until the new transaction
651
00:33:38,720 --> 00:33:42,040
is confirmed or if you if it's
like a 0 conf channel.
652
00:33:42,800 --> 00:33:45,000
So a channel that doesn't need
any core informations.
653
00:33:45,320 --> 00:33:47,680
Basically you will be instantly
be able to use the.
654
00:33:47,800 --> 00:33:49,960
Oh, that's also possible.
Yeah, that's possible.
655
00:33:49,960 --> 00:33:54,880
Like if you if if you have a
channel with shores and you
656
00:33:54,880 --> 00:33:58,840
trust shores that he won't
double spend your channel, you
657
00:33:58,840 --> 00:34:01,800
could yeah you could do a 0 conf
channel right right, right
658
00:34:01,800 --> 00:34:05,680
shorespace.
OK, is this Does this cover
659
00:34:05,680 --> 00:34:08,719
splicing?
I want to ask you who's
660
00:34:08,719 --> 00:34:11,719
implemented, but unless there's
something more to say, like
661
00:34:11,880 --> 00:34:14,120
yeah, about the technical
details.
662
00:34:14,880 --> 00:34:17,840
Yeah, I think it covers most of
the technical details, yeah.
663
00:34:17,920 --> 00:34:23,000
OK, yeah, so splicing was not in
lighting since day one,
664
00:34:23,159 --> 00:34:28,400
obviously, right?
But still now it's not like a
665
00:34:28,400 --> 00:34:31,560
standard thing, right?
It's still work in progress, but
666
00:34:31,560 --> 00:34:33,920
there are implementations that
have this or what?
667
00:34:33,920 --> 00:34:35,800
What's the status of splicing?
Yeah.
668
00:34:35,800 --> 00:34:38,760
So the spec is still a work in
progress, and it's still being
669
00:34:38,760 --> 00:34:41,719
negotiated exactly how how the
spec should look.
670
00:34:41,719 --> 00:34:44,480
Like or even the spec is still
open for discussion.
671
00:34:44,480 --> 00:34:47,840
Yeah there's a few things in the
spec like how many confirmations
672
00:34:47,840 --> 00:34:50,920
the splice has, like you should
be able to negotiate the
673
00:34:51,440 --> 00:34:53,920
confirmations before the splice
is logged.
674
00:34:55,520 --> 00:34:57,880
There's also for the gossip
protocol.
675
00:34:57,880 --> 00:35:02,080
Maybe they want to add a feature
bits to the gossip messages
676
00:35:02,080 --> 00:35:05,360
saying oh this channel is a
splice channel and then yeah
677
00:35:05,360 --> 00:35:08,880
there's a few like a bit more
minor things.
678
00:35:08,880 --> 00:35:14,720
And one of the bigger things is
in a channel you have a channel
679
00:35:14,720 --> 00:35:19,000
reserve.
So 1% of your of each side of
680
00:35:19,000 --> 00:35:24,320
the channel has each side of the
channel has 1% of the channel
681
00:35:24,320 --> 00:35:28,960
capacity as reserve and you're
not allowed to spend this 1% in
682
00:35:28,960 --> 00:35:40,120
in the channel and so that why
because you always want your
683
00:35:40,120 --> 00:35:44,160
peer to have something to lose.
You always want to be able to,
684
00:35:44,920 --> 00:35:46,960
yeah, punish your peer.
You want to be able to punish
685
00:35:46,960 --> 00:35:48,200
you.
Want to inflict pain on your
686
00:35:48,200 --> 00:35:49,520
peer?
Potentially, yes.
687
00:35:49,520 --> 00:35:52,560
OK, so and 1%.
So this is true for all
688
00:35:52,560 --> 00:35:55,360
lightning channels.
Yeah, basically all lightning
689
00:35:55,360 --> 00:35:59,000
channels, yeah.
And and I work, I I work for
690
00:35:59,000 --> 00:36:01,800
Breeze.
But with Breeze the the clients
691
00:36:01,800 --> 00:36:05,800
don't have a general reserve
because with Breeze we know like
692
00:36:05,800 --> 00:36:09,520
we are always online.
So you basically wouldn't be
693
00:36:09,520 --> 00:36:13,000
able to cheat us even if you
tried because we have like a two
694
00:36:13,000 --> 00:36:15,560
week period in which we can
broadcast and transactional
695
00:36:15,560 --> 00:36:17,520
change.
So we we're all right with that.
696
00:36:18,200 --> 00:36:21,760
So you could configure that but.
But generally speaking, every
697
00:36:21,760 --> 00:36:25,560
lighting channel has needs at
least 1% for each pair.
698
00:36:25,760 --> 00:36:30,320
Yeah, but you can open a channel
with one 100% on one side,
699
00:36:30,320 --> 00:36:31,120
right?
Yeah.
700
00:36:31,120 --> 00:36:34,160
So this is an exception to the
rule, like once you've opened
701
00:36:34,160 --> 00:36:36,680
the channel, all the funds here
on your side.
702
00:36:36,680 --> 00:36:39,840
So your pair won't have the 1%
yet, but as soon as you send
703
00:36:39,840 --> 00:36:43,520
something to the other side then
they won't be able to spend that
704
00:36:43,520 --> 00:36:45,800
1%.
As soon as the other pair has 1%
705
00:36:45,800 --> 00:36:47,960
that, that needs to be stuck
there essentially.
706
00:36:48,040 --> 00:36:49,120
Yeah, OK.
Yeah.
707
00:36:49,560 --> 00:36:53,080
But there's so now there's an
issue with splicing because
708
00:36:54,320 --> 00:36:58,960
let's say Alan, we have we have
lightning channel and and now I
709
00:36:58,960 --> 00:37:02,840
decide to add a huge amount of
funds on my side of the channel.
710
00:37:04,120 --> 00:37:08,480
Now you're part of the channel
dips below that one drops.
711
00:37:09,040 --> 00:37:09,720
Yeah.
Reserve.
712
00:37:09,720 --> 00:37:12,600
So they're still discussing
like, how how should we handle
713
00:37:12,600 --> 00:37:14,320
this?
OK, this is still part of the
714
00:37:14,320 --> 00:37:18,160
discussion of the spec and it it
there's no real, so are there.
715
00:37:18,400 --> 00:37:21,520
So if the spec is still being
discussed and I would think
716
00:37:21,520 --> 00:37:24,280
there's no implementation that
has splicing yet.
717
00:37:24,280 --> 00:37:26,800
Or are there?
Yeah, there are implementations
718
00:37:26,800 --> 00:37:29,520
that have splicing.
You've got the Esseng team,
719
00:37:29,520 --> 00:37:33,760
they've implemented splicing in
Eclair and in Phoenix.
720
00:37:34,240 --> 00:37:38,520
OK.
You've got the LDKLDK as
721
00:37:39,000 --> 00:37:42,880
Splicing Sport and Core
Lightning as Splicing Sport as
722
00:37:43,080 --> 00:37:44,720
experimental feature.
OK.
723
00:37:44,720 --> 00:37:46,640
And are these all compatible
with each other?
724
00:37:47,000 --> 00:37:50,560
Compatibility is part.
It's sort of happening now like
725
00:37:50,560 --> 00:37:55,040
this is the the period that
people will start compatibility
726
00:37:55,040 --> 00:37:55,880
testing.
And right.
727
00:37:55,880 --> 00:37:57,760
What about Breeze?
And so the rule is.
728
00:37:57,760 --> 00:38:02,440
We're working on this.
Oh, so the rule is that once two
729
00:38:02,440 --> 00:38:06,160
different implementations are
compatible, that's when a spec
730
00:38:07,000 --> 00:38:10,240
is final or can be made final.
Yeah, but there needs to be at
731
00:38:10,240 --> 00:38:12,320
least two different
implementations that are
732
00:38:12,640 --> 00:38:14,600
compatible and the only way to
find out if things are
733
00:38:14,600 --> 00:38:17,240
compatible is to actually build
it because that's how you run
734
00:38:17,240 --> 00:38:19,960
into the things you did not
think about in the design.
735
00:38:20,640 --> 00:38:22,280
So I think that's a a sane
strategy.
736
00:38:22,280 --> 00:38:24,320
But the problem is, and I think
we've talked about that in
737
00:38:24,320 --> 00:38:30,520
earlier episodes, different
Lightning projects like LMD or
738
00:38:30,520 --> 00:38:33,600
Core Lightning or whoever, they
all have their own priorities.
739
00:38:34,320 --> 00:38:37,360
And so if they all have their,
if they all literally have just
740
00:38:37,360 --> 00:38:40,080
one pet project and they don't
pay attention to any of the
741
00:38:40,080 --> 00:38:42,640
other projects, then nothing
happens because there's never
742
00:38:42,640 --> 00:38:45,560
two different implementations.
And this is one reason why
743
00:38:45,560 --> 00:38:48,000
things can take a while.
You need to have two, at least
744
00:38:48,000 --> 00:38:51,560
two that happen to have the same
priority, but there's no
745
00:38:51,880 --> 00:38:54,400
Lightning CEO out there.
No, exactly.
746
00:38:55,120 --> 00:38:58,240
And yeah, by the way, L&D also
has it on the road map for
747
00:38:58,480 --> 00:39:02,600
somewhere in the future.
Yeah, I thought they had it
748
00:39:02,600 --> 00:39:04,600
years ago, but apparently I'm
just wrong about that.
749
00:39:04,720 --> 00:39:07,720
I I I remember writing an
article that maybe it was like
750
00:39:07,720 --> 00:39:10,440
one of these articles about
what's in store for the future
751
00:39:10,440 --> 00:39:12,800
of lightning that I wrote like
five years ago.
752
00:39:12,800 --> 00:39:14,560
I don't.
Yeah, yeah, eventually.
753
00:39:14,720 --> 00:39:16,600
Like it's still the same things
in the store.
754
00:39:16,640 --> 00:39:21,960
Right, they seem to stick in in
production for a while.
755
00:39:22,080 --> 00:39:23,720
Yeah.
And and I guess one observation
756
00:39:23,720 --> 00:39:28,120
I could make is that the reason
why Phoenix can use Lightning in
757
00:39:28,120 --> 00:39:31,360
the wild, because they really
are shipping it as part of their
758
00:39:32,800 --> 00:39:36,800
tap swap.
Is it tap swap swap root?
759
00:39:36,880 --> 00:39:40,720
Oh yeah, swap root protocol,
which is swapping and using
760
00:39:40,720 --> 00:39:43,160
taproot and using music and
other other cool stuff.
761
00:39:44,080 --> 00:39:48,360
They can use that in a while
because their wallets Only
762
00:39:48,360 --> 00:39:53,240
Connect to the Eclair node.
And so even though you know the
763
00:39:53,240 --> 00:39:55,680
spec is not completely flashed
out, they they have control over
764
00:39:55,680 --> 00:39:56,960
which nodes you're connecting
to.
765
00:39:57,240 --> 00:40:00,360
So the app is is not going to
break even if it's not
766
00:40:00,360 --> 00:40:02,560
completely following the spec
yet because the spec is still
767
00:40:02,560 --> 00:40:06,240
being changed.
Now I assume they have thought
768
00:40:06,240 --> 00:40:09,200
about, you know, safety because
everybody can.
769
00:40:09,920 --> 00:40:12,480
You know, it's open source, the
Phoenix app, so you can look at
770
00:40:12,480 --> 00:40:15,280
it and see how it works and you
can change it and make it
771
00:40:15,280 --> 00:40:17,920
misbehave.
And presumably they've made, you
772
00:40:17,920 --> 00:40:20,640
know, they've made it strong
enough that it will survive
773
00:40:20,640 --> 00:40:24,360
abuse, but it may not be
compatible yet with other notes.
774
00:40:25,320 --> 00:40:28,480
Exactly that, yeah.
Can you splice from a splice?
775
00:40:29,040 --> 00:40:30,680
Yeah, you can splice from a
splice.
776
00:40:30,680 --> 00:40:31,360
You can.
You can.
777
00:40:31,920 --> 00:40:34,560
Yeah.
You can have a chain of
778
00:40:34,760 --> 00:40:38,840
unconfirmed splices.
And yeah, So what happens then
779
00:40:38,840 --> 00:40:41,600
is then you have a transaction
that spends A transaction that
780
00:40:41,600 --> 00:40:43,680
spends A transaction that spends
a transaction.
781
00:40:43,680 --> 00:40:45,720
But they have to all confirm on
chain.
782
00:40:46,880 --> 00:40:48,080
Yeah, yeah.
Yeah.
783
00:40:48,080 --> 00:40:50,440
Basically, they should
eventually confirm on chain
784
00:40:50,640 --> 00:40:52,320
because.
I think one question we hoped
785
00:40:52,320 --> 00:40:55,920
you would be able to answer is
can you change the splice?
786
00:40:56,480 --> 00:40:58,960
Can you splice the splice that
is in progress but not confirm?
787
00:40:58,960 --> 00:41:01,880
We know we can RBF it, so we can
increase the fee of the splice,
788
00:41:02,440 --> 00:41:04,480
but could we also change the
size of the splice?
789
00:41:04,480 --> 00:41:06,960
That should work right?
Like that would be better that
790
00:41:06,960 --> 00:41:09,120
way that way?
It sounds like the spec would be
791
00:41:09,120 --> 00:41:11,840
even more complicated.
So I think that should work in
792
00:41:11,840 --> 00:41:14,280
some circumstances.
But yeah, you do fall into
793
00:41:14,440 --> 00:41:16,480
issues with the will the man
pool.
794
00:41:16,480 --> 00:41:20,760
Except yeah yeah yeah my new RBF
splice.
795
00:41:20,760 --> 00:41:24,520
So yeah, I I'm not sure how
implementations do this, where
796
00:41:24,520 --> 00:41:26,160
where the restrictions are in
this.
797
00:41:26,680 --> 00:41:28,920
OK, well, that's getting a bit
into the weeds.
798
00:41:29,000 --> 00:41:31,720
But, but the one thing I wanted
to say about these chains of
799
00:41:31,720 --> 00:41:35,440
unconfirmed splices is that,
yeah, well, then you have to,
800
00:41:35,760 --> 00:41:40,360
for every channel update, you
have to update all of these.
801
00:41:40,640 --> 00:41:42,000
And the same goes for RBF,
right?
802
00:41:42,000 --> 00:41:43,840
Every time you RBF you have to
update everything?
803
00:41:43,840 --> 00:41:47,320
Or is RBF done more efficiently?
Yeah, with the RBF, exactly.
804
00:41:47,320 --> 00:41:48,080
That's the same.
Yeah.
805
00:41:48,080 --> 00:41:52,200
So every time your RBF is
basically like a new, a new
806
00:41:52,200 --> 00:41:53,600
splice.
So you have to yeah, you.
807
00:41:53,840 --> 00:41:57,120
Have to have 1010 times the
number of you have to every
808
00:41:57,120 --> 00:41:59,720
transaction you make.
Every HDLC you forward, you have
809
00:41:59,720 --> 00:42:01,600
to keep track of it in 10
different ways.
810
00:42:01,880 --> 00:42:02,800
Yes.
Yep.
811
00:42:03,160 --> 00:42:06,880
Right, OK, I think that kind of
covers it because we're getting
812
00:42:06,880 --> 00:42:10,240
into weird weights now, so I
would assume that the main
813
00:42:10,240 --> 00:42:12,080
splicing topic has been covered
now, right?
814
00:42:12,080 --> 00:42:14,440
Did we miss anything?
No, we we got it all.
815
00:42:14,960 --> 00:42:17,040
OK, awesome.
Well, yes, Sir, thanks for
816
00:42:17,040 --> 00:42:19,360
coming back.
Do you want to pitch where
817
00:42:19,360 --> 00:42:20,960
people can find you or something
like that?
818
00:42:21,240 --> 00:42:23,600
People can find me on Twitter
and on Nasser.
819
00:42:23,600 --> 00:42:25,480
I bet it's going to be in the
show notes.
820
00:42:25,480 --> 00:42:27,520
It will be I.
I will put it in the show notes.
821
00:42:27,520 --> 00:42:28,120
Yeah, all.
Right.
822
00:42:28,120 --> 00:42:30,120
Then, Ivan, do you have anything
to add?
823
00:42:31,320 --> 00:42:33,200
No.
I'll see you soon.
824
00:42:33,200 --> 00:42:34,400
Sure.
All right, then.
825
00:42:34,400 --> 00:42:36,200
Thank you for listening to
Bitcoin.
826
00:42:36,480 --> 00:42:37,280
Explain.