Bitcoin Core and the Spam Debate with Murch | Bitcoin Infinity Show #182

0:00 Murch, welcome to the Bitcoin Infinity Show. Nice to have you here. Thank you, Knud. Thanks for having me. Yes, just before we started here, we were trying to figure out if we met in real life ever, and I don't believe we ever have. So I'm looking forward to this conversation and get to get to know you a little better. Where to start? So where to start this one? This is an interesting one you're a core developer yeah it's it's part of what i do i've been doing a lot of educational projects in the past decade i've also co-founded localhost research recently so now i'm sort of also helping run a well to be fair my my co-founder does more more of the back office but a little bit of the running of a non-profit that funds bitcoin development and so yeah i've been a Stack Exchange moderator since 2013.

0:56 So I've been looking at a lot of technical questions. I've helped with the Optech project for a while. We've been recording a lot of technical newsletters as podcasts in every week. So I also contribute to Bitcoin Core, but it's only part of my time, is what I'm trying to say. Yes, but you're definitely a more technical person than I am, I'd say. I agree with that, probably. I think I'd like to start with a question I get a lot from noobs, and that is the simple question, what is Bitcoin? What's your answer to that question? Yeah, Bitcoin is a decentralized network on the internet that allows us to have a censorship-resistant digital cache.

1:44 So it's sort of the native currency of the internet. okay yes i usually answer it's an agreement on a fixed set of rules and the longer answer is that the reason we agree on this specific set of rules is because these are the only rules known to man where it's practically the only rules known to man where it's more expensive to try to break the rules than to just follow the rules and would you agree with that i i think i'm not sure if i'd say cause and effect aren't a little intermingled here. But maybe my answer is more abstractly what we're trying to achieve, while how you describe it as a shared set of rules that we all agree on is more of an implementation, how we get what we want out of it.

2:34 So I think they're both aspects of the whole picture. Maybe I need a little more of your answer in mind, but vice versa. Yeah, I'm trying to find the common ground here because I think a huge part of this debate between core and nuts and so on and about how dangerous spam is and so on and so forth, a lot of that has to do with what people think Bitcoin should be. And I think there's one camp that wants Bitcoin to be money only, and that is send, receive, do not lose value, sort of, or do not inflate. Nothing more than that. And then there's the other camp who wants to scale Bitcoin in all sorts of ways and add functionality.

3:21 and i think sort of everyone agrees that that functionality has to have something to do with money or or maybe it has to is wrong but but ought to have something to do with money and how money functions so we scale in layers but i i think it's a little unfair to assign bitcoin to be money only to one of those two groups i think both of these groups want bitcoin to be a money One group thinks that scaling is not part of what makes it a better money, maybe, or not as much. The other group, I think, well, I don't want to put too much on it, but I think part of when you think about the technical system that achieves what we want from it to create a internet money is where is this going to be in 10 years?

4:17 where is this going to be in 20 years? What will make this future proof? And what are the inherent properties of this technical system that make it stable? And for example, I had this conversation with Luke DeWolf a few days ago on Twitter, where he said, it's only money and shouldn't be anything more and censorship resistance is not a core property of Bitcoin. And for example, I would push back on that because if you cannot spend your money without being adhering to some censors agenda then it becomes a lot less useful as money so for me censorship resistance is an inherent property that must be present in order for us to be able to use our money and that is therefore a core property of what we need out of bitcoin so i i think there's there's not a sharp line like you described it as two groups here.

5:15 I think it's a spectrum of how people perceive the project and what they include as core properties or useful properties. So there's nuance here. I would agree that there is everything from Bitcoin should ossify now and it should never be anything but send and receive and store value. And everything on a line from that to Bitcoin should be Ethereum 2.0, basically. And everything in between. I don't think anybody here is asking for Bitcoin to be Ethereum 2.0. This is a talking point that gets brought up a lot. I think it's just a straw man and not very interesting.

5:58 But maybe you can explain to me what would make Bitcoin Ethereum 2.0. Well, when I hear baps, I cringe, because baps, to me, sounds an awful lot like daps, which weren't really... What are baps? Well, apps on Bitcoin. This is what Citria is trying to build, for instance. But yeah, let's rewind this, because I really want to dissect this from... I want to go from the inside of the onion and out. I want all of it. So when I hear censorship resistance, I absolutely 100% agree that censorship resistance is crucial for Bitcoin to function.

6:40 Otherwise, it wouldn't be Bitcoin. But to me, that means uncensorable transactions. It doesn't mean I get to do whatever I want in terms of what kind of other data I put on the chain. Would you agree with that? Transactions in this case means payments. Yes. Yes, I send... You want uncensorable payments, but not uncensorable transactions. I want uncensorable sats. Like, I want to send... Sats is the thing I send to other people, and then they give me something of value back. Including whatever you do on computers, including BAPs, including whatever I find valuable. The thing is, money...

7:22 If Bitcoin is money, like, if we want to come to a damn near perfect form of money, or as flawless money as possible, then other use cases is completely... It's bad for its functionality as money, just as jewelry and industrial use cases are bad for gold as money because it messes with the price signal. Sure, it may make price go up for a while, but it's just added volatility because at some point there will be a rug pull and then the interest for this goes away. So what would you say? how would you define censorship resistance let's let's start there so censorship resistance for me means that people are going to be able to get their transactions into blocks as long as they are willing to pay the price to do so and they do not have to adhere to usually one specific group's agenda that is trying to prevent something the counter example for example would be if too much of the hash rate moves to the United States and the US government gets some sort of power over what gets into block templates and forces the US miners to enforce those restrictions. And suddenly everybody has to register their addresses with the US government. That would become censorable.

8:45 And we would not be able to just use Bitcoin the way we want. I would like us to not need to adhere to outside forces idea of what Bitcoin can be used for. 100% agree. Wasn't this, by the way, what Mara tried to do when they were trying to be OFAC compliant in that? And it blew up in their face wonderfully. Yes, wonderful. I absolutely agree with that. So to devil's advocate that. So I'm a Bitcoiner. I want to send Bitcoin to someone else because I want to buy a pair of jeans or whatever. I want to send sats to someone. but it costs me too much so i refrain from buying the jeans because the fee is too high because the block is full of because someone fooled another person that is that a picture on the internet can be owned so therefore this person has paid a lot since he was able to fool the other person that a picture could be owned he managed to cram the block full of arbitrary data so now i am censored in a way because i cannot use my bitcoin to buy the jeans because i the fee is artificially high and not high because of a high demand for monetary transactions what's wrong with that i disagree with that because what is preventing you from spending your money is your preference of spending less for using your money rather than a censor deciding that you shouldn't be able to

10:17 so to talk about censorship resistance a little more i think we need to open a couple other threads here one is why do we even have a scripting language in bitcoin what are we trying to achieve with that and the second one is why do we have a block size limit because both of these lead to a people being able to do other stuff with bitcoin and b we have us having a blocks-based market that drives up fees if there's a lot of demand. Yeah. Yeah, sounds good. Okay. So far, then again, there's a lot of things to double-click on there.

10:59 For instance, blocks can be four megabytes now, and in hindsight, it would have been better if it would have been capped at one megabyte. I don't agree with that either. Okay, so just, I'm unsure if I agree with that, but I think I lean towards that. But okay, give me more information, please. Where do we start here? Scripting language. Explain this. Where do we have a scripting language in Bitcoin in the first place? Do you have an answer? No, I bet you have a better answer than I do. Well, the best lead we have on that is a conversation that Gavin, Andreessen, and Satoshi had, where Gavin was like, oh, scripting language makes it more complex and complexity is the opposite of security.

11:43 And Satoshi said, well, I wanted to be able to express any form of transaction, monetary transactions like escrows, like future contracts and so forth. And the only way that I found to do this in the first version of Bitcoin that would basically set how Bitcoin would work forever was to introduce a scripting language in order to be able to flexibly later design these things. And I think this remains the goal. We have a flexible scripting language because we don't know exactly yet what people will use Bitcoin for in monetary ways.

12:24 For example, an escrow is a very obvious monetary smart contract that is super useful, that gets basically used all the time. So the question is, if we don't want those sort of things, we wouldn't have to have a scripting language, but we would be set forever on basically the things we can do with just very basic standard Bitcoin transactions. Or do we want to be able to build things like the Lightning Network or other scaling solutions that crop up like ARK or UTXO sharing mechanisms and so forth.

13:05 And if we do, we do have to afford ourselves this flexible scripting language. So the question is, do we want to have a flexible scripting language in order to be able to express more predicates in the future that allow us to do nifty things on top of Bitcoin or don't we? How big a percentage of the Bitcoin users do you think thinks this is a priority? Like, how many Bitcoiners actually care about shared UTXOs and maybe shared UTXOs? How many Bitcoiners use Lightning?

13:45 Yeah, that's a good question. I know of Bitcoiners That a good response I think Because that is exactly a UTXO sharing scheme Lightning is a UTXO sharing scheme Yeah Here the thing though with Lightning in particular So SegWit came with this discount, right? And the intended purpose of the discount was to incentivize people to consolidate their UTXO. So basically less UTXO bloat. Am I right about that? Well, there's several different reasons that led to the SegWit discount. first. Without the SegWit discount, we wouldn't have been able to add another section to Bitcoin transactions that was not covered by the transaction ID. So adding the SegWit discount indirectly enabled us to remove transaction malleability. Yes, that's a big one. Wait a minute. So the discount, that wouldn't have been possible without the discount. Are you saying that?

14:44 Then we would have needed a hard fork in order to increase the block size. And then the second one is, yes, it intended to align the cost of inputs and outputs in a different way. Previously, if you look at pay-to-public key hash, an input is 148 bytes, an output is 34 bytes. So an input is four and a half times or so more expensive than an output, which could lead to many situations in which it was cheaper to create a second output than to add an input. and it tended to just bloat the UTXO set. Yeah, so it was to disincentivize also UTXO bloat.

15:24 So UTXO bloat in two different ways. Make it cheaper, yeah, to spend UTXOs versus creating them, yeah. And also to incentivize people. Is it correct to say that it was also to incentivize people to consolidate UTXOs in a direct way? It definitely makes it cheaper, but only for new UTXOs, right? The old UTXOs still cost the same, right? So it's not really affecting people's will to consolidate old stuff because it's still expensive to spend, right? Okay. But in hindsight, could one say that it actually led to more UTXO bloat because of spam suddenly appearing in February 2023 or not?

16:06 I feel that's a bit of a leading question. I don't think spam suddenly appeared in 2023. A new wave of spam appeared in 2023. We've had spam before multiple times. We had up return spam. We had dusting attacks. We had someone allegedly, some people, some blockchain researchers think that someone had been inflating Bitcoin transaction volume in order to keep the fee rates high in order to drum up support for PCash for a while. So transactions for the sake of transactions or transactions for non-monetary purposes have been around for 11 years, at least, probably more like since the beginning of Bitcoin.

16:51 I would push back on the characterization that that is completely new. There's certainly been a lot more of it in the last two years. And the way that it was introduced certainly made use of the witness discount in order to store more data in the blockchain than would have been possible in outputs. I mean, that's obvious. the UTXO set growth was definitely affected by the BRC20 token stuff because BRC20 used uses an output for each input that creates a token or moves a token it has a regular payment output whose key doubles as the key for the token so they did create a lot of UTXOs and frankly BRC20 is a terrible design.

17:42 If I could switch a wand, I would love for it to never have been introduced to Bitcoin because it is obviously a poor design that encourages UTXO bloat. But all of those UTXOs are spendable. And they are above economic consolidate. They're like at 0.1 sat per VBite, it costs six sats to spend the pay-to-type root input. so they're all 294 plus which means they'd get 288 sats out if they spent them it is spendable utixos owned by people yeah so so brc20 tokens for those who don't know like it's a shitcoin on bitcoin that's what it is right it's it's it's another token built on top of bitcoin that requires a third-party website to even have any use of them.

18:37 I mean, you could run Ord, I guess, or I don't even know if Ord supports BSC. Yeah, but it's not enough to run Bitcoin software. It is an overlay network, yes. Meaning that, in your mind, is there any other way to get rid of this than to just educate people on why these things are useless in the long run? Unfortunately, not. I think they're extremely dumb, And there's very little we can do about people doing that. Oh, so we're getting right at it. Yeah, I'm afraid this is where this conversation was always going to go. So when you see, for instance, a website I love that I use a lot is mempool.space.

19:24 And I've been using it since forever. It's wonderful open source software. and where the devs are funded by grants and sponsors from voluntary payments from companies and people, right? I think it's a for-profit company, but yeah. It's a for-profit, yeah. They recently moved to El Salvador. So this is just a precursor here. I'm not trying to shit on memple.space here. But when you see them first visualizing these spam transactions as shit and then all of a sudden going over to calling it data and naming these things for what they are.

20:05 I'm giving them validation sort of in terms of like calling them a BRC20 token or calling them a JPEG or visualizing a block in such a way that people think that there's a picture there when to Bitcoin itself, there is absolutely no picture there. And then you see that they're sponsored by the Taproot Wizard. like what what what thoughts run through your head now when you when you see stuff like that and and this is just one example of how shitcoiners have always tried to influence bitcoin right and i feel we had we're in this constant fight against them and what are your reactions to that what what do you think when you see that i think to be fair they uh rolled out mempool.space and mempool.space the same day.

20:50 So they did offer these two colored glasses, different sets of colored glasses at the same time. So it strikes me more as a neutral stance. But yeah, I mean, so the data is definitely there. Call it what you want, if you want to call it data or not. But someone has put those bytes into the Bitcoin blockchain. And very clearly, there is a standard or a interpretation of how that data is to be interpreted. And if you subscribe to that interpretation, that data is absolutely there.

21:34 Just like if you don't enforce SegWit, those SegWit transactions will all look like anyone can spend to you. And if you do enforce it, it's SegWit transactions. So I'm not saying that I have, just to be clear, maybe to set my stance here, I have never owned NFTs. I don't find it particularly interesting. I've never traded or otherwise. So a lot of people have been calling us shitcoin enablers or shitcoiners directly. I just want to be very clear here. I've never well I have owned altcoins due to forks and due to getting some at work for working on stuff but I've never been interested in altcoins or NFTs just to be very clear no me neither and I wasn't saying you had been like just for the record I wasn't accusing it's more for your audience than you just yeah I think it needs to be said apparently occasionally Because I think a lot of people take offense when it feels like Bitcoin Core has taken a path where instead of steering Bitcoin in the direction it was supposed to go, it's now steering into the direction that the users want it to go.

22:53 But if the users aren't Bitcoiners anymore, but shitcoiners, do we really want to steer the ship in the direction the users want it to go? Like, I mean, I agree in principle, but I hate your label. So how do you know what the direction was that Bitcoin was supposed to go in? That's your personal preference. And how do you decide whether people are still Bitcoiners or not Bitcoiners when they use Bitcoin and they think Bitcoin is the most important invention, but they happen to like cat pictures on Bitcoin. Suddenly they're shit corners. that I think that while I understand that interpretation and it's closer to my personal stance, I think that needlessly biases our conversation here.

23:42 So just to be clear. Yes, go ahead. I'll try to pull back on that, but it's hard for me because I hear a lot of technical people saying that all metaphors are misleading, but it's hard for a guy like me who only speaks in metaphor. I never do anything else. I don't know how to not speak in metaphor. for. All models are wrong, but some are useful, right? I think I have another framing then. Or I think I have an answer to your question. If it's in the title Bitcoin, a peer-to-peer electronic cash system, cash meaning settlement in that sense, right? There's a consensus around... Or not a payment that is facilitated by someone else.

24:25 like direct exactly it's final settlement and it's peer-to-peer that's what cash means in on the white and i think all people agree on that that that's what that word means especially all bitcoin core devs that i know okay okay good so the metaphor here because that's my only means of communication would be that well if someone paints dick pics all over my dollar bill it's gonna get worse like i'm gonna have a harder time using it because not all merchants may and may accept it any longer if there's if if the dollar bill is full of dick pics would you agree with that metaphor somewhat or is that also just somewhat but you need to wear special glasses in order to see the dick so i think most merchants won't notice if you give them the the dollar bill so no i mean underlying like the the graffiti is only visible to the people that want to see it for the most part. I want to also push back that Bitcoin Core has taken a stance to enable this or facilitate this in any way or manner or form. I think that is a huge misunderstanding that has unnecessarily made this debate a lot more vitriolic. I challenge people that believe this to look through all of Bitcoin Core's pull requests and find me a single one that references NFTs, colored coins overlay networks or anything like that in any manner and i'm certain that they will

25:57 not find anyone that actually has ever talked about this in the bitcoin core repository except in the context of people are doing something and it has this effect and that like with citrea as an example of making a part of their scheme to write data to payment outputs That is the only reference that comes to mind for me. Yeah, but if we take the Citria case, as far as I understand it, it's like the approach Core has taken is like, all right, we'll talk to them and convince them to put the data in op-return instead because it's much less harmful.

26:40 I mean, how about we double-click on the Citria case? Because it's often called the reason for the op-return increase, and it's not. It's an example of how the old up return limit can be detrimental at times. So Citria specifically needed to put data for settling, like for basically what is a penalty transaction in Lightning. For their system, they needed 144 bytes or so to go into a block very quickly and reliably. So their solution was, well, the standardness limit is 80 bytes for up return. So we'll put 80 bytes into up return and split the rest of the data into two payment outputs and put it there.

27:23 And now they have 144 bytes in a transaction that is standard that will be in the next block if they pay enough. And they have all their data available for their penalty transaction mechanism. So what people noticed when they looked at this was like huh they are trying to play by the implicit rules Now regardless of them doing something that we don necessarily think needs to be done they're trying to be good citizens and trying to play by the rules. And that leads them to putting data into payment outputs, which is the worst place for them, for the data. And that highlighted that the 80 byte up return limit had downsides, right?

28:10 yeah so far so far i i agree taken that you think that these are legitimate transactions in the first place i mean they are from a from the viewpoint of they paid the fees but also what what does legitimate transaction mean here yeah that's that's sort of the at the pun intended core of the debate right but no no i mean very literally they're valid they're even standard yeah right so and we can't prevent them unless we very specifically introduce some some mechanism to identify them and like citria is not allowed to spend money or something right which seems very difficult to me yeah and so what makes these transactions illegitimate illegitimate here okay So a South Park episode comes to mind and it's one called the death camp of tolerance where Mr. Garrison tries to get fired for being gay because he has figured out that he may get like a million dollars in compensation if the school fires him for being gay.

29:24 So he starts doing the most perverted gay shit he can come up with. And the worse it gets, the more people just call him courageous. And the whole point of the episode is to point out the difference between tolerance and approval. So I would say for Citria, for instance, I don't relay their transactions with my node. And I don't approve of them. But I tolerate them once they end up in a block. because I understand that I need to in order for, because enough other people did for Bitcoin to be Bitcoin, sort of. So I need to follow suit. But I think there's a difference between tolerance.

30:04 I would like to push back here already. One sec. You absolutely would have accepted the Citria transaction because it looks perfectly standard to you. So you don't tolerate it abstractly, but I fail to see how you can concretely even distinguish this from happening because payment outputs look like payment outputs it's a pseudo random data in the output it is very difficult to distinguish intent from we we know because they describe it in their in their description of their schema that they would add two payment outputs but if you just look at the transaction you would just see an 80 byte up return and then you would see two payment outputs and it would be impossible for you to notice that this is a ctria penalty each transaction. So the argument there is that if it's in an op return, it's easier for me to figure out that this is a transaction I don't want to relay, right?

31:00 That is your interpretation, of course, but I don't think that's a useful interpretation. I'm asking you, is that what you're saying is if this was an op return, would it be easier for my node to figure out? Absolutely, yes. But I don't think that that is a useful stance, but we can talk about that later. Okay, so let's rewind the tape to, was this 2014? Satoshi Dice. Sorry, sorry. No, I would like to double down on. You call this a TRIA transaction illegitimate and your node would not accept it. No, no, no. If I said illegitimate, I should choose another word because from a technical standpoint, it's not illegitimate to the Bitcoin network. I would say it's undesirable. That's a better word.

31:46 Sure. Undesirable. But also, I think the important point is it is impossible to distinguish as such for third parties. And that, I think, is a very important point here in the context. So when people do this sort of thing, we will not necessarily be able to tell that they're doing this thing until they reveal to us how the data is supposed to be read to even notice that it's not random data and actual payment outputs no i mean yeah sorry trying to see where do you understand the point that i'm trying to make absolutely if it's if it's uh and so but but i still think i'm gonna go back to this whole censorship resistance because in in my view it applies to, as I said, to monetary transactions and not necessarily to what you could put on chain.

32:46 I would love that, yes. So would it be entirely futile to fight these things? Because we have in the past, right? If we go back then once again to the Satoshi Dice thing, that was stopped because Bitcoin adapted to stop it, right? No. So how was it stopped it was priced out that's it i think so wasn't it i think it just wasn't just went away the one set per v byte that we had the dust limit the the very small payment the dust the dust limit did help make these small bets go away yes yeah so for instance if we wanted to stop citria could we increase the dust limit would that be this is just me asking no questions here what was I mean, if we made the dust limit a consensus rule, we could make dust transactions invalid and we could prevent them.

33:45 But I don't think that Citria relies on dust transactions. I think this is something else. Maybe there was something about anchor outputs or what is it, the construction that ARK uses. they were trying to have smaller amounts and f2 pool and someone else is now mining transactions that have dust amounts which i find unfortunate very unfortunate actually but unless we make this a consensus rule there is literally nothing i don't think there is anything useful we can do especially nothing cost effective that we can do like if we talk about the amount of time it would take and the rate of success that we would have okay so some people would see this as capitulation but i understand and i i mean i've listened to your conversation with tone and jimmy and also with your converse to your conversation with eric haysen yeah and i think you you made that point a couple times that you would like us to fight tooth and nail give not an to anything but monetary uses.

34:56 In an ideal world, yes. Yes, in an ideal, yeah. And I think the, I don't even disagree with the sentiment or anything. It's just, I disagree with the suggestion that the things that are being proposed would have any sort of positive impact on that goal. And what really, really, really frustrates me is that essentially a number of people either deliberately or unknowingly have been propagating this idea that we're just not doing enough for now years while the for me from a technical perspective the obvious situation is this is inherently extremely costly to fight and the success chance is negligible. So it's just a waste of time to do. And this mischaracterization as, oh, they're not doing anything. You talked about economics in your podcast with Eric Kaysen being the reasons why people do things, like the social economics being a social science in the sense that it explains why people act the way they act. Why do Bitcoin core developers not fight this?

36:14 if you think about it it's an economic reason it takes a lot of time and it's probably futile so they don't fight it because they use their time for other things right yeah yeah and i think this is this is some somewhere here is the is the current there's a kernel of truth there to to why this debate is happening at all and why it's still ongoing because i i think when mempool policy defaults right they do send a signal to the network to to to bitcoin users who want to put whatever transactions into the bitcoin blockchain yeah they they clearly send a signal that this is okay and this is not okay or this is right i wouldn't more classify it as a gentle nudge but Yes.

37:05 Sure. But increasing from 83 bytes to 100 kilobytes, the default op return, sends a signal that it's okay to put data here, and a lot of it, right? And how you get that interpretation, yes. But do you agree with that statement, that it sends a signal? Yes, I guess I do agree with that. But I want to comment in two ways. One is, you asked earlier how we were able to introduce the dust limit back in, I think, 2014 or so. Yep. And the huge difference back then was mining pools were a lot less economically oriented.

37:55 The node population was much smaller and much more homogenous. people just generally ran standard bitcoin core out of the box and we could like the mining pool operators would just hang out in irc and you could just say hey we're we think this is a good reason to to introduce this new limit and it actually got enforced to 100 or close to 100 almost immediately by both the nodes and the miners. And the huge difference to today is while the large mining operations are still fairly centralized, they have a lot of financial backing. They have shareholders that they need to satisfy. They are generally trimmed towards maximizing revenue. They often do not have a lot of technical people that actually care about Bitcoin, what's going on on the technical side, they're not accessible in that sense.

38:56 So some mining pools have very deliberately undermined mempool policies in the past few years. And this has generally made or brought to the surface just how much of a small nudge these mempool policies are and how easily they are supported at a minor level if miners choose to do otherwise. So that is the reason why introducing the dust limit worked back then and why today I have a very different perspective on that. But yeah, once again, that defeatist attitude allegation then, because then if miners don't do what the network tells the miners to do, then we're clearly in trouble, right?

39:44 If miners can override what the nodes want, then Bitcoin doesn't work. I don't think that's the case. You also said to Eric that miners should be ruled by nodes and Eric pushed back that. He sees it more as two different branches of the system. And it is the case. We are paying the miners to provide a service to the network. But the miners are still also actors in the system. They do make some of their own decisions. No, no. Back to semantics. I do believe that miners are also, they are their own employees, their own employers. So they employ themselves, but they're also employed by the entire network.

40:30 We pay them to find block space, right? So what do you propose? We start boycotting a miner that misbehaves? That's one thing that could happen. Like the way I see it. But how would you implement that? Yeah, let me paint a picture. Let me try to still mind this and paint a picture here. So if I'm a user of the network, I pay miners, I willingly pay with consent and voluntarily. I pay miners in the form of block subsidy, like reward and fee or subsidy and fee. So whatever newly minted Bitcoin, they have the right to claim plus fees, right?

41:13 that's i'm really willing to pay them that for finding a correct block in which but the reason i do that is because i want my transaction to be in that block that's a one of the main reasons that i'm willing to pay this fee for them i follow so far yes so if now for instance they instead they choose to fill up the block with other things than my transactions than my transaction that I was willing to pay for them to do then I, as the node runner, and me as the Bitcoin user, may choose to switch to another way of interacting with the protocol.

41:57 So I may switch to nodes, for instance, or I may switch to another way of communicating with the rest of the network. that more looks that I believe more looks after my needs. So no problem so far. So, so is in your opinion, like when you see almost, well, the numbers can be questioned and we've, that's been, been discussed. Yeah. 20% of nodes are so listening. So if 20%, if a fifth of the network, which is the case now, if you trust the numbers are A fifth of the listening nodes, not a fifth of the network. Okay, so it's not a fifth of the...

42:39 I think it is, no. And what would you assume is the number there, like a 20th or a 10th? Well, I think that a lot of the node in the box setups specifically are geared towards becoming listening nodes. They make Tor connections. So people that switch to this sort of run-at-home node tend to be overrepresented in the Bitcoin network by being listening nodes. I think that I have not seen any economic companies, except for Start9, express publicly that they run Nuts or have support to filter endeavors. So there is a very loud group of people on Twitter, obviously, that are upset.

43:26 they have been campaigned at for running more nodes. And sure, a lot of them have switched over to nodes. I understand that it expresses their displeasure and sentiment towards what they would like to see in the network. But my question back to you would be, how does running nodes change anything about the outcome here? If other users of block space pay more, and miners include what pays more, How does it change to run Nuts in regard to getting your transaction into blocks? Well, it doesn't unless it gets enough momentum.

44:09 Maybe running Nuts was, I think, the way they see it. And I'm trying to stay as neutral as I can here because silence developer or podcaster is talking and all of that, right? We're having a conversation. Go ahead. Yeah, so the way I see it, like, Knotts was an attempt at stopping this change from happening. And even at the 42 to 83, 42 to 83, or 40 to 80 byte switch, I mean, Knotts was, Knotts is a couple of years old, right? No, no, no, Knotts has existed since 2014 or so. Yeah, yeah. With basically stuff that Luke didn't agree to.

44:53 yeah it's basically Luke's personal branch of Bitcoin core yes but the thing that this side or whatever you call it has been vehemently against is this op return change that was the most controversial thing and that is the thing that made this whole thing blow up and that made 20% oh you did 20% of listening nodes so upset about it so why I've heard the argument that core developers does not want to fall into traps on social media so they don't want to make decisions based on whatever noise people are making on social media but when you have 20% of listening nodes in other words users I mean these are the users after all these are the bitcoiners, the plebs if they clearly signal that they don't want this change what would it take?

45:51 how big a percent would it have to take for core developers to change their minds and think again and say like hey guys maybe we're missing something here like it would take one user making a good argument is that it and you don't think you've heard a good argument yet correct and i know how how pretentious that sounds right now but but i think it's really mostly a disconnect at a level where people took out the pitchforks first. They're making more space for spam. Sounds terrible. I could get behind that pitchfork mob. But actually, engaging with why the change was made, in my opinion, is quite convincing and does not support that interpretation.

46:44 yet it has been repeated a thousand times and i'm still arguing look and and and i find that when i take the time to talk with individual people they tend to oh i guess i get it i i don't love it but i now see how you're not shitcoin enabling but you actually have a technical reason to do it it's just extremely inefficient to do that person by person right so what i've been doing in the past few weeks is is trying to to explain this in in ways on platforms where maybe a couple more people will listen not i'm not sure how successful i've been so far but yes but there's a big difference between a change causing no damage and a change being important like why is it important to change the return thing why why why was it important what why i I don't think it was super important.

47:39 So why didn't you listen to the people then if it wasn't important? That's what I can't get through. Because they were wrong. And they were making noise, doubling down on being wrong, and tried to force us making a change that is technically not reasonable. No, no, no. They weren't trying to force you to make a change. They were trying to force you to not make a change. No, it was after the change had been proposed that they wanted the change to be reverted, which is reverting a technical decision with social media pressure. And that is very specifically, I think, what a lot of core contributors do not want to support. Okay, so it's because they picked the wrong battleground, sort of.

48:24 They should have been... No, I think that the discussion happened first on the mailing list for a few weeks. People generally found the arguments convincing. then a pull request was opened and someone very quickly noticed this and blew it up with a podcast. And then we got a lot of comments on that pull request within hours, all replicating this interpretation of the first instigator. But if you look at the argument, and I'm happy to dive into the argument again, I don't think that the interpretation is accurate.

49:09 You yourself, I think it was in the podcast with Eric, you said up return will not get used. It doesn't make sense to use it. But then also you said up return will be used for more shit coining. And I think having both of those interpretations at the same time is contradictory. Okay, so let me try to rephrase that then. because first of all, the pod with Eric was quite long ago now. Yeah, it just happened to... I was looking at a little bit of your stuff inside. Even when it was out, it was pretty old because we did it back in between July or August or something. Please feel free to take any new stance because there's no evidence.

49:52 I feel I expressed that better in the tone pod. You said you listened to that too, right? Yeah, the audio was a little... The connection was... Unfortunately. So the argument is that if you signal that it's okay to put data, then people would... I'm just thinking that just because they put data somewhere else before and you add another place to put data doesn't mean they'll stop with what they were doing before. I agree. They may just put more shit in there. Or instead put it there. Yes. Yeah, but it's the instead part that I'm not convinced about. Well, I'm not convinced that inscribers will put data into upreturns.

50:37 That doesn't make any economic sense. The tooling for inscriptions has been built out very well in the last two years, unfortunately. Upreturn has a lot worse tooling, and it's four times as expensive. It makes no sense for people to switch over. Fully agree on that. Yes. so what it specifically does is it is cheaper than putting data in other outputs yeah but right that's the whole argument yes but okay so explain to me in layman's terms if if it does nothing for inscriptions so you get a block with that would have been so here's a case like you get a block that would have been two megabytes if uh if it weren't for these two megabytes full of inscriptions but now but now you have the op return stuff too which is another type of spam that people put in op return and that's the other two megabytes of this four megabyte block so the so the witness discount only applies to witness data the way the witness discount works is that the byte of witness data counts one weight unit whereas transaction data in any other place weighs four weight units.

51:52 The maximum for blocks is four million weight units. So non-witness data can never exceed one megabyte. So yeah, I'm phrasing this wrong. It's not an additional place that you can put data. It is a place that is in the output section. Output data weighs four weight units per byte. And in order to fill, if a block were filled with return outputs, it would be no bigger than one megabyte. Okay, I think I'm phrasing this wrong. So let me paint another picture. Sure. You have an empty block, and you had one transaction, an inscription, and now you have two transactions, which is one inscription plus one other transaction with a ginormous op return.

52:43 That block would have been smaller had not that op return thing been there, right? So, yes, I agree. If you put more data in an empty block, that would obviously be more blockchain data that wasn't there before. Yes, because I feel the argument is about already full blocks. And I don't understand why we want blocks to be full. Like, wouldn't we want them to be as empty as possible from a starting up a new node perspective? I know you had your rebuttal to this on Twitter when I pointed that out. No, I mean, I think that was someone else, but I did see the conversation. So yes, all things equal, less blockchain growth would be preferable, it would potentially make IBD slightly faster, and it would reduce the future cost for people doing IBD in the future. Fully agree on all that.

53:34 I think the points that I would supplement here are a bandwidth and disk space have both been getting cheaper exponentially, while the block space is limited linearly. So over time, it is becoming exponentially cheaper to run a node. so i don't think that between the 92 percent of all block space being used right now i ran the numbers a couple weeks ago for a week and about 92 percent of block space was demanded i think it might be more now because we've been seeing fees in the two to three set per v byte range between 92 percent full blocks and 100 percent full blocks i think that the the difference is very small and with the cost of running nodes going down exponentially, I do not think that the future cost is immense and necessarily a problem.

54:31 But you can't run a node on a Raspberry Pi anymore, I hear. That is incorrect. That is absolutely incorrect and overstated. Okay. Yes. Yeah, it's not something I've verified. Specifically, Chris Guida has been making that argument a lot and it is my impression that he was taking the point at which the assume valid block was for an older version of Bitcoin Core, at which it starts doing full script validation. And before that point, it'll just go through the transactions, rebuild the UTXO set, and just check that, for example, the TXID matches that the block was properly formed, but doesn't check that the signature was valid because it assumes, oh, there's this buried months below the chain tip.

55:15 So clearly that must have been valid because otherwise we wouldn't be on that chain tip right now. So it assumes that months of work on top of transactions indicate that signatures probably are valid if all the data is there and matches the block. And at a point about a month or two months before the release of a new version of Bitcoin Core, we pick a block that is the assume valid block, up to which by default nodes will IBD without doing script validation. And then for the last two months or so, we do full script validation. And that becomes a lot more expensive because now you do elliptic curve math and you have to build the SIG hashes and so on for the transactions and you have to check the signatures.

56:05 So there's additional computational cost. And I think that it coincided with the start of the spam wave that we had set an assume value point. And my suspicion is, I haven't talked much with Chris Guida any time lately, that he interpreted the assumed valid point as the effect of the spam. Okay, when it was really the effect of nodes actually validating even more thoroughly than they were before. yeah and and maybe for the node runners that are listening if you're trying to run an old version of bitcoin core you can pass an assume valid argument to the configuration which will allow you to do assume valid to a higher point in the chain and it will significantly speed up the valid the ibd of your node so this is a configuration option that you can use to to get the effect all right yeah however this is this was not the argument i was making on the there's so much to dig into the the argument i'm trying to make is from like whenever i think about effects of decisions in bitcoin i try to extrapolate the thought factor as far into the future as possible i want this to be generational wealth as it has been promoted me too as by many people so and in order for that to in order for that to be true like

57:35 even though the cost of running a node is getting cheaper exponential at the moment we don't know if that will be true how long that will be true there is a physical limit to how big a computer chip can get and we don't know if quantum computing is just headline stuff or actually a real thing that will ever take off, right? So for the sake of argument, it is desirable to have the blocks as small as possible from the perspective of a person who forever buys new nodes and downloads the entire thing. All things equal, I absolutely agree.

58:16 So how important is that specific metric to core in general? What is your perspective on that? Is it that, okay, we agreed on 4 megabytes and that's what we have to assume? Yeah. I mean, we have to always assume the worst case in our designs. 4 megabytes was perceived to be safe in 2017. It's now 2025. I think that other than the reports that some Raspberry Pis were having a hard time, and for example, Lawrence has been doing a ton of work specifically to improve the IBD on Raspberry Pis, which ship in 30.0 partially and some probably in 31. So if you're struggling with your Raspberry Pi, ironically, running 30 might actually be a huge improvement for you. The perspective is simply this. We have these shared rules that we all agreed on, and those are the consensus rules. And the consensus rules are now that blocks can be up to four megabytes so we have to plan for up to four megabytes and we've actually been significantly smaller than that for for the largest part after segwit the blocks went up to roughly 1.35 megabytes and then when inscriptions became popular it very briefly peaked over two megabytes but it's been trending down since then it almost immediately

59:46 dropped to 1.8 and now it's been trending down it's more around 1.5 megabyte of block size in average and the funny thing is when we were discussing segwit and adopting segwit one of the popular figures that were estimated how big blocks might become if all transactions in blocks became segwit transactions was 1.7 to 2.1 megabyte so we're significantly lower even than than the estimates people were making when we rolled out segwin i i just think having blocks that are an average 1.5 megabytes is well within the plan parameters and it's not problematic yeah good to hear that perspective it's it's thank you i haven't haven't heard that specific argument before so what okay another thing what would you call what do you call any of these inscriptions or stamps or whatever would you call them exploits like what do you agree that they are exploits i i yeah maybe you saw me talk to luke about that and luke the wolf i think the characterization strikes me as motivated i i think it's definitely unintended and undesirable use of Bitcoin from the perspective of people that are trying to make Bitcoin the best possible money. And I don't support it. I wouldn't review or spend time on features that specifically

1:01:20 benefit these cases at all. On the other hand, I think just as we established earlier, with the flexible scripting system that we afford ourselves to have the possibility of future innovation to build things like satoshi did not anticipate the lightning network and yet today the lightning network facilitates a large number of bitcoin transactions right to have this sort of possible path in the future we afford ourselves the flexible scripting system and a flexible scripting system will inherently allow you to embed data so my my point would be if you agree that the flexible scripting system is desirable, that we might want to be able to add another layer to like the Lightning Network in the future, then you also have to accept that there will be ways to embed data into Bitcoin.

1:02:21 Yeah. And one of the big things that Lightning does is just the very fact that the blocks are smaller now is a testament to that people are using lightning and and layer two solutions so they actually they it actually helps make the yeah unfortunately it makes it very cheap to use bitcoin for other things which led to the spam mania and maybe as bitcoin gets more adopted and fees go up it will just be priced out again just like the other spam waves before it but yeah right now there is a little bit of block space up for grabs. Actually, I had been looking at numbers.

1:03:03 I collect some statistics on the amount of inscriptions and so on in the blockchain. And I have found that, especially in the last few months, the fees paid by data embedding transactions have been significantly smaller than the fees paid by payments. So it looks like the data embedding transactions have mostly relegated themselves to being like the block space user of last resort and like just buying the leftover block space and to me this hopefully signals that they're close to being priced out in case that we get any sort of increase in demand for payment transactions well couldn't that be off-band payments though to miners that they come with a briefcase and dark sunglasses and pay the miner directly in dollar bills I'm not super convinced that that is an attractive model and it is also something that we very specifically are trying to suppress with how we think about mempool policy and incentive design for Bitcoin Core.

1:04:10 So when you make an agreement with a specific miner to get block space and pay for it out of band, you're only bidding on the block space of that specific miner, right? and that that inherently makes your transactions lower to confirm you might you might get a benefit by buying the block space in advance and getting a slightly cheaper price but it seems to me that the trade-offs of only bidding on one miners block space are pretty unattractive when you have the option to just send a transaction on the network and bid on every miners block space competitively.

1:04:52 Maybe you have more thoughts on that. You think about the sort of economics of things, right? No, well, there is the extreme case where mining is actually not decentralized at all, but the same entity owns like 80% of the mining pools or something, and in that case you only have to pay one guy, it's just that you have to find the guy on top of this Illuminati curve. When that's the case, I think probably we would consider the Bitcoin experiment to have failed. Yeah. Because then it's completely censorable. It is essentially up to this one entity to decide what can go into blocks or not.

1:05:36 It's barely better than a stablecoin. I might push back on that, actually, because I think since this ginormous entity, it very much has the incentive to at least make Bitcoin look like it's still working as intended. Because if this was ever to be pointed out that this entity owns all the... If anyone was ever to figure that out, then they would shoot themselves in the foot like mad, right? They have very high investments into hardware. Presumably they have their company resources tied up into this.

1:06:17 But they could also just make a huge short on Bitcoin and then announce it and make billions of it. Right. So I don't think it's necessarily true that you can assume that a majority miner would have aligned incentives with the rest of the network. I don't think that that generally would be the case. No, I would agree that you cannot assume that, but I would also say that you cannot. In my view, it's basically hoping that the dictator you choose is benevolent. And there might be some incentives to be a benevolent dictator and not just a ruthless dictator. But I think it very much breaks down what's attractive about Bitcoin.

1:07:02 I think it's a bit better than that. How so? I mean, you're disincentivized to destroy the thing you invested so much in. You still have the majority of the hash power. There's no reason. I mean, yeah, it's killing the golden goose, sure. Yes, for a kinder egg. Sometimes if someone bids enough for the golden goose, you might. You might choose and do something else. Yeah, if you're one guy and you just want to retire and buy an island somewhere or something. Yeah, sure. So I would say that it's maybe not be the death of Bitcoin, but it sure is less robust than the intended security model.

1:07:42 I mean, the bus factor becomes one. It's up to one entity, if not one person, one entity, whether Bitcoin lives or dies. And what you can destroy, you control, as Dune had to call Dune, right? But I think the core tenet of why Bitcoin is interesting is because not a single entity owns it. Not a single entity can decide what will happen in the network. And without that, I think Bitcoin would be way, way, way less attractive. So in a way, even if they are benevolent dictators, I would assume that the value or the ability of the system to retain its value would be undermined, at least once that becomes publicly known or easy to guess.

1:08:32 okay so a bit more of a meta debate thing here then with so during the block size wars the miners figured out that they weren't in charge of bitcoin sort of like this is a uh would you agree with that so they i would say they definitely learned that they weren't as solely in charge of bitcoin exactly and neither were and i think that was a very valuable uh thing for them to realize Yes, and right now, when there's this distrust in Bitcoin Core, then developers are somewhat, maybe not learning the same lesson, but a similar lesson, regardless of the outcome of this fight, that we can do stuff, but we can only do stuff to a certain extent.

1:09:20 So how much power does the developers actually have And how do you see that dynamic Are you afraid that people will... I mean, we're basically... We have a form of soft power. People choose to run our software. There's no auto-update. It is very possible to fork our software, to release alternative clients, to build up a competing implementation in the first place. So in the sense that Bitcoin Core relies on the trust or the users choosing to run their software, it is a soft power.

1:10:06 We can only do things that are supported by the network or that we can explain to the network, right? And in that sense, the node operators and the economic actors in the Bitcoin network choose whether or not we have any power at all. Right. The power that we do have is I think that many of us, like myself, have been around for over a dozen years and have been doing a lot of thinking about how the system works. great work in the past on developing and improving the system. So when we go out and try to explain how we arrive at conclusions and why we did things, we have the power of people actually hopefully listening to us and trying to see it from our perspective.

1:10:58 And I think that is the whole extent of our power. Is that a decent answer, maybe? Yeah, absolutely. I mean, yeah, we'll see what happens here and how this whole thing plays out. I mean, it seems like Core 30 is the most popular implementation now, right? Am I right about that? I'm not sure if it's the most popular implementation. I did look at the adoption of 28 and 29, and 30 was adopted more quickly. I don't think that it necessarily was a much better release than other releases, but the amount of attention certainly led to people being more aware of it being available.

1:11:41 But I definitely see that the prediction that Bitcoin Core version 30 would be adopted very slowly did not pan out. A question I don't really want to talk about these things because I just don't want to be part of that. a question I feel forced to ask because I think my listeners would like me to ask it is what happens if all of a sudden a transaction with a giant op return with CSAM in it ends up on the Bitcoin time chain what are your predictions for what happens after that possible future unfolds in all likelihood most people would not even notice until it's buried several blocks deep. And I think that it would have almost no impact. I don't see how contiguous data in up return is special from any other forms of contiguous data. And there's dozens of ways how you can embed contiguous data in transactions.

1:12:53 we have already had objectionable material in the Bitcoin blockchain for over 10 years. There is porn, there is other... I think I read a paper by... I read the abstract and conclusion of a paper by some researchers that analyzed the content of the Bitcoin blockchain and they found that there were prior instances of this. I just think that per the decentralized nature of Bitcoin mining, how it is a append only log that allows any single miner to append a transaction.

1:13:33 As long as we retain that characteristic of it being decentralized, I see absolutely no legal ramification for this. But I'm not a lawyer at all. I just saw some people talk about this. I just think it's a boogeyman. I'm not specifically addressing the legal issues, perhaps. I personally think that they are kind of vague and that a judge would do whatever a judge does anyway. But the thing is, with OpReturn specifically, the intent of OpReturn is other data. So it's like the intent of the rest of the transaction is transactional data.

1:14:15 like so so i yeah i really don't don't like that distinction i think you're talking about payments and not transactional data okay bitcoin transactions are bitcoin transactions they need to be consensus valid and all of them have data most of it is my point my point is that op return is is is specifically designed to store data that has nothing to do with payments yeah It's a way of giving people a harm reduction way of putting data on the blockchain. It's still super expensive. It is especially more expensive than witness stuffing.

1:14:55 It's, I think, only attractive to people that would put data otherwise in outputs. My expectation would be that it gets used very little. And it had been used before. We've had one megabyte of returns, which are consensus valid. before. Just the standardness of it is different. And the standardness can be motivated or is motivated by the impact of what gets propagated on a network to make it less financially attractive to defect from this specific mempool policy by removing it and to curb people from putting data into payment outputs.

1:15:37 And we've seen people put data in payment outputs, and that's sort of the worst outcome. An attractive and very bad way of putting data into outputs is there's this one project that apparently puts data in native SegWit version 12 outputs. So they just write it into our upgrade hooks. And if we block upper turn, they'll just write it there. It costs the same, and it lives in the UTXO set instead of not living in the UTXO set with up return. Yeah, so you don't think there's a difference here in intent, like from a legal perspective, or even from an innocent node-runner perspective?

1:16:23 That if, for example, just to use CSAM as the example, because that's the word being used. I think we're very clear on Bitcoin being for monetary transactions. And that is the only work that we're working on is to facilitate Bitcoin being good money. But I think the biggest difference is that we realize that it will always be possible for people to stuff data into transactions. And there's basically three possible ways of dealing with this. One is fight it very hard, but we perceive this as a losing proposition.

1:17:08 The second one is to provide a way to do it that is less harmful, which I think is what Bitcoin Core's approach has been in the past and continues to be, or to just ignore it. And I think ignoring it is not really satisfactory because it's going to happen either way. so at the very least we would like it to happen in a less harmful manner and I mean I've been lucky enough not to have to deal with courts a lot but I assume that the explanation of it being a form of harm reduction and not an intended use case should hold up but again I'm not a lawyer okay that's a very satisfactory answer I understand that perspective as a counter argument.

1:18:02 I mean, people have been predicting that up return would get used a lot more. And I looked at the statistics earlier today. And obviously, Bitcoin Core 30 has only been out for a few weeks. Actually, almost two months now. But the up return use is down from before up return, at least in count. and I think this aligns with my expectations because it's economically not savvy to use and for the people that are building these cryptographic systems may they be BAPs or whatever that we are not super interested in but are going to happen either way, they now have a way to use the data in a way that it's not going to pollute our UTX OSET and I think that is looking at the equation of what the up-return limit did before, where it was one of the most undermined mempool policies already.

1:19:00 There had been miners that accepted bigger up-return outputs for a very long time. The blocks generally being full, so it wasn't really preventing more data getting into the blockchain because data had been going into witnesses, which actually grows the blockchain faster than putting data in outputs. So the main two reasons why up return was limited 11 years ago do not apply anymore in that sense. And it was already undermined in the sense that you could reliably get very large up returns mined. They propagated on the network and would get included into blocks, just probably not the next block.

1:19:41 So this creates a situation in which the miners that break the policy get rewarded and the miners that follow the policy do not get any reward and do not have any success. So from a system perspective, all of the advantages that enforcing the up-return limit had started to become less important and the disadvantages of enforcing the up-return limit hurt good actors that were trying to stick to the limit. they made less money or they they had to put data into payment outputs in order to put the data so from that perspective it just didn't make sense to enforce the limit anymore okay a bit of arguing in circles here but like the the devil's advocate to that would be that yes so so instead of instead of fighting this completely you give in to the demands of the shit corners in order to make them less destructive like so it's it's this i think this is what most people have a problem with is this listening to shit corners at all like that's like we're not listening to them we're observing them and yeah but that is listening to the reduction if no i I don't think I've ever actually gotten any input from any shitcoiner regarding this issue.

1:21:11 No, no, no. But if you observe what's going on in the chain, and that is shitcoining, and then you adapt to that, then that is listening to shitcoiners from a certain perspective. I mean, I appreciate how you get to that conclusion, and I understand that that is actually a position that a lot of people that are yelling in my face have had. Most people I know on the Knot side, that's what they were upset about in the first place. Yeah, I understand. So my pushback to this would be, what concretely are your proposed ways of fighting this?

1:21:54 Let's actually look at what we can do and how effective that would be. So we've had a huge debate on the efficacy of mempool policies, right? So I already previously said that I think it's more of a nudge rather than a, I mean, sure, it has the signaling effect of what we think should be done or not. But if people choose to sidestep it, the consensus rules apply. The miners are bound by the consensus rules. The nodes enforce policy. I think you said in, yeah, I know it's an old podcast, but there was this point about 90% of nodes enforcing a mempool policy.

1:22:37 And I think that point is misunderstood. So at 90% of listening nodes enforcing a mempool policy, it starts to have any effect at all. Below 90%, it doesn't have any effect. Yeah, I understand that. It sounded more like, or not necessarily you, but other people thought that at 90% it's enforced. But really at 90%, it just starts to show any effect at all. And at 10 nodes running a more lenient mempool policy that mempool policy for all intents and purposes is reliably enforced Or like you can send transactions that conform with that more lenient policy reliably on the network So when you assume that mempool policies enforced by a few listening nodes on a network are going to make it more expensive or delay transactions or anything like that, I have to push back from a technical perspective. I don't think it works.

1:23:44 doesn't do anything yeah okay that's uh this is the filters if filters work debate right well yeah just to recap that so i i would offer another perspective there they work from the perspective of my node refusing to relay shit like and all i can do is hope that enough nodes do that to reach that 90 level but we're never going to reach it if people just have the defeatist attitude of or we're never going to reach 90% or it has no purpose. Well, again, you need to reach more like 99% to actually prevent or delay things. 90% is the starting point where it starts to do anything besides signaling.

1:24:30 Yeah, but I don't really care because I don't want to use my node for relaying shit that I don't want to relay. I appreciate that, yeah, sure. So I'm looking at this from a very individualistic perspective, and then I can only hope that other people do the same, but I can't control that. What I can control is my node, and the control of my node is what I like about Bitcoin. That's the thing I'm in control of. I'm not saying people can run these mempool policies or configure their own mempool policies. And surely the way a mempool policy is implemented, obviously, is it is 100% effective for your own mempool.

1:25:14 Yes. But the effect past your own node, I think, is misunderstood by a ton of people participating in this debate. And that's why I recapped, I think, what the important points in that debate are. Yeah. Yeah. I'm repeating myself. I'd say it's misunderstood by some, but I think there's a lot of people that absolutely understand that too. And isn't the same true for the policy of 100 kilobytes of returns, that that needs to reach at least 10% to be all over the place? Like the opposite. Yes. Again, 10% is basically when it is reliably deployed.

1:25:57 Exactly. That's what I mean. That's what I mean. What we saw with the low fee rate transactions, the subset summer, as someone titled it, was... Yeah, it's very catchy. Neither LibreRelayNOTS nor Bitcoin Core were, by default, propagating transactions below one set per VBIT. There just happened to be a few people that had already been running with lower minimum fee rates. And then a few people started getting together and making connections between their nodes and deliberately creating a peering network, basically a backbone in the Bitcoin network to propagate subset transactions.

1:26:44 And then someone convinced a couple miners to start including them. and from what I can tell I think none of the prominently run node implementations supported this at all and it must have been a few hundred nodes or so that did and that was sufficient for two weeks later 40% of transactions to be sub 1 set so what I'm trying to point out is the mempool policies work reliably as long as 100% of the miners enforce them.

1:27:24 And they work somewhat reliably to prevent transactions from propagating on a node network if somewhere around almost 100% of nodes enforce these rules. But that does not prevent transactions to get to miners either directly or through deliberate node peering. All right. Sorry, it's sobering, I know. No, no, no, I follow. And this is no surprise to me. Like this is the way I've seen it all along. It's just, I think this, well, maybe not all along because I learned a lot during this war.

1:28:06 I think this is the biggest, the thing that people should be happy that this is happening just because of how much more informed a lot of people are now and how much more people are running nodes and doing things. And what costs, though? I mean, talking about the cost of this is, I know a number of Bitcoin developers that have been feeling extremely discouraged regarding their chosen career. And I personally have spent several hundred hours on trying to help educate. And I could have done other things with those several hundred hours, to be honest.

1:28:48 Probably it could have been more efficient in my time use there too. But the cost here is, the cost and the disconnect, I think, is we look at this spam, this bullshit, these monkey pictures, and we're like, well, that's crap. And we don't want this. I certainly don't think BRC20 tokens are a good use of anyone's time. But the question is, how much time do we want to spend on fighting this? And how much success are we expecting to have with that? And is that a good use of our time? And what I essentially feel like is certain pundits have been promising that users have a lot more agency in preventing this than they have, which has skewed expectations of node runners to an extent where when they are set straight on what is actually possible to achieve, they react aggressively.

1:29:54 and we've had a huge debate on our hand that basically could have been an email. So you're unhappy that this whole thing unfolded? No, I love the educational effect of it. I'm unhappy about my time being hijacked in this manner because I feel it's important to talk to the node operators. So how many of the core developers do you think have Bitcoin stacks of their own and that are actually significant for their survival in the long run. I saw you make that point before and I think you should remember that the rules of Bitcoin Club are always talk about Bitcoin, never talk about your Bitcoin.

1:30:40 Yeah, no, no, no. I'm not trying to do... Okay, without doxing anyone. Do you think there's an incentive to disalign? That's not the point I was trying to get to. The point that I was trying to get to is, I think it's a disingenuous argument. Do you think people would be working on Bitcoin if they didn't think Bitcoin was important or interesting or valuable? And Bitcoin core contributors generally have their career tied up, many of us for over a decade. If Bitcoin were to not succeed, it would probably not look very great on our resumes. Sure, we're getting paid right now, but I would absolutely assume that all Bitcoin core contributors hold Bitcoin. It's just that they don't talk much about it because they're already publicly known to be Bitcoiners. Talking about your stack when you're a public figure is a bad idea for obvious reasons.

1:31:37 So turning this around to claiming that Bitcoin core contributors don't have skin in the game here, I think is not a fair argument at all. Okay, just to be clear, it's not an argument I'm making. I'm just posing the question now. Okay, sorry. Usually this is provided in the context of they don't have skin in the game and they shouldn't be making decisions or contributing to Bitcoin in the first place. My question is sort of, do you think there's any truth to this, that the incentives might be misaligned because they're getting more money from somewhere else, which might be a malicious... I think that is completely baseless and character assassination.

1:32:20 Okay, good. Thank you for the answer. I guess I could have come to that immediately, but I think with the explanation, it might be more convincing. I just want to have to have asked. I don't think anyone at Citria had even talked to anyone that contributes to Bitcoin Core. And the discovery was the other way around. Someone saw Citria doing something and looked at it and was like, well, incentives seem to be misaligned here. Because we really don't want people to design stuff that they put data into payment outputs. Yeah, I'm not aware of any altcoin, shitcoin, coloredcoin, ordinal crap funding, any Bitcoin core contributors. Happy to be corrected on that.

1:33:09 Okay. Yes. I don't see any financial incentive there to. And again, I mean, so maybe to be clear, there are some very technical people among the Ordinal users, some of which seem to significantly better understand how Bitcoin works than some of the filter proponent pundits. and when Bitcoin core contributors confirm that their understanding of Bitcoin that might end up in a reply is correct that doesn't mean that they're supporting the shit corners they're just explaining how Bitcoin works and I think that might have led to some people thinking that we're all aligned in some way but it's just there are things that Bitcoin does and how it works that sometimes are not completely obvious.

1:34:04 We had a whole multi-month debate on how useful mempool policies are and what sort of adoption they require. So this may have been obvious to many or some Bitcoin core contributors, but it certainly wasn't well known before. So yeah, I mean, sorry i think i got off on a tangent here i i didn't mean to accuse anyone of anything that was not the point of the question really i uh i'm sorry i'm i guess there's been a lot of that in the last few months so i guess i have a few buttons that can be pushed i i'm very careful with that because if anything i'm i am super grateful for every single contributor to bitcoin I mean, whether it be a developer or a miner or a pleb or a podcast or whatever it is, if they're passionate about it and they understand the difference between Bitcoin and shitcoins, then I am absolutely grateful to them putting their time and effort into this because I still think it's the best bet humanity has to achieve world peace, basically, because we disincentivize aggression.

1:35:21 And I love it. I wouldn't be here if I didn't. So there's that, to be clear. Yeah, I think part of why this is so frustrating is I think we're this close in almost everything. It's just that I think deliberately or undeliberately, a few people have found some triggered topics that can be used to shove a veg into the Bitcoin community in a way that hasn't been done in a long while. and people that got along or trusted each other suddenly insult each other on Twitter. We like the amount of how the even just the ability to entertain other people's thought processes has broken down.

1:36:12 I think that's the actual damage of what's been going on. And that that is the frustrating part for me. Like having spent over a dozen years on trying to educate people about how Bitcoin works and so on. People, me trying to explain how Bitcoin works and people calling me a shit corner and so forth, that just didn't happen as much until the recent years, right? So that is the actual damage, this erosion of even talking to each other. Yeah, and I completely agree. from my perspective the same thing is happening when i try to explain what money is and how money ought to work and people call it plebslop because they're more technically but it's it's exactly the same thing that's the other side of that coin absolutely and it is frustrating from all perspectives but that why these conversations are valuable yeah hopefully any we been going for quite a while these shows are usually much shorter than this but I found this insanely fascinating Is there anything else you like to add before we wrap this thing up?

1:37:20 Yeah, let me briefly, as I said, I spent a little time going through your prior two conversations that I had found. Yes. Let me just briefly look over my notes if I had something that I was missing. Yes, I'm going to have to remember what I said and then defend it. That could be interesting. Sorry for putting you on the spot here. I mean, I think we managed to have a good conversation. Yes, yes. Oh, do you want to talk about RDTS at all? RDTS? Dathan Ohm's software proposal. Oh, yeah, yeah, yeah.

1:38:01 There was one thing that I found interesting. You said you think it's a good idea to threaten the soft fork, but you don't think it should be implemented. And I thought that was interesting, and I was going to ask you about that. Yes. Okay. So that's one of the things I said on TonesPod. Slightly misinterpreted. I said, I like the threat of a soft fork more than a soft fork. And what I meant by that is I wish the spammers would be scared of something and stop scamming. that that's that's what i meant by that like if there's anything we can do to scare them then i'm for that and not yeah i'm not necessarily for changing bitcoin in ways that are potentially harmful but i am for scaring sending a signal to spammers that this is not okay like i'm totally for that yeah yeah i agree i wish we could convincingly signal that the problem that I see with the proposed soft fork is just sending that signal is a very low reward for a soft fork of that level of controversy. It might have the opposite effect.

1:39:18 And basically it feels to me like a bluff with a high card and the spammers can see our hand because there's a mirror behind us. And so like within minutes, someone posted a large data transaction that circumvented these new rules. I think it would be trivial for spammers to come up with new ways of inserting data, just how they found the up if, up false, up if envelope idea. And basically having a soft fork for the purpose of signaling that it's not welcome is setting us up on a path where we're going to end up significantly hampering the scripting system and preventing future innovation or not achieving our goals.

1:40:08 And spending a lot of effort on something that is bound to fail and make us look like clowns just seems like spending social capital that we don't have to spend on nothing useful. Okay, I have to, like, disclaimer here, I'm not read up on the fork enough to actually have an opinion on whether I'm pro or against it. I like to claim Swedish neutrality here. Swiss neutrality. Or Swiss neutrality. Swedish neutrality was sort of fake, but Swiss neutrality.

1:40:50 I see, I see. I didn't know that about Swedish neutrality. Thanks for the heads up. Yeah, we were supposedly neutral, but in reality we were pro-Nazi during the war and pro-NATO ever after. So yeah, there's that. Anyway, no, so, so yeah, I, the reason I didn't go there is I don't know enough about it. I don't feel like, yeah, I know you're against it. So I don't think there's much. I just don't think it's a very strong proposal. Okay. Could any proposal be strong enough, do you think, to resolve this?

1:41:31 So with Luca on Twitter, I recently talked a little bit, and Luke the wolf again. So he was talking about limiting the up return size in outputs, and we agreed that limiting the count wouldn't necessarily be useful, but limiting the amount per output would break that contiguous data argument. And the problem that I specifically see with that approach is we already have at least one project of spammers, as you call them, use native SegWit outputs for contiguous data. Specifically, native SegWit outputs are defined up to version 17 already per the SegWit soft fork, but all of the future versions are left unencumbered so we can impose rules later, right?

1:42:22 Soft fork introduces new rules that restricts what you can do with something in order to give it meaning. But up to that point, people can basically just write anything into future native SegWit versions. And what that means is it costs exactly the same as up return, but future native SegWit outputs live in the UTX OSET. Anyone can spend, so miners could just take the money or whatever. But it seems to me very obviously worse than people writing data in up return. So the question is, we see some people use crayons to draw dicks on upgrade hooks.

1:43:05 do we throw away our upgrade hooks or do we give them up return to at least do it here please and for me the the unsatisfactory but practical solution is let's give them up return to to draw dead dick pics rather than have them pollute our upgrade hooks because they're gonna do it either way. And yes, I know, defeatists and all, but it's basically a pragmatic stance on what we can achieve and what we want to spend time on. And for all I care, they can go somewhere else and not do this on Bitcoin. But Bitcoin has become so valuable that it is attractive for them to to have their nfts and pictures on bitcoin and while i i appreciate that having a single purpose makes it more valuable for that single purpose like you want bitcoin to only be used for monetary transactions and we want the bitcoin block hashes to only serve the purpose of proof of work and not also find large large mathematical what is it the primes or whatever was proposed in the past we want it to be single purpose so it's only used for that but but we do not have an efficient tool to to enforce that outcome so that that's my defeatist uh closing word i guess prime coin

1:44:41 was an interesting shit coin back in the first like in the 2014 shit coin right that's what i was referring to yeah yeah and and they uh quickly figured out that putting another incentive for the miner just makes it worse than Bitcoin at doing money. Yeah. I always thought that that was an interesting but not necessarily obvious. At first glance, I see how people say, oh, this is only wasted. If we could do something else with it, it would be better. But at second glance, when you think about it, no, absolutely not. I wish we could enforce that for Bitcoin to be used as monetary funds.

1:45:23 But if we wanted Bitcoin to be only used for monetary purposes, it would have to be designed very differently. More like, for example, Mimblewimble, which encodes outputs as elliptic curve points and doesn't allow any scripting whatsoever. so the only way that you could embed data there would be by grinding keys or or i don't know if there's meta data but basically we would have to have a much more restrictive way how bitcoin is designed and can in the future evolve and that is that there might be a place for that system but it's not bitcoin no and bitcoin is the only chance we have like we won't get an immaculate conception like this playing out again i believe i i i truly think this is yeah so so it is what it is however it's very interesting to reminiscence about prime coin because uh this is one of my light bulb moments in this journey too that no holy shit it's not wasted at all it's sacrificed like and and for a very good purpose like yeah and alternatively what was it pure coin where essentially yeah it became uh controlled by sunny king or whoever the founder yeah and he he because it was the first proof of stake and it was inherently unstable so essentially he rubber

1:46:54 stamped the best chain the best chain was whatever sunny king's node first saw and it it was just this perfect illustration of some of the issues with proof of stake. Yeah. No, it's fantastic. And the whole DAO debacle in Ethereum and how they just rewrote the whole thing. That's also like, yeah, no. It's centralized. It's absolutely 100% centralized. And maybe the surprising thing is how long Peercoin existed afterwards and how that traded value, right? Ethereum still exists for some fucking reason.

1:47:35 Anyway, Merge, thank you so much for doing this and keep on educating people and keep on working on Bitcoin. I love having these conversations and I'm going to keep on educating people about why shitcoins are shit first and foremost and why sound money is important. And yeah, all the best in the future. Please keep at it. Thank you. Thank you. Where can people reach you on the internet? What's the easiest way if they want to talk to you? If you have questions about how Bitcoin works, Bitcoin Stack Exchange is a great place to find pretty well-reasoned answers. I am Merchandamus on Twitter. You've probably seen me or know how to find that.

1:48:21 I recently founded Localhost Research. We are a new Bitcoin contributor office on the West Coast in the US. We're donation based. So if you have change that you want to get rid of and want to support Bitcoin development, we have currently four full time contributors and a couple of people helping run the organization where I registered nonprofit here in the US. So if you find that interesting, you can find our transparency reports on our website, lclhost.org. And we write a lot about all the things we've been up to. So, yeah, I think that about covers it.

1:49:03 Oh, and if you are interested in news, what's going on in development, we, Mike Schmidt and I, host the Optic Recap every Friday, no, Tuesday. Newsletter on Friday, Recap on Tuesday. We talk about an hour or one and a half about all the things that go on in development. And yeah, that's sort of where I'm at. That's a reminder to myself. I should pay more attention to that. Thank you. All right. Anyway, all the best. And thank you for the conversation. See you next time. Yeah. Thanks for having me. Thanks for the pleasant conversation. I think it's pretty late for you. I hope you have a good night.

1:49:44 It's eight o'clock, so it's not that bad. Oh, wait. You're originally from Sweden, right? But you're not in Sweden anymore. In Spain. Spain. Yeah. Okay. That's a little better. Yeah, it's a little better. Well, the same time zone, so it doesn't matter. Oh really? Yeah. Most of Europe is. Europe is smaller than one thing. Only Portugal, right? Yes, exactly. So, yes, like, subscribe, brush your teeth and comment and get at us with all your... Yes, call me whatever you want. And don't call merch nasty things. Alright, take care everyone. Or do, but I'll probably not respond to you if you cheat me that way.

1:50:28 way. Anyway, thanks for having me and a wonderful conversation. Thank you. This has been the Bitcoin Infinity Show. Thanks for listening. I can't talk anymore. It's been a long podcast. Two hours. I can't do two hours. Yeah. Yeah. All right. Take care. I'm also feeling it. Bye-bye. Thank you.