Episode 93: The Great Consensus Cleanup Revival (And an Update on the Tornado Cash and Samourai Wallet Arrests)

1
00:00:19,890 --> 00:00:22,090
Life of interest This is
Bitcoin.
2
00:00:22,090 --> 00:00:24,970
Explained.
Sure, it's been a month.
3
00:00:25,410 --> 00:00:28,930
That means you had a whole month
to think about this poem that
4
00:00:28,930 --> 00:00:30,170
you told me you're going to
tell.
5
00:00:31,130 --> 00:00:33,960
All right.
Dear listeners for this episode,
6
00:00:34,080 --> 00:00:35,080
let's hear it.
Let's hear it.
7
00:00:35,160 --> 00:00:37,720
That's right.
So it's cold outside.
8
00:00:38,240 --> 00:00:41,000
The government is cold.
You know what else is cold?
9
00:00:42,520 --> 00:00:44,960
Source our sponsor.
That's right.
10
00:00:45,320 --> 00:00:49,160
The cold card, The cold card?
If you have coins you want to
11
00:00:49,160 --> 00:00:51,640
store them.
Cold card is the place for that.
12
00:00:51,640 --> 00:00:54,000
Is the audio OK?
Are we too loud?
13
00:00:54,160 --> 00:00:56,400
It's too much echo.
Too much echo.
14
00:00:57,480 --> 00:01:03,240
OK, Cold card, Cold card.
Cold card, cold card, cold cart.
15
00:01:03,600 --> 00:01:08,040
I think that was like our 20
seconds that we're obligated to
16
00:01:08,120 --> 00:01:09,680
talk about the cold cart.
What do you think?
17
00:01:09,680 --> 00:01:12,160
I think it's great, but it's a
hardware wallet for people who
18
00:01:12,160 --> 00:01:13,080
don't know.
Yes.
19
00:01:13,080 --> 00:01:15,880
Why did you say the government
is called?
20
00:01:16,040 --> 00:01:18,200
Well, that's a segue to our next
section.
21
00:01:19,760 --> 00:01:24,000
So this episode we're going to
talk about the Great Consensus
22
00:01:24,000 --> 00:01:29,040
Clean Up revival, which is a
proposed soft work, which sort
23
00:01:29,040 --> 00:01:31,920
of includes several soft forks
into one.
24
00:01:31,920 --> 00:01:34,520
You could kind of argue, right?
Basically, that's what it comes
25
00:01:34,520 --> 00:01:37,040
down to.
But before that, a lot has
26
00:01:37,040 --> 00:01:41,440
happened in the Bitcoin and
Ethereum space in a way that's
27
00:01:41,440 --> 00:01:45,840
relevant to Bitcoin as well.
So you want to touch on that a
28
00:01:45,840 --> 00:01:48,000
little bit first.
You'll be following it pretty
29
00:01:48,000 --> 00:01:52,320
closely.
Let's start with where do we
30
00:01:52,320 --> 00:01:54,240
start?
Let's start with what happened
31
00:01:54,240 --> 00:01:55,960
with Tornado Cash in the
Netherlands.
32
00:01:55,960 --> 00:01:59,400
Yeah, in case anybody was living
under a rock, the Tornado Cash,
33
00:01:59,400 --> 00:02:05,920
we talked about that in episode
69, but he got convicted, so
34
00:02:05,920 --> 00:02:10,280
that's bad.
Yeah, Alexei Persev, one of the
35
00:02:10,280 --> 00:02:14,440
Tornado Cash developers, got
convicted for 64 months in
36
00:02:14,440 --> 00:02:15,480
prison.
Yep.
37
00:02:16,160 --> 00:02:20,120
Which does seem to have a lot of
relevance for Bitcoin because
38
00:02:20,960 --> 00:02:22,960
really he was just writing
codes.
39
00:02:23,720 --> 00:02:26,000
You know, he was writing privacy
code, but he was never.
40
00:02:26,440 --> 00:02:27,720
Maybe he should give the
context.
41
00:02:27,720 --> 00:02:30,080
Why do you think it's relevant
for Bitcoin?
42
00:02:30,640 --> 00:02:33,840
Well, the main point of
relevance for us I think is the
43
00:02:33,840 --> 00:02:36,280
fact that he was building a non
custodial system.
44
00:02:36,280 --> 00:02:40,040
So a system that does not hold
the coins yourself.
45
00:02:40,040 --> 00:02:42,480
I mean there is, you know, a
website and those kind of tools.
46
00:02:44,080 --> 00:02:47,080
So that's that's a very
dangerous precedent, I think
47
00:02:47,080 --> 00:02:49,160
because it's not very clear
where that line is.
48
00:02:49,560 --> 00:02:53,240
Yeah, we already knew that
running a custodial mixer, which
49
00:02:53,280 --> 00:02:55,960
a lot of other mixers were,
where you just send coins to
50
00:02:55,960 --> 00:02:58,320
someone and that someone sends
different coins back.
51
00:02:58,960 --> 00:03:02,200
That was always illegal and
everyone knew that was illegal.
52
00:03:02,200 --> 00:03:04,280
If you're doing that, that's
that's basically money
53
00:03:04,280 --> 00:03:07,320
laundering and that is illegal.
Well, I think you can narrow it
54
00:03:07,320 --> 00:03:09,760
down slightly.
It's not illegal to mix the
55
00:03:09,760 --> 00:03:12,880
coins, but it is when you don't
do KYC.
56
00:03:13,280 --> 00:03:16,520
I guess that's maybe a different
interpretation, but for for the,
57
00:03:16,560 --> 00:03:18,920
you know, for all practical
purposes you can't build a a
58
00:03:19,000 --> 00:03:22,080
mixer with KYC in an ethical way
anyway.
59
00:03:22,840 --> 00:03:25,880
So it, you know, effectively
mixers are illegal.
60
00:03:25,880 --> 00:03:29,400
But technically I think the the
non KYC part of the mixer is
61
00:03:29,400 --> 00:03:31,040
what makes it illegal.
Fair enough.
62
00:03:31,520 --> 00:03:35,160
In either case, so far it was
generally assumed that yeah, if
63
00:03:35,160 --> 00:03:37,840
you're taking coins and they're
sending other coins, then you,
64
00:03:37,880 --> 00:03:41,040
you're at risk.
But if you're just developing
65
00:03:41,040 --> 00:03:44,040
software which allows other
people to send their coins to
66
00:03:44,040 --> 00:03:47,280
other people, then you know that
that then that you're not the
67
00:03:47,280 --> 00:03:50,880
one money laundering.
However, the Dutch court just
68
00:03:50,880 --> 00:03:53,200
tracked it down and now it looks
like Nope.
69
00:03:53,200 --> 00:03:57,160
Just developing codes can make
you responsible for how other
70
00:03:57,160 --> 00:04:00,320
people use that code, right?
Well, probably, but we don't
71
00:04:00,320 --> 00:04:02,960
really know because this verdict
was extremely unclear about
72
00:04:02,960 --> 00:04:05,120
that.
So we don't know if it's simply
73
00:04:05,120 --> 00:04:09,960
the act of writing code or it is
the, you know, making that code
74
00:04:09,960 --> 00:04:14,360
available on your own website
or, you know, making that code
75
00:04:14,360 --> 00:04:18,480
available on some automatic
website like system, or whether
76
00:04:18,480 --> 00:04:22,400
it's about maintaining this code
after you've written it once or
77
00:04:22,400 --> 00:04:25,440
if it's about promoting the code
or making money from the code.
78
00:04:25,760 --> 00:04:28,560
It's very unclear.
And in fact, the prosecutor
79
00:04:28,560 --> 00:04:31,800
seemed to emphasize making money
from the code, but the judge
80
00:04:31,800 --> 00:04:35,280
much less so.
Yeah, the the prosecutor.
81
00:04:35,280 --> 00:04:40,120
Really honed down on it
essentially being a business and
82
00:04:40,120 --> 00:04:43,920
that's why you say the making
money part was important, but
83
00:04:43,920 --> 00:04:46,480
the judge didn't even really
seemed focal on that.
84
00:04:46,480 --> 00:04:49,920
The judge just said, look, if
you write this code knowing that
85
00:04:49,920 --> 00:04:52,440
it can be used for this purpose
and you don't do anything to
86
00:04:52,440 --> 00:04:55,960
stop that, then you're
responsible if it's really used
87
00:04:55,960 --> 00:04:58,600
for that purpose, right?
Yeah, pretty much.
88
00:04:58,640 --> 00:05:00,560
And what was?
The purpose here of course,
89
00:05:00,560 --> 00:05:02,120
being money laundering.
Yeah.
90
00:05:02,120 --> 00:05:05,520
What was especially interesting,
though not clear entirely how
91
00:05:05,520 --> 00:05:08,320
that's going to apply to
Bitcoin, was the argument that
92
00:05:08,560 --> 00:05:10,280
he made the whole thing
unstoppable.
93
00:05:10,280 --> 00:05:13,080
So in Ethereum, you know, part
of the system at least is
94
00:05:13,080 --> 00:05:14,920
unstoppable.
It's a smart contract, unless
95
00:05:14,920 --> 00:05:16,320
you stop Ethereum itself, of
course.
96
00:05:17,640 --> 00:05:20,680
And the fact that he did that
where the prosecutor just tried
97
00:05:20,680 --> 00:05:22,720
to argue, well, it's not all
decentralized.
98
00:05:22,720 --> 00:05:25,560
Some of it is is fake to
centralization, others is real.
99
00:05:26,160 --> 00:05:28,720
The judge completely ignored
that and basically said, well,
100
00:05:28,720 --> 00:05:31,080
the fact that you even tried to
make it decentralized, that is
101
00:05:31,080 --> 00:05:35,880
actually making it worse.
So that that argument of course,
102
00:05:35,880 --> 00:05:38,320
can apply extremely broadly
because you could say, well, if
103
00:05:38,320 --> 00:05:41,320
you just publish source and you
know that other people are using
104
00:05:41,320 --> 00:05:44,000
that source and you just keep
updating that source code, well,
105
00:05:44,680 --> 00:05:46,640
that's also kind of unstoppable
in a way.
106
00:05:47,400 --> 00:05:49,720
So that might also be a problem.
And of course, you know
107
00:05:49,760 --> 00:05:50,600
somebody.
We know.
108
00:05:50,600 --> 00:05:52,400
We all know somebody or we don't
know them.
109
00:05:53,360 --> 00:05:56,520
Somebody who created an
unstoppable system a long time
110
00:05:56,520 --> 00:06:00,920
ago and kept working on it so.
You're referring to Satoshi
111
00:06:00,920 --> 00:06:02,200
Nakamoto.
Exactly.
112
00:06:02,480 --> 00:06:04,800
So we're waiting for his arrest
warrant, I guess.
113
00:06:04,840 --> 00:06:06,640
Yeah.
Well, the short way of looking
114
00:06:06,640 --> 00:06:11,560
at it I would say is we all
fought so far that there was a
115
00:06:11,560 --> 00:06:15,760
fairly clear line of what would
make you, you know, what would
116
00:06:15,760 --> 00:06:19,920
be what, what, what would make
you responsible, which is
117
00:06:20,280 --> 00:06:23,800
custody in a way.
And now it's kind of a all bets
118
00:06:23,800 --> 00:06:25,240
are off type of situation.
Yeah.
119
00:06:25,240 --> 00:06:28,320
And this creates a bit of a
problem because because we
120
00:06:28,320 --> 00:06:32,440
assumed that this line existed,
we did not do much to defend
121
00:06:32,440 --> 00:06:34,120
people who built custodial
mixers.
122
00:06:34,120 --> 00:06:36,840
And in retrospect, that was
probably a mistake because as
123
00:06:36,840 --> 00:06:41,800
soon as you lose that line of
defense, now, you know, I guess
124
00:06:41,800 --> 00:06:45,000
the only way to win now is to go
all the way back and say, no,
125
00:06:45,000 --> 00:06:47,480
all mixers should be legal,
including custodial ones.
126
00:06:47,480 --> 00:06:50,000
But now you have all this
precedent that wasn't stopped.
127
00:06:50,480 --> 00:06:51,880
So that's a problem.
Right.
128
00:06:52,720 --> 00:06:59,440
OK, let's move on to the actual
Bitcoin case, which is the
129
00:06:59,440 --> 00:07:01,960
summarized apps.
And just add 1 little detail.
130
00:07:01,960 --> 00:07:04,160
He is, as far as I know, he is
going to appeal.
131
00:07:04,160 --> 00:07:07,560
So we'll see what happens, and
appeals can quite dramatically
132
00:07:07,560 --> 00:07:09,920
change things.
Yeah.
133
00:07:10,080 --> 00:07:12,240
Is there any timeline?
I.
134
00:07:12,240 --> 00:07:14,000
Don't know.
OK.
135
00:07:14,000 --> 00:07:16,960
So let's move to the more
Bitcoin relevant case or I mean
136
00:07:16,960 --> 00:07:18,480
this.
The more direct Bitcoin case.
137
00:07:18,720 --> 00:07:21,680
Exactly.
So the Samurai wallet
138
00:07:21,680 --> 00:07:28,480
developers, Kiona Rodriguez and
Bill Hill, William Hill, both of
139
00:07:28,480 --> 00:07:31,480
them, you know, right?
Yep, yeah, I used to work with
140
00:07:31,480 --> 00:07:33,520
them when I was at
blockchain.com.
141
00:07:33,520 --> 00:07:35,560
So back in time, Blockchain at
info.
142
00:07:35,760 --> 00:07:37,920
Right.
So they were arrested as well,
143
00:07:38,920 --> 00:07:41,160
one of them Portugal, one of
them in the United States, both,
144
00:07:41,200 --> 00:07:47,320
both on behalf of the Department
of Justice DOJ.
145
00:07:48,400 --> 00:07:51,400
So how, what?
What do you want to say about
146
00:07:51,400 --> 00:07:52,720
that, if anything?
How?
147
00:07:52,920 --> 00:07:57,520
Well, I'm not surprised that
this happened because you know,
148
00:07:57,520 --> 00:08:00,520
the fact that they were going
after Tornado cash made it clear
149
00:08:00,520 --> 00:08:05,120
that they would go after non
custodial systems after Monaco
150
00:08:05,120 --> 00:08:07,080
studio mixes.
So seemed like a matter of time
151
00:08:07,080 --> 00:08:09,160
before they would go after it.
And then obviously they always
152
00:08:09,160 --> 00:08:12,040
go after the biggest or at least
a big one.
153
00:08:12,040 --> 00:08:15,200
So the only question was were
they going to go after Wasabi or
154
00:08:15,200 --> 00:08:16,440
were they going to go after
Samurai?
155
00:08:17,440 --> 00:08:20,040
Samurai has some interesting
marketing that maybe made them
156
00:08:20,040 --> 00:08:23,360
more interesting to prosecute,
but I don't know if the
157
00:08:23,360 --> 00:08:26,240
difference, you know, and and of
course we know that Wasabi was
158
00:08:26,240 --> 00:08:33,440
doing some proactive compliance
ish things, but this I don't
159
00:08:33,440 --> 00:08:35,159
know why they picked one and the
other.
160
00:08:35,159 --> 00:08:40,600
Ultimately, we'll we'll find out
what else was I going to say
161
00:08:40,600 --> 00:08:42,280
about?
It well, it was my suggestion to
162
00:08:42,280 --> 00:08:46,280
just sort of explain how the
samurai mixing actually worked,
163
00:08:46,640 --> 00:08:51,800
but at this point should we just
move on to the main topic of the
164
00:08:52,160 --> 00:08:54,160
of the episode?
No, I think it may make sense to
165
00:08:54,160 --> 00:08:56,880
briefly explain a little bit.
So there's 2-3 aspects to
166
00:08:56,880 --> 00:08:58,680
Samurai wallet I think that are
relevant.
167
00:08:59,000 --> 00:09:01,520
Well, one is it's a non, it's
not just a mixer.
168
00:09:02,000 --> 00:09:03,880
Definitely not.
It's, it's a wallet, right?
169
00:09:03,880 --> 00:09:07,320
It's a non custodial wallet and
so far it seems that that wallet
170
00:09:07,320 --> 00:09:11,120
was taken down mostly as a side
effect of taking the mixer down,
171
00:09:11,120 --> 00:09:14,400
not you know, as a direct
target, but it is down.
172
00:09:14,960 --> 00:09:17,760
But fortunately it was a non
custodial wallet and people
173
00:09:17,760 --> 00:09:19,760
wrote down their 12 words
hopefully.
174
00:09:20,360 --> 00:09:22,840
And so they should be fine
'cause they can just import it
175
00:09:22,840 --> 00:09:25,360
into another wallet.
But there was also a mixer
176
00:09:25,360 --> 00:09:28,720
component.
And I think the most the two
177
00:09:28,720 --> 00:09:31,600
most important parts of that are
something called the Whirlpool
178
00:09:32,800 --> 00:09:37,480
which is A5 input 5 output mixer
that you can use multiple times.
179
00:09:37,840 --> 00:09:40,960
Yeah, it's just a coin join
which uses equal amounts.
180
00:09:41,240 --> 00:09:43,880
Yeah.
And then there is something
181
00:09:43,880 --> 00:09:46,960
called Picochet, which
basically, just as far as I
182
00:09:46,960 --> 00:09:49,320
understand it, just forwards
your coins a couple of times.
183
00:09:49,320 --> 00:09:52,160
So you're making a couple of
unnecessary transactions and
184
00:09:52,160 --> 00:09:54,160
then you send the e-mail that
you want to send.
185
00:09:54,520 --> 00:09:58,040
And that might help when you're
dealing with an exchange that
186
00:09:58,040 --> 00:10:03,400
only looks at, say, 5 hops ago
or two hops ago, and then maybe
187
00:10:03,400 --> 00:10:05,480
you can get around that.
I don't know how effective any
188
00:10:05,480 --> 00:10:07,760
of these things are.
Yeah, you're basically making
189
00:10:07,760 --> 00:10:09,560
transactions to yourself a
couple times.
190
00:10:09,840 --> 00:10:11,920
Yeah.
Now it should be noted that from
191
00:10:11,920 --> 00:10:15,120
my reading of the indictment,
they don't even talk about
192
00:10:15,120 --> 00:10:17,240
whether or not these tools,
these mixing tools were
193
00:10:17,240 --> 00:10:20,000
effective or not.
They just, you know, the fact
194
00:10:20,000 --> 00:10:22,120
that it's doing any mixing that
is the problem.
195
00:10:22,840 --> 00:10:25,160
So that's something to keep in
mind.
196
00:10:27,080 --> 00:10:30,320
Yeah, I I would say the ricochet
one, the fact that the fact that
197
00:10:30,320 --> 00:10:35,640
that one is even mentioned is
blatantly like every wallet.
198
00:10:36,120 --> 00:10:38,360
With every wallet you can send
coins to yourself.
199
00:10:38,400 --> 00:10:41,480
This is just a button that just
sort of automates that you do
200
00:10:41,480 --> 00:10:43,200
that a couple of times.
Exactly.
201
00:10:43,840 --> 00:10:47,960
That this is even like the other
the Whirlpool, I can sort of at
202
00:10:47,960 --> 00:10:51,640
least understand why it's seen
as some I mean I don't agree
203
00:10:51,640 --> 00:10:52,600
with.
That, well, the Whirlpool
204
00:10:52,600 --> 00:10:55,160
requires coordinating with other
users, right?
205
00:10:55,160 --> 00:10:56,600
Whereas the ricochet thing does
not.
206
00:10:56,600 --> 00:11:00,440
It's just your wallet sending a
transaction to itself
207
00:11:00,440 --> 00:11:04,080
essentially five times in a row.
Yeah, which, again, literally
208
00:11:04,080 --> 00:11:07,160
every wallet can do.
But I would be very surprised if
209
00:11:07,160 --> 00:11:11,480
in the court case they're going
to debate the specific details
210
00:11:11,480 --> 00:11:13,840
of what is and what is not
mixing.
211
00:11:15,440 --> 00:11:18,480
My guess is they just go go with
the marketing.
212
00:11:18,480 --> 00:11:21,960
They say, well you guys called
it a mixer and that's all we
213
00:11:21,960 --> 00:11:23,520
care about.
Right.
214
00:11:25,480 --> 00:11:31,640
Anyways, yeah, seems like a new
era in Bitcoin and Bitcoin
215
00:11:31,640 --> 00:11:33,400
development to me.
Yeah.
216
00:11:33,400 --> 00:11:36,960
And I think we could briefly do
a recap of the differences, how
217
00:11:36,960 --> 00:11:38,240
these cases relate to each
other.
218
00:11:38,800 --> 00:11:40,400
So we brought up most of the
things.
219
00:11:40,400 --> 00:11:43,560
So the interesting thing about
summarize that it's only
220
00:11:43,560 --> 00:11:46,520
happening in the US where's the
Tornado Cash trial is happening
221
00:11:46,520 --> 00:11:50,200
in the US and the Netherlands in
parallel, which is interesting.
222
00:11:50,600 --> 00:11:53,480
Yeah, you didn't mention that
yet, but yeah, one of the other
223
00:11:54,880 --> 00:11:58,280
Tornado Cash Co founders is was
arrested in the US and will be
224
00:11:58,280 --> 00:11:59,440
on trial there.
Yeah.
225
00:11:59,440 --> 00:12:03,080
And this is interesting because
the Dutch court system is not
226
00:12:03,080 --> 00:12:06,560
very transparent that you can go
to the to the court hearings,
227
00:12:06,560 --> 00:12:08,480
but you don't get to see any of
Dutch.
228
00:12:09,400 --> 00:12:11,200
Whereas in the US it's much more
transparent.
229
00:12:11,200 --> 00:12:14,200
So we'll probably learn much
more about the Dutch case
230
00:12:14,200 --> 00:12:19,920
through the US case.
Both of them are non custodial.
231
00:12:21,840 --> 00:12:25,680
Both of them use a well, no.
So the Samurai uses a central
232
00:12:25,680 --> 00:12:27,560
coordinator.
So that might be a service.
233
00:12:27,560 --> 00:12:29,720
Whereas in Tornado Cash it's
it's a smart contract.
234
00:12:29,720 --> 00:12:32,960
So there's not really a service,
although they are, the
235
00:12:32,960 --> 00:12:34,720
prosecutor argued that it's a
service anyway.
236
00:12:36,320 --> 00:12:39,000
You mean the the main smart
contract or?
237
00:12:39,560 --> 00:12:42,920
Yeah, the main smart contract
and everything around it, you
238
00:12:42,920 --> 00:12:45,040
could argue like it's an
autonomous system, so it's not
239
00:12:45,040 --> 00:12:47,760
really a service, but that's
what they're arguing.
240
00:12:47,760 --> 00:12:51,280
I think in both the Netherlands
and the US, against or for,
241
00:12:51,280 --> 00:12:52,560
depending on which side you're
at.
242
00:12:53,760 --> 00:12:57,160
I'd say Samurai used fees
fairly, pretty direct fee
243
00:12:57,160 --> 00:13:03,800
system, whereas the Tornado Cash
system did not charge fees
244
00:13:03,800 --> 00:13:05,560
directly.
At least the fees don't go
245
00:13:05,560 --> 00:13:08,080
directly to the developers or
operators.
246
00:13:08,480 --> 00:13:12,920
They have a more convoluted
tokenomic system where at least
247
00:13:12,920 --> 00:13:16,040
the prosecutor argued that these
tokenomics are.
248
00:13:16,080 --> 00:13:19,160
You know how it's how the
business works.
249
00:13:21,280 --> 00:13:25,160
I think the short summary I
would give is if the Tornado
250
00:13:25,160 --> 00:13:29,960
Cash developer is guilty in the
Netherlands, which he is, then
251
00:13:29,960 --> 00:13:32,200
the Samurai developers have to
be as well.
252
00:13:32,360 --> 00:13:34,280
So it's sort of even more
straightforward.
253
00:13:34,280 --> 00:13:35,400
Exactly.
Yeah, it's a.
254
00:13:35,400 --> 00:13:41,960
It's a simpler case, right?
So yeah, bad news.
255
00:13:41,960 --> 00:13:44,520
Let's move on to our actual
topic for the podcast.
256
00:13:44,520 --> 00:13:47,000
What do you think?
Yeah, also some bad news in a
257
00:13:47,000 --> 00:13:49,040
way.
Yeah, yeah.
258
00:13:49,040 --> 00:13:50,560
But bad news that we're going to
fix, right?
259
00:13:50,560 --> 00:13:51,440
Yours.
Yeah, exactly.
260
00:13:51,960 --> 00:13:56,000
That we hopefully fix in time.
So we're going to talk main
261
00:13:56,000 --> 00:13:58,440
topic of the of the podcast.
Finally, we're here.
262
00:13:58,640 --> 00:14:00,200
We're here, ladies and
gentlemen.
263
00:14:00,520 --> 00:14:04,640
We're going to talk about the
Great Consensus Clean Up, or
264
00:14:04,640 --> 00:14:07,200
maybe more specifically the
Great Consensus Clean up
265
00:14:07,200 --> 00:14:11,280
revival, because the Great
Consensus cleanup was proposed
266
00:14:11,280 --> 00:14:17,280
by Matt Corello a couple years
ago and was recently revived by
267
00:14:17,280 --> 00:14:19,800
Antoine Poncho.
Am I saying that right?
268
00:14:20,040 --> 00:14:23,240
Probably it was him, right?
I, I got the person right, at
269
00:14:23,240 --> 00:14:27,040
least whether I got the name
pronunciation right or not sure
270
00:14:27,040 --> 00:14:31,560
about that one.
And the Great consensus Cleanup
271
00:14:31,560 --> 00:14:36,600
revival maybe?
What's the difference between
272
00:14:36,600 --> 00:14:38,560
the original and the?
Is there a difference?
273
00:14:39,680 --> 00:14:42,280
Yeah, there is.
So the, the the revival adds
274
00:14:42,280 --> 00:14:45,400
something and I guess I'll let
you know when when we get to
275
00:14:45,400 --> 00:14:46,560
that new bit.
OK.
276
00:14:46,720 --> 00:14:50,920
And as far as I understand, the
great consensus cleanup would be
277
00:14:50,960 --> 00:14:55,280
what would basically be one soft
fork that bundles several soft
278
00:14:55,280 --> 00:15:00,480
forks, and these soft forks sort
of fix existing bugs in the
279
00:15:00,480 --> 00:15:03,040
protocol.
Yeah, they could be individual
280
00:15:03,040 --> 00:15:06,280
softworks and you know, in the
worst case, maybe out of the
281
00:15:06,280 --> 00:15:09,800
four components, people really
like three of them and are kind
282
00:15:09,800 --> 00:15:13,680
of arguing about the 4th. 1:00
Then you can simply do three and
283
00:15:13,680 --> 00:15:16,160
not do the other one.
OK, And if I understand
284
00:15:16,160 --> 00:15:20,560
correctly, basically everyone,
and when I say everyone, I mean
285
00:15:20,560 --> 00:15:23,400
everyone that's you know, has
enough expertise to have an
286
00:15:23,400 --> 00:15:27,200
opinion in the 1st place, agrees
that at least the bugs are
287
00:15:27,200 --> 00:15:31,920
problems.
There's maybe at most like some
288
00:15:32,400 --> 00:15:35,400
conversation about the best way
to solve these problems, whether
289
00:15:35,400 --> 00:15:38,080
these these are the best ways.
But the problems are real.
290
00:15:38,400 --> 00:15:41,200
There's no one that says no,
these are actually futures,
291
00:15:41,200 --> 00:15:42,360
right?
There's these are just real
292
00:15:42,360 --> 00:15:44,680
problems, bugs that exist in the
bit more protocol I.
293
00:15:44,680 --> 00:15:48,080
Think when it comes to the time
warp protector, might have been
294
00:15:48,080 --> 00:15:51,200
someone who could think of some
interesting schemes that you can
295
00:15:51,200 --> 00:15:53,960
do using a time warp attack.
That's right.
296
00:15:53,960 --> 00:15:55,280
Yeah.
You're thinking of Mark
297
00:15:55,280 --> 00:15:58,600
Friedenbach, who had some sort
of proposal years ago to sort of
298
00:15:58,720 --> 00:16:02,360
increase the block size and yes,
yeah, yeah, yeah, you're right.
299
00:16:02,760 --> 00:16:04,480
But let's.
Every bug is a feature.
300
00:16:04,480 --> 00:16:06,280
Yeah, let's table that for a
second.
301
00:16:06,840 --> 00:16:08,720
Although I mean, it is
interesting that you bring that
302
00:16:08,720 --> 00:16:11,520
up, but.
Well, I mean, that won't work if
303
00:16:11,520 --> 00:16:14,960
somebody exploits the time warp
maliciously before the
304
00:16:14,960 --> 00:16:17,280
legitimate use case happens, I
think.
305
00:16:20,360 --> 00:16:24,920
Well, is the legitimate use case
still possible after this bug
306
00:16:24,920 --> 00:16:26,840
would be fixed?
Actually, I'm not sure.
307
00:16:26,840 --> 00:16:28,280
So we'll, we'll, we'll show
that.
308
00:16:28,280 --> 00:16:31,760
So there may be a, you know, as
always, there may be some, some
309
00:16:31,760 --> 00:16:33,560
ways that you could use this to
your advantage.
310
00:16:34,040 --> 00:16:36,000
I think it's better to fix them.
Yeah, OK.
311
00:16:36,000 --> 00:16:39,080
And so they're basically 4 bugs,
right?
312
00:16:39,120 --> 00:16:42,560
There are four bugs.
There are four things that this
313
00:16:42,560 --> 00:16:45,600
would solve.
That's right, plus an an open
314
00:16:45,600 --> 00:16:47,480
invitation to anyone who knows
another bug.
315
00:16:48,600 --> 00:16:52,320
OK, so 4, let's start with the
first one.
316
00:16:52,320 --> 00:16:55,560
So the first one, you already
mentioned it, the time warp
317
00:16:56,440 --> 00:16:58,720
attack, the time warp problem.
What do we call this?
318
00:16:58,920 --> 00:17:00,520
Yeah, the Time Warp attack.
Yeah.
319
00:17:00,600 --> 00:17:05,079
And so it's about the the time
warp, the time warp attack is
320
00:17:05,079 --> 00:17:08,079
possible now and we're talking
about fixing that.
321
00:17:08,079 --> 00:17:09,960
That is possible.
Like that shouldn't be possible
322
00:17:09,960 --> 00:17:11,760
essentially, right?
That's right, and we did an
323
00:17:11,760 --> 00:17:13,800
earlier episode about the time
warp attack.
324
00:17:13,800 --> 00:17:17,079
It's episode #5 S scroll all the
way back.
325
00:17:17,520 --> 00:17:20,119
That's a long time back.
Where we explain how it works.
326
00:17:20,240 --> 00:17:23,960
I think I didn't listen back to
it, but basically I mean the the
327
00:17:23,960 --> 00:17:28,520
TLDR is that you can mess with
the time stamps in every block.
328
00:17:28,520 --> 00:17:31,600
So miners can.
You know, Bitcoin is not a clock
329
00:17:31,600 --> 00:17:35,840
contrary to popular belief.
But blocks do have a time stamp
330
00:17:35,840 --> 00:17:38,640
in it and this time stamp
cannot.
331
00:17:39,480 --> 00:17:41,720
I mean, the miner can pick this
time stamp however they want,
332
00:17:41,720 --> 00:17:45,800
but there are a few restrictions
on it based on earlier possible
333
00:17:45,800 --> 00:17:47,600
attacks.
One of the restrictions is that
334
00:17:47,600 --> 00:17:51,120
it cannot be more than two hours
in the future as determined when
335
00:17:51,120 --> 00:17:57,000
when you receive the block.
The other rule is that every, I
336
00:17:57,000 --> 00:18:00,480
think it's the rolling average
or the median I should say, of
337
00:18:00,480 --> 00:18:04,040
the last 11 blocks has to go up
by one second every block.
338
00:18:06,440 --> 00:18:09,400
And so basically you're, you
know, the block time has to go
339
00:18:09,400 --> 00:18:11,800
up a little bit and it can be
too far in the future.
340
00:18:11,800 --> 00:18:13,600
Those are the only two
restrictions, but turns out you
341
00:18:13,600 --> 00:18:16,360
can still mess with the system
this with those two rules.
342
00:18:17,680 --> 00:18:22,680
How so?
Well, you can basically fool the
343
00:18:22,680 --> 00:18:27,200
system I think.
I think we need to explain
344
00:18:27,200 --> 00:18:30,760
another related bug here first,
which is that the difficulty
345
00:18:30,760 --> 00:18:32,600
adjustment, how the difficulty
adjustment works.
346
00:18:33,160 --> 00:18:37,640
So the goal of the system is to
keep one block every 10 minutes.
347
00:18:38,200 --> 00:18:41,720
And this is achieved by looking
at the last block of the
348
00:18:41,720 --> 00:18:45,720
difficulty adjustment period and
comparing it to the first block
349
00:18:45,720 --> 00:18:49,400
in that period and then dividing
it by 2016.
350
00:18:50,080 --> 00:18:52,480
And there are multiple problems
with that, but the biggest one
351
00:18:52,480 --> 00:18:56,800
is that you are not comparing
the first block of each period
352
00:18:56,800 --> 00:18:58,680
to the first block of each last
period.
353
00:18:58,720 --> 00:19:01,000
You're you're comparing the
first block of a period to the
354
00:19:01,000 --> 00:19:04,120
last block of a period.
And that allows you to kind of
355
00:19:04,120 --> 00:19:09,600
match mess around the edges.
Oh yeah.
356
00:19:09,680 --> 00:19:11,880
OK, so how do you mess around
the edges?
357
00:19:12,720 --> 00:19:14,960
Well, one thing you can do here
is you can increase the
358
00:19:14,960 --> 00:19:19,480
timestamp of.
Basically you increase the
359
00:19:19,480 --> 00:19:22,920
timestamp of every block as
little as possible, so the
360
00:19:22,920 --> 00:19:27,560
entire two week period will look
like it's only a few minutes
361
00:19:27,640 --> 00:19:28,600
basically.
Yeah.
362
00:19:28,640 --> 00:19:32,520
And well, to be clear, this
would require a majority of
363
00:19:32,520 --> 00:19:34,240
minors to.
Yeah.
364
00:19:34,280 --> 00:19:38,360
The collaborate attack is is a
51% attack basically or requires
365
00:19:38,360 --> 00:19:40,680
a 51%.
Attack so miners a majority of
366
00:19:40,680 --> 00:19:45,360
miners is faking the time stamps
and all nodes on the network
367
00:19:45,440 --> 00:19:48,000
will accept this.
But because it's not breaking
368
00:19:48,000 --> 00:19:51,880
the rules, the the the nodes are
just looking is this block mind
369
00:19:51,880 --> 00:19:55,160
in the future?
And is it mined at least one
370
00:19:55,160 --> 00:19:58,400
second previously later than
like the 11 blocks before
371
00:19:58,400 --> 00:20:00,920
something like that.
So then you can mine, you can
372
00:20:00,920 --> 00:20:04,160
fake the timestamps to make
every blocks look like it was
373
00:20:04,160 --> 00:20:05,600
all mined within the same
minutes.
374
00:20:05,600 --> 00:20:07,720
Basically, yeah.
And then you all periods mined
375
00:20:07,720 --> 00:20:09,840
within the same minute.
Why would you want to do that?
376
00:20:09,840 --> 00:20:12,400
Well, there's another part of
this attack, which is where you
377
00:20:12,400 --> 00:20:14,800
take the last block of the
difficulty adjustment period,
378
00:20:14,920 --> 00:20:17,680
and there you don't lie.
You just put it two hours in the
379
00:20:17,680 --> 00:20:20,840
future or right now.
It doesn't really matter if you
380
00:20:20,840 --> 00:20:23,680
do that in just one difficulty
adjustment period.
381
00:20:23,680 --> 00:20:25,880
It really has almost no effect,
right?
382
00:20:25,880 --> 00:20:28,840
Because the first, the first
block in that period had a had a
383
00:20:28,840 --> 00:20:30,840
real time because you weren't
lying.
384
00:20:31,640 --> 00:20:34,080
The last block in the period has
a real time because you weren't
385
00:20:34,080 --> 00:20:35,400
lying.
You were only lying for all the
386
00:20:35,400 --> 00:20:38,080
other blocks.
So the difficulty will just stay
387
00:20:38,080 --> 00:20:40,800
the same because you took took
you two weeks to make these
388
00:20:40,800 --> 00:20:45,160
blocks, but but the attack has
already begun even though
389
00:20:45,400 --> 00:20:47,360
doesn't have any visible effect
yet.
390
00:20:48,200 --> 00:20:51,840
For the next two weeks you do
the same thing.
391
00:20:51,840 --> 00:20:55,320
So the first block you set a
fake time as low as possible, so
392
00:20:55,320 --> 00:20:57,400
much older than the last block
of the previous period.
393
00:20:57,400 --> 00:20:59,520
You just keep that original
clock going.
394
00:20:59,840 --> 00:21:03,240
Right, so now you're back in the
the original minutes, so to say.
395
00:21:04,200 --> 00:21:07,680
Yes.
And now the last block, you're
396
00:21:07,680 --> 00:21:09,880
speaking the truth again, the
last block of the period.
397
00:21:10,800 --> 00:21:14,360
And now if the blockchain is
looking at what to do with the
398
00:21:14,360 --> 00:21:17,800
difficulty, it's seeing the last
block of the of the of the
399
00:21:17,800 --> 00:21:20,800
period, which is real.
And it's seeing the first block
400
00:21:20,800 --> 00:21:23,600
of that new period, which is now
4 weeks ago, right?
401
00:21:23,600 --> 00:21:26,160
Because we've only increased
that timer very slowly.
402
00:21:26,800 --> 00:21:29,960
And so that means the difficulty
can be cut in half now.
403
00:21:30,160 --> 00:21:31,960
Yeah.
And then you repeat this little
404
00:21:31,960 --> 00:21:33,880
trick.
Yeah, the rest of the network,
405
00:21:33,880 --> 00:21:36,600
all nodes are looking at these
two blocks and they're thinking,
406
00:21:36,600 --> 00:21:40,240
wow, it took a whole month to
mine 2016 blocks.
407
00:21:40,240 --> 00:21:42,120
It's way too long.
We got to decrease the
408
00:21:42,120 --> 00:21:45,720
difficulty by half.
How difficulties create divided
409
00:21:45,720 --> 00:21:47,760
by half.
Yep, even though that was not
410
00:21:47,760 --> 00:21:50,040
really necessary, it's just the
time stamps were all being
411
00:21:50,040 --> 00:21:51,200
faked.
Right, exactly.
412
00:21:51,240 --> 00:21:53,600
So now you can do one week worth
of.
413
00:21:53,880 --> 00:21:57,240
Now you can make 2 weeks worth
of blocks in just one week.
414
00:21:57,760 --> 00:22:00,480
Because assuming that all the
hash power is still the same,
415
00:22:00,480 --> 00:22:02,960
now you can mine two weeks of
blocks in one week.
416
00:22:02,960 --> 00:22:05,680
Yep.
Yeah, because again.
417
00:22:05,680 --> 00:22:07,080
And then at the end of that one
week, you're.
418
00:22:07,080 --> 00:22:10,200
Still faking the time stamps, so
we're still sort of back mining
419
00:22:10,200 --> 00:22:11,560
in the first minute or, you
know.
420
00:22:11,600 --> 00:22:13,680
Yeah.
So at the end of that of that
421
00:22:13,680 --> 00:22:17,120
week, which you know, for the
blockchain is 2 weeks, you're
422
00:22:17,120 --> 00:22:20,120
like, OK, this was five weeks.
This took five weeks to produce
423
00:22:20,120 --> 00:22:21,520
this block.
So could I decrease the
424
00:22:21,520 --> 00:22:25,160
difficulty even more?
And then so cuts gets cut in
425
00:22:25,160 --> 00:22:27,440
half again.
So now you can mine in about 2
426
00:22:27,440 --> 00:22:30,560
1/2 days, the equivalent of two
weeks.
427
00:22:31,080 --> 00:22:34,520
And the blockchain's like, whoa,
that took five weeks and two
428
00:22:34,520 --> 00:22:36,600
days.
I gotta reduce the difficulty
429
00:22:36,600 --> 00:22:37,680
again.
Yep, Yep, Yep.
430
00:22:37,680 --> 00:22:40,760
And so the difficulty goes to
one very, very quickly, in a
431
00:22:40,760 --> 00:22:43,360
matter of about 40 days,
according to Antwan's
432
00:22:43,360 --> 00:22:47,040
calculation, right?
So yeah, miners, like you said,
433
00:22:47,040 --> 00:22:51,240
it's basically 51% tech where
miners can drive the difficulty
434
00:22:51,240 --> 00:22:56,240
down to one and then they can
mine all remaining coins that
435
00:22:56,280 --> 00:22:59,800
are still to be mined exactly
over the next century.
436
00:22:59,800 --> 00:23:03,200
They mined the equivalent of
until the year 21 O 6 and
437
00:23:03,240 --> 00:23:05,920
they've got every last set we've
got, you know, millions of
438
00:23:05,920 --> 00:23:07,880
blocks in a very short period of
time.
439
00:23:10,040 --> 00:23:12,640
And and then they probably stop
the attack because there's no
440
00:23:12,640 --> 00:23:14,040
need to do it anymore.
Yeah.
441
00:23:14,800 --> 00:23:19,640
And then on top of that, that
would mess up probably a bunch
442
00:23:19,640 --> 00:23:22,560
of like smart contract things,
time lock types of.
443
00:23:23,080 --> 00:23:25,520
No.
Well, time locks are well, they
444
00:23:25,520 --> 00:23:29,360
might be effective, but because
time is moving more slowly, your
445
00:23:29,360 --> 00:23:32,440
time locks would indeed not
expire because.
446
00:23:32,440 --> 00:23:35,280
But that's that's probably not a
big deal like during this
447
00:23:35,280 --> 00:23:37,880
attack, because the attack takes
five weeks plus a little bit to
448
00:23:38,000 --> 00:23:40,560
suck all the coins out.
Well, it could definitely the
449
00:23:40,560 --> 00:23:43,760
time locks that's are locked on
a certain block in the future.
450
00:23:43,760 --> 00:23:45,200
Yeah.
So if you're looking at height
451
00:23:45,200 --> 00:23:47,760
locks, I guess you call them,
height locks are definitely
452
00:23:47,760 --> 00:23:50,800
affected because if you have a
contract that expires in block
453
00:23:50,800 --> 00:23:54,120
1,000,000, well, guess what that
that happens immediately.
454
00:23:54,640 --> 00:23:58,160
But a time lock would be kind of
during the attack, it would be
455
00:23:58,160 --> 00:24:00,200
effective because your time lock
is never happening because they
456
00:24:00,200 --> 00:24:03,680
keep the time behind.
But once they stop the attack,
457
00:24:04,000 --> 00:24:06,920
it'll be fine.
So you might be unlucky if your
458
00:24:06,920 --> 00:24:08,560
lightning thing is in the wrong
place.
459
00:24:08,920 --> 00:24:11,720
Yeah, it could be bad.
But the the worst aspect of this
460
00:24:11,720 --> 00:24:15,880
attack other than the five week
disruption is simply that they
461
00:24:15,880 --> 00:24:20,120
have now exhausted the full the
the full subsidy.
462
00:24:20,760 --> 00:24:24,120
And so we were hoping to not
have to deal with the no subsidy
463
00:24:24,120 --> 00:24:29,120
world only 20-30 years from now.
But we have to deal with it in,
464
00:24:29,480 --> 00:24:32,920
well, 40 days if this attack is
exploited.
465
00:24:32,920 --> 00:24:35,720
And it could happen at any
moment, OK, So, and a majority
466
00:24:35,720 --> 00:24:38,240
of miners, you know, might
think, well, you know, why not?
467
00:24:38,240 --> 00:24:42,640
We're the majority of miners.
Well, I mean, one reason why not
468
00:24:42,640 --> 00:24:45,120
is that it would probably
undermine trust in the protocol.
469
00:24:45,480 --> 00:24:48,080
But let's ignore that.
Let's see if we can fix the
470
00:24:48,080 --> 00:24:51,000
protocol instead of relying on
that kind of trust.
471
00:24:51,000 --> 00:24:53,960
So what's the fix here?
The fix is actually fairly
472
00:24:53,960 --> 00:24:57,960
simple.
Well, the ideal fix would be
473
00:24:57,960 --> 00:25:02,080
that we just compare every block
to the same block in the last
474
00:25:02,080 --> 00:25:03,800
period.
But that's a hard fork.
475
00:25:04,440 --> 00:25:06,960
So instead, at least I think
it's a hard fork.
476
00:25:07,280 --> 00:25:10,120
So instead.
So by that you mean instead of
477
00:25:10,240 --> 00:25:13,320
comparing the 1st to the last
block within the same periods,
478
00:25:13,760 --> 00:25:17,040
you know, and checking if that's
two weeks, we should really just
479
00:25:17,040 --> 00:25:19,160
check the first block to the
next first block?
480
00:25:19,520 --> 00:25:22,240
Yeah, but it but that's not
possible, right?
481
00:25:22,240 --> 00:25:23,720
I mean.
As far as I know that's a hard
482
00:25:23,720 --> 00:25:26,320
fork, so can't do it.
They would also.
483
00:25:26,320 --> 00:25:29,520
How is that even possible?
Because by then the difficulty
484
00:25:29,520 --> 00:25:33,440
should have already adjusted
right by the time the first
485
00:25:33,440 --> 00:25:35,280
block of the next period is.
Well, obviously you'd have to
486
00:25:35,280 --> 00:25:37,960
change exactly how the
difficulty adjustments happen,
487
00:25:37,960 --> 00:25:40,440
but you should just do the
difficulty adjustments correctly
488
00:25:41,160 --> 00:25:44,040
and the but the simplest
solution here is that every
489
00:25:44,040 --> 00:25:49,080
first block or block zero of
every period needs to have needs
490
00:25:49,080 --> 00:25:52,120
to be in the present or two
hours ago, but no more than
491
00:25:52,120 --> 00:25:53,000
that.
Every what?
492
00:25:53,200 --> 00:25:54,800
Every first block of every
period.
493
00:25:55,200 --> 00:26:00,840
So block 0, block 216, etcetera
has to be in the present, the
494
00:26:00,840 --> 00:26:03,440
time stamp.
And it can be two hours ago for
495
00:26:03,440 --> 00:26:05,800
weird mining, mining related
reasons.
496
00:26:06,160 --> 00:26:08,200
But it can.
And it can of course not be more
497
00:26:08,200 --> 00:26:10,920
than two hours in the future.
But basically it has to be in a
498
00:26:10,920 --> 00:26:13,480
four hour window between two
hours ago and two hours in the
499
00:26:13,480 --> 00:26:16,760
future.
Every first block has to be yes,
500
00:26:17,280 --> 00:26:19,840
right?
OK, yeah, that sounds like a
501
00:26:19,840 --> 00:26:22,600
pretty simple fix.
Yeah, because don't remember the
502
00:26:22,600 --> 00:26:24,960
attack involved comparing the
last block to the first block.
503
00:26:25,080 --> 00:26:27,320
Yeah, and really messing with
the first block, that's the the
504
00:26:27,400 --> 00:26:29,680
the part of the messing that you
weren't messing with the last
505
00:26:29,680 --> 00:26:32,440
block already.
Yeah, but you were messing with
506
00:26:32,440 --> 00:26:34,520
the first block.
And this fix basically makes
507
00:26:34,520 --> 00:26:37,520
that impossible and therefore
the difficulty adjustment will
508
00:26:37,520 --> 00:26:39,040
be correct.
Problem solved.
509
00:26:39,680 --> 00:26:41,120
OK, makes sense.
Yeah.
510
00:26:41,120 --> 00:26:45,040
And as far as I know, that's
still the the going the proposed
511
00:26:45,040 --> 00:26:49,760
fix that hasn't changed.
OK that was a time time warp
512
00:26:50,040 --> 00:26:51,760
attack fix.
What's the next one?
513
00:26:52,640 --> 00:26:56,920
Slow scripts.
So as you know, it takes a while
514
00:26:56,920 --> 00:27:01,040
to validate the whole blockchain
and some blocks take a bit
515
00:27:01,040 --> 00:27:03,760
longer than others.
That can be because there's tons
516
00:27:03,760 --> 00:27:07,600
and tons of transactions in
them, but there's certain, you
517
00:27:07,600 --> 00:27:10,280
know, there's at least we have a
limit on the on the block size.
518
00:27:10,280 --> 00:27:13,400
A block can be more than 4
megabyte, so there's some limit
519
00:27:13,400 --> 00:27:15,520
to how much you can do in a
block.
520
00:27:15,520 --> 00:27:18,480
But it turns out you can make
some special transactions that
521
00:27:18,480 --> 00:27:22,000
are really quite slow to verify.
And that's usually a combination
522
00:27:22,000 --> 00:27:24,840
of lots of signature checks.
Because signature checks take a
523
00:27:24,840 --> 00:27:28,520
while, you have to do the ECDSA
thing and hashing.
524
00:27:30,240 --> 00:27:34,440
So we talked about this
signature checking speed problem
525
00:27:35,120 --> 00:27:38,000
back in episode.
Let me see.
526
00:27:40,360 --> 00:27:45,120
I think episode 32 and Episode
76, yeah.
527
00:27:47,160 --> 00:27:49,000
Yeah.
So from what I understand, the
528
00:27:49,280 --> 00:27:54,200
problem here essentially is like
every transaction includes
529
00:27:54,200 --> 00:27:56,840
scripts, and for many
transactions that's just a
530
00:27:56,920 --> 00:28:00,200
straightforward check that the
signature is valid type of
531
00:28:00,200 --> 00:28:03,040
thing.
But you can make more complex
532
00:28:03,040 --> 00:28:06,480
transactions that includes, like
you say, hashing or more
533
00:28:06,480 --> 00:28:09,520
signature validation.
Yeah, so, so for example.
534
00:28:09,880 --> 00:28:14,680
And if you would intentionally
want to design A transaction, or
535
00:28:14,680 --> 00:28:17,600
maybe even unblocked full of
transactions with like
536
00:28:17,600 --> 00:28:21,640
complicated stuff, then that
could in the worst case lead to
537
00:28:21,920 --> 00:28:25,440
blocks that take minutes to
actually validate.
538
00:28:25,560 --> 00:28:27,160
Yeah.
And so, you know, people have
539
00:28:27,160 --> 00:28:30,920
been, I believe, has been doing
some math on seeing what is the
540
00:28:30,920 --> 00:28:34,360
absolute worst you can do.
And he came up with something
541
00:28:34,360 --> 00:28:37,400
that took more than one hour to
validate on a Raspberry Pi 4,
542
00:28:37,480 --> 00:28:39,720
Right.
And that's not good.
543
00:28:40,000 --> 00:28:44,280
Now you could say, well it sucks
to have a Raspberry, but be nice
544
00:28:44,280 --> 00:28:47,760
if it didn't.
And and even on a fast laptop it
545
00:28:47,760 --> 00:28:50,320
took several minutes, right?
Yeah, and several minutes would
546
00:28:50,320 --> 00:28:53,080
be bad, right?
So if you are a miner and you
547
00:28:53,080 --> 00:28:56,160
receive that block that takes
you several minutes to validate,
548
00:28:56,520 --> 00:29:00,480
well now your competitor can do
all sorts of shenanigans because
549
00:29:00,480 --> 00:29:04,080
you're kind of stuck validating.
Yeah, we're not shenanigans.
550
00:29:04,080 --> 00:29:07,080
Just get a head start.
Head start from finding a nice
551
00:29:07,080 --> 00:29:10,080
block for example.
Right, that's one shenanigans,
552
00:29:10,080 --> 00:29:11,800
but I think there might be other
things you can do.
553
00:29:11,920 --> 00:29:14,720
Yeah, it would be a disruptive
thing for the network if blocks
554
00:29:14,720 --> 00:29:17,360
take minutes or even longer than
that to validate.
555
00:29:17,360 --> 00:29:22,600
And so the question is, how do
we prevent those blocks from
556
00:29:22,600 --> 00:29:24,400
being created now?
For now, the.
557
00:29:24,640 --> 00:29:28,240
Just to give you a comparison,
how long does it take to
558
00:29:28,240 --> 00:29:30,520
validate average block right
now?
559
00:29:31,080 --> 00:29:33,640
I think on a good laptop, a
fraction of a second.
560
00:29:33,760 --> 00:29:36,240
Yeah, and on like a Raspberry
Pi.
561
00:29:36,800 --> 00:29:38,200
Probably one second.
Yeah.
562
00:29:38,880 --> 00:29:40,480
OK.
Just to sort of paint the
563
00:29:40,480 --> 00:29:42,680
context there.
OK.
564
00:29:42,680 --> 00:29:46,880
So the solution?
Well, the solution is.
565
00:29:47,160 --> 00:29:49,600
In the original proposal by
Bluemath, there was a solution
566
00:29:50,560 --> 00:29:53,480
which was just changing a few
rules.
567
00:29:53,520 --> 00:29:56,600
I think Now this discussion
about a slightly different
568
00:29:56,600 --> 00:29:59,880
solution, so that's actually
still ongoing research.
569
00:29:59,880 --> 00:30:01,560
What is the actual best
solution?
570
00:30:02,200 --> 00:30:06,720
But the gist of it is that there
are certain extra rules in
571
00:30:06,720 --> 00:30:09,560
SegWit and in Taproot that make
the script safer.
572
00:30:09,840 --> 00:30:12,320
This was why the block size
could be increased with SegWit
573
00:30:12,320 --> 00:30:15,240
because any of these extra
SegWit transactions would not be
574
00:30:15,240 --> 00:30:17,640
as expensive and as slow.
These worst case couldn't
575
00:30:17,640 --> 00:30:20,200
happen.
But it looks like some of these
576
00:30:20,200 --> 00:30:23,360
rules should also be applied to
legacy scripts, to legacy
577
00:30:23,360 --> 00:30:25,960
transactions.
And then the problem is you
578
00:30:25,960 --> 00:30:29,160
can't just apply all of Seguid's
rules to legacy transactions.
579
00:30:29,160 --> 00:30:31,840
So you have to be very careful
which ones you'd want to apply.
580
00:30:33,600 --> 00:30:36,720
Main problem there is, you know,
somebody might have a
581
00:30:36,720 --> 00:30:41,880
transaction that they put in a
cold wallet and or like offline
582
00:30:41,880 --> 00:30:43,080
wallet, right?
So we don't see it on the
583
00:30:43,080 --> 00:30:44,920
blockchain and now they want to
broadcast it.
584
00:30:44,920 --> 00:30:47,200
But we changed the rules and now
they can't spend it anymore.
585
00:30:49,240 --> 00:30:52,240
Now, you know, the, the changes
that people have in mind would
586
00:30:52,240 --> 00:30:56,400
only impact the most bizarre,
unrealistic transactions that
587
00:30:56,400 --> 00:30:59,600
you can possibly imagine.
But still that that could still
588
00:30:59,600 --> 00:31:02,000
be controversial.
So the, the key is to find the
589
00:31:02,160 --> 00:31:07,160
absolute minimum extra rules
that you need in order to fix
590
00:31:07,160 --> 00:31:10,000
the problem and no more.
Because, you know, the simplest
591
00:31:10,000 --> 00:31:11,640
solution would just be to say,
hey, you know what?
592
00:31:12,240 --> 00:31:15,200
You can only make type of
transactions that would that
593
00:31:15,200 --> 00:31:18,800
would fix the problem, but it
would basically make a lot of
594
00:31:18,800 --> 00:31:22,320
people very angry.
Yeah, I thought the idea was
595
00:31:22,320 --> 00:31:28,160
also to like only apply these
new rules from a certain block
596
00:31:28,160 --> 00:31:32,320
height, so if you already had
your coins in some.
597
00:31:32,960 --> 00:31:36,720
So those are other things you
couldn't do, you could do to
598
00:31:36,720 --> 00:31:40,320
restrict the possible damage
that a rule could do.
599
00:31:40,320 --> 00:31:42,480
But the trade off there is
complexity.
600
00:31:42,880 --> 00:31:46,640
So a rule that says only do this
after this block or only when
601
00:31:46,640 --> 00:31:49,400
the coins you're spending is
from this block, that's extra
602
00:31:49,400 --> 00:31:51,360
complexity that you'd prefer not
to have.
603
00:31:52,560 --> 00:31:55,720
Plus, you know, if the attack,
this is one of the problems,
604
00:31:55,720 --> 00:31:59,720
once you publish the exact fix,
somebody might come up with what
605
00:31:59,720 --> 00:32:03,280
it is fixing and then do the
attack before the soft work is
606
00:32:03,280 --> 00:32:06,440
activated.
That's probably inevitable
607
00:32:06,440 --> 00:32:07,840
anyway, just like the time warp
attack.
608
00:32:07,840 --> 00:32:11,840
Everybody knows what to do
there, so there's that.
609
00:32:13,200 --> 00:32:16,240
Yeah, I, well, you really want
to avoid that people lose their
610
00:32:16,240 --> 00:32:17,520
coins, right?
That's kind of.
611
00:32:17,640 --> 00:32:20,400
A yeah.
So realistically, even the
612
00:32:20,400 --> 00:32:23,520
original proposal by by Bluemat,
I think it was changed a bit for
613
00:32:23,520 --> 00:32:26,640
him because there were several
things that he wanted to change
614
00:32:26,680 --> 00:32:30,560
for this problem and I think
they ended up dropping one of
615
00:32:30,560 --> 00:32:34,160
these things.
So hopefully there's a way to
616
00:32:34,160 --> 00:32:37,840
make sure that you can like
there's that nothing gets
617
00:32:37,840 --> 00:32:41,160
unspendable.
It might just take more fees for
618
00:32:41,160 --> 00:32:43,120
example.
Right.
619
00:32:44,640 --> 00:32:46,400
OK.
So that was slow scripts.
620
00:32:47,200 --> 00:32:49,840
Are we done with those scripts?
Yep, we are.
621
00:32:50,240 --> 00:32:54,040
All right then the next point is
about banning 64 byte
622
00:32:54,040 --> 00:32:57,120
transactions, is that right?
Yes, 64 bytes bad.
623
00:32:57,880 --> 00:33:00,440
Why?
Well, we've, we've mentioned
624
00:33:00,440 --> 00:33:01,960
this a few times in other
episodes.
625
00:33:01,960 --> 00:33:04,600
I don't think we've done an
actual episode about it, but in
626
00:33:04,600 --> 00:33:08,360
our episode 81 we talked about a
change to Bitcoin Core 25 that
627
00:33:08,800 --> 00:33:16,000
makes transactions that are 65
bytes or greater.
628
00:33:16,400 --> 00:33:20,280
I think they make makes them
illegal again or something weird
629
00:33:20,400 --> 00:33:22,800
about that.
I forgot what exactly we
630
00:33:22,800 --> 00:33:24,600
discussed.
The point is, 64 byte
631
00:33:24,600 --> 00:33:27,240
transactions are bad, and the
reason they're bad is because
632
00:33:27,240 --> 00:33:30,680
they look the same as 232 byte
transactions next to each other
633
00:33:30,680 --> 00:33:35,520
in the block because of the way
the Merkel trees are made.
634
00:33:37,000 --> 00:33:38,280
Sorry, we have to take step
back.
635
00:33:38,280 --> 00:33:40,080
It shows.
What does it mean?
636
00:33:40,320 --> 00:33:44,120
Why is there such a thing as a
64 byte transaction and also
637
00:33:44,120 --> 00:33:46,000
such a thing as a 32 byte
transaction?
638
00:33:46,400 --> 00:33:48,720
Why aren't all transactions the
same number of bytes?
639
00:33:49,280 --> 00:33:51,440
Because the size of a
transaction depends on the
640
00:33:51,440 --> 00:33:54,480
number of inputs, the number of
outputs, what kind of script you
641
00:33:54,480 --> 00:33:56,840
have in those inputs and
outputs, and whether it's has a
642
00:33:56,840 --> 00:33:58,320
witness or not.
OK.
643
00:33:58,880 --> 00:34:06,680
And then 64.
But a 32 transaction would also
644
00:34:06,680 --> 00:34:09,440
look like 216 byte transactions,
right?
645
00:34:09,440 --> 00:34:11,880
Yeah, but I don't think you can
make a 16 byte transaction
646
00:34:11,880 --> 00:34:18,360
because simply it wouldn't fit.
OK, and now 128 byte transaction
647
00:34:18,360 --> 00:34:22,840
would look like 432 bytes.
Why is 64 singled out is my
648
00:34:22,840 --> 00:34:27,120
question.
OK, so the Merkle tree that the
649
00:34:27,120 --> 00:34:32,199
Bitcoin transactions are stored
in takes the SHA 256 hash of
650
00:34:32,639 --> 00:34:38,920
every transaction and then puts
that next to the shot to 56 hash
651
00:34:38,920 --> 00:34:41,560
of the next transaction.
So you take all the transactions
652
00:34:41,560 --> 00:34:44,760
and you take their shot to 56
hashes, and then in pairs you
653
00:34:44,760 --> 00:34:47,440
put those hashes next to each
other and the size of the hash
654
00:34:47,440 --> 00:34:52,080
is 32 bytes.
Right, that's always 32 bytes,
655
00:34:52,239 --> 00:34:54,800
yes.
Yeah, so.
656
00:34:54,840 --> 00:34:57,040
Two hashes.
I remember, I vaguely remember
657
00:34:57,160 --> 00:34:58,760
this problem We.
Discussed this.
658
00:34:58,800 --> 00:35:01,400
So two hashes next to each other
is 64 bytes.
659
00:35:01,800 --> 00:35:04,920
And so then the question is and
I when you are.
660
00:35:04,920 --> 00:35:07,480
So I guess it's not 232 byte
transactions because you can't
661
00:35:07,480 --> 00:35:10,440
have 32 byte transactions too
small because the minimum size
662
00:35:10,440 --> 00:35:12,640
of a transaction.
Keep in mind that a transaction
663
00:35:12,640 --> 00:35:17,840
has an input at least, and the
input is already 32 bytes plus a
664
00:35:17,840 --> 00:35:20,920
little bit more because the
input of a transaction refers to
665
00:35:20,920 --> 00:35:22,400
the hash of a previous
transaction.
666
00:35:22,440 --> 00:35:25,800
We just set the #32 bytes.
So and then it has to have a
667
00:35:25,800 --> 00:35:28,640
number and a few other things.
So yeah, a transaction cannot be
668
00:35:28,640 --> 00:35:31,480
32 bytes, but it can be. 64.
Bytes.
669
00:35:31,640 --> 00:35:34,400
It would be a pretty nonsensical
transaction, but it can be 32
670
00:35:34,400 --> 00:35:40,360
bytes and so 6464, yeah.
But it that would look like 2
671
00:35:40,360 --> 00:35:44,080
hashes that are both 32 bytes.
And why is that a problem?
672
00:35:44,680 --> 00:35:47,040
Because like, where are these
hashes in the blockchain?
673
00:35:47,040 --> 00:35:49,080
It's caused multiple problems in
the past Exactly.
674
00:35:49,080 --> 00:35:53,720
So the there is a in the in each
block is a Merkel tree of all
675
00:35:53,720 --> 00:35:55,680
the transactions in that block
in a tree.
676
00:35:56,160 --> 00:35:59,280
And and all the leaves of the
tree are 32 bytes these
677
00:35:59,280 --> 00:36:01,040
transactions.
And then you go one level up and
678
00:36:01,040 --> 00:36:02,840
it's 32 bytes again.
It's 32 bytes again.
679
00:36:03,640 --> 00:36:06,600
And now what you can do is you
can give somebody a block and
680
00:36:06,600 --> 00:36:08,840
say here's a block and here's
all the transactions in this
681
00:36:08,840 --> 00:36:11,760
block.
And then you verify it and you
682
00:36:11,760 --> 00:36:17,520
see this these 32 transactions.
Sorry, you see these 2 * 30 twos
683
00:36:17,960 --> 00:36:19,840
and you can mine them and, and
it looks all good.
684
00:36:20,200 --> 00:36:25,080
But somebody could leave out the
the actual transactions and just
685
00:36:25,080 --> 00:36:28,280
pretend that it's only the 64
byte transactions instead of two
686
00:36:28,280 --> 00:36:30,720
separate ones.
But then you validate the 64
687
00:36:30,720 --> 00:36:34,000
byte transaction and you say,
hey, this is an invalid
688
00:36:34,000 --> 00:36:35,640
transaction.
So the whole block is invalid.
689
00:36:37,360 --> 00:36:39,360
And now you think this block is
invalid.
690
00:36:39,600 --> 00:36:41,760
And the next time you see this
block, because somebody gives
691
00:36:41,760 --> 00:36:45,000
you the same block hash, you're
like, I don't, you know, I'm not
692
00:36:45,000 --> 00:36:46,520
going to check this block, it's
invalid.
693
00:36:47,080 --> 00:36:50,240
But actually it's not invalid
because somebody sent you,
694
00:36:50,640 --> 00:36:53,120
because now you got the real one
where you actually have the two
695
00:36:53,120 --> 00:36:56,440
separate transactions in it.
I'm lost.
696
00:36:57,840 --> 00:37:00,280
Who's who's, who's the target
here?
697
00:37:00,280 --> 00:37:02,360
Who's the what's the problem and
what's the like?
698
00:37:02,360 --> 00:37:03,760
Who are we?
Targeting the the different
699
00:37:03,760 --> 00:37:06,480
targets.
So this example I think was
700
00:37:06,560 --> 00:37:10,000
could be used to make a network
split where you would make a
701
00:37:10,000 --> 00:37:14,560
real block with 232 byte
transactions in it, but that
702
00:37:14,560 --> 00:37:17,080
when you combine those 232 byte
transactions it would also make
703
00:37:17,120 --> 00:37:21,200
a real 64 byte transaction.
So the hash of those, the hashes
704
00:37:21,200 --> 00:37:24,080
of those thirty of those two
transactions, not 32 byte
705
00:37:24,080 --> 00:37:27,080
transactions, but the hashes of
those two transactions, if you
706
00:37:27,080 --> 00:37:30,600
add them together, look like a
real transaction, but it's an
707
00:37:30,600 --> 00:37:35,960
invalid transaction.
So now you are or or the other
708
00:37:35,960 --> 00:37:38,600
way around.
The 64 byte thing is valid, but
709
00:37:38,600 --> 00:37:40,720
the two individual transactions
are invalid.
710
00:37:41,040 --> 00:37:46,080
So if you give somebody a block,
it will have the same hash at
711
00:37:46,080 --> 00:37:48,640
the top because the Merkle tree
is the same at the top.
712
00:37:48,640 --> 00:37:50,480
And that's the only thing you're
you're communicating when you're
713
00:37:50,480 --> 00:37:53,240
communicating a block hash.
So I'm giving you a block hash
714
00:37:53,560 --> 00:37:55,480
and I'm giving somebody else the
same block hash.
715
00:37:56,200 --> 00:38:01,200
But I'm going to give you the
two transactions and I'm going
716
00:38:01,200 --> 00:38:04,680
to give this other person the
164 byte transaction.
717
00:38:05,280 --> 00:38:07,760
And now one of you is going to
say this block is invalid and
718
00:38:07,760 --> 00:38:09,280
the other is going to say this
block is valid.
719
00:38:10,040 --> 00:38:13,760
Now you have a network split.
Yeah, OK.
720
00:38:13,760 --> 00:38:16,640
I kind of get that now.
Except what?
721
00:38:16,640 --> 00:38:18,440
What do you mean?
Why would they check for
722
00:38:18,440 --> 00:38:23,080
different things?
Because I've given you the the
723
00:38:23,080 --> 00:38:25,680
block hash, the root of the
Merkle tree, I've also given you
724
00:38:25,680 --> 00:38:27,480
all the transactions
individually.
725
00:38:27,480 --> 00:38:31,480
OK, so you're actually putting
those back in a tree, but I'm
726
00:38:31,480 --> 00:38:34,440
giving you a different set of
transactions than I'm giving the
727
00:38:34,440 --> 00:38:36,200
other person.
They get the same root of the
728
00:38:36,200 --> 00:38:38,800
tree, but one of them will say,
hey, this transaction's invalid
729
00:38:38,800 --> 00:38:40,720
because I don't know it's
spending more money than it's
730
00:38:40,720 --> 00:38:42,800
earning.
Some other rule that's violated.
731
00:38:43,920 --> 00:38:45,520
Right.
And that's because it's not
732
00:38:45,520 --> 00:38:49,360
really a transaction.
It's really 242 bytes hashes.
733
00:38:49,920 --> 00:38:51,440
Yeah.
Am I saying that's right?
734
00:38:51,480 --> 00:38:54,080
Of real transactions.
Of actual transactions, yeah.
735
00:38:54,080 --> 00:38:56,000
So for one person.
One person.
736
00:38:56,000 --> 00:38:59,920
Sees a 60. 4 byte transaction,
one person sees 1 invalid 64
737
00:38:59,920 --> 00:39:01,440
byte transaction.
Or valid.
738
00:39:02,800 --> 00:39:05,960
One person sees 164 byte
transaction, the other person
739
00:39:05,960 --> 00:39:08,280
sees two other transactions.
Doesn't matter what size they
740
00:39:08,280 --> 00:39:11,600
are and if.
If these two transactions are
741
00:39:11,600 --> 00:39:15,400
invalid but the 64 byte point is
valid, then you come to a
742
00:39:15,400 --> 00:39:19,680
different conclusion at the
block and now you have.
743
00:39:19,680 --> 00:39:22,840
And this depends on which
transactions you saw earlier
744
00:39:23,080 --> 00:39:27,160
essentially kind of.
Well, the rest of the block is
745
00:39:27,160 --> 00:39:29,720
the same, right?
So it just.
746
00:39:29,880 --> 00:39:31,880
It's just that one of these
transactions is actually
747
00:39:31,880 --> 00:39:34,760
invalid.
So the 64 byte transaction might
748
00:39:34,760 --> 00:39:36,240
be invalid, or it might be
valid.
749
00:39:37,280 --> 00:39:38,840
Yeah, I think.
Has nothing to do with what
750
00:39:38,840 --> 00:39:40,960
you've seen before.
Yeah, you're basically just
751
00:39:40,960 --> 00:39:44,120
giving two versions of the same
block that you're, you know,
752
00:39:44,120 --> 00:39:47,080
think is the same block because
it only remembers the hash and
753
00:39:47,080 --> 00:39:48,880
it's not.
So that that bug has been fixed
754
00:39:49,480 --> 00:39:52,640
by simply, not by simply not
storing the block if it's
755
00:39:52,640 --> 00:39:54,200
invalid, so.
No, hang on.
756
00:39:55,600 --> 00:39:58,520
I I have a question.
I I still have one question.
757
00:39:58,680 --> 00:40:01,200
All right, You and I are both
running a node.
758
00:40:01,240 --> 00:40:05,480
OK, Yeah.
Now some joker sends as a
759
00:40:05,480 --> 00:40:10,800
transaction sends us a block
that has this 164 byte
760
00:40:10,800 --> 00:40:14,880
transaction in it.
Yes, Why would my notes look at
761
00:40:14,880 --> 00:40:18,840
this like 242 byte transactions
while your note is looking at it
762
00:40:18,840 --> 00:40:24,800
like a 164 byte transaction?
Because as the Joker is sending
763
00:40:24,800 --> 00:40:28,000
you the hash of the block and
it's sending you all the
764
00:40:28,000 --> 00:40:32,880
individual transactions, so he's
sending you two individual
765
00:40:32,880 --> 00:40:36,320
transactions at the end of this
block, and it's sending me one
766
00:40:36,320 --> 00:40:38,200
individual transaction of 64
bytes.
767
00:40:38,840 --> 00:40:40,280
So they're sending us different.
Things.
768
00:40:40,280 --> 00:40:44,680
Isn't that just in the block?
Isn't that just the block that
769
00:40:44,680 --> 00:40:46,240
he's sending?
That's the block, right?
770
00:40:46,240 --> 00:40:47,960
The in the block is the
transaction.
771
00:40:47,960 --> 00:40:50,040
Give it a block when you.
When you receive a block, what
772
00:40:50,040 --> 00:40:52,080
it really is is a is a message,
right?
773
00:40:52,080 --> 00:40:55,440
And the message starts with the
header and it's followed by the
774
00:40:55,440 --> 00:40:57,080
list of every single
transaction.
775
00:40:57,640 --> 00:41:00,400
And so that list of
transactions, yeah, it's very,
776
00:41:00,400 --> 00:41:02,000
it's different.
So if you were to look at the
777
00:41:02,000 --> 00:41:04,560
bytes on on the, if you printed
it out a piece of paper, you
778
00:41:04,560 --> 00:41:06,320
would see that at the end of the
piece of paper, it's different.
779
00:41:06,520 --> 00:41:07,720
OK, you and I got a different.
Block.
780
00:41:07,720 --> 00:41:10,400
We got a different block.
It just has the same hash.
781
00:41:10,400 --> 00:41:13,880
Yes, it hashes to the same hash.
And because you say it's
782
00:41:13,880 --> 00:41:15,720
invalid.
Yeah, because it is invalid.
783
00:41:15,720 --> 00:41:18,280
The one you send me is invalid.
Yours exactly, but it's only
784
00:41:18,280 --> 00:41:20,000
sending you.
Somebody else sends you the
785
00:41:20,000 --> 00:41:21,880
correct one.
Yeah, then I'll be like, no, I
786
00:41:21,880 --> 00:41:23,720
already saw this and it was
invalid.
787
00:41:23,760 --> 00:41:25,360
Yeah.
And so that and that problem,
788
00:41:25,360 --> 00:41:28,160
you know, keep in mind that this
problem was discovered in 2012
789
00:41:28,160 --> 00:41:29,800
or something.
So back then that attack was
790
00:41:29,800 --> 00:41:31,720
cheap.
Right now this attack would be
791
00:41:31,720 --> 00:41:33,960
expensive.
But the attack was fixed because
792
00:41:33,960 --> 00:41:36,440
basically when this happens to
you, you say, hey, this buck is
793
00:41:36,440 --> 00:41:37,520
invalid.
You just forget it.
794
00:41:37,760 --> 00:41:40,040
And so the next time somebody
sends you the correct one,
795
00:41:40,040 --> 00:41:42,400
you're fine.
So that attack is fixed.
796
00:41:42,840 --> 00:41:45,000
But then there was other ways
that you can fool like clients
797
00:41:45,000 --> 00:41:48,120
like SPV wallets using the same
trick because they are asking
798
00:41:48,120 --> 00:41:50,440
just for an SPV proof.
So they just want proof that a
799
00:41:50,440 --> 00:41:53,200
transaction was included.
And you could now give them a
800
00:41:53,200 --> 00:41:55,640
transaction that they think is
included because you gave the
801
00:41:55,640 --> 00:41:59,280
SPV proof, but it wasn't
included because the real block
802
00:41:59,280 --> 00:42:02,760
had two separate transactions
that happened to combine to this
803
00:42:02,760 --> 00:42:06,000
one fake transaction.
And this could be used to steal
804
00:42:06,000 --> 00:42:09,440
light wallets, but possibly also
to rob site chains if those site
805
00:42:09,440 --> 00:42:12,560
chains only use SVP proofs for
peg insurance and peg outs.
806
00:42:13,560 --> 00:42:17,080
And that problem I think was
solved by telling light clients
807
00:42:17,080 --> 00:42:19,360
to be careful.
I don't think it was actually
808
00:42:19,360 --> 00:42:21,680
solved.
OK, back to the great consensus
809
00:42:21,680 --> 00:42:23,960
cleanup revival.
What's the solution here?
810
00:42:23,960 --> 00:42:25,800
Don't allow 64 byte
transactions.
811
00:42:25,800 --> 00:42:28,040
Well, what if my transaction is
64 bytes?
812
00:42:28,040 --> 00:42:32,600
Though then you are out of luck.
So if you still.
813
00:42:32,600 --> 00:42:36,200
Have.
So if I create, I create a
814
00:42:36,200 --> 00:42:41,000
transaction that consists of 64
bytes because I want to pay
815
00:42:41,000 --> 00:42:45,760
exactly this many people, this
many coins with the this many
816
00:42:45,760 --> 00:42:47,120
UTXO.
SI think the and.
817
00:42:47,240 --> 00:42:49,800
The Bitcoin network say no, your
money is not valid.
818
00:42:49,800 --> 00:42:52,960
Here, yeah, I think the actual
examples would be burning coins.
819
00:42:52,960 --> 00:42:56,520
So you can make an opportune
transaction that burns your
820
00:42:56,520 --> 00:43:00,400
coins, doesn't send it anywhere,
and that can be shorter than 64
821
00:43:00,400 --> 00:43:02,200
bytes, but it could also be 64
bytes.
822
00:43:02,600 --> 00:43:05,720
So if you want to burn your
money using an Opportune that is
823
00:43:05,720 --> 00:43:09,480
exactly 64 bytes in total, then
yeah, you can't do that.
824
00:43:09,720 --> 00:43:12,000
Are there already?
Are there no normal transactions
825
00:43:12,000 --> 00:43:15,440
that are exactly 64 bytes?
I believe not, so you can
826
00:43:15,440 --> 00:43:20,080
already not send those in the
Maple today the IT won't be
827
00:43:20,080 --> 00:43:21,240
relayed.
OK.
828
00:43:21,280 --> 00:43:23,480
And so I think that was the
change in version 25.
829
00:43:23,480 --> 00:43:28,360
So I think there was a rule that
says nothing under 64 bytes or
830
00:43:28,360 --> 00:43:31,720
sorry, nothing under 65 bytes.
That was the Maple rule.
831
00:43:32,000 --> 00:43:34,680
And then people like well, but
it could be useful to have a 63
832
00:43:34,680 --> 00:43:38,560
byte or a 62 byte transaction to
burn your coins and so the I
833
00:43:38,560 --> 00:43:41,600
think the rule was changed to no
64 bytes.
834
00:43:41,960 --> 00:43:45,400
So the difference.
Is make this make this consensus
835
00:43:45,400 --> 00:43:48,880
rather than policy?
OK, so most transactions are
836
00:43:48,880 --> 00:43:51,680
well over 64 bytes, or at least
more than 64 bytes.
837
00:43:51,680 --> 00:43:54,200
That's that's normal for a
transaction to be more than 64
838
00:43:54,200 --> 00:43:56,640
bytes.
If you see a 64 byte
839
00:43:56,640 --> 00:43:58,800
transaction, it's kind of
something special.
840
00:43:59,200 --> 00:44:00,440
Yeah, then there's probably an
attack.
841
00:44:00,440 --> 00:44:03,360
OK, right.
And now the great consensus
842
00:44:03,360 --> 00:44:06,200
clean up says let's just get rid
of that altogether.
843
00:44:06,520 --> 00:44:10,360
However, 63 or 62, that's still
OK.
844
00:44:10,680 --> 00:44:13,320
If if you really do, like if
you're not attacking but you're
845
00:44:13,600 --> 00:44:15,200
burning coins, then that should
work.
846
00:44:15,640 --> 00:44:20,240
But yeah, so basically if people
make 64 by transactions in the
847
00:44:20,240 --> 00:44:23,440
future and this software
happens, then their transaction
848
00:44:23,440 --> 00:44:26,760
wouldn't be confirmed.
Then I have to make a new
849
00:44:26,760 --> 00:44:30,320
transaction that's either 63 or
65 or something else, as long as
850
00:44:30,320 --> 00:44:32,240
it's not 60.
Four, and you can probably
851
00:44:32,240 --> 00:44:35,760
malleate it.
So we, I think we talked about
852
00:44:35,760 --> 00:44:39,160
transaction evaluation where you
can like mess with another
853
00:44:39,160 --> 00:44:40,720
transaction.
So you might, even if you lost
854
00:44:40,720 --> 00:44:43,560
the original coin that you used
to make this thing, you think
855
00:44:43,560 --> 00:44:47,000
you might be able to just make
it 1 byte longer, but I'm not
856
00:44:47,000 --> 00:44:48,440
entirely sure about that.
Right.
857
00:44:49,320 --> 00:44:51,560
OK, got it.
Sounds like.
858
00:44:52,280 --> 00:44:54,880
But this is another case of
like, yes, it would be, you
859
00:44:54,880 --> 00:44:57,760
know, you could just ban
anything under 64, but or
860
00:44:57,760 --> 00:45:00,640
anything under 65, but you want
to make the minimum change
861
00:45:00,640 --> 00:45:05,080
possible to reduce controversy.
That's not too complicated, OK.
862
00:45:05,880 --> 00:45:10,120
Last one BIP 3034.
Yeah, we did a whole episode
863
00:45:10,120 --> 00:45:13,560
about this called episode 87 and
it was called the Block
864
00:45:13,560 --> 00:45:18,520
1,983,702 problem.
Right.
865
00:45:18,520 --> 00:45:20,280
What was that problem again?
It was.
866
00:45:20,440 --> 00:45:22,800
It was about two transactions
that look similar, right?
867
00:45:23,400 --> 00:45:25,680
Yeah.
So the TLDR of this one is that
868
00:45:26,720 --> 00:45:30,760
there was a BIP 30 that prevents
duplicate transactions because
869
00:45:30,760 --> 00:45:33,520
having duplicate transactions,
transactions with the same hash,
870
00:45:34,000 --> 00:45:36,920
it causes problems.
You can override coinbases do do
871
00:45:36,920 --> 00:45:38,760
all sorts of weird things.
It happened a few times in the
872
00:45:38,760 --> 00:45:40,760
beginning of Bitcoin.
It was fixed.
873
00:45:41,120 --> 00:45:43,200
The problem of this fix is that
it was a slow fix.
874
00:45:43,360 --> 00:45:46,080
So the every time there's a new
block coming in, you have to
875
00:45:46,080 --> 00:45:48,400
check every transaction to make
sure that it doesn't already
876
00:45:48,400 --> 00:45:50,760
exist.
And this check is is expensive,
877
00:45:50,760 --> 00:45:56,080
requires a lot of disk reading,
unfortunately.
878
00:45:56,080 --> 00:45:57,360
And so there was a way to speed
it up.
879
00:45:57,360 --> 00:46:00,960
The way to speed it up was to
make to force the Coinbase
880
00:46:00,960 --> 00:46:03,160
transaction to have the block
hide in it.
881
00:46:04,080 --> 00:46:06,720
So that makes every transaction,
every Coinbase transaction
882
00:46:06,720 --> 00:46:09,800
unique, and since every
transaction eventually descends
883
00:46:09,800 --> 00:46:12,080
from a Coinbase transaction,
every descendant is unique.
884
00:46:12,160 --> 00:46:15,360
Yeah, that way you can't have
duplicate transactions anymore.
885
00:46:15,360 --> 00:46:17,120
Yeah.
And so then people thought, OK,
886
00:46:17,120 --> 00:46:21,080
so we can turn off this
expensive check, but turns out
887
00:46:21,080 --> 00:46:26,000
you can't because there are some
very old transactions before
888
00:46:26,000 --> 00:46:30,320
this BIIP 34 rule was introduced
that if you read them, you could
889
00:46:30,320 --> 00:46:32,800
interpret the, you know, the
first bytes of those
890
00:46:32,800 --> 00:46:36,360
transactions as a version.
Oh sorry, as an as a block hide.
891
00:46:36,360 --> 00:46:37,800
Yeah.
And.
892
00:46:37,840 --> 00:46:40,560
So there's something in these
old transactions, in these old
893
00:46:40,560 --> 00:46:43,160
Utxos, I guess we should say.
Yeah, that is effectively the
894
00:46:43,160 --> 00:46:44,440
same as putting a block hide in
there.
895
00:46:44,440 --> 00:46:46,560
Yeah, but the wrong one.
Yeah, yeah.
896
00:46:47,040 --> 00:46:48,560
Yeah.
And so these ones are gonna
897
00:46:48,560 --> 00:46:50,000
start.
We're gonna start encountering
898
00:46:50,000 --> 00:46:51,440
these.
And we've already encountered a
899
00:46:51,440 --> 00:46:52,680
few, but they didn't cause
problems.
900
00:46:53,480 --> 00:46:57,240
So we got lucky.
And so as of the first one we're
901
00:46:57,240 --> 00:47:00,840
going to encounter again is
block 1,983,702.
902
00:47:01,360 --> 00:47:04,240
So there is an old transaction
out there that looks like it's
903
00:47:04,240 --> 00:47:06,640
at that height.
So in theory, somebody could
904
00:47:06,640 --> 00:47:09,880
then make a could make a
Coinbase transaction that's a
905
00:47:09,880 --> 00:47:13,040
duplicate of that old one.
And we don't want that.
906
00:47:13,480 --> 00:47:17,040
So the BIP 30 check, the slow
check is re enabled from that
907
00:47:17,040 --> 00:47:21,200
hide on and that's annoying
because that check, as we said,
908
00:47:21,200 --> 00:47:25,000
is slow.
So the proposal here is to do
909
00:47:25,000 --> 00:47:28,280
something else that makes sure
that this duplication cannot
910
00:47:28,280 --> 00:47:30,360
happen.
So not just putting the height
911
00:47:30,360 --> 00:47:32,920
in the Coinbase, but also
putting something else in it.
912
00:47:33,840 --> 00:47:35,800
What that's something else is we
don't know.
913
00:47:36,160 --> 00:47:40,120
My favorite is to make SegWit
mandatory as in SegWit
914
00:47:40,120 --> 00:47:45,520
commitment, because every SegWit
block has a has an opportune and
915
00:47:45,520 --> 00:47:47,920
followed by the hash of the
witness data.
916
00:47:48,600 --> 00:47:51,320
And right now, if there is no
transactions in the block,
917
00:47:51,840 --> 00:47:54,360
including if there's no secret
transactions even in the
918
00:47:54,360 --> 00:47:56,560
Coinbase, well then there's no
witness commitment.
919
00:47:56,800 --> 00:47:58,480
And so that opportunity is not
present.
920
00:47:58,960 --> 00:48:02,680
But you could make it mandatory
from off as basically you could
921
00:48:02,680 --> 00:48:05,720
make it mandatory starting at
block 1,983,000.
922
00:48:05,720 --> 00:48:09,960
And so people will have 20 years
to upgrade, but if they don't,
923
00:48:09,960 --> 00:48:12,360
they could accidentally mind an
invalid block at that height.
924
00:48:12,800 --> 00:48:15,600
Right.
There's different ways.
925
00:48:15,680 --> 00:48:19,240
We we discussed this at length
in the other episode, of course,
926
00:48:19,240 --> 00:48:22,080
which was 87.
Yeah, for anyone who wants to
927
00:48:22,080 --> 00:48:24,920
know more about this problem.
So that's roughly the.
928
00:48:25,000 --> 00:48:28,800
Also the potential fix 87.
So that's the whole great
929
00:48:28,800 --> 00:48:31,840
consensus cleanup.
And so as you can hear, some
930
00:48:31,840 --> 00:48:33,440
changes are very
straightforward.
931
00:48:33,440 --> 00:48:35,800
There's not really any
discussion, some there is
932
00:48:35,800 --> 00:48:41,000
discussion.
And so we'll have to figure that
933
00:48:41,000 --> 00:48:42,960
out and then at some point
somebody will have to take the
934
00:48:42,960 --> 00:48:46,840
initiative to actually proposes
as a soft work, do activation
935
00:48:46,840 --> 00:48:48,480
parameters, hope there's no
drama.
936
00:48:49,440 --> 00:48:54,280
Well, that is kind of one of
the, you know, side goals of
937
00:48:54,280 --> 00:48:59,920
this proposal, I would say is
figuring out how we actually do
938
00:48:59,920 --> 00:49:02,440
soft forks and how we actually
do Bitcoin upgrades.
939
00:49:02,480 --> 00:49:04,400
Exactly.
This was proposed long before
940
00:49:04,400 --> 00:49:07,440
Taproot as a way to sort of get
over the seguatrama.
941
00:49:07,600 --> 00:49:12,200
Yeah, like we're still, it's
still not clear how we're
942
00:49:12,200 --> 00:49:13,880
supposed to do these kinds of
things.
943
00:49:13,960 --> 00:49:17,600
So then the idea was let's do
something that's very
944
00:49:17,600 --> 00:49:22,400
uncontroversial that everyone
should or does or will agree on.
945
00:49:22,400 --> 00:49:25,480
There's nothing like, it's just
very obvious bugs that we're
946
00:49:25,480 --> 00:49:28,800
going to fix, and then we can
figure out how we're actually
947
00:49:28,800 --> 00:49:33,040
supposed to do these soft forks.
And then, you know, it's sort of
948
00:49:33,040 --> 00:49:36,960
a good trial run for, you know,
future software, I guess.
949
00:49:36,960 --> 00:49:39,400
Kind of now we've already done
Taproof, but of course there was
950
00:49:39,400 --> 00:49:41,600
still discussion about how that
software was activated.
951
00:49:42,040 --> 00:49:45,440
So I don't know if we really now
have a, you know, have broad
952
00:49:45,440 --> 00:49:46,600
consensus on how to do.
This.
953
00:49:46,600 --> 00:49:47,720
Oh, we definitely don't.
Sure.
954
00:49:47,920 --> 00:49:50,720
But this may be another case of
like nobody cares what the
955
00:49:50,720 --> 00:49:52,680
activation mechanism is, just
activated.
956
00:49:54,600 --> 00:49:58,240
The main thing is of course this
takes away the options of minors
957
00:49:58,240 --> 00:50:00,920
to do a time warp protect, So if
they actually like to keep that
958
00:50:00,920 --> 00:50:04,760
option, they might veto it.
And then you get into more
959
00:50:04,760 --> 00:50:08,840
difficult territory.
Well, but they may.
960
00:50:08,920 --> 00:50:11,600
I don't know if we want to get,
we don't want to get into the
961
00:50:11,720 --> 00:50:14,200
activation discussion in this
episode.
962
00:50:14,320 --> 00:50:15,920
We do not.
I'm just saying like it might be
963
00:50:15,920 --> 00:50:17,200
straightforward, it might not
be.
964
00:50:17,200 --> 00:50:19,040
And we'll have to.
We may have to.
965
00:50:19,040 --> 00:50:21,240
No, I'm telling you it will not
be OK.
966
00:50:22,400 --> 00:50:24,640
For sure I'm more bullish.
OK.
967
00:50:25,960 --> 00:50:28,240
And of course, we keep in mind
that you can deploy multiple
968
00:50:28,240 --> 00:50:32,160
softworks in parallel, so this
doesn't have to be before or
969
00:50:32,160 --> 00:50:36,680
after some your favorite feature
X you can activate, I don't
970
00:50:36,680 --> 00:50:38,160
know, 10 soft forks at the same
time.
971
00:50:38,760 --> 00:50:41,120
Yeah, Remember when people
thought that would actually
972
00:50:41,120 --> 00:50:43,560
happen?
Good times.
973
00:50:43,680 --> 00:50:44,280
Good times.
Good.
974
00:50:44,280 --> 00:50:46,120
Times indeed.
I'm just saying it, you know,
975
00:50:46,120 --> 00:50:48,960
don't worry about that, that
aspect, OK, I think that's all
976
00:50:48,960 --> 00:50:50,760
we've got.
Thank you for listening to
977
00:50:50,760 --> 00:50:52,040
Bitcoin.
Explain.