Episode 98: Return of the OP_RETURN

Aaron van Wirdum Live from Utrecht, this is Bitcoin

Sjors Provoost Explained.

Aaron van Wirdum Sjors, I just discovered something. I had never actually paid attention to this before, but I was scrolling through my own podcast app, and I noticed that Bitcoin Explained is getting 4.6 out of 5 stars.

Sjors Provoost On your random podcast app. Because every podcast app has its own ratings.

Aaron van Wirdum Is that how it works? Oh, I have Pocket Casts. On Pocket Casts, we get 4.6 stars out of... Oh, every single listener has left a review. We have 20 reviews.

Sjors Provoost But it's even worse than that. Every podcast app has its own reviews, and then some podcast app, like Apple, will split those reviews between countries. So you might have somebody in Tanzania leaving a review, but you will never see it because we're not in Tanzania.

Aaron van Wirdum Okay, well, I don't know what to make of 4.6. Let's see. What Bitcoin Did with Danny has 4.8.

Sjors Provoost Nice.

Aaron van Wirdum Well, no. That means Danny is doing better than us, Sjors.

Sjors Provoost Oh, okay.

Aaron van Wirdum I still have Junseth's World. Junseth's World has got zero reviews.

Sjors Provoost Zero stars.

Aaron van Wirdum Zero stars, but that's what he's going for, right?

Sjors Provoost No, they wanted one star.

Aaron van Wirdum Bitcoin Audible, 4.9. Oh, my God. Stephan Livera, 4.9. We're the lowest one, Sjors. Other than zero stars. Reckless Review got five stars.

Sjors Provoost Okay.

Aaron van Wirdum Does anyone remember what Reckless Review is? I'm still subscribed to it, but that was our goal. That was our only goal, Sjors.

Sjors Provoost To surpass them.

Aaron van Wirdum To be better, to at least meet the lowest of low bars and to be better than Reckless Review, but we failed at that even.

Sjors Provoost Well, sounds good.

Aaron van Wirdum Let's go for another five-star episode today, Sjors. What do you think?

Sjors Provoost Sounds like a good plan. You know what else is annoying?

Aaron van Wirdum What's annoying?

Sjors Provoost Smoke alarm batteries.

Aaron van Wirdum Why?

Sjors Provoost Well, because the way you find out that your smoke alarm battery is empty is at 3 o'clock in the night when it starts beeping and doesn't stop until you find a ladder and remove the smoke alarm.

Aaron van Wirdum Repeat that. The only...

Sjors Provoost The way you find out that your smoke alarm battery is empty is that it starts beeping at you in the middle of the night. And then... You buy a new battery and the battery says, oh, don't worry, you can keep this battery in its packaging for 10 years or for five years or whatever. Of course it doesn't. So you don't want to buy the battery when the last one runs out. Because by the time you need the new battery, the old battery that you kept in your closet is going to be leaking.

Aaron van Wirdum Why are we talking about smoke alarm batteries?

Sjors Provoost Because they are the same battery that fits on the little device that is in front of you.

Aaron van Wirdum This beautiful device right here uses the same battery as a smoke alarm.

Sjors Provoost That's right.

Aaron van Wirdum What is this device? It's, oh my God, it's like a piece of art that I hold in my hands right now.

Sjors Provoost Yes.

Aaron van Wirdum It's sublime. Tell me what this is, Sjors.

Sjors Provoost That is the COLDCARD Q. Also the BlackBerry. No, it's not a BlackBerry. It looks like a BlackBerry.

Aaron van Wirdum The COLDCARD by CoinKite happens to be our amazing sponsors as well. Pure coincidence, I'm sure, that it's laying here when you bring that up.

Sjors Provoost Yes.

Aaron van Wirdum You just have it here as a piece of art in your living room.

Sjors Provoost Exactly.

Aaron van Wirdum For people to admire when they walk in.

Sjors Provoost Next to the anvil.

Aaron van Wirdum Seriously, though, COLDCARDs, the hardware wallet that you need to store your Bitcoin. Get it today.

Sjors Provoost Thanks for sponsoring us.

Aaron van Wirdum Alrighty. Now, Sjors, today we had a very hard time finding a topic to talk about. We had to look all over the internet to find anything, something technical that people were talking about. Finally, we found this one obscure comment somewhere on GitHub about the OP_RETURN limit.

Sjors Provoost Yes.

Aaron van Wirdum And how Bitcoin Core developers or some Bitcoin Core developer wants to potentially lift it. Is that right? Is the rumor true?

Sjors Provoost I can neither confirm nor deny. No, you can see it on GitHub.

Aaron van Wirdum Twitter runs ablaze this week. I'm not on Twitter anymore, which I find wonderful. Well, I do have my account, but I really only use it for one-way tweets once in a while. I don't spend any time.

Sjors Provoost I deleted it, so if you see anybody with my username on Twitter, it's not me. And I'm not going to double your coins.

Aaron van Wirdum Yeah, I'm de facto Nostr only. You're really Nostr only.

Sjors Provoost Yep.

Aaron van Wirdum Yeah. So honestly, whatever was debated on Twitter on this topic, I don't think I've seen it other than indirectly because other people are talking about it or I saw screenshots on Nostr.

Sjors Provoost Yeah, but they were also debating it on Nostr and more importantly on GitHub and on the mailing list.

Aaron van Wirdum Well, they were not discussing it on GitHub, I heard, because the Core developers shut that discussion down.

Sjors Provoost Well, not effectively enough.

Aaron van Wirdum Anyways, okay, so we're going to make the 37th podcast on the OP_RETURN drama.

Sjors Provoost Yes, and for the listeners, we did one before.

Aaron van Wirdum But this is just to say this will be the highest quality one. Because we got our very special Sjors. Well, this is not even your first podcast talking about the OP_RETURN drama, I think.

Sjors Provoost No, we've done episode 61 on it.

Aaron van Wirdum Well, also, and you were on the Bitcoin Optech podcast. But it's your first podcast speaking about it with me after the drama happened. And indeed, we did other episodes on OP_RETURN as well.

Sjors Provoost Yes.

Aaron van Wirdum But let's dig into it. Let's see if we can bring anything new to the table. If not, well, maybe you get at least new voices talking about the same thing. So, dear listener, I hope you enjoy it at least a little bit. Sjors, we're going to start at the beginning. And yes, we did a previous episode on it, which these were episode six, very early one, and episode 76, and I'm sure it came up in other episodes.

Sjors Provoost You mean episode 61, not six.

Aaron van Wirdum I have 76 here, though.

Sjors Provoost Yeah, 61.

Aaron van Wirdum Oh, not six.

Sjors Provoost Yeah.

Aaron van Wirdum Oh, right. That was one after the six on the next. Next row. Okay, 61 and 76, probably here and there between as well. But actually, I do want to sort of use this episode to kind of give a complete picture. So let's not go back to that episode thing and let's just kind of start from the beginning.

Sjors Provoost No, but you could listen to it if you think that I randomly changed my mind on these topics, which is possible. But we have the earlier episode.

Aaron van Wirdum Sure. Let's start at the beginning. What is OP_RETURN? Let's start there. What is OP_RETURN?

Sjors Provoost Well, if we really go back to the beginning, it was a way to basically steal everybody's coins. Because there was a bug in the original version of it. It basically says like...

Aaron van Wirdum Well, okay, first question. Was OP_RETURN in the Bitcoin protocol since day one?

Sjors Provoost Yes.

Aaron van Wirdum Okay, but that means, because you mentioned, there was originally a bug in the OP_RETURN implementation. So that means, if I understand you correctly...

Sjors Provoost It wasn't in the OP_RETURN implementation itself. It was that you can use it basically the way, just as a reminder, how do you spend a Bitcoin? You spend an output, right? So it's like coins. And the output says, here's a challenge if you want to spend me. And then the way you do it in practice is first you provide some answers to the blockchain. We now call that the witness. It used to be the scriptSig. It doesn't really matter. You start with the answer. And then it's followed by the question. It's kind of a riddle-y way, right? So you say, your answer might be, here's my signature. And then the question would be, like, give me a signature for this public key.

Aaron van Wirdum For the next person that will spend it.

Sjors Provoost Yes. Now, the problem is, because of this sequence, if you use OP_RETURN, you could say, okay, OP_RETURN, that just says, I'm done now. And so you're not going to look at the question.

Aaron van Wirdum This is already skipping ahead too far.

Sjors Provoost That was basically how, I believe, how the bug worked.

Aaron van Wirdum Yeah, but people don't understand how the bug works if they don't understand OP_RETURN itself, right? So that's why you're skipping ahead too far already. In either case, this is not even what we're talking about, the bug. But I guess we... What is OP_RETURN?

Sjors Provoost It just says, like, you're done now. We're finished evaluating this. whatever script it is. It's the end of the script.

Aaron van Wirdum Right.

Sjors Provoost Even if it's not actually the end of the script.

Aaron van Wirdum So I'm running a node and my node is looking at a transaction. So in my node, my computer is reading these transactions, going line for line, seeing what I'm supposed to do here. And then at some point, my node sees OP_RETURN in a transaction and then my node says, oh, I'm done reading now.

Sjors Provoost Yes.

Aaron van Wirdum Okay.

Sjors Provoost And I guess the thing I forgot about the exploit is... When you're done reading, the question then is, is this transaction now valid or not? That's the actual challenge. Can I spend this coin or not?

Aaron van Wirdum Yeah.

Sjors Provoost And whether or not you can spend a coin does not depend on the last thing you read. It depends on what's on the stack. And we talked about stacks earlier. Like you put something on the stack and you can take things off the stack and you can multiply them, whatever. Well, you can multiply them. And so what you would do is you put the word true. on the stack and then you finish and so the rule is if at the end of a script the last thing on the stack is true then you're done so this was kind of the trick you would just put true on the stack and you would stop and you wouldn't read the challenge

Aaron van Wirdum okay but I want to ask what is the benefit of this what is the benefit of saying stop reading now

Sjors Provoost I mean it's used in pretty much every programming language to say okay the program is done or yeah usually or the function is done

Aaron van Wirdum well why not just stop writing code after OP_RETURN and not include OP_RETURN because then the node is also done reading because there's nothing to read like what's the difference

Sjors Provoost yeah so this is why you know it's a general thing that you would use in programming language it wasn't I don't think there was a specific reason to include it Satoshi just added a whole bunch of opcodes to Bitcoin some of which were, like, a lot of them were just from, this is kind of how programming languages work and we can make smart contracts. I think there wasn't that much thinking about which opcodes to include, which is why a lot of them were disabled.

Aaron van Wirdum Okay, the way you're explaining it to me now, and this is the first time I'm hearing it explained like this, so let me ask, you explain it like OP_RETURN is the equivalent of, like, a dot in regular text. It's like the end of the sentence. Is that what it is?

Sjors Provoost Pretty much. I mean, in programming language, you can use return just as its own statement, which just ends, but you can also put a value after it. So you can return something, return a value. That's kind of where it comes from. So you can say return five, and then whichever function is calling you gets the number five. But this gets too deep in the programming weeds. I think for the purpose of Bitcoin, it just means stop where you are.

Aaron van Wirdum Yeah, okay. So let me skip ahead a little bit, or not, depending on your answer. The way OP_RETURN is used is you put some sort of other kind of data in... in OP_RETURN. That's how it's usually explained. Like you have an OP_RETURN output and then you put some other kind of data, whether that's a hash or something. That's what you use OP_RETURN for. My question then is, was that the original intention of OP_RETURN or is that something that was figured out later in the sense of, okay, that's what we could use that for?

Sjors Provoost I think it was figured out later. I think the original reason was it just stops the program. And because you stop the program, you can put whatever you want after it because you're not going to check it.

Aaron van Wirdum Okay, I think this is new to me, unless you explained this to me in a previous episode.

Sjors Provoost I don't know if I did, but...

Aaron van Wirdum You may have. So it was not necessarily the original intention of Satoshi for putting OP_RETURN in there, but it did effectively work that way. Because if my node stops assessing data, but the data is technically in the transaction, then that means that... you know, the data ends up in the blockchain and can be used for other purposes, basically. That's how OP_RETURN was effectively used, at least later.

Sjors Provoost Yeah, I think the first OP_RETURN ever was long after Satoshi left, but I haven't checked this. I mean, Satoshi himself put a message in the blockchain at the Genesis block, but he didn't put it in an OP_RETURN.

Aaron van Wirdum No, he put it in a Coinbase.

Sjors Provoost Yeah.

Aaron van Wirdum Okay, you think... double-check us if one of our listeners thinks it's wrong or not. We don't actually care. We're not going to read the comments. But you think, Sjors, that OP_RETURN was probably only ever used after Satoshi left, in fact.

Sjors Provoost I think so. You can easily check this. I don't know for sure.

Aaron van Wirdum Okay. So the original thing was just a generic code thing. Stop reading here.

Sjors Provoost Yeah, this is one of many opcodes that Satoshi added, and it's kind of standard if you know how programming languages work.

Aaron van Wirdum Okay, and now the next step. Now the first time it was used, or maybe not the first time, but when it started to be. People started to use OP_RETURN to embed other types of data other than transaction data, other than send Bitcoins from here to there. Other types of data. in the blockchain and they were used... Okay, go on. You go first.

Sjors Provoost Here, I'm not sure if they actually did that first. I think what they did first was to use fake public keys.

Aaron van Wirdum Right.

Sjors Provoost And then somebody told them, hey, don't do that. Use OP_RETURN instead.

Aaron van Wirdum Right.

Sjors Provoost So let's assume that this sequence is incorrect. It doesn't really matter for the argument.

Aaron van Wirdum Indeed.

Sjors Provoost So, okay. So you want to embed something in the data and you're like, we're in the blockchain. The first thing is you would ask yourself is where am I going to put this?

Aaron van Wirdum You want to put data in the blockchain that's not sending Bitcoins from A to B.

Sjors Provoost Yeah, and at the time...

Aaron van Wirdum Other type of data, for whatever reason.

Sjors Provoost Yeah, and so at the time you're like, okay, what is in a transaction? Well, there's public keys, there's signatures, all these things. Why don't I just make a fake... Well, if you make a fake signature, then the transaction is invalid, so it doesn't end up in the blockchain. At least, you know, there's some caveats there, but that's a general idea. But a fake public key... Yeah, you can do that.

Aaron van Wirdum Yeah, and by fake public key, what you mean is something that looks like a public key, except some parts of the numbers and figures that are in there are actually data that you use for something else, right?

Sjors Provoost Yes, and the effect of that is that there's not going to be a corresponding private key. You can infer that as a human. So one of the first things that are in the blockchain, I think, is a picture of Obama, the Bitcoin white paper PDF. You can get it out of the blockchain. Yeah. And I think a lot of that is done with fake signatures. Some of it might have been done later with OP_RETURN.

Aaron van Wirdum Yeah, so what I could do potentially is I could write a message to you that says, hey, Sjors, let's explain the new Bitcoin Explained. Let's record a new Bitcoin Explained episode today at 6. And then I create a bunch of pubkeys that have these exact letters as the last letters of each one of them. Hi, Sjors, you can actually read that. And if you run some sort of program that monitors the blockchain for that, then at some point you can actually see that message and then you can message me back in the same way. And now we've created a bunch of pubkeys that cannot actually be spent because I just generated them for the message. But they do end up... in the blockchain, and worse,

Sjors Provoost they end up in the UTXO set.

Aaron van Wirdum They end up in the UTXO set.

Sjors Provoost Yeah, and the UTXO set is this database of coins that exist. And right now this database, I think if you put it on your disk, it's like 13 gigabytes.

Aaron van Wirdum To be clear, to be clear. So if I do this, then of course I do indeed need to send some coins to each of these addresses, right? One satoshi at least. Or not even? Or can I send zero?

Sjors Provoost No, there's a dust limit. So you have to send, I think, a couple hundred satoshis in practice.

Aaron van Wirdum Well, is that a consensus?

Sjors Provoost No.

Aaron van Wirdum Okay.

Sjors Provoost No, no, no. Consensus-wise, you can actually spend zero and you can make a transaction that spends nothing. also doesn't produce any outputs.

Aaron van Wirdum Yeah, I heard that recently on the Bitcoin Explained podcast.

Sjors Provoost Interesting.

Aaron van Wirdum Yeah, they were talking about a new Bitcoin Core release and I learned a lot from it.

Sjors Provoost Okay, well, it sounds like a nice podcast then.

Aaron van Wirdum But practically speaking, let's say I wanted to send these messages, then yeah, probably I would just use the dust limit, which is whatever it is, 400 sats or what is it?

Sjors Provoost Yeah.

Aaron van Wirdum Whatever it is.

Sjors Provoost Whatever.

Aaron van Wirdum Yeah, it's pretty cheap still and then I have this message. The thing is that the rest of the world...

Sjors Provoost And especially then, it was pretty cheap, right?

Aaron van Wirdum Right. So the rest of the world, I know that I can't spend these coins. You can probably also figure out that I can't spend these coins. But for the rest of the world, it just looks like spendable coins. Now the rest of the world, everyone who runs a node needs to keep track of these coins and their existence. And in fact, because they go into the UTXO set, so the database basically of unspent coins, that means I think, correct me if I'm wrong, but they end up in the... the memory of your computer, which is kind of resource-intensive.

Sjors Provoost Yeah, they don't have to be in memory, but it's better if you do. But the most important thing is you cannot delete it.

Aaron van Wirdum Yeah.

Sjors Provoost Because, I mean, you could bluff, basically. You could say, well, I'm going to look at these transactions and I know nobody can spend it, so I know I can delete this from my computer and it will never cause a problem. But if you're wrong, somebody creates something that looks like a picture, but it's actually, you know, it's a real key and they end up spending it. well, you will look at that block and think the block is invalid because they're spending a coin that doesn't exist because you deleted it. So there's really no objective way to figure out which of these coins are real and which of these are fake, other than saying, hey, Bitcoin Core, why don't you make a database and tell us all what the real coins are and what the spam coins are? But that would be fairly centralizing.

Aaron van Wirdum We don't want that.

Sjors Provoost No.

Aaron van Wirdum Okay, so then at some point, Core developers said, This sucks. We don't want you guys to upload Obama pictures and white papers and Bitcoin Explained scheduling messages into the UTXO set. That sucks. Here is actually a better solution, right? That's kind of how it went.

Sjors Provoost Yeah, so I guess there were people that said don't embed this kind of stuff anywhere. But specifically, don't put it in the UTXO set because it is this thing that will grow forever until the end of time. Like, you cannot shrink it. Every time you spend a coin, it shrinks. But if you never spend a coin, it never shrinks.

Aaron van Wirdum Yeah, so if you create UTXOs that cannot be spent, then...

Sjors Provoost then they will never be spent, exactly. So the idea was, okay, how can we, you know, we can't stop people because, again, then that would require some weirdness. But you can encourage people to put data on the blockchain in a way that does not grow the UTXO set. And that is when people realized you can use OP_RETURN for this.

Aaron van Wirdum Right.

Sjors Provoost And so then a change was made in the relay rules. We'll need to get to the relay rules with basically saying, just put this OP_RETURN code and then after it, put your JPEGs.

Aaron van Wirdum Yeah.

Sjors Provoost And then the limit was still 80 bytes.

Aaron van Wirdum Well, so let's get to that right now. So the way I understand it, what I remember, I think, from our previous episode, is that originally, as a consensus rule, as what is valid in a block, there was never a limit on OP_RETURN.

Sjors Provoost Yes.

Aaron van Wirdum The block size limit was made one megabyte by Satoshi. I guess before that.

Sjors Provoost Yeah, the original OP_RETURN limit was 32 megabyte.

Aaron van Wirdum And that was because transactions of...

Sjors Provoost Because blocks are 32 megabytes. And I think even that limit...

Aaron van Wirdum Was that even a consensus rule? I think even that was a relay rule.

Sjors Provoost Well, I don't know about relay rule, but it was like any network message that was larger would be rejected. So it's possible if you got the block on a floppy disk, then you could load it. Right. But it's not like what we now would call a policy rule.

Aaron van Wirdum Yeah, policy rule. That's a term I was looking for, actually. But at least as a consensus rule, OP_RETURN transactions could be as big as block size limits or the message limit that you just mentioned. But at that point, I think there was still a relay restriction of no OP_RETURNs at all, maybe. Like OP_RETURNs would just not be relayed. Is that correct, or do you not know this?

Sjors Provoost Yes, so if we go back to relay history in general, without recapping everything, in the beginning, Satoshi made a whitelist of things that can be relayed. basically between nodes. And those would be the very standard transaction types. Like I'm spending from a public key and receiving to a public key. There were some limits on, say, multi-signature, how many, I think it was three. in a multisig, so no more than three keys in a multisig, etc. So it was a very, very small subset of everything that was possible, was allowed, and it was definitely a whitelist.

Aaron van Wirdum Yeah, and to re-emphasize this, you now distinguish between what is possible and what is allowed. The difference is, there is one set of rules, the consensus rules, for what may end up in a block, and other nodes will consider valid. And then there's another set of rules. The relay rules or what's the actual policy rules?

Sjors Provoost Policy rules.

Aaron van Wirdum And that will determine what nodes will accept in their mempool and relay to other nodes.

Sjors Provoost Yeah.

Aaron van Wirdum Right? That's the difference. Okay, so there's one set of rules for what goes into a block, what's allowed, and one set of rules for what a node will tell other nodes is happening. Right? So, at first, anything was allowed in a block, or at least any OP_RETURN size was allowed in a block, but nodes would not send it to other nodes. They would say, OP_RETURN, I'm not going to help spread that. But that was then changed. So, at that point, Core developers said, there was a debate about this. whether it should be 40 or 80, and I think they settled on 80 bytes.

Sjors Provoost Yes.

Aaron van Wirdum Yeah, so they said, okay, from now on, with this new Bitcoin Core release, that was the Bitcoin Core, whatever, six or whatever it was. I don't know. Do you know this?

Sjors Provoost I don't know.

Aaron van Wirdum Yeah, well, it was a long time ago. They said, okay, from now on, we are going to relay OP_RETURNs up to 80 bytes. Okay, why was... The limit set at 80 bytes.

Sjors Provoost Yeah. So for this, we need to introduce another use case of this putting data on the blockchain because this 80 bytes is still not enough to relay anything like the white paper and JPEGs. I guess they weren't that popular back then, but what was starting to get popular was something called Counterparty. And it was more about smart contracts that would not put the actual image on the blockchain, but put like a hash of the image in the blockchain and you would sell, quote unquote, your... trading cards, NFTs, as we call them now. And those transactions, I think...

Aaron van Wirdum Yeah, I mean, I think Counterparty was more than just that, but go on, yeah.

Sjors Provoost Yeah, but basically those transactions...

Aaron van Wirdum I mean, it was also like meta coins and stuff like that, but go on.

Sjors Provoost Yeah, trading cards is one example, but there were other things. Rare Pepe was quite famous, I think, back then.

Aaron van Wirdum Yeah.

Sjors Provoost So those transactions, I think, were in practice a little bit like 60 bytes or 70 bytes, some number. And so... And that was kind of the use case that people wanted to not facilitate, but basically say, let's not, for every time somebody is selling or buying a card or this other coin, let's not add an entry to the UTXO set. So then let's give them these 80 bytes that they need. Now, there was some discussion because some people said, well, you could make this protocol better and use only 40 bytes. And then the Counterparty people were like, yeah, but we don't feel like implementing that or we don't agree with that. And remember, the goal again was harm reduction here, right? So the goal was to convince those people to stop doing what they were already doing and use OP_RETURN instead. So you're negotiating basically from a fairly weak position. You can ask people nicely, but they were already doing this. And apparently they could afford it. So you can only say like, well, if we allow this... I don't think it would even be cheaper. It's just like, this is better for the network. People are going to stop screaming at you if you do this.

Aaron van Wirdum Yeah, there's a small piece of context here that I want to clarify. At this time in history, blocks were basically never full. So what's Counterparty, and I think there was also Mastercoin maybe, which was a predecessor of Counterparty, but never mind that. if they were using or they were also using the pubkey system that I used before or I explained before how I would message you about what time we record Bitcoin Explained so Counterparty could also do that basically for free Right? It was just an annoyance. So then the Bitcoin community, the Bitcoin Core developers asked, let's just use the OP_RETURN instead. At least that's better. But for the Counterparty people, there was no financial incentive or anything to do that. It was more...

Sjors Provoost Yeah, I don't think so. I don't think there was a discount in doing it. There might be slightly because if you're creating three fake public keys, that means you need to make... three outputs of your transaction and every output has a little bit of overhead because it has like some bytes to indicate the amount so it's possible that using OP_RETURN was slightly cheaper and that was sort of the extra incentive but it wouldn't have been a very dramatic change

Aaron van Wirdum Well, the blocks were not full, so there was no fee pressure. Fees were basically more or less voluntary.

Sjors Provoost Yeah, they were just set to a certain amount per vbyte or even fixed. I don't know. There were times when a fee was just like 0.1 Bitcoin and people were like fine with it.

Aaron van Wirdum Yeah, because there was nothing at the time. Yeah, and no one cared. Where was I? In any... Well, I also pointed out because it says something about... You pointed out that, you know, let's just say Bitcoin Core. Bitcoin Core had a weak negotiating position because Counterparty might as well just have used the pubkey system. So then, you know, when there was a debate between 40 or 80 bytes, then... You know, you kind of had to give in or say, okay, use the 80 byte one then if you really want it because that's still better than using the pubkeys right?

Sjors Provoost Yeah.

Aaron van Wirdum Yeah. A little extra.

Sjors Provoost And so I don't remember why there was no debate about putting entire images on the blockchain. And my guess is because people didn't or at least not at any meaningful scale. But I'm not sure about that.

Aaron van Wirdum Yeah, well, there is another interesting little detail here, which is that as this debate was happening back then between, okay, should we increase relay policy to 40 or 80? And then, you know, some Bitcoin Core developers wanted to keep it at 40. They said that was enough. And it was kind of like a hassle back then. The, you know, the origin story of Ethereum goes that Vitalik Buterin, he was sort of witnessing this debate and witnessing the pushback. from Bitcoin Core developers to increase it to 80, even though they did in the end agree with that. But he was witnessing that and he saw or he thought, okay, this is not a... This is not an environment that's going to be friendly towards me and others building meta protocols like Ethereum on Bitcoin. So let's just build our whole own system to build that on and let's forget about all of that Bitcoin hassle.

Sjors Provoost And conveniently get rich in the process.

Aaron van Wirdum Yes, although he could have also done that with a meta layer on top of Bitcoin, like a Counterparty or a Masterparty. He could have done that on Bitcoin, I guess. But anyways, that's sort of a sidestep there. This is considered sort of the origin story of Ethereum, the original OP_RETURN wars. If you want to call that a war, it was more like a discussion or conflict maybe.

Sjors Provoost But then you have the BitMEX research wrote a blog post called the OP_RETURN Wars of 2014. So it was really considered sort of a part of history. We had this phase. And nothing happened for another decade or so.

Aaron van Wirdum Yeah. Nothing happened for another decade or so. And then what happened, Sjors?

Sjors Provoost Well, we can do the actual chronological sequence or we can do an alternative history that I think would illustrate the problem better.

Aaron van Wirdum Okay.

Sjors Provoost The alternative is that we would arrive today and this really big elephant in the room didn't happen. Inscriptions didn't happen. Let's pretend they didn't happen, okay?

Aaron van Wirdum Sure.

Sjors Provoost So today we see other metaprotocols, more sophisticated than Counterparty, but still sort of the same idea. We want to do fancy contracts off-chain. And in order for those contracts to work, we need to put stuff on the blockchain. And in this time, the things were not 80 bytes, but they were like 140 bytes. And so they looked at it and they just said, OK, doesn't fit in the 80 bytes. Let's just use fake public keys. So that's a blast from the past. When did we last see that? So again, we're in the same situation, hypothetically here. There's a protocol out there that wants to do this. Now, maybe you can say, let's wait and see if they actually do it, but let's say you just want to anticipate it.

Aaron van Wirdum Oh, hang on. You call this alternative history, but this part of the alternative history is actually what happened, right?

Sjors Provoost It happened, but the considerations are now a little bit different because of this bigger thing that's also happening. But if we imagine that only this...

Aaron van Wirdum I'll let you cook.

Sjors Provoost Yeah. If it was only this new protocol, then we could have had the same discussion from the 40 versus 80 byte discussion saying, okay, well, these guys are clearly using 140 bytes, so let's give them the 140 bytes so they stop making these fake public keys that we can never get rid of in the future. That would have been sort of a repeat, same drama, but pretty simple. The problem is, and the reason why, instead of just going to 140, we're just going all the way and just dropping the limit completely. is this elephant in the room called inscriptions.

Aaron van Wirdum Okay, so in the alternative history where inscriptions never happened, then it would have been probably fairly reasonable to say, okay, we're going to double limit to 160. However, we live in real history where inscriptions happened, and inscriptions can already go to 4 megabytes, I guess.

Sjors Provoost Yes, so we did an episode about the SegWit discount. So for all the reasoning of why the limit increased to 4 megabytes and why, even despite inscriptions, I still think that was a good idea. We kind of had that whole discussion. So yeah, somebody figured out quite late, really, like many years after SegWit happened, even a while after Taproot happened, that you can really just stuff 4 megabytes into a blockchain by using the witness data. And basically kind of a similar trick where you tell the... the validation code, the script interpreter. Okay, here's an if statement. And so an if statement means like do the following code if the condition is true. And then otherwise skip the following code. That's kind of what an if statement does. And so you would basically start with a zero, which means it's not going to be true. So you say zero and then if. So that means the script interpreter is going to skip everything after the if.

Aaron van Wirdum Yeah.

Sjors Provoost Very much like OP_RETURN.

Aaron van Wirdum Right.

Sjors Provoost And you do that again and again and again because you can only fit like 500 bytes at a time that way.

Aaron van Wirdum Okay. I want to jog my own memory here. We discussed the difference between consensus rules and policy rules. So for a consensus rule, what you just described is possible up to four megabyte. What was the deal with the policy rule in that regard? Is that what changed with Taproot? Is that what happened? Is that right?

Sjors Provoost No, I think what happened with Taproot is that the way you would write these scripts was more efficient, but I don't know the details. You could have done something very similar with SegWit, but slightly less efficient.

Aaron van Wirdum Okay, what is the deal with the policy rule when it comes to this? Can you broadcast a 4 megabyte inscription to the network and other nodes relay it?

Sjors Provoost No. Because there is another limit, that is the transaction size limit. So there is a limit for 100 kilobyte, or if it uses SegWit, 400 kilobyte. That doesn't change. Even in this whole new debate, that limit is still there.

Aaron van Wirdum Okay, so if you want to get an inscription of 4 megabyte in the blockchain, you need to contact the miner directly and send that transaction to a miner to put it in the block, or mine a block yourself.

Sjors Provoost Yes, and unfortunately that doesn't happen a lot, because if we had to have the same discussion about allowing 4 megabyte transactions in the mempool, that would be bad. It would not be a simple trade-off as this one.

Aaron van Wirdum Why does that not happen a lot? Is it just because it's expensive to do or is it because it's hard to do?

Sjors Provoost My guess is not enough people feel the need to do it because it's not hard to do. You call MARA and you send them some money and they do it for you.

Aaron van Wirdum I don't have their phone number. Most people don't. That's already hard to do.

Sjors Provoost Corporate sales have existed for a long time. If you are a corporation, there's going to be somebody willing to... If somebody wanted to... say hey i want to you know for now until the end of time i've got a billion dollars i'm just gonna fill every block with four megabytes of pictures of me that that's not a skill problem it's just a matter of hiring someone to figure it out for you

Aaron van Wirdum yeah okay but it's still harder than just broadcasting it to the network there's still an extra step you need to take there

Sjors Provoost yeah the the extra step being a phone call

Aaron van Wirdum this yes yeah or an email well hang on though they also have this thing on their website right or you can like some miners also have a way to just submit transactions directly to them through some API and maybe that even allows you

Sjors Provoost to do 4 megabytes I don't know that might be right But that wouldn't get it in every block. So if you wanted to really have every block be four megabytes, you'd have to call a lot of different miners and go through this process. But you get the gist. So for now, this 100 kilobyte limit doesn't seem to be under attack, so to speak.

Aaron van Wirdum Okay, so... Now that we're in real history, so inscriptions exist, and you can do them up to 4 megabytes if you call a miner, or up to 100 bytes easily, right?

Sjors Provoost 400 kilobytes.

Aaron van Wirdum 400 kilobytes, sorry. 400 kilobytes, you can just even relay over the network. Why are we... And there's the SegWit discount. So why are we even talking or caring about OP_RETURN anymore? There's basically a better way to do the same thing.

Sjors Provoost Yeah, it's about four times cheaper, especially for big payloads. The only question is, and so this is why I think it was two years ago and we did an episode sort of around that time. There was already a proposal to just drop the OP_RETURN list restrictions completely because it was just extra complexity that wasn't doing anything.

Aaron van Wirdum I think that was my proposal.

Sjors Provoost Was yours? Okay, well...

Aaron van Wirdum I think I brought it up on one of the previous episodes that I thought it would be dropped.

Sjors Provoost Great, well then you're going to get cancelled instead of me. That's good.

Aaron van Wirdum Well, we're at what, episode 99?

Sjors Provoost 98.

Aaron van Wirdum It's time to get cancelled, Sjors.

Sjors Provoost Well, we'll see.

Aaron van Wirdum No, I do think I mentioned that on one of the previous episodes, but maybe I'm just confusing myself.

Sjors Provoost And so the idea is generally it's going to be cheaper to use these inscriptions. However, there is a sweet spot where that's not the case. And so I think Murch did some math on it. Other people have repeated the math and turns out that roughly 140 bytes, if it's less than that, OP_RETURN is going to be cheaper.

Aaron van Wirdum Okay, yeah.

Sjors Provoost And so that was sort of the final little straw, small size reason why this limit wasn't dropped two years ago. It was like, it was almost dropped. People tried to drop it. And then it was like, nah, let's not drop it because there's still this window between about 80 bytes and 140 bytes that we don't want to encourage people. But four megabytes is fine. But yeah, there was this little sweet spot.

Aaron van Wirdum There was a Goldilocks zone where,

Sjors Provoost well,

Aaron van Wirdum or the opposite of a Goldilocks zone.

Sjors Provoost There was this space where it was like, if we had dropped the limit back then, you could say, well, we're making it worse because now we're allowing, we're making spam cheaper between this range of sizes. It's kind of an academic concern almost.

Aaron van Wirdum To be clear, I was, I didn't really propose this in this...

Sjors Provoost Sure, sure, sure. You're trying to wiggle out of it.

Aaron van Wirdum I remember mentioning that I thought it should just be lifted, but I could even be wrong about that. But I definitely didn't make any sort of real consideration of anything. I was just talking. Anyways.

Sjors Provoost So the point is, remember this number sounds familiar, right? Because we just talked about this new protocol, which required increase in this alternative history, which required going from 80 to about 140 to accommodate this. So guess what? The whole, this area between 80 and 140 is now taken, and now there's really no reason left to keep it.

Aaron van Wirdum Okay, hang on. So now there is an actual new protocol being developed, I think, right, called Citrea or something?

Sjors Provoost Yeah. And it's not really about that particular protocol, like it might fail, but the general pattern is clearly useful, BitVMs, et cetera. So if somebody are useful, I mean, like in the sense that people want to use it.

Aaron van Wirdum Yeah.

Sjors Provoost And also Bitcoin Core makes one release every six months. So we cannot just sit back and say, well, we'll see what they actually do and then change it because it takes a long time to deploy these changes. And again, this negotiation position is if they deploy something to mainnet and start using it at scale, and then we say, please use OP_RETURN instead of these fake public keys. They're going to be like, sure, we'll add it to our to-do list, and they'll do it like 20 years later.

Aaron van Wirdum Okay, hang on. Would they use the fake pub key thing otherwise? Like, you confirm that as if you know?

Sjors Provoost It's written, that's in their white paper.

Aaron van Wirdum Oh, it is. Okay, that's actually literally what they would do.

Sjors Provoost Yeah.

Aaron van Wirdum Okay, so now...

Sjors Provoost And what they will still do, unless they...

Aaron van Wirdum So the whole alternative history part is kind of irrelevant. Like, we are just in real... and there is now, it's just a repeat of the original OP_RETURN thing, kind of.

Sjors Provoost Yeah, it was just like, okay, we should increase to 140 because they're going to be doing this and we can still convince them to change their minds if it's before they launch.

Aaron van Wirdum Okay, let's get there then. Why not increase OP_RETURN to, let's call it 160 because it's double of 80 and not remove it altogether. Why not increase the relay? rule to 160.

Sjors Provoost Yeah, that was an option.

Aaron van Wirdum Okay, why not do that?

Sjors Provoost Well then, you're going to have the same discussion again two years later because there's going to be drama. Like every time you try to raise this limit, there's going to be a lot of drama. So if you just look at like changes per unit of drama.

Aaron van Wirdum Not if you're not on Twitter. No drama.

Sjors Provoost No, the drama was on GitHub too.

Aaron van Wirdum That's true.

Sjors Provoost So if you just look at it, do the math from like, you know, amount of drama per change. Like, do you really want to have discussions about, you know, the next protocol shows up and says, oh, we need 200.

Aaron van Wirdum Well, that's probably not going to happen, though, because there's an inscription. But I guess you're saying it might still happen for some reason we don't understand yet.

Sjors Provoost No, so this is a relevant point. They cannot use inscriptions because the trick in inscriptions is a two-stage process. First, you create a transaction that has an output. Like, that's just a hash in Taproot, right? And you can't see anything. You have to spend it in order to put the witness on chain, which is where the data goes. So you have sort of a commitment and then a reveal. Does that make sense? The witness is the part you do when you're spending another transaction. The problem with these protocols is they need to publish this information. In this case, it's a zero knowledge proof. It doesn't really matter. They need to publish it immediately. They don't want to have another transaction that then reveals it. It doesn't really work for them. So they need OP_RETURN, or sorry, they need outputs. Let me be clear about that. They need to do something on the output side of a transaction. The easiest thing to do would be for them to use OP_RETURN on the output side. But that doesn't fit. So they use OP_RETURN plus a few fake keys. And then you could say, well, why don't they just use a bigger OP_RETURN? And even though it's officially not relayed by Bitcoin Core, there's plenty of other nodes that will relay it anyway. There's Peter Todd's Libre Relay project, et cetera. So you could say, why don't they just ignore the standardness rule? And I think, I don't know what the answer is because that's not explained, but my guess is they were just trying to be safe. Because if you're dealing with a transaction where there's, I don't know, a million dollars at stake in some other sidechain project, you don't care about saving a few dollars on Bitcoin transaction fees. You just want to make absolutely sure that your transaction is relayed. So that's why you would use OP_RETURN, so you would not risk using a bigger OP_RETURN and having more hassle to relay it. You would simply do the thing that always works, which is the fake public keys. So this comes back to the negotiation situation where like, okay, just use these bigger OP_RETURNs, we'll allow them. And you'd be like, well... Seems to be a bit of drama around that, so I don't know if we're going to do that.

Aaron van Wirdum So the last part I don't understand.

Sjors Provoost So even now that this change has been proposed to increase or drop the limit, doesn't matter for that use case, if they would look at this drama, they would be like, well, what if this release never happens because people have gone crazy over it? Right. So they would just keep using the fake public keys because it's safer from their point of view. Which I think is an argument for we should have done this two years ago and not had this academic discussion.

Aaron van Wirdum Or... And now I'm going to sort of cosplay, I guess, as one of the opponents to this change. Which I am at least a little bit sympathetic to, I should add. Or at least I like the... Well, let's not get into that. Or... They just bug off some other chain, like Vitalik did, and then not bother Bitcoiners at all, and let Bitcoiners use Bitcoin as money. And then, you know, as long as we're hostile towards all these other use cases, then they'll eventually go away, which is what we want, right?

Sjors Provoost But is that why they proposed using the fake signatures then?

Aaron van Wirdum You mean the fake pubkeys?

Sjors Provoost The fake pubkeys?

Aaron van Wirdum Yeah, well...

Sjors Provoost Because we're allowing those, and that didn't scare them. So I think if you want to scare them away, you have to do something extra, right?

Aaron van Wirdum Well, let's do something extra then. Let's create an environment and do everything we can to get them to bug off so they don't pollute our UTXO set or our chain at all.

Sjors Provoost And we can't assassinate people, right? There's no real world attacks. We have to do only on the blockchain or mempools or nodes.

Aaron van Wirdum Let's make that assumption, yeah. Let's draw a line at physically harming people and let's say, you know, we change the protocol in some way or another, right? So let's then try to keep these people away from Bitcoin. They can do their own things on their own chains, but not make us all download and store this data, either in the UTXO set or even in the mempool or on the blockchain, right? There are ways to fight back against that. So why not put our effort to that?

Sjors Provoost Yeah, so then there are roughly two ways that you can do this, now that we've ruled out physical violence. One is at the mempool level, the policy level, and the other is at the consensus level.

Aaron van Wirdum Right. Let's keep the consensus level out of it as well, unless you want to go there.

Sjors Provoost Well, we need to go there, but let's first go to policy because I think we should explain that there is no point in fighting this through policy. And once we've established that, then the only fight we have left is consensus, and then we can sort of close the argument.

Aaron van Wirdum Okay, fair enough. So why can't we fight back on this on a policy level? Why are you being so defeated?

Sjors Provoost Because you can just run another node.

Aaron van Wirdum What do you mean?

Sjors Provoost So basically, because it's not a consensus rule, not all software has to do the same thing. So Bitcoin Core can say, okay, we're going to do something to fight it, and we have to get into the actual things you could do but regardless of what that thing is we change policy in some magical or non-magical way so that you can no longer relay a spam then some people say well i will run a node that does relay a spam either because somebody's paying me to do it or because i like to be contrarian and i like to run nodes that relay things that people don't like and so then we get to the problem of the mempool being very good at censorship resistance which i think the The nice example, somebody gave at a presentation, I think it might have been Peter Todd, in Prague, was this. You have an audience of 100 people, and you whisper something to somebody in the front row. And then you've told people like either, like you basically told half the room, like do not relay this message. But you whisper it to the guy in the first row and he whispers it to the people around him. Some people don't relay it, but it gets to the other side intact. And in fact, I think you can do this with about 10% of cooperating people because Bitcoin nodes connect to like more than 100 peers. So even if 90 out of 100 peers censor you, the other 10 are enough to get your message through. Your message just needs to go from you to the miner. Just ignoring the incentive to just call the miner directly, right?

Aaron van Wirdum Yeah.

Sjors Provoost So in other words, even if Bitcoin Core were to make these rules that stop relay, if at least, say, 5 or 10% of people don't care about that and run different rules, it's going to get through. And you can, in fact, announce, like, you don't even have to guess, right? We have service bits. in Bitcoin, which are a way for your node to say, I support this feature. Like, I'm a pruned node, I'm not a pruned node, you can get the whole blockchain from me. I support encryption, yadda yadda. So you can basically signal, okay, I will relay anything for the original standard rules, basically. And then if you want to use any of these protocols, then you simply connect to nodes that have advertised that they will relay this for you. And conversely, miners will do this because they want to make as much money as possible, so they don't want to... give up on potentially valuable transactions. So no matter what the actual changes you make in policy, and we can get into these actual changes, it doesn't work because they can be evaded using these methods I just described.

Aaron van Wirdum Well, you say that, and here I'm actually going to push back against that argument. We just established that this new protocol, Citrea or whatever, They could already do everything in OP_RETURN, but they don't. They use pubkeys as well to embed data. So clearly the Citrea people themselves, they don't believe what you just said. They are worried that...

Sjors Provoost They don't want to take the risk.

Aaron van Wirdum Right. So now if you make it even harder for them, maybe they even more don't want to take the risk and just bug off, which is the whole point, right? So on a technical level, I follow you on your thing that...

Sjors Provoost Okay, so now you're talking about a very, very risk-averse actor, right?

Aaron van Wirdum Which they apparently are, because they're embedding...

Sjors Provoost That, or they didn't even think it through, that's also possible, right? They may have just taken the standard of those rules for granted and didn't want to bother going around them. But basically, what they would end up doing is exactly creating more fake public keys. If we said, okay, OP_RETURN goes to zero, they're just going to make more fake public keys. But we could design some countermeasures even for those fake public keys, but we can get to that later. So then the question is, yeah, would they be so risk averse that thanks to these countermeasures, they wouldn't even use the fake public keys. Now the problem is...

Aaron van Wirdum I mean, I can easily imagine you make a filter that filters out, or I don't know if it's easy.

Sjors Provoost No, you can. Yeah, it's not easy, but you can.

Aaron van Wirdum Yeah, you can create a filter that looks at whatever looks like a Citrea protocol transaction. We're not going to relay that. Done. So you can fight back in ways, right?

Sjors Provoost Well, I wouldn't say something that looks like a Citrea transaction, but you can say a more general rule because you don't want to have these super specific rules, right? You just change one letter in the protocol and it doesn't work anymore. But you can say every signature, sorry, every public key that's relayed has to have proof that it's not fake. Like you prove that there's an actual private key and therefore it's more difficult to, you can't make these fake keys anymore.

Aaron van Wirdum Right, well, that's a very complicated way to fight back, but sure, yeah.

Sjors Provoost Yeah, so now the question is, they are not very price sensitive, as we've already established. So they might be willing to pay $1,000 in fees because that transaction represents millions of dollars in some other protocol. So if you're willing to spend a lot more... One thing you can do is instead of having just one fake public key to encode 32 bytes of data, you can say, well, we're going to grind these fake public keys. Grinding just means like brute forcing. And, you know, with a bit of brute forcing, you can maybe put six bytes. let's say instead of 32, you get six bytes, or maybe to keep it simple, let's say 16 bytes. So half of the public key is, so it's a real, it's a real spendable public key. Half of it is gibberish because you can't brute force that part, but the other half is not gibberish, it's signal. So that means your transaction needs to be two times bigger. In other words, it has to pay twice as much fees, but you can still get your spam in there because you've just gone through a little bit of extra trouble. Now, in reality, you probably need to make it maybe 10 times bigger to do this. But 10 times bigger, you know, if the current fees are $1 to get this transaction in, and now you've increased them to $10, but they're willing to pay $1,000, you still haven't really fought the spam, at least for this very, very price -insensitive class of users.

Aaron van Wirdum Yeah.

Sjors Provoost Now, if you have the...

Aaron van Wirdum Go on.

Sjors Provoost Yeah, if you're looking at the JPEG users, there I think a much, much simpler solution is to reduce the block size. like to 100 kilobytes or something, because then it's more expensive for them. However, there's another problem there because they have...

Aaron van Wirdum Well, Luke will support that as well, I think.

Sjors Provoost Yeah, he did in the past. The problem there is that there are people that attach status to the fact that it's expensive. So there might be some of these people putting JPEGs in there that are like, oh, this is too expensive now. There might be others that are saying, great, this is expensive now. There's plenty of millionaires that say, look, I can afford this even with the one kilobyte block size. So I think you'll still fill it up, but your blocks will be smaller, but it will hurt everyone else. But that's already consensus changes, and we were actually talking about relay rules. So for relay rules, the way you would fight the spam is, say, every public key has to have a corresponding signature, and every hash has to have a corresponding pre-image, as it's called. So something that creates the hash. And checking that might be expensive, might create other... attack vectors, so it's not a trivial change, it's a lot of engineering time that goes in there. But I don't think it's going to work, because again, somebody will just say, okay, I'm going to run this Peter Todd version, and if people pay me a little bit to relay, or miners make more money, they'll just go around any of these barriers. So they have to be consensus. If you're satisfied with that argument, otherwise we can keep going.

Aaron van Wirdum Yeah, well, let's stall there for a little longer, and I will drop the debate dynamic here, but let's get real quick into the actual problems that the current limit is causing or would be causing, right? So I think, for example, one problem is that if you want to include a big OP_RETURN in a block, then the way to do that right now would be to contact the miner directly which means that If a miner wants to maximize its profit, it will have to create avenues or APIs, whatever, for people to be able to submit these transactions to directly. But right now, that's really something that requires resources to maintain that and to make that available. Therefore, it's really something that bigger miners can do, but smaller miners cannot. If you're a home miner, you don't have... the ability to do that never mind that you're only finding one block per year maybe so that no one's going to want to use that so there's like a centralizing pressure to keeping the limit rather than making it like rather than making these transactions available for whatever miner wants to mine them only certain miners can mine them so there's centralizing pressure right yes it's one of the arguments in favor of removing the limit.

Sjors Provoost And generally in favor of not trying to block things on the relay network that are economically incentivized. Like there are some things that we're blocking on the relay network that are just pure attacks. Like they will crash a node kind of stuff. But not the, you know, like we talked about the great consensus cleanup, right? These transactions that take an hour to validate, that sort of stuff is also blocked by standardness and really should be blocked by consensus. but isn't yet.

Aaron van Wirdum I think we've now mentioned two arguments. So one argument, it's better that people use OP_RETURN over popkeys. Two, it's centralizing pressure if people have to connect with miners directly to get these transactions into blocks. Are there other arguments in favor of removing this limit that I'm not mentioning right now?

Sjors Provoost So we need to raise it. I think that's because we want people to use OP_RETURN and not use these fake public keys. The question then is, do we need to drop it entirely? And the argument for that is simply that it's cheaper to use inscriptions beyond that point anyway. We don't want to have the same discussion for the next 100 bytes, 200 bytes, 400 bytes. That's just basically a simplification. It's not that we must drop OP_RETURN. There's no point in keeping it anymore. And then, of course, there's a general argument of this is code that needs to be maintained. It's nice to get rid of code. But it's not mission critical that we drop OP_RETURN, right? It's mission critical that we raise it and that we keep an eye on people that need more and be ahead of them so that we don't keep getting back into a situation where somebody says, well, I need a 250 byte, so I'm going to make these fake outputs again and then... You raise the limit, but then it's too late for them to change their system and you kind of keep, you know, you're constantly behind.

Aaron van Wirdum Yeah. Yeah, there's also the argument that if we live in a world where people are submitting transactions directly to miners because that's the only way to get transactions confirmed. then regular users like me, and we don't see these transactions because they're all submitted directly to miners, that means that when I send a transaction, I don't really know how much fee I'm supposed to include because I'm not seeing all the transactions. So I'm making wrong calculations of fee inclusion because I don't know that I'm competing with JPEGs.

Sjors Provoost Yeah, now we don't know how big that effect is, but it could be a thing.

Aaron van Wirdum Yeah, so that's another... That's another argument for removing this limit. This gives a more precise overview of what's actually happening on the network, what's actually likely to be included in future blocks.

Sjors Provoost But the bigger thing is compact block relay. I think we have talked about that before, which again is a centralization risk. So in the beginning, in the olden days, you would get these transactions in your mempool. And then you would get a block and the block would have all these transactions. So people were talking about, like, if you were doing a Skype call, you know, the other guy was using Bitcoin because their Skype call would drop for a second as soon as a new block came in. And so the solution there was rather than sending the whole block, you send a summary of the block, essentially. And the summary says, here's the identifiers of all the transactions that are in there. Hopefully you already know them. If you don't know any of them, tell me and I'll send them to you. So that's a round trip. So ideally. I'm sending you this block, this compact block. You've got all the transactions already in your mempool. You quickly look at it, send it on to the next person, send it on to the next person, and blocks relay really quickly across the network. This has really made a big impact, along with a few other improvements. There's some charts that show how often miners were producing stale blocks, or orphan blocks, as they were incorrectly called. This used to be quite often. I don't know if it's every day, but it used to be very often, and now it's maybe once a month or so. So blocks propagate across the network a lot faster than they used to thanks to compact blocks. If, on the other hand, people have different mempools because they have disagreements on what should and should not be on their node, that doesn't work anymore because I'm sending you the compact block. You look at it and you're like, I'm missing this OP_RETURN transaction. Now I have to send it to you. So this would, again, slow block propagation down, increase the orphan rate. And this hurts small miners more than it hurts big miners. Which is the whole reason for doing this.

Aaron van Wirdum Yeah. Okay, so just to sum that up, I think the arguments for removing it, and we were actually having some sort of debate and we got sidetracked because you still want to get to consensus rules. But anyways, the arguments for removing it.

Sjors Provoost I think it is useful. Okay, let's do that after your list.

Aaron van Wirdum Yeah, summarize this real quick. So the arguments for removing it is, one, people can upload data to the blockchain anyways, and in a more harmful way, we don't allow them to use OP_RETURN with a bigger limit. Two, it incentivizes miner centralization if people have to connect with miners directly, and only bigger miners can do that. Three, it gives a more accurate fee estimation if you're aware of everything that's going on on the network, which ties in also with the direct connection with miners and also connecting. Also, tying in with the direct connection of miners is that your block download and therefore block propagation over network is faster if people have a mempool that reflects the newest blocks because people are just relaying whatever transactions are paying the highest fees. Are there other arguments? These are four of the main arguments for dropping the limit.

Sjors Provoost I don't have a long list, but we kind of went through all that.

Aaron van Wirdum Okay, then let's get back to what happened to fighting all this. You can just fight all this spam.

Sjors Provoost So we talked about fighting this at the level of relay rules and this kind of two-pronged objection. One is that it's circumventable because people can just run different relay rules and advertise that and you only need like 10% of people to do that and you get through it and people might be paid to do it. Miners want to do this. and you're incentivizing direct to miner submission as well, even if you could block it this way. So that leaves only one method of fighting, which is consensus changes. And of course, when is the last time we were able to deploy any soft fork? It's been a while. It's hard to design soft forks. I think we should use the energy that is there to design soft forks very, very wisely, and not for this, mainly because this seems to be a cat and mouse game you can't win. So I already talked about some of the specific things you can do. You could make a consensus rule that just says every public key must have a signature along with it that proves it is real. Now you are making blocks bigger or putting less stuff in it because this stuff, the proof that needs to go in the blockchain. The same with the hash, the pre-image, that's even harder to even prove that, that there is something that belongs to the hash. Then you'd probably have to use a... So I don't know if you understand this problem, but... Anyway, never mind. It's complicated. So then really...

Aaron van Wirdum Too complicated for my brain.

Sjors Provoost I can try, but...

Aaron van Wirdum No, if you think it's too complicated for me, I trust you.

Sjors Provoost But just to [unclear], so if you want to prove that a public key isn't fake, there's a very simple way to do that. You provide a signature, right? Because a signature proves that you know the private key. That's essentially what you're doing with a signature. So that means that every output on the blockchain needs to have a corresponding signature, so... They get bigger, but not hugely bigger. Now for hashes, which you can also use to put fake data in, so you say, hey, I have a hash. Trust me, it's a hash, but it's really not a hash. You need to prove that there is, you know, the pre-image of the hash exists. But how do you prove that? You'd have to reveal it. That's really the easiest way to do it. But you don't want to reveal it. That's the reason why you put the hash there in the first place. And the thing, the pre-image might be 50 megabytes, so you don't want to do that. But even in something like Lightning, where you have a hidden pre-image, that's how you take the payment. Pre-image just means the thing that leads to the hash.

Aaron van Wirdum I know.

Sjors Provoost Yeah. So how do you prove that you have a pre-image that is not a fake hash without revealing the pre-image? And then presumably there's some fancy zero -knowledge proof that can do it. But now you're entering whole new cryptography that we would have to make consensus. So that's super scary. I don't even want to go there.

Aaron van Wirdum Yeah.

Sjors Provoost So that's really the two, I think, most obvious tools that we have. Decreasing the block size would be another one. That's not a complicated fix. It's just something that nobody wants. So it's probably, you can propose it and everybody will say no. And then that's the end of the discussion. So then I think the only way you can really fight spam if you really, really wanted to do this passionately at the consensus level is to say, well, okay, spam is subjective. We need people to look at it and just judge it. And so you would need to say, okay, we're going to assign a public key. Like, we're going to have a vote every four years or whatever it is. And whoever has a private key can censor anything they want. If they say it's spam, we believe them. That sounds pretty bad to give that kind of power. But you could do it as a consensus rule. It's not complicated.

Aaron van Wirdum I mean, that's really bad as a consensus rule. However, it does bring me back.

Sjors Provoost I think that's the ultimate fight, basically, if you really wanted to fight it this way. This is the most powerful weapon you can use against spam is saying, okay, there's a human in charge now of the blockchain.

Aaron van Wirdum Yeah, sure. I mean, this is a straw man. No one argues this.

Sjors Provoost No, I agree.

Aaron van Wirdum I agree nobody argues this. I know you're making a point. I'm just trying to sort of push back a bit where I can.

Sjors Provoost Well, my pushback is this is the only thing that I think could actually work, but we all agree we shouldn't do it. And I think people should be careful when saying, oh, let's just do this one little thing at the, you know, just one setting. Even though if you really game it out to the end, you're going to lose this thing and either you're going to lose or you're going to end up doing something that's horrible, like this super user key. I have not seen anyone propose something serious that actually works.

Aaron van Wirdum Okay. You mentioned setting. You just used the word setting. So I want to get to that. And I don't know. Let's not keep talking for much longer, but I do want to mention the setting thing. Why not let people set their own OP_RETURN limit or their own mempool policy as much as possible? Let people figure out for themselves what they want to download and what they want to relay. Because right now, as I understand, the Bitcoin Core proposal is to just remove the OP_RETURN policy limit. And that's just what you have to deal with if you download Bitcoin Core. Why not just make it more configurable?

Sjors Provoost Because two reasons, I think. One is it's a placebo. And because of the reasons I just explained, it's too easy to circumvent, yadda, yadda, yadda.

Aaron van Wirdum Well, not for my personal, no. My personal mempool.

Sjors Provoost Yeah, but then the question is, do you have feelings about your personal mempool? I assume you have a goal, right? That's more important than what is in your mempool. Maybe, maybe not, but... Again, I still think that's a placebo from a systems point of view. It's like keeping individual users happy about what is in their mempool, making individual users feel good. That almost sounds like the microaggression kind of stuff. I don't necessarily think that's a good argument. But it's there. The other problem is that it's harmful. Because if you set this thing to something else and other users are doing, you break compact block relay. And you don't just break it for yourself. You break it for people around you. Because every node that connects to you fails to relay these compact blocks. So it's a kind of setting that, as an ethical developer, you would have to write in the documentation, do not use this. And then you come up with a philosophical question, like, should you have a setting where everybody agrees it's a bad idea? Is that moral or not? You can have a long debate about that. But I think at this point, if you are, as a user, really do not... believe in what the developers are doing at some point i think you should just use a fork of the software and not force the developers to do something that they consider wrong yeah and so this is where i think in general it should be easier for people to have customized versions of bitcoin Core and not have to say install all of Knots because Knots like adds another thousand other changes that you may not care about um if all you want is this setting for whatever reason you have it's open source software so you're free to write your own software to modify the software. You're not free to force people to add a setting that they don't want to add for you. But I think it would be good if it was easier for somebody to say, hey, look, I've got a modified version of Bitcoin Core. I can prove that it only adds this setting back and nothing else. I think that would be nice. I think it's technically very possible because we have deterministic builds, et cetera. And we still recommend that people don't install that. But, you know, Bitcoin Core developers are not in charge of what people install, basically.

Aaron van Wirdum Yeah.

Sjors Provoost And I think the latest version of Bitcoin Core deprecates the setting instead of immediately removing it, which means it will be removed, but it won't be removed now. So if you're looking for this alternative client, you can wait a little bit longer until the infrastructure is there to have those.

Aaron van Wirdum Yeah. Okay, I want to wrap this up and I want to sort of summarize what I at least think there's a sort of core contention is here or the sort of difference in philosophy in a way. And I think to a large extent it boils down to what you just said and what I think most Bitcoin Core developers apparently believe is that you cannot stop this anyways. So because you cannot stop it anyways, let's do harm [unclear], like, you're not arguing for people uploading JPEGs to the blockchain. That's not what you're doing. You're saying people will do it anyways and people can do it anyways. And the incentives align for miners to... you know, collaborate in doing this. So let's at least make it, you know, as unharmful, at least harmful as possible.

Sjors Provoost Yeah.

Aaron van Wirdum Whereas I think someone like Luke is the perfect example. Luke Dashjr, of course. I think Luke will always pick what he believes to be the most principled position on any issue. And completely disregarding how plausible or feasible or realistic achieving that is. He will just go for that. And that's sort of his, the only thing that he will say, like another good example is, you know, he's been advocating for decreasing the block size limit. He was doing that during the block size wars. He was doing that. Like, well, everyone was talking about increasing the block size limit. Are we going with four megabytes or eight, or is it going to double ever? And he was talking about decreasing the block size limit. It was like so far outside of the Overton window.

Sjors Provoost Yeah, and for good reasons, by the way.

Aaron van Wirdum Well, I think that's an important point to point out. Luke sometimes sounds crazy, but it would not be the first time that years later people will say, well, Luke was maybe kind of right, or at least he had a good point. So that's why, at least for me personally, I will always listen to what Luke has to say, even if it sounds completely crazy.

Sjors Provoost Well, yeah, listening is generally a good idea. If you're able to filter the signal from the noise, you should definitely find the arguments that are out there and parse them. And even if you think somebody, you might disagree with the person on 99.9% of the things they're saying, you still want to find a way to find that 0.1% that you completely agree with.

Aaron van Wirdum Yeah, and in Luke's case specifically, like I said, I think he's a good example of what he says is just a complete disregard of the Overton window, of what's socially acceptable, of anything else. He just... says what his principle is and that's what you should be doing. So an argument like, well, we're not going to be able to stop it just does not work for him because he will say, no, we need to stop this because it's bad. So the only thing we should be doing is focusing on how to stop it.

Sjors Provoost Yeah, but I think he's been much less clear about how far he wants to go.

Aaron van Wirdum Yeah.

Sjors Provoost If it's only fighting at the standardness level or, you know, he wants to fight at the consensus level.

Aaron van Wirdum Right.

Sjors Provoost And I think that's... because then you can sound very principled, but you're not because you're not really willing to go all the way there. But, you know, if you had to steelman, you could say, well, it's just about creating a perceived threat to people, you know, creating a perceived threat, even it could be a bluff, but it might be enough to kind of signal that to the people that are doing these protocols. Look, I think where we would agree is that these non-monetary uses are not something we should optimize for. It's something that exists. I don't necessarily think we have to actively fight it, but I, you know, I think Bitcoin should be censorship resistant money. And, you know, then you have limited resources and you have spam and you have some mitigations against it.

Aaron van Wirdum Yeah. I mean, let me be clear in case that wasn't. I personally also fall more on the pragmatic side or, you know, the Bitcoin Core sort of side of the arguments here where it's like, you're not going to be able to stop this. It's like RBF all over again. It's the same thing in my view. But there's also still a bigger point in one direction. Let's just do some harm reduction. It's not that big of a problem. I think the real, you know, the real spam... limit that we have is the block size limit itself that will eventually, if not already, just outprice spam. It's basically the original reason Adam Back even came up with Hashcash, just make spam expensive and then it will go away. Essentially, we see that in Bitcoin or we should see that in Bitcoin as fee pressure.

Sjors Provoost Well, it was his hope, but it may turn out the opposite, right? It may turn out that making spam expensive is what makes it interesting and you'll always have some of it. But you can at least limit the damage it can do. And if you look really long-term, there's proposals like Utreexo that make the UTXO set go away. We did an episode about that many years ago. And well, then suddenly you no longer have this argument of we don't want to pollute the UTXO set. So then the whole game theory changes and you might say... We can have OP_RETURN because we don't care if people make fake public keys because nobody's going to see them because they go into this accumulator. The game theory could change 10 years down the road, but those protocols are not concrete enough that we can count on them.

Aaron van Wirdum Okay. Is there anything we forgot to mention so far?

Sjors Provoost Probably, but we spent quite a bit of time on this.

Aaron van Wirdum I'm sure there's arguments on both sides we didn't mention, but let's wrap this up. Slowly but surely. Or maybe just right now. Right now.

Sjors Provoost Let's put the whole episode on an OP_RETURN.

Aaron van Wirdum No.

Sjors Provoost Thank you for listening to Bitcoin.

Aaron van Wirdum Explained.