The Canadian Bitcoiners Podcast - Bitcoin News With a Canadian Spin - Making Sense of the OP_RETURN Drama (with MrRGnome)

Episode Date: May 9, 2025

FRIENDS AND ENEMIESMrRGnome makes another appearance on the CBP. He is a former mod the the Bitcoin subreddit, current mod of the Bitcoin channel on Discord, and Bitcoin Maxi. He will hopefully help make sense of what is going on with the OP_RETURN Drama in Bitcoin Core.#Bitcoin #BTC #Investing #finance #opreturn #BitcoinCore #BitcoinKnotsJoin us for some QUALITY Bitcoin and economics talk, with a Canadian focus, every Monday at 7 PM EST. From a couple of Canucks who like to talk about how Bitcoin will impact Canada. As always, none of the info is financial advice. Website: ⁠www.CanadianBitcoiners.com⁠Discord:   / discord   A part of the CBP Media Network: ⁠www.twitter.com/CBPMediaNetwork🎙️ New to streaming or looking to level up? Check out StreamYard and get $10 discount! 😍 https://streamyard.com/pal/d/65024650...

Friends and enemies, welcome to yet another edition of the Canadian Bitcoiners podcast. This is a impromptu video discussion and I have a couple of gents that are going to be joining me. One we have talked to in the past, Mr. Arnaam and another I'm going to be introducing for the very first time to our audience. And both gentlemen, they know their stuff inside out. I am appreciative of both of them. They give me their time and I'll discuss why, but let me just bring them on one at a time. And the reason I'm bringing them on is because we're talking about

the opera term drama. Number one, we have Mr. Arnoum. And before I ask you a question, just going to give you a quick introduction and maybe you could just brief me if I missed anything former mod of the Bitcoin subreddit current mod of the Bitcoin discord channel Bitcoin maxi Anything else am I missing? No, I'm just an angry jerk on the internet. That's really my whole deal and I appreciate you taking the time to come on second we have current mod of the Bitcoin CA subreddit, current mod of the Bitcoin subreddit, and current mod as well as the Bitcoin

Discord channel. Did I get all that right, Mr. All Caps? Yeah, you did. Good to be on here. Thanks for having me. Gentlemen, I appreciate you taking the time to come on here because we have something that's happening in the world of Bitcoin that is taking us by storm and it's the opera turn stuff and maybe you guys could help shed some light and you know Maybe sling some mud at the same time because there's a what is being proposed is sling some mud at the same time because there's a what is being proposed is is a change to the op return now before we go into it maybe I'm gonna throw it over to you mr. our gnome what exactly is the op return and why are people wanting to change it all return is one of the op codes the Bitcoin script keywords that

perform a function that we use in our Bitcoin scripting system. And we use it, I use it personally, to store arbitrary data on chain. And I know that arbitrary data is a naughty word to some Bitcoiners, but I'm going to tell you it's not. And if you are going to be storing arbitrary data on chain, OpReturn is the correct way to do it because it does not bloat the UTXO set. And that's really, really important. As we've seen, for example, with the ordinal spam and stuff that doesn't use OpReturn, it has dramatically bloated the UTXO set. It's like over 20 gigs.

I'm pretty sure at this point. That's a problem. It's a problem for full verifying nodes. We can't have people storing arbitrary data in ways other than on-return. So yeah, that's what it's for. Ideally, you should be using it to store just like a hash or a Merkle tree root, which is like a hash.

Like you don't wanna be just putting data on chain because that's not what the Bitcoin blockchain is for. It's, which is like a hash. Like you don't want to be just putting data on chain. Cause that's not what the Bitcoin block chains for us. The world's like shared database. You can't just be throwing whatever the hell you want in there. That should cost you huge sums of money. But if you just want to throw a little tiny little hash and it's in transactions, you're already doing anyways. Fantastic.

Throw in an offer, turn output, get it done. And this proposed change is one that was submitted by Peter Todd. Is that correct? Did I get that correctly? Well, all caps can elaborate on this a little bit, but my understanding is that while Peter Todd has submitted this change for OpReturn, and we should specify what exactly it is he's proposing, it wasn't actually his idea to make this PR. My understanding is he was approached by a third party.

I believe it was those shit coiners, Citria or something. Uh, and my understanding, and again, all caps can correct me on this. He knows more about this than I do is that Citrio wants to throw data arbitrarily on chain like their shit coin layer. And they don't like that their users have to, find a non-standard route potentially to propagate a transaction because their oper returns might break standard as rules.

So there's threatening to not use oper returns. They're threatening to do what I was just talking about in terms of bloating the UTXO set. So Peter Todd comes along and says, hey guys, what if we relaxed the default opreturn byte limit, the size of an opreturn, the size of the arbitrary data that we can put on chain? Why don't we relax that, get rid of the default limit? Hell, why don't we get rid of the setting entirely? And it'll be great. Let's do that PR push. That's the situation we find ourselves in. And there's, you know, some other background color to it involving, for example, the moderation policies

of Bitcoin cores, GitHub and other repositories that we can get it. It's full of drama and fun and misunderstanding by everybody. Why are people upset by this? What makes, because right now it's 83 bytes and right now they're going to change that potentially to unlimited, but you also have one megabyte. It would be one megabyte maximum per block. Just, it's not unlimited, but it would be significantly more than it is right now. So just keep that in mind. Well, no, no, it is that right now.

These limits on relay policy don't actually stop anybody from putting a transaction that violates them in the blockchain. I mean, if we could just decide what doesn't get it. Does it incur more costs?. Does it incur more costs? Doesn't it incur more costs? I mean, people are using an opreturn bot and paying fees on that bot.

Well, that makes them very stupid when they can just go directly to the miners website. They are. Have their non-op, their standard opreturns or other transactions propagated directly. Like, yeah, scammers are taking advantage of this. But to my point You can't use your mempool or relay policy to stop anybody from getting anything in a block your node settings

They affect to you They don't stop other people from accepting those transactions and as we saw with full RBF it takes less than 5% of nodes Propagating a transaction to get it to miners even if there is a minority of them. Getting back to the original question, why are people so angry? I think that's the core of the issue is that the choice to limit your own mempool is being not eliminated, but with core, if you're going forward, you're not going to have that toggle option. So you're kind of forced to either stay on a downgraded version of of core or you switch to another client like Bitcoin knots or lib Bitcoin or some other fork. And it's not ideal for, for people who want more control of their,

of their nodes. Absolutely. That's, that is a hundred percent the truth. And it's also the function of the problem is we've got core contributors and maintainers trying to limit node operators' influence on the node. And they've got a variety of reasons for doing this. And I think we should break them all down and explain why I think that they're ridiculous. But ultimately, at the end of the day, what they're doing

is disenfranchising node runners from making their own decisions, even if it's possible that those decisions can shoot themselves in the foot, a foot gun as they like to call it. That is possible. The reality is that people that don't have a very good idea of what's going to be into the next block are at a disadvantage when submitting their own transactions in terms of estimating what the resolution time for that is, which can be really important for security on things like lightning, for example. If you're using lightning and your node is trying to broadcast a justice transaction, it wants to know is it

going to confirm? When is it going to be confirming? Is it going to confirm within the time limit that I have to do this justice transaction? In this sense, having an estimate is important, but at the same time, because a mempool and relay policy are not part of consensus, they can't be. If they were, then we would just have a no blockchain, we would just have a mempool and relay policy that says no double spends, and they wouldn't happen, right? Obviously, that's not how it is. So the reality is that this is kind of inevitable. You're always going to have people with different relay policies running different software. That's where our decentralization comes from. Everybody managing their nodes,

making informed choices that are best for themselves about managing things like node resources and just making consensus decisions or even just arbitrary decisions based on how they feel. That independence is our decentralization. People should be running odds. People should be configuring these things. But as I alluded to earlier, there are many reasons why core devs think that this is a bad idea. They think users are going to hurt themselves.

They think it could even be bad for the network. I don't agree with those things, but I'm happy to give my best good faith representation of what I feel their views are. give my best good faith representation of what I feel their views are. Did you ever hear or hear the theory that by making this change it's going to potentially help the scaling of Bitcoin in the future? And if so, do you believe that's truthful or not truthful? Well, op return and being able to store arbitrary data on chain definitely is an important thing for layers. Layers may need to store state data or resolutions of state to the chain.

Like I said, I use OpReturn. In fact, it was my first use case. I was using not specifically OpReturn. It wasn't around at that time, but putting data on the chain is how I was originally running my business, is how I came into Bitcoin. I wasn't using it as money.

I was using it because I wanted to be able to approve in a court of law that a given state system existed at a given time. I can do that by putting a hash of that state in the time chain or a more culture root of that state in the time chain. And that is a very optimized usage of chain state in the time chain, or a more culture root of that state in the time chain. And that is a very optimized usage of chain state. It is no more data than a hash. It fits very easily within

either the original, whatever, 42 bytes or now 83 bytes limit of core standard propagation policy. And it's considered just good manners to stay within that byte limit. But nobody says you have to. There's no consensus rule saying that you have to. And if there was, it frankly would be a bad thing. One of the reasons, like I said, this PR got brought forth is because these shit coiners are threatening to flood the UTXO set and by using other mechanisms of storing their arbitrary data on chain. The logic that I think,

I don't mean to speak for them, but I think that the logic that Peter Todd is coming from is like, well, it's so much better if they use op return. So why don't we just make it easier for them? And they can spam all they want. And we can not really care because they're, you know, unspendable UTXOs. They don't need to be part of our UTXO set. And if we don't do this for them, then they're gonna do way worse. I don't agree with that. I think that they definitely should be using OpReturn in the first place, but I don't think that they need to change

anybody's standard relay policy or defaults in order to get their transactions broadcast. I mean, Open Time Stamps does just fine. I can do it just fine. Anybody who wants to can go to a miner and directly broadcast a non-standard transaction at an accepting miner. You don't even need to do it directly through the gossip network of Bitcoin itself. You can just go directly to the miner if you have to. But as I said, even 5% and less of the network propagating those transactions through the gossip protocol does still get them to miners. So this is a non-issue. The idea that these shit coiners are trying to push this change in

default for that reasons, I don't, that's dumb. In fact, I think all the reasons for pushing for this op return change set are pretty dumb, but I, my position is yeah, okay. You know what? Remove the limit. That's fine. Remove. I don't care. Remove the limit. Doesn's fine. Remove, I don't care.

Remove the limit doesn't affect me at all. Keep the options. Node runners need to be able to manage and configure their nodes, even if it puts them at a disadvantage in certain contexts. And that's what kind of the core devs have been taking away is our ability to manage our nodes. And they're treating users like they're idiots.

Like they aren't the source of the decentralized properties in the protocol. Like they can't be trusted to make their own decisions about what code they're going to run and how they're going to configure it. And I think that is such a short sighted traditional software development idea that is actively blowing up in their face.

If you look at, for example, knots and the amount of people that have been running knots, it was just six months ago, 0.8% of nodes, according to Luke Jr's DNS seed polling, like 0.8%. It's already now almost five. They have shot themselves. So we wanna talk about footguns. The core maintainers making this an issue has so far removed themselves from their own goals, their

own naive goals of trying to get mining policy and relay policy to be similar, which like they never ever can be. They want it because it makes resolutions. If they can, if they can guess what's in a block with a high degree of accuracy, that's really, really good for all these layers. It's really, really good for users that want to know when their transaction is going to confirm. Like from a software development standpoint, you're used to simply dictating what software people are going to run for your protocol application and things like this. Like they've got so many advantageous reasons.

Also, they talk about things like block propagation time and reconstruction time. That's part of that. This is when let's say I reject a transaction from my mempool. I don't want it in my mempool. I don't want to relay it. When it gets into a block, I still need that transaction.

I'm going to have to download it whether I've rejected it or not because I need still need that transaction. I'm going to have to download it, whether I've rejected it or not, because I need to validate that block. That's part of my safety and security as a node runner is validating all the blocks, even if I don't like what's in them. So I'm going to end up spending even more bandwidth, at least on the download side, doing that if I don't have very many peers. Whereas I believe that if I had a ton of peers, let's say that I'm spending way more bandwidth on upload,

I might actually be saving bandwidth by blocking these from a mempool. Yeah, I might have to download it twice if it gets into a block, but how much bandwidth did I save not propagating it? I don't know. There's also the fact that real residential internet connections often have much more down bandwidth than they do up bandwidth. So like, I think setting these settings, even if they have negative consequences in terms of things like block propagation, reconstruction times,

it's not always so clear cut on whether or not you're costing yourself resources or saving resources. And even if it was, even if you could say, no matter how you set these settings, you're hurting yourself, it still wouldn't matter. It wouldn't be relevant because people being able to arbitrarily set these non-consensus settings and choose the code they run is fundamental

to our decentralized properties. It's where they come from. And so it will always occur. It was previously occurring only to the tune of about 1%. But now it's occurring more. And this is kind of why I find it so funny for the core devs that they've put all of this, they've made this problem. They've made this problem and now it is biting them in the ass.

And I am here for it if I'm being honest. And you answered his question, protect the penguins question with your, and that's it, they want to add anything more to what he's asking and he's asking. Yeah. So you're paying per byte for your UTXO, your signed transaction and the UTXOs within. So like, for example, when you're combining a lot of inputs,

you've got a lot of small inputs, you're going to end up paying a higher total fee for the same SAT per V byte because their transaction is just larger from a data size perspective. The same is true with when you're shoving arbitrary data in the transaction, the transaction is larger, you're paying more.

This is also another good reason why we want people to use OpReturn instead of other things is because if they're using other things like inscriptions, they get the SegWit witness discount. Not only can we not prune those transactions from the UTXO set, they're getting discounted. We're subsidizing scammers and spam. That's ridiculous. So we really do want them to use OpReturn for all their incredibly bad ideas. And it will cost them more. It'll cost them a lot more

than it would if they didn't have that data in the transaction proportional to however big that data is. So wouldn't it make sense then to, this is gonna be a two part question. I'm gonna ask the first one. Just simply put a slider in the Bitcoin Core client and it could be defaulted to no limit, but then the user itself could easily adjust that to whatever they want,

be it 83 bytes, 42 bytes, whatever the heck they want. Wouldn't that be the best way around? That's what knots have. And I mean, I've putting on my core maintainer hat for a second. If I want to pretend to be a core maintainer, they're going to say that having more people having their own unique mempool policy is both bad for those individuals for the reasons of fee estimation, I already said,

but it's also bad for the network in terms of block propagation and reconstruction times. This is the time between when a miner mines a block and when a competing miner is able to build on top of that block. So they start mining when they find it and then, oh, I see Len found a block. He's already mining. I now have to, as quickly as I can, download, reconstruct that block, which is really easy if I already have all of those transactions in my mempool, right? I can just, I don't need to download anything. I just make the block. I've got all the constituent components inside my RAM and I can just, I don't need to download anything. I just make the block. I've got all the constituent components inside my RAM

and I can just go away at it. I still have to wait, you know, the latency of it coming back and forth, but I'm not out there grabbing transactions from other peers being like, hey, has anybody seen this transaction? I got to get it in this block I'm reconstructing because I really want to start mining on top of it.

But the reality is, is that block propagation times are some of the lowest they've ever been. And in our history, we've actually had pretty high propagation times. Like as late as 2017, you know, propagation times are sometimes 20 seconds to get a block across the network. So I don't buy the argument from several core devs that this block propagation and reconstruction issue is a significant advantage to large miners. It is an advantage of some amount, but that advantage has always existed to some degree. That's the nature of block propagation latency. Yeah, maybe there's some merit in minimizing it where you can, But if that tiny merit that doesn't impact anything at all

is at the expense of users being able to run and configure their nodes, no, nothing comes at the expense of decentralization. That's where our, like, miners are not where our decentralized properties come from. It's nodes. It's users choosing the code that they run. So I don't buy into a lot of those block propagation arguments,

or reconstruction time arguments either. Sorry, Greg Maxwell. My apologies if it looks like I'm cutting out. I'm here. I may be having rudder issues. If by chance I drop off, I'll come right back in as soon as possible. It's just an FYI. What if they come with a different way of doing this? But if by chance I drop off, I'll come right back in as soon as possible. It's just an FYI.

What if they come with a different way of doing this? Right now they're talking about just removing the limit altogether. What if they say, hypothetically, let's raise it to 95, 105, like something that's just a little bit higher than what it is now. Would this be something that's palatable in your eyes? I mean, palatable to who? I think that one of the problems we face, and I think most of the issues we face

on this are actually social. The PR itself to me is something of a nothing burger, because as I said, these limits don't really stop anybody from getting transactions published, and you're not in any way doing anything to harm anybody else really, as far as I'm concerned. Sorry, what was the question? I was asking, it would be more palatable if it was just-

Yeah, is it palatable for them to increase it to like a hundred bytes? I mean- Or just something that's arbitrary. A number that's higher than it is now, but just not unlimited. It's a happy medium, so to speak. What would, I guess, be the social merit in this?

Is like, are we placating people who wanna believe that you can restrict spam with these limits? Are we just, is this just about socially calming people? Cause like 100 bytes, 83 bytes, there's really no difference. It doesn't matter. There's no. See, the way I'm looking at this is like, Bitcoin is open source and Bitcoin is decentralized. And the fact that we could run our nodes, but we could also, if we want to submit code and potentially have that included into a node,

as long as it's in consensus, if people want to run whenever we want to include it in a no client, that's fine. And it's accepted. So that's part of decentralization. We have an ability to participate in multiple ways. But this, it just seems like it's autonomy where they just have all the power. They're making a decision without any consultation and it just it

seems to be a step away from decentralization. Is this correct? In my mind every time they take any kind of settings over your resource management or consensus away from you or withhold security disclosures as well as another example you are being disenfranchised as a node runner your ability to choose and run and configure your own code is compromised this is a probably I think minor example of that relative to other things like lot true Lot true was when we were talking about, I'm sorry, excuse me. We were talking about activating, what was it?

Taproot. And we were debating about whether or not to have a minor activated soft fork or a user activated soft fork for it. And all the user activated soft fork people understanding that nodes are the ones who get to decide, you know, what the definition of the protocol is. They're like, well, let's just throw up a node setting. We'll have lot equals true or false. And if it's true, they're opting into a user-activated soft fork flag day. And the core devs are like, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no,

that's dangerous. We can't have nodes choosing through configure options, what they want their consensus to be. Some of them will hurt themselves, which is a common theme you're gonna find in these stories. They might hurt themselves. And that's probably true. Some of them would,

but anytime you are a self-sovereign user, you have the possibility of hurting yourself. So they're like, no, we're not going to allow people to choose whether they want a UASF. If they want a UASF, they can go run a different client. And at the same time saying, do not run a different client, it's dangerous. This is kind of like the doublespeak of core maintainers and contributors is like, if you disagree with us, go run a different client. But at the same time, if you run a different client,

you're insecure and nobody should ever do that. So just do what we say we know best. It's very, very paternalistic. So they've already made these kinds of decisions as relate to consensus. And it kind of just got swept under the rug. Nobody really cared. The fact that people are losing their minds about this,

but didn't lose their mind about LotTrue, that blows my mind. This is not a new phenomena. I mentioned the security disclosures. How is it reasonable that Bitcoin node runners define the protocol, and they're the ones that are supposed to be defined in consensus, yet they don't know the code that they run with Core,

because they don't know what security that they run with core because they don't know what security vulnerabilities are in it or have been patched. The core devs do, but they've decided you don't get that information because you, they need to protect you. It's dangerous if they let you have that information, Len. What if bad guys attacked you with it? There's no conversation of having this information encourages you to, you know, make an informed choice about what code you're running and defend yourself. It's the bad guys might attack you.

They assume you're an idiot because frankly, in computer land as a software developer, we assume all the users are idiots. We go with the lowest common denominator thing here. And that lowest common denominator is an idiot user. But introducing that kind of paternalism to a decentralized project where the users are themselves the ones that are responsible

for the security properties is insane. But that's what the core devs are doing. They're applying the very best practices as relates to a centralized FOSS project. But that's not what I recall correctly. They're releasing these critical bunch updates, but not these These flaws within previous versions of core. I think they're now releasing up to core version 24. I could be wrong That's so far Run line to boom 29. Yeah. Yeah. Is this the block size wars 2.0?

Yeah, we're gonna forget about all this and argue about something else next week. Yeah, absolutely. There we go. Boom, that's your answer. You two are both there during the block size war. So this is nothing anywhere close to that. There's nothing to fight over. There's no consensus issue here to fight over. The lot true stuff could have been the next block size

or as if people were paying attention and decided to do something about it. But there's nothing to fork over here. Like we're talking about mempool policy. It's entirely arbitrary. What the negative consequences of this quote unquote war are going to be people leaving core for alternative clients, whether it's for reasons that are rational or not.

And we already see it happening. Like I said, not spent from like 0.8% adoption to 5% in the matter of weeks. So this is already happening. It's just a question of what, to what degree will it happen? And I think it's funny, like I said, I think it's hilarious because so many of these core devs, the reason that they're doing what they're doing

is because they want mining policy and relay policy to match as much as possible. And that is benefited the more people that run core when they were living in the lap of luxury when they had 99% of people running core nodes, and they didn't even know how good they had it, but they're gonna know now because that's not the reality anymore. Everybody's like, Oh, wait, no, I can run my own code. I can configure whatever I want.

It doesn't matter if I have the ability to shoot myself on the foot. I can also manage my resources. I can do competent, constructive things with my node and my data. And I think that no matter how you slice it, that empowerment of node users is a strengthening of our decentralization. It is the lifeblood of our

decentralization. And I love, love, love to see it. Both the rich irony of how the core devs are shooting themselves in the foot with this drama and how all these people, even if they're very misinformed and think that they're stopping spam somehow, are then empowering themselves by running a node and learning about its configuration. Good for them. And the people that are now running Nauts, and you're saying it's being reported around 5% of the overall network that at least are reporting what they're running. The majority of that has been in the past few days. A few days ago it was like 2 or 3% and now it's up to around five, just a little bit past 5%. So this is all a result of what is this opera turn drama.

So people are actively voting with their CPU power, which is pretty damn cool. Now, I just want to talk about somebody that seems to be very active on this, Jamison Lopp. Do you have any comments about him or? Because he seems to, yeah, go ahead. We just forked Lopp's site. Oh yes, talk about that. Bmaxis.com is where we forked it to.

So Lopp has an okay resource. Btcmaxis.com, just I just want to clear it. Btcmaxis.com. We just started it up. It's not quite done want to clear it. btcmaxies.com. We just started it up. It's not quite done yet, but it's there and it's functional. And basically I had a problem with some of Lop's positions. I don't like how he shills CASA in his resources. I don't like how much he tolerates shit coins

in his resources. It's problematic for me in the communities I want to run. So the Bitcoin discord community, which all caps and I run together, I decided that the community would do all the work for me and I would just fork Lopsight and they would fix it. And it's been working great. We forked Lopsight, we're at btcmaxes.com, and we are just systematically going through the many hundreds of resources and adding other ones that are new, removing dead links, and most importantly removing shitcoins and bad advice. And it's great. And that doesn't mean that LOP

isn't a valuable resource still. I really appreciate the research that he does, for example, on block sync or node sync times. He tests all the nodes every year to see how they sync, to see how they've changed year to year, whether they've optimized their syncing progress. I think that's really valuable progress. I think that's really valuable research. I think he's done really valuable research in regards to things like

materials testing and hard backup wallets. He's a good resource. I just don't agree with him about anything or about a lot of his views. I agree with him with some things and I don't like that. I don't like that he's got those resources in places where I'm directing newbies. So I wanted a different resource that I could direct newbies to, and that is btcmaxis.com. And that was spun up in the last two days, if I recall correctly.

Is that right? Yeah, I mean, we've had a GitHub repo open where please do come contribute. Like I said, I'm, I'm really relying on other people to do the work of vetting these links for Bitcoin maximalism because there's so freaking many, but we've, we've been doing it for a couple of weeks now and yeah, we just got the domain and we just got it set up in prod yesterday. A plethora on Twitter started calling us out and directing people to us.

So I was like, oh, we better get something up. He lit a fire under your asses to get it. Because yeah, he's got a pretty big following. And it's good stuff that he's shining a light on this. So btcmaxes.com for people who are wanting to check it out. BitVM. it out. BitVM. Did any of you want to talk about what the fuck this is? It's a way of validating that code was executed in a given way between multiple parties by going through all the various gates on chain.

I don't know if we've got a way to do it in an optimized manner yet. I haven't really been keeping up with the new iterations of it. As I recall last, I heard they were begging for covenants to make it more viable. I don't know specifically which covenant they're looking for, but that's as I recall. Quite frankly, I'm not overly interested in BitVM.

I do like the VUTXO proposal ideas and the channel factories for lightning ideas. I think that ultimately those are how we are going to scale. And I do support several of these covenants. What about you, uh, all caps, you got a dog in this covenant race? Not really. Is there any, if anything to do with the op return change, is that going to impact BitVM at all moving forward?

No. So there's no connection whatsoever with these two things. Doubling back to Lopp, one smart fellow is asking, what happened to Lopp's interest in privacy education? I don't think he's still doing that. Yeah, he's still writing articles about privacy. Lopp quite infamously was swatted, as I recall. And he went hell and high water to put himself off the grid, to get himself in a way in a situation where he couldn't be. Yeah, I believe it was during the block size wars.

That's fucking bullshit for people to do that. Like nobody deserves that bullshit. No, no, it doesn't matter what you think. Like, yeah, he, he was feeling like he was in danger. And so he took extreme means to dissociate himself from his docs locations and services. And he walks other people through how to do similar on his blog, which I think is another one of the valuable things that he does. Just because somebody shitcoins doesn't mean that they don't have

valuable ideas here and there. Each idea to its merit. But I'm not directing people to his site anymore. Sorry, Lop. That's fair. Peter Todd, any comments with him per se as a Bitcoin developer because I believe you did you ever meet him either of you two I think all caps did but no I didn't okay yeah I've met him a couple times he's a he's an interesting character I think the all caps and I have differing views on Peter Todd. I know he's angered a number of people due to his recent positions, trying to defend open timestamps from what he sees as anti-spam misinformation and attacks. But I think that Peter Todd's generally a good egg.

I also think that he's hypocrite. I think that it's very ironic that he is one of those leading the charge against things like mempool policy, claiming that they're spam, which, or that they don't do anything, which they do, claiming that they censor stuff or are trying to censor stuff, which they don't. I think that that's ridiculous because he's the one that was pushing full RBF. He's the one that was saying, hey, look, it doesn't matter that you've got these default core relay policies. You can just get by them whenever you want. And also it takes less than 5% of nodes propagating this to get by them. So the fact that he's like, oh no, mempool policy is censorship.

And then he's also like, but no, it's not. You can put in whatever you want is like I say, I think that he's a hypocrite. This is more about the ego and his open timestamps project and how he personally feels attacked by the anti-shit coin or community because they don't want to put arbitrary data on chain. And that's what he's doing. And he sees value in that, which frankly I see value in it too. I think Open Time Stamps is a great project, but that's where I see a lot of his position coming from is from that emotional position, not one grounded in facts he knows and has argued for.

So that's what I think of Peter Todd. If you want to see a great debate between Peter Todd and Luke Jr, you got to look up on YouTube, the plan B forum debate between Luke Jr and Peter Todd. And it's a really good one. Highly recommend watching that one You know what you should do all caps I know you have great media presence is you should cut up a set of clips of Peter Todd debating Peter Todd like this full rbf

One hand and then his work stamps On the other hand like yeah, I think that'd be a hilarious video. Yeah, you two guys was right. I did one for Michael Saylor where Michael Saylor debates himself. It's just crazy. Cause like he was talking about,

like Michael Saylor did a debate, a gold debate with a gold bug, like back, I don't know, five years ago. And in that debate, he was claiming, you know, gold gets seized all the time. But more recently, sailor was saying things like, you know, we like the United States didn't seize the gold at all, which is just totally nonsense. Anyways, that's a I'm sidetracking. Yeah, I think that guy he was always sorry

It's funny to watch a lot of these people that have an agenda argue against themselves. I really enjoy that Now you two both seem to be proponents of Not just options, but also not You seem to talk about it rather fondly. The one question or concern I have, I'm wondering if you guys could share the same concern I have, is that it's being maintained by, looks like just one person. Doesn't that kind of have any issues? I know we could review the code. We could do whatever we want with it as well,

but still it's just in the hands of one guy. And if somehow this goes rogue, isn't that concerning? Is it in the hands of one guy? I mean, it has multiple contributors and I know I audit the change set. And as well, I mean, the vast majority of people that are contributing to code that ends up in knots, like, I mean, you could just see the git

are the same people contributing to core because it is a downstream core fork. So almost all of the changes that you get in a knots release are core changes. You can't tell me nobody's auditing those. You can't tell me that that's one contributor. One contributor for their own change sets. That's no different than any of the other contributors who are also one contributor for their own change sets. So if you want to just do some extra review

on Luke's specific changes, I think that's a really good idea when you're running knots. I think you should, but you don't have to audit the whole thing. You don't... if your argument is that core is so much better audited and Luke's specific changes aren't, they're very minimal in any given release. They're trivial to look over. You can see exactly what's going on. I don't for a second accept the argument that there is only one contributor to knots and that that makes it dangerous and it can be overtaken. If Luke decides to start publishing malware, I mean like I'll fork knots and I'll do it

or someone else will do it. Like, I mean, it's... And it's not exactly a security concern for your Bitcoin because like Bitcoin nodes are infrastructure. They're not for securing your keys or they shouldn't be. You should not be using Bitcoin Core or Bitcoin Nauts as a wallet. You're using your cold card, you're storing your keys offline, and you're using air gaps to interact with the Bitcoin network. And you're just using your Bitcoin node to express Bitcoin network and you're just using your Bitcoin node to express your view on consensus or policy like OP return policy is in this case. So it's

not even if nots was totally compromised it's not like your Bitcoin are going to get stolen maybe your node gets knocked over for a day that could be a problem for your Lightning node. If your Lightning node is relying on Bitcoin knots, but it's not a big deal in most cases. Even if it is, I mean, your time lock time for your Lightning injustice transaction is gonna be longer than one day

and you're always empowered to, this is why it's so important to be engaged in the code you run and making these choices. Benny asks, Luke got hacked and he claims to have lost all of his coins from a vault beside his computer or something ridiculous like that. And he's, I think, worried what happens when people that have been hacked are pushing malware.

It's like, well, this is why it's so important that you'd be building from source or at the very, very least be checking against hashes from known people. And that's not a very good option when you're checking just one guy's hash because what if he gets hacked? So just build from source.

Build from the source, review the gets, it's not hard, don't needITs. It's not hard. Don't need to be a programmer to do it. I'm a huge proponent of that. I try to, at least for the stuff that matters to me, I try to build it from source. And you're right, you don't need to be a programmer. You just have to follow instructions

and sometimes even just do some searches online if you do run into any roadblocks. That is, I'm a big proponent of that. I just want to ask you a question about clients, Bitcoin, node clients that we have available to us. There seems to be so few out there. Is this concerning? Because now we're, what, 16 years into this Bitcoin experiment, to quote air quotes, and we really

just don't have that many alternatives to core. Isn't this concerning at all? Well, first of all, is what you're saying true? Is it an accurate statement that there are very few alternatives to core? Let's start by just naming some nodes that we know. Can anybody name some nodes that they know? We got core, we got knots, what about any others? Libicoin? Is that one? Am I wrong? Yeah, BTCD. Bcoin, BTCD, yeah. Are they all being maintained? I just don't know. So I would love to direct you to a great page,

uh, on btcmaxes.com. I'll post it in the chat right here and it has all of this information on it for you. Oh, apparently I've got to connect to my YouTube. I'll put it in the private chat and you can put it in the full chat. But yeah, we have a list of all the nodes that are commonly used. These are also the nodes I mentioned to that Luke, or not Luke, I'm sorry,

that LOP does a yearly review of nodes and their syncing properties. So we've got Bitcoin Core, we got Bitcoin Nuts, we got Bcoin, we got Block Core, we got BTCD, we got Floresta, we got go coin, we got lib Bitcoin, we got Nick's Bitcoin. So we made a lot of those, we got a lot of them, I'd say we got like 75% of them. And what are being which ones are being maintained? Because a lot of them, I have Floresta I've never heard of a go coin

never heard of that. I mean, not those downplay it but I just never did are all allegedly being maintained I haven't actually see this is why we need people reviewing this according to lop those are the maintained ones he also has a list of the unmaintained full node software BTC warp Mako parody Bitcoin zebra B Parity, Bitcoin, Zebra, BTC, and links to those abandoned projects. So it's possible that some on that list have already been abandoned. It's also incredibly likely that there are others that aren't on the list. This is part of why we need people to come in and help us review some of this content. But

we do know for a fact that there are a number of these other kinds of nodes. And I'm pretty sure all of them work. Cause like I say, he tests them every year. Okay. That's fair. It just seemed to me that there was just so few. I don't know. I don't know why it just- We don't, Core has 99% of the market and up until, you know, a couple months ago,

Knotts had 0.8 and that was it. Everything else like there's BTC sweep with point oh three or something like there are people running nodes. I think it's more of the concern that the larger communities pretty much just doing the default of downloading Bitcoin core and not really thinking about any of the other options. And so, you know, Any of the other options and so, you know skirmishes like this one Are very good education opportunities to let people know it's not you know You don't have to just run Bitcoin core. There are these other options. You should consider them and That's that's a choice you have that choice

Somebody was asking about hidden agenda or having oh we're not allowed to talk about that. Didn't you read the moderation rules for Bitcoin core and related repos like dip slant. You're not allowed to talk about where people work or what their agenda is or their ulterior motives that gets you banned. Didn't you know that I was not not over here. Over here, we're able to talk about what the fuck we want.

So, well, almost. Just checking. I didn't want to get banned. You know, you're definitely not going to get banned, but do you want to add anything to that? Because it seems like you have. Well, I would like to add the pointed comment that the moderation rules of these repos

are absolutely ridiculous. And of course, I'm alternative motives. I want want to add to like, this was a tip. Like there's there's two things here. It's the actual issue of the technical overturn toggle being removed and the limit being removed. But it's also how how this social interaction has happened with Bitcoin Core and the larger community. They have bungled the shit out of this. This is a PR nightmare for the brand of Bitcoin core.

They have lost, they have lost their shit and it's a public relations disaster. And it's just, it's not, it's not a great look how they've handled any of this. Like banning users from the GitHub, hiding comments, then locking the thread for the PR, then opening the thread for the PR to allow one Bitcoin Core contributor to comment with an act and then closing it right afterwards and then deleting that act in Embarrassment it is just a nightmare for these people and they're kind of getting what they deserve But also not like humans. They are humans, but the flaws are Kind of showing and you know, it's not pretty. It's really not pretty.

Yeah, managing projects doesn't seem to be their forte. There are a lot of them. They are coders, computer scientists, shit like that. So when they have to step outside their comfort zone, it's really noticeable that they're lacking in some other skill sets. And I'm not sure what to do about that. I mean, does somebody that with better all around skills get into the Bitcoin Core team and help them out?

Is that something we should be advocating? Let's talk about this. So like, I've been arguing about this with Greg Maxwell for a week now, and he's of the position and there's a degree to which I agree with him that core devs actually need to be much more strict with their moderation. That they need to have a much safer place to do their development work outside of all of this drama and misinformation and nonsense. And I think that he's actually very right about that. They do.

Where he's wrong in my opinion, is that because the core devs and maintainers and contributors, they don't acknowledge either an action or word, the value of node runners and how they define the protocol, how devs have no power over the protocol. They can't auto update software. They have no ability to push code. they can't auto update software, they have no ability to push code,

they can't manage things like consensus. I think that users need to have a very real role in determining the direction of the software, even if that's a negative direction as far as the devs are concerned. Bitcoin users define the protocol and if you do not give them that kind of access over the repo, which no other FOSS software repo would have, this is an absurd idea because Bitcoin is absurd. Developers

generally get free rein to decide the things that they want without consulting users about it. But not in Bitcoin. If you want people to continue using the reference repository, you need to give users a say. So there needs to be some structured way to both keep the core developers insulated because a lot of these are just, you know, autistic engineers, which I can really sympathize with frankly. But at the same time, like they don't get to decide what the protocol is. They are facilitators at best and maybe they don't like that decide what the protocol is. They are facilitators at best, and maybe they don't like that,

and yeah, they're volunteers, you don't get to direct their work. But if you don't give users a voice, if you don't let users have these options, even if you feel like they're foot guns, they're gonna go to somewhere else. They're gonna go to knots. They're gonna go to other alternative clients.

And like I said, that doesn't serve the dangers that the core dev see either. That's like way worse than having this option. I want to push back on, on their, I think they're them being defined as volunteers. A lot of them are paid to do what they're doing. At least now, maybe they were volunteers to start out with, but a lot of them are paid to do what they're doing, at least now. Maybe they were volunteers to start out with, but a lot of them are now paid by private companies. And I don't think it's a fair description to describe a lot of these people as volunteers. Which is why it's so important to be able to discuss things like conflict of interest

and actual motivation of some of these proposed changes, but you can't do that. That's not allowed. You get that. No, you get banned for that. Sorry. Given that the block size wars, it's a little less than 10 years ago, but still the people that are involved with core, they were there at that time.

involved with core, they were there at that time. How could they forget that the people that the node runners have a lot of power? This is a good one. This is a great question. Don't you remember how they acted in the block size? Go No, remember what they were doing? They were actively fighting against the UASF at every turn. They blocked every proposal to include logic accommodating it in every turn. They blocked every proposal to include logic accommodating it in core itself.

They went on social media and actively discouraged everywhere they went. They told people that running these clients was dangerous. That was gonna cause all kinds of problems for Bitcoin. They fought as hard as the big blockers did against the UASF. They haven't changed. They're doing exactly what they've always done. They believed in, at the time, state security. They felt that allowing nodes to arbitrarily

choose when to activate a fork without knowing that they had state safety in the form of a majority of miners agreeing with them could lead to people ending up on minority forks. And they're absolutely right. It could, it is dangerous. They're right about all of these arguments. The thing is, it doesn't fucking matter because nodes need to be able to choose their own consensus. They need the ability to hurt themselves. That is a consequence of their sovereignty.

To not have the ability to hurt themselves is to not have that sovereignty. And that's the ballgame. So yeah, no, they're just doing what they've always done. They've always been incredibly paternalistic. So another thing too, is the person who wrote the UASF client is the same person who maintains Bitcoin knots. So this is this is a microcosm. It is a reflection in a mirror event of the UASF

user activated soft fork and the block size wars. It's a proxy. It's like it's another skirmish of the same kind of conflict, same characters, and same ideals are kind of at play here. This is just a microcosm of what has happened before. So Luke Jr. was the one who put together the UASF client during the block size wars and he's the same guy running Bitcoin knots, maintaining it. Fun. He has to have a target in his back. Well yeah, I mean like you look at how the core devs have treated Luke, like in every

IRC meeting he is immediately dismissed. Hell, they Luke made their repository for the translations. Yeah, they stole it. They stole it from him. They just outright took it. Yeah, he made the mistake of giving I don't even remember which core contributor he gave shared ownership over it, but he gave it to him and then it kicked him out.

Because on the basis that some translator just didn't want to translate for not. What actually happened is Luke first kicked out that person and then someone with like with admin access kicked out Luke. So it was kind of a tit for tat and it did it was just really messy if you look at the IRC logs. It's his repo. Yeah. I mean it Luke did did sort of fire the first shot. Well, yeah, I mean, they were, I don't blame them at all. They kind of set him up, though. They did set him up.

He took the bait, though. Which isn't to say, like, I agree with even Luke on everything. Like, I think I was just watching the Bitcoin Plus Plus panel and Luke was on it. And like the things that he says just makes me crazy. He does believe that Mempool policy in some way either increases the costs. So do I. So do I. You're both ridiculous.

And that it actually mitigates spam that reaches the chain and it just doesn't, there's no mechanic of. No, we're not saying it doesn't reach the chain. We're saying it raises the cost and that cost is worth fighting for. It's worth fighting for. No, I'm willing to play Whac-a-mole. Let me play Whac-a-mole.

I will play Whac-a-mole all day with this. If I can just go to a miner and I can have my transaction published at will as like I showed you yesterday that you can do, how is that a cost to me? It doesn't cost me, it costs me time. If there's a minority of miners that are willing to mine this,

I have to wait for one of them to get a block. Yeah, that's fine. Time is enough as well. Time is a great cost. But that cost isn't created by the filters. That cost is created by miners choosing what they do and do not wanna mine. Your node doesn't, unless you're a miner using Datum,

which frankly every miner should do, please use Datum on Ocean so that you can choose what goes into the blocks. But unless you're doing that, like you don't get a say in what goes into blocks as a node. Not outside consensus anyways. You want to fork over it? Fork over it.

And that's kind of what you're talking about. You're putting words in my mouth. Well how else would you play whack-a-mole without forking to put some of this, like for example, we can identify when somebody is misusing the if syntax as an ordinal, right? We can identify when somebody is trying to do an op return. We could fork those out, but it wouldn't stop people from putting arbitrary data on chain. They would just obfuscate it. I don't know why you're setting up this false goalpost again of like stopping them. That's not, well, kind of is the goal, but I know we can't reach it.

It's more about creating costs for them. So that's friction. So what friction is created knowing that, you know, we can publish these whenever we want. And the only cost, I guess, is time. Like, is there any cost other than the time? Well, time and scamming them when they go to the web portals. See, but that's just another avenue for the scammers to make money.

Like it sounds, so you can go to any miner, right? And many of them will have web portals if not accepting connections directly to their node where you can have transactions broadcast. They basically hook it into the Bitcoin core or not broadcast API. And like you can get a transaction into their mempool. However, I think Fiat is saying that they're going to start charging for that.

The way that opportunistic scammers who are like, oh no, they're censoring us. Why wouldn't they them? Why wouldn't they charge? Like they have a captured audience that is ignorant, stupid and doesn't know any better. They will charge something. Why not? Yes, vague is factually correct. Filtering is virtue signaling to a degree. You can also use it to manage your node resources. You can also use it to incur additional resource costs, but it can also be virtue signaling. And all those transactions are still added to the blockchain anyway.

And you do run your ability to estimate fees. Let's keep in mind though, Vic, what ability did you really have to estimate fees in the first place? It's gonna be a little bit of a delay before he answers, but I just want to say, if anybody likes this discussion between Gnome and and all caps and myself, beer, sorry, Bitcoin and beers on the Bitcoin Discord. There's a website that

directs people to that Discord directly. What is that website? BitcoinDiscord.com and yeah it's tomorrow at, I don't know, I don't know what UTC time would be. Sometime in the afternoon. Tomorrow at I don't know. I don't know what UTC time would be Sometime in the afternoon. Yeah, it's it's three hours before now tomorrow So it'll be around 5 p.m. Eastern ish So if people like this type of discussion this happens frequently on that discord Not just verbally but also typing the signal is very high. I just want to every two weeks on thursday Perfect. I I just you know, I I can't talk about it highly enough. So please check it out

now with all this banter back and forth With all this peter todge shit this jamison lovston and everything that's going on Does this leave a black eye on Bitcoin itself? Now that we have traditional finance failing, you see nobody wants to invest in bonds, gold, although it's done well this year, but people are trying to look for alternatives and Bitcoin has a lot of advantages over gold. But still you see this in fighting this bickering that's going on within the Bitcoin community.

Does this leave a black eye and it makes it harder for people to want it? No, this is the core of Bitcoin. It's like fight or flight. It's like this all the time. You just haven't noticed. And this is part of it. The fight for Bitcoin is constant and it's on all domains and it's beautiful. I love it. Best part of Bitcoin. I really enjoy this shit.

And like it's, it's, this is my jam and I'm all about it. I get bullish when, when we have these fights because honestly they're, they're not the end of the world. They're education opportunities. They're fire drills. They're, um, just ways to show people how to do things in the best way possible with your Bitcoin, run a Bitcoin node, take possession of your Bitcoin keys, and, you know, have a cold wallet. And this is why I love like when exchanges blow up, their education opportunities. It's not the end of the world. It's just Bitcoin doing Bitcoin things and everyone's learning. I completely agree with that. Like I was saying, I actually, I disagree with kind of

the largest section of both sides of this debate. I disagree with the core devs have kind of been hammering on them a lot. I disagree with Luke and his positions on this. The people that think that they can use mempool and relay policies to in any way inhibit shit coins or scams, I disagree with them. I see as Fiat says, you know, this says, or sorry, all caps says,

this is an opportunity for education. And even if some people are a little misinformed, I'm really, really so encouraged at the fact that so many people are running out to choose the code they run, to configure the code they run. That to me is a way bigger prize than the inconvenience of dealing with a little bit of misunderstanding

about how their mempools work. This is like an opera, huge opportunity to educate that like you should configure your mempool, but it's not about stopping anybody else from doing anything. It's about you. It's about your resources. It's about what you want Bitcoin to be. It's about how you want your software to run.

And I think it's beautiful that people are, are starting to take an interest in that instead of just lazily defaulting to whatever core says or does. I think that that's a really unhealthy behavior and what's happening right now is a really healthy behavior, regardless of if it's coming from a place of ignorance or not.

Guys, we've been at this for a little over an hour and you two are still full of energy and still able to provide some very good insight. Anything else you guys want to, do we exhaust this topic in totality? Do you still want to, or you have anything else you want to bring up that we just haven't discussed? Oh, we're like, we're going to be talking about this for weeks. Like we got, like you

said, Bitcoin and beers tomorrow. Like we haven't even scratched the surface of this subject. Going into depth about some of these arguments, like the reconstruction times, the block reconstruction times. Greg Maxwell says that it's even for one single missing transaction in a block. Like let's say you've blocked an ordinal spam, but the ordinal spam makes it into the next block anyways. You then have to redownload that.

It can increase your personal, as the average node runner, your personal block reconstruction time by up to three times, just for one transaction. If you've blocked many, many transactions that are in the block, you can imagine that your reconstruction time for this block is actually pretty significant. It could be huge. And that's

something that has Greg Maxwell and several other core developers very concerned. I don't agree with the concern at all in any way, shape, or form. We have previously had way slower block propagation times before we had, for example, the compact block propagation. But at the end of the day, it doesn't really matter because it's kind of an inevitable consequence. Even if there was some huge issue with block propagation times because people are choosing their own mempools, people are going to choose their own mempools. They're going to choose their own relay policy. So while I'm very interested in the statistics that Greg brings up and how this more people running alternative clients might be affecting the network, I think that's a very curious and interesting thing to observe and measure.

I don't think that it should be changing anybody's mind about any of these issues. Why should I, as a node runner care about block propagation times for Bitcoin miners? It's not affecting me, right? And that's the other part of it is like, if you are a Bitcoin miner, you already are aware that propagation times are really important to you. Every millisecond you don't have the last block that was mined is a millisecond that someone else is mining on that block and you're not. So you care about it in a normal small.

So if you're a miner, you're already, you are not the average node. Measurements of the average node statistics are irrelevant to you because you are already taking actions to directly connect to other miners to make sure that you aren't being exclusive about your mempool policy because you do want to have all of them in your mempool so that you can quickly reconstruct these blocks.

There is- I want to pivot on that. The point there is Bitcoin Core is building for Bitcoin miners and Bitcoin Nauts is building for Bitcoin node runners. There's a sort of specialization that I believe is going on here. And I think it's gonna grow.

I think we're just starting and we're gonna see more competing Bitcoin clients and I'm here for it. I think it should happen. I don't know if I'd put it so bluntly that they're like building for miners and not just building for users. But I-

That's what it feels like. Settings that they're proposing, if everyone adopted them, would be good for the network properties as developers define them while disenfranchising users of their sovereignty. Who does it benefit? Who benefits?

Well, it can benefit users. So it is in a user's interest in terms of things like fee estimation to know what the mempool looks like. If you want to accurately and minimally pay your fees for whatever your stated block priority is, I wanna be in the next block, I wanna be in five blocks from now, you want a good idea of what is going to get mined.

And if- Do you think that's primary argument being put forward here? It's definitely a major argument. It's one of them. It underlies all of these issues because it's kind of a constant way of thing. Like for example, all the mempool rejiggering that Core just did, a lot of that is about the fact that many Core maintainers

and contributors believe that it is in the best interest of Bitcoin that relay policy and mining policy mirror each other as much as possible. If they don't, quote, vaguely bad things can happen. And they're not wrong about those things, but that's Bitcoin. Like those vaguely bad things, they're gonna happen. Just like, you know, people are gonna fork.

They're gonna do UASFs. They're going to do whatever the hell they want and you can't stop them. So quit trying to control other people's behavior and instead insulate users for the reality that all of these options are available to them. Some of them they might use to shoot themselves in the foot. Some of them they might try and use

to shoot their neighbors in the foot, regardless of how effective that may or may not be. But this is Bitcoin. It is a blood sport and everybody is doing their own thing. If it isn't in consensus, it is not nailed down. And the sooner that core devs can appreciate that, can accept that, the sooner we can move on to far more substantive conversations. can accept that the sooner we can move on to far more substantive conversations One smart fellow writes isn't miner block proposition Time a wash sometimes you win sometimes loots keeps adding to that You only see the times you lose but you would likely win equal amount of times odds are so yeah That's that is correct. But like imagine one smart fellow, imagine that you are a big miner.

You've got like 30% of the mining pool and you produce more blocks than somebody who's got 5%. Every time you produce a block, that time between when I produce that block and it goes to someone else, that's a smaller minor, that is time I get to mine for free. I get to mine with no competition or minimal competition because the block I mined hasn't reached anybody else yet but I can start mining on it like instantly. So that time between when the

block is fully reconstructed and delivered i.e. block propagation time to the smaller miners. And when I find it, that gap of time is free mining for me. If I'm a bigger miner, I'm gonna have more and more free mining time than the guy that's only got 5% of the mining power because I'm gonna find more blocks. There are going to be more occasions in which I get that window of time to be mining for free.

And this is also one of the reasons that we see so many empty blocks mined. It's because if you don't have all of the transactions downloaded right now, the only way that you can mine is to mine on an old block that you don't, the one you have validated. So you're not mining on the new block, even though you know there's new block.

You're racing in that little tiny window to be like, oh my goodness, can I find another block? I'll make it empty. I just won't put any transactions in it because I don't know what was in the last block and I don't want to double spend anything and invalidate myself. And sometimes they win it.

And so you see like a block happen one after another, like even a couple of seconds. And the second one often is empty. That is part of this phenomena of propagation times. So the argument is that it's bad for miners decentralization if there is a very large propagation time. And that's true to a degree. But the reality is miners are not the source of our decentralized properties. And this small amount of time is inconsequential on the larger scale of propagation times we've seen over Bitcoin's history. This is a non-issue, at least as far as I'm

concerned. Many others disagree. So doubling back to a comment that CJ wrote about seven minutes ago, he says the op return situation is simple. Does the removal of the limit aid or prevent spam scammers on a network? Everyone knows the answer, so everyone should know it's not a good idea. No, the limit doesn't aid or prevent spam slash scammers on the network. The argument I think could be made that

the more scammers and spammers are using OpReturn as opposed to other methods, the better it is for the network, just because the UTXOs set isn't bloating. Like we can, that's really important. We don't want to bloat the UTXO set. That makes it really hard for light clients. It makes it very much more arduous in terms of the data that needs to be stored for pruned nodes

and the verification that needs, we want a small UTXO set. And when people aren't using OpReturn to store their arbitrary data, as we've seen the last couple of years, like it blows up the UTXO set in very destructive ways. So we kind of do, scammers are gonna scam is the reality of it.

I know that all caps, I know you wanna play whack-a-mole to whatever degree you can, but I'm of the view scammers are gonna scam. They always have, they always will. There's nothing that we can really do about it except for make sure that they pay the costs that are appropriate to them. We can't do that if they're in the witness script.

We can't do that if blocks are too big. But yeah, they need to pay what they owe. And they need to optimize their data. And we need to make the cost significant enough that they have an incentive to optimize their data. And right now that just really isn't the case. You look at the people that are using OpReturn or are using Ordinals, and it is the most poorly engineered shitcoin garbage you've ever seen in your life. Like they're putting JSON on chain. They're putting JSON on chain. They're putting JPEGs.

Like this is not in a coding that you want to use for saving space and data. Like you put the same exact nonsense data on chain at a fraction of the size if they would just use their freaking brains or better yet don't put any of it on at all. Take it off chain and be using hashes of that state. Store the data yourselves in your own nodes privately. It doesn't need to be on chain. So there are ways to do this responsibly. It's just that nobody's doing them. And that maybe that's a description

of a lack of the proper incentives. Maybe we need a smaller block size to increase the costs of block space so that scammers pay what they owe. Yeah, I don't know. I would be more open to smaller block size discussions in terms of if we wanna talk about playing whack-a-mole with scammers.

Like to me, the way that we stop abuses on chain is by economic cost. If we all agree that these scammers are abusing the chain state, like we should increase the costs. And as somebody who does put arbitrary data on chain, like I would very much support that because I optimize my use case. I'm only putting down a very small hash.

And I think that's what other people should be doing too, but they're not. So like, let's, let's jack up their costs. Let's do it. To the limit Chad, many let's go I'm in for it for making it smaller to Gulag saying decrease the block size. It looks like you're, you're resonating with some folks out there. They seem to like this. What's SegWit a good or bad idea in the end? I think SegWit was a good idea. I think that we need to change the, I would at this point be getting rid

of the witness script discount. I don't know if that was a good idea. Yeah, but SegWit is a lot more than that. I don't like the witness script discount. Yeah, it's also not clear to me whether that's a soft fork or not. I keep hearing different answers about that. So like, did you know, did you know all caps

that on your knots node, you can change the way that you weight the script data when you're calculating your V bytes? Normally when we calculate virtual bytes, we take the real bytes, the actual size of the data, and all the non-witness data, we multiply it by four. Then we add all of that together and we divide it by four. So the result is that witness data basically gets a discount of 75%. And if you want to in your knots node change that calculation,

so your definition of V bytes is different than everyone else's, you can absolutely do that. There is like Glenn was saying, like a slider, there's a box and you can put in whatever weighting you want and change the definition of V byte to get rid of, for example, that discount. It doesn't take a hard fork. All it would take is miners deciding that they were going to agree on a different convention for V bites and different waiting. And I think that that would do it.

It sounds like a dust limit. Gentlemen, have we exhausted this? Is it 115? I don't want to keep you guys forever here. I'll play. Some of us are obviously trying to exit this conversation. I don't think it's me or all cap. No, no.

Fuck. I'll stay here for I just don't want to abuse your time. You guys are going to blow you to right now. Virtually blow you to. I do not consent. I don't. Me either. Not here for you. You're a handsome man, but I do not consent when I don't need either not here for you

I'm you're a handsome man, but I'm not doing that No, but we only do that in Montreal then No, but I appreciate you guys taking time to come on here look the people in the chat They absolutely love this and said it so did I so like I again This is just awesome. And if you want to hear more of this I can't stress enough go to the discord the Bitcoin discord the Bitcoin and beers Every two weeks on Thursday, there's gonna be one tomorrow. That's gonna be May 8th So check it out and it's gonna be a lot of fun. So Guys, I think it's it's pretty much time to sign off before we do

Silencing us. I told you he'd ban us. No, I will never fucking ban you guys We love you then love you too, but I just want to Yeah, where can people find you in case they want to reach out and start with you. Mr. No Arnaud when discord calm I'm there I'm also there. Yep. I'm on Bitcoin discord.com where you can follow me on Twitter, Bitcoin All Caps. And I have to say, All Caps, this is the first time you've been on somebody else's YouTube. You did run your own YouTube and I don't want to rehash, so it will bring up some old wounds, but this is the first time you've been on somebody else's YouTube channel, is that correct?

I think so. Yeah. So was it all is it made up to be did you enjoy it? Was it? I really did. Thank you for having me on and thanks, Noam for leading the charge. I'm sorry. I didn't even let you talk. I just kind of like, I'm good with it. Thank you for everything you do. Thank you guys, appreciate it. We'll be back at this again Monday. And thanks once again for joining us gentlemen. So have a good one everyone. Take care.