Episode 97: Bitcoin Core 29

1
00:00:16,720 --> 00:00:19,280
Life from address.
This is Bitcoin.
2
00:00:19,440 --> 00:00:23,840
Explained as yours.
Hello, Welcome back, welcome
3
00:00:23,840 --> 00:00:25,120
back.
It's just been a few days.
4
00:00:25,880 --> 00:00:29,800
Yeah, well this this episode is
delayed by like 2 weeks.
5
00:00:30,040 --> 00:00:35,240
We were supposed to record this
at MIT in Massachusetts at
6
00:00:35,360 --> 00:00:37,760
Bitcoin Expo, which you did
attend.
7
00:00:38,200 --> 00:00:43,800
I did attend it and I did joined
some panels there, but we
8
00:00:43,800 --> 00:00:46,200
couldn't do the podcast.
Yeah, we were supposed to do the
9
00:00:46,200 --> 00:00:48,880
podcast on stage.
Big, big spectacle.
10
00:00:48,880 --> 00:00:50,960
But but.
You got deported to El Salvador
11
00:00:50,960 --> 00:00:53,320
and like, it was complicated to
get you out there and.
12
00:00:53,640 --> 00:00:56,560
It was a, It's a, It was a Long
story short, I'm surprised you
13
00:00:56,560 --> 00:00:58,600
didn't get deported to El
Salvador.
14
00:00:59,080 --> 00:01:01,560
I'm happy.
You, you look like MS13.
15
00:01:01,880 --> 00:01:04,280
That's, I mean, that's what
people usually say when I say,
16
00:01:04,800 --> 00:01:07,600
yeah, I record podcasts with
shorts and they say, oh, that's
17
00:01:07,600 --> 00:01:10,480
the MS13 guy.
And I have to explain, no, no,
18
00:01:10,480 --> 00:01:13,640
he just looks like that.
He's actually a bit of a core
19
00:01:13,640 --> 00:01:16,320
developer.
All right, well.
20
00:01:17,160 --> 00:01:19,680
Somehow you made it back.
I made it back.
21
00:01:20,240 --> 00:01:24,240
So we're going to record an
episode on Bitcoin Core 29.
22
00:01:24,440 --> 00:01:27,080
That's right.
Which means it's been about six
23
00:01:27,080 --> 00:01:29,160
months since the previous
Bitcoin release.
24
00:01:29,520 --> 00:01:33,920
That's right.
And as usual, that means there's
25
00:01:33,920 --> 00:01:36,840
some new futures which we're
going to discuss.
26
00:01:37,400 --> 00:01:41,440
Yep, that's right.
Let's let's just get into it.
27
00:01:42,320 --> 00:01:44,760
What's up?
Oh yeah, we have a sponsor.
28
00:01:45,160 --> 00:01:48,120
That's right.
We are being sponsored by a very
29
00:01:48,120 --> 00:01:53,560
generous contributors to the
show Coin Kite who produce the
30
00:01:53,560 --> 00:01:57,040
Coles Cart hardware wallet.
Right now I'm holding the.
31
00:01:57,440 --> 00:02:00,880
I think it's called the Q.
Cold cart Q which looks like a
32
00:02:01,280 --> 00:02:03,600
big calculator.
Or BlackBerry.
33
00:02:05,280 --> 00:02:06,640
You can store your Bitcoin on
it.
34
00:02:08,199 --> 00:02:10,440
Have you actually used it or is
it just laying around here?
35
00:02:11,000 --> 00:02:14,400
This one, yeah, I'm not going to
answer that question.
36
00:02:15,520 --> 00:02:18,280
Smart.
I'll take that as a yes.
37
00:02:19,680 --> 00:02:20,920
I will check that it's still
here.
38
00:02:22,320 --> 00:02:26,880
All right, so there's a new
bicolor release and then what
39
00:02:27,120 --> 00:02:29,440
we're going to do is we're going
to highlight some futures that
40
00:02:29,440 --> 00:02:32,440
are in this bicolor release
that, you know, there's a bunch
41
00:02:32,440 --> 00:02:35,640
of futures including buck fixes
and you know, all kinds of
42
00:02:35,640 --> 00:02:37,680
smaller stuff.
But we we highlighted some
43
00:02:37,680 --> 00:02:41,080
futures that are at least kind
of worth worth discussing for a
44
00:02:41,080 --> 00:02:42,640
couple of minutes.
I think they are.
45
00:02:42,720 --> 00:02:45,080
I mean, I had to convince you of
some of them, but.
46
00:02:45,920 --> 00:02:50,360
Yeah, I mean, you know, none of
them are major shorts, but.
47
00:02:50,840 --> 00:02:53,320
I think some of them are major.
OK, let's get into it.
48
00:02:53,320 --> 00:02:57,520
So the first one is called Upnp
has dropped.
49
00:02:58,200 --> 00:03:00,400
That's right.
And but it has dropped, I mean
50
00:03:00,400 --> 00:03:03,080
has been dropped.
I mean, it's wait.
51
00:03:03,200 --> 00:03:05,040
Oh yeah.
It's not, it's not included
52
00:03:05,040 --> 00:03:06,240
anymore.
That's what that means.
53
00:03:06,240 --> 00:03:08,360
Yeah.
I, I was thinking dropping like,
54
00:03:08,360 --> 00:03:10,840
you know, dropping a new album.
Yeah, exactly.
55
00:03:10,840 --> 00:03:14,280
But the Pitco Core developers
have dropped Upnp, No, OK, it's
56
00:03:14,280 --> 00:03:16,080
not.
It's no longer in micro core
57
00:03:16,080 --> 00:03:17,760
actually.
That's what it means, yeah.
58
00:03:17,760 --> 00:03:19,840
So what is Upnp?
Yeah.
59
00:03:19,840 --> 00:03:24,640
So Upnp is and was a way for you
to make your Bitcoin node at
60
00:03:24,640 --> 00:03:28,120
home or wherever it is reachable
from the outside.
61
00:03:28,840 --> 00:03:32,880
Because typically, so when
you're on a server, your node
62
00:03:33,200 --> 00:03:36,320
will find other peers to connect
to, but it will also listen for
63
00:03:36,320 --> 00:03:37,720
other peers that want to connect
to it.
64
00:03:38,360 --> 00:03:40,720
And if you're sitting on Amazon
somewhere in the server park,
65
00:03:41,240 --> 00:03:43,720
that tends to just work.
But if you're sitting at home,
66
00:03:44,040 --> 00:03:49,280
most routers for your home
create a firewall, and anybody
67
00:03:49,280 --> 00:03:51,960
that tries to connect to you
will not succeed.
68
00:03:52,360 --> 00:03:55,400
You can connect to anybody you
want, but nobody can connect to
69
00:03:55,400 --> 00:03:58,440
you as sort of a standard safety
measure, because they don't
70
00:03:58,440 --> 00:04:01,920
want, you know, random hackers
to connect to random insecure
71
00:04:01,920 --> 00:04:03,800
Windows computers that you might
be running.
72
00:04:03,960 --> 00:04:07,800
Yeah.
OK, so because I've I, I always
73
00:04:07,800 --> 00:04:10,520
kind of wondered about this.
Well, I always sort of knew the
74
00:04:10,520 --> 00:04:15,840
answer, but this confirms it.
Like in my case, I, I, I do run
75
00:04:15,840 --> 00:04:19,399
Bitcoin Core, but I just
downloaded, downloaded software,
76
00:04:19,399 --> 00:04:24,320
run it on my computer.
But in my case that means that
77
00:04:24,440 --> 00:04:28,680
I'm not actually sharing blocks
or transactions with other nodes
78
00:04:28,680 --> 00:04:29,760
because.
You are.
79
00:04:29,880 --> 00:04:32,000
However, you're not receiving
connections.
80
00:04:32,000 --> 00:04:35,840
So if you make a connection to
another node, you will send and
81
00:04:35,840 --> 00:04:40,000
receive blocks and transactions.
So it's not about you're not a
82
00:04:40,000 --> 00:04:43,880
leecher basically as they used
to call that in, in torn jargon.
83
00:04:44,320 --> 00:04:47,440
You are sharing just as much.
It doesn't really matter whether
84
00:04:47,440 --> 00:04:49,360
you are whether who initiates
the connection.
85
00:04:49,360 --> 00:04:53,520
It's just that if everybody in
the world is only listening, I'm
86
00:04:53,560 --> 00:04:55,680
sorry if everybody, nobody in
the world's listening and
87
00:04:55,680 --> 00:04:57,720
everybody's trying to connect
and they have nowhere to connect
88
00:04:57,720 --> 00:04:59,280
to.
So somebody needs to listen.
89
00:04:59,400 --> 00:05:02,560
Right, that's it.
So you know, in your case I
90
00:05:02,560 --> 00:05:05,760
don't know if you run a note
with or without the firewall.
91
00:05:06,640 --> 00:05:08,720
Yeah, so I run multiple notes
that you can reach.
92
00:05:08,840 --> 00:05:12,120
Right, so then my note, because
I never changed any settings,
93
00:05:12,120 --> 00:05:14,440
right?
I just, I just, well, I changed
94
00:05:14,440 --> 00:05:15,600
somethings.
Well, not this setting.
95
00:05:16,160 --> 00:05:18,360
So I basically run it
out-of-the-box.
96
00:05:18,560 --> 00:05:22,560
So then I am connecting to you
so that I'm sharing blocks and
97
00:05:22,560 --> 00:05:26,480
transactions with you that I
might also get from like another
98
00:05:26,480 --> 00:05:27,960
source that is doing the same
thing.
99
00:05:28,480 --> 00:05:31,920
But I will not connect to
another errand because the other
100
00:05:31,920 --> 00:05:33,760
errand is also running it
out-of-the-box.
101
00:05:34,040 --> 00:05:36,800
So I have no way of connecting
to him and he has no way of
102
00:05:36,800 --> 00:05:40,520
connecting to me.
So then yeah, the, the, I mean,
103
00:05:40,520 --> 00:05:42,640
isn't that a problem?
Like, isn't it a problem that if
104
00:05:42,640 --> 00:05:46,080
there's just too few, if there's
too many errands and too few
105
00:05:46,080 --> 00:05:50,080
sources, that it just becomes a
form of centralisation because
106
00:05:50,080 --> 00:05:53,120
everyone is running, You know,
it becomes basically like a
107
00:05:53,120 --> 00:05:55,560
hobby spoke network, I guess
would be the technical term.
108
00:05:55,560 --> 00:05:57,160
Yes.
Now we're nowhere near that that
109
00:05:57,160 --> 00:06:01,400
point, because there are many,
many thousands of nodes that are
110
00:06:01,400 --> 00:06:03,280
listening.
So there's no shortage.
111
00:06:03,600 --> 00:06:07,160
However, we talked about in an
earlier episode about AES map,
112
00:06:07,960 --> 00:06:10,280
which is like a map of the
Internet of which providers.
113
00:06:11,000 --> 00:06:13,280
And one of the things that
Bitcoin Core wants to do in the
114
00:06:13,280 --> 00:06:15,560
future is to have more diverse
connections.
115
00:06:15,560 --> 00:06:17,760
And I don't mean that in ADEY
sense.
116
00:06:18,440 --> 00:06:20,960
I mean that in a sense of you
should not have all your
117
00:06:20,960 --> 00:06:23,080
connections to Amazon.
You should have one connection
118
00:06:23,080 --> 00:06:27,880
to Amazon, maybe one to Google,
One to some ISP in Kenya, one to
119
00:06:27,880 --> 00:06:32,040
some ISP in Germany.
So, so that if somebody's trying
120
00:06:32,040 --> 00:06:34,600
to mess with you, like it's very
difficult for them because they
121
00:06:34,640 --> 00:06:38,200
would have to somehow pretend to
be a lot of different Internet
122
00:06:38,200 --> 00:06:41,880
providers in the world.
And if we do that, and that
123
00:06:41,880 --> 00:06:46,280
means that the number of notes
that are listening, if if you
124
00:06:46,280 --> 00:06:48,440
know the the notes that are
listening now that are sitting
125
00:06:48,440 --> 00:06:51,440
on Amazon and Google, exactly
the kind of places where it's
126
00:06:51,440 --> 00:06:54,880
easy to set that up, they will
get fewer connections.
127
00:06:55,280 --> 00:07:00,040
And all the obscure, all the
nodes in the obscure apartments
128
00:07:00,040 --> 00:07:03,280
in random countries will get a
lot more connections.
129
00:07:03,720 --> 00:07:07,000
And it could be, depending on
the simulation, that that's too
130
00:07:07,000 --> 00:07:09,760
much that you would start
overloading the more obscure
131
00:07:10,120 --> 00:07:12,120
places.
Yeah, because there's only one
132
00:07:12,120 --> 00:07:15,360
guy in Kenya running a node
exactly so that everyone wants
133
00:07:15,360 --> 00:07:17,360
to connect to the one guy in
Kenya node.
134
00:07:17,440 --> 00:07:19,280
Yes, because it's not Amazon.
Yeah.
135
00:07:19,480 --> 00:07:22,280
So in order to prevent that,
it's probably necessary to
136
00:07:22,280 --> 00:07:24,440
increase the number of listening
notes at least somewhat.
137
00:07:25,600 --> 00:07:28,360
Now.
So there are two kinds of nodes
138
00:07:28,360 --> 00:07:35,600
that listen by default. 1 is
sorry, no, let me rephrase that
139
00:07:36,200 --> 00:07:37,560
there.
There is another node that
140
00:07:37,560 --> 00:07:41,160
listens by default, which is a
Tor node because some of the, if
141
00:07:41,160 --> 00:07:45,280
you set up Tor, you you set it
up usually to also be to use a
142
00:07:45,280 --> 00:07:47,760
hidden service.
And it turns out that projects
143
00:07:47,760 --> 00:07:50,960
like Umbrella will do that
automatically for you and that's
144
00:07:50,960 --> 00:07:53,760
easier.
But those are only on Tor, so
145
00:07:54,280 --> 00:07:55,640
not that useful if you're not on
tour.
146
00:07:55,760 --> 00:07:59,120
They're only they, Yeah, they
would Only Connect to other tour
147
00:07:59,120 --> 00:08:00,880
users.
And if you're running in a data
148
00:08:00,880 --> 00:08:03,960
center, then typically
everything is just wide open so
149
00:08:03,960 --> 00:08:07,920
everybody can connect to you.
But there's also a tool that
150
00:08:07,920 --> 00:08:10,400
used to be included in very
early versions of Bitcoin Core
151
00:08:10,400 --> 00:08:12,880
called Upnp.
And what this would do is it
152
00:08:12,880 --> 00:08:15,600
would look for your router.
So from the inside, it would
153
00:08:15,600 --> 00:08:18,440
look at the router and say, hey,
router, please like open this
154
00:08:18,440 --> 00:08:21,080
port for me.
Open this door so that everybody
155
00:08:21,080 --> 00:08:22,480
who wants to talk to me can talk
to me.
156
00:08:24,000 --> 00:08:28,320
And UNUNP is the setting you use
if you want to be a listening
157
00:08:28,320 --> 00:08:30,520
note.
It was yes, yeah.
158
00:08:30,680 --> 00:08:32,559
And and so this this was
introduced quite a while ago.
159
00:08:32,559 --> 00:08:34,320
And that's why there are, you
know, from the beginning there
160
00:08:34,320 --> 00:08:36,840
were quite a few listening notes
because every that was, I think
161
00:08:36,840 --> 00:08:39,000
it was on by default.
So everybody who downloaded
162
00:08:39,000 --> 00:08:43,559
Bitcoin Core would, if possible,
punch a hole in their router and
163
00:08:43,559 --> 00:08:45,000
and start listening.
Right.
164
00:08:45,000 --> 00:08:47,200
OK, Yeah.
And or in their firewall.
165
00:08:47,200 --> 00:08:50,880
I guess the problem is that Upnp
is a software package was
166
00:08:50,880 --> 00:08:54,000
extremely insecure.
There were multiple bugs found
167
00:08:54,000 --> 00:08:57,520
in it that would say, allow
somebody to take over your
168
00:08:57,520 --> 00:09:01,840
computer and steal your coins.
That sounds bad.
169
00:09:02,120 --> 00:09:06,600
Yes, exactly.
And so this was not removed, but
170
00:09:06,600 --> 00:09:10,120
it was turned off by default.
So as a result, for many many
171
00:09:10,120 --> 00:09:12,160
years, if you install a new
version of Bitcoin Core, it
172
00:09:12,160 --> 00:09:15,560
would simply not do any of this
unless you turned it on yourself
173
00:09:15,600 --> 00:09:18,320
at your own risk.
Do you know when this change was
174
00:09:18,320 --> 00:09:20,440
made?
Many, many years ago, Probably
175
00:09:20,440 --> 00:09:24,280
2012.
OK, so if if I had downloaded
176
00:09:24,440 --> 00:09:26,360
if.
If you had downloaded a Bitcoin
177
00:09:26,560 --> 00:09:29,400
in 2011 or something like that,
you would be listening, right?
178
00:09:29,800 --> 00:09:32,480
If you were still running a note
from 2011, you would be
179
00:09:32,480 --> 00:09:34,360
listening and you would be
hacked.
180
00:09:35,840 --> 00:09:40,000
But yeah, you could.
So you know it's.
181
00:09:40,000 --> 00:09:43,480
Been in any case, this setting
was called, I mean it's still
182
00:09:43,480 --> 00:09:47,760
called Upnp, yes?
And this was removed.
183
00:09:47,760 --> 00:09:49,600
Yes.
And in recent years, so there's
184
00:09:49,640 --> 00:09:53,640
added a whole new system to it.
I'll skip some intermediate
185
00:09:53,640 --> 00:09:55,240
steps.
So basically we added something
186
00:09:55,240 --> 00:09:59,520
called Port Control Protocol
PCP, which is a much more modern
187
00:09:59,520 --> 00:10:02,280
way of doing the same thing of
asking your router to please
188
00:10:02,280 --> 00:10:05,800
open it, but it is much simpler
in terms of code.
189
00:10:06,000 --> 00:10:08,400
Therefore, we're a little less
worried about any security
190
00:10:08,400 --> 00:10:11,480
vulnerabilities there.
That's still not turned on by
191
00:10:11,480 --> 00:10:15,680
default.
So nothing really changes.
192
00:10:15,680 --> 00:10:18,040
You still if you download
Bitcoin Core and you have the
193
00:10:18,040 --> 00:10:22,200
GUI, there's a settings dialogue
and you can click on basically
194
00:10:22,360 --> 00:10:25,560
PCP now where it said where it
used to say you BNP and now it
195
00:10:25,560 --> 00:10:30,760
says PCP.
OK, maybe you said it, maybe you
196
00:10:30,760 --> 00:10:35,440
just said it, but is PCP new in
this Pico Core release or OK and
197
00:10:35,440 --> 00:10:38,200
that's why now Upnp has been
removed?
198
00:10:39,200 --> 00:10:40,120
Yes, exactly.
It.
199
00:10:40,120 --> 00:10:44,120
It's essentially a replacement
and then perhaps we'll turn it
200
00:10:44,120 --> 00:10:46,280
on by default in the future.
I mean, that's something that
201
00:10:46,280 --> 00:10:48,480
has to be considered somewhat
carefully because it would
202
00:10:48,480 --> 00:10:52,840
impact a lot of different nodes.
OK, but the the functionality is
203
00:10:52,840 --> 00:10:55,360
basically the functionality has
not changed so far.
204
00:10:55,360 --> 00:10:59,120
It's it's just the fewer bugs
exactly, presumably.
205
00:10:59,360 --> 00:11:01,520
Yeah, now the bugs that were
originally found were fixed.
206
00:11:01,520 --> 00:11:04,080
But the problem is, of course,
if you found multiple really bad
207
00:11:04,080 --> 00:11:06,120
bugs in a project, do you still
want to use it?
208
00:11:06,640 --> 00:11:09,040
Maybe not, because maybe you
didn't find all of them.
209
00:11:09,440 --> 00:11:15,960
And did I understand correctly
that PCP either PCP itself or
210
00:11:15,960 --> 00:11:21,080
the integration of PCP in OK,
first question is PCPA Bitcoin
211
00:11:21,080 --> 00:11:24,560
specific project or no?
OK, No, it's, it's a general
212
00:11:24,560 --> 00:11:27,200
project simply just like you
PNP, which was not a Bitcoin
213
00:11:27,200 --> 00:11:29,240
specific project.
It was used by torrent clients,
214
00:11:29,240 --> 00:11:32,600
all that sort of stuff to to be
able to open your ports
215
00:11:32,600 --> 00:11:34,560
automatically.
Games tend to use the stuff like
216
00:11:34,560 --> 00:11:38,160
this right?
And then did I understand that
217
00:11:38,600 --> 00:11:42,160
then the integration of PCP into
Bitcoin Core was done by
218
00:11:42,160 --> 00:11:44,160
Vladimir Falaban?
That's right, yes.
219
00:11:44,160 --> 00:11:46,840
And he actually re implemented
it.
220
00:11:46,840 --> 00:11:49,520
So he he rewrote the code
specifically in C++.
221
00:11:49,520 --> 00:11:51,920
So that's kind of nice.
Right.
222
00:11:52,560 --> 00:11:54,960
Yeah, that's cool.
Nice to hear if Vladimir is back
223
00:11:54,960 --> 00:11:56,000
at it.
Yep.
224
00:11:56,160 --> 00:11:58,640
In case there's listeners that
don't know, Vladimir was the
225
00:11:59,000 --> 00:12:02,960
lead developer of Bitcoin Core
for eight years.
226
00:12:03,440 --> 00:12:05,720
Very long time.
A whole, a whole while took a
227
00:12:05,720 --> 00:12:07,600
step back.
So very nice to hear that he's
228
00:12:07,600 --> 00:12:10,520
back at it.
Well, not back at the annoying
229
00:12:10,520 --> 00:12:12,840
work of being a maintainer, but
simply doing the.
230
00:12:12,960 --> 00:12:14,600
Contributing.
Doing interesting stuff.
231
00:12:14,680 --> 00:12:19,000
Yeah, exactly.
OK, the next one has definitely
232
00:12:19,000 --> 00:12:21,360
the coolest name out of the
list.
233
00:12:21,480 --> 00:12:23,760
Ephemeral dust.
There we go.
234
00:12:24,320 --> 00:12:28,240
Although, yeah, no, that's got
to be the coolest one.
235
00:12:29,040 --> 00:12:31,360
OK, Ephemeral dust.
What does it do?
236
00:12:31,360 --> 00:12:32,760
What is it?
What are we talking about?
237
00:12:32,800 --> 00:12:37,080
The new finished metal band
started by Marty Malmi No.
238
00:12:37,200 --> 00:12:40,640
And better than Bitcoin Core
Place place by default.
239
00:12:40,680 --> 00:12:43,880
I guess and better than Bitcoin
Core would also be a nice metal
240
00:12:43,880 --> 00:12:48,680
band name.
But in any case, basically the
241
00:12:48,680 --> 00:12:53,040
idea we've talked about parents,
child pays for parent kind of
242
00:12:53,040 --> 00:12:57,240
situations in the men pool back
in our episode about version 28,
243
00:12:57,800 --> 00:12:59,400
which I think it's just two
episodes ago.
244
00:12:59,400 --> 00:13:01,400
So for you it would have been 20
minutes ago if you're listening
245
00:13:01,400 --> 00:13:05,800
to the whole series in one go.
Child pays for parents means you
246
00:13:05,800 --> 00:13:09,960
are receiving a transaction, but
the fee is so low that it's just
247
00:13:09,960 --> 00:13:13,960
sort of hanging around to the
manpole kind of, you know, being
248
00:13:13,960 --> 00:13:16,920
unconfirmed in your wallet.
And then the way you can solve
249
00:13:16,920 --> 00:13:21,680
that is to actually spend these
coins to yourself with a higher
250
00:13:21,680 --> 00:13:24,760
fee in the new transaction.
And then miners will sort of
251
00:13:24,760 --> 00:13:27,920
make the overall calculation
that if they include both
252
00:13:27,920 --> 00:13:31,360
transactions, both the original
transaction to you as well as
253
00:13:31,640 --> 00:13:34,440
the new transaction you just
made to yourself from the same,
254
00:13:34,440 --> 00:13:37,120
you know, with the same coins,
then they're both getting
255
00:13:37,120 --> 00:13:41,000
confirmed and your, your coins
are finally in your wallet.
256
00:13:41,080 --> 00:13:43,800
Exactly, so you have to bring
some of your own coins in order
257
00:13:43,800 --> 00:13:46,000
to pay the fees for the
transaction that you want to
258
00:13:46,000 --> 00:13:47,560
receive.
Now in your example, it was
259
00:13:47,560 --> 00:13:50,720
still in the men pool, but
imagine if these are so low that
260
00:13:50,720 --> 00:13:53,840
they're not even in the map
pool, then you have to relay
261
00:13:53,840 --> 00:13:58,040
them together because nobody's
map pool will accept it if the
262
00:13:58,040 --> 00:14:00,920
fee of the original is too low.
And this is called package
263
00:14:00,920 --> 00:14:03,840
relay, which we we covered in
that episode.
264
00:14:03,840 --> 00:14:06,640
So you relay 2 packages, 2
transactions as a package.
265
00:14:07,200 --> 00:14:10,040
And then every node along the
way can reason about it and say,
266
00:14:10,040 --> 00:14:12,160
hey, OK, this is fine.
This this should be a
267
00:14:12,560 --> 00:14:14,120
interesting enough for a miner
to include.
268
00:14:14,160 --> 00:14:18,280
Yeah, so basically notes would
start to use how far are we with
269
00:14:18,280 --> 00:14:19,760
this?
I I know we covered it in
270
00:14:19,760 --> 00:14:21,840
previous episodes.
Yeah, we, we covered most of
271
00:14:21,840 --> 00:14:23,880
this, but this might be useful
to go to the basics.
272
00:14:23,880 --> 00:14:26,320
That's what a package is.
And the only form of packages
273
00:14:26,320 --> 00:14:29,480
that Bitcoin Core supports is
one parent, one child.
274
00:14:30,000 --> 00:14:32,840
And it has simply to do with the
fact that it's complicated to
275
00:14:32,840 --> 00:14:34,880
reason about anything bigger
than that.
276
00:14:35,000 --> 00:14:37,280
Well, that was included in the
previous Bitcoin Core release.
277
00:14:37,320 --> 00:14:41,040
Same thing, yeah.
So I mean the idea then is
278
00:14:41,040 --> 00:14:49,000
basically that notes will use a
similar ish strategy as minors.
279
00:14:49,000 --> 00:14:51,560
Like minors already make this
calculation and now notes are
280
00:14:51,560 --> 00:14:55,120
starting have been starting to
make a similar calculation to
281
00:14:55,120 --> 00:14:56,800
decide if perceptions show up in
the met pool.
282
00:14:57,160 --> 00:15:00,920
Yes.
And so then the, the part where
283
00:15:00,920 --> 00:15:04,160
dust comes in, part of the
ephemeral part is that, well,
284
00:15:04,160 --> 00:15:07,040
there's other rules that don't
allow you to relay stuff in the
285
00:15:07,040 --> 00:15:08,400
mempool.
And one of them is if you're
286
00:15:08,400 --> 00:15:12,400
creating an output that is too
small, it used to be like 543
287
00:15:12,400 --> 00:15:15,520
bytes.
Sorry, SAT's, if you had an
288
00:15:15,520 --> 00:15:19,080
output that was less than 543
sets, nodes would say this is
289
00:15:19,080 --> 00:15:20,800
dust.
I'm not going to relay it.
290
00:15:21,160 --> 00:15:23,040
It's valid in the blockchain,
but I'm not going to relay it.
291
00:15:23,800 --> 00:15:26,320
That was just basically a way to
prevent somebody from creating
292
00:15:26,320 --> 00:15:28,880
lots of very small outputs in
the Utxil set that are just
293
00:15:28,880 --> 00:15:32,320
wasting everybody's memory or,
or whatever they're wasting.
294
00:15:34,760 --> 00:15:39,440
And so if you have a one child,
one parent construction, but the
295
00:15:39,440 --> 00:15:42,520
child is basically the parent
has a bunch of dust as the
296
00:15:42,520 --> 00:15:46,040
output and the child is
consuming the dust and then
297
00:15:46,040 --> 00:15:48,520
paying their own fees.
So they might be paying enough
298
00:15:48,520 --> 00:15:51,720
fees, but because there's dust
involved, the notes would still
299
00:15:51,720 --> 00:15:53,640
reject it because they don't
like dust.
300
00:15:54,440 --> 00:15:58,040
And the ultimate example of dust
is a 0 output.
301
00:15:58,560 --> 00:16:00,200
Yeah, which is apparently
possible.
302
00:16:00,560 --> 00:16:03,600
Yes, yeah, definitely.
There was, it was I think a year
303
00:16:03,600 --> 00:16:06,840
ago, back when everybody was,
was this, you know, remember
304
00:16:06,840 --> 00:16:10,560
this ordinals inscription type.
So the ordinals inscriptions,
305
00:16:10,560 --> 00:16:13,280
they, they come up with this set
of rules that are not consensus
306
00:16:13,280 --> 00:16:15,480
rules, so just their own rules.
And it would count like, you
307
00:16:15,480 --> 00:16:17,720
know, you are SAT number one,
SAT #2 yada, yada.
308
00:16:17,720 --> 00:16:19,800
Yeah.
And it turns out I think they
309
00:16:19,800 --> 00:16:22,160
didn't take account of the
possibility to have a
310
00:16:22,160 --> 00:16:25,880
transaction that has zero SAT's
as an input and 0 SAT's as an
311
00:16:25,880 --> 00:16:29,760
output.
So somebody made one as a joke,
312
00:16:30,000 --> 00:16:32,440
like just sent it directly to a
miner because it's consensus
313
00:16:32,440 --> 00:16:33,760
valid even though it's not
standard.
314
00:16:34,240 --> 00:16:38,640
And so all their their their
tools were off by one because
315
00:16:38,880 --> 00:16:40,840
the numbering system was broken,
basically.
316
00:16:41,440 --> 00:16:44,680
OK, so you can because I didn't,
I don't know if I don't think I
317
00:16:44,680 --> 00:16:46,880
knew this.
You, you can apparently in
318
00:16:46,880 --> 00:16:52,720
Bitcoin spend 0 Bitcoin to an
address that then receives 0
319
00:16:52,720 --> 00:16:53,760
Bitcoin.
That's the issue.
320
00:16:54,160 --> 00:16:57,080
A valid transaction.
Yeah, and you've got zero fees.
321
00:16:57,080 --> 00:17:00,360
And zero fees, yeah.
So the as long as a minor
322
00:17:00,360 --> 00:17:02,840
includes that in a block then
everyone's going to say yeah
323
00:17:02,840 --> 00:17:07,000
makes sense 0. 00 Of course,
minors have no financial, good
324
00:17:07,000 --> 00:17:08,960
financial reason to do that
unless they're being paid out of
325
00:17:08,960 --> 00:17:10,240
band.
So we don't want to encourage
326
00:17:10,240 --> 00:17:13,359
this, but yeah, you can fill a
whole block with just zero fee
327
00:17:13,359 --> 00:17:16,000
transactions as far as I know.
OK, what's zero amount and and?
328
00:17:16,319 --> 00:17:18,680
And I know we were getting
there, but what is the, what's
329
00:17:18,720 --> 00:17:20,599
the, what's the benefit of
making?
330
00:17:20,599 --> 00:17:23,119
Because there is apparently an
actual benefit to doing this
331
00:17:23,280 --> 00:17:25,280
sometimes.
So I think the easiest example
332
00:17:25,280 --> 00:17:29,520
would be a lightning transaction
or so we, you and I have a
333
00:17:29,520 --> 00:17:32,240
lightning channel and there's
two ways we can close it.
334
00:17:32,240 --> 00:17:35,000
One is we are online together
and we decide to close it
335
00:17:35,000 --> 00:17:37,160
cooperatively.
We look at the fee market and we
336
00:17:37,160 --> 00:17:39,480
just make a transaction that
closes the channel, pays enough
337
00:17:39,480 --> 00:17:42,800
fees, done.
But the other scenario is one of
338
00:17:42,800 --> 00:17:44,800
us is not offline or one of us
is trying to cheat.
339
00:17:45,240 --> 00:17:48,800
But one of us is offline.
Yeah, sorry, is offline, is not
340
00:17:48,800 --> 00:17:51,280
online.
One of us is trying to cheat
341
00:17:51,280 --> 00:17:54,120
some scenario like that where we
cannot cooperate.
342
00:17:54,280 --> 00:17:56,840
That means we have to broadcast
a transaction that we signed in
343
00:17:56,840 --> 00:17:58,600
the past.
So we, we previously got
344
00:17:58,600 --> 00:18:00,000
together when we were still
buddies.
345
00:18:00,360 --> 00:18:03,640
We signed this transaction and
we say this closes the channel
346
00:18:03,640 --> 00:18:07,600
for both of us.
However, we don't know when or
347
00:18:07,600 --> 00:18:09,200
if we're going to use this
transaction.
348
00:18:09,560 --> 00:18:11,680
So we have no idea how much fees
to put in this thing.
349
00:18:12,680 --> 00:18:16,000
So, but lightning notes in the
beginning have to do is just
350
00:18:16,080 --> 00:18:17,640
pick the worst case possible
fee.
351
00:18:17,640 --> 00:18:19,120
And like, that was kind of
annoying because you're
352
00:18:19,120 --> 00:18:22,720
reserving a lot of money for,
for like a case that might never
353
00:18:22,720 --> 00:18:25,320
happen.
So what you can do instead is
354
00:18:25,320 --> 00:18:29,480
you add 0 fees to this
transaction and you say this has
355
00:18:29,480 --> 00:18:31,840
to be paid by a child.
So it's like bring your own,
356
00:18:32,280 --> 00:18:34,960
bring your own fees.
That way we don't have to decide
357
00:18:34,960 --> 00:18:36,320
in advance what the fees are
going to be.
358
00:18:36,880 --> 00:18:41,080
And if this scenario occurs, you
and I want you or I want to
359
00:18:41,080 --> 00:18:45,000
close the channel, we add one of
our own inputs to it and that
360
00:18:45,000 --> 00:18:47,040
pays for the fees.
Yeah, right.
361
00:18:47,040 --> 00:18:50,680
SO and this so.
So basically you and I establish
362
00:18:50,800 --> 00:18:56,600
a Lightning channel and they did
the closing transaction in case
363
00:18:56,600 --> 00:19:00,760
one of us is unresponsive.
In case source ends up in the
364
00:19:01,080 --> 00:19:05,040
Dal Salvadoran prison, then I
can still broadcast the
365
00:19:05,040 --> 00:19:07,240
lightning transaction with the
zero fee.
366
00:19:07,960 --> 00:19:12,040
And the way I get that included
in an actual block is to take
367
00:19:12,040 --> 00:19:16,000
some of my own coins, spend
these to myself, child paid for
368
00:19:16,000 --> 00:19:19,120
parent style.
But in that transaction also
369
00:19:19,120 --> 00:19:22,800
includes that 0 zero to zero
with 0 fee transaction.
370
00:19:22,800 --> 00:19:24,400
So now that's part of 1
transaction.
371
00:19:24,400 --> 00:19:26,560
And it's not just zero fees,
it's also zero amount.
372
00:19:26,880 --> 00:19:29,480
Yeah, exactly 0 to 0.
Yeah, exactly.
373
00:19:29,480 --> 00:19:32,000
So, so the nice thing is you
have a transaction that is
374
00:19:32,280 --> 00:19:35,760
rating an output that is 0,
which is dust, and you have a
375
00:19:35,760 --> 00:19:37,040
transaction that spends the
dust.
376
00:19:37,360 --> 00:19:39,520
And so this transaction that
creates dust normally would not
377
00:19:39,520 --> 00:19:41,280
get broadcast because it is
dust.
378
00:19:42,440 --> 00:19:46,320
But this thing called ephemeral
dust is saying, well, as long as
379
00:19:46,320 --> 00:19:48,680
you're creating dust and
immediately removing the dust,
380
00:19:49,080 --> 00:19:52,760
we're going to allow that.
And so that's being relayed and
381
00:19:52,760 --> 00:19:54,600
it's hopefully being mined as a
pair.
382
00:19:54,600 --> 00:19:56,800
So in the end, there's no dust.
OK.
383
00:19:56,800 --> 00:20:01,760
So what's new here is I think
we're talking here about the
384
00:20:01,760 --> 00:20:04,680
relay policy of Bitcoin Core
now.
385
00:20:05,480 --> 00:20:08,920
Takes this into account, is
there a my Bitcoin Core note or
386
00:20:08,920 --> 00:20:12,520
your Bitcoin Core note or anyone
else's Bitcoin Core note As as
387
00:20:12,520 --> 00:20:15,640
long as they upgraded to Bitcoin
Core 29, of course, they will
388
00:20:15,640 --> 00:20:18,760
actually look at these
transactions in tandem and they
389
00:20:18,760 --> 00:20:22,200
will say, OK, that's a that's a
transaction, but because it's
390
00:20:22,200 --> 00:20:25,000
immediately being spent as well,
it's fine.
391
00:20:25,000 --> 00:20:28,680
This is not going to create an
extra UTXO in my database or
392
00:20:28,680 --> 00:20:32,280
anyone else's database.
In other words, it's ephemeral.
393
00:20:32,880 --> 00:20:35,960
Exactly.
Now we know why it has such a
394
00:20:35,960 --> 00:20:37,120
cool name.
Yeah.
395
00:20:37,120 --> 00:20:40,440
And my understanding is that
there are some fancy future
396
00:20:40,440 --> 00:20:43,680
protocols people have in mind
like Ln, symmetry, etcetera,
397
00:20:43,680 --> 00:20:48,640
where you might have a a series
of transactions for whatever
398
00:20:48,640 --> 00:20:52,440
reason, like three in a row.
And it's nice if all three of
399
00:20:52,440 --> 00:20:56,320
them are the exact same amount
versus, you know, transaction 1
400
00:20:56,320 --> 00:20:58,120
is a little bit lower than
transaction 2 is a little bit
401
00:20:58,120 --> 00:20:59,960
lower than Section 3, because
they're all paying for their own
402
00:20:59,960 --> 00:21:02,080
fees.
Makes it easy to reason about if
403
00:21:02,080 --> 00:21:05,680
the amount stay identical and so
that for those kind of
404
00:21:05,680 --> 00:21:07,880
constructs ephemeral dust is
also useful to have.
405
00:21:08,440 --> 00:21:09,880
But that's for the future.
OK.
406
00:21:10,080 --> 00:21:12,520
And just to wrap this up.
And apparently Lightning Dust
407
00:21:12,520 --> 00:21:14,560
are super happy with this
ephemeral dust stuff.
408
00:21:15,040 --> 00:21:16,880
Well, that's how I wanted to
wrap it up.
409
00:21:16,880 --> 00:21:23,360
Basically, like the practical
benefits of this is that so far,
410
00:21:23,760 --> 00:21:26,200
if you wanted to make a
Lightning channel, then you kind
411
00:21:26,200 --> 00:21:29,920
of had to, you know, be on the
safe side and include a high fee
412
00:21:30,280 --> 00:21:33,560
for the fall back transaction
because you don't know how much
413
00:21:33,560 --> 00:21:35,320
how high fees are going to be in
the future.
414
00:21:35,640 --> 00:21:40,360
So you you're likely going to
overpay on fees if you use this
415
00:21:40,360 --> 00:21:43,600
fall back mechanism.
And now with this you can just
416
00:21:43,880 --> 00:21:48,280
make the exact right fee for
depending on how much in a rush
417
00:21:48,280 --> 00:21:49,640
you are.
And it means you can also.
418
00:21:49,720 --> 00:21:51,520
Use.
In other words, you can use like
419
00:21:51,640 --> 00:21:54,320
lower fees for closing lighting.
Yeah.
420
00:21:54,320 --> 00:21:57,160
And it means in general and you
can use more of your channel
421
00:21:57,160 --> 00:22:00,000
because if you're, you know,
reserving 10% of your channel
422
00:22:00,240 --> 00:22:02,680
for a worst case fee, you can't
actually spend that.
423
00:22:03,160 --> 00:22:04,840
Right.
Yeah, I see.
424
00:22:04,840 --> 00:22:06,400
Yeah.
So it improves the lighting
425
00:22:06,400 --> 00:22:12,480
network in that way.
Yes, the lower lower fees and
426
00:22:12,480 --> 00:22:14,600
therefore more actual liquidity
on lighting itself.
427
00:22:14,600 --> 00:22:16,080
Yeah.
The little caveat there is that
428
00:22:16,080 --> 00:22:17,440
you do have to bring your own
UTX.
429
00:22:18,600 --> 00:22:21,280
So so if you have a Lightning
wallet that only has a channel
430
00:22:21,760 --> 00:22:24,160
now things get a little bit more
complicated because how are you
431
00:22:24,200 --> 00:22:26,840
actually going to do the child
pay for parents if you don't
432
00:22:26,840 --> 00:22:30,680
have any children?
But the you know, the rabbit
433
00:22:30,680 --> 00:22:32,880
hole does not end here.
But it is a lot better this way.
434
00:22:32,880 --> 00:22:36,680
You need to have at least one
other UTXO or another channel in
435
00:22:36,680 --> 00:22:38,960
the in the same wallet.
Yeah, maybe.
436
00:22:39,160 --> 00:22:41,040
I mean, I guess.
I guess that could work
437
00:22:41,040 --> 00:22:46,400
depending on how it's designed.
OK, that was ephemeral dust.
438
00:22:47,400 --> 00:22:50,320
Then we go to a slightly less
school name.
439
00:22:51,040 --> 00:22:54,120
Still pretty cool, but less
cool.
440
00:22:54,720 --> 00:22:57,680
Block reserved weight.
Yes.
441
00:22:57,680 --> 00:23:00,040
What is what is the update here?
Block reserved weight.
442
00:23:00,600 --> 00:23:03,120
Yeah.
So this was so basically a
443
00:23:03,120 --> 00:23:05,360
little background here is
Bitcoin Core is able to make
444
00:23:05,360 --> 00:23:09,000
block templates that miners can
use to create a block basically.
445
00:23:09,480 --> 00:23:12,160
And they Bitcoin Core tries to
stuff as many transactions as it
446
00:23:12,160 --> 00:23:14,400
can into a block to give you the
maximum fees.
447
00:23:15,000 --> 00:23:17,680
However, as a minor, you need to
bring your own Coinbase
448
00:23:17,680 --> 00:23:20,280
transaction.
It's just how the protocol
449
00:23:20,280 --> 00:23:21,560
works.
Yeah, that's that's the
450
00:23:21,560 --> 00:23:25,520
transaction that pays the coins,
the new coins and the fees to.
451
00:23:25,680 --> 00:23:29,760
Does that it might also have
some commitments to various like
452
00:23:30,840 --> 00:23:35,960
what's it called like Co mining.
Do you mean like the ocean
453
00:23:35,960 --> 00:23:38,200
thing?
Not ocean thing, but usually
454
00:23:38,200 --> 00:23:40,440
there's all these like other
protocols that you're mining on
455
00:23:40,440 --> 00:23:43,360
to merge mining, Sure, yeah.
So there may be other stuff in
456
00:23:43,360 --> 00:23:45,320
the Coinbase that Bitcoin Core
just doesn't do for you.
457
00:23:45,920 --> 00:23:48,760
So that means what that means is
that Bitcoin Core does not know
458
00:23:48,760 --> 00:23:50,680
how big the Coinbase transaction
is going to be.
459
00:23:50,680 --> 00:23:53,720
Therefore, it doesn't precisely
know how much transactions it
460
00:23:53,720 --> 00:23:56,560
can actually put in your block
because the Coinbase does count
461
00:23:56,560 --> 00:23:58,120
towards the limit, right?
Sure.
462
00:23:58,120 --> 00:24:00,920
As does the header people.
You know, you don't want to
463
00:24:00,920 --> 00:24:05,800
forget that.
So it used to be that Bitcoin
464
00:24:05,800 --> 00:24:11,640
Core, I think, tried to reserve
4000 bytes for this, basically
465
00:24:11,640 --> 00:24:14,520
just like here, OK, I'll just
not use 4000 bytes and then you
466
00:24:14,520 --> 00:24:18,160
should be OK.
Accidentally, that was increased
467
00:24:18,160 --> 00:24:21,840
to 8000 bytes, though it wasn't
a complete accident because the
468
00:24:21,840 --> 00:24:24,920
commit that did that, the pool
Crest that did that had a common
469
00:24:24,920 --> 00:24:26,600
saying, oh, I think we're doing
it twice now.
470
00:24:26,600 --> 00:24:28,200
And then the reaction goes,
yeah, that's fine.
471
00:24:29,160 --> 00:24:32,760
That's the attitude I like to
hear from the Bitcoin Core
472
00:24:32,760 --> 00:24:36,320
developers that are building the
future of money.
473
00:24:36,680 --> 00:24:40,120
Well, it's better to be safe
than sorry, but basically, you
474
00:24:40,120 --> 00:24:42,920
know, some miners really want to
squeeze out every last bit
475
00:24:42,920 --> 00:24:45,640
because the downside is, you
know, if we reserve 8000 bytes
476
00:24:45,640 --> 00:24:51,880
by default, but you only need, I
don't know, 500 bytes for your
477
00:24:51,880 --> 00:24:54,840
Coinbase, kind of, you know,
your weight, you're, they're
478
00:24:54,840 --> 00:24:56,440
throwing away some potential
fees there.
479
00:24:56,520 --> 00:24:58,680
Yeah, you're you're leaving.
You have.
480
00:24:58,680 --> 00:24:59,800
You're leaving sats on the
table.
481
00:25:00,080 --> 00:25:02,200
Unnecessary headroom, Yeah.
Yeah, you're leaving sats on the
482
00:25:02,200 --> 00:25:03,720
table.
And then what happens is miners
483
00:25:03,720 --> 00:25:06,800
think, hey, I'm leaving SAS on
the table, let me edit the
484
00:25:06,800 --> 00:25:09,560
Bitcoin Core source code and
change the stuff so it uses the
485
00:25:09,560 --> 00:25:12,640
exact, you know, limit.
And then they make a mistake
486
00:25:12,640 --> 00:25:15,080
because Bitcoin Core stuff is
hard to reason about.
487
00:25:15,440 --> 00:25:19,240
And they produce a block with
4,000,001 weight units.
488
00:25:19,400 --> 00:25:22,680
And now they've lost hundreds of
thousands of dollars while
489
00:25:22,680 --> 00:25:24,280
trying to save themselves two
cents.
490
00:25:24,880 --> 00:25:28,040
So we want to discourage that.
And one way to do that is by
491
00:25:28,040 --> 00:25:32,120
giving people what they want is
mostly so that they don't have
492
00:25:32,120 --> 00:25:35,080
to start doing this editing.
So there's a new setting now
493
00:25:35,080 --> 00:25:36,880
that's called block reserved
weight.
494
00:25:37,040 --> 00:25:39,800
It defaults to this 8000 number
that Bitcoin Core is already
495
00:25:39,800 --> 00:25:42,720
using, but you can set it lower
if you know what you're doing.
496
00:25:42,920 --> 00:25:47,720
OK, so I think that was clear,
but I'll repeat it anyways.
497
00:25:47,720 --> 00:25:53,800
So yeah, right now in blocks
Bitcoin Core reserves 8000 bytes
498
00:25:53,840 --> 00:25:58,440
for the coin base transaction 8.
1000 weight units, but yeah.
499
00:25:58,560 --> 00:26:01,120
Sure.
That's the standard number, and
500
00:26:01,120 --> 00:26:04,320
now that's become configurable.
That's right.
501
00:26:04,920 --> 00:26:09,640
Not less, not less than 2000.
But if you yeah, we don't think
502
00:26:09,640 --> 00:26:12,560
you should go below 2000.
If you do, then edit the source
503
00:26:12,560 --> 00:26:15,880
code, but don't blame us.
I mean I have no idea what these
504
00:26:15,880 --> 00:26:18,680
numbers mean.
I I have no how well How big is
505
00:26:18,680 --> 00:26:22,120
a Coinbase transaction usually?
That really depends on what
506
00:26:22,120 --> 00:26:24,120
you're doing it.
Like Ocean Pool is trying to pay
507
00:26:24,120 --> 00:26:26,760
all of their mines directly.
So those are quite big and, and,
508
00:26:26,760 --> 00:26:28,440
but they already know how to use
settings like this.
509
00:26:30,120 --> 00:26:32,360
But you know, a minimum point
based transaction might be a lot
510
00:26:32,360 --> 00:26:33,960
smaller.
You have to include, you also
511
00:26:33,960 --> 00:26:34,880
have to include the block
header.
512
00:26:34,880 --> 00:26:40,040
So the block header is 80 bytes,
which times 4 is 320 weight
513
00:26:40,040 --> 00:26:42,280
units.
And then a transaction might be
514
00:26:42,280 --> 00:26:45,640
another 400.
So maybe the minimum is 809
515
00:26:45,640 --> 00:26:48,600
hundred.
But we basically, while we were
516
00:26:48,600 --> 00:26:51,240
reviewing this pull request,
people kept getting confused.
517
00:26:51,520 --> 00:26:54,320
They're like, well, if this
confuses us, probably we should
518
00:26:54,320 --> 00:26:57,800
just pick a higher number than
what we think it can be, so you
519
00:26:57,800 --> 00:26:59,000
might be wrong.
Well, why?
520
00:26:59,000 --> 00:27:02,400
OK, but why make the minimum
maximum two?
521
00:27:02,600 --> 00:27:04,960
Wait, which one is it?
The minimum is 2000.
522
00:27:05,040 --> 00:27:06,360
Yeah, why not?
Why?
523
00:27:07,000 --> 00:27:08,920
Why?
Because if you set a number
524
00:27:08,920 --> 00:27:10,880
that's too low, you produce a
block that's invalid.
525
00:27:10,920 --> 00:27:13,560
That's not your problem though.
As a As a, who do you?
526
00:27:13,680 --> 00:27:15,680
Who do you think they're going
to get angry at?
527
00:27:17,800 --> 00:27:21,880
OK, so you're still giving some
some some room for error there
528
00:27:21,880 --> 00:27:23,840
or some?
Yeah, some, some, some, some
529
00:27:23,840 --> 00:27:25,560
seat belt.
Yeah, belt and suspenders.
530
00:27:25,560 --> 00:27:27,120
And if you really know what
you're doing, you can edit the
531
00:27:27,120 --> 00:27:28,560
source code.
OK, fair.
532
00:27:28,560 --> 00:27:31,080
You really, you really shouldn't
for those five SAS extra.
533
00:27:32,040 --> 00:27:33,720
Right.
OK.
534
00:27:33,840 --> 00:27:38,920
So that's new.
Next one there's some mediation
535
00:27:38,920 --> 00:27:42,560
or solution?
No, I'll just let you explain
536
00:27:42,560 --> 00:27:44,280
it.
It has to do with a time warp
537
00:27:44,280 --> 00:27:45,240
attack.
Exactly.
538
00:27:45,240 --> 00:27:48,480
So as you know there we talked
about the time warp attack in
539
00:27:48,480 --> 00:27:52,840
general many episodes ago.
Now there is a new proposal
540
00:27:52,840 --> 00:27:55,600
called the Great Consensus Clean
Up that tries to fix the time
541
00:27:55,600 --> 00:28:00,000
warp attack once and for all.
That is not deployed yet, but we
542
00:28:00,000 --> 00:28:03,480
do want to deploy some code in
the minor that make sure no
543
00:28:03,480 --> 00:28:06,160
accidents happen should the
software ever become active.
544
00:28:06,560 --> 00:28:10,000
OK, so there's now I I do want
you to explain what the time of
545
00:28:10,000 --> 00:28:11,720
attack was, or at least in
brief.
546
00:28:12,240 --> 00:28:16,880
But if I understand this upgrade
correctly, Bitcoin Core has
547
00:28:16,880 --> 00:28:23,160
included a solution to a
potential future problem based
548
00:28:23,160 --> 00:28:25,720
on a future upgrade.
So the solution is now there,
549
00:28:25,720 --> 00:28:28,600
but the problem not yet.
Basically, if you upgrade to the
550
00:28:28,600 --> 00:28:32,240
29 as a minor, but then you
don't upgrade to whatever new
551
00:28:32,240 --> 00:28:35,640
version has this this eventual
soft fork, you will not
552
00:28:35,720 --> 00:28:37,720
accidentally violate the soft
fork.
553
00:28:38,120 --> 00:28:41,040
Right, OK.
So yeah, I I see how that makes
554
00:28:41,040 --> 00:28:42,440
sense.
It sounded.
555
00:28:42,560 --> 00:28:45,200
Ideally you would sounded.
More silly when I said it, but
556
00:28:45,200 --> 00:28:48,360
yeah, of course sometimes miners
will be slow to upgrade, so
557
00:28:48,360 --> 00:28:49,640
actually it's a good idea to
all.
558
00:28:49,720 --> 00:28:50,840
Yeah.
And, and generally with
559
00:28:50,840 --> 00:28:54,800
software, it is important for
miners to upgrade, but there are
560
00:28:55,480 --> 00:28:59,640
ideally like you need like 90%
of miners to upgrade just a
561
00:28:59,640 --> 00:29:03,680
signal that they did so and and
you know, and safely enforce it
562
00:29:03,680 --> 00:29:07,560
so that there's no longer.
That depends on how you what
563
00:29:07,560 --> 00:29:10,480
settings you use, right?
If if we ignore all the UAF
564
00:29:10,480 --> 00:29:13,280
stuff, the the normal way that
software have been deployed so
565
00:29:13,280 --> 00:29:17,320
far, most of them, all of them
depending on who you ask, is 90%
566
00:29:17,320 --> 00:29:19,520
of the miners signal that
they're ready to enforce it.
567
00:29:19,520 --> 00:29:22,640
Which means that if a miner
doesn't upgrade, the air block
568
00:29:22,760 --> 00:29:26,240
gets orphaned.
But there's not going to be a
569
00:29:26,240 --> 00:29:28,760
long change plate because if
only half the miners enforce the
570
00:29:28,760 --> 00:29:32,040
software, then you might get 2
roughly equally sized block
571
00:29:32,040 --> 00:29:34,520
chains going in different ways
and it becomes an absolute mess.
572
00:29:35,640 --> 00:29:37,920
So.
Strictly speaking, I think the
573
00:29:37,920 --> 00:29:41,880
90% number has only been used
once with that route, but that's
574
00:29:41,880 --> 00:29:44,520
another top because I think SEC
Wiz was 95%.
575
00:29:45,040 --> 00:29:46,480
That's even safer.
Yeah, sure.
576
00:29:46,760 --> 00:29:50,800
And and then of course, there's,
well, I, well, that's not
577
00:29:50,800 --> 00:29:52,560
really.
The point is what happens with
578
00:29:52,560 --> 00:29:54,400
miners that.
Don't I think during the block
579
00:29:54,400 --> 00:29:58,040
size was one of the whatever the
thing was called that was like
580
00:29:58,480 --> 00:30:04,360
that was that happened even
lower like 75% Anyways, let's
581
00:30:04,400 --> 00:30:06,280
say that was not the Bickel core
thing.
582
00:30:06,280 --> 00:30:08,200
That was the no the Jeff Garzik,
the.
583
00:30:08,200 --> 00:30:11,520
Question is in this in this way
that you know some people would
584
00:30:11,520 --> 00:30:13,840
like to see soft works happen.
What happens to the miners that
585
00:30:13,840 --> 00:30:16,840
don't upgrade?
Now usually there's some.
586
00:30:17,560 --> 00:30:19,800
For example, the one of the
reasons for standardness
587
00:30:19,800 --> 00:30:23,240
transactions is that if there's
a soft work, the new transaction
588
00:30:23,240 --> 00:30:26,000
type that appears in the soft
work is non standard for the
589
00:30:26,000 --> 00:30:28,720
older nodes.
So an old minor will think a
590
00:30:28,720 --> 00:30:31,000
transaction is non standard and
won't include it in their
591
00:30:31,000 --> 00:30:33,120
blocks.
So you cannot accidentally
592
00:30:33,120 --> 00:30:36,120
violate the rules of a soft work
when it comes to transactions,
593
00:30:36,120 --> 00:30:37,640
even if you as a minor do an
upgrade.
594
00:30:38,840 --> 00:30:41,360
Let's get away from the soft
work topic and let's go to the
595
00:30:41,360 --> 00:30:43,560
time warp topic.
So what?
596
00:30:43,560 --> 00:30:46,720
What is the time warp attack?
The time warp attack is is
597
00:30:46,800 --> 00:30:50,960
basically shenanigans with the
timestamp where you make it look
598
00:30:50,960 --> 00:30:53,480
by basically messing with the
timestamps.
599
00:30:53,480 --> 00:30:57,760
You make it look like the the
block period was 4 weeks instead
600
00:30:57,760 --> 00:31:00,560
of two weeks or six weeks
instead of two weeks.
601
00:31:01,160 --> 00:31:04,520
And then the difficulty goes
down and you do this by because
602
00:31:04,520 --> 00:31:08,240
the the timestamp of the first
block, basically the difficulty
603
00:31:08,240 --> 00:31:11,320
adjustment looks at that the
last block of the period minus
604
00:31:11,320 --> 00:31:14,600
the first block of the period
instead of what it should have
605
00:31:14,600 --> 00:31:16,920
done, the first block of the new
period minus the first block of
606
00:31:16,920 --> 00:31:18,720
the old period.
So because it doesn't overlap,
607
00:31:18,720 --> 00:31:21,200
you can mess with the
timestamps, you decrease the
608
00:31:21,200 --> 00:31:25,720
difficulty very rapidly and
somebody can basically destroy
609
00:31:25,720 --> 00:31:29,160
that, basically bring the
difficulty back to one which is
610
00:31:29,160 --> 00:31:33,920
basically ACPU miner in 38 days
I believe.
611
00:31:33,920 --> 00:31:37,720
And then they can just mine all
the remaining subsidy and it
612
00:31:37,720 --> 00:31:43,000
create a complete mess.
This is a hypothetical form of
613
00:31:43,000 --> 00:31:45,720
attack that could be done, but
then there's well.
614
00:31:46,080 --> 00:31:47,600
It's not hypothetical.
You can just do it.
615
00:31:47,680 --> 00:31:52,480
Yeah, it's a bad idea, probably.
I mean, it's not that easy
616
00:31:52,480 --> 00:31:54,320
either.
You need a majority of minors,
617
00:31:54,320 --> 00:31:56,000
right?
So yeah, I mean, OK.
618
00:31:56,840 --> 00:31:59,440
You need a majority of minors
too, but so the main concern
619
00:31:59,440 --> 00:32:03,480
would be not a full time we'll
protect, but limited time we'll
620
00:32:03,480 --> 00:32:05,280
protect.
For example, you can double the
621
00:32:05,280 --> 00:32:07,560
speed of blocks to have one
block every 5 minutes.
622
00:32:08,200 --> 00:32:12,960
That means minors are getting
paid 2 times the subsidy per day
623
00:32:12,960 --> 00:32:17,800
or per hour or per week, and
everybody gets, you know, double
624
00:32:17,800 --> 00:32:20,680
the block size.
I mean, that's, you know, at
625
00:32:20,680 --> 00:32:24,880
least something you can imagine
actually happening and would
626
00:32:24,880 --> 00:32:25,560
still be.
Very bad.
627
00:32:25,560 --> 00:32:32,040
I mean, I'm not yes, agreed, but
and now there's a salute or
628
00:32:32,040 --> 00:32:35,920
there solution again there is
like a proposed solution for
629
00:32:35,920 --> 00:32:37,760
that that might be rolled out in
the future.
630
00:32:37,760 --> 00:32:40,480
So what is the proposed solution
that might be rolled out in the
631
00:32:40,480 --> 00:32:42,760
future?
So the proposed solution really
632
00:32:42,760 --> 00:32:46,640
boils down to putting some tie
wrap around the last block of
633
00:32:46,640 --> 00:32:49,760
the period and the first block
of the new period.
634
00:32:50,320 --> 00:32:52,680
Because right now they it's like
they can just shift, you can
635
00:32:52,680 --> 00:32:55,120
shift them all the way back.
But if you tie wrap them
636
00:32:55,120 --> 00:32:57,160
together, you can no longer mess
with the timestamp.
637
00:32:57,400 --> 00:33:00,320
And so the actual rule is the
first block of the new period
638
00:33:00,320 --> 00:33:05,960
must be no older than the last
block of the previous period -2
639
00:33:05,960 --> 00:33:09,080
hours.
OK.
640
00:33:10,000 --> 00:33:15,560
So yeah, we we just had a block
period of two weeks.
641
00:33:16,000 --> 00:33:21,480
The last block was mined at, you
know, January 1st at noon.
642
00:33:22,000 --> 00:33:25,960
So that means that the first
block of the next period, the
643
00:33:25,960 --> 00:33:32,240
time stamp in that block can be
at the earliest 10 AM on January
644
00:33:32,240 --> 00:33:35,960
1st, right?
Yes, that's that's the proposed
645
00:33:35,960 --> 00:33:39,320
rule.
That proposed rule is there to
646
00:33:39,680 --> 00:33:42,880
prevent this time warp attack.
Exactly prevents you from
647
00:33:42,880 --> 00:33:44,800
setting the time stamp date 2
weeks in the past.
648
00:33:45,480 --> 00:33:47,800
Right, but now there's another
problem.
649
00:33:49,040 --> 00:33:51,080
Yes, the.
Problem is there's now now
650
00:33:51,080 --> 00:33:53,320
there's a problem with the
solution that needs to be fixed
651
00:33:53,320 --> 00:33:56,880
exactly and again the the the
solution, this solution is
652
00:33:56,880 --> 00:34:00,160
actually now in Bitcoin Core for
the future problem potentially
653
00:34:00,160 --> 00:34:02,600
exactly and what is the.
Solution Now test net 4 already
654
00:34:02,600 --> 00:34:05,440
has test net four.
Well the problem is can be seen
655
00:34:05,440 --> 00:34:08,000
on test net 4 because test net 4
does have the time warp fixed
656
00:34:08,280 --> 00:34:10,440
deployed.
However, it instead of two
657
00:34:10,440 --> 00:34:12,440
hours, it uses 10 minutes as the
rule.
658
00:34:12,800 --> 00:34:16,600
So if your block was mined at
12:00, the last blocking period,
659
00:34:16,600 --> 00:34:19,480
the first block of the new
period must be mined at no
660
00:34:19,560 --> 00:34:24,159
earlier, sorry, no earlier than
10 minutes before 12.
661
00:34:24,280 --> 00:34:28,800
Yeah, 1150 AMI.
Think if yeah exactly.
662
00:34:29,120 --> 00:34:34,600
Now the problem is that a if if
you let's say they're the last
663
00:34:34,600 --> 00:34:38,159
miner is a bit mean the miner of
the last clock, they can put
664
00:34:38,159 --> 00:34:40,760
their timestamp 2 hours in the
future cause Bitcoin Core allows
665
00:34:40,760 --> 00:34:44,760
up to two hours in the future.
So now you are mining, and if
666
00:34:44,760 --> 00:34:47,320
you're just using your clock,
you will just use the time of
667
00:34:47,320 --> 00:34:51,400
today right now.
But we've just said that you
668
00:34:51,480 --> 00:34:55,440
have to be less than 10 minutes
in the past from the last block.
669
00:34:56,199 --> 00:34:59,480
So now you've created an invalid
block under the new time warp.
670
00:34:59,480 --> 00:35:02,800
Rules.
OK, so indeed you sure you are?
671
00:35:03,200 --> 00:35:08,200
You are mining and then because
you're a criminal and a troll,
672
00:35:08,760 --> 00:35:13,320
you mine a block at noon on
January 1st, but you put the
673
00:35:13,320 --> 00:35:16,360
timestamp in it of 2:00 PM
exactly.
674
00:35:16,360 --> 00:35:19,720
And now I'm also mining and I'm
like a nice honest guy.
675
00:35:20,160 --> 00:35:25,400
So I now find the next block at
10 past twelve, 12:10.
676
00:35:25,400 --> 00:35:28,320
You know, I'm just putting the
honest time in there.
677
00:35:28,360 --> 00:35:31,160
But then because you were
trolling and put the timestamp
678
00:35:31,160 --> 00:35:35,480
in the future, now my block that
is actually telling the truth
679
00:35:35,480 --> 00:35:37,920
with the time stamp, that one is
now considered on valid.
680
00:35:38,080 --> 00:35:40,840
Exactly.
So you successfully trolled me
681
00:35:40,840 --> 00:35:42,800
and robbed me of my money.
Exactly.
682
00:35:42,800 --> 00:35:45,440
Well, you didn't get the money,
but at least I didn't get it.
683
00:35:45,440 --> 00:35:49,120
Either I told you that that I
may have trolled the person
684
00:35:49,120 --> 00:35:49,520
after.
You.
685
00:35:49,520 --> 00:35:50,600
It's a source of pleasure for
you.
686
00:35:51,480 --> 00:35:53,720
Yeah, well, I told you I may
have trolled the person after
687
00:35:53,720 --> 00:35:56,120
you because people may try keep
finding the first block and
688
00:35:56,120 --> 00:35:58,400
until actually two hours have
passed, they will lose.
689
00:35:58,920 --> 00:36:00,760
So there's two solutions to
this.
690
00:36:00,960 --> 00:36:04,560
One is that we just made the
margin 2 hours so that you can't
691
00:36:04,560 --> 00:36:06,960
really exploit this anymore
because you can't put the clock
692
00:36:06,960 --> 00:36:08,440
more than two hours in the
future.
693
00:36:08,560 --> 00:36:10,720
So while you can't attack.
Somebody who uses the real
694
00:36:10,720 --> 00:36:11,280
clock.
Right.
695
00:36:11,280 --> 00:36:13,720
So while on test net it's 10
minutes.
696
00:36:14,360 --> 00:36:17,520
So that's why the example that I
just gave worked on the actual
697
00:36:17,520 --> 00:36:22,280
main net the the difference is 2
hours, it's two hours.
698
00:36:22,280 --> 00:36:27,320
So even if you try to troll me
by putting the clock 2 hours in
699
00:36:27,320 --> 00:36:32,440
the future on your minor, then
me the honest guy with the real
700
00:36:32,440 --> 00:36:35,280
time in the block, that's still
going to be fine because there's
701
00:36:35,280 --> 00:36:40,040
a margin of two hours exactly.
But so OK, so that was but.
702
00:36:40,040 --> 00:36:43,440
Basically, you want yeah, but
it's not, you know, it's nice to
703
00:36:43,440 --> 00:36:46,840
solve a problem in multiple
ways, I guess just to make sure
704
00:36:46,840 --> 00:36:49,920
that it really works.
And this solution also works in
705
00:36:49,920 --> 00:36:52,760
Test Net 4, so that's kind of
nice with this fight being more
706
00:36:52,760 --> 00:36:54,160
strict rule.
The nice thing about Test Net 4
707
00:36:54,160 --> 00:36:55,720
is it helps reveal bugs like
this.
708
00:36:55,720 --> 00:36:57,480
But we know what.
What is the solution?
709
00:36:57,480 --> 00:37:01,400
The the solution is that Bitcoin
Core rule when it creates a box
710
00:37:01,400 --> 00:37:03,720
template, it also provides some
hints of what you know.
711
00:37:03,960 --> 00:37:06,640
Remember you have to make your
own Coinbase, but Bitcoin Core
712
00:37:06,640 --> 00:37:08,640
will give you hints of what to
put in that Coinbase.
713
00:37:08,840 --> 00:37:10,560
And one of the hints is the
minimum time.
714
00:37:11,520 --> 00:37:14,680
So it will say your time stamp
must be at least this time
715
00:37:14,680 --> 00:37:16,720
stamp.
So it will tell you your time
716
00:37:16,720 --> 00:37:19,040
stamp should be one hour and 15
minutes in the future.
717
00:37:19,480 --> 00:37:21,640
And as long as your mining
software actually pays attention
718
00:37:21,640 --> 00:37:25,080
to that, they should be fine.
Now we found some open source
719
00:37:25,080 --> 00:37:28,080
software that did not pay
attention to that hint, so that
720
00:37:28,080 --> 00:37:31,400
even if Bitcoin Core fixes this,
they're still they still have a
721
00:37:31,400 --> 00:37:33,640
problem because they're not
looking at the hint that Bitcoin
722
00:37:33,640 --> 00:37:35,880
Core gives them.
Though we don't know if mining
723
00:37:35,880 --> 00:37:39,120
pools have this bug because all
the mining pool software is
724
00:37:39,120 --> 00:37:41,960
closed source.
That's why you want to have a
725
00:37:42,000 --> 00:37:44,520
sort of a double solution.
Hang on here, here's let me
726
00:37:44,520 --> 00:37:46,960
repeat the solution just to make
sure I got that part right.
727
00:37:47,040 --> 00:37:50,400
Yeah.
OK, so it's it's noon on January
728
00:37:50,400 --> 00:37:54,400
1st and you shores are mining
and trolling and putting the
729
00:37:54,400 --> 00:37:57,560
time stamp in there of two to
2:00 PM.
730
00:37:58,240 --> 00:38:00,960
Now me I'm also mining super on
the sky.
731
00:38:01,400 --> 00:38:05,200
I want to put the real time in
there, but then Bitcoin Core
732
00:38:05,200 --> 00:38:08,160
says no, no, no.
If you're being honest right
733
00:38:08,160 --> 00:38:10,520
now, then your block will be
invalid.
734
00:38:10,680 --> 00:38:13,720
So you also have to throw along
with yours.
735
00:38:14,000 --> 00:38:15,800
Yeah.
And then I will put the block
736
00:38:15,800 --> 00:38:18,800
time also at like 2:00 PM or two
one or whatever.
737
00:38:18,800 --> 00:38:21,120
And and generally Bitcoin Core
will give you 2 values.
738
00:38:21,120 --> 00:38:24,160
It does that for every block.
It says the minimum time like do
739
00:38:24,160 --> 00:38:27,680
not go below this number and
it's a field called the current
740
00:38:27,680 --> 00:38:29,480
time.
But now it's going to lie about
741
00:38:29,480 --> 00:38:32,080
the current time.
OK, so because you were lying
742
00:38:32,080 --> 00:38:36,640
and cheating and stealing and,
you know, being your usual self.
743
00:38:36,640 --> 00:38:40,320
Now I go along in that in that
behaviour, but only for the
744
00:38:40,320 --> 00:38:43,600
first block of the period after
that, because that's the time
745
00:38:43,600 --> 00:38:45,960
warp block, sort of that's
that's where that matters.
746
00:38:46,320 --> 00:38:49,840
And then whoever is mining after
me, he they, they all start
747
00:38:49,840 --> 00:38:51,960
using the real time again.
Yes, right.
748
00:38:52,160 --> 00:38:54,640
OK, so.
Beacon Core will suggest the
749
00:38:54,640 --> 00:38:57,640
real time again, yeah.
When you say, suggest.
750
00:38:59,200 --> 00:39:01,960
It's so many suggestions Bitcoin
Bitcoin Core says you should put
751
00:39:02,040 --> 00:39:04,120
put this stuff in the block,
these transactions and it says
752
00:39:04,120 --> 00:39:08,960
you should put this time stamp
in the block with one field
753
00:39:08,960 --> 00:39:10,120
saying this is the absolute
minimum.
754
00:39:10,120 --> 00:39:12,440
So maybe you don't want to use
the time stamp that Bitcoin core
755
00:39:12,440 --> 00:39:15,640
suggests for whatever reason,
but it does say that do not go
756
00:39:15,640 --> 00:39:18,560
below this number again, we
don't know what minors are doing
757
00:39:18,560 --> 00:39:22,520
because it's all closed source.
Now on Test Net 4, there's
758
00:39:22,520 --> 00:39:26,400
another weird, weird little
thing that exposes this problem.
759
00:39:26,400 --> 00:39:30,720
So there is another rule called
the MTP rule, which is that like
760
00:39:31,080 --> 00:39:36,880
the the the time stamp of every
block has to be higher than the
761
00:39:36,880 --> 00:39:38,960
median time stamp of the last 11
blocks.
762
00:39:38,960 --> 00:39:41,200
I don't know if you're familiar
with that rule.
763
00:39:41,200 --> 00:39:42,880
I mean, I've heard of it, yeah.
Yeah.
764
00:39:42,880 --> 00:39:46,200
So in practice that tends to
mean that you your time stamp
765
00:39:46,200 --> 00:39:49,880
must be at least no more than
one hour in the past or
766
00:39:49,920 --> 00:39:52,280
something like that, right?
Because it's six blocks per
767
00:39:52,280 --> 00:39:54,320
hour.
So typically the the median
768
00:39:54,320 --> 00:39:58,440
block from the last 11 would be
the middle one, which is about
769
00:39:58,440 --> 00:40:01,760
an hour old.
But typically your minimum time
770
00:40:01,760 --> 00:40:04,240
is about an hour in the past.
So you don't even pay attention
771
00:40:04,240 --> 00:40:05,600
to this.
You don't pay attention to
772
00:40:05,600 --> 00:40:07,160
minimum time, you just use the
current time.
773
00:40:07,880 --> 00:40:11,240
But on test net 4, there's some
crazy people that are CPU mining
774
00:40:11,760 --> 00:40:14,600
as much as they can and they're
putting blocks 2 hours in the
775
00:40:14,600 --> 00:40:16,840
future to CPU mine for weird
reasons.
776
00:40:17,960 --> 00:40:21,480
So because all these miners are
putting their blocks 2 hours in
777
00:40:21,480 --> 00:40:25,040
the future, the actual medium
time past is one hour in the
778
00:40:25,040 --> 00:40:26,640
future, not one hour in the
past.
779
00:40:27,760 --> 00:40:32,440
So if a minor does not use the
field that the concord gives
780
00:40:32,440 --> 00:40:34,800
them the mean time and the
current time field which are
781
00:40:34,800 --> 00:40:38,320
both lies, well the current time
field is a lie because the
782
00:40:38,320 --> 00:40:40,880
mining code will say you you
must use one hour in the future
783
00:40:40,880 --> 00:40:42,480
as a time stamp, otherwise it's
invalid.
784
00:40:43,400 --> 00:40:46,120
You seem confused.
I mean you are getting very into
785
00:40:46,120 --> 00:40:48,640
the day and I also are you
talking about you're talking
786
00:40:48,640 --> 00:40:51,160
about test net now, right?
This is test net.
787
00:40:51,160 --> 00:40:53,920
I don't.
I don't care about test net.
788
00:40:53,920 --> 00:40:57,120
Well, test net is how we found
this problem basically because
789
00:40:57,120 --> 00:41:00,480
the these people are doing weird
things in test net, being DGNS,
790
00:41:02,120 --> 00:41:04,840
timestamps in test net are
actually in the future, which is
791
00:41:04,840 --> 00:41:09,040
not doesn't happen on mainnet.
And therefore the Bitcoin Core
792
00:41:09,040 --> 00:41:11,240
mining code always tells you to
lie.
793
00:41:11,240 --> 00:41:13,360
It always says you, you should
produce a block one hour in the
794
00:41:13,360 --> 00:41:14,520
future or it's going to be
invalid.
795
00:41:14,880 --> 00:41:17,040
And especially around that time
warp window, of course, it's
796
00:41:17,040 --> 00:41:19,320
even more clear.
And then people started
797
00:41:19,320 --> 00:41:22,000
producing invalid blocks and
they were like, why am I
798
00:41:22,040 --> 00:41:24,280
producing invalid blocks?
Well, that's because your
799
00:41:24,280 --> 00:41:26,760
software is not checking these
values that Picon Core is
800
00:41:26,760 --> 00:41:32,480
telling you to use.
So so that happened, but it was
801
00:41:32,480 --> 00:41:35,760
with some open source mining
projects and maybe the real
802
00:41:35,760 --> 00:41:39,520
mining projects do actually
check the hint because otherwise
803
00:41:39,520 --> 00:41:43,440
this could happen on mainnet.
Let's move to the next topic.
804
00:41:43,440 --> 00:41:45,680
I think right we're we're done
with the.
805
00:41:46,280 --> 00:41:52,000
Yeah, I think so.
Time Warp potential future
806
00:41:52,000 --> 00:41:54,360
attack solution that's been
implemented.
807
00:41:54,720 --> 00:41:57,360
I think we'll we'll do the other
3 tip topics a little quickly.
808
00:41:58,200 --> 00:42:01,920
Yeah, that sounds good.
I mean the the OK, the first one
809
00:42:01,920 --> 00:42:06,560
is we can run through this in,
let's see, in 20 seconds.
810
00:42:06,720 --> 00:42:08,840
Yeah, I think the mainstream
media has already covered this
811
00:42:08,840 --> 00:42:13,680
one, right?
OK, mem pool or the four RBF is
812
00:42:13,680 --> 00:42:16,920
now the standard in Baker core.
There are no other options.
813
00:42:17,240 --> 00:42:20,680
Exactly.
So if you run a Bitcoin note and
814
00:42:20,680 --> 00:42:24,040
you receive a transaction and
then you receive a conflicting
815
00:42:24,040 --> 00:42:27,360
transaction, so spending the
same coins but that has a higher
816
00:42:27,360 --> 00:42:30,840
fee, then now you know, it will
say that's perfectly fine by me.
817
00:42:30,840 --> 00:42:32,800
I'll just take this one and
throw the other one.
818
00:42:32,800 --> 00:42:34,920
Out it's more complicated than
just a higher fee.
819
00:42:35,520 --> 00:42:38,120
It's but you don't need to
signal anymore because it used
820
00:42:38,120 --> 00:42:40,560
to be that we would only like we
would take the first transaction
821
00:42:40,560 --> 00:42:44,920
seen unless it's signalled this,
this RBF flag, then we would
822
00:42:44,920 --> 00:42:47,920
say, OK, we'll look at the fees.
But we also look at the, the
823
00:42:47,920 --> 00:42:49,800
rate has to be higher.
The absolute fee has to be
824
00:42:49,800 --> 00:42:52,040
higher.
A bunch of other rules that
825
00:42:52,040 --> 00:42:53,520
decide whether you replace it or
not.
826
00:42:54,400 --> 00:42:55,480
Oh, OK.
Yeah, yeah.
827
00:42:55,680 --> 00:42:58,400
I mean, sure.
The the marketeers always like
828
00:42:58,400 --> 00:43:00,400
to say, oh, we just replaced
everything with a better fee.
829
00:43:00,400 --> 00:43:02,920
It's like, yeah, it's more
complicated, but anyway, that's
830
00:43:02,920 --> 00:43:04,720
the default now.
We've done multiple episodes on
831
00:43:04,720 --> 00:43:08,360
RBF and mental fool RBF so.
Yeah, I think including the last
832
00:43:08,440 --> 00:43:12,360
one.
So step by step Bitcoin Core has
833
00:43:12,360 --> 00:43:16,560
been, you know, moving more
towards a world where highest
834
00:43:16,560 --> 00:43:19,920
fee just sort of wins.
Of course, Needless to say, but
835
00:43:19,920 --> 00:43:23,000
I'll say it anyways.
This is all before a transaction
836
00:43:23,000 --> 00:43:25,400
is included in the block, before
a transaction.
837
00:43:25,400 --> 00:43:29,400
So which transaction is a minor
going to include in a block
838
00:43:30,240 --> 00:43:33,800
rather than looking at which
transaction is received first or
839
00:43:33,800 --> 00:43:36,320
like this flag that you
mentioned, it will just say OK,
840
00:43:36,320 --> 00:43:39,400
this one is paying a higher fee.
Unconfirmed transactions are
841
00:43:39,400 --> 00:43:40,960
unsafe.
They were always unsafe.
842
00:43:40,960 --> 00:43:44,920
They are now marginally more
unsafe, but that's sort of the
843
00:43:44,920 --> 00:43:47,040
the direction.
This was sort of slowly coming.
844
00:43:47,040 --> 00:43:49,040
There was mostly an argument
about how soon.
845
00:43:50,480 --> 00:43:53,920
OK, we far exceeded our 22nd
limit for that one, so let's
846
00:43:53,920 --> 00:43:56,800
move on to the next one, which
is Cmake.
847
00:43:57,200 --> 00:43:58,600
Yes.
So as a user, you won't notice
848
00:43:58,600 --> 00:44:01,240
anything, but this was a giant
change under the hood in the way
849
00:44:01,240 --> 00:44:04,000
that you go from the source code
to the actual binary.
850
00:44:04,000 --> 00:44:07,640
So source code stays more or
less the same, binary stays more
851
00:44:07,640 --> 00:44:09,920
or less the same, like at least
you know from what you
852
00:44:09,920 --> 00:44:13,600
experienced as a user.
But the way you go from source
853
00:44:13,600 --> 00:44:17,080
to binary has been revamped by
using this thing called Cmake
854
00:44:17,080 --> 00:44:18,720
that everybody else already
used.
855
00:44:20,040 --> 00:44:21,840
And yeah, this makes things much
better.
856
00:44:21,920 --> 00:44:24,760
Yeah, so source and other
Bitcoin developers, they're
857
00:44:24,760 --> 00:44:28,040
writing their codes on their on
their keyboards, and it looks
858
00:44:28,040 --> 00:44:31,640
all like C + + C, but then your
computer needs to translate it
859
00:44:31,640 --> 00:44:34,440
into ones and zeros.
And now there's a new way for
860
00:44:34,440 --> 00:44:37,720
computers to translate.
Yes, we used to type make and
861
00:44:38,280 --> 00:44:41,680
then hit enter and now we type T
make and then hit enter.
862
00:44:43,280 --> 00:44:47,000
It's not what I was referring
to, but also good to know for
863
00:44:47,000 --> 00:44:49,800
people that you know well.
That must be a drag though.
864
00:44:49,800 --> 00:44:52,080
That's like an extra.
An extra character.
865
00:44:52,080 --> 00:44:54,720
Character you have to.
You can, you can.
866
00:44:54,840 --> 00:44:56,800
You can make shortcuts, so it
doesn't matter.
867
00:44:58,200 --> 00:45:02,040
OK, again, nothing that regular
users like myself will ever
868
00:45:02,040 --> 00:45:05,040
notice, but developers.
You'll see fewer grumpy
869
00:45:05,040 --> 00:45:08,480
developers, but yeah, that's
about it.
870
00:45:11,240 --> 00:45:15,400
You're you're always even.
You sure even even the?
871
00:45:15,840 --> 00:45:17,160
I don't work on the build
system.
872
00:45:17,280 --> 00:45:18,840
You will see fewer, you will see
more.
873
00:45:18,840 --> 00:45:20,880
Happy build system developers,
let's put it that way.
874
00:45:21,960 --> 00:45:22,320
All right.
OK.
875
00:45:22,320 --> 00:45:24,720
Last one then we're we're almost
there.
876
00:45:26,640 --> 00:45:29,880
Oh, UTXO to SQLite.
That's also there's a new
877
00:45:29,880 --> 00:45:35,640
feature in between core which is
you can dump the UTXO set into
878
00:45:35,680 --> 00:45:39,400
SQL light wait.
SQL light, yeah, or SQL light
879
00:45:39,400 --> 00:45:40,840
depending on who you are
exactly.
880
00:45:41,480 --> 00:45:45,240
So it there it's been possible
for a while to make a snapshot
881
00:45:45,240 --> 00:45:48,280
of the UTXO set just to dump it.
That's used by a zoom UTXO as
882
00:45:48,280 --> 00:45:51,000
well to load the UTXO set.
But you can do it at any height
883
00:45:51,720 --> 00:45:53,720
and it's just a list of every
coin that exists.
884
00:45:53,720 --> 00:45:57,920
But the format is very unusable.
So there's now a little script
885
00:45:57,920 --> 00:46:02,000
that takes that unusable format
and turns it into a SQLite file,
886
00:46:02,000 --> 00:46:05,000
which is much easier to edit.
It's not a spreadsheet quite
887
00:46:05,000 --> 00:46:07,760
yet, but it's a lot closer for
most people than know what to do
888
00:46:07,760 --> 00:46:09,880
with databases.
So it's a it's basically a
889
00:46:09,880 --> 00:46:11,840
research tool.
If you want to study what is
890
00:46:11,840 --> 00:46:15,000
what coins exists, or maybe you
want to make multiple snapshots
891
00:46:15,000 --> 00:46:18,520
over time and and compare, you
know how the YouTube show set
892
00:46:18,520 --> 00:46:21,720
changes over time.
This will make your life easier.
893
00:46:22,760 --> 00:46:23,600
Yeah.
OK.
894
00:46:23,600 --> 00:46:27,600
So it's basically a new tool for
like, you know, data nerds.
895
00:46:27,800 --> 00:46:29,480
Exactly.
Researchers that want to like
896
00:46:29,480 --> 00:46:34,800
figure out how are coins moving
over the blockchain or how are
897
00:46:35,480 --> 00:46:38,800
coins distributed across
different addresses?
898
00:46:38,800 --> 00:46:43,720
And how long does it take before
UTX OS are spent compared to
899
00:46:43,720 --> 00:46:46,640
other UTX OS or like whatever
you may come up with and you
900
00:46:46,640 --> 00:46:50,480
want to research now there's an
easier tool to get that data
901
00:46:50,480 --> 00:46:54,280
from Bitcoin Core into whatever,
so.
902
00:46:55,000 --> 00:46:57,240
So anyway, go to
bitcoincore.org, download
903
00:46:57,480 --> 00:47:03,360
version 29, do the checks for
the checksums and have fun with
904
00:47:03,360 --> 00:47:05,920
it.
So is that that all we got?
905
00:47:07,800 --> 00:47:10,280
Where can they?
Where can find Where can people
906
00:47:10,280 --> 00:47:13,200
find Bitcoin Core 29 shorts?
Bitcoincore.org.
907
00:47:13,200 --> 00:47:14,640
Did you already mention?
That I did.
908
00:47:14,960 --> 00:47:16,840
Good, good that we're there, all
right.
909
00:47:16,840 --> 00:47:18,320
Thank you for listening to
Bitcoin.
910
00:47:18,320 --> 00:47:19,120
Explain.