OP RETURN Wars - Episode 61

Aaron van Wirdum Live from Utrecht, this is Bitcoin

Sjors Provoost Explained.

Aaron van Wirdum Hey Sjors.

Sjors Provoost What's up?

Aaron van Wirdum How exciting. Two weeks ago you told me that maybe you would go to Bitcoin Amsterdam.

Sjors Provoost Yes.

Aaron van Wirdum And now you're a speaker.

Sjors Provoost I'm a panelist. Probably. Not a real speaker.

Aaron van Wirdum That counts. That's a speaker in my book, Sjors.

Sjors Provoost Sounds good.

Aaron van Wirdum How exciting. Sjors, today we're going to discuss the blog post by BitMEX Research.

Sjors Provoost That's right.

Aaron van Wirdum Which is about the OP_RETURN wars.

Sjors Provoost Exactly. Very nice clickbait title.

Aaron van Wirdum Do you remember what the name of the blog post is? Was it just the OP_RETURN wars?

Sjors Provoost It's called the OP_RETURN wars of 2014, dApps versus Bitcoin transactions. And it's a slightly clickbaity title because, well, it was only called wars by certain other people.

Aaron van Wirdum But wasn't it referred to as the OP_RETURN wars previously in your memory?

Sjors Provoost Yeah, but some people object that the OP_RETURN wars have been sort of that term was phrased by people trying to launch various coins and trying to make Bitcoin developers look bad.

Aaron van Wirdum Right.

Sjors Provoost Not everybody likes the term.

Aaron van Wirdum Okay, fair enough. Okay, so let's start at the beginning. This has been, we've discussed this in some of our episodes here and there before, I think. But first of all, Sjors, what is OP_RETURN?

Sjors Provoost So when OP_RETURN appears in a transaction, so in a script, then as soon as that happens, the script is invalid. And so a nice example, and so the most practical form to use that would be that your entire script starts with OP_RETURN. And then it follows whatever you want to put there. For example, some random text. Because when a script is invalid, you know it's not going to run. And that means that nobody can ever spend it. Because no matter what you do, it's always going to be invalid.

Aaron van Wirdum Right but that to me sounds like the transaction would be invalid.

Sjors Provoost Oh no no it's an output of a transaction. So if you're sending to an OP_RETURN transaction so if you're sending if your address quote-unquote so the script on the blockchain is an OP_RETURN followed by anything, then whoever tries to spend it will find that their transaction is invalid.

Aaron van Wirdum Right okay so you can send to an OP_RETURN. It's just provably unspendable. You can't spend anything from an OP_RETURN.

Sjors Provoost Exactly.

Aaron van Wirdum From an output that has OP_RETURN in it.

Sjors Provoost Yes, and because it's provably unspendable, that allows software that processes the Bitcoin blockchain to make some optimizations. It can basically just pretend that those coins don't exist. But whether they really exist or not is kind of in the eye of the beholder. They're there, but it's impossible to spend them.

Aaron van Wirdum Right. An OP_RETURN has always been in Bitcoin? Has it always been... it's a a function in Bitcoin. Has it always been possible?

Sjors Provoost As far as I know yes. And and so that means it's also been always been possible to put anything you want after the OP_RETURN code right?

Aaron van Wirdum So you could always create a transaction with OP_RETURN. However and now we'll get to this in a second I think originally… Transactions that spend from an OP_RETURN. No, wait. Transactions that spend to? Wait, now I'm confused.

Sjors Provoost Yeah, as far as I know, originally, if you created a transaction that spends to an OP_RETURN, then nodes generally will not relay that transaction. They would simply ignore it. However, if they saw it in a block, they would be fine with it. So that's called standardness. In this case, it's not standard. So standard transactions are transactions of a specific shape and form. Those are automatically relayed. And that's partially to prevent people shooting themselves in the foot by creating a transaction that's just wrong. And there's probably some other reasons that we can get into in another podcast.

Aaron van Wirdum Right, yeah. So an OP_RETURN was always possible, but Bitcoin nodes generally just wouldn't forward it to other nodes.

Sjors Provoost That's right.

Aaron van Wirdum So it's very hard to get it into an actual block.

Sjors Provoost Yeah, you'd have to talk to a miner.

Aaron van Wirdum Yeah, and then the miner would have to put it into a block because I assume that mining software also by default just wouldn't include it in blocks, right?

Sjors Provoost Yeah, so either you would have to know which node is a miner and then maybe that miner is configured that they do consider it standard, but more likely the miner would have to manually include it through some process.

Aaron van Wirdum Right. So at some point, and this is what the blog post is about, at some point it was decided that Bitcoin nodes, Bitcoin Core nodes specifically, although back then it wasn't even called Bitcoin Core yet, they would actually start forwarding some OP_RETURN transactions, right?

Sjors Provoost Yeah.

Aaron van Wirdum So why was that?

Sjors Provoost Yeah. So in roughly the end of 2013 or the beginning of 2014, there was a release of Bitcoin Core that would let you... that if there was less than 40 bytes or 40 bytes or less after the OP_RETURN message it would be standard so you would relay those And then later on, as we'll discuss, it was increased 80 bytes. And so the reason is it was kind of, I think one of the analogies that was used, or many analogies used, I'll stick to the, let's say the friendly ones, is this idea of people were breaking windows all the time because they're trying to get inside of a house. And it was nice to, you know, just leave the window open, basically. So it was actually a form, it was meant as a form of damage control.

Aaron van Wirdum Well, before we get to the analogy. Well, now you've given the analogy, but what is it an analogy for? What are we actually talking about?

Sjors Provoost What is the actual damage, right? Why were people breaking windows? So basically people were trying to put things on the blockchain that are not transactions, that are not moving money, but that are sharing information. And one example of that, which I'll shamelessly plug, you can also find in my book, is to put the Bitcoin white paper inside the blockchain.

Aaron van Wirdum Right.

Sjors Provoost And the way they would do that is to create a transaction that sends money to a multisig address. And that multisig address would have three keys. But those keys, you know, would not actually be keys because a public key would, you know, be a nice piece of data, but they wouldn't be actual keys. And it turns out that if you add up all these fake keys, you can reconstruct a Bitcoin white paper. Now, the problem with that is that for nodes who are looking at the blockchain, those transactions look like they're real. They look like they're really sending money to somebody and that somebody apparently is a multisig owner. This is where the problem comes in. Nodes don't only need to relay those transactions and store them in the blockchain. They also need to keep track of this thing called the UTXO set. So there's a set, usually kept in memory, if at all possible, of every coin that currently exists. So when you create a transaction, you're spending a coin, so those coins no longer exist and you're creating new coins and those coins do exist. That's what you need to keep— keep track of and so these… This white paper and this other stuff that was put in that way has to be kept track of by nodes even today even though nobody will ever spend it, you still have to keep track of it. And so the solution is to use OP_RETURN now you can still put that kind of data on the blockchain if you wanted to, but nodes don't have to keep track of it because they know it is not spendable.

Aaron van Wirdum Right so to… go one step back or tackle that step by step. So originally, if you wanted to include data in the blockchain, could be any type of data, you gave the Bitcoin white paper as an example, then what people would originally do is basically break down the Bitcoin white paper into data and then create public keys that aren't actually public keys because there are no private keys for them. And these public keys would just include the data that is the Bitcoin white paper, right?

Sjors Provoost Yes.

Aaron van Wirdum Right. So and then... That's transmitted over the Bitcoin network. Everyone verifies these as transactions. It's included in the blockchain. And then it's also included in the UTXO set. Now, with OP_RETURN, it's still included in the blockchain.

Sjors Provoost Yes.

Aaron van Wirdum However, it's not included in the UTXO set. That's the real difference there, right?

Sjors Provoost Yeah, exactly.

Aaron van Wirdum No, it's just no. These coins are provably unspendable, so we don't have to store these in the UTXO set.

Sjors Provoost Yeah, so this saves some time because now when, you know, you still have to download the blockchain, you still have to check every block. That does not change. But the difference is that this little database that you're keeping of the UTXO set, that no longer has to grow. And you can also normally throw away old blocks. So if you have a small hard drive, you can always toss out the old blocks, but you can never toss out anything from the UTXO set.

Aaron van Wirdum Yeah, so the two main benefits are, first of all, storage, especially for pruned nodes that don't store the entire blockchain because they now have a benefit, because they have a smaller UTXO set. And the other one is computational. When a new transaction comes in, there's a smaller UTXO set to check the new transaction against.

Sjors Provoost Yeah, so I guess a better way to say that is it's potentially saving you memory. So ideally, you want to keep the entire UTXO set in RAM. Now, that's already not possible these days. I guess back when this discussion was happening, the UTXO set may have been much smaller, maybe a few hundred megabytes. Now it is over 10 gigabytes. So for now, most people, unless you have like 20 gigabytes of RAM, you're probably not holding it in RAM anyway. But it is nice. If you can keep the UTXO set in RAM all the time, it's much faster. And we did an episode about that. It is episode 15, in which we explain a mechanism that could solve this problem called Utreexo.

Aaron van Wirdum Right.

Sjors Provoost And that would remove the need to keep the UTXO set in RAM, but it comes at the expense of some trade-offs. And we just explained those there.

Aaron van Wirdum Okay, let's stick to the OP_RETURN for now.

Sjors Provoost Yeah.

Aaron van Wirdum So people were storing data in the blockchain. This came at a cost for people that were running full nodes. And so at some point developers figured, okay, look guys, if you're going to store data in the blockchain anyways, then please use OP_RETURN, and that way there's a—there's a smaller cost to all nodes.

Sjors Provoost Yeah, but there was a second request too, I would say, because this limit of 40 bytes.

Aaron van Wirdum Yeah, I was going to get there. So OP_RETURN was always in the protocol, but it was basically useless because nodes wouldn't forward OP_RETURN transactions. And then Bitcoin developers said, all right, guys, you're going to store data anyways. We'll allow, we'll effectively enable OP_RETURN. But then the next debate was about the size of the OP_RETURN messages.

Sjors Provoost Yeah, exactly. So one number you could have used for that size was to say, okay, how big can these multisig transactions be? And I think that was 172 bytes. So you could have said, okay, we're just going to make OP_RETURN 172 bytes. Because in that case, there is really no reason to use these multisig keys anymore, because you might as well use OP_RETURN. But there was a simultaneous, I guess, movement or desire to not make the blockchain unnecessarily big. And I think it's useful to look at that in perspective. So right now, there is a fee market. So that means that if you're putting a lot of data onto the blockchain, it's going to be very expensive for you to do that. Or at least there's a mechanism to make sure that useful stuff goes on the blockchain more easily than useless stuff, depending on if you define useful by how much you're willing to pay for it. But back then, blocks were super small. They were maybe 10 kilobytes or 100 kilobytes. I don't know where they were in 2014. And that meant that this OP_RETURN data could just make blocks really big, for the time that happened. And we've done an episode in the past where we looked at, I think it's episode number 55, where we looked at old Node software and see how that old Node software would perform under the current block sizes. And it turns out that very old Node software, especially from, say, 2012, would not have been able to keep up with actual 1-megabyte blocks, or at least not very easily. So back then, it was actually necessary to keep blocks small, basically from a more altruistic point of view. And that's what a lot of the discussion was about. Like, what is good behavior on the blockchain? Yeah.

Aaron van Wirdum So why was, so the first limit that was set, well, initially the limit was zero. Initially, OP_RETURN was effectively impossible. But then the limit was increased to 40. And why was it increased to 40?

Sjors Provoost Okay, so the idea behind 40 is that it allows you to put a hash. In there, a typical hash using normal cryptography like SHA-256 is 32 bytes. So this allows you to put a 32 byte hash on the blockchain and then a few extra bytes to do, I don't know, some metadata for that hash. Now, there were some protocols out there that wanted 80 bytes.

Aaron van Wirdum Yeah Counterparty in specific. Yeah this is what sort of this blog post that is the reason we're making this podcast, that's the main example that's given. It's basically about the Counterparty protocol.

Sjors Provoost Yeah so I don't know for sure, if the increase to 80 bytes was only for Counterparty or whether there was another protocol that needed it but basically there was some back and forth, and and I guess people decided to just allow 80 bytes, but but really, 40 should be enough for most things, but it requires a little bit more work for those protocols. So if you look at something like,

Aaron van Wirdum As far as I know, the reason 40 is enough is what you're saying is because really the only data you ever need to include in the blockchain really is a hash.

Sjors Provoost Yes.

Aaron van Wirdum Because then you anchor any other data you want to anchor in. And that's really all you ever need to do.

Sjors Provoost Yeah. So if you're building some sort of other protocol, and we talked about OpenTimestamps in an earlier episode, we talked about other things. Generally, that protocol has its own software and that software should take care of its own data. It should have its own peer-to-peer network, essentially. It should send its own data around. Maybe that data is a blockchain. Maybe that data is something else. But that's more complicated to implement because now you have to build your own peer-to-peer network. And so a lot of these protocols back in the day, and very likely Counterparty as well, prefer to just shove everything onto the Bitcoin blockchain and not have to deal with that complexity. And so that was some of the discussion about. But Counterparty was using the multisig solution in the beginning. So they were putting data on the blockchain anyway, and so yeah I guess then it makes more sense to say, okay let's just increase the OP_RETURN limit to 80 bytes so they stop doing that right.

Aaron van Wirdum So at first it was increased to 40. This was in 2014, and the argument there as we explained what you explained, is that you really only need 40 because you can just include a hash. But then people you say the Counterparty project it was using more than 40, for whatever they want to do so essentially Bitcoin developers conceded and said all right well if you're going to do it anyways, here's 80 here have fun with it with your 80. You definitely…

Sjors Provoost I think that's how it went, but there may have been other projects there too that needed 80s for some reason. Now there is some confusion because if you look at the original proposal so the original release that had the 40 byte limit there was also a pre-release so with Bitcoin or Bitcoin Core anyway nowadays what happens is when you make changes they go into a pull request on GitHub. And then once they're approved, they get merged and they end up in this master branch. And this master branch is sort of a working copy, which is not released, but anybody can run it. So there was a time when there was a limit of 80 if you were using that master branch of Bitcoin. But generally, that's not considered final software. It could have bugs in it, etc. So before that release came out, it was reduced to 40. Does that make sense? So there was a limit of 80, but only in unreleased software. Then there was a limit of 40 in the release software. And then much later, there was another limit of 80. And so some of the fight, war, whatever you want to call it, seems to be about that.

Aaron van Wirdum Ah, yeah. They announced 80.

Sjors Provoost It was sort of seen as a revoking of the 80.

Aaron van Wirdum Right.

Sjors Provoost But that was never really released.

Aaron van Wirdum Right. Got it. It was never 80, but it was announced to be 80. And then it was brought back to 40. And that's what threw some people off.

Sjors Provoost So I think what happened is there was this OP_RETURN thing was introduced in the code and they just picked 80 as the first number. Then there was, I think Jeff Garzik put it on the mailing list saying, hey, we should probably talk about that. And then people said, okay, let's make it 40. And that was what went into the release. So, and then there's, you can find newer discussions where people said, oh, you know, we told you about Counterparty. And then I think Greg Maxwell would say, no, you didn't. You told us after basically this release and then we increased it. But, you know, so that's a whole fight about what was the sequence of events there.

Aaron van Wirdum So, and right now the limit is 80.

Sjors Provoost Yes.

Aaron van Wirdum Yeah, and there was a minor maybe mistake in the blog post where it said that currently the limit is 83, but you say it's just 80, right?

Sjors Provoost So the amount of data you can put on it is 80. However, the size of the output, so what the script on the blockchain would look like, is 83. And the reason is because you have one byte that says OP_RETURN, then you have another byte that says, I'm going to give you a bunch of data now, and then another byte that says how much data. So that that would be 80 bytes for example and then the data itself so that in total that's 83. And there's some some weird edge cases where you could have like one OP_RETURN and then say I'm gonna… And then you could say I'm gonna give you five bytes of data and and now I'm gonna give you another five bytes of data. So there's like ways of grouping your data. There's just very subtle implementation details but as long as you stay below the 83 bytes for the whole script you're fine.

Aaron van Wirdum Right now one thing you already alluded to, is that back then back when this discussion was happening I think people were really looking at the Bitcoin blockchain as sort of a shared resource, and they weren't thinking about it as much it seemed like like we would today as a market. So today we In general, I think we have more of this idea that whoever is willing to pay the highest fees gets into the block. And we have a block size limit to protect nodes, essentially, to protect users from having to store too much data. And back then, people weren't really thinking about fee markets yet. There were no fee markets yet. So it was really just considered a shared resource. Now, from today's perspective... don't you think it would make more sense to just remove any OP_RETURN limit and just say whoever wants to pay for it will pay or put differently, would you say that maybe the people that were making that argument What was it eight years ago? Maybe you were right that it should have just been allowed and whoever pays pays.

Sjors Provoost I'm not sure. So one of the things is that the fees that you're paying go to miners. They don't go to node operators. So every node operator is still somewhat altruistically running these things. So you'd still want to see what you want node operators to do for you. Do you want them to store your Bible or do you only want to do payments? So you could still have that argument that even if somebody was willing to pay a very high fee to miners to include lots of OP_RETURN data, you could argue, well, but they're not paying the node operators to store that OP_RETURN data and people are not running nodes to publish the Bible or whatever.

Aaron van Wirdum But they don't have to store the data. Though they still need to verify it once.

Sjors Provoost Yeah they still need to process it. Yeah so but yeah the burden is a bit lower especially when you use OP_RETURN and it's much better than the alternatives. On the other hand, there's also now things like RGB and things like OpenTimestamps various other projects that show that you can just use a single hash or even not a hash at all, because from a privacy point of view things like a tweaked signatures tweaked public keys or tweaked signatures are even a more privacy friendly way to put data on the blockchain, which also makes them indistinguishable from regular transactions. That one thing, that means that you can't stop it, whatever you do in the protocol. But it also means that by using the protocol in that way, even though you're using it for something that's not moving money around, you are helping the people that are moving money around because you're creating a bigger anonymity set for everybody else. Because you're just creating a bunch of noise between all the transactions.

Aaron van Wirdum Right. Well, that could also be considered an argument for removing the limit. It's like you say, if you can create it anyways and no one can even see that you're just creating data that's non-transaction data, essentially.

Sjors Provoost You can't see it if you're not using OP_RETURN. So those protocols that use tweaked signatures don't use OP_RETURN at all.

Aaron van Wirdum Well, that's what I mean. So at that point, why don't we just say, okay, people can put data on the blockchain and we [unclear] stop them. We might as well just make it easy and have it done in such a way that it doesn't impact the UTXO set.

Sjors Provoost But then it's actually hurting privacy because if people start using OP_RETURN for their data instead of these more privacy-friendly ways, then they're just hurting their own privacy. But as far as I know, there's nobody currently... with a serious proposal of why they would need bigger OP_RETURN messages. I think Bitcoin SV is experimenting with very, very, very, very large OP_RETURN messages and has 99.999999% of their chain with OP_RETURN data. So I don't know how I would feel about it, but so far I don't think it's a relevant question.

Aaron van Wirdum So the general idea behind, and I, I think this is what you mentioned when you said some people don't like the term OP_RETURN wars, is that this part of Bitcoin's history is sort of considered by— Vitalik decided to launch Ethereum.

Sjors Provoost Yeah, but that makes very little sense because he could have used, if, if Bitcoin was, you know, if he needed OP_RETURN, then he could have done the same thing with OP_MULTISIG. So I don't think that... particular thing would have made the difference. It's not possible to run Ethereum on top of Bitcoin with or without OP_RETURN.

Aaron van Wirdum And the other thing anyone can do, of course, is just fork Bitcoin Core and allow for bigger OP_RETURN messages since it's not a consensus rule.

Sjors Provoost So, you know, maybe the lesson from that discussion was that Bitcoin was clearly not going the way of allowing everything and everyone to do complicated things on the blockchain. And that may have been a realization point for him to say, OK, if Bitcoin is not going that direction, I'll try my own project.

Aaron van Wirdum Yeah I think that's sort of the argument or that's also the argument sort of presented in this blog post that it was a cultural thing that the Bitcoin culture at that time was not very accommodating to non-transaction data on the blockchain and that's why Vitalik decided to start his own blockchain.

Sjors Provoost Perhaps might also have something to do with being able to make money but… And of course the nice thing about having a new chain is you know you can do whatever you want, so it does give you a lot of creative freedom. That's the more optimistic interpretation of it.

Aaron van Wirdum Yes they can clearly do whatever they want. We cover everything about OP_RETURN?

Sjors Provoost I think so Well, it might be fun to mention there was an incident in 2019, a project called VeriBlock, which I believe has Jeff Garzik as their advisor. And at some point, there was a lot of increase in the number of OP_RETURN transactions. Not the size of them, just the sheer number of them. To the point where they were starting to compete. They had to pay some pretty high fees to compete with regular transactions. And it was interesting to watch. And there was kind of a worry that this would just mean that OP_RETURN transactions are the buyer of last resort. And every block from now on will be full.

Aaron van Wirdum That was basically an altcoin that used Bitcoin's proof of work as its security.

Sjors Provoost Yeah, I believe so. I think roughly what the idea was is that people on that altcoin would create candidate blocks, basically. And the hash of those candidate blocks would be on the Bitcoin chain. And then whoever paid the highest fee on the Bitcoin chain would be the winning block on that chain. So you'd have lots and lots of Bitcoin transactions, each with a hash that could represent the future block. And then whichever has the highest fee would win. So it would be a nice way to give money to Bitcoin miners. But last time I checked on CoinMarketCap, it said market data is untracked. So... It sounds like that's not going very well.

Aaron van Wirdum It doesn't sound very good, Sjors.

Sjors Provoost But who knows?

Aaron van Wirdum Okay, I think that's it or not.

Sjors Provoost Yep, that's all I got. So thank you for listening to Bitcoin

Aaron van Wirdum Explained.