Bitcoin Spam: A Libre Relay View

I think that ultimately when it comes down to categorizing what is spam and what isn't spam, it becomes a subjective judgment. I think that it's important to make the distinction between what is consensus and what is policy. If you replace the word spam with an OFAC non-compliant transaction, the end result is why am I storing other people's transactions at all? I think one of the biggest misconceptions about Libre Relay is that a Libre Relay node only connects to other Libre Relay nodes. This isn't actually the case. And for me, whether or not something is spam is not a binary decision that I make right off the bat, but more of like a points based system. If you exceed some sort of threshold, then now the probability that you're spam is much higher than the probability that you're not.

Hi everyone and welcome back to Stephan Livera podcast. We're gonna be talking about the whole Bitcoin spam debate and, I think, it's very topical right now, and so I wanted to get someone on who I actually met, recently. his name is Kevin Kie, he is the platform engineering lead at Lightning Labs. But I will just clarify, this is mainly a, let's say, personal opinions conversation as opposed to an official stance of Lightning Labs or anything like that. But, Kevin Is, also known on Twitter as Proof of Cash. I thought he had some really interesting perspectives to share, and so I wanted to get him on. So first of all, first off, welcome to the show, Kevin.

Thank you, Stefan. Thanks for having me. you know, I first met you over at Plan B Lugano, which is probably one of my favorite conferences that I've attended so far. as Stefan mentioned, you know, please don't go bothering, Elizabeth about my opinions. These are just, you know, opinions that I hold, Some of the perspectives that I've had, but ultimately, yeah, really excited to be here and, to talk through some of these topics.

Great. And so look, in this whole Bitcoin spam debate, there are, let's say, there are different camps, right? And to some extent, there are- Kind of partial alliances between some of these camps, right? So as an example, there's the Not's camp, right? They're kind of pro-filter, they wanna filter out the content, spam. You've got Bitcoin Core And, like they're, you know, they're sort of, to some extent, beset on both sides by different views. There's Libre Relay, right? Which I think arguably you're kind of in the Libre-- Obviously Peter Todd is in the Libre Relay camp, and you're kind of, you're kind of-- I'm gonna put you in that camp. And then let's say there's the Ordinals camp, right? That's like the Casey, or, or Retardinals, as I like to say. The Casey Radames of the world, the Taproot Wizards, people

You know, they don't necessarily all agree on everything, and obviously even inside of these camps there are different views, but let's just start there. So, let's put it that way. So, would you consider yourself part of the Libre Relay camp?

So that's a great question. you know, recently I was watching a interview that had Joachim and Jimmy Song, and one of the questions that was asked to them was, "What implementations do you run? " I realized that actually, me and Joachim are very similar in that regard. I run Libre Relay, I run Core, and I even run a Knots node. I'll get into that a little bit later. But I would say that if I had to get put onto like a political compass, you know, an alignment of some kind, I would probably align myself most closely

I have that sort of alignment is because to me the most impressive part about Bitcoin was that not only do we d-achain-achain this, you know, Byzantine fault tolerance, we also managed to create an unstoppable form of currency that governments, which were arguably, you know, the groups of people that held the most amount of power among all of us, wouldn't be able to stop it either through sanctions, either through just trying to control the protocol and change it. we've seen Bitcoin fend off these attacks time and time again. and I think that Libre Relay It just makes sense in the, that it tries to align consensus with policy in a way where miners have the incentives aligned, as well as users who are just trying to make consensus valid transactions, right? I think that ultimately when it comes down to categorizing what is spam and what isn't spam, it becomes a subjective- Judgment that we're placing on top of a transaction. you know, perhaps I would want to launch an on-chain service that's not too dissimilar from Sat's Dice. I want people to try out Bitcoin, and, you know, they don't necessarily have to buy an entire Bitcoin to try out my service, but they can learn about how on-chain transactions work, maybe even, you know, make a few sats in the process. It's, it's an exciting, you know, little gambling application that I've put together. To somebody else, their subjective view of that may be these Happen at all, right? My sort of attempt to onboard more people onto Bitcoin by giving them a fun little application to play around with is viewed as wasteful of a, you know, common public resource. So for that reason, I think that it's important to make the distinction between what is consensus and what is policy. Policy is a guideline, it's a nudge that we use to try and push users to behave a certain way. Consensus is all or nothing, right? You either follow consensus, you're either Contingent on doing things in a consensus valid way or your consensus invalid and the network will reject your transaction, no matter what it is. and so, you know, bringing all of these factors together, I think it's really easy for people who are making these subjective sort of judgments on transactions to say, "Well, you're making transactions that I view as unnecessary, as spam, so you're a bad actor. You're only here to stir the pot. You're only here to waste my node's resources, and none of these transactions needed to happen." But I think what- They fail to take into account is if you replace the word spam with an OFAC non-compliant transaction, you could very well make the same sort of compliance-based argument, right? Why am I going out of my way? To store your OFAC non-compliant sanctions violating transaction, and then if you continue down this logical path, the end result is, why am I storing other people's transactions at all? Why not just store my own transactions and prune away and use zero knowledge proofs in order to be able to ascertain that the chain state is correct without actually storing those transactions? And I think this really misses the point of Bitcoin. The entire point of Bitcoin is that by joining together all of our resources across this decentralized network, we can create a level of re- redundancy and reliability that no other system on Earth begins to approximate, right? As soon as we start carving away pieces of that in order to benefit ourselves, we make the entire system weaker. and this is one of the reasons why Bitcoin is one of the few systems out there that is anti-fragile, where even though you try to attack it, it resists it, and the more it's adopted, the better it resists those attacks.

I see. And so, I mean, there's a lot of things to kind of get into. We'll try to get into those. And again, I'll do my best to try to make this accessible for the layman who's maybe not like deep into the technical weeds. So I guess the big obvious thing that people need to know is there's a difference between policy and consensus. Policy means things that it's like you set this on your own individual node, and we can all set different defaults. You can set your, setting more permissive and more liberal than I have, or whatever. We kind of have to agree on certain things. And so some of these arguments, they get into like, oh, as an example, Luke Dash's accusation to Peter Todd, "Oh, you're a bad actor. are you a bad actor spamming the chain?" and as I read from what you're saying, it's sort of like you believe in the censorship-resistant point, like, component of Bitcoin, and I, I, I would-- Am I right to say then that you see it like Libre Relay is a- Manifestation of that censorship resistant idea.

Exactly, that's, that's precisely correct. So I've always made this argument, you know, when talking with my friends who I may politically disagree with, I don't agree with a word of what you just said, right? But I will defend your right to be able to say those words any day of the week, even though I think you're completely wrong. I, it's the same exact case, you know, I personally don't think that inscriptions, ordinals are particularly interesting. I, I think they're kind of Kind of a waste of time and money, but I'm also not going to go out of my way and try to unilaterally decide that I want to stop this activity dead on chain. you know, I, I think it's perfectly fine if you wanna run not's, if you wanna run more restrictive filters. I just don't think that it's constructive to portray in such a way that, okay, well, if I run this filter, I'm meaningfully contributing to the reduction of this type of transaction. I think that is where we start veering off course a little bit, going from My node's preferences. I'm expressing what I want to relay, what I want to participate in, and conflating that with I am meaningfully shaping the behavior of transactions on the network. I think that is a fairly thin line, and many people cross that because they're thinking about it in terms of a system in which ninety-nine percent of the network has adopted a particular filter, right? They're thinking it in terms of like, you know, let, let's say an oversimplification, there's only one hundred nodes of, you know, Bitcoin nodes running on the network, and if ninety-nine of Running filters, then how are you going to get a transaction that's going to be refused by every single, you know, node on that network? How is a miner going to hear that transaction? Now, of course, you've got your standard explanations, okay, you know, look at Mara's slipstream, you know, you can directly submit a transaction to a miner. In the past, people have even emailed a hexadecimal representation string of a transaction to a miner, and then the miner just included it as part of their block template. I would say let's set those aside just for a moment to

Submission, what sort of network effects can arise? What sort of, you know, small differences in policy can amalgamate into a effective tolerant minority of nodes, right? And how basically you don't have to actually bypass the public relay network, you just have to convince enough people that you can create a path from point A to point B, not dissimilar to Lightning, right? One of the biggest, you know, things that people get confused by with Lightning is, well, you know, there's only so many channels How am I going to pay an arbitrary receiver? Well, that's the beauty of Lightning, right? You can take a path and make these hops, and you've only gotta find that singular path from you as a source to your destination, and then your payment's made. You don't have to have a direct connection between you as the sender and the receiver. The same is true for Relay, right? A lot of people make this oversimplification. They use things like epidemic theory, they use things like percolation theory, which are mostly, mostly meant for like graphs that have random edge weights We want to apply it to Bitcoin, which is a network that has highly redundant connections. So if we're talking in the classic Alice, Bob, Carol example where Carol is a miner and Alice to Bob to Carol is one particular possible route, yes, if Alice cannot send to Bob and can rely on Bob to pass that transaction to Carol, that specific path won't be usable. However, because that's not the singular path that connects Alice to Carol, it ultimately doesn't matter, so long as Bob can find a path somewhere along that public relay. network as it exists in that graph to traverse it and get to Carol, then Carol can mine that transaction without a problem.

Okay. And so this kinda gets into some of the, let's say, criticism or let's say, an argument that I believe I've seen Luke Dashow make this argument where he tries to say, "Well, Libre Relay is just actually just a direct to miner network." What's your stance on that? Is it just a network to get transactions from the spammers to the miners?

I can see why Luke would say that. personally, I think one of the biggest miscon Conceptions about Libre Relay is that a Libre Relay node only connects to other Libre Relay nodes. This is actually not the case. And, you know, I like to check my peers every morning when I wake up, it's just part of my morning coffee routine. And, very commonly, in my Libre Relay peers list are Core V twenty-nine, Core V thirty. I've even had a garbage man node that's tried to connect to my Libre Relay node, which I promptly banned. but, you know, the, the beauty of Libre Relay is that it is a small When I, when I, whenever I run a piece of software, I try to do my best, you know, you know, attempt at looking at what changes were actually made, trying to understand them before deploying them, right? I don't really want to just be deploying this black box that I don't understand how it works. And the beautiful thing about Libre Relay is how little it changes, right? you're setting this user agent so you're identifying yourself as a Libre Relay node, and then you're looking around on the DNS seed for Libre Relay nodes which you will have a higher weight But by no means do you ignore other nodes on the network, right? I still connect to core nodes, I still connect to Knots nodes even. those nodes may not facilitate the relay of my transaction, but I still connect to them as part of the peer-to-peer network. And so for that reason, I don't believe that Luke's assertion that Libre Relay is through its preferential peering system ignoring or bypassing the public relay network. I think it's just a subset of the relay network. It's no different from Knots in the sense that- That you are advertising you're running a particular version of, or a particular implementation, and if you want to preferentially connect through your Knots node to only other Knots nodes, you can write a ten line bash script to do that. If you don't know how to write scripts, you can go ask Google Gemini or ChatGPT to do it for you, right? And, one of the things I find so perplexing about this is that a lot of people in the Bitcoin space are libertarians, and one of the most common basic- Forms of ideology in libertarianism is the freedom of association, right? That your individual liberty should entitle you the ability to freely choose who you will associate with, who you won't associate with. When I apply that same lens of ideology to Bitcoin nodes, I don't see the difference, right? What is the-- what is the line at which I'm crossing where-- Choosing who I should be able to connect my node to is somehow a violation of the protocol, right? I think that would be a much more, you know, valid argument if Bitcoin as part of its spec, as part of the code base that exists today, did some sort of randomization of what nodes it connected to and tried to maybe keep like a balance of the amount of implementations within your peer list. Like, for example, in this hypothetical scenario, maybe you would try to equally divide up connections to Core, to Knots, to Libre Relay. If that was the case, then yes, I Absolutely one hundred percent be on the same page with Luke here and say that, yes, you're circumventing the very intent of the peering protocol, because in this hypothetical scenario, the peering protocol wants to balance which implementations you're connected to. That it doesn't do that tells me that this is left intentionally open, right? You should be able to allow-- You should be allowed to choose basically the conditions, of how you select and vet the nodes that you're connecting to. And for me personally, I don't have any interest in connecting to nodes that I know aren't going to carry a my transactions throughout the network. They are, in my opinion, defective. They don't achieve what a node is supposed to do, which is remain neutral and carry any consensus valid transaction throughout the network. now where I do draw the line Are scripts that take a very long time to validate. For example, this actually goes back to the history of why is standard was even introduced into Bitcoin. It was introduced because people were creating scripts that took up to a minute, sometimes longer, to validate, right? And so rather than moving quickly and making those types of transactions consensus invalid, Satoshi said, "Okay, I'm going to institute a standard check, and if the transaction doesn't meet these, you know, relatively permissive qualities of being standard..." Transactions, then I will simply refuse to relay them to, to minimize the amount of impact, to minimize the harm that's being done to the network. Where I think that the line has become fuzzier over time is transactions that aren't strictly harmful, right? Op returns are very cheap to validate, even inscriptions with their envelope are cheap to validate. You're not executing any script, the script interpreter is looking at that script saying, "Okay, there's nothing for me to do here, right? Op return, cool. We're not even gonna put that into the UTXO set, we're gonna Inscriptions, right? We, we see this OP_IF envelope, this is unreachable code. We're not going to do actual any execution. Even BitMEX research has done IBD studies where blocks that are consistently filled with inscriptions are actually faster to validate than blocks that are filled with monetary transactions, because in the monetary case, you're actually executing scripts. Now, you know, you can make the argument that because Bitcoin is monetary network, that those validation requirements are therefore justified, et cetera, but my point here is that these types of transactions that we're talking about now in twenty twenty The types of transactions that we're debating banning through consensus through a soft fork aren't strictly harmful in the same way that the transactions that introduced the need for standardness checks in the first place were, right? you could make the argument that, you know, it's bloating the amount of storage that you might need to have, that blocks could have been less full and you could have stored less data. My argument to that is, well, the rate at which the blockchain is growing is still linear, it's very predictable, and storage drops at a power law price every- Year, storage is getting cheaper and cheaper as manufacturers improve their ability to manufacture high density storage. This goes for both hard drive storage as well as solid state. you know, we're even seeing a cottage core industry of node in a box solutions that aren't just Startnine or Umbral, and they're packaging on very nice hardware. They're packaging like nice Crucial SSDs in there, they're like as powerful as some of the nodes that I was building back in two thousand seventeen, two thousand eighteen, and you can just buy them as pre-made devices. So overall, I It's a very overblown set of risks that are being used to justify this very, you know, subjective approach to determining what is a good transaction, what is a bad transaction, what is good for the network, what is harmful for the network. you know, like my, my bottom line here is, as long as what you're doing isn't harmful in the sense of being expensive to validate, I don't care what it is that you're doing, right? You're a paying customer on the Bitcoin network, you are funding the security that I benefit from. And- And if I'm a user that predominantly just stacks Sats and I hold UTXOs in my cold card, I hold UTXOs on my Jade wallet, and I don't ever do transactions, in a sense, I'm a free rider. I'm not contributing to the security costs, I'm not contributing to paying the miners, right? I just have these UTXOs sitting here, I'm benefiting from the store value characteristics of Bitcoin, but I'm actually not pulling my weight in terms of making sure that Bitcoin remains secure. and for those reasons, I think that it's just incredibly silly Paying customers of Bitcoin, right? It, it would be as if you were running a corner store, and because you don't like the way somebody looks, you chase them out of your store, even though your store could use all the revenue that it could get, maybe it's in a, you know, a high rent area. so yeah, it's, it's, it's been very perplexing to me just like thinking about this from a more technical standpoint where I've divorced and decoupled the emotional aspect from the technical aspect.

Okay, so a few things. I mean, there's lots of different directions we can go out of what you spoke about there, but I guess this, question, like, okay One point that I've seen discussed, and I believe Jimmy Song and Murch have sort of gone a little bit back and forth on this idea, which is about very small UTXOs, right? And so this is an area where, as an example, Murch from the core camp, now again, he's one person, core isn't a monolith, but his view is actually using policy to discourage certain forms of DOS, in a sense, of very, very small UTXOs like one sat outputs and things. He, he sees that as, yeah, that's a good thing to do, whereas I guess if you go to the full other end of the extreme, it's just like, if you're a full Libre Relay, it's just like, yeah, if it's consensus valid, go for it. Where do you stand on that? Is that-- would that be a problem? Like, as an example, hypothetical, like if somebody said, "Hey, Kevin, I'm just gonna like..." Even though it's not policy, I'm just gonna create many, many, many, many one sat outputs, 'cause I know your node has to store all of them, and it's computationally maybe more, inefficient or costly to have to-- for the network to deal with that.

That's a great point. So, you know, I try to view these things as less of a binary and more of a spectrum. So on, on the one end, you've got the most harmful type of, you know, DOS, which is a hard to validate transaction, and then maybe on the other I think that when it comes to dust limits, we're, we're looking at something that's closer to the harmful side, but not necessarily enough that it would make me worry about it, right? I, I think that it's definitely good to set a semblance of a dust limit that makes sense and that you're not creating an output that costs more than to, you know, actually spend it, and doesn't hold as much value to justify its existence. But on the other end, I think there's a lot of misinformation out there regarding the UTXO set that drives a lot of this One of the things I see on Twitter all the time is like the UTXO set needs to fit in memory for a node. This is not true, right? You can have a one hundred gigabyte UTXO set and still run. A Raspberry Pi with Bitcoin Core, it'll do the job just fine, right? A lot of the reasons why people end up having such a slow node do-- comes down to misconfigurations for their hardware and not necessarily because of particular transaction history that has happened. That being said, I think if you put a gun to my head and you said, "Kevin, you need to choose between making the current dust limit enshrined in consensus or making it just, you know, no policy at all and it's just a free-for-all and everyone is making one sat UTXOs," I'd say I would say I would lean a little bit closer to making it a consensus rule, but again, it's not something that jumps out to me as necessarily urgent, right? I think I would, I would look at this from a more reactive perspective rather than a proactive perspective. I would like to see some evidence that people are actively abusing this and then move to enshrine this in consensus and change it. Until then, I don't really think there's much point in changing consensus in order to try and prevent a certain kind of bad behavior. you know, the example I always use is when we look Our repository, there are files that haven't been touched in years and years and years. Almost all of those files are consensus, right? You would have thought, you know, somebody at some point would have at least jumped in and made a linting change, fixed up some of the formatting there, maybe refactored a function or two, made it a little bit cleaner, maybe not even, you know, delving into the aspects of performance. However Consensus changes are so incredibly fraught with peril that, you know, we don't even lint them. We don't even try to fix the formatting of the file and have all of the code behave exactly the same, because there's just no point in going to the consensus level unless there's an urgent reason to change consensus.

I see. Now, I'm not in the noz camp, as you know, but this is an argument I've seen from the noz camp, which is, "Look, the dust filter is an example of a filter that works." and so what, what would be your answer on that? Is it that- It's that there's not an economic or social reason to go around that filter or like how, how are you explaining that? Because I guess this comes up in the argument about, and again, maybe it's an oversimplification of filters work or filters don't work, and maybe it's more like, no, there's actually a bit of a nuance you have to explain. How do you see that around the dust filter? Is it that the dust filter works?

Yeah, so I think that the easiest way to relate this to a lot of people is not looking at the dust filter, because not much has changed there, right? Like you said, there's not a lot of people who are trying to get around the dust limit. They're not trying to, you know, we don't see meta protocols being built with one set outputs, right? They're, they're going with dust outputs. And I think what ends up happening here is a lot of people conflate an equilibrium with the sort of actual barriers that exist. What, what do I mean by that, right Pretty orthogonal, you know, to the dust limit, which would be sub-sat fees, right? So sub-sat fees weren't obviously not being carried and relayed by a majority of the nodes in the network for a very long time. one sat per byte was the minimum, right? So how did that shape the development of wallets? A lot of wallets chose an integer, so one would be the lowest value they could put in, including Sparrow Wallet, right? But then we saw a small group of people starting to put sub-sat fee rate transactions on chain, and that actually caused more and more people to consider, okay, wait a second, this is now possible, miners are willing to mine this, this could be something interesting. And as they continued pulling on that thread, they realized that what we're observing, and, and this is a graph that a lot of people in the not spam camp will post a lot, is, you know, sub-sat summer actually proves that filters work. Look at this huge spike at one sat per vbyte. but What this really ignores is that all of that, all that screenshot, all that graph shows you is that there is a cluster at one sat per byte, right? it shows that wallets aren't still defaulting to one sat per byte. It shows that there's a latency, a, a lag in adoption to a new sort of de facto standard. It shows that users perceive one sat per byte to be the minimum safe fee. What it doesn't show is that that is actually the minimum safe fee, right? It, it shows that there is a- Latency in which knowledge becomes available to the public and then that knowledge being widely disseminated. And if we follow the timeline for SubSat Summer, what we saw is that once this knowledge became disseminated enough, Sparrow Wallet had a PR that went up that would check to see what your Min Relay TX fee was for your core node if you were connecting it to a core node, and it would check it against Electrum, if you had it connected to Electrum, and it would allow you to just drag that slider and suddenly Whereas the previous day you couldn't do subset transactions, the next day you could. and so, you know, I, I think that it's a little bit confusing to people who are looking at this because intuitively they might think if the filter doesn't work, then we might see something that's more akin to a uniform distribution, right? Where, where you're looking at it and it's like a bar graph and all of the bars are sort of equivalent. However, I think that really ignores that In reality, very, very few distributions are actually uniform. I would expect to see more of a bimodal distribution where you have two spikes in the graph, and what do you know? If you look at that graph, that's exactly what you see. You see a spike that is sub sat, and then you see a spike that is at one sat per byte. you know, these clusters, they exist because human incentives and behavior aren't so easily attributable to a predictable model. Sometimes there's latency and adoption, sometimes there's wallets that- That haven't updated, sometimes there are exchanges that have hardcoded backends in terms of how they handle fee rates, right? There's all of these factors that go into how quickly something goes from existing to widely adopted and it being observable, that looking at observational data like this collapses all of those factors down to just the data that you're looking at. It doesn't contextualize it, it doesn't tell you why a cluster exists at a particular fee rate. All it tells you is that this is- This is the instantaneous snapshot in time. I think what's far more useful is to look at that data and plot it over time, right? Over the next ninety days, how much has-- have those distributions shifted? Are there more sub-sat fee rate transactions that have occurred? I think the same would be true if we applied this to the dust limit, if core v. thirty one. Lowers the dust limit. You can now make one sat outputs. I don't believe that overnight you would start seeing one sat outputs everywhere. I think that there would be a latency. I think that it could be months, if not years, before we start to see meta protocols beginning to switch to that, because it takes time for knowledge to disseminate. It takes time for people's mental models to recalibrate to reality. even now, plenty and plenty of people out there are making their transactions at one sat per byte, despite knowing that you can do transactions at zero point five, that Mara will mine Per byte transactions, the reality isn't instantaneously reflected in behavior, you know? I think this is the key argument that people really just drop. they expect that if there's a change, that there will be an instantaneous associated change in people's behavior. but this isn't just not true, right? In reality, there are all sorts of latencies and externalities that Actually come into play that affect how quickly changes are made. And because a lot of Bitcoiners are very risk-averse, even if they know something is possible, they may not be willing to hazard trying that out until more and more people have done it and they look around and they see that this is a much more commonly done thing.

Yeah, and I guess the, the whole sub-satsuma thing arguably is more like a social phenomenon, right? I think, was it Moninord or Peter Todd or someone kind of noticed this, and then it, I think- I think they pointed it out and then it sort of became a thing that mining pools started to drop their threshold, I guess their min relay tx fee, I guess what we're talking about here. now there is kind of a point back and forth there where people said some of these mining pools they lowered it really low and then theoretically or arguably, I think they were saying, "Oh, but the orphan rate went higher, so that was like a risk to them, so therefore they had-- they raised it back up, and there was like a sweet spot." So in the case, as you mentioned,

You know, lower than that. Do you see that as-- and maybe this ties into kind of also the Knots argument, the Knots camp argument of, "Oh, more and more people running filters hurts people, the miners, who mine spam, right? Like, kind of, or because that they would have a higher orphan rate and therefore they are less profitable or get less revenue." Can you explain that or at least from your perspective? For sure, yeah. So, so,

orphan rate is obviously a concern for any miner, right? You don't wanna be working on a block

Block, and now you're not getting your block reward, even though you've spent all of this electricity and time and effort. so yes, in, in regards to Mara originally taking zero point one sat per view byte transactions and then, you know, doing some math, recalculating their risk, and then deciding that zero point five was more appropriate, I think that the way that they're calculating that is basically coming down to how much potential propagation delay could be affected by, you know, filtering. So from the perspective of a filtering node, you're looking at about Six seconds roughly for propagation delays, and that translates to approximately a one percent chance that the network would outcompete your particular pool, saying, saying that you're running on Nots in this example. I think that that is obviously a real risk if you're running a highly centralized, highly scaled, you know, benefiting from economies of scale type operation. I think it's probably not as big of a deal to you if you're running a smaller mining operation like what I'm doing in my basement with a few hundred terahashes per second of hash rate. and this actually ties in really well to the fiber network. So the fiber network was something that was launched by Matt Carallo a long time ago, and it basically used the same logic as compact block reconstruction, where you're relying on miners having the transactions that are gonna go into a block being in their mempool already, and then the actual process of reconstructing the block is you pull all the, all of those transactions from your mempool into the block, and then you also grab any transactions that weren't part of that block. that small slice of time, I think, is what you're Orphaning risk that's introduced, and this is something that scales with the number of transactions that you don't have in your mempool. I think this is actually fixed by having better relay policy across the network, right? Which is one of the reasons why Core v30 changed this. If you look at like the guy who runs Fort Monitor, he had updated from v29 to v30, and he saw his compac-compacted block reconstruction rates significantly improving. and as a miner, this doesn't change. This, this mechanic and this sort of, you know, interaction with the network has always been the same. But one thing that people leave out in their factoring of how miners operate is that miners don't necessarily just peer with the wider peer-to-peer network and rely on them. To get transactions, miners very often will peer over high, you know, bandwidth, low latency connections to miners directly using things like fiber, which also, you know, makes use of UDP instead of TCP to ensure that you don't have to wait until an entire sequence of data is transmitted before you find out that one piece of data was corrupted or maybe missing and then you have to resend that data. point being there is Miners are already going to be peering with other miners in such a way that they'll be able to get transactions very, very quickly, so they can reasonably minimize the amount of risk that gets brought upon pulling in transactions that other nodes in the network didn't have in their mempools, right? Because miners, at the end of the day, aren't running just a vanilla core, they're running core with patches on top, sometimes to block template construction, sometimes by peering with Libre Relay nodes and setting more, you know, permissive policy in regards to relay so that they can hear about all of those transactions. Not one miner out there, to my knowledge, uses Libre Relay as their block template constructor. They simply peer with one Libre Relay node, and that's enough to get those transactions into their own mempools, right? So, so al- as long as you have the ability to hear those transactions from any part of the network, you don't need to rely on the greater portion of the network in order to be able to hear those transactions. Where I think the equation here changes a little bit is with Ocean Miner With people who are mining to DTEM, for example, those people are generally not running a modified version of Core, they're generally not peering with Libre Relay nodes, they're just peering with the peer-to-peer network. In that situation, yes, by running stricter filters, you are putting yourself at higher risk for being orphaned, but this isn't the same as centralized miners being hit with additional orphan risk, right? So TLDR, I think Mara is operating out of an abundance of caution here. I predict that in the future, if Bitcoin's price continues goes-- going up That, that will drop from zero point five sats per vbyte maybe down to zero point four, right? Zero point one is truly very, very low. They're gaining so little, little revenue from including these transactions that risking any bit of orphaning is just not worth it, right? But if Bitcoin's price continues to go up, then it's very possible, very likely even, that zero point two five, zero point three, zero point four, somewhere around that neighborhood, is still worth the potential risk of orphaned, blocks, which is, you know, again Low, because miners can peer with one another over these high-speed links, and so if Spiderpool is peer with Mara, and Spiderpool has this transaction in their mempool, it's very easy for Spiderpool to compact, block, reconstruct Very quickly and mine on top of the tip, which might have been Mars' latest block, right? At the end of the day, it's the people with hash who are running nodes that are determining what the orphan risk is, because miners predominantly care that they're not mining on top of a stale tip. Now, to sort of really drive this point home, I wanna bring up spy mining. So spy mining is when you don't actually wait to hear a block from a competing pool before mining on top of it. So let's say that I am running Running my pool, which is just me and a few friends, called Libre Pool, and I have a fake miner, so to speak, that's connected to Mara's pool. It's going to be able to get the header and the hash of that block by being connected over Stratum without being able to validate if that block is actually valid. What does this give me? It gives me the advantage that if Mara mines a block right the second, that I will be one of the first people to begin mining the block that builds on top of that, because I- I didn't have to wait to hear that block, I didn't have to wait to validate that block. Now you might say, "Wow, isn't that incredibly degenerate? " Right? There's no way for you to know whether or not that block is valid, but it just goes to show that mining is such a competitive operation that some mining pools are even willing to take on the risk of building on top of an invalid block just so that they can be the first ones to kick off that race of finding the next block. And for those reasons, I think, you know, the incentives are clear to As long as the orphan risk doesn't exceed a certain threshold, miners will always be willing to open their back doors and let in a few of these sub-sat, you know, fee rate transactions, and we've seen that as a trend. The number of miners who are willing to accept such transactions has been increasing over time, not decreasing. And I don't think that Mara lowering, you know, the threshold from zero point one to zero point five disproves anything. I think, in fact, it proves that they're staying power in sub-set transactions, that there's enough economic demand for these cheap transactions. And, you know, I don't, I also think it's no surprise if you look at the types of transactions that are using sub-sat fee rates, right? A lot of them are people who are consolidating thousands of UTXOs that are each dust outputs, right? They don't, they're not gonna wanna pay one sat per vbyte. That's gonna be forfeiting a good portion of the inputs' values, right? And so this is like a very unique tranche of transactions that doesn't really try to compete with other transactions. When I'm making a one sat per vbyte channel open, I am making that channel open with an expectation that it's gonna be done in a timely manner. I have a high time preference. If I'm trying to consolidate thousands of UTXOs because I'm a degenerate that gambled a ton of Bitcoin on inscriptions and I With all of these dust outputs, and I just, I just wanna consolidate them and get them back to a UTXO and store them on my hardware wallet. I don't care how long that takes. I'm willing to wait weeks for a, you know, lower fee opportunity in the mempool, if need be. I'll wait for months even, right? It's not a huge priority for me to get that consolidation through, but it is a huge priority for me to not lose a ton of value in the process. A-and for that reason, I think unless subset fee rates begin to crowd out,

As well as block space, they're always just going to be like a nice little cherry on top for the miners. Gotcha.

And what would you say to the general argument then about, like, the not filter argument, which is, "Well, mining is centralized now, if it was more decentralized, then spammers, miners who mine spam, get penalized by doing so, compared to monetary-only mining, let's say?"

Yeah, I think that's true. I think that's true. If we were to wave a magic wand today And we got all of the plebs across the entire country who are currently mining at home with their S-nineteens, with their S-nines, even their BitAces, and they all decided to either mine to a improved version of Datum, I'll get to that in a second, or even solo mining with like a CK pool or a public pool locally running instance. Yes, you would have a significantly higher ability to punish spam on the network. Now, why do I think that that's not something that's going to happen in the short term? the first reason is network asymmetry. So I think Matt Carallo wrote this, that, the current probability of receiving a block in its entirety over a TCP connection without any retransmits being necessary is about ninety-one percent, which sounds pretty good, right? But again, going back to what we were talking about regarding orphan risk, if you're not the first to start working on that next block, you may as well have given up your opportunity to potentially get that block. Everything is very, very latency sensitive, right? So if you're a miner and you're operating all of your template construction nodes in a data center Not only are you benefiting from economies of scale because you can just, you know, take out a business loan and buy tons of these ASICs, you're also benefiting from having some of the highest speed connections. You can negotiate with your ISPs to get, you know, better SLAs where they're contractually obligated to have certain levels of uptime and performance that you're essentially dedicated, you know, and guaranteed to have, otherwise you'll be able to get money from them. it just becomes very difficult for pleb miners to compete with that, and that's one of the reasons why I think

As the gateway, the idea there being that, you know, you can somewhat benefit from having these high speed connections, while also still being able to do your template construction locally. The problem that I take with Datum is that, and I, I've watched this, video by one of their engineers where they talk about eventually, in the future, what they want to do is have a subset of miners validate the work of other miners. I think that would be like the Platonic ideal of Datum. I would be screaming from the rooftops, everybody needs to switch to Ocean right now, The issue that I take with Ocean and Datum that it-- as it exists today is if the Datum server goes offline and then comes online, let's say three hours later, there's a bit of catch-up that needs to happen for all of that accounting to come up to speed, right? I think that that means that essentially Ocean is this unnecessary third party, and until we can get to a point where the Datum server can go down and operations aren't affected whatsoever, that it's Somewhere in between centralized and decentralized, probably closer to decentralized, but not fully decentralized. And the other issue I take there is that, you know, obviously a lot of people, they want to reduce their variance, right? They don't want to solo mine with CKPool Solo, they don't want to solo mine with PublicPool with their Bitcoin Core or Bitcoin Knots doing template construction because they might be mining and, you know, chugging away at this for years and years with no revenue whatsoever. But to me, I think that that's just what comes with the territory, right? If you can't Get out of the kitchen. If you can't handle paying for power bills for potentially ten years on end without finding a block, well, that's just how the cookie crumbles, right? Every single pool out there that operates, operates under this assumption. It's only the introduction of, you know, the drug of fPPS, where you're paying by share, that has made people so averse to high variance, where they want to just get a small amount of payouts constantly, even though if the pool has higher than average or expected- Luck, they don't get a share of the increased earnings, right? This is, this is how F2Pool operates, for example. so a lot of stuff that Ocean is doing is great. I would just like to see them push a little bit harder on Datum, and then the narrative will- Generally be true that you can punish spammers because the hash rate isn't coming from a handful of centralized mining operations. But I also think it's important to temper our expectations here, because allowing for this decentralized group of miners to bloom requires significant infrastructural upgrades as well. You need the average person with their average internet being a lot more reliable, being higher speed, being able to peer with tons and tons of nodes, being able to use things like fiber to get blocks pushed in In a way that doesn't require retransmits. Everything needs to get tightened up, right? Mining isn't a sloppy enterprise. It requires a lot of attention to detail and precision in order for you to be viable, right? So, you know, for that reason, I always take issue with people saying, "Well, I'm fixing the decentralization of mining. I'm mining to Ocean, right? I'm doing my block, template construction locally. Yes, that's definitely one part of the equation. But so long as you're dependent on Ocean to do the accounting correctly for you to be paid out correctly, that's always going to be a point of failure, and until we can refactor that out, and, you know, two oceans credit, they have talked about doing this, until we've reached that point, I, I think there's still a lot of work that needs to be done before we can truly decentralize hash power.

I see, okay. now on the question of Libre Relay, because we've been talking about that, given that this exists now and it basically means people, you can get transactions mined in, non-standard transactions mined in. Is it, is it fair to say that the filters that matter now are the filters that a miner applies on their node?

I think, perhaps to be more like, you know, specific here, it's less about the mempool policy that a miner is setting and more about what they're willing to permit. So policy in the more generalized term, not referring to what will they put into a block. Right, exactly. Their policy in terms of what they'll put into a block. Now we've seen that miners have unsuccessfully tried to- you know, make more permissive certain things like the SigOps limit. We've seen invalid blocks get broadcast onto the network because a miner misconfigured a portion of their modified, you know, daemon that they're using for template construction. So we, we know that miners tinker with these settings. We know that they're not just downloading the latest release of Bitcoin Core and using that to mine on top of it. but ultimately, yes, I think the answer is what miners decide they're willing to mine shapes the reality of what is going to be On chain, far, far more than filters, because at the end of the day, a filter is simply a means of transport, right? This would be like if I said, "If you're wearing a blue shirt, you can't get on the public bus." Therefore, it's going to become impossible for people who are wearing blue shirts to get to the park because there's a bus stop right next to the park, right? It completely ignores the fact that you could just hop in your car and drive to the park if you want. You could even hop onto a bus line that maybe is,

There's all sorts of ways for you to get people who are more permissive, who are more sympathetic to you getting from point A to point B, to allow you to do that, and it's just not a very robust way of preventing certain types of transactions, right? We saw that with mempool full of RBF as well. We didn't need the entirety of the network to upgrade, we just needed the hash power to upgrade and a small amount of people, I think it was about ten percent or so, of the network to upgrade, and then regardless of the flag on RBF, you were able

Because it was not so controversial, not a lot of people really complained or made a big stink about it. But as soon as you flip the narrative to talking about things that are more culturally, you know, clashing like op-return and data embedding, that's where we start to get a lot more friction. And what I find to be really interesting there is that I think that this cultural sort of, you know, divide goes all the way back to when Ethereum first came into existence, right? I've always been of the opinion that you should know thy enemy, so I've kept my My ear to the ground, I've even made friends with a lot of people from the ETH space just to see how things are going over there, to, to get a temperature check. And what you'll see is that culturally, Ethereum L2s are way more comfortable with things like rollups, where you're posting to L1 for data availability, you're posting like either a proof or you're posting some, you know, subset of the state onto L1 and you're anchoring onto Ethereum, the base chain. On Bitcoin, we haven't really done that for our L2s, right? On Channel open and you got your channel closed. Those are the two times that you interact with L1. You're not really pushing a whole lot of arbitrary data on chain, right? All of that, all of that state, all of that, you know, state machine transition, all of that is being stored off-chain. So this, this like even technical cultural limitation, I think, is driving a lot of the divide and causing people to Interpret the operator limit being raised as, you know, encouraging rather than being a form of harm reduction.

This episode is brought to you by CoinKite, the makers of my favorite Bitcoin hardware wallet, the Coldcard Q. Now, some people think self-custody is too hard, but it's really about taking responsibility for your Bitcoin wealth and understanding that self-custody gives you a true feeling of liberty. The Coldcard Q has a full keyboard and big screen. It's got two secure elements and a true air gap, allowing you to go fully air-gapped using QR codes from seed transaction signing. You can power the device using three triple A batteries, so you don't even have to plug it into the wall for power. You can easily use it with Sparrow Wallet for PC or Nunchok on mobile, and you can dial it into the right level of security and complexity that you choose. If you want a simple setup, just use twelve words and single signature. If you want passphrase, easy. If you want to add multi-sig or co-signing features, you've got those too. So go to coinkite dot com, use code livera to get ten percent off on Let's get into the whole spam war stuff. Obviously, we've been kind of indirectly talking a bit about it. Let's talk a bit about what exactly constitutes spam in Bitcoin, right? and maybe you wanna distinguish-- and you were touching on this a little bit about maybe you have to distinguish here between, let's say, content spam per se and genuine technical DOS spam. And I guess the other kind of- Sort of thing that gets thrown in here is like, okay, there are filters that relate to what's colloquially known as upgrade hooks, and so that's another reason why these filters exist. so Let's talk a little bit about that. What, what constitutes spam in Bitcoin? How are you thinking about that?

So I will preface everything that I say from here on with, "In my opinion," right? 'Cause that, that is, that is my stance here is that everything is subjective. So in my opinion, embedding data that is purely non-monetary in nature And I'll get onto the specifics of how I, I categorize that. it's a bit fuzzy when you get into certain edge cases, right? But I, I think if the intent of the transaction is purely non-monetary in nature, that is a fairly good way of adding a point. And, and for me, whether or not something is spam isn't a binary decision that I make right off the bat, but more of like a points based system where if you have a certain amount of points and you exceed some sort of threshold, then now the probability that you're spam is much higher than So let's say that this arbitrary threshold is ten points, right? I think if your data is purely non-monetary in nature, it's just embedding like a JPEG, for example, like an inscription, that's gonna be two points right off the bat, right? I'm a little bit suspicious that this is probably spam. If your data is not facilitating a layer- To scale on, that's going to add like three points, right? So now I'm at fifty percent probability that this is spam, for like an inscription, for example. Then I'm gonna assign a few points based on who is making this transaction, right? Did this transaction come from a Bitcoiner who's maybe just testing out a new platform that exists? Did it come from someone who's in the ETH space who's trying to reproduce something that exists in the ETH space, right? so an example I'd give there is like the BRC twenty standard. If you look at how the Is structured. It's structured in a way that more closely resembles interacting with an ETH smart contract than something that would exist on Bitcoin. So for a BR-C20 transaction, I'm adding three more points. Now I'm at eight out of ten, right? And then the remaining two points, I think, mostly come down to, is this trying to compete with monetary transactions on a fee rate basis? Is this paying a one hundred sat per V-byte, you know, fee even though the median in the mempool is like twenty, right? If it's doing that, then I assume that it is It is highly timesensitive and it's trying to compete with monetary transactions, both in terms of time as well as fee. Yes, now I've hit this threshold, this is spam. I think the line becomes a lot fuzzier. For example, let me pitch you this idea. I have a swap provider and I have a preimage, right? And in order to settle a transaction, the preimage has to be released that corresponds to a particular hash, but you don't know what the preimage to that hash is, right? So I could just as well embed a tiny, tiny little JPEG or a I could use that as the preimage to the hash, and then when you go to claim the funds, I release the preimage on chain, and that is now spam. However Going back to how I said, you know, if you have a magic wand and you can make some sort of outcome happen magically with no regard to how you would actually make that happen. If I had a magic wand where I could wave it and say, "Any spam that is on chain, instantaneously destroy. Smitherines, right? " Have I not just stopped a monetary transaction from going through, one that I didn't know was spam until the reveal stage for the preimage? I think that I would have, right? And in that sense, you would be committing a particularly heinous kind of censorship In regards to the Bitcoin ethos, you've been stopping a monetary transaction because one step of facilitating that monetary transaction happened to reveal spam. For that reason, I'm generally hesitant to try and project my own subjective view on what is spam and what isn't spam and translate that to actual action. I think it's fine to look at a transaction and be like, "Wow, this is spam, this really sucks, right? We should figure out who's making these types of transactions, and we should try to encourage them to do them in a better way." I don't think that it necessarily- Creates enough incentive for us to try and stop them. So what do I mean by that? I think Citra is a great example of this, right? Citra gets thrown around a lot as the reason why the op return limit was raised. Now, setting aside that that's completely inaccurate, let's talk about how Citra's justice transaction requirements play out. They could use a standard eighty byte op return and then they could have two fake taproot pubkeys 'cause they have a little bit more data than eighty bytes, and that would work just fine for Citra, right? It, it doesn whatevers if they use an eighty byte op return and two fake Taproot pubkeys, or if they use a non-standard op return. What it does make a difference to is the common, the public resources of nodes, right? Obviously, I would prefer to store a one hundred byte non-standard op return because it doesn't enter and, you know, you know, pollute the UTXO set forevermore, even though this is an edge case of a transaction. I still want to choose the technically superior solution out of the two, right? However, a lot of people didn't see it that way, they saw it as, you know, you're raising the operator limit, so therefore you're, you're, you're putting a neon sign above your head that says, "Please spam me." I don't see it that way, right? And I, I think we can relate this to the real world as well. In, you know, the, the late nineties, there was a flight, by, operated by a Brazilian airline, and very tragically, somebody had smoked a cigarette. This was a, this was a flight that allowed you to smoke on board. Somebody had smoked a cigarette and they didn't put it out fully, and they put it into the waste bin in the bathroom, and consequently, the waste bin in the bathroom lit up in flames, the bathroom lit up in flames, and, you know, the

FAA started requiring that, regardless of whether or not you allowed smoking on your flight, you would have to include in the laboratory in ashtray. Now, if you took the approach that a lot of people from the nots camp have taken to the upper turn limit being raised, you might say, "Well, the FAA is clearly endorsing that you smoke on the plane. Why else would they put an ashtray on board, right?" But I think if you look and zoom out and look at the bigger picture, you would see that what the FAA was simply doing was taking into account human behavior, that It's very possible that somebody will try to skirt the rules, and if they do, if you don't provide them a less harmful alternative, they may either unintentionally or intentionally end up doing the worst possible thing that they could do in that scenario, which is trying to hide the lit cigarette that they smoked in the lavatory by stuffing it into the wastebasket, and maybe we get a repeat of the incident that happened. so I think, you know, a lot of this comes down to, you know, what your sort of ideology is. Are you teleological? Do you believe that an object exists because of its purpose, or are you an instrumentalist? Do you believe that we have found a purpose and ascribed it to the object? Take this fork, for instance. Does it have these tines on the end because that's what facilitates us using it to stab meat and eat food with it, or did we look at a farming fork, right? Do we look at Other similar systems like a skewer that we were putting our meat on and roasting over a fire and say, "Wait, we could use this in a handheld format." Did the form factor of the fork arise because this was easier to manufacture than other potentially superior solutions like a spork, right? I find myself in the instrumentalist camp. I think that we create objects because of a smorgasbord of reasons, because a bunch of incentives that are pushing us and pulling us one way or another, and then once we have- We have something that is useful, we ascribe a purpose to it after the fact. I think Bitcoin is the same, right? Satoshi set out to create a very, very resilient database that would allow you to conduct moneta-- monetary transfers, right? But that doesn't mean that Bitcoin can only conduct strictly monetary transactions in the way that Satoshi outlined. Satoshi doesn't talk about scaling and layers. That's not mentioned in the paper. Lightning doesn't exist in the white paper. That doesn't mean, right, that Lightning isn't- Bitcoin or that Lightning has no place in Bitcoin. Similarly, I think systems like Citra that aim to try and steal away users from Ethereum EVM based chains and bring them to a platform that is anchored in Bitcoin is the traditional definition of being a Bitcoin maximalist, that Bitcoin is the only blockchain that we actually need to make all of these systems work, that we can have them all plug into Bitcoin, and that they don't need to exist as independent entities, right? We don't have five in- Internets. We have one internet, and we have all of these systems that plug into the internet and use it as the communication layer that brings and connects everything together. Open timestamps isn't a monetary protocol, but it's intensely useful for Bitcoin projects, specifically because you don't want to have a piece of software that is released on a particular date and then somebody went and tampered with it, right? So being able to timestamp that a particular piece of software was released and signed at a point in time is very useful to Bitcoin, and I would argue that- Despite being non-monetary in nature, it only earns itself a few points on my "is it spam" scale, and therefore, it's not spam. I think, you know, whenever somebody is selling you their, you know, criteria as being a simple yes or no answer based on three seconds of thought, you should be immediately suspicious that their bias has clouded their judgment and their ability to objectively look at something and say, "Is this detrimental to Bitcoin? Does it compete and try to crowd out monetary transactions? Is it being made?" By somebody who has no skin in the game, who, who doesn't, you know, benefit from Bitcoin becoming better, and also similarly isn't hurt by Bitcoin becoming worse. I think all of those factors need to be fused together into a holistic viewpoint that then informs you on whether or not this is spam. And I don't think that that's something you could do on an automated basis, right? If Not's, you know, has a filter in place for checking if n lock time is equal to twenty one, that's not checking the context or the intent of a transaction that says n lock time twenty one It's just looking at the contents of the transaction in terms of that specific field, right? and it, it's just a gross oversimplification of whether or not a transaction is good or bad for tran-- for Bitcoin, because at the end of the day, if a transaction is paying fees, I view it as starting out from a place of good, innocent until proven guilty.

Okay, so as I read you, then BLC20 is spam, but JPEG inscriptions on their own aren't spam, in your view, what about stamps? Is stamp spam?

Stamps is absolutely spam. I think stamps actually wouldn't exist without inscriptions having paved the road for them. If you look at Mike in space, he routinely talks about how, you know, he has this very like, Confrontational view of, inscriptions being printable data, and he says, "You know, prune this, like, you can't get rid of me, like, I'm here to stay." It's like almost a, a very rebellious way of going about data embedding. So for that reason, you know, I think the intent there is very clearly, we want to embed arbitrary data on Bitcoin, and we want to do it to piss you off, in a similar way to how a, you know, silly tourist might go to one of the wonders of the world and scribble

To, you know, use this very beautiful public resource and degrade it. They're trying to, you know, do graffiti on it, right? That's, that's a far more straightforward interpretation of what's going on, because they're not trying to hide their intent, and there's no, ambiguity in terms of their intent, whereas with inscriptions and like transferring, you know, pictures back and forth, I could just as easily ascribe that to people being stupid and wasting their money on Bitcoin, you know, they're, they're trying out this new fad that they heard about. The amount of damage that inscriptions can do is necessarily, you know, something that's reflected by the community. I think that a lot of the times, the yardstick by which the community uses to determine if something is harmful or not is simply by comparing its similarity to what happens in the ETH space, right? Ethereum kind of like blew up the whole, you know, chain with NFTs and like CryptoKitties and all of these other like stupid kind of, you know, on-chain games. So when we see something like that, or something that's similar to it coming up We immediately have this like very, very visceral reaction of disgust, of like, you know, we want to reject this, we want to keep this off our chain, take that crap somewhere else, right? But I don't think that that is a very objective way of looking at it, especially when you consider how much revenue to miners came from inscriptions. I think Peter Todd was saying like in the PR that Luke had raised to filter out inscriptions, these types of transactions might be stupid, but they correspond to a pretty large proportion of miner revenue right now. So the incentives aren't in- favor for miners to go along with something like this. Nor is it really going to make all that much of a difference if Casey pushes an update next week that changes the envelope slightly, or maybe gets rid of the envelope entirely, right? it's always going to be this cat and mouse game, and what we know is that there's economic demand to do stupid transactions like this. So why not let this be a self-solving problem, right? If you look at a company, and this company is purely unprofitable, all they ever do is make a product that nobody wants, what happens to that company They go bankrupt, they, they cease to exist. Why must we take a interventionalist standpoint and say we must come in and destroy this fledgling ecosystem when the probability that it survives in the long term is already low, right? If you look at the Deejans who have been trading runes, they're all hurting badly. Many of them have lost five figures, if not more, in terms of Bitcoin. They're probably not going to come back for the next season of, you know, Run Mania. They're going to be hurting. They're gonna have their tail tucked between their legs, and they'll probably go back to other chains to do their shitcoining, because it's going to be cheaper. It's gonna have a lower opportunity cost, right? If you lose a little bit of Ethereum today shitcoining, you've only lost a little bit of Ethereum. If you do-- if you lose a bunch of Bitcoin while shitcoining, you've lost the hardest money, the best store of value in the process. Your opportunity cost is massive. So again, I, I think it's really funny to me that, you know,

The basic ideology of libertarianism of, in having this individual freedom to do things in a voluntary way so long as it doesn't result in a immediate harm to somebody else, I think the, the common saying is, "Your right to swing your fist ends at the tip of my nose," unless you can demonstrate to me that there is immediate harm that inscriptions are bringing that we must stop and that is existential. I remain unconvinced that it's a big enough problem that we have to, you know, spring forward and act, especially if the cure is potentially worse than the disease.

I see. Now, The argument I've seen from people is, okay, all this spam on the chain is making Bitcoin worse as money, and for that reason, people should try to work really hard to stop it, and, should i-implement filters or potentially consensus rule changes to stop these things, and I guess the other, they, they might layer on another level of argument to say, well, some of these miners are short-term focused, they're not thinking about the long term, and it's on them in their view as the node runners of the network, let's say to, I don't know, some of them see that as teaching the miners what is appropriate monetary transactions, other people might frame it more like You have to sort of defend the monetary use. That's, that's as I'm trying to understand it. Maybe people say, "No, Stephan, you're strawmanning them," but try and respond to that at least as I've- Sure. Yeah, so I'll, I'll

try to engage with that, you know, a-as best as I can. So I think one of the contributing factors here is actually what, you know, Lightning Labs has been building. I think a great portion of why we don't see as much on-chain activity today is

Edges of transactions that ordinarily would have happened on chain, and that's why we're seeing blocks that aren't consistently full, that's why we're seeing one sat per byte fee rates. You know, if I got into Bitcoin yesterday, I think the first question I would ask is, for a such a widely adopted network that's used for monetary transactions, how come it's so cheap? Right? Typically, when you see lots and lots of demand for a commodity, you see the price go up. Block space is no different, it's a commodity. So if the price of that commodity is low, that communicates A large amount of supply relative to demand, and that there is an insufficient or, you know, not robust enough fee market. I think for number two, the easiest explanation for why we don't see a robust fee market is simply because a lot of people use Bitcoin more as a store of value than a medium of exchange, and that's not a coincidence, right? Only recently did we see that Square had rolled out their integration to allow taking Bitcoin for merchants, and also, prior to Lightning becoming a thing, this was even something that was a sticking point for me, which was- Why are merchants going to take, Bitcoin when they're gonna have to wait several confirmations to know that it's actually in their wallet and that I'm not gonna go and double spend them and, you know, run off with the shoes that I just bought and also the Bitcoin that I supposedly paid them? once Lightning got introduced, you know, it, it created a very different UX for merchants, and I think just as I mentioned before with there being a latency period, a lag before features are going from existed to adopted, that latency has created a, a bit of a lull. On chain, where there is a lot of activity from people learning how to use Lightning, a lot of people who are spinning up their routing nodes, a lot of merchants who are also trying to figure out how to take Lightning, and therefore creating a downwards pressure for how much on chain activity there is, and then subsequently, miners are going to be trying to look for fees in any possible way that they can. I remember one of the most prevailing, you know, conspiracy theories out there was that Casey was paid off by mining pools in order to create a demand that was exogenous for transactions on chain. Because there were so few that were happening. but in the long term, I think that this will be solved through aggregation. So what do I mean by that? Obviously, if, you know, Stephan, if you and I were transacting on chain, let's just say that we lived in a world in which Lightning didn't exist, and we went out to dinner, we had a few drinks, and the bill ended up coming out to about a hundred dollars, and I wanted to send you that money that I owed for my portion of the bill, I could send you those fifty dollars worth of Bitcoin And if we multiplied that by, let's say, the transaction volume that Venmo enjoys, I would expect the on-chain fees to sit somewhere around a hundred sats per vbyte, maybe even higher. that could translate to a fairly expensive transaction where it might even be more expensive for me to send you Bitcoin on-chain than to do a wire transfer and pay the thirty or thirty odd dollars that my bank would be charging me. That, in my opinion, would be a failing of Bitcoin, right? However, it would also be demonstrating that the free market for block space is is functioning properly and it is healthy. So what's the solution to this? If you and I can't transact on an individual basis and sort of recreate a Venmo-like peer-to-peer payment system, what is there left for us to do? I think that one particular path would be ARC, right, where you've got these systems that build on top of Bitcoin as a layer that aggregate people's transactions, making them off-chain with a possible unilateral exit if they need to go back on-chain, but allowing them to save fees in the interim. Then it might not be so So insane for me to pay one transaction, which might be expensive, to board the arc, do a bunch of transactions, hundreds if not thousands of transactions on the arc, and then finally, if I, you know, lost my conviction in Bitcoin or if I needed to sell some of my Bitcoin for fiat and the exchange that I'm using doesn't take ARC or doesn't have ARC integration, then I might pay a second transaction that's expensive, and you might be seeing a similarity here with Lightning. I think all of these types of scaling systems, these types of layers, would allow there to be a robust fee to still happen, we just have to take a more efficient engineering approach here. Rather than having individual users submit transactions and paying fees on an individual basis, on a per event basis, we would instead have them get onboarded to a layer two, do all of their transactions or at least a majority of them there, saving tons of fees in the process, and then maybe paying one exit transaction worth of fees. In that sense, I think it's very easy to compete then with traditional banking, which can easily cost three percent of the volume to the merchant, right? And can also cost To merchants significantly more through things like chargebacks as well. I think if we're doing transactions with merchants on systems like ARC or systems like, you know, Lightning, then it's much more likely that monetary use cases will prevail and be protected while also having a robust fee market that naturally is like an immune system to spam, right? Because as a spammer, you're not here to try and compete with monetary transactions, you're trying to find the bottom of the barrel fee rates, you're trying to buy up the block space that is very, very cheap. You're, you're, you're Okay, ASIC miner, in terms of buying electricity, right? ASIC miners don't go out of their way to operate out of jurisdictions that have very high electricity costs, no. They seek out very low electricity costs, in some cases, free electricity costs, if they can get it. If they can partner up with a hydroelectric dam, if they can find a natural gas deposit and bring their own infrastructure and run their own generators and generate their own power on site, they're going to do that instead. Spammers are no different. Spammers are looking for bottom of the barrel fee rates, they're looking for Transactions so that they can get into blocks at some point in the future, but they're not necessarily super time sensitive. I will say that BR-C20 is the exception to this general heuristic. But, you know, we're, we're talking about two different kinds of transactors fundamentally, right? The spammers aren't looking at this as a, a value transfer, they're not looking at, at this as something that has a deadline that they want to get done by a certain point in time. They have a very, very, very, very, long term based approach in terms of,

Possible rate because storing data permanently is always going to be a better value proposition than paying on a monthly basis to AWS for cloud storage, right? you know, it's always going to be in my favor as somebody who wants my data to be there perpetually to pay once, and, you know, ideally pay as little as possible. so for all of those reasons, I don't think that spam is going to crowd out monetary transactions. I think it's a little bit backwards instead. I think that if there aren't enough monetary transaction demand in the market, then we see the inefficiency of the block space commodity market, which then ends up being filled by actors who are looking to purchase the cheapest possible block space. But if you get rid of the cheapest possible block space and you start sharing fees over a longer period of time, you start amortizing it, then it becomes a very small problem in the long run naturally, and you don't need to be an interventionist for that to occur.

Now, I think the, just losing my, I'm just thinking So one other point with the BRC20, as you said, I think it's-- and this is, I've seen this comment as well that inscriptions actually get priced out pretty quickly, right? Like as soon as there's real monetary demand, inscriptions are, like, it's just way too expensive for them to do that. But maybe one thing that got a lot of people angry, at least in, let's say, late 2023, early '24, around there, is that there was this whole BRC20 competitive mint process, right, which you touched That there was like a three stage process to that or two stage, I think it was like deploy and then mint or something like this. But the point is, like, there was a lot of people trying to get their transaction into the next block, and because they were, because of so called the competitive mint process, that was bidding the fees to the, to the moon, right? Like we were seeing like ridiculously high sat per byte fees, and I- Subjective, but I think that's what got a lot of the not camp people angry, and I was kind of annoyed about that too, because I thought, "Hey, like, this mon- our monetary network is being degraded." Now, of course, yes, I was using Lightning, but- There were kind of concerns that people had that, hey, it's hard for people to even start using Lightning because the fees are so high, this kind of thing. For sure. And there were-- and I'm sure you're in the Lightning world, so there was this whole argument of like, when fees spiked so quickly, a bunch of Lightning nodes just kind of forced close, and that causes other issues, you know, that kind of thing. I think some of that has been, is, or is going to be resolved with like the anchor, zero fee anchor stuff, but maybe you wanna

touch in a way that it's economically very similar to Ethereum. And I always say no die enemy. And in Ethereum's world, if you look at some of the periods of the highest fee rate spikes, it was largely due to very similar deployment contracts where you'd have a shitcoin that would have a mint function. Once the contract was deployed, people would then slam that mint function as much as possible, and as you know in Ethereum, or maybe you don't know, because you don't use it. But I, I used to, you know, have a lot of friends who were in this space

And one of the things that they taught me was, you know, in Ethereum, you can make that transaction, you can submit it, the transaction can be accepted, sequenced if it's on a L2 or just confirmed on base chain, and then nothing happens because the, the contract state is entirely enforced by what's going on in terms of ordering, right? So it, it doesn't matter if you, Stephan Livera, submitted a minting transaction on Ethereum, if I submit a transaction on Ethereum that paid a higher fee and then I ended up getting processed by that smart contract first before you, so You know, potentially high fee, because you're looking at, you're looking around, you're looking at the median fee rates that are going on in the mempool, and you're gonna pay something that's comparable, but because I paid a humongous amount of a premium over you, or perhaps I even went to a private mempool, then my transaction will get confirmed and processed first, and then I will have minted those tokens, and you'll be left with nothing and have paid the fee for nothing, right? I suspect that this sort of, interaction and, and the hype that it Is that a lot of people will use a mempool's fee rate as a proxy for activity, right? If people are getting all excited because they're seeing tons and tons of transactions and they're, you know, minting this new shit coin, that's going to create FOMO and that's going to create a demand, and it's a feedback loop, right? So I, I suspect that the design of BRC20 was very intentional. It wasn't just bad engineering, it was people who are trying to bring the same hype cycle sort of mechanism from Ethereum into Bitcoin. And yes During this period of time where it reached peak popularity. But again, I think that this is a, a bit of a short-sighted way of looking at the problem. I think that in order to ascertain the true harms of a system like this, you have to zoom out and look at the longer term impacts. And today, BRC twenty is, is a shadow of its former self, it's a husk, even, right? and one of the reasons I think this is the case is because the more hype you drive and the more losers you create, losers in the sense of losing economic value

The less sustainable it becomes. And just like a Ponzi scheme or tulip mania, once it's over, it's over. It'll be a long time before you have to deal with it again. In some senses, I think it's actually better for us to get the pain over with, to sort of front load that pain, as opposed to if BR-C20 had been better engineered. Let's say that instead of using this competitive minting process, right, there was a more deterministic way of going about it. Maybe there was like a sequence number that you could assign to yourself during the mint

Sequence number six, you could pay one hundred satz per vbyte getting sequence number seven, and it wouldn't matter if my confirmation happened in a timely manner or not, both of us could get, you know, the shitcoins out of that contract. I think that would actually be significantly worse. It would give sustainability to the scam protocol that would allow it to persist for a much longer period of time. By contrast, with the amount of people that were burned by BRC twenty, I think that inherently made it less popular, it made it have less staying power, it made it more unpopular. For the spammers, for the scammers, and as a result, what we see is that today, what prevails is the solution for spamming that has the lowest friction, that has the lowest possibility for you being burned, which is inscriptions, right? And even inscriptions wasn't perfect. Inscriptions had a problem in which there was a non-standard transaction that, paid to a nonexistent, or paid to a zero sat output, and that broke its ability to track how an inscription would move because of its, its FIFO processing logic. So as a result, there was a- It was a schism in the inscriptions world where ORD had to be updated by Casey to have the concept of a cursed, cursed inscription, right? So even inscriptions were thrown off course by non-standard on-chain activity, and there were some pain points that were introduced. But because inscriptions are a pain-minimizing protocol, I predict that they're staying power is significantly higher, that they'll be around for a lot longer compared to these scammer protocols that are trying to bring in a one-to-one ergonomic, you know, you know- Usability from Ethereum that is trying to approximate, if not outright, bring that experience straight from Ethereum to Bitcoin, which is, again, why I include that as part of my heuristics for, is this transaction spam? Who is making this transaction? Who is designing this protocol? Is it a Bitcoiner? Is it an Ethereum user? What is their goal? What do, what, what do they want to accomplish, right? With me, I think I look at inscriptions and I see a bunch of idiots who are, who love to trade cards back and forth together. I have a lot of friends A rare Pokemon card trading amongst themselves. Some of them are even so into it that they have cards that are worth thousands of dollars. Do I think that that is idiotic? Yes. Am I going to go out of my way to unilaterally try and, you know, destroy the trading card market because I'm on some sort of crusade to exert my moral, you know, imperative view onto- These people, absolutely not, right? It is just a market, it is filled with willing participants who are doing this on a voluntary basis, and so long as they're not directly creating a harm to the commons, I don't think that there's any real reason to, to do anything, right? Just sit back and let the problem take care of itself.

Now we're talking about fees, what about other costs or impacts on node runners, things like hard disk drive or SSD cost or increased internet, like increased bandwidth, right? Because yes, people could argue, look, in 2017, we, the community or we, the node runners, whatever you wanna call it, we, the network, agreed to SegWit, which obviously- allows for the possibility of a theoretical maximum block size of four MB, four megabytes, four million weight units, whatever, but actually in practice, it was meant to be, it would come out to be more like one point six, one point seven megs, something like that, and maybe we could argue because of inscriptions and some of this other spam It's now more like two and a half Megs, and sometimes we get these larger blocks. and o-obviously there's, you know, a, an increased kind of hard drive or SSD cost and increased internet bandwidth. so is that An impact of spam, a negative impact.

Sure. Let's start with storage. So storage, as I mentioned earlier, fol-follows a power law decrease in price and increase in density. So because Bitcoin has a linearly sized, you know, growth rate for the blockchain, number one, I think it's highly predictable. So if you as a user are very serious about running a node, then I think that you should be thinking about what the system requirements are for running that node, not only just this point in time, but also going into the future, that it is linear and predictable. Means I think it is fairly easy for you as a user to prepare for hardware upgrades that you may need to do in the future. So if you're running an Umbrel node today that has two terabytes of space, you can very easily calculate how much more space the blockchain is going to require over the next ten years and plan accordingly. Now, setting aside that hardware itself is getting cheaper, that storage is very accessible to the average user, I wanna bring in my own personal use case, and how I run my nodes. So under my desk here, I've got three Minisforum X30 By no means bleeding line, bleeding edge rather. They're not top of the line, they are definitely slower than the desktop computer that I'm using to speak with you, but they run Bitcoin Core v30, Knots, and Libre Relay just fine, and each one of them cost a hundred fifty dollars. I run multiple nodes because I'm a developer and I like to test different configurations. I like to put them into, you know, little reg test networks and pit them against each other and do all sorts of tests, but the average user is only going to need one node. So a hundred

relatively large SSD some years in the future is going to bring you to about three hundred and fifty dollars, and that's if you wanna build a purpose-built system. For everybody else, you can get a Dell Optiplex for about a hundred bucks, you can get a hard drive for about a hundred bucks, that's gonna be a two hundred dollar expenditure, and you're gonna be able to run a Bitcoin node, albeit a slower one than mine, for many, many years into the future. I don't think that this is really a realistic problem, for the vast majority of users, Electronics are considerably more expensive, like Brazil, where there's a significant tariff for any imported electronics. And to that, I say, I think the solution there is that we must continue to optimize Bitcoin Core to be able to run on lower end hardware, but we must not be behest to it. We can't let that be a sort of hard requirement in terms of, we're not going to apply optimization X because it's not going to help out somebody who's running on a Core 2 Duo from like two thousand six, right? We have to, we have to draw the line somewhere. You see Development. I'm a core developer for Blixed Wallet. We have a explicit cutoff for the oldest device that we're willing to support. And what we found is that even with that cutoff, people who are in Cuba, people who are in Latin America, they're still able to get their hands on devices that are a couple of years old, right? So even if hardware is expensive, if they're going to be using this as a replacement to their bank account, they can afford to secure a device, a mobile phone at the very least. They can use light client protocols like Neutrino or Utri You know, a coincidence that Vintiem, for example, a nonprofit in Brazil, is funding the development of things like Floresta, which embeds Utxo to give you like a Bitcoin Core like RPC locally. I think that a lot of people have this like very cypherpunk manner of looking about this as, "I want, the case to be that if there's four million or four billion rather, users on Bitcoin, that there should be four billion full nodes out there." I think that this is a little idealistic and romantic, right? At a certain point, the rubber pragmatic and, you know, you're going to have Uncle Jim type situations where a trusted member, a pillar of the community, runs a full node on behalf of maybe a hundred users, and then they plug into that through light clients or Electrum wallets, and there's a certain trade-off that's going to be made so that you can have this wide amount of usability, even if it's not the fully self-sovereign deployment of Bitcoin that people who are living in a first world country would easily be able to afford. So that's my first point is, I don't think that the hardware will bottleneck here. I think there's a lot of different structures that you can use that will allow communities to adopt Bitcoin in a way that doesn't require every single user be able to afford the hardware. The second point that I have is regarding connectivity. So there's this law that, is about internet connections, and it, it is Nielsen's Law, which states that a high-end user's connection will increase at about fifty percent per year. In Massachusetts, where I reside, good old Bean Town, I have gone from living in a place that had a highest speed internet con- connection of a hundred megabits to having a five G at home internet that maxed out at two hundred fifty megabits when there was not a lot of traffic, to now having fully symmetric gigabit fiber, and I pay the same amount per month as I have for each one of those plans. So the organic growth of network connectivity over time, I think, will also mean that running a Bitcoin node And having some extra relay requirements isn't going to be a massive, you know, burden on people. The one thing that I, I've seen online that has been a point of contention is that, you know, back a few months, I don't remember exactly what the time is for this, there was like a, you know, there's like a, a, a bad actor, should we, should we call him, that wrote a node list tool that would fake IBD downloads specifically from Knots nodes that were under a residential IP block, and the goal was to- Basically, you know, troll people who had a data cap on their Comcast internet and try and deplete it so that they couldn't run their Nodz node anymore. Now, obviously, I don't condone this behavior, but it does point out a very interesting interaction for people who are in areas that don't have the viability of using a good ISP. my sort of response there is that I think in the future we will see a great degree of penetration for systems like Starlink and internet providers that aren't able to enjoy a regional sort of monolithic monopoly, and that they will disrupt this enough that running a Bitcoin node will be fairly trivial, right? We, we saw with the recent rollout of Starlink direct to mobile handset that it is entirely possible to roll out connectivity networks that don't require new hardware. But even Even if they did, you know, Starlink has been subsidizing their dishes for quite some time now. You can get like a, a mini dish for like a hundred bucks, which is close to what you would pay on a monthly basis to Comcast if you're renting their, router, and be able to get high-speed internet with no data caps, right? Even their cheapest plan is five dollars a month for five hundred kilobytes per second continuous, no caps. you may have seen on Twitter that SuperTestNet had posted a calculator for how much more bandwidth. A core v thirty node uses relative to nots. What you might not know is that he made that calculator after having a debate with me regarding what the worst possible case scenario was, and that worst possible case scenario came out to about ten to eleven dollars per year, and that was with the calculation of using an Alaska ISP where there is a monopoly and you have a data cap in place where you pay per gigabyte, right? So when you factor all of this together, the marginal cost of having more transactions on the network is really just close to to nothing. And as we get additional penetration from competitors in the ISP space, as we get better connectivity in general, because cities get better connectivity, which then means that there's more budget available to connect places that didn't have connectivity before, we would see that over time that connectivity will outpace the amount of connectivity requirements that Bitcoin will grow over time, if that makes sense.

right. So in simple terms, the blockchain is growing linearly, but internet and- And and- Even, even beyond just like the storage

aspects, I would argue that the relay amount of data is also growing at a linear rate, right? Because at the end of the day, what is the point of relaying trans-transactions around that will never ever be confirmed, right? There, there will be a convergence over time where relay policy will reflect what transactions are routinely getting mined. So for example, in a hypothetical scenario, let's say all of the other mining pools that are mining subset fee rate transactions adopt Mara's threshold of zero point five, what I would observe is that over the long term, Have relay policy be around zero point five, because relaying transactions that pay zero point one that are never ever going to get mined would be a waste of bandwidth, and people will react to that. And if people don't react to it, then maybe core will react to that and tune the defaults to be more in line with reality. you know, this just goes back to what I was saying, is a lot of classes of problems, they don't require human beings to constantly be tinkering, to constantly be there twiddling their knobs and trying to figure out like, what is the optimal set of

Get some data, inform your decision off of a captured, you know, observation over time that gives you a better picture of what's actually going on instead of trying to, okay, I'll build this like potentially imperfect model in my brain, and then based off of my mental model, I'm going to try to dictate some set of rules that make sense to me. I think a data-driven approach makes more sense, but that also means that you have to be a little bit more hands-off to gather that data in the first place.

Yeah. now another big, I guess, argument or point that comes up in this debate is If a lot of people run, like in their mind, they see it as if a lot of people run not and filter the spam, it's gonna not stop the spam, but it's gonna significantly reduce the spam or make it more costly or make it take longer for the spam con- transaction to be confirmed into the blockchain. What's your stance on that? Is that true? How, how true is that? So let me address

each one of those. The first one being cost. I think a lot of people get this idea because in the past, Peter Todd and, you know, maybe a couple of other people who wanted to demonstrate that you could bypass filters would use services like Slipstream, which obviously have a premium associated with them, where you have to pay them a fee in order to make them take the transaction out of band, right? And so a lot of people created this, you know, linkage in their head, they're

like, "Oh, okay whole road in order to get to miners. Unfortunately, this isn't accurate, right? you know, at that time, a lot of miners hadn't been peering with Libre Relay for one reason or another. Peter ended up, you know, sending them some DMs, writing them some emails, whatnot, and these mining pools started peering with Libre Relay, which obviously doesn't have any marginal cost associated with it because it's basically just a parallel relay network that exists alongside the, the, the public one. I would even say that it's part of the public relay network because it

Here with Libre Relay. so that's, that's it for the cost one, right? There is no marginal cost. My upturn bot demonstrates this really obviously, by setting a static zero point five sat per vbyte fee rate. it never adjusts its fee rate paid. It doesn't pay, you know, like what mempool spaces fee recommendations are. It doesn't pay any less, it doesn't pay any more. It always pays zero point five sat per vbyte. And relative to the average person's transaction, who's probably still using a wallet that pays one sat per Actually represents a discount in how much I'm paying on a fee rate basis, right? Now, if you wanted it to be a perfect comparison in terms of cost to inscriptions, you would have something that is greater than one hundred and sixty V bytes in size, and then I would have to be paying a zero point two five sat per V byte fee rate to account for the four x witness discount, right? But without getting into the tech-- the technical weeds there, if we're just comparing the op return from my op return bot to a monetary transaction that's paying one sat per V byte, I Less, right? So that's, that's a, that's an objective, empirically observable rejection of the theory that filters work to increase the cost of spam. The second one, that's often talked about is the time to confirmation, and this is something that a lot of people get conflated with, the amount of time that it takes for a transaction from my Operturn bot to be mined. They, they look at mempool dot space and they say, "Oh, well, we saw this transaction one hour ago and it took like an additional hour to get mined, right?" Two hours to get mined, that's definitely an increase in time for how long it would have taken a transaction to get mined, ignoring the fact that it's paying subsat fee rates, right? If the bot was modified to pay one sat per vbyte, and in fact, I, I may consider adding a feature where you can choose between the two of them, if you want to choose to pay zero point five sats per vbyte or one. if it were paying one sat per vbyte, given that the mempool was having a median around that, it obviously would have been confirmed sooner,

Of the miners out there are willing to mine subset fee rate transactions in the first place, and also, that happens to be the same proportion of miners that are willing to mine non-spam transactions, right? So you could make the argument that because you would have to wait a little bit if one of those miners had recently mined a block just by the rules of probability, you might have to wait a little bit longer before you can get your transaction mined. My counter to that is, well, again, look at the trend, right? There might be only three mining pools that are consistently mining these types of

Going down. And if TX fee rates don't reflect people being willing to pay more right away, miners are going to be more desperate for revenue. So Foundry, which doesn't mind such transactions, might be willing to let it go if you're paying one sat per vbyte and you have a non-standard transaction, right? You know, other mining pools, even ones that are facilitated through Datam, that are willing to not take these types of transactions because a majority of their revenue comes from subsidies, might have Their calculus here shifted a little bit, once that subsidy gets smaller and smaller, right? They'll take anything that they can get, they'll become more desperate. And I think that the-- if you look at the trend and you, you think about the incentives that are at work, the most likely outcome is that this situation is the worst that it will ever be in regards to getting a non-standard, you know, sub-sat fee-paying transaction on chain. I think it will only improve from here on out. I think there will only be more miners that will join in mining these types of transactions. I think Will become more desperate for fee revenue, and I think that talk is incredibly cheap when a majority of your revenue comes from a subsidy in the first place, right? we've seen this play out with the electric car market, right? EVs enjoyed a substantial subsidy for a very long time, and then the government got rid of that subsidy. What happened? EV prices dropped because consumer expectations aren't going to change just because a subsidy is gone, right? Consumer expectations will remain much the same. They're going to want to spend relative same amount of money to buy this vehicle. In the same way, I think people who purchase block space, their expectations aren't going to instantaneously adjust over time once the subsidy decreases. They're not gonna be thinking to themselves, "Oh, well, the miner's getting paid less from the subsidy, so I've gotta increase the amount of fee rate that I'm paying." There's gonna be a latency period, and during that latency period, miners will experience the greatest amount of temptation to start relaxing some of the rules of policy. And, you know, there's a lot of talk from the no-SPAM camp that, you know, the way

You know, shaming the mining pool and saying I'm not going to hash to this mining pool if they mine non-standard transactions, but I just don't think that this has any real impact on an industry that has quite literally millions and millions of dollars of revenue, right? Just to really drive this point home, many Bitcoin miners actually make more when they shut off their miners from the deals that they've signed with power companies than they do from mining Bitcoin, right? So unless that changes in the long run, I think that miners are basically always going to be acting according to their incentives, which is how do I pay my electricity bill, how do I pay my employees, all of those expenses are gonna be denominated in USD, they're not gonna be denominated in Bitcoin, right? And, and for that reason, people who are saying that a farmer's not going to kill the golden goose because it continues to lay these eggs and it wants this golden goose to live as long as possible, are ignoring the factual realities of what- Miners actually have to deal with. They have to keep their operation running, especially with these, you know, razor-thin profit margins, especially with how hard it is to secure financing. You try to go to any bank and use Bitcoin as collateral, and what they're gonna tell you is, unless you've had that Bitcoin sitting in an exchange and has never been touched, never been withdrawn to a, a, a hardware wallet or any form of self-custody, they're not willing to touch it with a ten-foot pole and regard it as assets toward, towards things like securing a loan, right? LTV. And so consequently, you're dealing with businesses that are having to, having to provide a certain amount of liquidity just to keep their day-to-day operations running, right? If they have to forego a significant portion of their revenue to make some people on the internet happy, it's just not going to happen.

Okay. And what about the, is there any increased cost or time of having to install LibreRelay or not just the miners themselves, but even the broader, let's say, spam ecosystem of having to hook up with LibreRelay instead of using Core or whatever else?

Absolutely not. So much in the same way that if I wanted to craft a transaction, locally on my computer, which, you know, I, I need a node to do that, or at the very least, I need a library that can craft To Bitcoin transactions, let's, you know, just say that for the sake of argument, I've already crafted this Bitcoin transaction, I've got the hex string, right? What do I do in order to minimize my friction to broadcast to the Bitcoin network as it exists today? Maybe I go to block, Blockcypher dot com, maybe I go to mempool dot space and I click on the broadcast transaction option, I paste in the hex representation string, and I click broadcast. You can do the same exact thing with Libre Relay. All it takes is somebody running a mempool space instance or running an API Broadcast that transaction on your behalf, right? If you continue down the chain of abstraction, you would get something like my operator bot, where you don't need to know what a Bitcoin node is, you don't need to know what RPC is, you don't need to know what a transaction looks like, you don't need to know what an operator is. All you need to know is how to type text into a box, click a button. And how to pay a Lightning invoice, and, you know, hypothetically that part could even be abstracted away as well, if you have a credit card processor, for example, right? If I wanted to support fiat payments, which obviously I don't, you know, I work in Lightning, I could just add like a Stripe integration, and then you don't even need to know what a Lightning invoice is, you don't need to know what Bitcoin is for that matter. You just need to know that you're trying to put a message somewhere where it's going to be stored forever, and this be within your purview. You don't need to run a Libre Relay node, you don't need to know what it is, you don't need to know what a node does, you don't need to know how transaction relay dynamics work, and you certainly don't need to know which miner is going to pick up on your transaction. Like the, the most ridiculous argument that I see online a lot of the times when I post an example of a non-standard transaction is, "Well, you had to go out of your way, you had to go find a miner, you had to go hit them up on The first reaction to that is, well, that's just not true. I created a transaction in very much the same way that I would create any Bitcoin transaction, and then I programmatically sent it to the network using an RPC, which you would be using if you were building this application and built on top of Bitcoin Core instead. And in fact, I do plan on removing Libre Relay from my stack in the next month or two. I will just point my operation at Core v30 once it's attained enough adoption where I don't have to worry about, you know, manually choosing my Here's, I'm gonna switch out the backend, and there will be absolutely zero marginal friction. and, you know, for what it's worth, the OpReturn bot is open source, so if anybody wanted to do this today, all they'd have to do is spend a little bit of time learning how to deploy this, and then they could get it running. If, if I so desired, I could create an Umbral app where it would be a one-click install for you to install the OpReturn bot on your Umbral node, and then you could do all of this within the to me as a service, you wouldn't have to run Libre Relay, 'cause again, once Core v30 gets enough adoption, you know, there's this tipping point at which it becomes very reliable to send non-standard transactions, It's just going to basically be a self-improving situation, right? Now, of course, there's still things that I wouldn't need Libre Relay to do, if I wanted to do weird stuff like having, you know, a one set output, for example. I'm not in the business of harming Bitcoin, right? That's why I do my data embeds in OpReturn. It is the least harmful way of embedding data on chain. I want what's best for Bitcoin. But if I wanted to create a more subversive bot that, you know, created one set outputs, I would still need Libre Relay for that, but I would argue that that is a good thing and also that it enforces that people care much more strongly about a demonstrable harm, which is bloating the UTXO set, than embedding data in op-return, which is pruneable, never enters the UTXO set, and is basically a nothing burger if you haven't been listening to people who are trying to rile you up about things like CSEM risk, which have existed in chain for quite some time, as of, seven- Years ago, I think people were using apertus to embed illegal content on Bitcoin. now proponents of knots like Luke and Bitcoin mechanic would have you believe that a court would have a meaningful distinction between a non-contiguous embed like an inscription, for example, and a contiguous embed like an operturn. And I've tried to steelman this on several occasions. I've tried to think to myself, okay, Alice isn't a trial and Bob isn't a trial, they have the same exact cSAM file, except Alice embedded it using an operturn and Bob- Bob embedded it using an inscription, and there's no scenario, I've been through every possible scenario in my head, there's no scenario in which the prosecution comes with a different outcome between these two trials, right? so I, I think that a lot of the argument there is just-- And that question is probably worth

exploring. There's this kind of, this argument that Luke seems to put out, which is sanctioned. They're saying somehow, as of V thirty, it's now magically sanctioned. I, I-- To me, I'm, I don't, I, I don't quite understand even there, you could also, also talk about the consensus limit, which is one megabyte, not just one hundred kilobytes in V thirty, and that's been in place, you know, much longer than just V thirty. I think this goes back to our, our, our philosophical differences, right?

I think this goes back down to the, the, the philosophical difference of being someone who uses teleology or thinking about it from the perspective that everything is designed with a purpose as the first and foremost sort of starting point, that the, the purpose is the seed, and that you grow the usable tool versus instrumentalist, which is that you're building a tool and then you ascribe a purpose to it. I think that people like Jimmy Song, Luke Dash Junior, Bitcoin Mechanic, they're teleological, right? They say that the sanction is because op-return is happening in a field that is for arbitrary data. They're saying that, you know, for example, scriptpubkey doesn't have that as its explicit purpose, that scriptpubkey is used for, you know, a, a different purpose relative to arbitrary data, that you have a more obvi- Obvious embedding of data. However, I think this overlooks the reality of how cases like this are prosecuted, right? A judge isn't going to sit there and open up a hex editor and look for C-SPAN. No, they're going to have a computer forensics company look at a disk snapshot and say, okay, you know, in, in many cases, this isn't even about C-SPAN. In many cases, it's about corporate espionage where somebody has stolen documents that are sensitive that should have never left the perimeter of an enterprise network and, and, you know, maybe they're Another company. It doesn't matter, right? In those court cases, they hire a computer forensics expert who then looks at a snapshot of the disk and says, "Okay, well, here's a piece of a file, here's a piece of a file, let's glue those two pieces together. Oh, here's some other pieces that can be glued together, and they can reassemble a file. And that's not considered by the court to be a reconstructed or transformed piece of data. It's just a file that had been fragmented across different parts of the file system. And indeed, if you

In onto the SSD. If you zoom in onto the hard drive, the bits and pieces of a file don't exist right next to each other, right? They are distributed in physically separate, isolated locations, and what your hard drive, what your SSD does is it stores a lookup table of where those locations are, and then it says, okay, here's a file, and here's all of the sectors on your storage device that make up that file, and then when you go to read that file, it uses that lookup table to reassemble The file on the fly. How is this any different from an inscription which has within a single transaction multiple data pushes separated by a opcode, right? If you strip out the opcode and you look at this data structure, it's contiguous data. If you don't strip out the opcodes and you look at this data structure, it's a lookup table. In either way, I don't think that this is like a, a good faith argument. I think it's just intended to confuse people who don't have necessarily a very technological, you know, technical background who don't know about things like LBAs and sectors who perhaps are easily deceived or, you know, misled into thinking that there's any real world difference between the two. If you have CCM on your disk, it doesn't matter what sort of encoding you use, it doesn't matter how you've fragmented it, it will be prosecutable, right? And the fact that CCM has existed on chain for over seven years in Bitcoin with no prosecutions is a pretty good data point that courts understand that much like the protections afforded to Yahoo with Section two thirty in the case Doe v. Bates, that you aren't Are a neutral infrastructure provider and not somebody that they're interested in coming after for prosecution, right? In the Yahoo case, Dovey Bates, Yahoo had like a, a community forum type product where they allowed people to discuss, various news topics and some terrible people created a group that they used for sharing CSAM and the prosecution moved that Yahoo was essentially a publisher in all of this and should be prosecuted to the same extent of the law as the people who created the content. And what the court ruled was that no, we don't go after neutral infrastru- Infrastructure providers because they didn't facilitate the creation of the content, and we can't hold people who are running infrastructure liable for the contents that their users are producing, right? If, if we applied this to ISPs, every ISP on earth that has ever served somebody who has sent CSAM over the internet would be held liable and prosecuted to the full extent of the law. The fact that we haven't seen that, the fact that section two thirty as a protection hasn't been repealed, means that the government understands the difference between someone who has relayed a piece of data that they themselves didn't create or facilitate or take part in creating or transforming, and they can legally distinguish that from a person who is the origin, the nexus point, and creating this illegal content. But, you know, at the end of the day, I, I understand that this is a lot of nuance. You know, not a lot of people out there are gonna be reading case law for fun, and even less people out there are gonna be trying to relate it to something like Bitcoin, which is pretty unprecedented, right? You know, with the Yahoo group, like we, we've seen content And, and arbitrary content specifically from users, and we've learned that, that is something that we deal with, you know, like when Facebook first came out, people were posting like gore on Facebook because Facebook didn't have the necessary moderation to keep that kind of content in check. So we're all very, very aware of how that scenario plays out because it's a centralized platform, we know how that works, right? And more importantly, when that type of content is detected, Facebook very quietly gets rid of it. And so to a lot of people, the distinguishing factor here is that Bitcoin is immutable. Storage, you can never really delete it, right? But I would counter that by saying that it doesn't change the rules by which the courts ruled the case in the first place, right? There's no point in their ruling that said this is contingent on you deleting the data. There's no point in which they said the type of storage that is being used, the type of relay, the type of sending of data is what makes you complicit or not complicit. It was what role do you play? Did you create the content or not? Did you participate? In facilitating the transformation and production of that content, if you didn't, if you weren't the user that produced and sent that content into the system, then you aren't culpable. and I, I think that that will be the doctrinal way that we approach this as the courts and as the law catches up to Bitcoin as it exists, because again, it's very new relative to everything. But, you know, whenever we look at law As long as there's not case law precedent that exactly matches, the best that we can do is looking at similar cases and trying to come up with, okay, what are the guidelines? What are the standards by which this ruling was reached? And how can we apply that, to a system that is maybe not, you know, a one-to-one mapping, but shares some similarities in terms of what role that node runners play? even, even Giacomo, who is a self-described, you know, neutral party in all of this, says that the only reason he doesn't run He's not scared of things like C semrisk, and this is coming from somebody who's close friends with Luke, right? You know, I, I think that it's important to contextualize these things and keep them within the realm of objective reality instead of going to this hysterical place where, you know, people are just getting extremely stressed out about this threat that doesn't actually exist, at least not in the form that, you know, the people that they've been hearing it from. I guess

you'd put it as, "This is an already existing risk, it's not a new

risk back surfaces to Bitcoin. All it did was align consensus with policy, which is something that I've always believed is sensible.

Now, another big Not's talking point, Not's camp talking point is this notion of, "Oh, inscriptions could have been stopped in twenty twenty-three, right? Their, their idea is, well..." Okay, Luke put in a PR in, I think, September twenty twenty-three, which hypoth- if, if it w- I think it was rejected, but if it was accepted, it would have come in in December. but by then there was, you know, a lot of UTXO creation had already happened by then. But I think he's made this argument, well, look, Core could have done it before, and that's why, you know, there are arguments made that, oh, Core are either negligent or corrupt, that they could have tried to stop inscriptions by

Make data carrier size also relate to that. Do you have a view on that? Was that actually feasible? Would it have actually happened that way or how would-- or do you think it would happen some other way? I think it's

fairly unlikely that anything would have really come about from trying to block inscriptions. I think maybe the most charitable explanation that I have here is that if you introduced enough friction in the beginning, you know, early parts of when inscriptions were first starting to take hold, you might have been able to induce a form of infant mortality where it never really got to get to A place where, you know, it, it has built up enough momentum that there'd be enough drive for people to update Ord. but unfortunately, I think that this really doesn't hold up to scrutiny. earlier today, I think maybe it was yesterday, there was a discussion with Super Testnet, and the argument was basically, what if we just soft fork every year to ban the type of inscription data envelope, right? Right now, we use like the OP-IF, envelope, and that's why it's part of BIP four four four. What if we just Doing that. So if we ban OP_IF and then Casey updates the envelope to use like OP_DROP, for example, where you're just pushing elements onto the stack and then dropping them, what if we just soft fork again and then we ban that and then so on and so forth in perpetuity, right? Like annual soft forks essentially to get rid of spam and purify the chain? I think that there's an asymmetry here that a lot of people aren't taking into account, right? When we, when we talk about, the shitcoin industry, when we talk about things like MetaMask, when we talk about like Rabby Wallet, when we talk about all of their ecosystem, they're built on essentially common core libraries, right? Each one of those wallet developers isn't re-implementing the wheel, they're not building a whole bunch of stuff on top, they're mostly building UI stuff. All of the consensus, all of the code, all of the transaction crafting All of that is handled by shared libraries between all of them, which means that they benefit from having a central location where they can update all of the logic and then be able to work around, you know, the, the new consensus rules that you've rolled out as part of your software. We can apply the same thing to Ord. Casey, if he wanted to, could drink a whole bunch of coffee and do an update to Ord on a weekly basis, right? He would be able to trivially outpace the update rate that Core ever could, assuming that Core was, you know, willing to give Luke Dash Idea a try, we would be going down the path of this cat and mouse game, and Casey would win. Now, I, you know, it's, it's a little bit demotivating to think about, right? Because I, I think a lot of people, they, they're They, they have a good heart. They want to approach this from a perspective where, you know, somebody should do something. We, we shouldn't just sit idly by. We should try and take some action, right? But if you, if the action that you're taking is committing yourself to wasting a bunch of time and effort for a very, very temporary fix that will be undone by the next weekly update to Ord, it does kind of make you wonder if this is like a bike shedding moment, right? Where instead of shipping features that could actually benefit Bitcoin users, like Like CTV or OP, you know, with the, with the great script restoration where we can implement things like BLS, it, it does really make you wonder if like it's just sucking all of the oxygen out of the room and everybody's emphasis and focuses on this when they could be focusing on things that they can change, right? At the end of the day, you know, like with any permissionless network, you're having participants be able to jump on and start building without getting anybody's permission, right? As the name would suggest, you don't have to go and apply for a Permit to build on top of Bitcoin, which means that if somebody finds a way to do data, or, or, you know, arbitrary data embedding, they're going to do it, whether you like it or not. If you then go and try to ban them, and there's enough sufficient economic demand that they wanna continue doing what it is that they're gonna do, they're going to find a workaround. When you ban that workaround, it's just gonna continue the cycle. And, you know, quite frankly- There are some ways of embedding data arbitrarily that aren't defeatable, right? Like BitMEX research talked about embedding data in such a way that you use encrypted data with a very weak private key, and then you can grind the bytes to the private key until you find what the hidden data is there, right? There's not enough time for every single node on the network that's validating these transactions as they're witnessing them in the mempool to be able to grind those private keys. Maybe it takes like a week's time, but if the spammer is dedicated enough, they don't even need to rely on the data, they could just release the private key as well, out of band, right? If I embed a piece of data today that's a picture of my dog onto the Bitcoin blockchain and I encrypt it using GPG and a symmetric key, I could just wait a week and if nobody's figured out the key and posted the image and said, "Wow, look at this, there's a dog picture in this transaction," I'll just release the key. Maybe I'll even make a website that has a off-chain stored copy of every single decryption key for the data embeds that I've made. Congratulations, old version of an inscription, and in fact, even just the very nature of how inscriptions work illustrates this point, right? To embed an inscription onto Bitcoin, there are two stages. The first stage, you commit to a witness script, right? So at that point, all you see on chain is just you're committing to this hash. The second step is the reveal. So even if you had some means of stopping all of the reveal stages, you'd also have to go after the commit stages, which makes it a little bit more difficult, right? Because you're not able to introspect into what's Actually going on in the script. It's just a never ending race to the bottom, and it introduces potentially a lot of complexity for not a lot of gain. the other example of, of this same sort of, you know, ideology of adding tons of complexity for not a lot of benefit was this hackathon project that was a PR to Nats, that was a Lua based rule, engine, and the intent here was to allow any person to create a filter themselves, similar to how you might create a, a block rule for uBlock Origin to block ads on a webpage, and then they could share these filter rules with each other. They could upload them maybe to a central GitHub repository, and you could have some kind of auto-update process. But I think that this is also just a really interesting approach because, like, auto updates have always been extremely antithetical to the ethos of Bitcoin, right? Like, I watched your podcast with Gloria Zhao from, you know, the core maintaining team, and one of the things that she talks about is that the role of being a core maintainer is just That it's, it's closer to be, being janitorial in nature. There is no auto updates being pushed out, right? The, the HP printer on my desk, every time I fucking boot this thing up, checks with the HP servers, phones back home, and sees if there's a firmware update. What do I know about what's in that firmware update? Absolutely nothing. I'm blindly downloading a new firmware update from the manufacturer of this device, and I hate it, right? But in, in a, in a, in a, in a sense, this is like the very much- The fiat status quo for many things out there, whether it's a Tesla that you've bought that can auto-update its own firmware, whether it's a computer, and, you know, it's running Windows and Microsoft has pushed an update and it auto-updates and restarts it. you know, we've gotten so used to this concept of remotely pushed updates that we haven't stopped to think about how beautiful it is that this isn't the case for Bitcoin, right? It might be a little bit frustrating when there's a new CVE or security vulnerability that comes out for Bitcoin and people aren't An auto update would allow us to do it, but it gives you full control. You are always in the driver's seat. And by taking that away from you and relying on a third party, the logical conclusion of this is that Luke would just set up some sort of auto update server, and then nodes would, on every boot, check to see if your, you know, filter definitions are up to date, sort of like McAfee antivirus, and download the latest set of filters. And what happens if those filters are overly broad, right? You know, famously, like Luke had added a- filter to this D-gen protocol that uses an unlock time of twenty-one. What if you have a legitimate monetary transaction that has an unlock time of twenty-one and it gets filtered out, right? Like, there, there's also like the question of, and, and you know, I think there's some responsibility that needs to be shared here, but there's also the question of like, when the CoinJoin protocol for Whirlpool had a op-return that had more bytes than Luke would like, Luke asked them to change the spec, which I think is fair, right? You know, he, he reasonable to make it smaller so that it would fit. And when they explained to him that there are certain technical reasons for why they didn't wanna do that, you know, they had like a revenue sharing agreement at one point and they wanted to be able to store not only an identifier for themselves, but also a partner's identifier. And then they maybe had like, you know, twenty bytes of padding that they could have r-gotten rid of. Their argument was that even if they slimmed down this protocol considerably, that it would still be over this arbitrary limit that Luke had set, right? And again There's no particular reason why Samurai's Whirlpool service should be the one that has to move in this game of chicken, right? They, they have just as much of a claim to using Bitcoin as much as any other user on the network, and the fact that they had built out this slightly large operation as part of their protocol didn't mean that, you know, they deserved to have their protocol get broken. for this reason, you know, I, I think that ultimately filters are a nice way of expressing your node's intent. I think it is a good way for- You to contain and constrain what your individual node is going to operate. I think once you start getting into the, yes, if everyone would run this, then we could shape behavior, that's when it's starting to get a little bit delusional, because, you know, I just look at the compact block reconstruction rates, right? Like people are running very different mempool policies from one another because people have different priorities, right? One person who might wanna set data carrier size zero because they hate any kind of arbitrary data, even if they might have too broad of a stroke and, and hurt my Monetary transactions is gonna have very different incentives from somebody who's sending one hundred thousand or maybe just didn't know that it was raised to one hundred thousand and is just letting the defaults run. you know, the, the, the consequences here, the, that if you're trying to use a filter as a means of shaping- How behavior works, you're trying to make it do what consensus is there to do, right? As I, as I stated at the very beginning of the podcast, a, a filter or a mempool policy is, is just a gentle nudge. It's a nudge. It's, it's a little bit of a reminder from the nodes that, hey, if you're doing things this way and you're seeing that there's a higher failure rate than you expected, maybe you should make a slight adjustment and make it easier for yourself, and in the same, you know, process, make it easier To a miner. It isn't a hard stop, hard line policy that you're enforcing where you can unilaterally impose your will on the network unless you happen to civil attack it at the same time, right? And this is why the US government can't just spin up a hundred thousand nodes, blocking out any non-OFAC compliant transactions and bring Bitcoin to be a fully permissioned chain. It doesn't suddenly change when the subject of filtering is OFAC transactions. Versus spam, right? you know, the, the, the censorship resistant nature of Bitcoin is going to be agnostic to the contents of the transaction.

I see. now we've already been going for a while, for about two hours now, but I guess if we could just quickly cover your thoughts on the-- Now, most of our discussion so far has been on the policy side of things. Obviously, there's the consensus side of the house. Now, recently there has been the, Dathan Oehm proposed concept, quote-unquote, reduced data, temporary soft fork, I guess people were incorrectly throwing around the ta-- the title Bit four four four and that kind of- Kind of caught on as a bit of a meme, but I think technically they're trying to say it's RDTs, Reduced Data Temporary Soft Fork. Can you just give us a kind of a quick overview on your thoughts on this? As I understand, it proposes, I think, six or seven consensus rule changes, one of which is is to lower the operator size down to, I think, eighty-three bytes at consensus level, not a policy change, and like six or seven, I think six other changes. Can you just give us your quick thoughts on this? Do you agree, Where, where are you at?

Yeah, so the RDTs as put forward by Dathan Oehm, has become a little bit more palatable with time. When it first came out, it had two methods of deployment, a flag day type deployment, which we're all used to, and a reactive deployment wherein if CCM was embedded on chain and observable, there would essentially be a pre-coordinated fifty-one percent attack to reorg it out. Now, Dathan, after speaking to a bunch of people, realized that the reactive deployment was deeply unpopular, and removed that Around the legal liabilities of not running soft fork, which was interpreted by many as a, a threat to basically run the soft fork or else, now Approaching it from a technical standpoint, I think one of the things that stood out to me the most was actually based off of my own usage of Bitcoin. So Nunchuck Wallet, I'm not sure if you've ever used them, rolled out an update not too long ago that allows you to set an arbitrary miniscript, you know, spending condition sort of string that allows you to say, basically, "Alright, I love child A the most, so they'll be able to spend the funds soonest, and then I love child B the second most, so they'll be able to spend it, you know, a little bit longer from now, and child C, the furthest, right, in terms of time locks. Now Products like this have existed on the market, namely Liyana Wallet, that was one of the ones that I used back in the day to explain to my dad actually why Bitcoin was more than just peer-to-peer payments, it was actually being able to enforce contracts on chain, and you could hypothetically do away with your will, you could have your entire inheritance setup, done on chain and enforced by Bitcoin's consensus rules. Now, the, the interesting thing here is that Liyana Wallet, in their very conservative pro-approach of implementing these- Miniscript, type spending conditions within their wallet is actually not vulnerable to something that my own version of Liana Wallet is. So Liana Wallet constructs a miniscript construction which doesn't end up with an OP_IF in a tap leaf. However, my solution does. And what, what it comes down to is basically, if a tap leaf's miniscript uses only straight line combinators, the resulting tap script doesn't have an OP_IF. But if you have a branch- Spending type, Miniscript fragment, then what the compiler for Miniscript will do is it will, it will realize, okay, let's say you have like four pub keys that can spend this, these funds. What you could do, yes, and, and, and this is what Luke believes you should do, is you could create, spending conditions that each live in their own tap leaf. So you'd have one tap leaf here, another tap leaf here, another tap leaf here, and another tap leaf here. The problem with that is that by separating them out into different tap F goes from zero to one, so it actually ends up costing you more to execute in the case of having a particular pub key be used as a spending condition. So the Miniscript compiler is quite smart, and if it sees that your spending conditions align with it being cheaper, it will cost optimize for you, and it'll actually pack the conditions into one tap leaf. now Dathan Oehm's, you know, RTS Does include, to his credit, does include a exclusion for any existing UTXOs on chain that would be used for an input. However, this is where it starts to get into, a little bit scarier territory. Many people, for one reason or another, don't wanna commit funds to their inheritance setup right away. They might create a pre-signed transaction instead, and then on the activation or a, a particular, you know, sort of event that has occurred, let's say for me that that is my will, my lawyer would have a Hex representation, you know, or maybe it's a QR code, I don't know. you know, it could be either one of those. And upon my death, he would be instructed to scan that QR code or take that hex string and paste it into mempool space, thus broadcasting the funding transaction, moving the funds from my cold wallet into this set of conditions. At that point, you know, the time locks would start counting down, so maybe my wife has first dibs, she can spend the funds after a hundred blocks, but if my wife is dead, I want my first child to That's locked after two hundred blocks. In that scenario, I wouldn't enjoy the exemption because this would be a pre-signed transaction. The UTXO wouldn't have existed on chain prior to the soft fork's activation height. So in that situation, this would represent a freezing of my funds. When my lawyer goes to broadcast that transaction, assuming that the RDTs is activated, he would simply get an error. He would have to wait one year Until the RTTS, you know, potentially doesn't get renewed because it is a temporary soft fork, to broadcast that transaction, to put the state on chain, and then my wife would have to maybe wait a one hundred block time lock, anyway. So suddenly I've gone from my wife waits one day to be able to spend these funds to my wife has to wait one year and one day to spend these funds. This is obviously confiscatory, right? If my wife requires these funds in the meantime, and, you know, let's say that, you know, because I'm such a big Bitcoin Very few funds in our fiat bank accounts, she might be out on the street and starving because of the RDTs, because of this, you know, crusade against spam, it's actually worsened the outcomes for monetary use on Bitcoin considerably. And pre-signed transactions aren't weird, they're not uncommon, they're used by many types of people. Another example of a, a transaction that would be affected is, one that violates the rule for how deep the tapscript tree can go. If you're doing a six of eleven multisig and you're doing it in the cheapest and most efficient way possible, you won't be able to spend funds because the, the depth of the tree would exceed the limitation that's outlined. So the RDTs has a huge amount of confiscatory risk, you know, and how you define confiscation, I think, could be either more liberal or conservative, but I would say at the very least, we could, we could agree to disagree that even if it's not confiscatory, that it does freeze funds, and this is a significant contributor to why people don't like the RDTs. but personally, I don't like the R Flow, right? Like I, I am just another user who's using Bitcoin in a way that's not weird, in a way that's prescribed by the Miniscript compiler, right? I didn't go out of my way to write a weird script, I didn't come up with that Tapleaf script myself. I used Miniscripts, this higher level, abstraction layer that is provided to me by Nunchuck, which is also a higher level abstraction layer, and my crime was not knowing that Luke doesn't like the way that I construct my script. Are you serious? Right? So I are a good enough reason to not go through with the software. But I also wanna talk about the chain split risk. So as we know, we've been getting a lot of non-standard transactions getting mined. It happens pretty much every other block, if not every block. So the moment that the RDTs goes into activation and a block that has content that BIP four four four or the RDTs considers to be invalid, you would get a chain split where all of the enforcing nodes on the user activated software would continue Extending the chain that is compliant, and then all of the legacy nodes that haven't updated would probably, you know, given that I don't think a majority of the hash power will switch, continue building on the legacy chain or the original chain. in this situation, if it were to continue for a long enough period of time, we could see the formation of a new coin entirely, right? But a lot of people are confused because they see that it's a soft fork, and to them, a soft fork is backwards compatible, and therefore a chain split isn't on the table. But The difference here is that, you know, traditionally in software, what we did was we took an opcode that was just a success and we repurposed it and added additional validation on top of it. We didn't say that existing transactions under the existing rules would be made invalid. We certainly didn't try to take something that was in policy and turn it into consensus, right? And so if you're a miner and your modus operandum is to update core once every couple of months, you might not even be super aware that the RDTs is going into action Activation, right? So if there's enough miners that are like this, I, I call them asleep at the wheel miners, it's very possible that the user activated soft fork won't gain enough hash rate to really make a difference. And then, you know, either miners that want to support the soft fork will continue mining on that chain, or they'll just give up and go back to mining on the original chain after having forfeit all of the block rewards of mining on the alternative chain, right? I myself will be running a user rejection soft- Soft fork, I'll be running a copy of the user activated soft fork to check what the tip is, and even if that tip has a higher weight of proof of work, I will call invalidate block on my Libre Relay and Core nodes to reject it and to continue mining and pointing my hash power at the original chain, because I don't want to be in a situation where, let's say, I'm extremely lucky and I solo mine a block, but it turns out to be on the r d t s chain, right? I, I don't want to be in a situation where I have to clean up

That even if the Knots, you know, crowd manages to convince enough, of the hash power to switch over and mine on the user activated soft fork chain, I will refuse to do so, and I'll continue invalidating those blocks on my main block template construction nodes. I, I think that it'll be really interesting to see how this plays out, you know, there are some parallels to the twenty seventeen block size wars.

Interesting, yeah. And it is a bit of a evolving space because, I mean, just, I think just a few days ago, it- It was initially intended to be, I think, February 1st and just like a UASF, I think just a straight flag. I think there were even some rumors of trying to do like

a miner activated soft fork to get miners to basically flag their support and then maybe a user activated soft fork as like the backup option of activation if that didn't go so well. Right. I think

that might be what they've gone to next. I think so. And again, there's a lot of parallels with like the 2017

block size wars here, right? Like, many of, Remember that when BIP one forty-eight first came out, miners didn't necessarily like the idea a whole lot. So then eventually BIP ninety-one was put forward, which basically allowed miners to decide amongst themselves by signaling with flags whether or not they were going to support BIP one forty-eight, and then if they did, then BIP forty-eight would be enforced from a particular block height on. actually, I think it might have been a, on a particular date going forward, and then later we switched to using block heights instead of dates. But nevertheless, right? Like, I

taken, the amount of con-- the, the types of conversations that people are having regarding soft fork risks, like chain splits, but I, I think the greatest difference actually between this and the twenty seventeen, block size war was that the twenty seventeen block size war exposed a degree of dishonesty and also an existential threat to Bitcoin, which at the time was the ASIC boost technology. and, and for those who aren't aware, ASIC boost was a particular technique that you could use to induce a approximate twenty percent efficiency. Efficiency improvement in ASIC miners by taking advantage of some entropy generation with the, the chunks of the block header. Without getting too deep into this, basically there were two types of variants. There was the overt kind of ASIC boost, which was observable on chain because you're, you're twiddling with your end version bytes in order to make this work, and then there was the covert method, which was actually manipulating Bitcoin transactions in order to find a collision in the Merkle root, specifically last four bytes of it. and this covert one was, was sort of the point of contention, like Person was d-defending this and saying that, you know, this is just an efficiency improvement, why would we try to go against this? While, other Bitcoiners in the space were like, "Yeah, like obviously this isn't a good thing. We don't want to give Bitmain this patent where they have a competitive advantage where, you know, it's not widely available to everybody else. You know, they've, they've implemented this hack essentially in their hardware that gives them a huge, massive bonus, in, in hash rate efficiency, right? And a lot of people at Bug. but the problem was that the incentives weren't aligned, because the miners were more than happy to hard fork SegWit in or to use extension blocks, which was a different way of implementing SegWit. And the reason why they wanted to do that was because it was compatible with covert ASIC boost, right? So this is, this is sort of an admission of guilt to many people implicitly, that, oh, well, why are you interested in these solutions that are specifically architected around the idea of preserving your competitive advantage in a way that's not provable? Right? You know, in a way that it's covert and nobody can point at you and say, "Oh, well, you're using ASIC boost, I can see it right here in the block that you just mined." So that dishonesty created a schism between the miners who incorrectly believed that hash rate was what determined consensus with the users and the economic majority, the, the exchanges. to be fair, the exchanges were kind of like, you know, split on this one 'cause they were selling like futures for the coin outcomes, but for simplicity's sake, let's just say the users, That were saving in Bitcoin, using Bitcoin, mining Bitcoin even in some cases, right? Some miners weren't opposed to BIP one forty-eight, most of, most of it was just Bitmain because Bitmain had this competitive advantage through ASIC boost. It allowed us to explore the concept of, you know, re-evaluating this ninety-five percent threshold, which many people had misinterpreted to be a vote, by miners. It, in fact, was not a vote, right? Shaolin Frye, a Litecoin developer who, who also worked in the Bitcoin space in twenty seventeen, sends Are we going to feel some pressure from, you know, people trying to get them to vote one particular way or not in adopting SegWit? Maybe they wanna adapt SegWit two x, you know, like miners might not be in a position to upgrade even, right? They, they, they may not have the means to just go in and update their, client software without having done audits, without having done some calculations on what their risk levels are, right? Like this isn't something that we want to make miners feel like they have to rush in terms of making a decision.

Enforcement at a predetermined time in the future. That, that settles things in a, a more stable manner, in a more predictable manner. Miners would have time to really think things through, and they could flag support for SegWit by consensus rule, and eventually activate it. And, and this worked really well. You know, flagging started, in August first, twenty seventeen, we started seeing more and more miners come on board. It was controversial to small blockers even to take the user activated soft fork approach. It was seen by many as, reckless and too risky. Activation. And, you know, if the BIP one forty-eight user activated software could fail, it could also give big blockers a huge lead, right? So there's a whole lot of stress, there's a whole lot of like, you know, game theory going on where everybody was trying to figure out what everybody else was going to do. and even Greg Maxwell, one of the goats, opposed it, right? He, he, he said, I quote, "The primary flaw in BIP one forty-eight is by enforcing the activation of the existing non-user activated software segment nodes, it almost

On Reddit and such, a few even see the forced orphaning of one forty-eight as a virtue, that it's punitive for misbehaving miners. The reputation we earn for stability and integrity, for being a system of money that people can count on, will mean everything. I think this has huge parallels, right? with the RTTS we, we just discussed that the reputation for stability, for uptime, for integrity, Bitcoin has never gone down. This is something that we really stake our entire identity on as Bitcoiners, right? Like we, we laugh at Solana when it goes offline. We laugh at Ethereum when it goes offline. We, we do these things because Bitcoin is so incredibly far ahead from a technical perspective, from an engineering quality perspective, that it's what really sets us apart, and that's why we say things like, you know, Bitcoin, not crypto. It's what distinguishes us. To compromise these values in some misguided attempt to make spam consensus invalid and bringing on board all of the risks that we braved for activating SegWit, something that we needed desperately. Because it was an existential issue, it makes you wonder, like, what are the actual motivations behind this software? Are they really about spam? Are they about centralizing and seizing control of consensus changes, making it so that it's easier to push through more soft forks in the future, or perhaps scaring off would-be soft forks, right? Sending the message that, hey, you can try upgrading Bitcoin, we can always roll it right back, right? What else, why, like, what other purpose would there be in removing upgrade hooks, unless it- It was a desire to ossify Bitcoin. and then let me just finish up with my comparison to twenty seventeen, and then we can dive a little bit into the other topics here. But, you know, I, I, I see the most interesting thing here being that, you-- We had these two groups in twenty seventeen. Group A wanted to just not give a shit about what miners did. They just didn't care what miners thought one way or another. They would just reject blocks that aren't SegWit. They would use the nodes that the users and the economic actors- Miners were running in order to enforce their will around SegWit, and then we had Group B, which wanted to just do a vibe check with miners and check that, okay, is a certain threshold of miners on board before we go through with this massive change that could risk a chain split. The fact that BIP ninety-one was able to bring these two groups that were opposed to each other and allow them to, to reconcile their differences, I think is really nice, but unfortunately won't happen with the rDTS, right? The rDTS is far more opinionated. we don't We don't have groups of people who are, you know, ultimately wanting the same thing but getting there through different means. We want people who-- We have people who are strictly opposed, diametrically opposed in terms of what they would like Bitcoin to be like. and so, yeah, ultimately I think the misinterpretation by a lot of people from twenty seventeen is that the, the people have the power, the little nodes defeated the minor giants. This isn't what happened, right? This is, this is an incorrect reading of what occurred. I, I think Paul, Stork, actually, I, I probably just, I, I probably just butchered his name, but Paul Stork from Truthcoin, I think, puts it the best, which is that, you know, talk is cheap. Miners signing a sheet of paper that says they're gonna run SegWit two x isn't a meaningful signal of how they actually feel. miners refusing to ever run a SegWit two x client, on the other hand, is a perfect communication that they are in alignment with the economic majority, because at the end of the day, it is the miners that suffer Irrelevant. Their block rewards are worthless if they continue to mine on a chain where users refuse to adopt that chain as the canonical chain. And in this case, I don't think there's enough user backing behind the rdt's that miners are going to look at this calculus and say, "Yes, it is an existential and revenue based issue for us to adopt rdt's, or else we will lose out on the block rewards. " I don't think they're gonna come to that conclusion, because this isn't an existential issue. This is an issue born of a subjective reading of transaction. On chain and a conflation of an annoyance with an existential problem to Bitcoin.

One other, I guess, broader kind of comment around programmability, I think maybe that seems to be another kind of a schism in a way, because I think some people, maybe more in the not slash RDTs camp, see it like We want to minimize the vectors for spam, and if it means we have to cut down programmability, so be it. Whereas maybe the other side on this particular debate see it more like, no, actually programmability is important to Bitcoin. It's how we encode things, whether that's Lightning, other L2s, inheritance Absolutely. Security, multi-sig, redundancy, these kinds of things. So, do you see it in a similar way, or how do you see that split? Is that, a good or a bad direction? I

think programmability is extremely important. to sort of look at this a little bit more deeply, I think, you know, I, I have looked at this from multiple perspectives. I've looked at this from the perspective of being a developer, where I am obviously pro improvements to Bitcoin. For example, I, I think zk coins, which is something that Litecoin, Upgrade in privacy, but would require embedding zero knowledge proofs on chain, which is a form of arbitrary data storage, right? I, I think that that's very exciting to me, and I'm, I'm very pro-programmability. I've thought about it from the perspective of my dad, who's not technical, who's just using Bitcoin to transact, and who's just using it to, sort of, you know, be a replacement to wire transfers or using Zelle or Venmo. I've thought about it from that perspective, and I've also thought about it from the perspective of Quasi court, right? Where you can enforce your conditions into a, a contract, or a smart contract in this case, like Lightning HTLCs, for example, and let the Bitcoin chain enforce the outcome of contracts, and, and maybe you could even extend that to things like DLCs, where you have an oracle that is determining an outcome, and people can create a prediction market or something like that on chain. I think the programmability, bill-- programmability of Bitcoin is a non-negotiable aspect that makes it so interesting, right? If we wanted to create something that Digital gold. What we could do is we could just create a fork in which we remove all of the opcodes. We move back to pay-to-pubkey. We make it so that the fields that are currently responsible for witness can only contain, a spending, you know, condition basically would just be the signature essentially. and then dumb it down to the greatest possible manner where, you know, you can't do multi-sig, you can't do anything except for single-sig spending, and even in this crippled husk of a version of Bitcoin It would still be possible to do arbitrary data embedding, right? You could, you could simply use fake addresses. You could use fake addresses, you could use fake pub keys, you could send to those, you could then, you know, continue to shard the individual pieces of a larger file across there. I think there was this bsv guy that actually, talked about this, in regards to op return, but it's also applicable here, which is that a standard op return contains enough space that if you're only embedding pointers, that it's enough to accommodate about two hundred ninety-eight megabytes worth of other op-returns, so basically a indirect form of a table of contents, if you will, right? You could say that I want to embed a file up to three hundred megabytes in size, I split them up across all of these op-returns, and then I have a master op-return that points to all of them as a table of contents, and then some sort of parsing program can read that first master op-return, search up all of the other op-returns, and then reassemble this file. Maybe you could put like your favorite movie on chain Now, I, I, I think that the, the problem that a lot of people struggle to grasp, the, the, the concept that a lot of people struggle to grasp is that arbitrary data embedding is Part of the very nature of any communication based system, if I have a communication channel with you that's a phone line, right? I can build some sort of a data encoding protocol on top of that phone line, even though that phone line is only intending to communicate audio data from me to you through You know, the microphone going into the landline and then coming out the other end through your speaker. But if I denote that a certain tone is a zero and another tone is a one, I've just created an arbitrary data communication channel, right? And what difference is there between a communication channel and a Bitcoin transaction? The only difference is that it's recorded and stored rather than it being an ephemeral channel that then gets closed at some point in the future, right? The second, the second reason why this is such a concern is steganography, right? Going back to what we were talking about with like We created private key that could be brute forced by anyone. If I encrypt the data, there's only one possible venue for you to determine what's inside the encrypted data, which is to brute force it, or for there to be a vulnerability or a flaw with the way that I encrypted that data. Are you then going to spend countless amounts of compute hours trying to determine if anything that looks like it could be encrypted data could be decrypted through brute force? How much compute are you willing to throw at this? A data center? Ten? Are you going to burn megawatts, gigawatts of energy? Just trying to determine what's locked behind this transaction, which could be encrypted data, it pr-- it creates a, a form of asymmetry that's very difficult for someone who wants to impose their will on this censorship-resistant system, right? And that, that's part of what makes Bitcoin so beautiful, is that even if you try to dumb it down to the very basic atomic level of what it is, you can still do whatever you want on Bitcoin, so long as you're staying within the relatively permissive rules of consensus.

Okay, so I think, essentially, yeah, we've, we've obviously, this is, it's been a bit of a wide, wide range of conversation. w-we've spoken a bit about the different ins and outs of spam, Libre Relay, as well as IDTS, and kind of finishing with, programmability. I think we'll leave it there. but, any, any last, kind of where, where can people find you online, and, listeners can find you, I think it's, Proof of Cash on X. Yes, that's, Correct. So you

can find me on Twitter on x dot com slash proof of cash. I'm also in the Blixed Wallet Telegram, if you're ever interested in trying out a mobile, you know, lightning wallet that's easy to use. my GitHub is DJ Kazik, if you wanna check out some of the projects that I've been working on there. I'm typically, you know, got one or two side projects cooking at any given time. And, if you ever wanna speak to me in person, come to the Boston BitDevs,

That doesn't always carry through tone, and, you know, ultimately if you, if you wanna have a good discussion, I think there nothing beats getting a beer and, talking about some Bitcoin. So please come find me, via whatever means that you'd like, and, if you're in Beantown, come on down to BitDev's.

Excellent. Alright, well, Kevin, thank you for joining us. Thank you

for having me. It was absolute pleasure. and I hope to be speaking to you again.