WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode.

00:00:19.570 --> 00:00:21.950
<v Aaron van Wirdum>Live from Utrecht, this is Bitcoin

00:00:21.950 --> 00:00:23.330
<v Sjors Provoost>Explained.

00:00:23.630 --> 00:00:24.050
<v Aaron van Wirdum>Hey Sjors.

00:00:24.330 --> 00:00:24.870
<v Sjors Provoost>What's up?

00:00:25.510 --> 00:00:29.970
<v Aaron van Wirdum>How exciting. Two weeks ago you told me that maybe you would go to Bitcoin

00:00:29.970 --> 00:00:30.910
<v Aaron van Wirdum>Amsterdam.

00:00:31.330 --> 00:00:31.810
<v Sjors Provoost>Yes.

00:00:31.990 --> 00:00:32.830
<v Aaron van Wirdum>And now you're a speaker.

00:00:33.050 --> 00:00:36.330
<v Sjors Provoost>I'm a panelist. Probably. Not a real speaker.

00:00:36.970 --> 00:00:39.790
<v Aaron van Wirdum>That counts. That's a speaker in my book, Sjors.

00:00:40.050 --> 00:00:40.670
<v Sjors Provoost>Sounds good.

00:00:41.400 --> 00:00:46.940
<v Aaron van Wirdum>How exciting. Sjors, today we're going to discuss the blog post by BitMEX

00:00:46.940 --> 00:00:47.420
<v Aaron van Wirdum>Research.

00:00:47.740 --> 00:00:48.500
<v Sjors Provoost>That's right.

00:00:48.720 --> 00:00:50.660
<v Aaron van Wirdum>Which is about the OP_RETURN wars.

00:00:52.500 --> 00:00:54.620
<v Sjors Provoost>Exactly. Very nice clickbait title.

00:00:54.840 --> 00:01:00.290
<v Aaron van Wirdum>Do you remember what the name of the blog post is? Was it just the OP_RETURN wars?

00:01:00.470 --> 00:01:05.590
<v Sjors Provoost>It's called the OP_RETURN wars of 2014, dApps versus Bitcoin transactions.

00:01:06.700 --> 00:01:11.160
<v Sjors Provoost>And it's a slightly clickbaity title because, well, it was only called wars by

00:01:11.160 --> 00:01:12.860
<v Sjors Provoost>certain other people.

00:01:13.530 --> 00:01:18.510
<v Aaron van Wirdum>But wasn't it referred to as the OP_RETURN wars previously in your memory?

00:01:18.710 --> 00:01:22.890
<v Sjors Provoost>Yeah, but some people object that the OP_RETURN wars have been sort of that term

00:01:22.890 --> 00:01:27.970
<v Sjors Provoost>was phrased by people trying to launch various coins and trying to make Bitcoin

00:01:27.970 --> 00:01:28.970
<v Sjors Provoost>developers look bad.

00:01:29.290 --> 00:01:29.730
<v Aaron van Wirdum>Right.

00:01:29.790 --> 00:01:30.930
<v Sjors Provoost>Not everybody likes the term.

00:01:31.370 --> 00:01:37.140
<v Aaron van Wirdum>Okay, fair enough. Okay, so let's start at the beginning. This has been, we've

00:01:37.140 --> 00:01:42.460
<v Aaron van Wirdum>discussed this in some of our episodes here and there before, I think. But first

00:01:42.460 --> 00:01:44.120
<v Aaron van Wirdum>of all, Sjors, what is OP_RETURN?

00:01:44.240 --> 00:01:50.140
<v Sjors Provoost>So when OP_RETURN appears in a transaction, so in a script, then as soon as

00:01:50.140 --> 00:01:55.630
<v Sjors Provoost>that happens, the script is invalid. And so a nice example, and so the most

00:01:55.630 --> 00:01:59.030
<v Sjors Provoost>practical form to use that would be that your entire script starts with

00:01:59.030 --> 00:02:03.370
<v Sjors Provoost>OP_RETURN. And then it follows whatever you want to put there. For example, some

00:02:03.370 --> 00:02:07.310
<v Sjors Provoost>random text. Because when a script is invalid, you know it's not going to run.

00:02:07.650 --> 00:02:11.710
<v Sjors Provoost>And that means that nobody can ever spend it. Because no matter what you do, it's

00:02:11.710 --> 00:02:12.590
<v Sjors Provoost>always going to be invalid.

00:02:13.610 --> 00:02:17.870
<v Aaron van Wirdum>Right but that to me sounds like the transaction would be invalid.

00:02:17.870 --> 00:02:22.110
<v Sjors Provoost>Oh no no it's an output of a transaction. So if you're sending to an OP_RETURN

00:02:22.110 --> 00:02:26.170
<v Sjors Provoost>transaction so if you're sending if your address quote-unquote so the script on

00:02:26.170 --> 00:02:30.870
<v Sjors Provoost>the blockchain is an OP_RETURN followed by anything, then whoever tries

00:02:30.870 --> 00:02:34.050
<v Sjors Provoost>to spend it will find that their transaction is invalid.

00:02:34.050 --> 00:02:39.910
<v Aaron van Wirdum>Right okay so you can send to an OP_RETURN. It's just provably unspendable. You

00:02:39.910 --> 00:02:41.990
<v Aaron van Wirdum>can't spend anything from an OP_RETURN.

00:02:42.210 --> 00:02:42.450
<v Sjors Provoost>Exactly.

00:02:42.670 --> 00:02:44.990
<v Aaron van Wirdum>From an output that has OP_RETURN in it.

00:02:45.150 --> 00:02:49.490
<v Sjors Provoost>Yes, and because it's provably unspendable, that allows software that processes

00:02:49.490 --> 00:02:52.990
<v Sjors Provoost>the Bitcoin blockchain to make some optimizations. It can basically just pretend

00:02:52.990 --> 00:02:56.750
<v Sjors Provoost>that those coins don't exist. But whether they really exist or not is kind of in

00:02:56.750 --> 00:02:59.690
<v Sjors Provoost>the eye of the beholder. They're there, but it's impossible to spend them.

00:03:00.790 --> 00:03:06.670
<v Aaron van Wirdum>Right. An OP_RETURN has always been in Bitcoin? Has it always been... it's

00:03:06.670 --> 00:03:09.150
<v Aaron van Wirdum>a a function in Bitcoin. Has it always been possible?

00:03:09.150 --> 00:03:13.610
<v Sjors Provoost>As far as I know yes. And and so that means it's also been always been possible

00:03:13.610 --> 00:03:17.310
<v Sjors Provoost>to put anything you want after the OP_RETURN code right?

00:03:17.310 --> 00:03:21.670
<v Aaron van Wirdum>So you could always create a transaction with OP_RETURN. However and now we'll

00:03:21.670 --> 00:03:23.990
<v Aaron van Wirdum>get to this in a second I think originally…

00:03:25.470 --> 00:03:29.690
<v Aaron van Wirdum>Transactions that spend from an OP_RETURN. No, wait. Transactions that spend to?

00:03:29.890 --> 00:03:30.550
<v Aaron van Wirdum>Wait, now I'm confused.

00:03:30.550 --> 00:03:34.530
<v Sjors Provoost>Yeah, as far as I know, originally, if you created a transaction that spends to

00:03:34.530 --> 00:03:40.090
<v Sjors Provoost>an OP_RETURN, then nodes generally will not relay that transaction. They would

00:03:40.090 --> 00:03:44.710
<v Sjors Provoost>simply ignore it. However, if they saw it in a block, they would be fine with it.

00:03:44.850 --> 00:03:48.230
<v Sjors Provoost>So that's called standardness. In this case, it's not standard. So standard

00:03:48.230 --> 00:03:52.410
<v Sjors Provoost>transactions are transactions of a specific shape and form. Those are

00:03:52.410 --> 00:03:57.370
<v Sjors Provoost>automatically relayed. And that's partially to prevent people shooting themselves

00:03:57.370 --> 00:04:01.410
<v Sjors Provoost>in the foot by creating a transaction that's just wrong. And there's probably

00:04:01.410 --> 00:04:03.590
<v Sjors Provoost>some other reasons that we can get into in another podcast.

00:04:04.350 --> 00:04:10.050
<v Aaron van Wirdum>Right, yeah. So an OP_RETURN was always possible, but Bitcoin

00:04:10.050 --> 00:04:13.370
<v Aaron van Wirdum>nodes generally just wouldn't forward it to other nodes.

00:04:13.490 --> 00:04:13.750
<v Sjors Provoost>That's right.

00:04:13.770 --> 00:04:16.010
<v Aaron van Wirdum>So it's very hard to get it into an actual block.

00:04:16.170 --> 00:04:17.730
<v Sjors Provoost>Yeah, you'd have to talk to a miner.

00:04:18.400 --> 00:04:22.880
<v Aaron van Wirdum>Yeah, and then the miner would have to put it into a block because I assume that

00:04:22.880 --> 00:04:26.520
<v Aaron van Wirdum>mining software also by default just wouldn't include it in blocks, right?

00:04:26.920 --> 00:04:32.300
<v Sjors Provoost>Yeah, so either you would have to know which node is a miner and then maybe that

00:04:32.300 --> 00:04:37.020
<v Sjors Provoost>miner is configured that they do consider it standard, but more likely the miner

00:04:37.020 --> 00:04:39.220
<v Sjors Provoost>would have to manually include it through some process.

00:04:39.760 --> 00:04:45.620
<v Aaron van Wirdum>Right. So at some point, and this is what the blog post is about, at some

00:04:45.620 --> 00:04:50.840
<v Aaron van Wirdum>point it was decided that Bitcoin nodes, Bitcoin Core nodes specifically,

00:04:51.220 --> 00:04:55.020
<v Aaron van Wirdum>although back then it wasn't even called Bitcoin Core yet, they would actually

00:04:55.020 --> 00:04:59.440
<v Aaron van Wirdum>start forwarding some OP_RETURN transactions, right?

00:04:59.840 --> 00:04:59.980
<v Sjors Provoost>Yeah.

00:05:00.180 --> 00:05:00.960
<v Aaron van Wirdum>So why was that?

00:05:01.380 --> 00:05:06.320
<v Sjors Provoost>Yeah. So in roughly the end of 2013 or the beginning of 2014, there was a release

00:05:06.320 --> 00:05:11.250
<v Sjors Provoost>of Bitcoin Core that would let you... that if there was less than 40 bytes or 40

00:05:11.250 --> 00:05:15.450
<v Sjors Provoost>bytes or less after the OP_RETURN message it would be standard so you would relay

00:05:15.450 --> 00:05:20.260
<v Sjors Provoost>those And then later on, as we'll discuss, it was increased 80 bytes. And so the

00:05:20.260 --> 00:05:24.420
<v Sjors Provoost>reason is it was kind of, I think one of the analogies that was used, or many

00:05:24.420 --> 00:05:29.740
<v Sjors Provoost>analogies used, I'll stick to the, let's say the friendly ones, is this idea of

00:05:29.740 --> 00:05:33.620
<v Sjors Provoost>people were breaking windows all the time because they're trying to get inside of

00:05:33.620 --> 00:05:39.280
<v Sjors Provoost>a house. And it was nice to, you know, just leave the window open, basically. So

00:05:39.280 --> 00:05:41.900
<v Sjors Provoost>it was actually a form, it was meant as a form of damage control.

00:05:42.120 --> 00:05:46.800
<v Aaron van Wirdum>Well, before we get to the analogy. Well, now you've given the analogy, but what

00:05:46.800 --> 00:05:49.600
<v Aaron van Wirdum>is it an analogy for? What are we actually talking about?

00:05:49.820 --> 00:05:54.520
<v Sjors Provoost>What is the actual damage, right? Why were people breaking windows? So basically

00:05:54.520 --> 00:05:58.020
<v Sjors Provoost>people were trying to put things on the blockchain that are not transactions,

00:05:58.040 --> 00:06:02.960
<v Sjors Provoost>that are not moving money, but that are sharing information. And one example of

00:06:02.960 --> 00:06:07.360
<v Sjors Provoost>that, which I'll shamelessly plug, you can also find in my book, is to put the

00:06:07.360 --> 00:06:09.860
<v Sjors Provoost>Bitcoin white paper inside the blockchain.

00:06:10.100 --> 00:06:10.260
<v Aaron van Wirdum>Right.

00:06:10.580 --> 00:06:16.320
<v Sjors Provoost>And the way they would do that is to create a transaction that sends money to a

00:06:16.320 --> 00:06:21.810
<v Sjors Provoost>multisig address. And that multisig address would have three keys. But those

00:06:21.810 --> 00:06:25.290
<v Sjors Provoost>keys, you know, would not actually be keys because a public key would, you know,

00:06:25.350 --> 00:06:29.030
<v Sjors Provoost>be a nice piece of data, but they wouldn't be actual keys. And it turns out that

00:06:29.030 --> 00:06:32.490
<v Sjors Provoost>if you add up all these fake keys, you can reconstruct a Bitcoin white paper.

00:06:33.280 --> 00:06:38.060
<v Sjors Provoost>Now, the problem with that is that for nodes who are looking at the blockchain,

00:06:38.380 --> 00:06:42.480
<v Sjors Provoost>those transactions look like they're real. They look like they're really sending

00:06:42.480 --> 00:06:46.040
<v Sjors Provoost>money to somebody and that somebody apparently is a multisig owner.

00:06:47.930 --> 00:06:52.070
<v Sjors Provoost>This is where the problem comes in. Nodes don't only need to relay those

00:06:52.070 --> 00:06:55.290
<v Sjors Provoost>transactions and store them in the blockchain. They also need to keep track of

00:06:55.290 --> 00:07:00.360
<v Sjors Provoost>this thing called the UTXO set. So there's a set, usually kept in memory, if at

00:07:00.360 --> 00:07:05.420
<v Sjors Provoost>all possible, of every coin that currently exists. So when you create a

00:07:05.420 --> 00:07:08.180
<v Sjors Provoost>transaction, you're spending a coin, so those coins no longer exist and you're

00:07:08.180 --> 00:07:11.660
<v Sjors Provoost>creating new coins and those coins do exist. That's what you need to keep— keep

00:07:11.660 --> 00:07:16.700
<v Sjors Provoost>track of and so these… This white paper and this other stuff that was put in that

00:07:16.700 --> 00:07:21.380
<v Sjors Provoost>way has to be kept track of by nodes even today even though nobody will ever

00:07:21.380 --> 00:07:25.790
<v Sjors Provoost>spend it, you still have to keep track of it. And so the solution is to use

00:07:25.790 --> 00:07:30.230
<v Sjors Provoost>OP_RETURN now you can still put that kind of data on the blockchain if you wanted

00:07:30.230 --> 00:07:34.130
<v Sjors Provoost>to, but nodes don't have to keep track of it because they know it is not

00:07:34.130 --> 00:07:34.630
<v Sjors Provoost>spendable.

00:07:35.070 --> 00:07:37.530
<v Aaron van Wirdum>Right so to…

00:07:38.730 --> 00:07:43.790
<v Aaron van Wirdum>go one step back or tackle that step by step. So originally, if you wanted to

00:07:43.790 --> 00:07:47.610
<v Aaron van Wirdum>include data in the blockchain, could be any type of data, you gave the Bitcoin

00:07:47.610 --> 00:07:51.430
<v Aaron van Wirdum>white paper as an example, then what people would originally do is basically

00:07:51.430 --> 00:07:57.290
<v Aaron van Wirdum>break down the Bitcoin white paper into data and then create public keys that

00:07:57.290 --> 00:08:00.830
<v Aaron van Wirdum>aren't actually public keys because there are no private keys for them. And these

00:08:00.830 --> 00:08:04.390
<v Aaron van Wirdum>public keys would just include the data that is the Bitcoin white paper, right?

00:08:04.570 --> 00:08:04.790
<v Sjors Provoost>Yes.

00:08:05.210 --> 00:08:10.440
<v Aaron van Wirdum>Right. So and then... That's transmitted over the Bitcoin network. Everyone

00:08:10.440 --> 00:08:15.420
<v Aaron van Wirdum>verifies these as transactions. It's included in the blockchain. And then it's

00:08:15.420 --> 00:08:20.930
<v Aaron van Wirdum>also included in the UTXO set. Now, with OP_RETURN,

00:08:21.340 --> 00:08:23.480
<v Aaron van Wirdum>it's still included in the blockchain.

00:08:23.800 --> 00:08:24.040
<v Sjors Provoost>Yes.

00:08:24.640 --> 00:08:28.980
<v Aaron van Wirdum>However, it's not included in the UTXO set. That's the real difference there, right?

00:08:29.220 --> 00:08:29.500
<v Sjors Provoost>Yeah, exactly.

00:08:29.500 --> 00:08:33.860
<v Aaron van Wirdum>No, it's just no. These coins are provably unspendable, so we don't have to store

00:08:33.860 --> 00:08:35.520
<v Aaron van Wirdum>these in the UTXO set.

00:08:38.520 --> 00:08:42.080
<v Sjors Provoost>Yeah, so this saves some time because now when, you know, you still have to

00:08:42.080 --> 00:08:44.680
<v Sjors Provoost>download the blockchain, you still have to check every block. That does not

00:08:44.680 --> 00:08:47.640
<v Sjors Provoost>change. But the difference is that this little database that you're keeping of

00:08:47.640 --> 00:08:52.860
<v Sjors Provoost>the UTXO set, that no longer has to grow. And you can also normally throw away

00:08:52.860 --> 00:08:55.700
<v Sjors Provoost>old blocks. So if you have a small hard drive, you can always toss out the old

00:08:55.700 --> 00:08:58.220
<v Sjors Provoost>blocks, but you can never toss out anything from the UTXO set.

00:08:58.760 --> 00:09:02.940
<v Aaron van Wirdum>Yeah, so the two main benefits are, first of all, storage, especially for pruned

00:09:02.940 --> 00:09:07.650
<v Aaron van Wirdum>nodes that don't store the entire blockchain because they now have a benefit,

00:09:07.650 --> 00:09:12.870
<v Aaron van Wirdum>because they have a smaller UTXO set. And the other one is computational. When a

00:09:12.870 --> 00:09:17.690
<v Aaron van Wirdum>new transaction comes in, there's a smaller UTXO set to check the new transaction against.

00:09:17.970 --> 00:09:22.630
<v Sjors Provoost>Yeah, so I guess a better way to say that is it's potentially saving you memory.

00:09:23.170 --> 00:09:28.450
<v Sjors Provoost>So ideally, you want to keep the entire UTXO set in RAM. Now, that's already not

00:09:28.450 --> 00:09:33.270
<v Sjors Provoost>possible these days. I guess back when this discussion was happening, the UTXO

00:09:33.270 --> 00:09:38.510
<v Sjors Provoost>set may have been much smaller, maybe a few hundred megabytes. Now it is over 10

00:09:38.510 --> 00:09:43.230
<v Sjors Provoost>gigabytes. So for now, most people, unless you have like 20 gigabytes of RAM,

00:09:43.330 --> 00:09:46.630
<v Sjors Provoost>you're probably not holding it in RAM anyway. But it is nice. If you can keep the

00:09:46.630 --> 00:09:49.950
<v Sjors Provoost>UTXO set in RAM all the time, it's much faster. And we did an episode about that.

00:09:50.270 --> 00:09:56.200
<v Sjors Provoost>It is episode 15, in which we explain a mechanism that could solve this

00:09:56.200 --> 00:09:57.700
<v Sjors Provoost>problem called Utreexo.

00:09:58.560 --> 00:09:59.000
<v Aaron van Wirdum>Right.

00:09:59.260 --> 00:10:04.180
<v Sjors Provoost>And that would remove the need to keep the UTXO set in RAM, but it comes at the

00:10:04.180 --> 00:10:07.420
<v Sjors Provoost>expense of some trade-offs. And we just explained those there.

00:10:07.740 --> 00:10:10.100
<v Aaron van Wirdum>Okay, let's stick to the OP_RETURN for now.

00:10:10.280 --> 00:10:10.380
<v Sjors Provoost>Yeah.

00:10:10.580 --> 00:10:13.000
<v Aaron van Wirdum>So people were storing data in the blockchain.

00:10:14.880 --> 00:10:20.140
<v Aaron van Wirdum>This came at a cost for people that were running full nodes. And so at some point

00:10:20.140 --> 00:10:23.660
<v Aaron van Wirdum>developers figured, okay, look guys, if you're going to store data in the

00:10:23.660 --> 00:10:27.560
<v Aaron van Wirdum>blockchain anyways, then please use OP_RETURN, and that way

00:10:27.560 --> 00:10:31.600
<v Aaron van Wirdum>there's a—there's a smaller cost to all nodes.

00:10:31.810 --> 00:10:37.030
<v Sjors Provoost>Yeah, but there was a second request too, I would say, because this limit of 40 bytes.

00:10:37.150 --> 00:10:42.270
<v Aaron van Wirdum>Yeah, I was going to get there. So OP_RETURN was always in the protocol, but it

00:10:42.270 --> 00:10:47.070
<v Aaron van Wirdum>was basically useless because nodes wouldn't forward OP_RETURN transactions. And

00:10:47.070 --> 00:10:50.550
<v Aaron van Wirdum>then Bitcoin developers said, all right, guys, you're going to store data

00:10:50.550 --> 00:10:50.950
<v Aaron van Wirdum>anyways.

00:10:52.410 --> 00:10:57.470
<v Aaron van Wirdum>We'll allow, we'll effectively enable OP_RETURN. But then the next debate was

00:10:57.470 --> 00:10:59.850
<v Aaron van Wirdum>about the size of the OP_RETURN messages.

00:11:00.370 --> 00:11:04.630
<v Sjors Provoost>Yeah, exactly. So one number you could have used for that size was to say, okay,

00:11:04.730 --> 00:11:09.710
<v Sjors Provoost>how big can these multisig transactions be? And I think that was 172 bytes. So

00:11:09.710 --> 00:11:14.330
<v Sjors Provoost>you could have said, okay, we're just going to make OP_RETURN 172 bytes. Because

00:11:14.330 --> 00:11:17.950
<v Sjors Provoost>in that case, there is really no reason to use these multisig keys anymore,

00:11:17.950 --> 00:11:21.930
<v Sjors Provoost>because you might as well use OP_RETURN. But there was a simultaneous, I guess,

00:11:22.150 --> 00:11:27.550
<v Sjors Provoost>movement or desire to not make the blockchain unnecessarily big. And I think it's

00:11:27.550 --> 00:11:32.110
<v Sjors Provoost>useful to look at that in perspective. So right now, there is a fee market. So

00:11:32.110 --> 00:11:35.410
<v Sjors Provoost>that means that if you're putting a lot of data onto the blockchain, it's going

00:11:35.410 --> 00:11:38.930
<v Sjors Provoost>to be very expensive for you to do that. Or at least there's a mechanism to make

00:11:38.930 --> 00:11:43.150
<v Sjors Provoost>sure that useful stuff goes on the blockchain more easily than useless stuff,

00:11:43.210 --> 00:11:46.910
<v Sjors Provoost>depending on if you define useful by how much you're willing to pay for it. But

00:11:46.910 --> 00:11:50.910
<v Sjors Provoost>back then, blocks were super small. They were maybe 10 kilobytes or 100

00:11:50.910 --> 00:11:55.450
<v Sjors Provoost>kilobytes. I don't know where they were in 2014. And that meant that this

00:11:55.450 --> 00:11:59.520
<v Sjors Provoost>OP_RETURN data could just make blocks really big, for the time that happened. And

00:11:59.520 --> 00:12:02.880
<v Sjors Provoost>we've done an episode in the past where we looked at, I think it's episode number

00:12:02.880 --> 00:12:07.920
<v Sjors Provoost>55, where we looked at old Node software and see how that old Node software would

00:12:07.920 --> 00:12:12.320
<v Sjors Provoost>perform under the current block sizes. And it turns out that very old Node

00:12:12.320 --> 00:12:16.260
<v Sjors Provoost>software, especially from, say, 2012, would not have been able to keep up with

00:12:16.260 --> 00:12:22.040
<v Sjors Provoost>actual 1-megabyte blocks, or at least not very easily. So back then, it was

00:12:22.040 --> 00:12:25.580
<v Sjors Provoost>actually necessary to keep blocks small, basically from a more altruistic point

00:12:25.580 --> 00:12:29.120
<v Sjors Provoost>of view. And that's what a lot of the discussion was about. Like, what is good

00:12:29.120 --> 00:12:30.060
<v Sjors Provoost>behavior on the blockchain?

00:12:31.260 --> 00:12:31.740
<v Sjors Provoost>Yeah.

00:12:32.120 --> 00:12:38.020
<v Aaron van Wirdum>So why was, so the first limit that was set, well, initially the limit was zero.

00:12:38.280 --> 00:12:43.100
<v Aaron van Wirdum>Initially, OP_RETURN was effectively impossible. But then the limit was increased

00:12:43.100 --> 00:12:46.940
<v Aaron van Wirdum>to 40. And why was it increased to 40?

00:12:47.680 --> 00:12:52.950
<v Sjors Provoost>Okay, so the idea behind 40 is that it allows you to put a hash. In there, a

00:12:52.950 --> 00:12:58.820
<v Sjors Provoost>typical hash using normal cryptography like SHA-256 is 32 bytes. So

00:12:58.820 --> 00:13:02.240
<v Sjors Provoost>this allows you to put a 32 byte hash on the blockchain and then a few extra

00:13:02.240 --> 00:13:06.960
<v Sjors Provoost>bytes to do, I don't know, some metadata for that hash. Now, there were some

00:13:06.960 --> 00:13:10.920
<v Sjors Provoost>protocols out there that wanted 80 bytes.

00:13:10.920 --> 00:13:16.500
<v Aaron van Wirdum>Yeah Counterparty in specific. Yeah this is what sort of this blog post that

00:13:16.500 --> 00:13:20.180
<v Aaron van Wirdum>is the reason we're making this podcast, that's the main example that's given.

00:13:20.180 --> 00:13:22.420
<v Aaron van Wirdum>It's basically about the Counterparty protocol.

00:13:22.420 --> 00:13:26.640
<v Sjors Provoost>Yeah so I don't know for sure, if the increase to 80 bytes was only for

00:13:26.640 --> 00:13:30.060
<v Sjors Provoost>Counterparty or whether there was another protocol that needed it but basically

00:13:30.060 --> 00:13:34.140
<v Sjors Provoost>there was some back and forth, and and I guess people decided to just allow 80

00:13:34.140 --> 00:13:38.490
<v Sjors Provoost>bytes, but but really, 40 should be enough for most things, but it requires a

00:13:38.490 --> 00:13:42.530
<v Sjors Provoost>little bit more work for those protocols. So if you look at something like,

00:13:42.670 --> 00:13:47.810
<v Aaron van Wirdum>As far as I know, the reason 40 is enough is what you're saying is because really

00:13:47.810 --> 00:13:52.270
<v Aaron van Wirdum>the only data you ever need to include in the blockchain really is a hash.

00:13:52.450 --> 00:13:52.850
<v Sjors Provoost>Yes.

00:13:52.990 --> 00:13:56.190
<v Aaron van Wirdum>Because then you anchor any other data you want to anchor in. And that's really

00:13:56.190 --> 00:13:57.210
<v Aaron van Wirdum>all you ever need to do.

00:13:57.370 --> 00:14:00.670
<v Sjors Provoost>Yeah. So if you're building some sort of other protocol, and we talked about

00:14:00.670 --> 00:14:03.650
<v Sjors Provoost>OpenTimestamps in an earlier episode, we talked about other things. Generally,

00:14:03.830 --> 00:14:07.490
<v Sjors Provoost>that protocol has its own software and that software should take care of its own

00:14:07.490 --> 00:14:11.550
<v Sjors Provoost>data. It should have its own peer-to-peer network, essentially. It should send

00:14:11.550 --> 00:14:15.290
<v Sjors Provoost>its own data around. Maybe that data is a blockchain. Maybe that data is

00:14:15.290 --> 00:14:19.550
<v Sjors Provoost>something else. But that's more complicated to implement because now you have to

00:14:19.550 --> 00:14:23.850
<v Sjors Provoost>build your own peer-to-peer network. And so a lot of these protocols back in the

00:14:23.850 --> 00:14:27.510
<v Sjors Provoost>day, and very likely Counterparty as well, prefer to just shove everything onto

00:14:27.510 --> 00:14:31.570
<v Sjors Provoost>the Bitcoin blockchain and not have to deal with that complexity. And so that was

00:14:31.570 --> 00:14:37.330
<v Sjors Provoost>some of the discussion about. But Counterparty was using the multisig solution in

00:14:37.330 --> 00:14:42.410
<v Sjors Provoost>the beginning. So they were putting data on the blockchain anyway, and so yeah I

00:14:42.410 --> 00:14:45.710
<v Sjors Provoost>guess then it makes more sense to say, okay let's just increase the OP_RETURN

00:14:45.710 --> 00:14:49.020
<v Sjors Provoost>limit to 80 bytes so they stop doing that right.

00:14:49.020 --> 00:14:54.520
<v Aaron van Wirdum>So at first it was increased to 40. This was in 2014, and the argument there

00:14:54.520 --> 00:14:59.180
<v Aaron van Wirdum>as we explained what you explained, is that you really only need 40 because you

00:14:59.180 --> 00:15:05.090
<v Aaron van Wirdum>can just include a hash. But then people you say the Counterparty project it

00:15:05.090 --> 00:15:10.190
<v Aaron van Wirdum>was using more than 40, for whatever they want to do so essentially Bitcoin

00:15:10.190 --> 00:15:13.490
<v Aaron van Wirdum>developers conceded and said all right well if you're going to do it anyways,

00:15:14.980 --> 00:15:18.200
<v Aaron van Wirdum>here's 80 here have fun with it with your 80. You definitely…

00:15:18.200 --> 00:15:22.000
<v Sjors Provoost>I think that's how it went, but there may have been other projects there too that

00:15:22.000 --> 00:15:26.900
<v Sjors Provoost>needed 80s for some reason. Now there is some confusion because if you look at

00:15:26.900 --> 00:15:31.040
<v Sjors Provoost>the original proposal so the original release that had the 40 byte limit there

00:15:31.040 --> 00:15:35.620
<v Sjors Provoost>was also a pre-release so with Bitcoin or Bitcoin Core anyway nowadays what

00:15:35.620 --> 00:15:40.020
<v Sjors Provoost>happens is when you make changes they go into a pull request on GitHub. And then

00:15:40.020 --> 00:15:43.260
<v Sjors Provoost>once they're approved, they get merged and they end up in this master branch. And

00:15:43.260 --> 00:15:47.200
<v Sjors Provoost>this master branch is sort of a working copy, which is not released, but anybody

00:15:47.200 --> 00:15:52.940
<v Sjors Provoost>can run it. So there was a time when there was a limit of 80 if you were using

00:15:52.940 --> 00:15:55.900
<v Sjors Provoost>that master branch of Bitcoin. But generally, that's not considered final

00:15:55.900 --> 00:16:00.690
<v Sjors Provoost>software. It could have bugs in it, etc. So before that release came out, it was

00:16:00.690 --> 00:16:01.450
<v Sjors Provoost>reduced to 40.

00:16:02.980 --> 00:16:07.280
<v Sjors Provoost>Does that make sense? So there was a limit of 80, but only in unreleased

00:16:07.280 --> 00:16:10.660
<v Sjors Provoost>software. Then there was a limit of 40 in the release software. And then much

00:16:10.660 --> 00:16:16.140
<v Sjors Provoost>later, there was another limit of 80. And so some of the fight, war, whatever you

00:16:16.140 --> 00:16:18.280
<v Sjors Provoost>want to call it, seems to be about that.

00:16:18.660 --> 00:16:20.760
<v Aaron van Wirdum>Ah, yeah. They announced 80.

00:16:20.760 --> 00:16:23.360
<v Sjors Provoost>It was sort of seen as a revoking of the 80.

00:16:23.760 --> 00:16:24.080
<v Aaron van Wirdum>Right.

00:16:24.380 --> 00:16:25.640
<v Sjors Provoost>But that was never really released.

00:16:25.860 --> 00:16:30.460
<v Aaron van Wirdum>Right. Got it. It was never 80, but it was announced to be 80. And then it was

00:16:30.460 --> 00:16:33.780
<v Aaron van Wirdum>brought back to 40. And that's what threw some people off.

00:16:34.130 --> 00:16:38.350
<v Sjors Provoost>So I think what happened is there was this OP_RETURN thing was introduced in the

00:16:38.350 --> 00:16:42.570
<v Sjors Provoost>code and they just picked 80 as the first number. Then there was, I think Jeff

00:16:42.570 --> 00:16:45.050
<v Sjors Provoost>Garzik put it on the mailing list saying, hey, we should probably talk about

00:16:45.050 --> 00:16:49.510
<v Sjors Provoost>that. And then people said, okay, let's make it 40. And that was what went into

00:16:49.510 --> 00:16:49.970
<v Sjors Provoost>the release.

00:16:51.540 --> 00:16:56.620
<v Sjors Provoost>So, and then there's, you can find newer discussions where people said, oh, you

00:16:56.620 --> 00:17:00.100
<v Sjors Provoost>know, we told you about Counterparty. And then I think Greg Maxwell would say,

00:17:00.240 --> 00:17:04.640
<v Sjors Provoost>no, you didn't. You told us after basically this release and then we increased

00:17:04.640 --> 00:17:09.380
<v Sjors Provoost>it. But, you know, so that's a whole fight about what was the sequence of events there.

00:17:09.560 --> 00:17:11.980
<v Aaron van Wirdum>So, and right now the limit is 80.

00:17:12.940 --> 00:17:13.340
<v Sjors Provoost>Yes.

00:17:13.760 --> 00:17:18.080
<v Aaron van Wirdum>Yeah, and there was a minor maybe mistake in the blog post where it said that

00:17:18.080 --> 00:17:21.580
<v Aaron van Wirdum>currently the limit is 83, but you say it's just 80, right?

00:17:21.700 --> 00:17:27.400
<v Sjors Provoost>So the amount of data you can put on it is 80. However, the size of the

00:17:27.400 --> 00:17:32.040
<v Sjors Provoost>output, so what the script on the blockchain would look like, is 83. And the

00:17:32.040 --> 00:17:35.320
<v Sjors Provoost>reason is because you have one byte that says OP_RETURN, then you have another

00:17:35.320 --> 00:17:40.060
<v Sjors Provoost>byte that says, I'm going to give you a bunch of data now, and then another byte

00:17:40.060 --> 00:17:45.320
<v Sjors Provoost>that says how much data. So that that would be 80 bytes for example and then the

00:17:45.320 --> 00:17:49.940
<v Sjors Provoost>data itself so that in total that's 83. And there's some some weird edge cases

00:17:49.940 --> 00:17:54.420
<v Sjors Provoost>where you could have like one OP_RETURN and then say I'm gonna… And then you

00:17:54.420 --> 00:17:58.420
<v Sjors Provoost>could say I'm gonna give you five bytes of data and and now I'm gonna give you

00:17:58.420 --> 00:18:01.660
<v Sjors Provoost>another five bytes of data. So there's like ways of grouping your data. There's

00:18:01.660 --> 00:18:05.840
<v Sjors Provoost>just very subtle implementation details but as long as you stay below the 83

00:18:05.840 --> 00:18:07.790
<v Sjors Provoost>bytes for the whole script you're fine.

00:18:07.790 --> 00:18:13.650
<v Aaron van Wirdum>Right now one thing you already alluded to, is that back then back when

00:18:13.650 --> 00:18:19.590
<v Aaron van Wirdum>this discussion was happening I think people were really looking at the

00:18:19.590 --> 00:18:25.510
<v Aaron van Wirdum>Bitcoin blockchain as sort of a shared resource, and they weren't thinking about

00:18:25.510 --> 00:18:31.510
<v Aaron van Wirdum>it as much it seemed like like we would today as a market. So today we

00:18:32.270 --> 00:18:37.310
<v Aaron van Wirdum>In general, I think we have more of this idea that whoever is willing to pay the

00:18:37.310 --> 00:18:42.170
<v Aaron van Wirdum>highest fees gets into the block. And we have a block size limit to protect

00:18:42.170 --> 00:18:47.870
<v Aaron van Wirdum>nodes, essentially, to protect users from having to store too much data. And back

00:18:47.870 --> 00:18:52.410
<v Aaron van Wirdum>then, people weren't really thinking about fee markets yet. There were no fee

00:18:52.410 --> 00:18:56.890
<v Aaron van Wirdum>markets yet. So it was really just considered a shared resource. Now, from

00:18:56.890 --> 00:19:02.860
<v Aaron van Wirdum>today's perspective... don't you think it would make more sense to just remove

00:19:02.860 --> 00:19:07.300
<v Aaron van Wirdum>any OP_RETURN limit and just say whoever wants to pay for it will pay or put

00:19:07.300 --> 00:19:11.360
<v Aaron van Wirdum>differently, would you say that maybe the people that were making that argument

00:19:12.460 --> 00:19:17.060
<v Aaron van Wirdum>What was it eight years ago? Maybe you were right that it should have just been

00:19:17.060 --> 00:19:18.780
<v Aaron van Wirdum>allowed and whoever pays pays.

00:19:19.020 --> 00:19:24.060
<v Sjors Provoost>I'm not sure. So one of the things is that the fees that you're paying go to

00:19:24.060 --> 00:19:29.680
<v Sjors Provoost>miners. They don't go to node operators. So every node operator is still somewhat

00:19:29.680 --> 00:19:34.910
<v Sjors Provoost>altruistically running these things. So you'd still want to see what you want

00:19:34.910 --> 00:19:40.050
<v Sjors Provoost>node operators to do for you. Do you want them to store your Bible or do you only

00:19:40.050 --> 00:19:43.030
<v Sjors Provoost>want to do payments? So you could still have that argument that even if somebody

00:19:43.030 --> 00:19:48.710
<v Sjors Provoost>was willing to pay a very high fee to miners to include lots of OP_RETURN data,

00:19:48.930 --> 00:19:52.590
<v Sjors Provoost>you could argue, well, but they're not paying the node operators to store that

00:19:52.590 --> 00:19:56.970
<v Sjors Provoost>OP_RETURN data and people are not running nodes to publish the Bible or whatever.

00:19:57.150 --> 00:20:00.950
<v Aaron van Wirdum>But they don't have to store the data. Though they still need to verify it once.

00:20:00.950 --> 00:20:05.110
<v Sjors Provoost>Yeah they still need to process it. Yeah so but yeah the burden is a bit lower

00:20:05.110 --> 00:20:08.370
<v Sjors Provoost>especially when you use OP_RETURN and it's much better than the alternatives. On

00:20:08.370 --> 00:20:12.330
<v Sjors Provoost>the other hand, there's also now things like RGB and things like OpenTimestamps

00:20:12.330 --> 00:20:17.230
<v Sjors Provoost>various other projects that show that you can just use a single hash or even not

00:20:17.230 --> 00:20:20.730
<v Sjors Provoost>a hash at all, because from a privacy point of view things like a tweaked

00:20:20.730 --> 00:20:24.550
<v Sjors Provoost>signatures tweaked public keys or tweaked signatures are even a more privacy

00:20:24.550 --> 00:20:28.600
<v Sjors Provoost>friendly way to put data on the blockchain, which also makes them

00:20:28.600 --> 00:20:33.040
<v Sjors Provoost>indistinguishable from regular transactions. That one thing, that means that you

00:20:33.040 --> 00:20:38.200
<v Sjors Provoost>can't stop it, whatever you do in the protocol. But it also means that by using

00:20:38.200 --> 00:20:41.580
<v Sjors Provoost>the protocol in that way, even though you're using it for something that's not

00:20:41.580 --> 00:20:44.660
<v Sjors Provoost>moving money around, you are helping the people that are moving money around

00:20:44.660 --> 00:20:48.900
<v Sjors Provoost>because you're creating a bigger anonymity set for everybody else. Because you're

00:20:48.900 --> 00:20:51.420
<v Sjors Provoost>just creating a bunch of noise between all the transactions.

00:20:53.050 --> 00:20:57.970
<v Aaron van Wirdum>Right. Well, that could also be considered an argument for removing the limit.

00:20:58.230 --> 00:21:02.730
<v Aaron van Wirdum>It's like you say, if you can create it anyways and no one can even see that

00:21:02.730 --> 00:21:06.290
<v Aaron van Wirdum>you're just creating data that's non-transaction data, essentially.

00:21:06.570 --> 00:21:11.500
<v Sjors Provoost>You can't see it if you're not using OP_RETURN. So those protocols that use

00:21:11.500 --> 00:21:13.260
<v Sjors Provoost>tweaked signatures don't use OP_RETURN at all.

00:21:13.980 --> 00:21:19.220
<v Aaron van Wirdum>Well, that's what I mean. So at that point, why don't we just say, okay, people

00:21:19.220 --> 00:21:23.410
<v Aaron van Wirdum>can put data on the blockchain and we [unclear] stop them. We might as well just

00:21:23.410 --> 00:21:29.510
<v Aaron van Wirdum>make it easy and have it done in such a way that it doesn't impact the UTXO set.

00:21:29.630 --> 00:21:32.650
<v Sjors Provoost>But then it's actually hurting privacy because if people start using OP_RETURN

00:21:32.650 --> 00:21:37.350
<v Sjors Provoost>for their data instead of these more privacy-friendly ways, then they're just

00:21:37.350 --> 00:21:38.530
<v Sjors Provoost>hurting their own privacy.

00:21:40.210 --> 00:21:45.200
<v Sjors Provoost>But as far as I know, there's nobody currently... with a serious proposal of why

00:21:45.200 --> 00:21:49.260
<v Sjors Provoost>they would need bigger OP_RETURN messages. I think Bitcoin SV is experimenting

00:21:49.260 --> 00:21:55.240
<v Sjors Provoost>with very, very, very, very large OP_RETURN messages and has 99.999999% of their

00:21:55.240 --> 00:22:01.100
<v Sjors Provoost>chain with OP_RETURN data. So I don't know how I would feel about it, but

00:22:01.100 --> 00:22:03.240
<v Sjors Provoost>so far I don't think it's a relevant question.

00:22:04.320 --> 00:22:09.020
<v Aaron van Wirdum>So the general idea behind, and I, I think this is what you mentioned when you

00:22:09.020 --> 00:22:13.700
<v Aaron van Wirdum>said some people don't like the term OP_RETURN wars, is that this part of

00:22:13.700 --> 00:22:19.120
<v Aaron van Wirdum>Bitcoin's history is sort of considered by— Vitalik decided to

00:22:19.120 --> 00:22:20.200
<v Aaron van Wirdum>launch Ethereum.

00:22:20.580 --> 00:22:25.460
<v Sjors Provoost>Yeah, but that makes very little sense because he could have used, if, if Bitcoin

00:22:25.460 --> 00:22:29.000
<v Sjors Provoost>was, you know, if he needed OP_RETURN, then he could have done the same thing

00:22:29.000 --> 00:22:34.960
<v Sjors Provoost>with OP_MULTISIG. So I don't think that... particular thing would have made the

00:22:34.960 --> 00:22:39.840
<v Sjors Provoost>difference. It's not possible to run Ethereum on top of Bitcoin with or without

00:22:39.840 --> 00:22:40.240
<v Sjors Provoost>OP_RETURN.

00:22:40.860 --> 00:22:45.940
<v Aaron van Wirdum>And the other thing anyone can do, of course, is just fork Bitcoin Core and allow

00:22:45.940 --> 00:22:48.780
<v Aaron van Wirdum>for bigger OP_RETURN messages since it's not a consensus rule.

00:22:48.960 --> 00:22:52.880
<v Sjors Provoost>So, you know, maybe the lesson from that discussion was that Bitcoin was clearly

00:22:52.880 --> 00:22:57.880
<v Sjors Provoost>not going the way of allowing everything and everyone to do complicated things on

00:22:57.880 --> 00:23:02.880
<v Sjors Provoost>the blockchain. And that may have been a realization point for him to say, OK, if

00:23:02.880 --> 00:23:05.220
<v Sjors Provoost>Bitcoin is not going that direction, I'll try my own project.

00:23:05.520 --> 00:23:09.460
<v Aaron van Wirdum>Yeah I think that's sort of the argument or that's also the argument sort of

00:23:09.460 --> 00:23:14.120
<v Aaron van Wirdum>presented in this blog post that it was a cultural thing that the Bitcoin culture

00:23:14.120 --> 00:23:19.280
<v Aaron van Wirdum>at that time was not very accommodating to non-transaction data on the blockchain

00:23:19.280 --> 00:23:23.640
<v Aaron van Wirdum>and that's why Vitalik decided to start his own blockchain.

00:23:23.640 --> 00:23:28.640
<v Sjors Provoost>Perhaps might also have something to do with being able to make money but… And of

00:23:28.640 --> 00:23:31.040
<v Sjors Provoost>course the nice thing about having a new chain is you know you can do whatever

00:23:31.040 --> 00:23:34.280
<v Sjors Provoost>you want, so it does give you a lot of creative freedom. That's the more

00:23:34.280 --> 00:23:35.680
<v Sjors Provoost>optimistic interpretation of it.

00:23:35.710 --> 00:23:40.510
<v Aaron van Wirdum>Yes they can clearly do whatever they want. We cover everything about OP_RETURN?

00:23:40.860 --> 00:23:46.510
<v Sjors Provoost>I think so Well, it might be fun to mention there was an

00:23:46.510 --> 00:23:52.130
<v Sjors Provoost>incident in 2019, a project called VeriBlock, which I believe has Jeff Garzik

00:23:52.130 --> 00:23:53.230
<v Sjors Provoost>as their advisor.

00:23:54.530 --> 00:23:57.810
<v Sjors Provoost>And at some point, there was a lot of increase in the number of OP_RETURN

00:23:57.810 --> 00:24:02.050
<v Sjors Provoost>transactions. Not the size of them, just the sheer number of them. To the point

00:24:02.050 --> 00:24:05.090
<v Sjors Provoost>where they were starting to compete. They had to pay some pretty high fees to

00:24:05.090 --> 00:24:08.390
<v Sjors Provoost>compete with regular transactions. And it was interesting to watch. And there was

00:24:08.390 --> 00:24:12.290
<v Sjors Provoost>kind of a worry that this would just mean that OP_RETURN transactions are the

00:24:12.290 --> 00:24:15.730
<v Sjors Provoost>buyer of last resort. And every block from now on will be full.

00:24:16.010 --> 00:24:21.910
<v Aaron van Wirdum>That was basically an altcoin that used Bitcoin's proof of work as

00:24:21.910 --> 00:24:22.870
<v Aaron van Wirdum>its security.

00:24:23.200 --> 00:24:26.960
<v Sjors Provoost>Yeah, I believe so. I think roughly what the idea was is that people on that

00:24:26.960 --> 00:24:31.520
<v Sjors Provoost>altcoin would create candidate blocks, basically. And the hash of those candidate

00:24:31.520 --> 00:24:35.500
<v Sjors Provoost>blocks would be on the Bitcoin chain. And then whoever paid the highest fee on

00:24:35.500 --> 00:24:38.720
<v Sjors Provoost>the Bitcoin chain would be the winning block on that chain. So you'd have lots

00:24:38.720 --> 00:24:42.200
<v Sjors Provoost>and lots of Bitcoin transactions, each with a hash that could represent the

00:24:42.200 --> 00:24:45.460
<v Sjors Provoost>future block. And then whichever has the highest fee would win. So it would be a

00:24:45.460 --> 00:24:48.500
<v Sjors Provoost>nice way to give money to Bitcoin miners. But last time I checked on

00:24:48.500 --> 00:24:54.330
<v Sjors Provoost>CoinMarketCap, it said market data is untracked. So... It sounds like that's not

00:24:54.330 --> 00:24:55.030
<v Sjors Provoost>going very well.

00:24:55.170 --> 00:24:56.530
<v Aaron van Wirdum>It doesn't sound very good, Sjors.

00:24:56.690 --> 00:24:57.170
<v Sjors Provoost>But who knows?

00:24:57.370 --> 00:24:59.250
<v Aaron van Wirdum>Okay, I think that's it or not.

00:24:59.950 --> 00:25:00.830
<v Sjors Provoost>Yep, that's all I got.

00:25:02.160 --> 00:25:04.500
<v Sjors Provoost>So thank you for listening to Bitcoin

00:25:04.500 --> 00:25:05.560
<v Aaron van Wirdum>Explained.