Take_099 - OP_RETURN The Signal and the Noise

May 09, 2025 00:59:47
Take_099 - OP_RETURN The Signal and the Noise
Bitcoin Audible
Take_099 - OP_RETURN The Signal and the Noise

May 09 2025 | 00:59:47

/

Hosted By

Guy Swann

Show Notes

In this episode, I break down one of the most contentious mempool debates in Bitcoin’s recent history — the proposed removal of OP_RETURN limits. I explore what the change actually means, why it’s causing such a stir, and what both sides are getting wrong. Is this a technical clean-up or a social signal with dangerous implications? Could it quietly invite back the crypto spam Bitcoin has fought to shed? I do my best to separate the signal from the noise, stealman the arguments, and offer my own perspective on why this fight matters more than it seems — and maybe, why it shouldn't have started at all.

 

Host Links

Check out our awesome sponsors!

Trying to BUY BITCOIN?

Bitcoin Games!

Bitcoin Custodial Multisig

Education & HomeSchooling

View Full Transcript

Episode Transcript

[00:00:00] Something that had been in place for again more than a decade and that had been a clearly contentious issue for the entire time, was suddenly made a quite broad and sweeping change that not only removed the limit, which was going to be contentious, but is trying to remove the configuration option to keep the limit in any way that the node actually want, that the node runner actually wants to. Nobody should have been confused that this was going to be horribly contentious. It has been from the beginning. [00:00:52] What is up guys? Welcome back to Bitcoin Audible I am Guy Swan, the guy who has read more about Bitcoin than anybody else you know. And first off, before we jump into it, we have the latest Financial Freedom report. It's number 72 from the Human Rights foundation and there's a couple of really cool details if you haven't dug into this yet. So Belarus and Russia are actually partnering to make a cbdc a system that both will use that gives them unprecedented control and surveillance over what everyone is doing. [00:01:24] Details are in that Russia is also launching a state run crypto exchange that literally only the ultra wealthy are going to be able to use. And it just I find it interesting how explicit the state can be in just in purposefully screwing over the everyday citizen at the in order to make the wealthy wealthier and then people still think the state is going to be the solution to their problems. [00:01:50] In better news however, Ecash has made a very interesting debut in Cuba. Boltz has now changed their limits and has a special swap line for Nostr Zaps so you can send somebody 21sats even if you're using even if you're swapping between Lightning and Liquid and lightspark just released a state chain implementation so that you can have fast private off chain transactions where you are actually exchanging keys to the coins. If you want to find out more about this stuff you can sign up to their newsletter at the link below or you can check it out on nostr. That's how I keep up with it. I highly recommend it. And the HRF is just an amazing organization and kudos to them for the incredible work that they do. Next up, if you were looking for an easy to use and beautifully designed mobile wallet that is self custody on chain and Lightning that just works and it's intuitive. BitKit the BitKit wallet is a fantastic tool if you have not tried that out. If you do not have that in your toolbox, especially with all the things they are doing with pubkey and plenty of new peer to peer and sovereign tech to come, you should stay tuned on that one. And you should check out BitKit link in details again in the show notes. [00:03:05] Okay, so OP Return has turned out to be a really, really contentious issue. And it's kind of funny how innocent the supporting side is being like nobody knew that this was a contentious issue and that this hasn't been kind of going on for 12 years. But you know, I don't want to get ahead of myself and I and this not. That's not really the point of this. I'm not trying to like crap on one of the sides here because I am opposed to the change that is being proposed, but that's not the point of this episode. So if you are lightly into bitcoin or this is worrying you a lot, or you just don't know what to think about any of this because this is the first time you've ever heard the word OP Return, you can be forgiven for being completely confused and also thinking that the end of bitcoin is nigh. Neither one of those things is true. Don't worry. This is largely an issue that just extremely nerdy people like myself actually care about. And one of the interesting things about this particular episode of this same debate that has come up many, many times in bitcoin's past is how contentious it is versus how, how non existent. The explicit issue that has caused this to come back to the surface is in moving the needle either direction. And this is part of why I personally come down pretty hard on the opposing side. However, I have read tons of posts from people who oppose what is currently being proposed as a change for bitcoin core, saying stuff that is completely wrong, completely wrong, and also not relevant to the singular issue at hand. But I have seen the exact same thing from the people who support it, or they're bringing up a technical issue in which they're only presenting one side of the coin or just misrepresenting an issue that hasn't even really been part of this, which could maybe be on purpose or just completely out of ignorance. So I want to take this episode in order to do my best in separating the signal from from the noise. I want to steel man, both sides because I feel there's not been too many people to do that, honestly. And I am perfectly willing to note that I am opposed. But I don't want to kill anybody who's on the supporting side. And I take no issue in giving them the fairest shake that they can for their argument because there are very real technical concerns that they bring up. I just don't think they are the full picture. And. And I want to present both sides as honestly as I think I can. And hopefully at the end of this, you can walk away feeling like you have at least some better hold on the issue, or just safely knowing that you really don't give a shit. All right, so to do this, I'm going to pull together a handful of posts, Twitter threads, that sort of thing, quotes from people who've just made an argument one way or the other that I think are actually substantial arguments, and try my best to explain them in simple terms when they're a little hard to follow. Maybe the technical discussion is pretty nuanced, so you're forgiven if you don't see the whole picture, but I also want to cover, from both sides, arguments that keep getting pulled out and thrown into this, into the discussion that are neither accurate nor relevant, in my opinion, especially to this particular issue. So what's the issue? What has explicitly happened very recently that's got everybody in a tizzy, because it seems like 80% of the discussion basically doesn't have anything to do with the actual thing that came up on GitHub. So instead of refreshing the big picture argument that has been had for 12 or so odd years, let's get into the specifics. What just happened? Opreturn is a part of Bitcoin that allows people to put arbitrary data into a Bitcoin transaction, but specifically, it makes it obviously unspendable. This is obviously data that people don't have to worry about, you don't have to validate, because it has nothing to do with the actual ownership or confirmation of the transaction. It's just attached. I could put in a recipe, an image. Doesn't matter, it's just data. This has been strictly limited for more than a decade to a very small amount. And there have been extremely vicious debates about exactly which small amount it ought to be. The optimum small amount is clearly this much. I will literally fork the chain if it's any more than this much. Another important note, this has nothing to do with consensus code. Any node on the network can set the Opreturn limit to whatever it wants, and it will still just accept whatever transactions according to its policy, with or without, with more or less arbitrary data, just whatever shows up on the network. This all has to do with Mempool policy, which is a great way of saying, what does my node do with all of the crap that's being thrown around the network that that we're about to put in the next block? Nodes have been able to set this Manually for basically the whole time. So what is the change that has been proposed? Completely removing the limit and then importantly removing the option to configure the limit entirely. So there is no limit and nobody can put one back in. They cannot manually set it. If they upgrade their client to the latest bitcoin core, they will not be able to manually set it back to what it's been for most of bitcoin's history. Now, there are very good reasons potentially to do this, and there are reasons to not do this. The reason this particular incident of this became so contentious so quickly is that as soon as they published this on the GitHub, elements of this seemed pretty pointed, especially on a topic that has been so contentious for the entire time, because this is not the first time that this change has been proposed. And last time it went about this well. And so a lot of the detractors went up on GitHub and explained their opposition to this change and they got banned from the discussion. In particular, bitcoin mechanic. It was a perfectly rational assessment to think that this was a big, giant middle finger to everybody who has been on the other side of this issue. That sounded eerily like the statement, we're gonna do this anyway and it doesn't matter if you disagree. And frankly, there is no more perfect fuel for social media. And thus here we are. That is what has brought up this issue in this particular incident. Now, at the end of this, I really want to hit a point that I think a lot of people opposed to this measure are dancing around, but maybe not properly articulating. So I hope that I can help there. And you've probably heard people say that this is only a technical issue, and then other people say that it's not a technical debate at all, that the technical side is irrelevant. Both are kind of true in a way, and hopefully it makes more sense at the end of this. All right, so to start, let's get some of the bad arguments out of the way first. This will not make it harder to run a node. Everybody is saying that this makes sense in the general context of, oh, are you storing random data on chain versus are you not? Which would mean that we have a bigger blockchain than not. And yes, storing and being a good steward of the chain is a costly endeavor that nobody gets paid for, and you can't really pay anybody for it because it can easily be sybil attacked. And that's why we have proof of work, is because you don't know who's helping and who's not or who's just a bunch of fake bots. Running a node has to be voluntary, and having to store a bunch of people's dick butts and garbage NFTs is a cost. It is a burden on those nodes. However, we fully expect and want blocks to be completely full all the time. We want them to be monetary transactions and not dick butts, but nevertheless we want them to be full always. And there is a strict block size limit. This does not change that. So in a world where all blocks are full like we want them to be, there is a fee market. Whether this limit exists or not will not change how difficult it is to run a node. The blockchain will continue to get bigger at the rate that it has continued to get bigger. Actually, there's a stronger argument though. I do also think this is a little bit of a red herring that removing the limit will make it easier to run a node, because one of the main arguments on the supporting side is that we simply cannot completely prevent arbitrary data from being put on the bitcoin chain. That's 100% true. And I think most people on the opposing side know this, but some apparently don't. The whole inscription debacle should have made this rather perfectly clear. We have OPER turn limits, but they got around it just by creating a fake signature, more or less, that can't even be objectively determined as unspendable, but which is unspendable. Which is actually worse to store JPEGs that way, because at least with Opreturn you can just drop the UTXO knowing that there's nothing anybody's going to do with it. Whereas in this case you have to keep the utxo. And one of the most costly things to deal with for small devices is, is a huge UTXO set of where's the next transaction going to come from that you have to keep in memory. So in my opinion, the case that this makes it harder to run a node is not as strong as the case that this makes it easier to run a node, and that that's part of the purpose, because we would want people to use Opreturn instead of inscriptions. However, there's a pretty significant reason why they still just wouldn't use use opreturn, but somebody else might come in and use it. But I'll get back to that point in a minute. Now, where the supporters of this take it too far is that they say mempool policy has no effect whatsoever and anybody who thinks it does is stupid or occultist or misinformed that is also not true. And this is where we get to the power of the default. And there's a very simple argument for this is that if things don't get around the network, they're less likely to end up in blocks. Obviously that doesn't mean they will be prevented from getting into blocks, but they will be less likely to get into blocks depending on the amount of the network that has adopted these policies. And this is why the default setting is actually such an important role here. And if it didn't have a critical role, they wouldn't be proposing to change it because it wouldn't matter. And this would be a really stupid reason to bring this up because obviously it's hugely contentious. So why are they bringing it up? Because the default setting matters. It makes a difference on the network what the mempool policy is for 95% of nodes. Now the core arguments for core's position is that this would be preferable to the inscription method to putting in to using fake addresses and arbitrary information in the witness data. Another big one is about minor centralization is if you have a network that is not propagating the transactions that have JPEGs, they can still get into the chain and they're just going to go directly to the miners. So for this this was brought up by lop by everybody who's making the argument and trying to explain that position. But I'm going to read a post specifically from Seth for privacy because I think it's just a little bit simpler language. So whole first section is you cannot prevent arbitrary data storage. That is true. Many new L2s and scaling solutions would require storing proofs on chain something that that is simple data storage. They can do this no matter what you run on your nodes. As the only entity who matters for block inclusion are miners. And miners have a clear incentive to make more money. That incentive is at the core of Bitcoin's game theory and cannot change or everything falls apart. If you go nuts with mempool filters and everyone runs sketchy software to white knight as defenders of Bitcoin trademark, guess what happens? Everyone just sends transactions straight to the miners for an additional fee. Small miners can no longer be competitive and miner centralization gets drastically worse. Or they find unstoppable ways to simply make their transactions look standard using steganography, hiding data in tweaked pub keys, unspendable outputs, et cetera, inscriptions basically so that they don't have to bother with direct minor submission. Not only would that be literally impossible to filter it would also be drastically worse for scaling than the current state of things. So this is where I think it's important to go back to the concept of the default settings and to see what happens in conditions where 95% of the nodes are doing one thing thing versus another because I think it's a really important piece of this conversation. Now the issue about minor incentives is definitely true and we've basically actually seen this in the real world because Mara has this service called Slipstream and it's literally a way that they charge people to get around the mempool and put garbage directly into a block. Yes, Mara basically advertises that they are shit stewards of our monetary system. [00:16:35] Yes. This is also my bias showing. Obviously this is bad. You don't want people going around the mempool. However, we have to go back to that idea of the default policy because this incentive actually has a flip side. The street is both ways. It is not so simple as Mara just benefits from this and everybody else is screwed. And also it's important to note that right now descriptions and JPEGs and all that crap on chain is actually dying of its own accord. It really shows up as an important volume in the bitcoin chain when there's just nothing going on. It was horrible right at the beginning and it's petered out a ton and I would like that to continue on its way. But again, let's go back to the concept of the default policy because there is another element to this. If nodes do not receive the JPEGs as they are passed around the network in order to confirm the block when it gets mined, they have to suddenly reach out to the network because they get a. They have a bunch of bitcoin transactions that are normal and let's say they have a filter that says if your witness is bigger than 200 kilobytes or something, I'm just not going to do it because I don't believe you. And we set this arbitrary policy on our Knots client or something. Well, if they don't receive those jpegs and they don't keep them as they pass around the network and Mara suddenly publishes a block that has a one megabyte dick butt, just that's the whole block and it's just that one transaction. Well, suddenly they have to reach out to the network and ask what the hell is this dick butt? Does anybody know what this transaction is? Because I don't have it. And so they have to download the dick. But in order to confirm that the block is valid and so they can pass it on to other people in the network. And as they say, this hurts your node because it takes you longer to validate blocks, et cetera, et cetera. There's also a slightly. Even though it's. It doesn't really matter because you be doing it on the front end or the back end, but there's a slight peak in bandwidth strain on the network because people are having to ask for more secondary information after a block comes than they otherwise would because they would have gotten it when the transaction got broadcasted. So why do I say there's a flip side to that conversation? There is still an orphan block about once or twice every two weeks. Now, an orphaned block is when two miners produce a block at the exact same time and part of the network gets one of the blocks and part of the network gets the other block. And so right now there's no consensus because they have the exact same length of chain. And now we have to see who is which block is going to be built on top of and thus make the longest chain one of those blocks, since some of it got out to some of the network and the other the same. One of those blocks has to be let go. And so somebody who thought they mined a block is about to be undone because the network is not in consensus for a moment. Now, invariably one of those blocks is going to be built on first, and then that one is going to be the winner, the other one will be dropped, and we will continue on like nothing happened. That's a normal operation of bitcoin. [00:19:37] Orphan blocks have fallen over time, but they still happen. So you can expect 20 to maybe 40 on the high end of these blocks to get orphaned in a year. So let's think about the default again. So the argument is if most people are trying to filter or a significant amount of the network is trying to filter, well, then they'll just pay Mara in the slipstream, out of band, and then that miner will get more revenue. Nobody's going to go to a small miner to pay them extra to put their crap in blocks. They're going to want to do a big miner. So, yes, margins are thin. It can have a measurable effect on the bottom line of a big miner. Probably not a big one, but nonetheless a small one. But here's the thing. If we can get most people running nodes, if we can get most people building their own templates, which I think is the most important issue in all of this, because the better decentralization we have with miners, the less this problem is. And if you have 95% of the network filtering out these transactions, it's not just the node that pays the cost. It could also potentially be Mara that pays the cost. Mara is going to put their block with transactions that nobody has into the network. And the other miner is going to put the block with the monetary transactions that everybody has. Because we're assuming again, 95% are running some filter, well, there's going to be a race over which one gets orphaned. And if one can get to 95% of the nodes extremely quickly, while Mara's only quickly gets to 5% of the nodes, because now everybody else has to spend the time downloading a megabyte of Dick Butts in order to validate their block, Mara might lose their block because they are using slipstream. There's actually a great quote by Satoshi on this topic. Believe it or not says quote right. Nodes keep transactions in their working set until they get into a block. If a transaction reaches 90% of nodes, then each time a new block is found, it has a 90% chance of being in it. Now, obviously it's not quite the conditions of the network that he's talking about in this instance, because every single node is not a miner, but it still matters very much how much of the network gets which block faster and how long it takes them to validate and accept that block. And sure, Mara could have a little thin margin of potentially slightly higher fees because of slipstream and posting Dick Butts into the chain, but they also might lose a block if they end up being one of the 20 or 40 that gets orphaned during the year. And a block that would not have been orphaned may now be orphaned. If we were extremely vicious and we were all on the very same page about this and everybody ran filters with that goal in mind, you can actually turn what appears to be a centralization problem for Mara into a kick Mara in the ball for doing this out of ban. It's perfectly fair to argue that that's extremely unlikely. I also think it's extremely unlikely. But the incentive works both ways. It's a lot similar to the argument where small blockers said, well, we're going to get 90% of the miners and you're just going to sit there with your node and wait for blocks to come in and you'll wait forever. And that's why everybody will switch to bitcoin cash. But it was pretty clear that the opposite was also true, that, well, if we just sit here with our nodes and wait and don't switch, well, Miners are now mining hours or days of a shitcoin that nobody else is buying or accepting. And that costs a lot. So they'll probably just come back to our node network and we can just wait it out. It's not exactly the same, but it actually is a little bit same. There's another issue brought up on the support side that I think is a real misrepresentation of what's happening here. But I've seen a number of people bring this up that people are demanding things of Bitcoin Core and the developers. Now I'll read Seth for privacy and I'm not trying to pick on Seth here. I like Seth a lot. I think his heart's in the right place. But obviously we disagree on certain issues. But just because I think, I think this is a pretty fair representation of kind of the thought process behind this one. So I'm going to read this section of it now. The last major effect of this insanity is that it will absolutely lead to faster burnout of the few devs with willing to work full time on Bitcoin and disincentivize future devs from working on Bitcoin. As they'll know they have to wade through the morass of public opinion just to get simple changes in a pr. Guess what happens when less devs want to work on Bitcoin? It stagnates, becomes more and more vulnerable to attacks at a software level and becomes less useful as money because not enough people are maintaining or building the software. Now this is where, and I think it was a short video by. With Provost in it or. [00:24:31] I don't, I can't remember exactly who it was, but I saw this brought up by a number of other people. Be like, you're demanding things of Core. I can't believe you bring this up and you're just attacking them. That's not what happened here. Like there was no like. I mean granted I'm a, I'm a, I'm an anti spammer. Right. I really don't think that we should be optimizing for or accommodating Dick Butts on the chain in any way whatsoever. Even in the face of the fact that we can't really do anything complete about the picture. But regardless, I didn't know about any like mafia of anti jpeggers that were on some sort of secret telegram group where they all got together and they said, well, we're going to attack Bitcoin core today. Quite the opposite in fact. Nobody knew what was going on. And then Bitcoin Core decided to bring this issue up over something that I think will not move the needle at all. And I'll explain why. Another point of why it won't move. I believe it won't move the needle in just a second. But something that had been in place for again, more than a decade and that had been a clearly contentious issue for the entire time, was suddenly made a quite broad and sweeping change that not only removed the limit, which was going to be contentious, but is trying to remove the configuration option to keep the limit in any way that the node actually want, that the Node runner actually wants to. Basically, nobody should have been confused that this was going to be horribly contentious. It has been from the beginning. And this is actually funny. Even though I've had a lot of people argue all of the other arguments at me, I actually did not bring those up in a lot of the debating that I did. And this is the one comment that I posted on GitHub because it was already blowing up and getting out of control, which was obvious that that was going to happen. Look at the pr. It would obviously be interpreted as a slap in the face to everybody who is quote unquote anti jpeg. But my comment really quick, just so that I can get my point out, not only is this issue deeply controversial and the standard has been since the beginning to not force or push changes that are controversial, and this is a horrible look that will create pointless distrust in Core, but continuing to spend time and resources on this issue making changes for the sake of making changes when nobody asked for this is a profound waste of time and resources. This is only showing people that Core isn't interested in what the users or the network actually care about. And pushing forward with this would be incredibly ill advised. This is not an arbitrary or small issue, and you will start problems that are vastly larger than this in response to it. And I still basically think that. And so why do I think this won't really move the needle on all of the things that are kind of argued? I completely agree that if everybody was using Opreturn instead of inscriptions, that that would be better. The problem is OPreturn is still limited to the old 1 megabyte limit because it's in a different place in the transaction. Whereas inscriptions are in the witness data, which has a four megabyte weight, which means it's discounted. So talking about incentives here, nobody who is making inscriptions today of any size or consequence whatsoever are going to switch to Opreturn in a meaningful sense. They are incentivized, they are given a discount in order to put it in witness data. This is why I think all of the arguments saying that we would rather have people use Opreturn are as silly as the arguments of we would rather have no JPEGs at all. Because similar to, well, we're not going to be able to stop people from putting arbitrary data on the chain. That's true. Also, there's no incentive for people to switch to Opreturn unless they just happen to want to be good stewards of the blockchain and pay a little bit extra in fees. But since we're playing the people will go where they incentive are incentivized to go. Just like miners and just like users and nodes, they're not going to do that. Now, there's a lot of controversy about Citria in particular and that, you know, Jameson Lopp is an investor. Some people are like, he works for him. And I couldn't confirm that. I don't think that's true. I think he just has invested in it because they're trying to build something, which arguably sounds pretty cool, for Bitcoin to be able to do interesting new things and they need a place to put arbitrary data. [00:29:00] And he said specifically, I asked him this in a thread. [00:29:05] He said specifically that Citria has a challenge transaction that they can use. It's only like 100 bytes or 140 bytes or something like that. I can't remember that. They could put in the OPER turn limit and if that limit was gone, then they could be better stewards and they could use Opreturn. And in fact that it's specifically amount, an amount that wouldn't be a measurable difference in the cost. So it would be fine for them to use this. Except that after I kind of dug into it, even one of the developers from Citria said that that would basically not move the needle at all. That would happen almost never, essentially, or at least it would just happen so infrequently that it wouldn't be like there were 40 op returns instead of inscriptions every single block. No, it probably happened every two weeks or a month, or probably be news that somebody had to challenge the operator because again, the operators aren't incentivized to do it. If somebody can actually prove the truth, everything else is just incentivize all of their big data, their ZK proofs and all of that stuff. They're still just going to use inscriptions because it's a lot cheaper to do so and there's no reason they would pay a really high fee when they don't have to. Now there's another argument for the opposing side that they keep saying that people will put illegal data, child porn or whatever it is in the chain and we don't want them to do that. Well, obviously, yes, of course we don't want them to do that. But also, obviously there's nothing we can do about it and nothing about not doing this prevents that. They can do it right now. They can do it right now and there's nothing any filterers or anything, especially if they are trying to attack the chain. If we had 100%, if everybody was trying to be completely locked down on what they allow in the chain and there's no arbitrary data, they could still just get it in. Even though philosophically, yes, I perfectly agree with you. I'm sure every single person who is supportive of this completely agrees with that as well, and they would rather not have it. But the truth is there's nothing we can do about it. But back to my other point, look at the controversy this has stirred up. Look how ridiculous this argument is when this isn't going to fix the inscription problem. I really don't think this will change anything at all on that front. And I actually think it has the capacity to change a lot in how many people are just using Opreturn for a new or different reason. And again, I will explain that in just a second. And bizarrely enough, not what I expected. Oodie, of all people, actually has, I think, the best framing of why this is the case. But I want to hit a different technical argument first before we get there. So going back to the idea that if the nodes don't have the transactions, well, then they're going to have to request it from the rest of the network, you know, if they don't have dick butts, well, you're going to have to request that dick butt. And more importantly, if you don't have it in your mempool and most of the network does, well, then you don't know what the next block is going to look like. And so to you, it might look like there's only a mempool of like 200 kilobytes worth of transactions. Well, obviously I'm going to pay a 1 Sat per V byte fee and that's going to be my estimation. And then the next block comes in and it's absolutely full of JPEGs and not even a single one of your transactions that you had got in and you're like, where the hell did all this stuff Come from? I didn't have this in my mempool. And so you have to remove request a network. What? Where the hell is all the dick buts? Give them to me please. Let me put them in my block. And now my ability to estimate a fee is compromised or it's at least inefficient. But Jameson Lopp actually has a really funny post about this particular issue in practice. So we're going to read that really quick. Keep spam out of. Keep your spam out of my mempool. Are you running a lightning node? What if a channel counterparty tries to defraud you by publishing an old channel state? In that case you need accurate fee estimation. Your justice transaction will have to beat the dick butts in miners mempools. In order to beat dick butts, your full node needs to know about dick butts and what they are bidding. If you're ignorant of dick butts, you'll get fucked by dick butts. I gotta hand it to him, that's pretty funny. But the the issue here is that the idea is that there's some sort of perfect fee estimation or that it would be so optimal that this wouldn't be a problem. And that's just not true because for the simple reality that blocks are probably going to be every 10 minutes. But there's a million different times where you expect the block to be 10 minutes and it's two seconds from now and you expect it to be in 10 minutes and it's an hour from now. And of course you have no idea what transactions are going to be coming in in the next two minutes or two seconds for that matter. I've had it before where the fees had been almost nothing all day and I was just paying two sats per byte per V byte. And I just put that out there and it just shot up to like 9. Because this flood of transactions came from absolutely nowhere. I had no idea what was going on and I had to wait like 13 blocks before I got fed up waiting and I did rbf. And so here's the thing. This is exactly why we have rbf. There is no such thing as perfect fee estimation. Now I get this. This is an accurate potential concern. But that again is exactly why we have rbf. Predicting fees is like trying to predict the weather. Yes, you can certainly be a little bit better or a little bit worse at it, but you're never going to know for certain whether or not a drop of rain is going to land or not. And the harder you try to guess or the more you plan on it definitely being one way or another, the bigger the problem you're going to put yourself in when it doesn't work out like that. And the simple reality is that we have to account for the fact that there's going to be massive fluctuations that are specifically unpredictable. Which is why we have RBF and why the default. The very important default policy is mempoolfull rbf so that replace transactions with a little bit higher fee can in fact get through. Because it matters what 90 to 95% of the node network is doing or what their policy is. And notice that again this is a two way street. This also goes the opposite direction. Let's say taking the power of the default with filters. Again, let's say 95% of the network are running a bunch of filters like this. So dickbutts aren't making it around very well through the network. And most templates from block miners who are using Datum hopefully. Again that's what I want. That's the thing I want to move the needle on. I'm not concerned. This was not an issue and this became an issue. And I have to make another stupid episode about this because Core made it an issue again when it was clearly contentious. And there are other ways to solve these problems in much better or more optimal ways by doing more fundamentally in my opinion at least. And maybe this is supposedly out of Core's, you know, raison d' etre or their kind of field or what they even of what they even work on, but it would kind of be cool to just have like Datum plugged into the Bitcoin core client, right? That you could just super, super easily. Like where is the one click connect my miner to my node and build my own block template tool. How is that? Like that feels super important for the security and decentralization of the network. [00:36:23] Shouldn't that be a part of it? I don't know. It feels like that is a good place to spend time and resources on figuring it out. But anyway, going back to it, so it's a two way street. So let's say 95% of the nodes and miners and block templates are in fact leaving out JPEGs. Well then if you are accepting JPEGs and they're not included in the next blocks, well then you're going to be estimating fees that are way way higher when the fees are actually low because. Because you're just trying to make a monetary transaction so your fee estimate will still be broken in the other way. Simply because it's non homogeneous. Because the mempool has a separation between the people who have one policy and the people who have another policy, which also is not the end of the world. There's no perfect optimum. Yes, there is a technical argument for it being more efficient. Just in the same way, kind of this is a little, this, this is going to sound, sound more like an attack that like oh, this is big corporate. And that's not what I mean, but I mean it in analog, just in a simple analogy that a giant corporation is way more efficient because it can put the entire stack into its giant corporate system and thus it can produce way more with way less overhead and kind of fallout on the margins. Except that it does have another consequence of being extremely fragile and being susceptible or weak to, to huge shifts in the market and huge shifts in the product or the environment itself. So another example is that if we are expecting, if we basically make all of our lightning nodes assume that it knows exactly what the fee is going to be or close enough that it doesn't have to worry about whether or not it shifts a lot because everybody's got a homogenous mempool policy, well then you can actually cause like a really annoying problem just by screwing up mempools. And now somebody external to the situation can cause a problem because they're just trying to attack the network. But if we expect the fee to be largely not predictable and we have to do our best guess and adjust constantly, yes, it would be in our best interest from a node runner to accept all the dick butts and JPEGs and all that stuff because that would help us. But you also can accept them without propagating them if you're not trying to incentivize them getting into blocks. But basically on the whole I think it's. Even though this is not really. [00:38:49] It's not super meaningful, but it is what I think a net increase robustness. If a lightning node is built or designed to work under very non optimal conditions and still produce the expected results rather than trying to homogenize everything on the network as much as we can so that there are only optimal conditions, because we cannot count on optimal conditions, we're going to have wild fluctuations in fees because it's just the whole thing is just a giant auction on the whole globe and there will be pockets of the network that aren't super connected. There will be data that just comes from one entity or from one spot and we just have to, to be ready for that. Obviously if we want to minimize that, or if we can minimize that. There's not an evil thing in trying to do that. I think there is a very honest cause being pushed here to try to make that less of a problem. But it's also not as white and black as everybody's trying to say. It is. Now another issue that Matt Carollo brought up, which I think is a fair point to make. I'll read the post real quick. It says I think it's an important thing to Grok. He's referring to a Marty Bent note on Noster that says I think one thing's pretty clear. There's no consensus on the OPER turn issue. So Matt says, I think this is an important thing to grok. There's no reason Bitcoin Core should be bound by consensus for things unrelated to Bitcoin's consensus rules. Bitcoin Core is a software project with a wallet, a gui, an RPC API, and an implementation of a peer to peer network for rumoring blocks and transactions. For all of those things, there's no reason for Bitcoin Core to only act with consensus. Can you imagine if they needed consensus of the community to make an opinionated decision on the gui? But specifically on the topic of the peer to peer layer, Bitcoin Core contributors jobs are to be good stewards to that implementation and to do what is right for Bitcoin to maximize decentralization and robustness. There's no debate, except from people who don't understand Bitcoin, that reducing or removing paternalistic sensorial standardness limits is not not only good, but possibly important for Bitcoin's long term decentralization. There is nothing that says anyone has to run Core, and there is nothing that says Bitcoin Core must only do things where there exists consensus in the broader Bitcoin community, especially when it's abundantly clear those things are important for Bitcoin. None of this applies, of course, to Bitcoin's consensus rules. That sub project of Bitcoin Core has drastically different constraints. This is completely true, and I pretty much agree with it, except for the fact that again, I don't think this moves the needle either way. I think this is a claim that it improves Bitcoin's decentralization and I don't think it's a very strong standing and it's a claim that we would rather have Opera turn. But again, there's no incentive for anyone to use the OP return instead of inscriptions. And this change in particular is obviously very contentious because the issue underlying the Opinion is very, very contentious. And rather than just trying to raise the limit a little bit or even just removing the limit and allowing the configuration, there is this full on, we're just going to put our foot down and we're going to conclude this topic and then getting mad that it became contentious. Now I would love to go into kind of the history of OP return and kind of where this all began and the idea of quote unquote censorship. I think the whole censorship, this is censorship, or this is going to lead to censorship argument is completely moot. Like spam is clearly its own thing and always a huge problem in open networks. Like this is the problem of open networks is what do you do with spam? And I don't think there is any subjectivity really in identifying spam, because spam is according to the person who is receiving it. Like obviously the protocol cannot necessarily determine what spam is, but the user can determine what spam is and decide that they do not want to accept it. And I think the node with all of the inefficiencies and potential downsides that come with it, the node runner should be able to decide what they believe is spam in order to try and be a good steward of the bitcoin chain. But Matthew Crater has a really great video just kind of like to talking about the history of this and Satoshi's kind of input on this issue, the OP return issue and all this stuff. And just to think about it in the context of censorship, like this is the idea that this is censorship. Well then up to now OPERN would have been explicitly censorship defining what goes into the chain, rather than like, you don't censor a what, you censor a who. And even though the philosophical debate has been made a million times, I do just want to out point put for my own sake. The argument and analogy I use with the court system one more time is just because you can say that there's a market for parties and concerts doesn't mean that we should not, or that it's bad or that it's censorship in order to limit our court system to just arbitration and legal matters and protecting people's rights. Because concerts and parties and, and tickets and any sort of economic activity are necessarily dependent on the ability to enforce the rights of the person to get a service in the marketplace. In other words, if you crowd out the court case with people getting tickets and going to concerts, you undermine the very core function and purpose of getting a ticket and the ability for the person to know they'll be able to go to a concert, you undermine the rules of the market, the ability to enforce the rules of the market in order to just be like, well, the concert paid more money. Well, yeah, it might make a lot more money if I had a casino running on my security system, but the security system's purpose is the security of my home. I will not let someone run a casino software on my security system so that I can secure my home. Bitcoin is a monetary system, so the question of whether or not something is spam I think is a very easy question to answer. And no, it is not censorship or the OP Return for the entire history of the OP return has been blatant and broad censorship of the bitcoin network. Until of course, people found out that you could just inscribe crap into the witness and get around it. But I'll link to Matthew Crater's video just so you can kind of see the other this it was just a really good video. It was a really good video and I think it sets kind of a good historical precedent as to part of what's going on here and why this is still contentious and a little bit of history on the issue. But lastly, I want to hit the the post that I was surprised was actually reasonable by Udi on this one and he funnily brings up that these are surprising thoughts on the OP return drama. So quote on principle I agree with the technical claims made by core devs who want to remove the opinion return relay limits. There's a but coming soon. If when demand shows up for so called spam on chain, it won't be possible to stop it with relay policies and you might as well not try to. But there is currently little to no demand for spam. The mempool is empty and the average fees are virtually zero when there's no demand for spam. [00:45:58] The relay policy actually does help prevent demand from manifesting. Limiting opreturn relay makes it a little more difficult for people to spam and they need to contact miners or use inconvenient schemes like inscriptions. In most cases they just give up. I know this because they tell me if only we could easily do X we would. But they can't, so they don't. So the filter roars are right about one thing. If you don't make it easy to spam, it is less likely that people will want to spam. They'll just do something else instead. Note this only works when demand isn't there. If demand for spam is high, no filter can stop it. When the Filterers agreed argued two years ago that strict filtering would kill ordinals. They were wrong. People were paying hundreds of millions of dollars to inscribe, miners would gladly help them bypass any new filters and they'd have no effect. But the filterors so thoroughly consider convinced everyone that they're idiots. Devs can't see that they're not wrong this time. Enabling a new spam vector that isn't currently in use is virtually guaranteed to increase spam. As much as I do respect Bitcoin Core contributors and their work, I do think they made a serious unforced error here. The most dumbfounding thing is that no one asked for this. There's a small, somewhat obscure research group called Citria that authored a white paper. [00:47:18] It briefly mentioned how they'd consider to use Operetern if they could. They're not currently using it and they'll be just fine if they can't use it. Not that it matters. Based on that hypothetical sidebar in an obscure white paper, some CORE contributors decided to open Pandora's box with a debate that no one wanted. Everything would have been perfectly fine in the world if this wasn't brought up in the first place. I think CORE devs mean well and do a lot of good, and I think they don't deserve the harassment. But they made a huge unforced error. At the very least they could have waited to see if this ever becomes a real problem and deal with it then, otherwise avoiding the debate altogether. I've been saying for over a year that Bitcoin Core doesn't have the power and influence people think they have, and that eventually this would become obvious due to one blunder or another, at which point the entire ecosystem will smell blood and a power struggle will kick off. I believe this is now in full force. There are many implications for this. For one thing, I think projects championed by core, like the Great Consensus Cleanup now, have no chance of happening anytime soon. CORE has shown its hand. They have almost no political capital and cannot pull off small changes without massive backlash, let alone big ones. Also, I think many groups will form soon attempting to offer alternative clients to Bitcoin Core. This is a good thing, even if many of them will be of poor quality. It's possible that some mini disasters will happen along the way, but eventually we will have a balanced competitive ecosystem. More people will participate in technical discussions. The motivation will be political, but that's better than nothing. Competition will drive CORE to improve too. There are some great people there, so this is a huge win. Much can be improved there in building social and political capital, communicating their work, and forming some productive hierarchy. Also, thank you for hosting all of my jpegs on your nodes forever. I pretty much agree with this. [00:49:08] And it also brings me to my point as to why I think this. But why would it increase spam if it's more expensive to use opreturn? And that's what I think gets me to what this issue is really about is that this is not a solution to too many UTXOs. This is not a solution to the UTXO bloat, this is not a solution to inscriptions. This is not a solution to fee predictability. But it is an invitation. This is a fine. We give up crypto. Bring all your crap and come join us on the bitcoin chain. Now there's a lot of people who have said, you know, if bitcoin could do more things, like let's say just for numbers, that crypto is an $800 billion market and Bitcoin is a 2 trillion dollar market. And everybody says like, oh well, if bitcoin would just embrace all of this, well then it would be a $2.8 trillion market instead of just 2 trillion. I think exactly the opposite. I think if bitcoin embraces all of that bullshit, bitcoin actually becomes closer to the 800 billion dollar market. Because Bitcoin is solely and completely focused with as little room as it can possibly give and being extremely and explicitly un unwelcome to all of that crap. It is a monetary system and because of that it is seen as serious. It is seen as high integrity. It is seen like a nuclear bunker that nobody can mess with. It is the nuclear bunker of global digital monetary systems. Crypto is a joke. Crypto is a bunch of scammers. It's a bunch of speculators. It is fiat finance personified into a system where it doesn't even matter what any of the stuff is. Just make tokens and dick butts and NFTs. It is garbage on top of garbage. And the only thing that even has a use case are chains that have made decentralized exchanges to swap and trade garbage. Putting all of that, bringing all of that back to bitcoin does not make bitcoin more valuable. It undermines the very thing that makes bitcoin a two trillion dollar market and crypto completely unable to compete. It makes it look dumber, it cheapens it. It makes it look like it has low integrity. Like it doesn't really care about whether or not somebody puts a dick Butt on the chain. We must look like we don't want them here under any condition. Bitcoin is more valuable because people don't do that stuff on chain. And as I said before, it has already basically killed itself. [00:51:42] There is almost no demand for spam on bitcoin anymore. Please don't do anything that might change that, good or bad, because we're not 100% sure if this is seen as an invitation, if this is seen as a. Well, bitcoin doesn't really hate us anymore. I can put my token on chain, I can put my JPEG in the op return. And even better, I'm being a good steward of the chain. It will just open up a bunch of people who want to use that and it will bring a whole bunch of failed crypto projects who still never understood what any of this is about and still do not care about making a secure, global, decentralized, cannot do anything about it. It is hard as a rock money for the entire world and they will just put their shit in it. This is why I think it doesn't fix anything with the inscription problem. And it potentially just invites a whole lot more. And it says, come on crypto, we're open for business. Just, just come on back. And I think we send that signal. It is a social signal. Technically, I think this is garbage across the board. It doesn't really matter for or against. It is a social signal. And this is why a lot of people say it's not about the technical arguments. There are legitimate technical arguments, but I don't think they're really going to mean much in practice. It will mean a lot in practice, in my opinion, in the social signal that is that it is sending, that we are just going to open right up and there will no longer, you will no longer be forced to do inconvenient means of trying to get your crypto, your crypto project to work on bitcoin, because we'll just make it so that you can stick arbitrary data and it will be super easy for you. I want it to be hard and inconvenient even for the good projects, specifically so that the good projects have to be good enough to warrant doing an inconvenient thing. So there's plenty about the technical argument that I think bitcoin core is all the supporters for this change are entirely right about. On the surface it sounds right, but bitcoin is also a very social system. And I do not think the technical arguments actually align in the incentives the way they say they do or to the degree that I believe is a huge concern. Like another one about the, the mining centralization problem is that a whole bunch we're worried about like small margins for big miners but FPPS is obliterating miners margins and most of them don't even know it. But we have numbers out there that are floating about. A lot of people are pretty secretive about it because if you just stop letting mining pools pay you a little bit and estimate how many blocks they're going to have, you can get a 5 to 10% back just by taking the probability. And again we need to make it stupid, stupid easy for miners to build their own templates. Miners are not cypherpunks, they're the dumb brutes in boots. Most of the time they're, they're out there changing alternators and mining oil. That's the person who is often a miner. They're not the ones that break out the code and write a whole bunch of binary or c and you know, they're building their own system, they just want software that works. We can do that. I think focusing on that as a problem is going to move the needle way, way, way more. Whereas this makes a contentious issue come right back to the surface. And now look at all of the time that we're wasting on this and I don't think it's going to mean anything. And the only real effect that it will likely have is that it will invite more spam for no reason at all. But I'm open to being wrong. I, I'm totally, I have no problem reading the opposing side. I, I take them as honest arguments. There's a lot of great points across the board and I really wasn't able to cover every single thing. These are the things that I just think are most relevant because there's a lot of that, you know, at the edges argument about censorship and all. There's a bunch of stuff that people have been, you know, shit tossing back and forth that I just don't think is super relevant to the discussion or it's just large philosophical stuff about JPEGs which really isn't about this one issue that's happening right now. But I think a lot of node policies should be set by the node runners and with the trade offs that come with that I think that makes the network stronger to have that variety. Even though there's an efficiency loss or potential efficiency loss, I think it forces, it's also just a small stress on the operation of the network which Bitcoin is an anti fragile thing. It's going to get better under more stress and non optimal conditions because then you have to build for non optimal conditions. But in the end there's a lot of people who calling saying this is a disaster. And the social signal of inviting crypto, I think again going back to the point is that, oh, would Bitcoin be $2.8 trillion if we invited crypto? Nope, I think it would be a trillion dollars because it would cease to be the high integrity, high assurance, no nonsense system that it is seen as. And people who don't understand it will just see crypto and they'll be like, I'm staying away from this shit. So hopefully you got something out of this or this helped to explain it. I do not think this is the end of the world. I do not think bitcoin is dead if this happens and I certainly don't think bitcoin is dead if it doesn't happen. I just think this should have been left off the table because it's not meaningful in any great sense either way from a technical standpoint. And I think it does matter from a social standpoint because it's a signal that we want things on the chain that we don't want on the chain. And I think even a lot of people who support this change believe that also to be the case. But I still think it will be interpreted that way. And because of that we probably get a lot more spam if this goes through. But I don't know for sure and I guess that's just my two sets. [00:57:30] I love to hear where you think I'm wrong or what you think I wasn't fair about or what part, what issue I didn't bring up. This is already a super long episode. I'm sure I've forgotten multiple things. In fact, I think I've forgotten. I know there are a couple of decent points on the opposing side that I could have done brought up and probably should have, but ain't nobody got time for that. So we're just going to end this one here, you know. Please subscribe to Bitcoin Audible Shoot me any comments DMS tag me. I don't. I got thick skin. Call me a I don't care but I'll try to answer if you actually have a point to bring up and aside from calling me a cultist or a I'll try to answer it but I'm probably going to be less inclined to spend some time on you if you're a piece of so just just a note but I'm happy to be proven wrong. I would love to. As much as I really don't like this issue a lot, I do enjoy kind of making sense of things and trying to find the signal out of the noise. That's why I try to make this episode and hopefully it was useful. I've been talking with Michael Tidwell, who good friends really like the guy about maybe doing a show on it. So if you think that needs to be. I mean, I should probably get Michael on the show anyway. There's a couple people I need to get on the show, but whether or not we talk about this issue will be up to you guys. If you think we should do more on this and talk more about the philosophy, blah blah blah, let me know. Shoot me a dm, tag me on Nostr or Twitter. And of course check out the Financial Freedom Report by the Human Rights Foundation. They are an amazing institution and do incredible work and I love their Freedom Report. It is such a useful way to just kind of keep up on bite sized things that's going all going on all around the world. And check out the big hit Wallet for on Chain and Lightning. That just works. The links and details will be in the show notes and that will wrap us up. And until next time everybody, that's my two sats. [00:59:16] Later guys. [00:59:30] LA.

Other Episodes

Episode

July 23, 2018 01:03:30
Episode Cover

CryptoChat_003 - Nik Bhatia on The Future of Bitcoin Financial Markets

The Lightning Reference Rate, Changes in Lightning Tech #eltoo, Returns without Counterparty Risk, CFA Institute Enters Crypto, ETFs on the horizon, Futures, and a...

Listen

Episode

April 05, 2024 01:24:54
Episode Cover

Ai Read_006 - How (Actually) Open AI Wins

"As I see it, humanity is at a turning point where we must either embrace a small handful of totalitarian super intelligences or move...

Listen

Episode

February 05, 2025 01:38:48
Episode Cover

Chat_126 - Bitcoin In Real Life with Wyatt O'Rourke

"We've planted our orange flag in the ground. We've made it known this is a space where we will try to propagate and spread...

Listen