WEBVTT

00:00:00.500 --> 00:00:02.740
The following content is
provided under a Creative

00:00:02.740 --> 00:00:04.160
Commons license.

00:00:04.160 --> 00:00:06.370
Your support will help
MIT OpenCourseWare

00:00:06.370 --> 00:00:10.460
continue to offer high-quality
educational resources for free.

00:00:10.460 --> 00:00:13.000
To make a donation or to
view additional materials

00:00:13.000 --> 00:00:16.960
from hundreds of MIT courses,
visit MIT OpenCourseWare

00:00:16.960 --> 00:00:18.322
at ocw.mit.edu.

00:00:21.970 --> 00:00:26.780
TADGE DRYJA: OK, so today I will
talk about mostly fees, which

00:00:26.780 --> 00:00:29.390
is an interesting and
somewhat contentious

00:00:29.390 --> 00:00:32.740
issue in Bitcoin and
all these other systems.

00:00:32.740 --> 00:00:36.290
So schedule for today,
problem set 3 description,

00:00:36.290 --> 00:00:39.980
we'll talk about fees,
these unknowable acronyms--

00:00:39.980 --> 00:00:43.082
Child Pays for Parent,
Replaced By Fee--

00:00:43.082 --> 00:00:45.290
and then talk a little bit
about long-term incentives

00:00:45.290 --> 00:00:48.020
in Bitcoin, and how
that relates to fees.

00:00:48.020 --> 00:00:51.500
OK, so the problem set
3 is to grab UTXOs.

00:00:51.500 --> 00:00:52.850
Hopefully it's fun.

00:00:52.850 --> 00:00:55.490
You're going to be
making transactions

00:00:55.490 --> 00:00:58.340
on the real Bitcoin
test network.

00:00:58.340 --> 00:01:00.680
So one of the parts of it
that hopefully is not too hard

00:01:00.680 --> 00:01:06.080
is downloading and install
Bitcoin D. So I'll put a link.

00:01:06.080 --> 00:01:09.860
The current, most up-to-date
version is 0.16.0.

00:01:09.860 --> 00:01:11.600
I believe the next
version will just

00:01:11.600 --> 00:01:15.650
be called 17, because a lot
of the developers are like,

00:01:15.650 --> 00:01:18.350
this is annoying, it's
always starting with a zero,

00:01:18.350 --> 00:01:20.487
it's like 0.1, 0.2, 0.3.

00:01:20.487 --> 00:01:22.070
And they're like,
well, at some point,

00:01:22.070 --> 00:01:23.120
should we get to version 1?

00:01:23.120 --> 00:01:24.140
And they're like,
well, everyone's

00:01:24.140 --> 00:01:26.210
going to think version
1 means it's better.

00:01:26.210 --> 00:01:31.420
Let's just call the next
version 17 instead of 0.17.

00:01:31.420 --> 00:01:35.180
So download that, and
then sync up to testnet.

00:01:35.180 --> 00:01:36.710
If you just run
it by default, it

00:01:36.710 --> 00:01:39.140
will sync up to the main
network, which will download

00:01:39.140 --> 00:01:41.500
something like 170 gigabytes.

00:01:41.500 --> 00:01:42.982
You don't want that.

00:01:42.982 --> 00:01:45.440
And the homework assignment
cannot be completed on the main

00:01:45.440 --> 00:01:47.570
network.

00:01:47.570 --> 00:01:48.650
There's no free money--

00:01:48.650 --> 00:01:50.692
I haven't put any free
money on the main network.

00:01:52.882 --> 00:01:54.590
However, on the test
network, it'll work.

00:01:54.590 --> 00:01:58.640
And it's about 11
gigabytes of download.

00:01:58.640 --> 00:02:00.920
So I think most
people, on your laptop,

00:02:00.920 --> 00:02:02.180
probably have 11 gigs free.

00:02:02.180 --> 00:02:04.410
It's doable.

00:02:04.410 --> 00:02:06.900
And it's kind of fun
to see how it works.

00:02:06.900 --> 00:02:08.990
So if you don't have
access to 11 gigs,

00:02:08.990 --> 00:02:11.450
you can probably get an
Athena node to do it.

00:02:11.450 --> 00:02:12.440
It's not too big.

00:02:12.440 --> 00:02:14.900
You can run a tiny little
node with not much RAM, not

00:02:14.900 --> 00:02:16.520
much space, and it'll work.

00:02:16.520 --> 00:02:18.380
You can also sync up
on a Raspberry Pi.

00:02:18.380 --> 00:02:19.910
It just takes a little longer.

00:02:19.910 --> 00:02:22.580
So I don't think it'll
be too hard to do.

00:02:22.580 --> 00:02:24.463
You can probably get around--

00:02:24.463 --> 00:02:25.880
sort of the goal
of the assignment

00:02:25.880 --> 00:02:30.350
is to check out the actual
Bitcoin D and Bitcoin CLI.

00:02:30.350 --> 00:02:32.090
You can use a block
explorer if you want.

00:02:32.090 --> 00:02:33.632
I'm not going to
say that's cheating,

00:02:33.632 --> 00:02:34.760
but it's also not as fun.

00:02:34.760 --> 00:02:37.760
So the block explorers
websites will

00:02:37.760 --> 00:02:39.923
help you find a lot of
things, because they

00:02:39.923 --> 00:02:41.840
have different databases
and different indexes

00:02:41.840 --> 00:02:43.615
so you can sort of
search through things.

00:02:43.615 --> 00:02:45.240
It's more fun if you
write it yourself.

00:02:45.240 --> 00:02:46.860
But if you try this,

00:02:46.860 --> 00:02:48.860
OK, that works too.

00:02:48.860 --> 00:02:51.900
Yeah, so hopefully you get
familiar with the Bitcoin CLI.

00:02:51.900 --> 00:02:56.070
If you want to do your own
scripting with Bitcoin,

00:02:56.070 --> 00:02:57.390
you can use anything you want.

00:02:57.390 --> 00:03:01.080
So Bitcoin CLI is a
command-line utility

00:03:01.080 --> 00:03:05.190
that will let you interact
with the Bitcoin node.

00:03:05.190 --> 00:03:07.250
So for example--
is this readable?

00:03:07.250 --> 00:03:09.750
Kind of, right?

00:03:09.750 --> 00:03:13.260
So if I want to get peer info.

00:03:13.260 --> 00:03:15.210
I want to see-- this
is a computer down

00:03:15.210 --> 00:03:17.520
on the first floor,
running Bitcoin Mainnet,

00:03:17.520 --> 00:03:19.920
I want to see, OK,
who's connected to me?

00:03:19.920 --> 00:03:21.090
And then it'll tell me.

00:03:21.090 --> 00:03:24.840
It returns JSON, and it
tells me all about the people

00:03:24.840 --> 00:03:25.930
I'm connected to.

00:03:25.930 --> 00:03:31.080
If I want to say, get
wallet info, it'll tell me

00:03:31.080 --> 00:03:34.270
I don't have any money--

00:03:34.270 --> 00:03:36.400
things like that.

00:03:36.400 --> 00:03:37.690
And then there's, like, Help.

00:03:37.690 --> 00:03:42.250
It's weird and it's not
super well documented.

00:03:42.250 --> 00:03:44.140
It's fairly well
documented in this stuff.

00:03:44.140 --> 00:03:48.340
There's also tons of
undocumented hidden RPC calls

00:03:48.340 --> 00:03:52.895
that are deprecated, or
new, or programmers put in

00:03:52.895 --> 00:03:54.520
and they don't want
people to use them.

00:03:54.520 --> 00:03:56.690
They only want to use
them for themselves.

00:03:56.690 --> 00:03:59.560
So it's kind of a
mess, but it's fun

00:03:59.560 --> 00:04:02.680
to see exactly how
this software works.

00:04:02.680 --> 00:04:06.090
So hopefully you
can try that out.

00:04:06.090 --> 00:04:08.590
And I will add more UTXOs to
grab in the next few days.

00:04:08.590 --> 00:04:09.840
So that might be fun.

00:04:09.840 --> 00:04:13.445
You could, if you wanted to be a
jerk, just steal all the money,

00:04:13.445 --> 00:04:14.820
and then no one
else could do it.

00:04:14.820 --> 00:04:16.200
But please don't do that.

00:04:16.200 --> 00:04:19.500
I mean, this is not as
adversarial a setting

00:04:19.500 --> 00:04:20.578
as actual Bitcoin.

00:04:20.578 --> 00:04:22.370
If someone does it,
I'll be like, OK, fine,

00:04:22.370 --> 00:04:25.190
and I'll just like
reseed the place.

00:04:25.190 --> 00:04:27.440
So hopefully we don't
have too many trolls

00:04:27.440 --> 00:04:29.190
trying to prevent
everyone from having fun

00:04:29.190 --> 00:04:30.780
with this assignment.

00:04:30.780 --> 00:04:33.690
That said, there is at--
aspect some of them are--

00:04:33.690 --> 00:04:36.210
the one I put in the
assignment last night,

00:04:36.210 --> 00:04:39.210
there's five outputs
that you can grab.

00:04:39.210 --> 00:04:41.820
One of the sort of hints--
there's only five outputs.

00:04:41.820 --> 00:04:45.150
So the first five people
to grab it get the coins.

00:04:45.150 --> 00:04:49.220
So there is a little bit
of timing stuff there.

00:04:49.220 --> 00:04:49.970
Any questions?

00:04:49.970 --> 00:04:50.470
Cool?

00:04:53.990 --> 00:04:56.160
Yeah, so if you have
questions about it,

00:04:56.160 --> 00:04:59.720
office hours tomorrow,
also IRC, stuff like that.

00:04:59.720 --> 00:05:01.830
OK, so today's main topic--

00:05:01.830 --> 00:05:03.970
transaction fees.

00:05:03.970 --> 00:05:08.220
So we described earlier that
the transaction fee is just

00:05:08.220 --> 00:05:11.070
the difference between the sum
of the input amounts and output

00:05:11.070 --> 00:05:13.350
amounts.

00:05:13.350 --> 00:05:15.120
What's interesting
is it's implicit.

00:05:15.120 --> 00:05:17.880
So if you actually
look at a transaction,

00:05:17.880 --> 00:05:20.790
you can't tell
what the fees are.

00:05:20.790 --> 00:05:22.350
You have to look
at its ancestors

00:05:22.350 --> 00:05:24.840
to tell what the fees are.

00:05:24.840 --> 00:05:27.830
So for example, if you want
to go through here and-- oh,

00:05:27.830 --> 00:05:30.750
how am I going to do this?

00:05:30.750 --> 00:05:32.630
Jeez.

00:05:32.630 --> 00:05:35.970
If I want to say, OK, what's
the most current block?

00:05:35.970 --> 00:05:39.350
getblockchaininfo.

00:05:39.350 --> 00:05:42.840
OK, so the most
current block is this.

00:05:42.840 --> 00:05:46.550
And then I can
say, OK, getblock--

00:05:46.550 --> 00:05:47.610
can I just say getblock?

00:05:47.610 --> 00:05:50.120
Yeah, I want to get that block.

00:05:50.120 --> 00:05:53.230
OK, there's all the
transactions in this block.

00:05:53.230 --> 00:05:55.300
I can do getblock verbose
true, and it'll give me

00:05:55.300 --> 00:05:56.530
all the transaction data.

00:05:56.530 --> 00:05:59.260
But instead, I can just pick
one of these transactions

00:05:59.260 --> 00:06:04.430
and say getrawtransaction,
get that thing.

00:06:04.430 --> 00:06:06.790
Oh, here's another weird thing.

00:06:06.790 --> 00:06:08.590
So it'll just give
you hex, which

00:06:08.590 --> 00:06:13.180
is not very useful, unless you
somehow can read hexadecimal.

00:06:13.180 --> 00:06:19.381
And then in the actual thing,
it says, like, examples.

00:06:19.381 --> 00:06:20.260
Wait, true?

00:06:20.260 --> 00:06:21.120
Did they change it?

00:06:21.120 --> 00:06:23.340
You used to have
to do 1 at the end.

00:06:23.340 --> 00:06:24.050
Yeah.

00:06:24.050 --> 00:06:24.910
But true works too?

00:06:27.888 --> 00:06:29.430
It used to not work
if you said true,

00:06:29.430 --> 00:06:31.645
and you had to put the
number 1 instead of true.

00:06:31.645 --> 00:06:33.270
There is a lot of
weird bugs in Bitcoin

00:06:33.270 --> 00:06:35.120
that have been there
for years, and I

00:06:35.120 --> 00:06:36.570
guess they fixed that one.

00:06:36.570 --> 00:06:39.480
The most egregious is
probably the multisig bug,

00:06:39.480 --> 00:06:42.000
where when you're spending
from a multisig output,

00:06:42.000 --> 00:06:44.770
you have to push a zero-byte
onto the stack first,

00:06:44.770 --> 00:06:46.480
or else it doesn't work.

00:06:46.480 --> 00:06:48.160
It was just a bug Satoshi had.

00:06:48.160 --> 00:06:50.320
And now it's consensus critical.

00:06:50.320 --> 00:06:52.990
And people joke about
it, like, oh, we also

00:06:52.990 --> 00:06:54.670
have to put a zero-byte
in whatever new

00:06:54.670 --> 00:06:58.920
RPC we create, because
there's just, like, bugs.

00:06:58.920 --> 00:07:02.950
Anyway, so for example, this
transaction that I just brought

00:07:02.950 --> 00:07:10.010
up, this is how it'll look.

00:07:10.010 --> 00:07:14.198
Here's the TXID,
it's 370 bytes, it's

00:07:14.198 --> 00:07:16.490
got this lock time, which--
ooh, I should mention that.

00:07:16.490 --> 00:07:19.820
I'm guessing this transaction
was created by Bitcoin Core

00:07:19.820 --> 00:07:23.110
Wallet, not a different wallet.

00:07:23.110 --> 00:07:24.520
That's a hint.

00:07:24.520 --> 00:07:27.580
It's got one input--

00:07:27.580 --> 00:07:28.520
no, two inputs.

00:07:28.520 --> 00:07:32.710
OK, so inputs are
specified-- this TXID input,

00:07:32.710 --> 00:07:35.050
this TXID input--

00:07:35.050 --> 00:07:41.980
two inputs and one
output of value, 0004500.

00:07:41.980 --> 00:07:44.370
We can't tell what
the fee is from this.

00:07:44.370 --> 00:07:45.770
No, sorry, two outputs.

00:07:45.770 --> 00:07:46.970
Here are the two outputs.

00:07:46.970 --> 00:07:49.177
So we can tell these
two outputs, however,

00:07:49.177 --> 00:07:50.510
we don't know what the fees are.

00:07:50.510 --> 00:07:51.885
We know the total
output amounts,

00:07:51.885 --> 00:07:54.860
but the input amounts
are not encoded

00:07:54.860 --> 00:07:56.240
in the transaction itself.

00:07:56.240 --> 00:07:57.650
In order to figure
that out, we'd

00:07:57.650 --> 00:08:03.380
have to go to this transaction
and see what vout 0's output

00:08:03.380 --> 00:08:06.770
amount is, which we can do.

00:08:06.770 --> 00:08:12.710
And it's 0052-- you know, so
we can add it up that way,

00:08:12.710 --> 00:08:18.650
but it's not written directly,
which is a little weird.

00:08:18.650 --> 00:08:21.020
And the idea of the
fee is, whoever mines

00:08:21.020 --> 00:08:25.460
that block that includes that
transaction gets the fee.

00:08:25.460 --> 00:08:29.840
So the sum of all the inputs
and outputs within a block

00:08:29.840 --> 00:08:34.610
do add up, modulo the new
coins that are created.

00:08:34.610 --> 00:08:37.688
But long-term, when there's
no coins being created,

00:08:37.688 --> 00:08:39.480
when they've all been
created, you can say,

00:08:39.480 --> 00:08:41.299
OK, we can look
at a block, add up

00:08:41.299 --> 00:08:44.660
all the inputs spent in all
the transactions in the block,

00:08:44.660 --> 00:08:47.030
add up all the outputs created
in all the transactions

00:08:47.030 --> 00:08:50.090
in the block, and
those should equal.

00:08:50.090 --> 00:08:51.110
Otherwise, it's invalid.

00:08:51.110 --> 00:08:52.640
Well, they don't have to equal.

00:08:52.640 --> 00:08:54.890
You're always allowed
to destroy coins.

00:08:54.890 --> 00:08:57.200
So if the miner
says, hey, there's

00:08:57.200 --> 00:08:58.970
all these fees that
can be paid to me,

00:08:58.970 --> 00:09:02.030
and I just don't grab
them, you can do that.

00:09:02.030 --> 00:09:07.160
So it's a less-than-or-equals
operator that-- it's the check.

00:09:07.160 --> 00:09:10.910
And people have destroyed
coins, usually inadvertently.

00:09:10.910 --> 00:09:13.190
There was one in
January where there

00:09:13.190 --> 00:09:16.820
was a block that just had a zero
output for the miner reward,

00:09:16.820 --> 00:09:22.060
so all whatever, 13, 14
coins were just destroyed.

00:09:22.060 --> 00:09:24.220
Yeah, it seemed like a bug.

00:09:24.220 --> 00:09:27.320
So that's how fees work.

00:09:27.320 --> 00:09:29.320
What's interesting is,
you don't know who you're

00:09:29.320 --> 00:09:32.170
paying when you create the fee.

00:09:32.170 --> 00:09:34.060
You sign sort of, OK,
here's my transaction,

00:09:34.060 --> 00:09:38.110
I sign it off, whoever confirms
this transaction gets $5

00:09:38.110 --> 00:09:39.085
or whatever.

00:09:39.085 --> 00:09:40.210
And you throw it out there.

00:09:40.210 --> 00:09:42.790
So it's kind of interesting.

00:09:42.790 --> 00:09:43.800
There could be legal--

00:09:43.800 --> 00:09:45.967
I've heard there's legal
questions, like, well, what

00:09:45.967 --> 00:09:48.520
if one of the miners
is in Iran, now

00:09:48.520 --> 00:09:51.320
you're paying someone in Iran,
are you in trouble for that?

00:09:51.320 --> 00:09:52.570
You don't know.

00:09:52.570 --> 00:09:54.642
You can't tell who going
to mine it beforehand.

00:09:57.650 --> 00:10:00.290
And generally, we talk
about fee rates, or sort

00:10:00.290 --> 00:10:04.030
of a specific fee-per-byte.

00:10:04.030 --> 00:10:07.690
And it's expressed in Satoshis
per byte, and one Satoshi

00:10:07.690 --> 00:10:10.930
being the minimum
possible bitcoin

00:10:10.930 --> 00:10:17.410
amount, which is 1, 2, 3, 4,
1, 2, 3 zeros, so seven years.

00:10:17.410 --> 00:10:21.487
There's eight digits in bitcoin.

00:10:21.487 --> 00:10:22.570
And you usually keep that.

00:10:22.570 --> 00:10:26.220
So you pad it out.

00:10:26.220 --> 00:10:31.170
So even in something
where it's 0.0134,

00:10:31.170 --> 00:10:33.480
they put the extra four zeros.

00:10:33.480 --> 00:10:38.280
In the actual code, this is
just a 64-bit signed integer,

00:10:38.280 --> 00:10:40.740
and there is no decimal point.

00:10:40.740 --> 00:10:44.447
So it's sort of a UI thing
to put a decimal point in so

00:10:44.447 --> 00:10:46.530
that people can think of,
oh, that's two bitcoins,

00:10:46.530 --> 00:10:47.940
or that's half a bitcoin.

00:10:47.940 --> 00:10:50.910
But really, the code only
deals with the Satoshis,

00:10:50.910 --> 00:10:54.520
and the decimal point
is purely UI layer,

00:10:54.520 --> 00:10:56.095
which can be
confusing sometimes,

00:10:56.095 --> 00:10:57.720
when you're dealing
with JSON, and when

00:10:57.720 --> 00:10:59.850
you're dealing with
different programs,

00:10:59.850 --> 00:11:01.140
tossing numbers around.

00:11:01.140 --> 00:11:03.810
You can get a factor of
100 million off, sometimes.

00:11:03.810 --> 00:11:08.400
It's a big enough factor that,
usually, it's pretty obvious.

00:11:08.400 --> 00:11:11.420
So from a miner's
point of view, they

00:11:11.420 --> 00:11:17.170
want to prioritize, based on
the TX size and the fee rate

00:11:17.170 --> 00:11:18.730
because space is limited.

00:11:18.730 --> 00:11:20.920
So one of the other
rules that's probably

00:11:20.920 --> 00:11:23.440
one of the most controversial
and argued-about rules

00:11:23.440 --> 00:11:27.070
in Bitcoin was a 1-megabyte
block size limit.

00:11:27.070 --> 00:11:29.320
So the idea is, OK, you can
put all these transactions

00:11:29.320 --> 00:11:31.558
in the block, but the total
block, when serialized,

00:11:31.558 --> 00:11:33.100
including the headers
and everything,

00:11:33.100 --> 00:11:36.270
needs to be 1 million
bytes or less,

00:11:36.270 --> 00:11:39.560
which is now not quite
true because there's

00:11:39.560 --> 00:11:40.970
ways around that.

00:11:40.970 --> 00:11:45.220
But there's still a hard
limit of 4 megabytes today.

00:11:45.220 --> 00:11:47.950
What's also interesting is it's
totally unrelated to the amount

00:11:47.950 --> 00:11:50.290
of coins being transferred.

00:11:50.290 --> 00:11:52.270
So in that sense,
the fee is flat.

00:11:52.270 --> 00:11:55.360
Whether you're sending 100
Bitcoins, or one Bitcoin,

00:11:55.360 --> 00:11:57.830
or a millionth of a Bitcoin.

00:11:57.830 --> 00:12:01.210
The miner doesn't really care.

00:12:01.210 --> 00:12:02.890
It's just based on space.

00:12:02.890 --> 00:12:06.580
You're paying for your
data usage of the network,

00:12:06.580 --> 00:12:09.970
and your actual sort of
monetary value transferring

00:12:09.970 --> 00:12:11.410
is unrelated to that.

00:12:11.410 --> 00:12:14.860
To some extent, later on,
you might think, well,

00:12:14.860 --> 00:12:18.250
miners might try to charge
people sending more money

00:12:18.250 --> 00:12:22.590
more because they're
more able to pay.

00:12:22.590 --> 00:12:25.230
But so far, we haven't
seen anything like that.

00:12:25.230 --> 00:12:27.000
It's mostly just the
miners looking at,

00:12:27.000 --> 00:12:30.240
I've got a megabyte of size
to parcel out to people,

00:12:30.240 --> 00:12:33.820
I'm going to try to pack that in
is at as high a rate as I can.

00:12:33.820 --> 00:12:36.480
And whether someone's paying
a little bit or a lot--

00:12:36.480 --> 00:12:38.550
whether someone is moving
a little bit or a lot,

00:12:38.550 --> 00:12:40.390
the miners don't care.

00:12:40.390 --> 00:12:41.920
Any questions
about these things?

00:12:41.920 --> 00:12:42.420
Yeah.

00:12:42.420 --> 00:12:44.628
AUDIENCE: I have a question
about actually the miners

00:12:44.628 --> 00:12:45.610
getting the fees.

00:12:45.610 --> 00:12:46.745
So how does that--

00:12:46.745 --> 00:12:49.400
because that's not part of
the Coinbase transaction.

00:12:49.400 --> 00:12:50.980
TADGE DRYJA: It is, it is.

00:12:50.980 --> 00:12:52.520
So if we look--

00:12:52.520 --> 00:12:54.390
how am I going to do this?

00:12:54.390 --> 00:12:56.640
AUDIENCE: You could look
into the Coinbase transaction

00:12:56.640 --> 00:13:00.110
in the block and find out
what the fees would be.

00:13:00.110 --> 00:13:03.900
TADGE DRYJA: Well, if you
assume that the block is valid.

00:13:03.900 --> 00:13:06.028
So OK, the first
transaction is always

00:13:06.028 --> 00:13:07.070
the Coinbase transaction.

00:13:07.070 --> 00:13:08.300
That's little.

00:13:08.300 --> 00:13:10.730
So I'm going to do
getrawtransaction,

00:13:10.730 --> 00:13:11.990
get this one.

00:13:14.510 --> 00:13:16.940
And yeah, it says, Coinbase.

00:13:16.940 --> 00:13:20.990
So Coinbase's arbitrary data,
you've got a sequence number,

00:13:20.990 --> 00:13:24.160
there is no witness here--

00:13:24.160 --> 00:13:28.352
or is-- OK, anyway.

00:13:28.352 --> 00:13:29.310
Yeah, there is witness.

00:13:29.310 --> 00:13:31.917
OK, so this block is--

00:13:31.917 --> 00:13:33.750
well, two blocks have
come out since I first

00:13:33.750 --> 00:13:36.520
looked at it, because there's
now two confirmations.

00:13:39.740 --> 00:13:41.460
This is SegWit-related,
which I think

00:13:41.460 --> 00:13:43.310
I'm going to talk about Monday.

00:13:43.310 --> 00:13:45.500
So that's sort of this
weird opportune thing.

00:13:45.500 --> 00:13:48.590
This is the actual
Coinbase payout

00:13:48.590 --> 00:13:54.260
that the miner is
getting, and it's 12.79.

00:13:54.260 --> 00:14:01.430
So he got almost 0.4 extra
coins in fees, which is what,

00:14:01.430 --> 00:14:03.890
like $4,000, pretty good.

00:14:03.890 --> 00:14:07.720
It was super high
a few months ago.

00:14:07.720 --> 00:14:10.880
So it all gets aggregated.

00:14:10.880 --> 00:14:12.530
12.5 comes out of nowhere.

00:14:12.530 --> 00:14:14.900
12.5 is the new coins
being generated.

00:14:14.900 --> 00:14:20.122
And then the 0.398 is the sum
of all the fees in that block.

00:14:20.122 --> 00:14:23.060
AUDIENCE: I guess you
don't know [INAUDIBLE]

00:14:23.060 --> 00:14:25.560
TADGE DRYJA: Well, you have to
look at all the transactions.

00:14:25.560 --> 00:14:27.270
So if you look at
a transaction, it

00:14:27.270 --> 00:14:29.063
doesn't say in the
transaction itself.

00:14:29.063 --> 00:14:30.480
You have to look
at a transaction,

00:14:30.480 --> 00:14:34.200
look up its inputs, see
the sum of all the inputs,

00:14:34.200 --> 00:14:35.880
and then subtract
and say, OK, I can

00:14:35.880 --> 00:14:37.548
calculate the fee
for this transaction,

00:14:37.548 --> 00:14:39.840
calculate the fee for all
these different transactions,

00:14:39.840 --> 00:14:42.250
add it all up, it should equal--

00:14:42.250 --> 00:14:47.980
and it does exactly
equal 0.398 da da da da.

00:14:47.980 --> 00:14:51.690
So for the computer,
it's pretty quick.

00:14:51.690 --> 00:14:53.610
But yeah, it is a little
bit weird accounting

00:14:53.610 --> 00:14:56.730
to try to add it
all up yourself.

00:14:56.730 --> 00:15:00.960
Any other questions about
fee stuff, about this?

00:15:00.960 --> 00:15:01.473
Yes.

00:15:01.473 --> 00:15:03.390
AUDIENCE: Do miners
choose what blocks to mine

00:15:03.390 --> 00:15:05.016
based on their [INAUDIBLE]?

00:15:07.770 --> 00:15:10.920
TADGE DRYJA: Yes, but I'm
not sure I'd put it that way.

00:15:10.920 --> 00:15:13.440
The miners construct
the block to mine.

00:15:13.440 --> 00:15:16.240
So in the case of--

00:15:16.240 --> 00:15:21.340
here, getblock head dash 30, I
don't want to show all of the--

00:15:21.340 --> 00:15:25.820
but this is, OK, the
miner mined this block.

00:15:25.820 --> 00:15:30.550
Here's the size, weight,
height, version, vertical route.

00:15:30.550 --> 00:15:32.530
All these transactions
that get included

00:15:32.530 --> 00:15:34.960
are produced by the miner.

00:15:34.960 --> 00:15:38.620
So the miner sort of aggregates
the transactions themselves,

00:15:38.620 --> 00:15:40.120
and then decides to mine.

00:15:40.120 --> 00:15:43.980
So I think I talk about
that in the next--

00:15:43.980 --> 00:15:45.320
wait, do I say that?

00:15:45.320 --> 00:15:46.640
Yeah, OK.

00:15:46.640 --> 00:15:48.390
I'll talk about that
in the next slide.

00:15:48.390 --> 00:15:52.590
So basically the fee rate is
set by the transaction signer.

00:15:52.590 --> 00:15:54.460
When you're creating
a transaction--

00:15:54.460 --> 00:15:59.700
OK, I want to sign one Bitcoin,
I will spend 500 Satoshis,

00:15:59.700 --> 00:16:02.040
my transaction is
about 250 bytes, OK,

00:16:02.040 --> 00:16:04.610
that's a two-Satoshis-per-byte
fee rate.

00:16:07.470 --> 00:16:09.323
You choose your fee rate, sign--

00:16:09.323 --> 00:16:11.490
the way you increment and
decrement your fee rate is

00:16:11.490 --> 00:16:13.860
to say, OK, I've got
some change output,

00:16:13.860 --> 00:16:16.050
I'm going to increase or
decrease the change output

00:16:16.050 --> 00:16:16.740
amount.

00:16:16.740 --> 00:16:19.020
If someone's saying,
hey, pay me one coin,

00:16:19.020 --> 00:16:21.420
I can't really
change their amount

00:16:21.420 --> 00:16:23.870
and say, like, oh, sorry
man, there was a high fee,

00:16:23.870 --> 00:16:26.300
you didn't get a bitcoin.

00:16:26.300 --> 00:16:29.850
And that's sort of a cultural--
that's not a software thing.

00:16:29.850 --> 00:16:33.060
If someone says, pay me a
coin, you need to pay the coin.

00:16:33.060 --> 00:16:36.240
It's generally the sender
who's covering the fee.

00:16:36.240 --> 00:16:39.270
Which is different than
in credit cards, right?

00:16:39.270 --> 00:16:42.630
In credit cards, it says
$10, I swipe my card,

00:16:42.630 --> 00:16:45.150
I get charged $10,
and the merchant

00:16:45.150 --> 00:16:47.407
is the one absorbing the fee.

00:16:47.407 --> 00:16:48.990
And I don't even
know what the fee is.

00:16:48.990 --> 00:16:51.750
There's actually
contractual law that I'm not

00:16:51.750 --> 00:16:54.360
allowed to hear what the fee
is, the merchant can't tell me,

00:16:54.360 --> 00:16:55.710
things like that.

00:16:55.710 --> 00:16:58.320
But in general, in Bitcoin,
this fee is set by the sender.

00:17:01.043 --> 00:17:03.210
The transactions, however,
are chosen by the miners.

00:17:03.210 --> 00:17:06.349
So the idea is, you create
your transaction, set your fee,

00:17:06.349 --> 00:17:09.319
throw it out there,
everyone sort of broadcasts

00:17:09.319 --> 00:17:10.849
it to everyone else.

00:17:10.849 --> 00:17:13.940
And the miner then
looks at all these fees,

00:17:13.940 --> 00:17:17.480
looks at all these transactions,
and chooses the best ones.

00:17:17.480 --> 00:17:18.950
It's essentially
an auction process

00:17:18.950 --> 00:17:21.950
where you're bidding for us for
space in a future block that

00:17:21.950 --> 00:17:24.460
has not yet been created.

00:17:24.460 --> 00:17:28.890
So the simplest miner-side
algorithm is, take the mempool,

00:17:28.890 --> 00:17:32.190
sort the mempool transactions
by their fee rate,

00:17:32.190 --> 00:17:36.330
choose the top megabyte,
put them all in order,

00:17:36.330 --> 00:17:39.330
compute a merkle route from
all those transaction IDs,

00:17:39.330 --> 00:17:40.920
and then mine it.

00:17:40.920 --> 00:17:45.160
So the-- yeah, I explained
the merkle route stuff, right?

00:17:45.160 --> 00:17:49.500
So you're going to pick
a couple thousand--

00:17:49.500 --> 00:17:53.440
5,000, maybe-- transactions,
sort them by fee rate,

00:17:53.440 --> 00:17:56.910
put them all in a row,
hash it a bunch of times,

00:17:56.910 --> 00:17:59.642
and then just that 80-byte
header you keep mining.

00:17:59.642 --> 00:18:00.850
However, this keeps changing.

00:18:00.850 --> 00:18:03.060
This mempool changes
every second.

00:18:03.060 --> 00:18:06.503
There's new transactions coming
up multiple times a second.

00:18:06.503 --> 00:18:08.670
And so you're going to
re-compute that every second,

00:18:08.670 --> 00:18:11.760
probably, and say, oh, this
new transaction came out,

00:18:11.760 --> 00:18:14.460
oh, the fee's really
low, ignore it,

00:18:14.460 --> 00:18:16.980
that doesn't meet my threshold.

00:18:16.980 --> 00:18:19.020
Versus, new transaction
comes out, oh, it's

00:18:19.020 --> 00:18:22.980
got a really high fee rate,
OK, put it in near the top,

00:18:22.980 --> 00:18:26.445
and push out one or two
transactions at the bottom.

00:18:26.445 --> 00:18:29.070
And now I'm mining a block that
will have slightly higher fees.

00:18:29.070 --> 00:18:31.470
So this is sort of a
real-time process, where

00:18:31.470 --> 00:18:33.450
this is constantly changing.

00:18:33.450 --> 00:18:35.640
The mining is even
faster, so you're

00:18:35.640 --> 00:18:38.610
going to mine trillions
and trillions of attempts

00:18:38.610 --> 00:18:41.018
for each specific merkle route.

00:18:41.018 --> 00:18:43.560
But the merkle routes are also
going to change multiple times

00:18:43.560 --> 00:18:44.900
a second.

00:18:44.900 --> 00:18:48.480
The nonce is going to change
a gazillion times a second.

00:18:48.480 --> 00:18:48.980
Yes.

00:18:48.980 --> 00:18:50.688
AUDIENCE: How do you
know that you're not

00:18:50.688 --> 00:18:53.295
mining a stale transaction?

00:18:53.295 --> 00:18:55.170
TADGE DRYJA: So you know
it's in the mempool,

00:18:55.170 --> 00:18:56.730
you know it hasn't been--

00:18:56.730 --> 00:18:58.260
well, you don't
know, you're pretty

00:18:58.260 --> 00:19:02.760
sure that it has not been
confirmed in a block already.

00:19:02.760 --> 00:19:04.807
But it may be the case
that someone just came out

00:19:04.807 --> 00:19:07.140
with a block a few seconds
ago, and you haven't seen it,

00:19:07.140 --> 00:19:11.620
and then you are mining
a stale transaction.

00:19:11.620 --> 00:19:13.670
The thing is, whether
the transaction is stale

00:19:13.670 --> 00:19:19.450
or not, even if you
mine a block and it's

00:19:19.450 --> 00:19:21.670
got a completely different
set of transactions

00:19:21.670 --> 00:19:25.930
than the block you were
unaware of, you still lose out.

00:19:25.930 --> 00:19:29.020
Because you're pointing--
so OK, this comes out,

00:19:29.020 --> 00:19:32.200
but you're not aware of
it yet, and you mine this.

00:19:32.200 --> 00:19:36.780
Even if they have a completely
disjoint set of transactions,

00:19:36.780 --> 00:19:38.780
it doesn't matter because
they're still pointing

00:19:38.780 --> 00:19:40.490
to the same parent block.

00:19:40.490 --> 00:19:44.060
So you still, now, have two
blocks of the same height.

00:19:44.060 --> 00:19:45.530
You might win.

00:19:45.530 --> 00:19:49.580
If this happens, hey, maybe
this one gets built upon.

00:19:49.580 --> 00:19:54.170
Generally, miners pick the first
seen block to build off of.

00:19:54.170 --> 00:19:57.800
But you could change that.

00:19:57.800 --> 00:19:59.882
And you can't really verify
that that's the case.

00:19:59.882 --> 00:20:01.340
So yeah, it is
possible that you're

00:20:01.340 --> 00:20:02.960
mining transactions
that have already

00:20:02.960 --> 00:20:05.010
been included in the block
that you're not aware.

00:20:05.010 --> 00:20:05.510
Yes.

00:20:05.510 --> 00:20:07.843
AUDIENCE: Because blocks are
changing all the time based

00:20:07.843 --> 00:20:10.190
on the transactions
you want to put in it,

00:20:10.190 --> 00:20:12.856
are you kind of mining different
blocks at the same time?

00:20:12.856 --> 00:20:15.800
So the first one, you
try-- have started mining,

00:20:15.800 --> 00:20:17.302
do you keep mining
that one or no?

00:20:17.302 --> 00:20:18.260
TADGE DRYJA: You could.

00:20:18.260 --> 00:20:22.580
So in practice, probably yes,
but on a very small timescale.

00:20:22.580 --> 00:20:27.250
So what you'll have is we'll get
block template, you'll have--

00:20:27.250 --> 00:20:28.840
it's like network latency.

00:20:28.840 --> 00:20:31.960
So you'll have, let's say, a
bunch of different warehouses

00:20:31.960 --> 00:20:34.660
that all have thousands and
thousands of these mining

00:20:34.660 --> 00:20:35.560
chips.

00:20:35.560 --> 00:20:37.390
And they will connect
in, and they'll

00:20:37.390 --> 00:20:42.070
pull every second or so, and
get the current transaction

00:20:42.070 --> 00:20:43.270
list to mine.

00:20:43.270 --> 00:20:44.950
And that'll get
updated every second.

00:20:44.950 --> 00:20:49.870
And so there may be sort of lags
between different warehouses,

00:20:49.870 --> 00:20:52.420
between different machines,
that are mining slightly

00:20:52.420 --> 00:20:54.500
different sets of transactions.

00:20:54.500 --> 00:20:56.500
But generally, they're
going to be synchronized.

00:20:56.500 --> 00:20:58.090
Over the same time
scale of a few seconds,

00:20:58.090 --> 00:20:59.632
they're all going
to be synchronized.

00:21:02.768 --> 00:21:04.560
They're going to be
updated pretty quickly.

00:21:04.560 --> 00:21:06.603
Because every time a new
transaction comes in,

00:21:06.603 --> 00:21:08.520
that's potentially more
fees that you can get.

00:21:08.520 --> 00:21:11.280
So you want to push
that out and update it.

00:21:11.280 --> 00:21:14.100
Let's say a transaction comes
in that's got a nice $5.00 fee,

00:21:14.100 --> 00:21:17.010
and you can push out some
$4.00 fee transactions,

00:21:17.010 --> 00:21:18.240
that's an extra buck.

00:21:18.240 --> 00:21:21.060
And if you don't get it in
time, and mine a block anyway,

00:21:21.060 --> 00:21:25.230
hey, you still mined a buck,
but that $5 fee transaction now

00:21:25.230 --> 00:21:28.140
goes to the next person
mining the block.

00:21:28.140 --> 00:21:32.610
So you want to minimize your
latency so that you get things

00:21:32.610 --> 00:21:33.900
as quickly as possible.

00:21:33.900 --> 00:21:37.320
But there will be some skew.

00:21:37.320 --> 00:21:37.960
Yes.

00:21:37.960 --> 00:21:39.360
AUDIENCE: How does
mining stale transactions

00:21:39.360 --> 00:21:41.340
affect the block order and
block transaction fees?

00:21:41.340 --> 00:21:42.570
TADGE DRYJA: Sorry,
mining what transactions?

00:21:42.570 --> 00:21:44.040
AUDIENCE: Stale transactions.

00:21:44.040 --> 00:21:45.660
TADGE DRYJA: If you have--

00:21:45.660 --> 00:21:47.020
wait, wait.

00:21:47.020 --> 00:21:47.640
OK, wait.

00:21:47.640 --> 00:21:49.365
Stale transactions?

00:21:49.365 --> 00:21:51.240
A transaction that's
already been in a block?

00:21:51.240 --> 00:21:51.660
AUDIENCE: Yeah.

00:21:51.660 --> 00:21:53.702
TADGE DRYJA: It just
invalidates the whole thing.

00:21:53.702 --> 00:21:55.530
If you have if you
have a transaction here

00:21:55.530 --> 00:21:58.380
that was already confirmed
here, this block is invalid,

00:21:58.380 --> 00:21:59.550
and no one will--

00:21:59.550 --> 00:22:01.400
they'll just drop it.

00:22:01.400 --> 00:22:06.900
So stale transaction
isn't really a term.

00:22:06.900 --> 00:22:08.910
It's a stale block.

00:22:08.910 --> 00:22:11.250
This is a stale block because,
well, someone made it,

00:22:11.250 --> 00:22:15.330
but it got orphaned out,
and no one's using it.

00:22:15.330 --> 00:22:18.140
AUDIENCE: So the answer is,
there's no reward for that,

00:22:18.140 --> 00:22:19.428
right?

00:22:19.428 --> 00:22:20.220
TADGE DRYJA: Worse.

00:22:20.220 --> 00:22:21.270
You lose all your--

00:22:21.270 --> 00:22:23.350
you lose everything.

00:22:23.350 --> 00:22:26.370
So if there's
transaction A in here,

00:22:26.370 --> 00:22:29.520
and you try to include
transaction A in here,

00:22:29.520 --> 00:22:31.200
the block itself
is invalid, even

00:22:31.200 --> 00:22:32.760
if it has valid proof of work.

00:22:32.760 --> 00:22:36.600
So you lose everything.

00:22:36.600 --> 00:22:39.180
The thing is, in practice,
it's not a problem.

00:22:39.180 --> 00:22:43.110
Because you're
pointing to this block,

00:22:43.110 --> 00:22:45.187
so you must have
already seen it.

00:22:45.187 --> 00:22:47.520
So it's really easy to just
say, well, don't include any

00:22:47.520 --> 00:22:51.040
of the transactions in here.

00:22:51.040 --> 00:22:53.180
OK, wait, sometimes it's
a little complicated.

00:22:53.180 --> 00:22:56.580
Sometimes you see
this block, and then

00:22:56.580 --> 00:22:59.220
you immediately want to start
mining the block on top of it.

00:22:59.220 --> 00:23:03.270
But it's a fraction of a
second, and you haven't actually

00:23:03.270 --> 00:23:04.488
validated it.

00:23:04.488 --> 00:23:06.030
And you don't even
know what's in it.

00:23:06.030 --> 00:23:09.030
Maybe you only have
the 80-byte header.

00:23:09.030 --> 00:23:12.870
So one optimization which
is sort of bad in a way

00:23:12.870 --> 00:23:16.290
but optimal for the
miners is build a block

00:23:16.290 --> 00:23:17.893
that's empty on top of it.

00:23:17.893 --> 00:23:20.310
You haven't even seen what
transactions are in this block.

00:23:20.310 --> 00:23:21.870
You don't even
know if it's valid.

00:23:21.870 --> 00:23:24.507
But it's probably valid,
because most blocks are.

00:23:24.507 --> 00:23:27.090
And so what you do is you build
on top of it, you point to it,

00:23:27.090 --> 00:23:29.298
but since you don't know
what transactions are in it,

00:23:29.298 --> 00:23:31.830
the safest thing is just to
include no transactions in your

00:23:31.830 --> 00:23:33.900
so there's no overlap.

00:23:33.900 --> 00:23:36.840
And you only do this for
a fraction of a second

00:23:36.840 --> 00:23:40.050
until you've figured out
the Transaction List here

00:23:40.050 --> 00:23:41.550
and subtracted all the--

00:23:41.550 --> 00:23:45.150
removed all those from your set.

00:23:45.150 --> 00:23:49.710
But it saves you maybe 1/10 of
a second, 1/20, whatever it is.

00:23:49.710 --> 00:23:53.010
Which, over time,
statistically, you

00:23:53.010 --> 00:23:55.530
could be mining in
that 1/10 of a second.

00:23:55.530 --> 00:23:57.030
You don't you want
your chips to not

00:23:57.030 --> 00:24:00.480
be doing anything productive
for those fractions of a second.

00:24:00.480 --> 00:24:02.470
So that does happen.

00:24:02.470 --> 00:24:06.270
That is not software that's
in the normal Bitcoin D,

00:24:06.270 --> 00:24:09.210
but miners have written their
own software to do that.

00:24:09.210 --> 00:24:12.120
And so you will occasionally
see completely empty blocks

00:24:12.120 --> 00:24:14.010
with just a Coinbase
transaction.

00:24:14.010 --> 00:24:17.850
And they're almost always very
soon after the previous block,

00:24:17.850 --> 00:24:20.160
where you see one that
comes out at 10:30

00:24:20.160 --> 00:24:24.690
and 27 seconds, 10:30 and
29 seconds, and it's empty.

00:24:24.690 --> 00:24:28.980
So that does happen,
and that can work.

00:24:28.980 --> 00:24:31.710
Although what was
it, two years ago

00:24:31.710 --> 00:24:35.210
that happened,
where a miner mined

00:24:35.210 --> 00:24:37.230
a blocked that was invalid.

00:24:37.230 --> 00:24:39.810
Another miner
mined a block here,

00:24:39.810 --> 00:24:42.032
very quickly, that was empty.

00:24:42.032 --> 00:24:44.240
And then a bunch of miners
started building off of it

00:24:44.240 --> 00:24:46.140
because they're like,
well, this one looks valid,

00:24:46.140 --> 00:24:47.390
there's no transactions in it.

00:24:47.390 --> 00:24:49.610
And they mined like six
or seven blocks in a row,

00:24:49.610 --> 00:24:53.300
and the whole thing
was just invalid.

00:24:53.300 --> 00:24:57.290
Because they figured, the stuff
I'm building off of must be OK.

00:24:57.290 --> 00:24:59.630
So they lost some money there.

00:24:59.630 --> 00:25:02.770
This makes sense, right?

00:25:02.770 --> 00:25:05.610
Sort the mempool by fee rate,
choose the top megabyte,

00:25:05.610 --> 00:25:07.140
compute a merkle route, mine.

00:25:07.140 --> 00:25:10.070
Why is it not this simple?

00:25:10.070 --> 00:25:12.990
And I mean on an
algorithmic way.

00:25:12.990 --> 00:25:15.970
If you're just like, yeah,
sort, choose fee rate,

00:25:15.970 --> 00:25:18.480
sort, quick-sort
or whatever, that's

00:25:18.480 --> 00:25:20.910
super quick, and then mine.

00:25:20.910 --> 00:25:24.600
Why is it actually,
complexity-wise, not--

00:25:24.600 --> 00:25:26.940
what is it, n log
n for quick-sort?

00:25:26.940 --> 00:25:29.662
It's definitely not n
log n for the optimal.

00:25:29.662 --> 00:25:32.120
Although, wait, quick-sort is
worst-case scenario n-squared

00:25:32.120 --> 00:25:33.470
[INAUDIBLE] right?

00:25:33.470 --> 00:25:35.150
No, it's way worse
than n-squared.

00:25:35.150 --> 00:25:38.280
Anyway, any guesses onto why
the algorithmic complexity

00:25:38.280 --> 00:25:41.123
is actually quite a bit worse?

00:25:41.123 --> 00:25:44.350
AUDIENCE: Is it because the
example keeps on changing?

00:25:44.350 --> 00:25:46.100
TADGE DRYJA: No, I'm
saying, even at any--

00:25:46.100 --> 00:25:48.190
yeah, that changes it over time.

00:25:48.190 --> 00:25:51.020
But at any one state, let's
say, here's a mempool,

00:25:51.020 --> 00:25:57.135
find the optimal transaction
set to put into your block.

00:25:57.135 --> 00:25:58.970
AUDIENCE: Because Bitcoin
is slow to search,

00:25:58.970 --> 00:26:03.100
so you have to go into each
transaction and find the fee?

00:26:03.100 --> 00:26:06.650
TADGE DRYJA: Yeah, but
that's still n log n, right?

00:26:06.650 --> 00:26:08.870
Yeah, just because
the look-up is slower,

00:26:08.870 --> 00:26:10.886
that doesn't change the O.

00:26:10.886 --> 00:26:12.886
AUDIENCE: The problem is
[INAUDIBLE] because you

00:26:12.886 --> 00:26:14.690
have to find [INAUDIBLE].

00:26:14.690 --> 00:26:17.100
TADGE DRYJA: Yeah, so
there's dependencies.

00:26:17.100 --> 00:26:20.130
So the thing is, there may be
a transaction-- you can't just

00:26:20.130 --> 00:26:22.642
take all these transactions
independently and sort them.

00:26:22.642 --> 00:26:24.600
There may be a transaction
with a very high fee

00:26:24.600 --> 00:26:28.020
rate which depends on a
transaction with a very low fee

00:26:28.020 --> 00:26:29.280
rate.

00:26:29.280 --> 00:26:31.620
And so you know it's spending
an output that hasn't yet

00:26:31.620 --> 00:26:32.680
been created.

00:26:32.680 --> 00:26:34.560
So now it becomes--

00:26:34.560 --> 00:26:35.640
it's NP-hard.

00:26:35.640 --> 00:26:38.730
In practice, the
heuristics are fine.

00:26:38.730 --> 00:26:41.850
But it is pretty
ugly in that you're

00:26:41.850 --> 00:26:44.853
like, well, this transaction
has a very low fee,

00:26:44.853 --> 00:26:46.020
I'm not going to include it.

00:26:46.020 --> 00:26:48.720
This transaction that depends
on it has a high fee rate.

00:26:48.720 --> 00:26:52.140
Now I have to take the sort
of mean of the two fee rates,

00:26:52.140 --> 00:26:54.540
and keep computing those things.

00:26:54.540 --> 00:26:55.980
So it can get quite complex.

00:26:55.980 --> 00:26:57.482
In practice, it's usually OK.

00:26:57.482 --> 00:26:59.190
You have some heuristics
in the code that

00:26:59.190 --> 00:27:00.790
sort of don't deal with that.

00:27:00.790 --> 00:27:04.050
Also, I think you have max--

00:27:04.050 --> 00:27:06.870
there's no hard rule, but the
algorithms that mine usually

00:27:06.870 --> 00:27:11.790
have a max depth of like
three or four transactions,

00:27:11.790 --> 00:27:14.130
where they say, look, if
there's a chain of like four

00:27:14.130 --> 00:27:16.500
dependent transactions,
I'm not going

00:27:16.500 --> 00:27:18.690
to keep going down that path.

00:27:18.690 --> 00:27:21.270
Because you could potentially
have enormous chains,

00:27:21.270 --> 00:27:24.610
where you have 100 transactions,
each depending on another.

00:27:24.610 --> 00:27:27.090
And then the one at the very
end has a very high fee rate,

00:27:27.090 --> 00:27:29.090
and you're going to have
to go through all this.

00:27:29.090 --> 00:27:31.260
So they limit their search
to like four or something

00:27:31.260 --> 00:27:32.630
like that.

00:27:32.630 --> 00:27:33.550
Oh, sorry.

00:27:33.550 --> 00:27:37.140
Yeah, so the TX dependencies
make it kind of hard.

00:27:37.140 --> 00:27:39.970
Cheap transaction which allows
an expensive transaction

00:27:39.970 --> 00:27:44.380
to be confirmed, we call
this Child Pays for Parent,

00:27:44.380 --> 00:27:45.890
in that you've got this--

00:27:45.890 --> 00:27:47.950
in a graph, you've
a child transaction,

00:27:47.950 --> 00:27:50.200
and it's essentially paying
for the parent transaction

00:27:50.200 --> 00:27:53.020
by having a higher fee.

00:27:53.020 --> 00:27:56.475
There is no Parent
Pays for Child,

00:27:56.475 --> 00:27:58.600
in that if you've got a
transaction with a high fee

00:27:58.600 --> 00:28:01.390
rate, and then a descendant
transaction with a low fee

00:28:01.390 --> 00:28:03.460
rate, you just take the
parent and you ignore

00:28:03.460 --> 00:28:06.670
the child and someone
else in a later block

00:28:06.670 --> 00:28:08.810
can grab that child transaction.

00:28:08.810 --> 00:28:10.695
However, the
dependency graph is,

00:28:10.695 --> 00:28:12.070
no, if you want
in on this child,

00:28:12.070 --> 00:28:14.300
the parent has to
be confirmed first.

00:28:14.300 --> 00:28:17.740
It actually has to be confirmed
earlier in the list of TXIDs

00:28:17.740 --> 00:28:18.730
in the block.

00:28:18.730 --> 00:28:22.730
So it's not-- so like in this,
when you look at a block,

00:28:22.730 --> 00:28:24.820
the transactions are sequenced.

00:28:24.820 --> 00:28:28.480
And this transaction can
spend that transaction.

00:28:28.480 --> 00:28:32.200
But you need to be able
to go in through linearly.

00:28:32.200 --> 00:28:34.750
Update your UTXO set
at every row here,

00:28:34.750 --> 00:28:36.283
and it should be consistent.

00:28:36.283 --> 00:28:37.450
AUDIENCE: I have a question.

00:28:37.450 --> 00:28:38.158
TADGE DRYJA: Yes.

00:28:38.158 --> 00:28:41.820
AUDIENCE: You mentioned LVIV,
those are [INAUDIBLE] terms.

00:28:41.820 --> 00:28:43.330
You mentioned a
threshold earlier.

00:28:43.330 --> 00:28:45.430
How is that
threshold determined?

00:28:45.430 --> 00:28:49.817
TADGE DRYJA: Oh, OK, so there
isn't really a threshold.

00:28:49.817 --> 00:28:52.150
It's just at any point, you're
looking, and you're like,

00:28:52.150 --> 00:28:57.460
well, my minimum fee here
is 30 Satoshis per byte.

00:28:57.460 --> 00:29:00.610
Given the block I'm trying to
mine, what's my lowest fee?

00:29:00.610 --> 00:29:01.780
OK, 30 Satoshis per byte.

00:29:01.780 --> 00:29:03.280
So if I see one
with less than that,

00:29:03.280 --> 00:29:06.387
I know right away
I can ignore it.

00:29:06.387 --> 00:29:07.970
But yeah, it keeps
changing every time

00:29:07.970 --> 00:29:10.940
a new transaction comes in
that displaces an old one, now

00:29:10.940 --> 00:29:12.448
your minimum fee changes.

00:29:12.448 --> 00:29:14.240
So that's just sort of
an easy way to look.

00:29:14.240 --> 00:29:18.740
There is also a relay threshold
which I believe most nodes now

00:29:18.740 --> 00:29:22.400
have at one Satoshi per byte,
where if you're not mining

00:29:22.400 --> 00:29:24.920
and someone gives you a
transaction which is less than

00:29:24.920 --> 00:29:28.910
one-Satoshi-per-byte fee rate,
you will ignore it and not pass

00:29:28.910 --> 00:29:30.470
it on to your peers.

00:29:30.470 --> 00:29:33.250
That's sort of an
anti-spam kind of thing.

00:29:33.250 --> 00:29:34.760
And it may be too high.

00:29:34.760 --> 00:29:36.470
It's also not a
consensus rule, and you

00:29:36.470 --> 00:29:39.620
can set it to whatever you
want in your config file.

00:29:39.620 --> 00:29:41.600
And nodes won't get mad at you.

00:29:41.600 --> 00:29:44.120
They won't ban you if
you send something low.

00:29:44.120 --> 00:29:45.830
So that's sort of
from the miner's side.

00:29:45.830 --> 00:29:48.050
From the miner's
point of view, you

00:29:48.050 --> 00:29:51.140
keep seeing all these
transactions, you sort them,

00:29:51.140 --> 00:29:54.410
you have to deal with the sort
of descendent transactions.

00:29:54.410 --> 00:29:56.820
But you try to get a good
block, try to mine it.

00:29:56.820 --> 00:29:58.820
And you don't really care
what people are doing,

00:29:58.820 --> 00:30:00.362
you just want to
make a lot of money.

00:30:00.362 --> 00:30:02.870
You just want to
maximize for fees.

00:30:02.870 --> 00:30:05.450
From the person
transacting, on their side,

00:30:05.450 --> 00:30:06.722
you want to minimize fees.

00:30:06.722 --> 00:30:08.180
You don't want to
pay these miners.

00:30:08.180 --> 00:30:09.620
They already make
gazillions of dollars

00:30:09.620 --> 00:30:11.287
anyway from all the
new bitcoins they're

00:30:11.287 --> 00:30:13.310
generating-- bunch of jerks.

00:30:13.310 --> 00:30:16.750
So you set your fee to
one Satoshi per byte.

00:30:16.750 --> 00:30:20.110
So you know it'll be relayed,
you sign it, and you broadcast.

00:30:20.110 --> 00:30:21.710
Easy, right?

00:30:21.710 --> 00:30:22.940
So what's the problem here?

00:30:26.050 --> 00:30:26.550
Nobody--

00:30:26.550 --> 00:30:27.690
AUDIENCE: [INAUDIBLE]

00:30:27.690 --> 00:30:30.030
TADGE DRYJA: Doesn't confirm,
all the miners ignore it.

00:30:30.030 --> 00:30:32.670
This is actually a huge--

00:30:32.670 --> 00:30:34.740
well, OK, no, probably
the biggest sort

00:30:34.740 --> 00:30:37.110
of UI problem in
Bitcoin is that people

00:30:37.110 --> 00:30:39.030
have, for years
and years, lost all

00:30:39.030 --> 00:30:41.820
of their coins due to
theft, or loss, or whatever.

00:30:41.820 --> 00:30:42.690
That's the big one.

00:30:42.690 --> 00:30:46.140
But other than that, this
is the biggest UI problem.

00:30:46.140 --> 00:30:48.440
This is the biggest problem
in Bitcoin for users.

00:30:48.440 --> 00:30:52.260
I made a transaction, it hasn't
confirmed, what the heck?

00:30:52.260 --> 00:30:56.790
And I sort of had, on
Reddit, BTC fees, WTF.

00:30:56.790 --> 00:30:57.830
[CHUCKLING]

00:30:57.830 --> 00:31:00.300
Like, why are BTC fees so high?

00:31:00.300 --> 00:31:03.150
There's constant people
complaining, what the heck,

00:31:03.150 --> 00:31:03.960
why--

00:31:03.960 --> 00:31:05.520
are you kidding me?

00:31:05.520 --> 00:31:06.730
Trezor says $50 in fees.

00:31:06.730 --> 00:31:08.010
Am I missing something?

00:31:08.010 --> 00:31:09.990
People get mad.

00:31:09.990 --> 00:31:13.050
And then there's also, I
made a transaction last week,

00:31:13.050 --> 00:31:15.300
it hasn't confirmed.

00:31:15.300 --> 00:31:16.290
Bitcoin doesn't work.

00:31:16.290 --> 00:31:17.070
Bitcoin sucks.

00:31:17.070 --> 00:31:18.720
I hate this thing.

00:31:18.720 --> 00:31:23.750
So huge UI problem, really
poor user experience.

00:31:23.750 --> 00:31:26.280
A lot of it is, also,
the software is bad.

00:31:26.280 --> 00:31:28.850
Wallets-- OK, a
couple of years ago,

00:31:28.850 --> 00:31:31.070
wallets would always
just set a zero fee.

00:31:31.070 --> 00:31:33.890
There weren't fees in 2012.

00:31:33.890 --> 00:31:35.120
You just didn't pay any--

00:31:35.120 --> 00:31:37.820
2013, right?

00:31:37.820 --> 00:31:38.840
I never paid fees.

00:31:38.840 --> 00:31:40.430
It was awesome.

00:31:40.430 --> 00:31:42.830
Because there was this
block-size limit of one

00:31:42.830 --> 00:31:43.730
megabyte.

00:31:43.730 --> 00:31:46.970
But no one was ever running
up against that limit.

00:31:46.970 --> 00:31:49.230
The miners would just
say, look, I'm not even

00:31:49.230 --> 00:31:53.230
going to sort anything
because there's

00:31:53.230 --> 00:31:56.000
200 kilobytes worth of
transactions in the mempool.

00:31:56.000 --> 00:31:58.622
I just mine all of them,
whether the fees are zero,

00:31:58.622 --> 00:32:00.830
whether the fees are one
Satoshi, whatever-- whatever

00:32:00.830 --> 00:32:02.450
I can get, just mine it all.

00:32:02.450 --> 00:32:04.730
Now you've got this
constrained space,

00:32:04.730 --> 00:32:06.290
and so you're optimizing--

00:32:06.290 --> 00:32:07.070
the miner is.

00:32:07.070 --> 00:32:08.480
But years ago, you weren't.

00:32:08.480 --> 00:32:11.420
And so the wallets,
a lot of times,

00:32:11.420 --> 00:32:14.590
they would either have
zero fee, completely,

00:32:14.590 --> 00:32:17.240
a fixed fee per
transaction, which

00:32:17.240 --> 00:32:18.860
is also really
suboptimal-- they just

00:32:18.860 --> 00:32:21.560
say, OK, I'll pay 100 hundreds
Satoshi per transaction.

00:32:21.560 --> 00:32:24.710
Some transactions have a lot
of inputs, are much bigger,

00:32:24.710 --> 00:32:27.320
so that's a highly
variable fee rate which

00:32:27.320 --> 00:32:28.442
the user can't control.

00:32:28.442 --> 00:32:30.650
Or they'd have a fixed fee
rate, where they just say,

00:32:30.650 --> 00:32:32.980
I'm going to set five
Satoshis per byte,

00:32:32.980 --> 00:32:34.700
and that's the fee
rate in this wallet,

00:32:34.700 --> 00:32:37.100
and you don't allow the
user to change it at all.

00:32:37.100 --> 00:32:38.360
That's also really suboptimal.

00:32:38.360 --> 00:32:40.880
Once the fee market
starts changing

00:32:40.880 --> 00:32:44.690
and people start paying
more, this wallet software

00:32:44.690 --> 00:32:45.680
will not work.

00:32:45.680 --> 00:32:48.440
Or you can have the user choose
a fee rate, which seems great,

00:32:48.440 --> 00:32:51.080
but users are
like, I don't know.

00:32:51.080 --> 00:32:53.760
You're using Bitcoin,
what fee rate do you want,

00:32:53.760 --> 00:32:57.120
10 Satoshis per
byte, 20, 40, 70?

00:32:57.120 --> 00:32:58.040
What's a Satoshi?

00:32:58.040 --> 00:33:00.020
What's a byte?

00:33:00.020 --> 00:33:02.600
This is not a great problem
to hand off to the user.

00:33:02.600 --> 00:33:05.217
How do I even determine this?

00:33:05.217 --> 00:33:07.550
There are sites, and the sites
aren't very good, either.

00:33:07.550 --> 00:33:13.310
Where was it-- yeah, here
is what used to be 21.co,

00:33:13.310 --> 00:33:14.840
with all the Raspberry Pi guys.

00:33:14.840 --> 00:33:20.150
And then this is
their fee rate thing,

00:33:20.150 --> 00:33:22.730
which is a really
hard-to-understand chart.

00:33:22.730 --> 00:33:25.380
What does this mean, unconfirmed
transactions, transactions

00:33:25.380 --> 00:33:26.210
today?

00:33:26.210 --> 00:33:27.310
What are these numbers?

00:33:27.310 --> 00:33:29.140
I still don't really
understand this site.

00:33:29.140 --> 00:33:32.120
And at the bottom it
says, fastest and cheapest

00:33:32.120 --> 00:33:34.430
transaction fee is
50 Satoshis per byte,

00:33:34.430 --> 00:33:36.650
shown in green at the top.

00:33:36.650 --> 00:33:40.670
So I guess this, or this.

00:33:40.670 --> 00:33:43.430
Thing is, huge overestimate.

00:33:43.430 --> 00:33:47.630
I think one Satoshi per
byte is probably OK today--

00:33:47.630 --> 00:33:50.400
maybe five.

00:33:50.400 --> 00:33:52.680
This is a better
site-- also complex--

00:33:52.680 --> 00:33:54.960
where you can say,
OK, well, here's

00:33:54.960 --> 00:33:58.720
the mempool size in
megabytes, sorted by fee rate.

00:33:58.720 --> 00:34:01.140
And you can see that,
well, at 8 o'clock,

00:34:01.140 --> 00:34:03.600
mempool was basically empty.

00:34:03.600 --> 00:34:05.280
At 8 o'clock, you
could have paid zero

00:34:05.280 --> 00:34:07.260
and it would have
gotten through,

00:34:07.260 --> 00:34:08.699
but people are paying more now.

00:34:08.699 --> 00:34:11.580
And it's also kind of crazy to
see that some people are paying

00:34:11.580 --> 00:34:16.080
200 Satoshis per byte,
even though, generally,

00:34:16.080 --> 00:34:18.570
over the course of a few
hours, zero Satoshis per byte

00:34:18.570 --> 00:34:19.830
will also confirm.

00:34:19.830 --> 00:34:21.780
Are they really time-sensitive?

00:34:21.780 --> 00:34:22.530
Probably not.

00:34:22.530 --> 00:34:24.330
Probably, their
software is crummy,

00:34:24.330 --> 00:34:28.870
and their software
just estimates 200.

00:34:28.870 --> 00:34:33.979
So it's easy to
make fun of people

00:34:33.979 --> 00:34:35.710
and be like, these
guys are idiots.

00:34:35.710 --> 00:34:38.530
It's actually not that easy to
estimate what fee you should

00:34:38.530 --> 00:34:41.500
issue a transaction with.

00:34:41.500 --> 00:34:46.060
It's also sort of asymmetric
in that a lot of exchanges,

00:34:46.060 --> 00:34:49.870
someone says, I want to
withdraw my 10 bitcoins.

00:34:49.870 --> 00:34:52.750
I traded, this is a lot
of money, withdraw, click.

00:34:52.750 --> 00:34:54.340
It doesn't confirm
for six hours.

00:34:54.340 --> 00:34:56.560
The customer gets
super mad and starts

00:34:56.560 --> 00:35:00.707
calling customer support.

00:35:00.707 --> 00:35:02.290
Whereas if the
exchange is like, look,

00:35:02.290 --> 00:35:04.332
we're just going to issue
all of our transactions

00:35:04.332 --> 00:35:06.190
with 200 Satoshis
per byte, they always

00:35:06.190 --> 00:35:07.630
go through the next block.

00:35:07.630 --> 00:35:08.680
Yeah, we lose money.

00:35:08.680 --> 00:35:11.470
But maybe we get the
customer to pay for it.

00:35:11.470 --> 00:35:11.970
Yeah.

00:35:11.970 --> 00:35:12.724
AUDIENCE: Do you
think it could be

00:35:12.724 --> 00:35:15.530
people using maybe percentage
of their transactions,

00:35:15.530 --> 00:35:18.183
which obviously doesn't
make any sense, but--

00:35:18.183 --> 00:35:19.600
TADGE DRYJA: I
don't think there's

00:35:19.600 --> 00:35:20.480
any software that does that

00:35:20.480 --> 00:35:21.094
AUDIENCE: --finance
firm, and that's

00:35:21.094 --> 00:35:22.662
just what they're used to.

00:35:22.662 --> 00:35:24.870
That's how they're used to
paying fees, [INAUDIBLE]..

00:35:24.870 --> 00:35:26.735
I don't think so.

00:35:26.735 --> 00:35:29.110
TADGE DRYJA: I've never seen
any software that does that.

00:35:29.110 --> 00:35:31.060
I've seen some software
that does really dumb stuff

00:35:31.060 --> 00:35:31.907
with regard to fees.

00:35:31.907 --> 00:35:32.740
I haven't seen that.

00:35:32.740 --> 00:35:34.900
That would be a new thing.

00:35:34.900 --> 00:35:37.420
So I don't think so, but maybe.

00:35:37.420 --> 00:35:40.430
AUDIENCE: I presume that
it's the exchanges or wallet,

00:35:40.430 --> 00:35:43.568
companies just feel like their
customers are happy are happier

00:35:43.568 --> 00:35:45.110
and they're charging
their customers.

00:35:45.110 --> 00:35:47.272
It's just passing through
the cost to customers.

00:35:47.272 --> 00:35:48.730
But a quick question--
why not just

00:35:48.730 --> 00:35:55.130
do an algorithm that takes
the last six to 10 blocks,

00:35:55.130 --> 00:35:59.815
maybe time-weights it, and
do an algorithm base, so

00:35:59.815 --> 00:36:02.760
an actual experience
in the marketplace?

00:36:02.760 --> 00:36:06.280
TADGE DRYJA: Yeah, that is
what the current Bitcoin D

00:36:06.280 --> 00:36:08.140
algorithm does.

00:36:08.140 --> 00:36:10.173
Even that can be off sometimes.

00:36:10.173 --> 00:36:11.590
And it allows sort
of a estimate--

00:36:11.590 --> 00:36:13.310
OK, how quickly
do you need this?

00:36:13.310 --> 00:36:14.730
Do you need this
in the next hour,

00:36:14.730 --> 00:36:18.220
do you need it in the next
six hours, the next half hour?

00:36:18.220 --> 00:36:20.230
So yeah, the one in
Bitcoin D is better.

00:36:20.230 --> 00:36:26.230
But it's not-- it's easy to
say, oh, this should be easy.

00:36:26.230 --> 00:36:29.710
The thing is, it's
a weird market.

00:36:29.710 --> 00:36:32.563
You're bidding for something
that you don't quite know--

00:36:32.563 --> 00:36:34.480
and you don't know what
other participants are

00:36:34.480 --> 00:36:35.188
going to pile in.

00:36:35.188 --> 00:36:38.850
Sometimes-- so something
like this, oh, a block

00:36:38.850 --> 00:36:40.640
didn't come out
for half an hour,

00:36:40.640 --> 00:36:44.750
and a bunch of other people
came and submitted higher bids

00:36:44.750 --> 00:36:46.040
after you.

00:36:46.040 --> 00:36:48.590
And so now you got out--
in practice, well, yeah,

00:36:48.590 --> 00:36:51.610
someone who submitted a bid
here, a transaction here,

00:36:51.610 --> 00:36:53.720
a block came out there, and--

00:36:53.720 --> 00:36:57.140
let's zoom in for an example.

00:36:57.140 --> 00:36:58.260
Well, that's too low.

00:36:58.260 --> 00:37:02.150
But I submitted something here.

00:37:02.150 --> 00:37:03.230
I think it will get in.

00:37:03.230 --> 00:37:05.147
But then all these other
people came after me,

00:37:05.147 --> 00:37:06.890
and then the block
didn't confirm mine.

00:37:06.890 --> 00:37:09.830
It did later, another
few minutes later.

00:37:09.830 --> 00:37:12.380
But it's hard-- there's
never any determinism in how

00:37:12.380 --> 00:37:13.200
it's going to work.

00:37:13.200 --> 00:37:13.600
Yes.

00:37:13.600 --> 00:37:15.142
AUDIENCE: So if fees
are always lower

00:37:15.142 --> 00:37:18.060
around 8:00 AM or 4:00 AM,
why not just pool transactions

00:37:18.060 --> 00:37:19.040
for around that time?

00:37:19.040 --> 00:37:20.623
TADGE DRYJA: They're
not, because it's

00:37:20.623 --> 00:37:22.460
all over the world.

00:37:22.460 --> 00:37:25.010
They do tend to be
lower on the weekends.

00:37:25.010 --> 00:37:28.020
People don't make as many
transactions on the weekends.

00:37:28.020 --> 00:37:30.760
And so, yes, sometimes
people will say,

00:37:30.760 --> 00:37:32.540
hey, I've got
these transactions.

00:37:32.540 --> 00:37:35.270
In practice, if you say, I
don't care how long it takes,

00:37:35.270 --> 00:37:37.300
just set a low fee and wait.

00:37:37.300 --> 00:37:41.085
And it will stay in
the mempool for weeks.

00:37:41.085 --> 00:37:43.460
So there have been people who
said, I made a transaction,

00:37:43.460 --> 00:37:46.733
I put a super-low fee, it
confirmed a month later.

00:37:46.733 --> 00:37:47.650
The thing is, if you--

00:37:47.650 --> 00:37:52.520
I should go, yeah, this
is something of a tangent.

00:37:52.520 --> 00:37:57.200
But if you look over six months,
it's really highly variable.

00:37:57.200 --> 00:38:00.350
It used to be sort of
nothing, and then--

00:38:00.350 --> 00:38:03.460
part of it is the--

00:38:03.460 --> 00:38:06.330
it looks most dramatic here,
because you're sorting by--

00:38:06.330 --> 00:38:09.180
this shows the fee rate.

00:38:09.180 --> 00:38:11.008
It's like nothing.

00:38:11.008 --> 00:38:12.300
You don't have to deal with it.

00:38:12.300 --> 00:38:13.805
And then like, whoa, OK.

00:38:13.805 --> 00:38:15.180
And people were
complaining, hey,

00:38:15.180 --> 00:38:16.770
it's days where
nothing confirmed.

00:38:16.770 --> 00:38:20.310
Here it was weeks, months, like
all of December and January.

00:38:20.310 --> 00:38:23.280
And it was correlated
with everyone

00:38:23.280 --> 00:38:25.560
in the media, everyone
wanting to buy bitcoins,

00:38:25.560 --> 00:38:28.420
the price skyrocketed.

00:38:28.420 --> 00:38:30.120
So it's very sort of peaky.

00:38:30.120 --> 00:38:32.040
And then I think interest
has died down a bit,

00:38:32.040 --> 00:38:34.980
and the fees have
gone down with it.

00:38:34.980 --> 00:38:38.050
So this is a hard
problem to deal with.

00:38:38.050 --> 00:38:40.230
And it wasn't something
people were dealing

00:38:40.230 --> 00:38:43.433
with until a few months ago.

00:38:43.433 --> 00:38:45.600
Most of the time, you could
get by with just setting

00:38:45.600 --> 00:38:48.480
a low fixed fee or
something, and it would work.

00:38:48.480 --> 00:38:50.760
But now we're really seeing
the fee market develop.

00:38:50.760 --> 00:38:55.840
Also, people disagreed that
this should even be a thing.

00:38:55.840 --> 00:38:59.220
So there's Bitcoin Cash,
there's all these forks,

00:38:59.220 --> 00:39:03.550
the idea of, if you start
hitting the block-size limit,

00:39:03.550 --> 00:39:05.618
increase the limit.

00:39:05.618 --> 00:39:06.910
Why should we have to pay fees?

00:39:06.910 --> 00:39:09.760
The miners are already getting
plenty of money to mine with,

00:39:09.760 --> 00:39:12.220
we should just have as much
transactions that we want.

00:39:12.220 --> 00:39:14.920
So there's people that say that.

00:39:14.920 --> 00:39:15.480
Yes.

00:39:15.480 --> 00:39:17.980
AUDIENCE: Sorry, if you're
not getting them confirmed,

00:39:17.980 --> 00:39:21.020
you could just issue another
transaction with higher fees.

00:39:21.020 --> 00:39:23.103
TADGE DRYJA: That's what
I'm going to get to next.

00:39:26.340 --> 00:39:28.230
So not always.

00:39:28.230 --> 00:39:30.510
So one, your software
might not do that.

00:39:30.510 --> 00:39:33.410
Most software in
the last few years

00:39:33.410 --> 00:39:36.210
just said, look, once
the transaction is sent,

00:39:36.210 --> 00:39:37.270
it's stuck.

00:39:37.270 --> 00:39:39.960
It's just like, yeah, I sent
it, waiting for it to confirm.

00:39:39.960 --> 00:39:42.000
And you have to
actually code something

00:39:42.000 --> 00:39:44.310
to deal with changing
the transaction ID,

00:39:44.310 --> 00:39:45.780
invalidating the old one.

00:39:45.780 --> 00:39:48.390
That's some software.

00:39:48.390 --> 00:39:51.360
So one way a wallet could
deal with this is to say,

00:39:51.360 --> 00:39:53.040
OK, well I'll do
Child Pays for Parent.

00:39:53.040 --> 00:39:54.630
This is actually a little
bit easier, software-wise,

00:39:54.630 --> 00:39:56.547
because you don't have
to invalidate anything.

00:39:56.547 --> 00:39:59.088
You could just say, I'm going
to send a transaction, spending

00:39:59.088 --> 00:40:01.170
one of those new outputs
that's not confirmed,

00:40:01.170 --> 00:40:02.220
with a very high fee.

00:40:02.220 --> 00:40:04.220
Now, the average of the
two will be high enough,

00:40:04.220 --> 00:40:05.370
maybe it will get in.

00:40:05.370 --> 00:40:08.880
You can also do this when
you're on the receiving end.

00:40:08.880 --> 00:40:13.430
So if someone sent you a coin,
but they sent that transaction

00:40:13.430 --> 00:40:14.520
with a low fee.

00:40:14.520 --> 00:40:16.800
And maybe you can't
contact them anymore,

00:40:16.800 --> 00:40:19.050
maybe they're unresponsive
or they don't care.

00:40:19.050 --> 00:40:21.690
And you're like, well, I
really need this money,

00:40:21.690 --> 00:40:25.050
I want it confirmed,
I can then respend

00:40:25.050 --> 00:40:27.660
that output with a high fee
to confirm both of them.

00:40:27.660 --> 00:40:31.140
It's kind of annoying,
but possible.

00:40:31.140 --> 00:40:33.330
Downsides of this--

00:40:33.330 --> 00:40:35.610
Child Pays for Parent
is very inefficient.

00:40:35.610 --> 00:40:37.520
You're making an
extra transaction.

00:40:37.520 --> 00:40:39.895
And it's exacerbating the
problem you're trying to solve.

00:40:39.895 --> 00:40:42.062
The whole problem is, there's
too many transactions,

00:40:42.062 --> 00:40:43.260
there's not enough space.

00:40:43.260 --> 00:40:47.820
And you're increasing
your priority in the queue

00:40:47.820 --> 00:40:49.540
by wasting even more space.

00:40:49.540 --> 00:40:53.460
So if everyone does Child Pays
for Parent, it's really bad.

00:40:53.460 --> 00:40:55.050
Now every transaction
is going to take

00:40:55.050 --> 00:40:57.780
two or three transactions.

00:40:57.780 --> 00:41:00.030
And the dependency graphs
are kind of complex.

00:41:00.030 --> 00:41:02.160
You can have--

00:41:02.160 --> 00:41:03.780
I don't remember exactly how.

00:41:03.780 --> 00:41:08.600
There are certain cases
where Child Pays for Parent

00:41:08.600 --> 00:41:12.130
lowers the priority
of a transaction.

00:41:12.130 --> 00:41:13.130
I didn't understand how.

00:41:13.130 --> 00:41:15.770
But someone explained it to
me, and I'm like, oh, shoot,

00:41:15.770 --> 00:41:17.570
that's bad.

00:41:17.570 --> 00:41:20.120
Where someone else
spending an output can--

00:41:20.120 --> 00:41:22.430
if there's a whole branch
of tons of different outputs

00:41:22.430 --> 00:41:24.530
and tons of different
Child Pay for Parent,

00:41:24.530 --> 00:41:26.060
there are certain
parts where, OK,

00:41:26.060 --> 00:41:28.940
if someone makes a low fee
transaction, that can actually

00:41:28.940 --> 00:41:31.590
lower the priority
of the parents.

00:41:31.590 --> 00:41:32.940
I don't remember.

00:41:32.940 --> 00:41:35.070
Anyway, so it's kind of
a mess, it's complex,

00:41:35.070 --> 00:41:37.370
and it's also just
very inefficient.

00:41:37.370 --> 00:41:41.280
OK, so another way which
seems obvious, why don't I

00:41:41.280 --> 00:41:42.340
just double-spend it?

00:41:42.340 --> 00:41:44.160
I made a transaction
with a low fee,

00:41:44.160 --> 00:41:45.810
why doesn't my wallet
just say, look,

00:41:45.810 --> 00:41:47.727
I'm going to replace
that transaction with one

00:41:47.727 --> 00:41:49.140
with a higher fee?

00:41:49.140 --> 00:41:53.370
And I just decrease the
change output amount.

00:41:53.370 --> 00:41:55.675
That's simple, right?

00:41:55.675 --> 00:41:58.050
[CHUCKLING]

00:41:58.050 --> 00:42:00.280
Another problem-- the
default relay behavior

00:42:00.280 --> 00:42:02.020
is to ignore double-spends.

00:42:02.020 --> 00:42:06.580
And this is not just a
default that's for fun.

00:42:06.580 --> 00:42:09.160
This is actually-- there's
good reasons for it.

00:42:09.160 --> 00:42:13.480
So if you see a transaction
spending output A, output B,

00:42:13.480 --> 00:42:14.980
and then you see
another transaction

00:42:14.980 --> 00:42:18.010
over the wire, spending
one of those outputs

00:42:18.010 --> 00:42:21.550
that you've already
seen, you will ignore it.

00:42:21.550 --> 00:42:24.327
You won't ban-- won't get mad at
the person who sent it to you,

00:42:24.327 --> 00:42:25.410
but you'll just ignore it.

00:42:25.410 --> 00:42:26.080
Because you're
like, no, I already

00:42:26.080 --> 00:42:28.000
saw a conflicting transaction.

00:42:28.000 --> 00:42:30.798
So the default is,
first thing you see

00:42:30.798 --> 00:42:31.840
is the thing you go with.

00:42:34.200 --> 00:42:35.700
This is not a
consensus rule, right,

00:42:35.700 --> 00:42:37.410
because we're not dealing with
anything that's in the blocks

00:42:37.410 --> 00:42:38.070
yet.

00:42:38.070 --> 00:42:41.178
But any ideas of why this is
an important rule to have?

00:42:44.670 --> 00:42:46.650
What are some attacks
that you could perform?

00:42:46.650 --> 00:42:49.590
If you just said,
yeah, anything--

00:42:49.590 --> 00:42:52.560
I'm not going to stick with
the first-seen transaction.

00:42:52.560 --> 00:42:54.662
I will update anytime
I see a new one.

00:42:54.662 --> 00:42:55.620
I'll just go with the--

00:42:55.620 --> 00:42:57.600
I'll go with the last-seen
transaction instead

00:42:57.600 --> 00:42:58.830
of first-seen transaction.

00:42:58.830 --> 00:43:03.412
What would be an attack that
would be enabled by that?

00:43:03.412 --> 00:43:04.120
Any ideas?

00:43:06.645 --> 00:43:08.610
You got to think adversarially.

00:43:08.610 --> 00:43:10.310
I'm trying to
bring down Bitcoin.

00:43:10.310 --> 00:43:14.150
If you change your code to last
seen instead of first seen,

00:43:14.150 --> 00:43:17.220
how do I bring down the network?

00:43:17.220 --> 00:43:19.500
AUDIENCE: [INAUDIBLE]

00:43:19.500 --> 00:43:22.990
TADGE DRYJA: Right, yeah, I just
keep spending the same outputs,

00:43:22.990 --> 00:43:24.750
100 times a second.

00:43:24.750 --> 00:43:27.853
And they all have
the same fee rate.

00:43:27.853 --> 00:43:29.520
I can just keep doing
that indefinitely,

00:43:29.520 --> 00:43:31.755
and I just keep
flooding the network.

00:43:31.755 --> 00:43:34.380
And everyone's like, oh, here's
this new one, oh, here's this--

00:43:34.380 --> 00:43:35.920
total mess.

00:43:35.920 --> 00:43:38.500
However, there is a way to
prevent that kind of flooding

00:43:38.500 --> 00:43:40.900
attack, or at least
significantly mitigate

00:43:40.900 --> 00:43:44.620
it, which is, OK, we'll relay
conflicting transactions,

00:43:44.620 --> 00:43:47.260
but we require an
increase in the fee.

00:43:47.260 --> 00:43:51.010
And the required increase is
equal to our minimum relay fee

00:43:51.010 --> 00:43:52.930
of one Satoshi per byte.

00:43:52.930 --> 00:43:54.970
So every time I
could say, OK, I'm

00:43:54.970 --> 00:43:58.990
going to replace it because
it has a higher fee.

00:43:58.990 --> 00:44:01.300
So now it's sort of
constantly incrementing.

00:44:01.300 --> 00:44:03.220
You can't keep doing
that indefinitely.

00:44:03.220 --> 00:44:05.613
Every time you want to
send a transaction out

00:44:05.613 --> 00:44:07.780
to the network and use
everyone's network resources,

00:44:07.780 --> 00:44:11.970
you are sort of potentially
paying something for it.

00:44:11.970 --> 00:44:15.240
Yeah, you will continue
to ignore transactions

00:44:15.240 --> 00:44:17.950
with same or lower fee.

00:44:17.950 --> 00:44:18.980
Oh, I did the why.

00:44:18.980 --> 00:44:20.373
Yeah, the why happened there.

00:44:20.373 --> 00:44:22.790
Anyway, yeah, the DDoS attack
is make lots of transactions

00:44:22.790 --> 00:44:24.390
with the same fee,
clog the network.

00:44:24.390 --> 00:44:27.560
OK, so this seems simple, right?

00:44:27.560 --> 00:44:28.658
We have replace by fee.

00:44:28.658 --> 00:44:30.200
If you have a higher
transaction fee,

00:44:30.200 --> 00:44:31.790
you replace the
transactions, wallets

00:44:31.790 --> 00:44:32.870
implement it, no problem.

00:44:36.360 --> 00:44:39.960
Well, people don't like it.

00:44:39.960 --> 00:44:42.870
People said, no, we don't
like replace by fee.

00:44:42.870 --> 00:44:45.532
This was a controversy
around 2015,

00:44:45.532 --> 00:44:47.490
when a bunch of the
developers were like, yeah,

00:44:47.490 --> 00:44:49.530
this seems reasonable,
let's put it in.

00:44:49.530 --> 00:44:51.360
People said, no, this
hurts the security

00:44:51.360 --> 00:44:53.100
of unconfirmed transactions.

00:44:53.100 --> 00:44:55.320
And to some extent, they
do have a point, right?

00:44:55.320 --> 00:44:57.840
If every node on
the network says

00:44:57.840 --> 00:45:00.280
I'm going with my
first-seen transaction,

00:45:00.280 --> 00:45:03.480
if there's a conflicting
transaction later, I ignore it.

00:45:03.480 --> 00:45:05.580
That means it's hard
to double-spend,

00:45:05.580 --> 00:45:08.790
even before it
gets into a block.

00:45:08.790 --> 00:45:11.560
You spend-- you say, OK, I'm
going to send money to Alice,

00:45:11.560 --> 00:45:12.765
and here's my change output.

00:45:12.765 --> 00:45:14.140
And then you
replace it with, I'm

00:45:14.140 --> 00:45:17.860
going to send money to Bob
instead, and my change output.

00:45:17.860 --> 00:45:20.440
You can potentially make
it appear that someone's

00:45:20.440 --> 00:45:23.050
going to get paid-- it
still says unconfirmed,

00:45:23.050 --> 00:45:25.210
but they say, yeah, you
sent me a transaction,

00:45:25.210 --> 00:45:27.040
it'll get confirmed
soon, and then

00:45:27.040 --> 00:45:30.130
switch it out and try to
make it so that you pay it

00:45:30.130 --> 00:45:32.940
back to yourself instead.

00:45:32.940 --> 00:45:35.615
When everyone on the network
ignores those new transactions,

00:45:35.615 --> 00:45:36.240
it gets harder.

00:45:36.240 --> 00:45:39.100
You'd have to contact a
miner directly and say,

00:45:39.100 --> 00:45:41.200
hey, I have this
transaction on the network,

00:45:41.200 --> 00:45:46.020
here's a conflicting one, please
include it in your next block,

00:45:46.020 --> 00:45:48.120
to double-spend, to
defraud this person.

00:45:50.850 --> 00:45:53.723
The thing is, in practice,
it's not that hard to do this.

00:45:53.723 --> 00:45:55.390
And so a lot of the
developers are like,

00:45:55.390 --> 00:45:57.610
look, unconfirmed
transactions really

00:45:57.610 --> 00:45:59.470
have no security with them.

00:45:59.470 --> 00:46:01.510
And yeah, it might
seem like we're

00:46:01.510 --> 00:46:04.330
reducing the security here,
but you really should not

00:46:04.330 --> 00:46:05.765
depend on unconfirmed at all.

00:46:05.765 --> 00:46:06.890
It's not in the blockchain.

00:46:06.890 --> 00:46:07.932
There's no proof of work.

00:46:07.932 --> 00:46:10.360
The whole point of the system
is to put the proof of work

00:46:10.360 --> 00:46:12.160
to really get consensus.

00:46:12.160 --> 00:46:14.810
And you cannot rely on
network-level consensus,

00:46:14.810 --> 00:46:17.300
because there isn't any.

00:46:17.300 --> 00:46:19.390
And yeah, so to
some extent, replace

00:46:19.390 --> 00:46:21.700
by fee does make the
double-spends easier to do.

00:46:21.700 --> 00:46:23.470
That's the point.

00:46:23.470 --> 00:46:26.050
But the thing is, it's
not secure anyway.

00:46:26.050 --> 00:46:30.560
So anyway, it's
also a UI issue--

00:46:30.560 --> 00:46:32.960
should you even show
unconfirmed transactions?

00:46:32.960 --> 00:46:36.310
Almost all of the wallets
do, even the SPV ones.

00:46:36.310 --> 00:46:39.293
And the SPV ones have no
idea if it's even valid

00:46:39.293 --> 00:46:41.210
or has a valid signature
since they can't even

00:46:41.210 --> 00:46:42.470
check signatures.

00:46:42.470 --> 00:46:45.418
Unconfirmed transactions
are not meaningless.

00:46:45.418 --> 00:46:47.960
If you see it on the network,
and you're running a full node,

00:46:47.960 --> 00:46:49.460
you see, yes, this
is a transaction

00:46:49.460 --> 00:46:51.710
that could be confirmed.

00:46:51.710 --> 00:46:53.870
They've provided
a valid signature.

00:46:53.870 --> 00:46:55.340
Any miner can put this in.

00:46:55.340 --> 00:46:56.860
There's no conflicts.

00:46:56.860 --> 00:46:57.830
This can work.

00:46:57.830 --> 00:47:00.320
If you're SPV and you see
an unconfirmed transaction,

00:47:00.320 --> 00:47:02.863
you have no idea,
because you don't even

00:47:02.863 --> 00:47:05.030
know if it's spending outputs
that exist because you

00:47:05.030 --> 00:47:06.560
don't have a UTXO set.

00:47:06.560 --> 00:47:07.940
You can't verify the signatures.

00:47:07.940 --> 00:47:10.860
You don't even know what
the keys are supposed to be.

00:47:10.860 --> 00:47:15.200
But most SPV wallets still
show unconfirmed transactions

00:47:15.200 --> 00:47:16.550
because users want it.

00:47:16.550 --> 00:47:17.690
They want to know.

00:47:17.690 --> 00:47:20.360
And it's like, sometimes they'll
put it in, like, red text,

00:47:20.360 --> 00:47:22.568
like, hey, it's unconfirmed,
or put a little question

00:47:22.568 --> 00:47:24.360
mark next to it.

00:47:24.360 --> 00:47:27.240
I would rather just
not show it at all.

00:47:27.240 --> 00:47:31.070
I think it gives a
misleading sense to users.

00:47:31.070 --> 00:47:32.540
But this is an issue, right?

00:47:32.540 --> 00:47:36.350
Users are like, I want to know
if the sender has actually

00:47:36.350 --> 00:47:37.470
signed and sent.

00:47:37.470 --> 00:47:39.470
And then yeah, afterwards,
it gets in the block.

00:47:39.470 --> 00:47:41.137
Yeah, now it's
confirmed, now it's safe.

00:47:41.137 --> 00:47:43.010
But I want to know.

00:47:43.010 --> 00:47:46.300
So SPV can sometimes connect
multiple nodes and ask.

00:47:46.300 --> 00:47:47.750
But this is a
controversial thing

00:47:47.750 --> 00:47:50.390
that people have argued about.

00:47:50.390 --> 00:47:53.990
My personal opinion
is that security

00:47:53.990 --> 00:47:56.930
is more important than UI
and usability in this case,

00:47:56.930 --> 00:48:00.530
and you really should
not rely on anything that

00:48:00.530 --> 00:48:02.330
has unconfirmed transactions.

00:48:02.330 --> 00:48:05.540
And also, the RBF-- the
Replace By Fee policy

00:48:05.540 --> 00:48:10.010
is not a network
consensus-level rule.

00:48:10.010 --> 00:48:12.410
You don't know what
policy people have.

00:48:12.410 --> 00:48:15.375
If people are running-- if
nodes are running "I just

00:48:15.375 --> 00:48:17.000
stick with the
first-seen transaction,"

00:48:17.000 --> 00:48:18.860
or "I replace with
incrementing fees,"

00:48:18.860 --> 00:48:21.880
or "I replace no matter
what," or who knows,

00:48:21.880 --> 00:48:26.420
"I'll go with three or four
updates and then I'll ignore."

00:48:26.420 --> 00:48:29.200
You just don't know
what people are doing.

00:48:29.200 --> 00:48:31.020
So the compromise
that's currently

00:48:31.020 --> 00:48:35.970
in the Bitcoin software is
called opt-in replace by fee.

00:48:35.970 --> 00:48:40.740
You flag a transaction by
changing the sequence number

00:48:40.740 --> 00:48:45.120
in the input to not be FFFFF.

00:48:45.120 --> 00:48:48.210
And then you indicate, hey,
I'm flagging my transaction

00:48:48.210 --> 00:48:51.990
as this can be replaced
with an increasing fee.

00:48:51.990 --> 00:48:53.490
It's kind of ugly in my opinion.

00:48:53.490 --> 00:48:53.990
It's

00:48:53.990 --> 00:48:58.200
Like-- it's not really opt-in.

00:48:58.200 --> 00:48:59.520
You can't even opt out.

00:48:59.520 --> 00:49:03.510
It's weird to say to people,
oh, yeah, you opt into RBF.

00:49:03.510 --> 00:49:05.670
Because there's no
way to prevent it.

00:49:05.670 --> 00:49:07.140
You can always
contact the miners,

00:49:07.140 --> 00:49:08.580
or anyone can just run it.

00:49:08.580 --> 00:49:10.553
And there's code
out there that's

00:49:10.553 --> 00:49:11.970
a couple of lines
different that's

00:49:11.970 --> 00:49:14.700
like, here's the full
RBF version of Bitcoin,

00:49:14.700 --> 00:49:17.130
where it'll just
ignore this flag

00:49:17.130 --> 00:49:19.440
and treat everything the same.

00:49:19.440 --> 00:49:23.220
But we do now have the option--
so if you run a wallet,

00:49:23.220 --> 00:49:25.140
and I believe that
the Bitcoin Core

00:49:25.140 --> 00:49:28.110
Wallet, with the new
version last week

00:49:28.110 --> 00:49:31.680
or last month, now, by default,
flags every transaction as

00:49:31.680 --> 00:49:35.190
replace by fee, so that you
can then bump the fee later on.

00:49:40.730 --> 00:49:44.150
And this is a much better
way to deal with fees.

00:49:44.150 --> 00:49:45.440
Because then you're not stuck.

00:49:45.440 --> 00:49:47.360
And then, to some
extent, you don't even

00:49:47.360 --> 00:49:49.250
need to look at the
mempool and what

00:49:49.250 --> 00:49:51.020
fees everyone else is paying.

00:49:51.020 --> 00:49:55.090
You can just say, well, I can
also time-lock transactions,

00:49:55.090 --> 00:49:57.830
and I can say, OK, well,
at the current block,

00:49:57.830 --> 00:49:59.630
I'll pay one Satoshi per byte.

00:49:59.630 --> 00:50:01.640
I'll also send out
a transaction where

00:50:01.640 --> 00:50:03.170
it's not valid until
the next block,

00:50:03.170 --> 00:50:04.730
and I pay two Satoshis per byte.

00:50:04.730 --> 00:50:07.022
And then the block after
that, I'll pay four, and block

00:50:07.022 --> 00:50:10.310
after that, I'll pay eight, or
whatever sort of fee schedule

00:50:10.310 --> 00:50:11.210
you want.

00:50:11.210 --> 00:50:13.760
And then the miners now
have the option to look

00:50:13.760 --> 00:50:16.790
and say, well, two Satoshis
per byte is too little,

00:50:16.790 --> 00:50:17.963
I'm not going to take it.

00:50:17.963 --> 00:50:19.130
But then a block comes out--

00:50:19.130 --> 00:50:20.030
OK, now it's four.

00:50:20.030 --> 00:50:22.724
OK, I'll take that one.

00:50:22.724 --> 00:50:25.720
And so that's a really nice
sort of fire-and-forget

00:50:25.720 --> 00:50:28.960
from the user's wallet,
where I don't even

00:50:28.960 --> 00:50:30.670
know what fee I should
pay, well, look,

00:50:30.670 --> 00:50:32.470
I'll just keep incrementing it.

00:50:32.470 --> 00:50:35.470
And hopefully it confirms
soon at a low rate.

00:50:35.470 --> 00:50:38.350
As it takes longer and
longer, my rate goes up,

00:50:38.350 --> 00:50:39.620
and eventually I'll get it in.

00:50:39.620 --> 00:50:40.120
Yeah.

00:50:40.120 --> 00:50:43.200
AUDIENCE: Are there any limits
to how many times you do that?

00:50:43.200 --> 00:50:44.200
TADGE DRYJA: Not really.

00:50:44.200 --> 00:50:46.680
OK, so one limit is you
cannot actually broadcast

00:50:46.680 --> 00:50:51.890
the transaction that is
valid in a future block.

00:50:51.890 --> 00:50:53.192
The network will ignore it.

00:50:53.192 --> 00:50:55.150
It's a similar reason,
denial of service thing,

00:50:55.150 --> 00:50:57.980
where, hey, here's a transaction
that's valid next week.

00:50:57.980 --> 00:51:00.850
Well, why'd you
tell it to me today?

00:51:00.850 --> 00:51:03.310
So you'd have to be
online to do that.

00:51:03.310 --> 00:51:05.950
But your wallet can
do it automatically.

00:51:05.950 --> 00:51:09.240
It can just do it
in the background.

00:51:09.240 --> 00:51:11.000
And in practice, I
don't know any wallets

00:51:11.000 --> 00:51:13.310
that do that right now.

00:51:13.310 --> 00:51:16.280
The Core Wallet will
allow you to in the UI.

00:51:16.280 --> 00:51:18.200
You sort of right-click
and you say, bump--

00:51:18.200 --> 00:51:21.340
increase fee, and then it will
rebroadcast with an increased

00:51:21.340 --> 00:51:22.900
fee.

00:51:22.900 --> 00:51:29.110
OK, so yeah, it's a kind of a
mess, but it's getting there.

00:51:29.110 --> 00:51:31.300
We're getting better at this.

00:51:31.300 --> 00:51:35.230
Any questions before
we have a break?

00:51:35.230 --> 00:51:35.730
Yes.

00:51:35.730 --> 00:51:38.350
AUDIENCE: So the one
[INAUDIBLE] they'd

00:51:38.350 --> 00:51:40.842
pay [INAUDIBLE] their own
confirmation of transaction.

00:51:40.842 --> 00:51:42.800
TADGE DRYJA: Well,
eventually they will, right?

00:51:42.800 --> 00:51:43.980
AUDIENCE: [INAUDIBLE]

00:51:43.980 --> 00:51:45.630
TADGE DRYJA: Will
they eventually?

00:51:45.630 --> 00:51:47.297
AUDIENCE: Once it
gets the confirmation,

00:51:47.297 --> 00:51:49.460
but normally they
accept transactions

00:51:49.460 --> 00:51:50.460
without confirmation.

00:51:50.460 --> 00:51:51.835
TADGE DRYJA: That's
silly anyway.

00:51:51.835 --> 00:51:52.790
AUDIENCE: [INAUDIBLE]

00:51:52.790 --> 00:51:56.880
TADGE DRYJA: OK, well
yeah, so some sites

00:51:56.880 --> 00:52:01.200
will accept zero-conf
without RBF, but not with.

00:52:01.200 --> 00:52:03.210
My thinking is they
shouldn't be accepting

00:52:03.210 --> 00:52:06.630
zero-confirmation
transactions, regardless.

00:52:06.630 --> 00:52:08.190
So whatever.

00:52:08.190 --> 00:52:09.990
But yeah, and people--

00:52:09.990 --> 00:52:12.630
there was a thing,
Peter Todd stole $10

00:52:12.630 --> 00:52:15.060
from Coinbase a couple
years ago because he

00:52:15.060 --> 00:52:16.230
was trying to prove a point.

00:52:16.230 --> 00:52:20.070
It's so easy to double-spend
before it's in a block.

00:52:20.070 --> 00:52:21.810
And all these different
sites are saying,

00:52:21.810 --> 00:52:24.143
oh, yeah, here's a transaction
that's not confirmed yet,

00:52:24.143 --> 00:52:25.620
but it will be soon.

00:52:25.620 --> 00:52:28.653
And then they dispense
with the product.

00:52:28.653 --> 00:52:30.570
And then I remember Peter
Todd was like, look,

00:52:30.570 --> 00:52:34.120
I just got $10 from you
on Steam or whatever,

00:52:34.120 --> 00:52:35.070
do you want it back?

00:52:35.070 --> 00:52:36.600
And they didn't reply.

00:52:36.600 --> 00:52:38.220
Because it's really
not that hard to

00:52:38.220 --> 00:52:40.020
double-spend before
it's in a block.

00:52:40.020 --> 00:52:42.103
The whole point of the
blockchain, all the mining,

00:52:42.103 --> 00:52:44.310
is to prevent the double-spend.

00:52:44.310 --> 00:52:47.096
OK, so the last part
is going to be about--

00:52:47.096 --> 00:52:48.920
AUDIENCE: [INAUDIBLE]

00:52:48.920 --> 00:52:50.810
TADGE DRYJA: Oh yeah,
I already said this.

00:52:50.810 --> 00:52:53.330
One thing, though, is
further research is needed.

00:52:53.330 --> 00:52:56.390
This has all been
changing in the last year.

00:52:56.390 --> 00:52:58.495
If you had this talk a
year ago, it would sort of

00:52:58.495 --> 00:53:00.620
be like, yeah, I guess you
could do replace by fee,

00:53:00.620 --> 00:53:02.480
I guess fees could
work this way.

00:53:02.480 --> 00:53:07.640
But we had never really had this
sustained, long fee ramp-up.

00:53:07.640 --> 00:53:08.770
This hadn't happened.

00:53:08.770 --> 00:53:09.770
This had never happened.

00:53:09.770 --> 00:53:12.620
There had been cases where
sometimes blocks had been full,

00:53:12.620 --> 00:53:15.380
but we'd never
seen this ramp-up.

00:53:15.380 --> 00:53:17.420
It's also really
interesting how inelastic

00:53:17.420 --> 00:53:22.310
it was, in that
people started paying

00:53:22.310 --> 00:53:27.950
thousands of Satoshis per
byte, $20, $30 a transaction.

00:53:27.950 --> 00:53:30.230
And people got mad about
it, but what was interesting

00:53:30.230 --> 00:53:31.880
is people were paying.

00:53:31.880 --> 00:53:35.780
If everyone refuses to pay
these rates, the rates go down.

00:53:35.780 --> 00:53:38.870
But someone's paying that much.

00:53:38.870 --> 00:53:41.180
But a lot of it is
exchanges and stuff.

00:53:41.180 --> 00:53:45.680
OK, yeah, problems--
exchanges overpay.

00:53:45.680 --> 00:53:47.600
Bitcoin D Wallets overpays.

00:53:47.600 --> 00:53:49.250
Nobody cared for seven years.

00:53:49.250 --> 00:53:52.003
It's sort of like it's
also, efficiency-wise,

00:53:52.003 --> 00:53:53.420
in terms of your
transaction size,

00:53:53.420 --> 00:53:56.810
it kind of reminds me of 2008
when everyone was driving

00:53:56.810 --> 00:53:58.790
Hummers, and then gas
goes to like $4.00,

00:53:58.790 --> 00:54:01.820
and then everyone gets a Prius.

00:54:01.820 --> 00:54:03.980
That's happening now,
where it's like, OK,

00:54:03.980 --> 00:54:05.600
let's batch our transactions.

00:54:05.600 --> 00:54:09.290
Let's use compressed pub keys.

00:54:09.290 --> 00:54:11.390
There's all sorts of
techniques to reduce

00:54:11.390 --> 00:54:14.180
the size of your
transactions so more

00:54:14.180 --> 00:54:19.460
can fit in the block which are
now still being implemented.

00:54:19.460 --> 00:54:20.720
It's sort of after the fact.

00:54:20.720 --> 00:54:24.980
It takes this, hey, you're
spending thousands of dollars

00:54:24.980 --> 00:54:28.702
a day on this to really kick
people into action to write it.

00:54:28.702 --> 00:54:30.410
I remember looking
into December, though,

00:54:30.410 --> 00:54:33.350
at Coinbase's transactions
and being like,

00:54:33.350 --> 00:54:35.930
you should hire-- you guys
are probably losing $1 million

00:54:35.930 --> 00:54:37.340
a day.

00:54:37.340 --> 00:54:38.960
I could fix this for you.

00:54:38.960 --> 00:54:40.780
You should-- no?

00:54:40.780 --> 00:54:41.465
OK.

00:54:41.465 --> 00:54:42.950
[CHUCKLING]

00:54:42.950 --> 00:54:44.600
But it's sort of
frustrating to see.

00:54:44.600 --> 00:54:46.898
And probably, their
system is a huge mess

00:54:46.898 --> 00:54:49.440
from so many different layers
and things on top of each other

00:54:49.440 --> 00:54:50.357
that it's hard to fix.

00:54:50.357 --> 00:54:53.270
But looking at--

00:54:53.270 --> 00:54:54.740
Gemini also is an exchange.

00:54:54.740 --> 00:54:56.180
They use uncompressed pub keys.

00:54:56.180 --> 00:54:59.600
So the pub keys are 65
bytes instead of 33.

00:54:59.600 --> 00:55:01.340
There's no advantage there.

00:55:01.340 --> 00:55:03.480
It's just an extra 32 bytes.

00:55:03.480 --> 00:55:06.160
Which they've probably spent, I
don't know, a couple hundred K

00:55:06.160 --> 00:55:08.900
on just that weird
aspect of their software.

00:55:08.900 --> 00:55:10.960
I don't know if they're
aware of this, even.

00:55:10.960 --> 00:55:12.170
You might want to
be like, hey, guys,

00:55:12.170 --> 00:55:13.462
you're spending too much money.

00:55:13.462 --> 00:55:15.920
Because look, your transactions
are an extra 32 bytes

00:55:15.920 --> 00:55:18.530
per input because of this.

00:55:18.530 --> 00:55:21.800
But yeah, it's
interesting to see.

00:55:21.800 --> 00:55:23.360
I've also paid.

00:55:23.360 --> 00:55:25.190
I used to not pay.

00:55:25.190 --> 00:55:27.860
Oh, one thing that used to
be the case, transactions

00:55:27.860 --> 00:55:31.550
had priority, which
was based on the age

00:55:31.550 --> 00:55:35.100
of the outputs multiplied by
the amount of the outputs.

00:55:35.100 --> 00:55:39.010
That was a thing
until two years ago.

00:55:39.010 --> 00:55:41.280
And it was great because
it meant if you were rich,

00:55:41.280 --> 00:55:42.260
you didn't pay fees.

00:55:42.260 --> 00:55:43.020
[CHUCKLING]

00:55:43.020 --> 00:55:44.790
So if you had a
bunch of bitcoin,

00:55:44.790 --> 00:55:49.290
it was kind of a maybe
not-so-great social idea

00:55:49.290 --> 00:55:53.160
that, hey, if you have an output
that's got 100 coins in it,

00:55:53.160 --> 00:55:58.840
you can make a
zero-fee transaction.

00:55:58.840 --> 00:56:00.910
It actually worked from
a theoretical perspective

00:56:00.910 --> 00:56:02.770
because it prevented spam.

00:56:02.770 --> 00:56:05.590
Because the idea is, if
you have 100 coins, OK,

00:56:05.590 --> 00:56:10.198
you can spend that every day
or something, with no fee.

00:56:10.198 --> 00:56:11.740
If you have only
one coin, maybe have

00:56:11.740 --> 00:56:14.470
to wait 100 days to be able
to spend it with no fee.

00:56:14.470 --> 00:56:16.840
So there's this sort
of priority, age-based,

00:56:16.840 --> 00:56:20.710
to limit the velocity
of these payments

00:56:20.710 --> 00:56:22.870
based on how big they are.

00:56:22.870 --> 00:56:24.640
They got rid of
that because it made

00:56:24.640 --> 00:56:27.220
sense from a network
level, "let's protect

00:56:27.220 --> 00:56:29.410
the network from spam" idea.

00:56:29.410 --> 00:56:31.240
It did not make any
sense for the miners

00:56:31.240 --> 00:56:33.850
to prioritize
these transactions.

00:56:33.850 --> 00:56:36.497
I'm a miner, who cares if you
have a bunch of old outputs

00:56:36.497 --> 00:56:38.080
that you haven't
spent in a long time.

00:56:38.080 --> 00:56:40.990
It does nothing for me.

00:56:40.990 --> 00:56:42.490
It does help the
network in general.

00:56:42.490 --> 00:56:43.960
But so I was a
little disappointed,

00:56:43.960 --> 00:56:45.700
because I don't
have a ton of coins,

00:56:45.700 --> 00:56:48.587
but they're all really
old, so I could get away

00:56:48.587 --> 00:56:49.420
without paying fees.

00:56:52.990 --> 00:56:56.890
Long term though, this is
sort of an interesting thing

00:56:56.890 --> 00:56:58.780
to look at.

00:56:58.780 --> 00:57:00.180
I'm not sure that's--

00:57:00.180 --> 00:57:01.870
oh, shoot, is that number right?

00:57:01.870 --> 00:57:02.912
Wait, James, do you know?

00:57:02.912 --> 00:57:03.990
Is it 210,000?

00:57:03.990 --> 00:57:05.370
I think it is.

00:57:05.370 --> 00:57:06.990
That number might be wrong.

00:57:06.990 --> 00:57:09.765
I made a mental
note to confirm it.

00:57:09.765 --> 00:57:10.740
I think it's right.

00:57:10.740 --> 00:57:14.250
Anyway, the mining reward drops
in half, every four years,

00:57:14.250 --> 00:57:16.590
approximately.

00:57:16.590 --> 00:57:18.300
And eventually all
the coins are mined.

00:57:18.300 --> 00:57:20.640
So it's dropped in half twice.

00:57:20.640 --> 00:57:22.560
First it was 50 coins
a block, then 25,

00:57:22.560 --> 00:57:24.260
and now it's 12 and 1/2.

00:57:24.260 --> 00:57:28.410
In two years it's going
to be 6.25 or something.

00:57:28.410 --> 00:57:31.950
So eventually all the coins
are gone, you mined them all.

00:57:31.950 --> 00:57:33.200
That takes 100 years.

00:57:33.200 --> 00:57:35.100
So everyone's like,
I'll be dead--

00:57:35.100 --> 00:57:37.260
I'll be gone, you'll be gone.

00:57:37.260 --> 00:57:40.980
But actually the rewards
become negligible a lot sooner

00:57:40.980 --> 00:57:42.240
than you think.

00:57:42.240 --> 00:57:45.750
In 20 years, there's
way less than a coin

00:57:45.750 --> 00:57:48.180
in rewards, because it
keeps getting chopped

00:57:48.180 --> 00:57:49.950
in half every four years.

00:57:49.950 --> 00:57:51.780
so yeah, there's this
sort of long tail

00:57:51.780 --> 00:57:55.470
where you've got like 50 years
of a couple Satoshis per block.

00:57:55.470 --> 00:57:57.760
But it's negligible, right?

00:57:57.760 --> 00:58:01.060
So the rewards going
to near zero actually

00:58:01.060 --> 00:58:03.970
happens definitely within
our lifetimes, pretty soon.

00:58:03.970 --> 00:58:05.710
And a lot of people
looking at Bitcoin

00:58:05.710 --> 00:58:07.252
are sort of thinking
of it long term.

00:58:09.832 --> 00:58:11.290
Bitcoin's only
worth a lot of money

00:58:11.290 --> 00:58:12.748
now because people
think it's going

00:58:12.748 --> 00:58:14.770
to be worth a lot of
money in 20 years, right?

00:58:14.770 --> 00:58:17.050
If everyone knew it was going
to collapse in 10 years,

00:58:17.050 --> 00:58:20.280
I think people
would lose interest.

00:58:20.280 --> 00:58:23.810
So what are some weird
long-term problems?

00:58:23.810 --> 00:58:27.110
OK, well if there's no new
coins to mine, why do you mine.

00:58:27.110 --> 00:58:31.880
Well, the title of this piece.

00:58:31.880 --> 00:58:33.980
However, it's not that simple.

00:58:36.790 --> 00:58:39.390
There's a lot of problems
with the fees being

00:58:39.390 --> 00:58:43.650
the only incentive, in that
TX fees are very variable.

00:58:43.650 --> 00:58:47.910
Without a backlog, the fees tend
to go to pretty close to zero.

00:58:47.910 --> 00:58:51.360
And if the fees are zero,
there's no reason to mine.

00:58:51.360 --> 00:58:53.530
All the new coins
have been generated,

00:58:53.530 --> 00:58:58.410
there's no fees in the
mempool, why am I running my--

00:58:58.410 --> 00:59:00.840
maybe you have a megabyte
worth of zero-fee transactions

00:59:00.840 --> 00:59:02.100
in the mempool.

00:59:02.100 --> 00:59:04.800
But as a miner, why am
I spending electricity

00:59:04.800 --> 00:59:05.490
to mine this?

00:59:05.490 --> 00:59:06.670
I get nothing.

00:59:06.670 --> 00:59:08.250
So the miners just turn off.

00:59:08.250 --> 00:59:10.170
That would be what
they should do.

00:59:10.170 --> 00:59:12.042
And you can see, yeah,
it's super variable.

00:59:12.042 --> 00:59:13.750
Maybe miners are like,
oh, this is great,

00:59:13.750 --> 00:59:15.000
we're making a ton of money.

00:59:15.000 --> 00:59:17.650
And then here they're
like, I guess wrap it up,

00:59:17.650 --> 00:59:21.475
close down the mining facility.

00:59:21.475 --> 00:59:23.725
And that could be a problem,
even on much shorter time

00:59:23.725 --> 00:59:27.960
scales, such as the time
scale of a single block.

00:59:27.960 --> 00:59:31.110
So for example,
here's what you do.

00:59:31.110 --> 00:59:32.208
You're a miner.

00:59:32.208 --> 00:59:33.500
There's no fees in the mempool.

00:59:33.500 --> 00:59:34.410
There's no reward.

00:59:34.410 --> 00:59:35.900
There's no reason
to mine, right?

00:59:35.900 --> 00:59:37.640
Turn off your chips,
and then turn them

00:59:37.640 --> 00:59:39.485
back on once the mempool
starts filling up,

00:59:39.485 --> 00:59:40.610
because it will eventually.

00:59:40.610 --> 00:59:42.650
The idea is, OK, for the
next couple of minutes,

00:59:42.650 --> 00:59:45.540
I'm just idling.

00:59:45.540 --> 00:59:48.270
You could do that,
or you can be clever

00:59:48.270 --> 00:59:51.310
and say, well, I've
got all these chips,

00:59:51.310 --> 00:59:53.967
the opportunity cost,
a lot of it is CAPEX.

00:59:53.967 --> 00:59:55.800
A lot of is the capital
expense of the chips

00:59:55.800 --> 00:59:57.720
and not the electricity.

00:59:57.720 --> 00:59:59.460
So if I'm just
turning off my chips,

00:59:59.460 --> 01:00:00.570
that's a huge loss for me.

01:00:00.570 --> 01:00:01.890
I want to run.

01:00:01.890 --> 01:00:04.140
I don't want to run
with an empty mempool,

01:00:04.140 --> 01:00:05.340
because I get nothing.

01:00:05.340 --> 01:00:07.400
What should I do?

01:00:07.400 --> 01:00:08.600
What's a fun attack?

01:00:11.120 --> 01:00:11.680
Yeah.

01:00:11.680 --> 01:00:13.961
AUDIENCE: Could you make
a bunch of transactions

01:00:13.961 --> 01:00:15.961
where the fees are high,
and the new people will

01:00:15.961 --> 01:00:17.560
leave when the fees are high?

01:00:17.560 --> 01:00:18.727
TADGE DRYJA: Very good idea.

01:00:18.727 --> 01:00:22.870
I'm pretty sure miners are
doing that, or were in November.

01:00:22.870 --> 01:00:24.130
That doesn't help you--

01:00:24.130 --> 01:00:26.290
that helps you sort
of medium-term, right?

01:00:26.290 --> 01:00:28.450
In the very short
term, where there's

01:00:28.450 --> 01:00:30.212
an empty mempool, what do I do?

01:00:30.212 --> 01:00:31.670
There is another
attack you can do.

01:00:31.670 --> 01:00:32.170
Yeah.

01:00:32.170 --> 01:00:34.435
AUDIENCE: You can just
mine in empty blocks.

01:00:34.435 --> 01:00:36.310
TADGE DRYJA: Yeah, but
I don't get any money.

01:00:36.310 --> 01:00:38.030
You could, but that's
not a fun attack.

01:00:38.030 --> 01:00:38.530
Yeah.

01:00:38.530 --> 01:00:41.670
AUDIENCE: You could build up
a bunch of non-transactions.

01:00:41.670 --> 01:00:43.600
TADGE DRYJA: Yeah, but
I want to get money.

01:00:43.600 --> 01:00:47.200
I want to get paid, there's
nothing in the mempool,

01:00:47.200 --> 01:00:48.539
where do I go?

01:00:48.539 --> 01:00:49.039
Yeah.

01:00:49.039 --> 01:00:50.581
AUDIENCE: Output to
another currency.

01:00:50.581 --> 01:00:51.940
TADGE DRYJA: OK, so yes.

01:00:51.940 --> 01:00:55.225
So in Bitcoin's
case, the algorithm--

01:00:55.225 --> 01:00:57.100
well now there's Bitcoin
Cash, and so there's

01:00:57.100 --> 01:01:00.740
sort of two chains that
share a single algorithm.

01:01:00.740 --> 01:01:03.730
And in many alt coins, they
share either algorithms

01:01:03.730 --> 01:01:06.700
or they're using a GPU,
which can be quickly switched

01:01:06.700 --> 01:01:08.770
between different
mining algorithms.

01:01:08.770 --> 01:01:11.420
In Bitcoin's case, though,
you're sort of stuck.

01:01:11.420 --> 01:01:14.840
It's a big one, and
you're using Sha256.

01:01:14.840 --> 01:01:16.884
So OK, good.

01:01:16.884 --> 01:01:19.128
AUDIENCE: You could
mine off the previous--

01:01:19.128 --> 01:01:20.920
TADGE DRYJA: Yeah, you
go back to the past.

01:01:20.920 --> 01:01:23.950
You mine the past transactions.

01:01:23.950 --> 01:01:26.650
OK, someone mined a bunch
of transactions here,

01:01:26.650 --> 01:01:28.850
and they got two bitcoins.

01:01:28.850 --> 01:01:31.220
Those are two bitcoins
I could've mined.

01:01:31.220 --> 01:01:32.460
[CHUCKLING]

01:01:32.460 --> 01:01:36.140
So that last block at a
couple of coins in fees.

01:01:36.140 --> 01:01:37.566
I'm going to remine it.

01:01:37.566 --> 01:01:40.920
I'm not getting anything if I
mine-- if I continue the chain

01:01:40.920 --> 01:01:42.810
and make progress,
I get no money.

01:01:42.810 --> 01:01:46.170
But if I try to snipe the
last guy's mining stuff,

01:01:46.170 --> 01:01:49.200
I might be able
to take his money.

01:01:49.200 --> 01:01:51.870
If you find two blocks
in a row, which happens,

01:01:51.870 --> 01:01:53.500
you get all the fees.

01:01:53.500 --> 01:01:55.760
So that's sort of an
optimal thing to do.

01:01:55.760 --> 01:01:58.080
I've got all this
mining power, maybe

01:01:58.080 --> 01:02:01.417
I turn it off because I'm
mostly OPEX instead of CAPEX.

01:02:01.417 --> 01:02:03.000
But if I've got all
this mining power,

01:02:03.000 --> 01:02:06.090
I'm going to use it no matter
what, the optimal thing to do

01:02:06.090 --> 01:02:08.580
is try to take a
reorg the blockchain

01:02:08.580 --> 01:02:11.080
and take the last person's fees.

01:02:11.080 --> 01:02:13.930
So for example, instead
of sequentially building,

01:02:13.930 --> 01:02:14.680
you fight over it.

01:02:14.680 --> 01:02:16.410
So here's this blockchain.

01:02:16.410 --> 01:02:19.060
OK, Alice got two, Bob
got three, Carol got two,

01:02:19.060 --> 01:02:19.780
Dave got one.

01:02:19.780 --> 01:02:22.000
These are fees within the block.

01:02:22.000 --> 01:02:24.440
And now the current
mempool, it's zero.

01:02:24.440 --> 01:02:24.940
Dave got it.

01:02:24.940 --> 01:02:26.700
Dave swept it.

01:02:26.700 --> 01:02:28.730
It was sort of declining,
sort of going up.

01:02:28.730 --> 01:02:30.670
Dave completely
emptied the mempool.

01:02:30.670 --> 01:02:31.870
There's nothing in there.

01:02:31.870 --> 01:02:33.850
And there's no new
coins coming out.

01:02:33.850 --> 01:02:37.350
So I'm what, Eve,
I'm the attacker.

01:02:37.350 --> 01:02:41.940
Eve is always the
bad person, right?

01:02:41.940 --> 01:02:47.090
So what's also even better, I
say, OK, I'm going to build--

01:02:47.090 --> 01:02:49.560
I'm going to try
to reorg out Carol.

01:02:49.560 --> 01:02:51.780
I can take all the fees here.

01:02:51.780 --> 01:02:54.360
I can take the two bitcoins
here and the one bitcoin here,

01:02:54.360 --> 01:02:56.220
and I can mine it
into this block.

01:02:56.220 --> 01:02:57.960
This block is not
valid yet, right?

01:02:57.960 --> 01:02:59.010
This is higher.

01:02:59.010 --> 01:03:02.090
But I might build
another block here.

01:03:02.090 --> 01:03:03.840
And then I might build
another block here.

01:03:03.840 --> 01:03:05.940
And by now there
might be some coins.

01:03:05.940 --> 01:03:07.350
So now I get four coins.

01:03:07.350 --> 01:03:09.790
I could have mined here
and gotten nothing.

01:03:09.790 --> 01:03:12.820
If this happens and I pull
it off, "puh-toom," OK,

01:03:12.820 --> 01:03:15.800
Carol and Dave's
coins are now mine.

01:03:15.800 --> 01:03:17.615
So this is a--

01:03:17.615 --> 01:03:19.910
And to some extent,
you might think, well,

01:03:19.910 --> 01:03:21.940
whatever, it's a little
messy, but this is not

01:03:21.940 --> 01:03:23.290
the worst thing in the world.

01:03:23.290 --> 01:03:24.520
You still make progress.

01:03:24.520 --> 01:03:26.050
It's actually really bad.

01:03:26.050 --> 01:03:29.740
Because you're now trading
this sort of memoryless process

01:03:29.740 --> 01:03:31.930
where everyone's competing
on a level playing ground

01:03:31.930 --> 01:03:35.770
where whoever can mine fastest
is always going to win here.

01:03:35.770 --> 01:03:40.318
So now if you're a miner that's
twice as big as the next guy,

01:03:40.318 --> 01:03:42.610
you're always going to be
able to do this-- not always,

01:03:42.610 --> 01:03:43.750
there's still some--

01:03:43.750 --> 01:03:47.950
but this really
reduces the variance

01:03:47.950 --> 01:03:50.590
and really incentivizes
the miners to consolidate.

01:03:50.590 --> 01:03:53.470
And you're going to
end up with a monopoly

01:03:53.470 --> 01:03:56.598
in this kind of a scenario,
because small players will just

01:03:56.598 --> 01:03:57.640
always get a reorged out.

01:04:00.960 --> 01:04:03.072
Yeah, so the question--
is this an attack?

01:04:03.072 --> 01:04:05.280
It seems like they're just
trying to get paid, right?

01:04:07.968 --> 01:04:10.010
The whole idea is you're
not trusting the miners.

01:04:10.010 --> 01:04:11.900
You're just assuming
that they're acting

01:04:11.900 --> 01:04:13.468
in their economic interests.

01:04:13.468 --> 01:04:16.010
To some extent, you could say,
well, if they keep doing this,

01:04:16.010 --> 01:04:18.000
they reduce the
utility of Bitcoin,

01:04:18.000 --> 01:04:20.180
and so it's bad
for their holdings.

01:04:20.180 --> 01:04:25.460
Yeah, maybe, but it
looks dangerous, right?

01:04:25.460 --> 01:04:27.920
However, this isn't a problem.

01:04:27.920 --> 01:04:29.930
We don't see this problem today.

01:04:29.930 --> 01:04:32.770
There have actually been several
cases where we should have,

01:04:32.770 --> 01:04:34.770
where it would have been
optimal for the miners.

01:04:34.770 --> 01:04:37.430
So someone made a fee
that was like 1,000--

01:04:37.430 --> 01:04:39.765
no, it was 400
bitcoins or something.

01:04:39.765 --> 01:04:40.640
They just screwed up.

01:04:40.640 --> 01:04:44.180
They made a
transaction, and they

01:04:44.180 --> 01:04:45.680
were spending like
1,000 bitcoins

01:04:45.680 --> 01:04:47.570
and they only sent like
600 out or something.

01:04:47.570 --> 01:04:49.570
So the fee was 400
bitcoins, which is like,

01:04:49.570 --> 01:04:51.650
hey, that's way
more than a block.

01:04:51.650 --> 01:04:52.960
That's millions of dollars.

01:04:52.960 --> 01:04:54.710
It wasn't when it was
millions of dollars,

01:04:54.710 --> 01:04:56.180
but it's still a ton of money.

01:04:56.180 --> 01:04:58.280
And the miners, if
they were rational,

01:04:58.280 --> 01:04:59.742
they should have
all just stopped

01:04:59.742 --> 01:05:01.700
and all tried to fight
each other over that one

01:05:01.700 --> 01:05:03.890
block and that one
transaction, because it's

01:05:03.890 --> 01:05:07.770
so much more valuable than
progressing the chain.

01:05:07.770 --> 01:05:09.740
However, they didn't,
because they were just

01:05:09.740 --> 01:05:12.470
running their software.

01:05:12.470 --> 01:05:15.070
They weren't anticipating
this kind of thing.

01:05:15.070 --> 01:05:17.998
However, if this becomes,
long term, the general state

01:05:17.998 --> 01:05:20.040
of the network, they'll
definitely anticipate it,

01:05:20.040 --> 01:05:22.470
and they'll write the
software to do this.

01:05:22.470 --> 01:05:24.750
So it's not a problem
when there's low reward

01:05:24.750 --> 01:05:26.190
variance from block to block.

01:05:26.190 --> 01:05:28.980
If every block-- if the
next block coming out

01:05:28.980 --> 01:05:30.875
has about the same
fees as the last one,

01:05:30.875 --> 01:05:32.250
then you just keep
building on it

01:05:32.250 --> 01:05:35.580
and you're not trying to snipe
other people in the past.

01:05:35.580 --> 01:05:37.830
But that means there's
going to be a backlog.

01:05:37.830 --> 01:05:40.830
You need this really big
mempool with a large backlog

01:05:40.830 --> 01:05:43.380
of transactions
to ensure that you

01:05:43.380 --> 01:05:48.640
have low variance in the rewards
and to ensure that, long term,

01:05:48.640 --> 01:05:50.750
you've got a stable system.

01:05:50.750 --> 01:05:53.070
So this is tricky.

01:05:53.070 --> 01:05:54.800
This is a hard problem.

01:05:54.800 --> 01:05:57.890
Because you've already got
these sort of scalability

01:05:57.890 --> 01:06:00.500
balances in Bitcoin.

01:06:00.500 --> 01:06:04.400
One of them is related
to your hardware.

01:06:04.400 --> 01:06:07.460
So if you say, OK, we're going
to make the block size really

01:06:07.460 --> 01:06:10.250
small, we're going to make
the block size 10 kilobytes,

01:06:10.250 --> 01:06:13.490
so you can only have a few
transactions every 10 minutes,

01:06:13.490 --> 01:06:15.530
if it's too small,
then very few people

01:06:15.530 --> 01:06:18.620
can actually use Bitcoin.

01:06:18.620 --> 01:06:20.780
There's just not that many
transactions a second.

01:06:20.780 --> 01:06:22.697
Most people will have
something like Coinbase,

01:06:22.697 --> 01:06:24.740
where someone else holds
the coins for them.

01:06:24.740 --> 01:06:25.520
That's no fun.

01:06:25.520 --> 01:06:27.202
The point is to
have your own UTXO,

01:06:27.202 --> 01:06:28.910
so really be in control
of your own money

01:06:28.910 --> 01:06:31.430
and have your own private keys.

01:06:31.430 --> 01:06:33.710
However, if the
blocks are too large,

01:06:33.710 --> 01:06:36.170
then not many people can run it.

01:06:36.170 --> 01:06:38.150
If the blocks are
a gigabyte each

01:06:38.150 --> 01:06:42.080
and you've got these
petabyte-sized blockchains,

01:06:42.080 --> 01:06:43.190
I can't run that.

01:06:43.190 --> 01:06:45.050
I need a data center.

01:06:45.050 --> 01:06:47.510
And then you can't really
verify and validate

01:06:47.510 --> 01:06:50.390
that the system is operating
the way you think it will.

01:06:50.390 --> 01:06:52.550
You're just going to
have to trust, again,

01:06:52.550 --> 01:06:54.860
some kind of big institution
to do it for you.

01:06:54.860 --> 01:06:56.900
So they both sort of
turn into the same thing

01:06:56.900 --> 01:06:58.400
when you're at the extremes.

01:06:58.400 --> 01:07:00.903
If it's too small, well, I
can't really own my own coins,

01:07:00.903 --> 01:07:02.570
I got to have someone
else do it for me.

01:07:02.570 --> 01:07:05.120
If it's too large, I guess I
can own my own private keys,

01:07:05.120 --> 01:07:07.537
but I have no idea
if they're actually--

01:07:07.537 --> 01:07:09.620
if there's an actual
transaction in the blockchain

01:07:09.620 --> 01:07:12.980
because I can't download it.

01:07:12.980 --> 01:07:15.440
So these are sort of
balances based on hardware.

01:07:15.440 --> 01:07:19.160
And we're thinking, well, as
computers get more powerful

01:07:19.160 --> 01:07:21.260
and networks get more
powerful, we can sort of

01:07:21.260 --> 01:07:24.500
get into the larger side
and people will still

01:07:24.500 --> 01:07:25.563
be able to run it.

01:07:25.563 --> 01:07:26.480
And we have seen that.

01:07:26.480 --> 01:07:29.060
So like with SegWit,
the block size

01:07:29.060 --> 01:07:30.800
has been increased
through software.

01:07:30.800 --> 01:07:33.770
So it now takes a bit more
space and more network traffic

01:07:33.770 --> 01:07:36.040
to use.

01:07:36.040 --> 01:07:38.650
However, the long-term
fee sniping thing,

01:07:38.650 --> 01:07:40.180
it's not hardware related.

01:07:40.180 --> 01:07:42.460
Even if you had
perfect computers that

01:07:42.460 --> 01:07:44.380
were sort of like, oh,
this network can send

01:07:44.380 --> 01:07:47.560
any amount of data instantly,
we've got unlimited drive

01:07:47.560 --> 01:07:51.160
space, these are computronium--

01:07:51.160 --> 01:07:55.550
that's a thing, right, the
theoretical maximum computer.

01:07:55.550 --> 01:07:57.400
So even if you have
this amazing computer

01:07:57.400 --> 01:07:59.920
and the hardware limits
are not a limit at all,

01:07:59.920 --> 01:08:03.610
you still have to
balance the block size.

01:08:03.610 --> 01:08:06.110
Because if you make your
block size too large,

01:08:06.110 --> 01:08:08.225
you're going to have that
problem long term, where

01:08:08.225 --> 01:08:10.600
there's no real fee market
because there's no competition

01:08:10.600 --> 01:08:12.100
to get into the blocks.

01:08:12.100 --> 01:08:16.600
And so the whole system kinds
of halts, and then you've

01:08:16.600 --> 01:08:19.060
got the largest miner
just keep winning.

01:08:19.060 --> 01:08:23.220
So this is a mess.

01:08:23.220 --> 01:08:25.752
There's a paper.

01:08:25.752 --> 01:08:26.460
What's it called?

01:08:30.000 --> 01:08:34.183
Like, Bitcoin Is Not Stable
Without a Fee or something.

01:08:34.183 --> 01:08:36.175
It's Princeton guys, right?

01:08:45.830 --> 01:08:49.430
"On the Instability of Bitcoin
Without the Block Reward."

01:08:49.430 --> 01:08:52.189
And to be fair--

01:08:52.189 --> 01:08:53.590
yeah, these are Princeton guys.

01:08:53.590 --> 01:08:58.930
To be fair-- and they
write about this issue.

01:08:58.930 --> 01:09:02.680
But it's a little weird,
because one of their assumptions

01:09:02.680 --> 01:09:04.060
is that--

01:09:04.060 --> 01:09:05.569
mining strategy simulator.

01:09:05.569 --> 01:09:09.790
Anyway, one of their assumptions
is that every miner completely

01:09:09.790 --> 01:09:12.370
wipes out the mempool
at every block.

01:09:12.370 --> 01:09:14.500
And it's like, wait,
that assumption--

01:09:14.500 --> 01:09:17.202
given that assumption, yes,
you can show that it's unstable

01:09:17.202 --> 01:09:19.660
and there's all these problems,
like I was sort of showing.

01:09:19.660 --> 01:09:22.330
But that assumption
is a huge assumption.

01:09:22.330 --> 01:09:24.475
And a lot of the people
working on Bitcoin

01:09:24.475 --> 01:09:26.350
are like, no, you can't
make that assumption.

01:09:26.350 --> 01:09:29.649
Because we're aware that there's
these instability problems,

01:09:29.649 --> 01:09:33.760
and the solution, to the extent
that it's a solution, is always

01:09:33.760 --> 01:09:35.319
have a backlog.

01:09:35.319 --> 01:09:38.680
There's a really big
demand for transactions,

01:09:38.680 --> 01:09:40.240
and there's not
enough space, and so

01:09:40.240 --> 01:09:43.450
people have to compete
based on their fees.

01:09:43.450 --> 01:09:46.000
In that case, you can have
a stable system, long term,

01:09:46.000 --> 01:09:47.109
where the miners get paid.

01:09:47.109 --> 01:09:49.859
But without it,
these guys show it.

01:09:49.859 --> 01:09:52.890
And so yeah, it's true,
but it's sort of weird

01:09:52.890 --> 01:09:54.600
because one of
their assumptions is

01:09:54.600 --> 01:09:59.160
that there are no fees,
long term, essentially.

01:09:59.160 --> 01:10:04.950
So yeah, this is a weird issue,
and it's also how, timing-wise,

01:10:04.950 --> 01:10:06.600
do we need to worry
about this now?

01:10:06.600 --> 01:10:08.937
Maybe we can just punt
the problem for a decade

01:10:08.937 --> 01:10:11.520
and try to get lots of adoption,
lots of people using Bitcoin,

01:10:11.520 --> 01:10:14.478
and we'll figure it out once
it's really well established.

01:10:14.478 --> 01:10:15.520
I don't think that works.

01:10:15.520 --> 01:10:17.770
I think it's harder and
harder to change these systems

01:10:17.770 --> 01:10:19.530
as more people use it.

01:10:19.530 --> 01:10:21.300
So maybe we're stuck.

01:10:21.300 --> 01:10:24.120
And it's almost certain that
one megabyte or four megabytes

01:10:24.120 --> 01:10:25.900
is not the optimal size.

01:10:25.900 --> 01:10:27.900
We have no idea what the
optimal size is, right?

01:10:27.900 --> 01:10:29.700
Long term-- because
also, long term,

01:10:29.700 --> 01:10:31.367
how many people are
going to using this,

01:10:31.367 --> 01:10:34.330
and for what, and for
what kind of transactions?

01:10:34.330 --> 01:10:38.000
So it's definitely
an open problem.

01:10:38.000 --> 01:10:42.570
Yeah, so we're sort of
at the dawn of the fees.

01:10:42.570 --> 01:10:46.177
A year ago, we didn't
have all these things.

01:10:46.177 --> 01:10:48.010
We're starting to
understand the fee markets

01:10:48.010 --> 01:10:50.380
and see how it works.

01:10:50.380 --> 01:10:52.210
What's interesting is
that the elasticity

01:10:52.210 --> 01:10:54.880
seems like people really want
their transactions in when

01:10:54.880 --> 01:10:56.920
they want them in, which
I guess can make sense.

01:10:56.920 --> 01:11:00.505
If the price of Bitcoin
spikes to $18,000,

01:11:00.505 --> 01:11:03.130
and you're like, I want to
sell one, it's going to crash,

01:11:03.130 --> 01:11:05.230
and you're like, yeah,
I'll pay $50 to move it,

01:11:05.230 --> 01:11:08.080
to sell to someone, because
I'm selling millions of dollars

01:11:08.080 --> 01:11:09.710
worth.

01:11:09.710 --> 01:11:12.530
And so it seems
really inelastic.

01:11:12.530 --> 01:11:15.860
You also have people,
companies, wasting millions

01:11:15.860 --> 01:11:18.680
of dollars on fees that you can
just be like, why'd you do--

01:11:18.680 --> 01:11:20.780
oh, OK.

01:11:20.780 --> 01:11:23.900
You're wasting on
space, wasting on fees.

01:11:23.900 --> 01:11:25.602
It is a fun research area.

01:11:25.602 --> 01:11:26.810
And it's definitely research.

01:11:26.810 --> 01:11:28.490
And so I'm like, yeah,
I hope this works.

01:11:28.490 --> 01:11:30.950
We don't really know, long term,
if this whole system is stable

01:11:30.950 --> 01:11:31.450
and works.

01:11:33.950 --> 01:11:35.120
I think it can.

01:11:35.120 --> 01:11:40.940
But it's not something to base
the global economy on just yet,

01:11:40.940 --> 01:11:44.750
because we're not quite sure
it all really works long term,

01:11:44.750 --> 01:11:47.050
but we think it does.

01:11:47.050 --> 01:11:50.347
OK, any questions about this
sort of long-range attack

01:11:50.347 --> 01:11:50.847
stuff?

01:11:54.050 --> 01:11:54.730
Yes.

01:11:54.730 --> 01:11:57.385
AUDIENCE: What's the case
with a bunch alt coins points

01:11:57.385 --> 01:11:59.900
that don't have full members?

01:11:59.900 --> 01:12:01.150
TADGE DRYJA: Alt coins?

01:12:01.150 --> 01:12:03.100
AUDIENCE: The rest of
the cryptocurrency space

01:12:03.100 --> 01:12:05.360
that has sparse mempools.

01:12:05.360 --> 01:12:07.940
TADGE DRYJA: They
generally don't have fees,

01:12:07.940 --> 01:12:10.953
or the fees are enforced--

01:12:10.953 --> 01:12:11.870
you can enforce a fee.

01:12:11.870 --> 01:12:15.800
You can say, hey, the consensus
rule of this system is that

01:12:15.800 --> 01:12:21.990
every transaction has to have
a 50-Satoshis-per-byte fee.

01:12:21.990 --> 01:12:24.360
There's problems with
that, because then you

01:12:24.360 --> 01:12:27.210
can have out-of-band
fees where, if you

01:12:27.210 --> 01:12:30.960
try to make it a consensus
rule, it doesn't really work.

01:12:30.960 --> 01:12:33.150
It's sort of like price
controls, where you can say,

01:12:33.150 --> 01:12:36.600
hey, you have to sell
milk for $2 a gallon.

01:12:36.600 --> 01:12:39.030
And it's like, well, that's
not what the market says.

01:12:39.030 --> 01:12:40.238
So people can go out of band.

01:12:40.238 --> 01:12:42.197
And then they're saying,
OK, the consensus rule

01:12:42.197 --> 01:12:44.940
is I have to pay this fee, but
really, how about you give me

01:12:44.940 --> 01:12:46.170
some of it back?

01:12:46.170 --> 01:12:49.170
Or-- so generally
the rules they put

01:12:49.170 --> 01:12:50.850
in are minimum
fees, which you can

01:12:50.850 --> 01:12:53.730
try to work around that way.

01:12:53.730 --> 01:12:56.615
But in general, most of
the other alt coins--

01:12:56.615 --> 01:12:58.740
with the exception of
Ethereum, Ethereum definitely

01:12:58.740 --> 01:12:59.770
has similar issues--

01:12:59.770 --> 01:13:02.490
but most of the alt
coins have a block size

01:13:02.490 --> 01:13:05.190
or a network capacity
that exceeds their uses.

01:13:05.190 --> 01:13:07.410
So there isn't
really competition

01:13:07.410 --> 01:13:08.990
to get into the next block.

01:13:08.990 --> 01:13:13.350
Ethereum, though,
similar to Bitcoin, has--

01:13:13.350 --> 01:13:17.110
well, I don't-- where did it go?

01:13:17.110 --> 01:13:18.407
This kind of thing.

01:13:18.407 --> 01:13:19.990
I don't know, if you
graphed Ethereum,

01:13:19.990 --> 01:13:21.940
it probably wouldn't
look quite the same.

01:13:21.940 --> 01:13:24.820
But there are also
times in Ethereum

01:13:24.820 --> 01:13:27.530
where the fees skyrocket.

01:13:27.530 --> 01:13:29.360
A lot of times
with ICOs, everyone

01:13:29.360 --> 01:13:31.200
wants to get in their
bids really quick,

01:13:31.200 --> 01:13:34.130
and so the network will get
super congested for a day,

01:13:34.130 --> 01:13:37.190
and no one can use it for
anything-- for normal uses.

01:13:37.190 --> 01:13:39.120
So Ethereum also
has this problem.

01:13:39.120 --> 01:13:41.570
It's not quite the same in
that it's not a block size,

01:13:41.570 --> 01:13:44.080
it's a gas per
block kind of thing,

01:13:44.080 --> 01:13:46.220
so how much computation
or storage it's using.

01:13:46.220 --> 01:13:50.595
But in practice it's
a similar thing.

01:13:50.595 --> 01:13:52.220
So yeah, those are
sort of the only two

01:13:52.220 --> 01:13:56.840
that I'm aware of that really
have hit this issue so far.

01:13:59.640 --> 01:14:02.870
Any other questions about
this, the long term?

01:14:02.870 --> 01:14:04.170
Yes.

01:14:04.170 --> 01:14:06.870
AUDIENCE: Could you
comment on blockchains

01:14:06.870 --> 01:14:10.160
that have no transaction fee,
particularly blockchains that

01:14:10.160 --> 01:14:11.965
are designed for
things like IoT,

01:14:11.965 --> 01:14:15.145
and which pay to be able
to handle microtransactions

01:14:15.145 --> 01:14:19.953
and transactions at face
value without any fee.

01:14:19.953 --> 01:14:21.870
TADGE DRYJA: Should I
take advice from counsel

01:14:21.870 --> 01:14:23.370
before commenting on this?

01:14:23.370 --> 01:14:24.510
[LAUGHTER]

01:14:24.510 --> 01:14:26.292
Yeah, so you could Google--

01:14:26.292 --> 01:14:27.750
there's one, I
don't know if you're

01:14:27.750 --> 01:14:29.375
talking about it
specifically-- there's

01:14:29.375 --> 01:14:32.850
one called Iota that we
looked at last summer.

01:14:32.850 --> 01:14:35.310
My mom tells me, if you don't
have anything nice to say,

01:14:35.310 --> 01:14:36.540
don't say anything.

01:14:36.540 --> 01:14:42.240
But we did say quite
a bit in our report.

01:14:42.240 --> 01:14:43.740
That one specifically,
I don't think

01:14:43.740 --> 01:14:45.870
it really works that well.

01:14:45.870 --> 01:14:50.800
Actually, they have a fee,
they just pretend they don't.

01:14:50.800 --> 01:14:52.050
But they very much have a fee.

01:14:52.050 --> 01:14:53.970
So in Iota's case,
they say, you have

01:14:53.970 --> 01:14:55.520
to do work on your transaction.

01:14:55.520 --> 01:14:57.330
You have to mine
your transaction.

01:14:57.330 --> 01:14:58.620
And they say that's not a fee.

01:14:58.620 --> 01:15:01.140
Well, OK, it's on a fee you're
paying to some other miner,

01:15:01.140 --> 01:15:03.000
but you're still doing work.

01:15:03.000 --> 01:15:04.200
That has a cost.

01:15:04.200 --> 01:15:05.700
You can say it's
a cost, not a fee.

01:15:05.700 --> 01:15:06.600
I don't know.

01:15:06.600 --> 01:15:10.050
But it feels like saying, hey,
this refrigerator doesn't need

01:15:10.050 --> 01:15:12.900
electricity to run, it's just
got a hand crank in the back

01:15:12.900 --> 01:15:14.488
that you have to--

01:15:14.488 --> 01:15:16.030
yeah, OK, I don't
have to plug it in,

01:15:16.030 --> 01:15:19.410
but I still have
to do all the work.

01:15:19.410 --> 01:15:23.050
So it's an anti-spam measure
which you have to do work on.

01:15:23.050 --> 01:15:25.020
So it's the same new thing.

01:15:25.020 --> 01:15:27.540
But there are some that
have no fee whatsoever,

01:15:27.540 --> 01:15:29.850
and they're very
susceptible to spamming.

01:15:29.850 --> 01:15:32.670
If there's no fee, what stops
me from just sending out

01:15:32.670 --> 01:15:34.230
a bazillion
transactions and having

01:15:34.230 --> 01:15:35.850
everyone else store them?

01:15:35.850 --> 01:15:38.610
AUDIENCE: Generally
well MANO is one of them

01:15:38.610 --> 01:15:40.560
that claims to be instant
no fees, et cetera.

01:15:40.560 --> 01:15:43.050
But what that means
is, to get around that,

01:15:43.050 --> 01:15:45.915
they've made it so that you
don't need global consensus--

01:15:45.915 --> 01:15:48.460
until you do need global
consensus, at which point

01:15:48.460 --> 01:15:50.410
you do proof of state
and [INAUDIBLE]..

01:15:50.410 --> 01:15:52.850
But since there
are no fees, it's

01:15:52.850 --> 01:15:56.390
free to just calls for
state to happen every round,

01:15:56.390 --> 01:15:59.772
[INAUDIBLE] a bunch of
conflicting transactions.

01:15:59.772 --> 01:16:00.480
TADGE DRYJA: Huh.

01:16:00.480 --> 01:16:06.450
Yeah, there's a lot of really
smart people, way smarter

01:16:06.450 --> 01:16:08.430
than me, working
on these things.

01:16:08.430 --> 01:16:10.080
And it's a hard
problem, and they seem

01:16:10.080 --> 01:16:11.288
to think it's a hard problem.

01:16:11.288 --> 01:16:14.520
So I'm very skeptical
when someone, especially

01:16:14.520 --> 01:16:16.620
with a financial interest
in getting me to believe

01:16:16.620 --> 01:16:17.580
that they've solved
this problem,

01:16:17.580 --> 01:16:19.890
says, hey, I've solved
the problem, zero fees,

01:16:19.890 --> 01:16:21.180
infinite scalability.

01:16:21.180 --> 01:16:23.810
I'm just very skeptical
when I see that.

01:16:23.810 --> 01:16:25.325
Because, OK, what did you do?

01:16:25.325 --> 01:16:26.700
Like, we've been
looking at this.

01:16:26.700 --> 01:16:29.520
Maybe there's something there.

01:16:29.520 --> 01:16:33.873
But I haven't seen any
really great stuff.

01:16:33.873 --> 01:16:36.540
There's Lightning Network, which
I'll talk about in a few weeks,

01:16:36.540 --> 01:16:40.740
and I think that's pretty cool,
and I sort of work on that.

01:16:40.740 --> 01:16:43.860
There's other different
ways to do this.

01:16:43.860 --> 01:16:47.683
But in general, there's
got to be a cost.

01:16:47.683 --> 01:16:48.600
There's no free lunch.

01:16:48.600 --> 01:16:49.890
And you're going to have to--

01:16:49.890 --> 01:16:52.530
if you're requiring other
people to store a lot of data

01:16:52.530 --> 01:16:56.060
and process it, there's got to
be some kind of limit there.