C (3:02)

And you're by there you're talking about things like ordinals or any kind of NFT ish type thing on blockchain, on, on the bitcoin blockchain. And I mean like to my mind to be super strict about it would probably be anything that's like non transaction information on the bitcoin blockchain. Would that be like more comprehensive?

B (3:25)

I mean it's a little gray because there is some data. I mean the thing that started this whole debate was a small amount of anchor data for a new type of layer too, the bitvm. And there are a number of projects working on that. And so it's not uncommon for some kinds of financial activity on bitcoin to use anchors. For example some of the anonymity, some of the coinjoin type things. The Samurai wallet uses something so there timestamp is not necessarily financial related but the rest are financial privacy. I think where people start to push on ordinals, well sort of other assets on top of Bitcoin gets pretty gray. Right. Because there are many protocols going back to MasterCard Omni which tether rides on and probably some bits and counter body.

C (4:28)

By the way Adam, I'm sorry you're cutting out a little bit. I don't know if there's a way to shore up your Internet. Maybe go ahead and work on that for a second. And Chris, why don't you go ahead and jump in with what you think this debate about knots versus core is about.

A (4:47)

Yeah, cool. So yeah, thanks. I think it's a really important conversation. I think as Adam said it's been going on since the beginning of the Internet and of course since the beginning of bitcoin. I think there's always been a tension between the side that is more worried about spam and the side that is more worried about censorship. And in the extreme, you know extreme, extreme spam filtration could be seen as an attempt to, an attempt to censor and just to.

C (5:20)

So because you are on the side of knots which you know for people who have been following this they would consider that side as more kind of pro censorship. Ish. You can, you can dispute that if you, if you want. But yeah, how are you. How does your side define spam on bitcoin?

A (5:39)

So storing data in the blockchain is spam because that's a, it's a different use case from what bitcoin is intended for. Bitcoin is intended for payments. You know, it's intended to be money so that you can send money to people. And so when you're using it for data storage, that is a different use case altogether with completely different economics. And it competes with the payment use case. And in the extreme, my side's assertion is that if you gave data and payments a level playing field with respect to fees per block space, then data would crush payments. And so that's why we're more worried about spam in this moment. That's not to say that we're not worried about censorship. I want to clear that up. I think censorship is potentially a problem, but I think that spam in this moment is a worse threat.

C (6:30)

And would you agree with Adam that the kind of main catalyst, because just what you described there, like storage, it's a broad category, but the main catalyst behind it is nft, like objects associated with the Bitcoin blockchain, is that.

A (6:46)

Yeah. So there's all sorts of harmful ways to put data in the chain. There's all sorts of threats to Bitcoin that can arise as you raise the limit of what is allowed to be in the chain. And we can talk about ways to solve that. But the biggest one recently has been, for lack of a better term, shitcoins, or as I like to call them, altcoin Ponzi. And these cause a lot of disruption on Bitcoin because they cause something called UTXO set bloat, which maybe your more technical listeners know what that is, basically slows down IBD and makes it more costly to run a node. And then the other big problem is that it causes high fees, which crowds out merchants that are trying to use lightning to accept Bitcoin in their shops.

C (7:27)

For example, just to explain the UTX bloat, basically, I saw this. I'm going to say it in very layman's terms, and I might get it wrong, but basically, in order to create these NFTs or send them or something, I forget what it was. There would have to be a transaction that created this extraneous UTXO that was like burning something. I forget all the details about this, but the point is, what they're trying to do is to not have that waste anymore. That's like part of the change that they want.

A (8:00)

Yes. Yeah. Basically there was a thing called BRC20 that happened during 2023 and 2024, and it was basically an altcoin Ponzi meta protocol for NFTs or FTS, fungible tokens. And basically they just created all of this noise on bitcoin. They made it harder to sync a node and they made it harder to transact as somebody who's just trying to do payments. And so those are the most harmful kinds of spam. But if we just raise it to 100 kilobytes, I mean, there's all sorts of other nasty things that might happen as well.

C (8:32)

And one last thing that I wanted to ask because famously Satoshi in the very first block of the bitcoin blockchain included something that was like non transaction data, which is the message, you know, the headline from the Times of London. And I wondered, does that fall in the same category of things that we're talking about or.

A (8:50)

No, it, it doesn't. So in, in, in one sense, it is sort of a superficial sense. It does because it is data that is in the blockchain. But in, in sort of a relevant sense, it's, it's completely different because it's not Spanish. You know, Satoshi was not spamming the blockchain by, you know, putting proof of the creation of the Genesis block January 3, 2009, and sort of hinting at the purpose of bitcoin, which was this chancellor on the brink statement. So, I mean, yeah, that the important point with that is you can put a message up to 100 bytes in every block header, but you have to mine a block to do that. And so really there's no way for it to be abused for spam in the same way that these, these altcoin Ponzi's are doing.

C (9:32)

Okay. So Adam, let's return to you. I had to cut you off to make sure that people could even hear what you were saying. So go ahead and, go ahead and finish on what you think this debate is about and hopefully your Internet is a little bit better.

B (9:46)

Yeah, my Internet's plenty fast. So I tried it without the headset in case that was the issue. Okay, so I think we got onto the topic. You know, the image spam is just and ambiguously wasteful. But the thing which gets increasingly gray is the sort of layer two meta protocols. There are many of them. So I started enumerating master coin rebranded OMNI counterparty recently BRC 20 runes, which carried a bunch of meme coins. I think over a hundred, 100 million outputs, probably mostly abandoned when it got rug pulled and about three and a half million images. And also shouldn't forget RGB and taproot assets. So, you know, the knots is blocking some of those and I think it gets pretty gray because some of them can be used to carry tether. Probably some bank, you know, demo or actual.

A (10:59)

Which ones is blocking.

B (11:02)

So one of the BRC 20 or Rune, I think they set the. I mean they block a bunch of stuff, right? They block lightning truck fix. They block 1 of BRC 20 or runes because the other one is more. Is less wasteful. They block some semi runes.

A (11:19)

We should specify what you mean by block. So you're talking about by default. But yeah, but if the user wants to unblock those things, it's just a little setting, right?

B (11:29)

Well, I mean the defaults are blocking all those things or filtering them out, right? Of course, when other nodes in the network that are more constructively processing things, let's say mine them, then well relay them and then they get mined. Then of course, you know, any bitcoin node of any kind will store and relay them. So I think that there is some sort of side effect from this which is it's not really very well targeted. And some of those layer twos carry some of the kind of color coin related things basically. Right. They carry tether, they carry probably some real world assets and I think not. You know, before the spam drama has been having some kind of pedantic argument with Samurai Wallet and blocking their mix protocol. So not to get too, you know, just. I'm just saying it's grain and, and it's not clear which is worse actually because you know we, we're focusing on the image spam because just clearly unambiguously wasteful of block resources.

A (12:42)

But just to be clear, Knots is not blocking whirlpool transactions like the privacy related transactions intentionally. That's, that's not intentional. That's just an artifact of the, the privacy guys being a bit. Just hard to deal with. I've actually had conversations with them on Twitter like hey, you know, how much space do you need to. To relay your transaction? And they just won't say. And they're just like you know, screw you, censor. You know. And I'm like okay, but you're not actually.

B (13:13)

Let's just say it takes two to tango. Right? Because there are lots of users of Samurai who were complaining about this and Luke was also not helpful. And this, this dates before the spam, so it's not really as much about the spam.

C (13:26)

Yeah, let's. So I feel like you guys are getting a little bit in the weeds. So let's just keep zoomed out just for one more question. So basically what, what is happening is. And, and please correct me if I'm not explaining any of this correctly because obviously I'm not a developer. So there's a bitcoin opcode and opcodes are kind of like sort of the instructions for how the bitcoin blockchain is coded. And it's called oper. And this would allow arbitrary data or messages to be embedded in bitcoin blockchains in bitcoin transactions. And this is kind of at the center of what this Bitcoin core versus Knots debate is about. Right. And so let's just make sure everybody understands the two sides. So Bitcoin core plans to do what? And then Bitcoin knots is against that. So each maybe. Adam, why don't you explain like what Bitcoin core is going to do and then Chris, you can explain what Knots opposes and prefers.

B (14:29)

I mean, I think it's a bit of a red herring really, because opereturn has been standard one megabyte. Well, actually, sorry, I should say consensus valid. So that's the, the rules of the network, what gets enforced since 2014, when it was introduced, there was a filter or policy limit which is not, you know, it's just what a node or really it's not enforced by miners or full nodes. So it's pretty easy to bypass it if somebody really wants to. And so then the, the recent wave of spam which, you know, agitate people, basically started in the altcoin winter when Bitcoin VC funding doubled and altcoin VC funding dried up. And so a number of altcoins relabeled themselves as Bitcoin layer twos and bought their kind of meme coins and NFT.

C (15:27)

Collections to Bitcoin and talking about like starting in 2022.

B (15:32)

Yeah, something in that range. And so, you know, I think that's probably the big driving factor because realistically, this spam could have been sent anytime from 2009 in various encodings. As soon as you have a programming system, it can be. Have data hidden in it in numerous ways. Right. And so it still gets complicated, but basically they are heavily using hiding images, at least in Taproot script, which has a discount which relates back to 2017. SegWit introduction and Taproot itself didn't come until 2021. So the image spam is going in there and say what bitcoin developers did was to see. So actually the, the original introduction of Opera turn in this format in 2014 was reactive to people spamming or more. More like lazy application developers putting app small app messages in inefficient ways and one of the most inefficient ways to stash data in the bitcoin blockchain is in fake public keys. So public keys being, you know, how an address basically what you would send a transaction to. And so they just put the data instead of an address. And that actually is pretty bad because it gums up the utxo, which is the least scalable part of running a node. So that will overload your node faster than anything else. And so they, you know, this, this debate in 2014 has really been running since 2010. I only got involved in 2013, but it was already raging then. And so the OP return was basically a realization that look, there's nothing we can do talking to the app developers between getting angry, making suggestions to even remotely influence them, nothing so corrosive as a lazy app developer, basically. And so they made the OP return to at least say, well, if you're going to store application data and we can't deter you from it, at least do it in a way that doesn't, you know, get on the node up. So the point of the OP return is it doesn't need to go in the UTXO state and so it's less harmful. And so now with the all of the spam happening in Taproot actually like in a different script format, then this sort of same situation recurred which is some new app devs wrote up a, well, it's kind of layer two anchor protocol called Citrio, which is an instance of the BIT VM protocol. And they wrote up a paper implementation saying, well, they were going to store 80 bytes within the policy limit and then two fake pub keys because what they had, their anchor didn't fit. And so know the developers saw this as a, you know, it's complete, you know, mirror image of what happened in 2014. So rather than do nothing and have that, you know, have them start to do that, we don't know if it'll take off or not, it's a new protocol. But once people implemented things they won't generally want to change them for backwards compatibility reasons. And so they propose to increase the OP return to allow for that. And while they're in it, they realized that a lot of so in recent history the developers have been quite slow to adapt to network conditions. Full RBF was one example, 98% of miners were mining those before Bitcoin adapted policy, before the code adapted the policy to catch up. And the minimum fee rate dropping below 1 SAP of V byte is another great example. We could talk about that more. That's also recent and another feature are in Bitcoin 30. And so then the, the reaction to increase the OP return is to say, well, OP return is, I mean above 160, which probably people would have been happier with. That's what I suggested. But anyway, the argument for increasing it or basically removing it is, look, it's actually preferable if people would put images in OP return than putting them in inscriptions. Of course preferable, we don't do it at all. But given that we don't seem to prevent that, particularly in decentralized strict resistance system, then it would be less bad for the node and less dangerous in terms of tinkering with active code if they would do it in OPERA terms. So let's not create any disincentive to do that. Now of course they're probably not going to do it in practice because it's four times more expensive, which is a different problem. But at least things like Citria are not incentivized to do a worse thing. That's the start.

C (20:33)

Yeah, you explained so much there. So let me just make sure at least that I understood it because probably some huge percentage of people listening to this are either more like on my level of their understanding of the technical aspects, or even less so. This, you know, op. Sorry, the, the return, sorry, the OP return limit, I think currently is 83 bytes. Am I correct about that?

B (20:59)

Or that's the pulse limit. Yeah.

C (21:02)

And so essentially the change that Core is proposing, and in fact that is perhaps going to go live on Friday, is to, you know, or as you said, to not to not put a cap on it, which would effectively raise it to 4 megabytes. So for again, non technical people, that's raising it basically from 83 to essentially 4 million, which is like a huge 1 million. Am I wrong about that or what?

B (21:27)

One megabyte.

A (21:28)

One million.

C (21:29)

Oh, it's one megabyte. Oh, okay. Okay. Well, still 83 to 1 million. What?

A (21:34)

If you put things in the output, you get up to 1 million bytes and if you put things in the input, you get up to 4 million bytes because of how the segment discount works.

B (21:42)

And wait a second, we're also getting the things crossed a bit because if people care about filters and policy, there's a 100 kilobyte limit on transaction size. But realistically, policy doesn't prevent that much. That's, that's what people have learned over the last few years.

A (22:02)

So I have a lot of responses to all of those things.

C (22:05)

Okay. Go ahead, Chris.

A (22:06)

I don't, I don't think that's a correct. Well, okay, so you. The core devs position as well as they've explained it so far and I don't think it's a, I don't think it's a credible rationale. And the reason for that is because Citria first of all has not launched on mainnet yet. Second of all, their transaction only put 64 bytes into the UTXO set. And you know, and the BRC20 put like 7 gigabytes into the UTXO set. So. And furthermore, if you look at how the citrus bit VM bridge works, that transaction is never supposed to happen. So the rationale for creating the, for ripping out this, this very useful filter, the operator filter, which has existed for decades without any side effects. I know that you, you say there are side effects, but I, I haven't seen any evidence for these side effects. But so anyway, the rationale is okay, they might put 64 bytes into the UTXS set. So we're going to completely remove this filter that prevents, you know, that generally prevents spam and discourages people from spamming in order to fix the problem. And it doesn't, it doesn't fix the problem. The, the, the problem that is, that is being solved is tiny and effectively non existent. And then the fix is much, much, much worse than the, the disease that it purports to cure.

C (23:26)

And. Wait, I'm sorry, Chris, so why, why is it so much worse? Just explain why you guys are so opposed.

A (23:32)

Yeah, so what happened is in 2014, as Adam said, we agreed that we would give these applications, lazy application developers, a little space of 80 bytes where they could put arbitrary data to build their applications. And that was the limit. That was nobody wanted Bitcoiners, did not want any to allow any more than that. And that was enshrined in a thing called data carrier size. That was the default for 10 years and it worked wonderfully. And then in 2023, late 2022, Casey Rodimore found a hack which is called the Inscriptions hack or the Inscriptions. It's called inscribing, I guess. And it's a different way of putting arbitrary data in the chain which is not filtered. Right. He found a way to kind of sneak data in, in a way that notes would still relay, even though it violated that 80 byte limit that everybody agreed to in 2014. And so what happened is there was a bunch of spam, there were a bunch of Altcoin Ponzi that launched on top of this new type of embedding data. And this caused a bunch of UTXO bloat. Even we can get into this. Even though inscriptions are not stored in the UTXO set. So this, this, oh, you know, OPERA terms are not stored in the UTXO set, so they won't cause UTX OSET bloat is an invalid claim because inscriptions are the same way and they still caused UTXO bloat. And so basically what happened is there was this huge problem. All of these node runners that I was working with to try and, you know, b merchant nodes or lightning routing nodes were struggling to sync the chain. And it was blindingly obvious to anybody paying attention that it was because of these spam attacks. And it was also blindingly obvious that bitcoin core could have completely prevented this if they had just filtered inscriptions in the same way that opportunity is being filtered. And so, you know, this went on for years. It's got more expensive to run. And then finally core notices that there is UTXO set load. And instead of actually fixing the problem by filtering the spam, they decide to make the problem much worse by effectively making the inscribing method officially sanctioned by basically saying, well, everybody can already inscribe data anyway in the input, so we might as well just make the opportun output larger. And the reason why this is so much worse is because in 2014, what made the spammers go away is that the bitcoin devs were hostile to spam. And Vitalik even tweeted about this. He said, the reason why I left bitcoin and went and made my own blockchain is because the bitcoin core devs would be at. And so, you know, it's, it's, it's, it's been proven in history that if we just counter all of their moves, they'll eventually get kind of demoralized and frustrated and they'll just go to other chains. So that's the real solution. The real solution is be hostile to spam. And lifting the opportunity is the opposite of that. It encourages the spam.

C (26:10)

Okay, I'd like Chris, though. I guess the one thing is, you know, a lot of people like one of the core value propositions of blockchains is that they're censorship resistant. And so it's like, I think, you.

A (26:24)

Know what, a lot of people doesn't change that bitcoin is censorship resistant because of proof of work, because you can mine a transaction as long as you have energy to mine a bitcoin. Block or as long as, you know, a miner that has energy to mine a bitcoin block. So it's difficult to censor bitcoin. Even with widespread. Even if everybody wasn't relaying transactions at all, Bitcoin would still be censorship resistant. So I don't think that's as big of a concern as the other side seems to think. But you know.

C (26:59)

But what you can see that your side is, it is trying to censor, which I think that's what Adam's side is saying. Like no, no.

A (27:09)

So censorship and span filtration are different things. Censorship is trying to entirely block a transaction. Is that, as Adam already noted, this is impossible in bitcoin. You can't be like, somebody can't put that piece of data on the blockchain and just block them from doing it. As Adam said, and as everybody knows, bitcoin is censorship resistant. You can't do that. However, what spam filtration is useful for is if there's high volume spam, then put a filter in. Now the spam instead of at this level, it's much, much, much lower. And you can actually see this. If you look at the data, the opportun filter results in 99% fewer operations that are larger than 80 bytes. And if you look at the data there's a, you know, there's like a 99% drop off right at 80 bytes. So this notion that oh, you know, filters do nothing and never work is disingenuous. I think the other side, that they're being dishonest.

B (28:02)

Let me, let me, I shouldn't, shouldn't assume bad faith. I can debunk all of that. So the point is that because bitcoin is a censorship resistant network, as we just described, it's flood filled. So there are many routes through the network and so consequently it's going to be pretty hard for filtering to work. Right. So it distinguish between policy and filtering. So it should be clear that there are some policies that work quite well in the network. For example, fees are enforced by policy which is just by nodes. There are different types of policy enforcing different things. And filters are the sort of filter on the maximum size of an op return is another common policy. And those policies have changed the factor in the network in pretty dramatic, remarkable ways. At loss for years. So for example full rbf, that was a policy that completely broke. Basically miners and users decided that they didn't want it anymore or something. Some users did want to keep it. I was on the side of wanting to keep that one, because I thought that was enabling their use case a more timely in terms of happening recently and also a feature of Core 30. I mean, so Bitcoin 30 has three major features. One is truck, which is a fix for a lightning pinning attack also implemented as a policy. Another is the sub 1 Sat per V byte minimum relay configuration which has changed reacted to the network. And that one's quite topical to this. And the last one is the discussed op return relay increase. So I think it's useful to think about the sub ones that v bytes. So there's some interesting fact with the bitcoin network. Each node is connecting to lots of other nodes. And so what has been observed empirically is that if about 10%, it depends what the miners are doing, what the average node is doing, but something in that region. If 10% of nodes decide to relax a filter, the filter stops having any effect in the network as a whole. And there's a reason for that, which is there's many ways that data can route through the network and just organically connecting at random. That means that a sort of tolerant minority can change a policy or filter from working to not working. And that was the case with the 1 snap per V byte, which is the minimum fee rate that would get relayed. And it's quite an interesting and instructive one because it had near universal enforcement, because all prior versions of bitcoin and all versions of knots were filtering or blocking that. And yet a subset of users memed into existence for whatever reason. And there's some people on Twitter who said they participate in it. They decided as the blocks won't fall, bitcoin price has gone up. 1 SAP of E byte was too high. So miners went along with it, they change their nodes and what do you know? Now it works everywhere, right? And so that is an example of how filters can appear to work until they don't. And so I think if you look at the range of policies that work versus not it seems to be something like as long as users don't have a strong economic incentive to bypass them, or as long as miners go along with that, right? So some miners will process them, then it's going to break wide open. And so you can see that effectively with the sub onesat per vbuy change. And that's one of the changes in Bitcoin Core full RBF I mentioned that happened in the past. And Core felt that the bitcoin developers felt that they were behind the times. It got to 98% deployment before they reacted. So I think if anything you could say they are again reacting because the default in the network for relaying large op returns is effectively 100 kilobytes.

C (32:26)

Chris, I know you want to respond so just hold your thought. We're going to take a very quick ad break from the sponsors, make this show possible and we'll be right back. Mantle leads the establishment of Blockchain for Banking as the next frontier. UR is the access layer that transforms Mantle Network into a purpose built vertical platform. The Blockchain for Banking that enables financial services on chain. UR unifies and vertically aligns Mantle's focus on payments, trading and assets. MI4emmeth Protocol functions FBTC supported by developer grants, ecosystem incentives and the industry leading distribution platform through the UR app reward station and BYBIT launch pool. All economic activity within UR will be captured by Mantle Network to further drive value to token holders and establish its significance in Blockchain for banking. Follow mantellfficial to learn more. Over 3.4 billion transactions processed without disruption. More than $1 billion in stablecoins circulating over $720 million in in real world assets tokenized on chain all delivered with sub second finality block times under 100 milliseconds and fees less than a tenth of a cent making Aptos more than 100 times cheaper than other leading blockchains built by the team behind the DIEM project at Meta. Aptos is what blockchain performance looks like when it's built for global financial markets. Discover why Global institutions like BlackRock, Franklin Templeton and NBCUniversal are building on Aptos and see for yourself at the Aptos Experience, October 15th to 16th in Brooklyn. Back to my conversation with Chris and Adam. So Chris, I'm going to let you go with your response, but then I have specific questions for each of you because there are certain parts of the various arguments that we have not touched on. So go ahead Chris.

A (34:17)

Okay, yeah, I'll try to be brief. Can you hear me?

C (34:19)

Yeah.

A (34:20)

All right, perfect. Yeah. So Adam introduced two examples where filters that were filtered by default in Bitcoin core were circumvented and eventually sort of core sort of surrendered and ended up turning off the filter. And this was full RBF in 2021, 2022, something like that. And then much more recently subsat transactions, which basically transactions that pay very low fees. And so this doesn't prove that filters don't work. Adam's making the assertion that well, filters never work because we have these examples that are sort of counter examples. Right. But this doesn't prove that filters never work. It just means that filters don't work sometimes. And the obvious, the counter example to the claim that filters never work, of course is the opportun filter which is trying to be, which is the thing that CORE is trying to remove. This filter works very well. It's been in, in existence since 2014. It has attenuated the amount of operations that get confirmed in the, in the blockchain by 99%. Over 99%. It's wildly successful. Yes, of course a determined adversary, you know, a determined spammer can just post one or two of these transactions or 10 or whatever, but they're not going to, they're not going to be able to do a high volume spam attack of the type that we saw on inscriptions, obviously, because inscriptions were, were standard and being, were being relayed. Nobody would make an altcoin Ponzi metaprotocol on top of opera terms right now because is a non standard and those transactions would not get relayed. So I think it's time for CORE to stop saying filters don't work. I think a much more interesting conversation is filters work sometimes and then we can kind of, we can have a discussion about when do they work and when do they not work. And I think there are very good explanations for why those two examples brought up happened that way.

C (36:05)

Okay, so I'm going to go through various of the criticisms that I've seen of both sides just so we can see like what each of your responses would be. So Chris, I'll start with you. One that I've seen is that this change that CORE wants to put through on Friday would help make mining more sustainable. And I'm sure everybody knows that there is this question about the sustainability of fees, transaction fees for Bitcoin. Obviously the block reward will continue to be produced until roughly 100 and change years in the future. But there are some people who have modeled out that they actually think that the fees may not sustain the blockchain even as, you know, soon as like 10 to 15 years out. So there are some people who are saying that this change could make mining and therefore the security of the network more sustainable. And so Chris, I wondered if you could respond to that criticism of Knox.

A (37:04)

Yeah, I think that's, that's fud. I don't, I don't see a reason to, to think that low fees is going to somehow destroy the mining industry anytime soon. I mean, maybe once the block subsidy, I mean, so right now, you know, miners earn fe in two different ways. There's a block subsidy which is new bitcoins. Right now it's three and an eighth bitcoins every block and the fees are much, much, much, much lower than that. So there's the subsidy and there's the fees and those are the two ways that miners get, get, get fees. And as, as you mentioned Laura, over time, as the, as the halvings continue to happen, eventually the subsidy is going to go from three to three to the three and an eighth to zero. You know, 100 years from now. And at that point, yeah, it might be worth revisiting the economics of mining. But for now I think mostly it's just kind of outrage coming out of the mining industry like oh no, we don't have, you know, we don't have enough fees. And the thing is that's, that's not really a, that's not really a thing that can happen. Like if, if all the miners are earning less fees then, then their hash rate will, will go, will be lower than it otherwise would be and the difficulty will just down and then everybody will be just as profitable before. So I, I don't, first of all, I don't think that's a good threat. And second of all, the solution proposed is not a solution because as I alluded to earlier, if Bitcoin has to be saved by, by cramming data into blocks and you know, 100% of Bitcoin of the activity on Bitcoin IS data and 0% of the activity on Bitcoin is payments, then can you really, can you really call Bitcoin money anymore? I mean, at that point it's not money. So I mean I, I think it's really important that money and payments be the dominant use case. And the only way to ensure that is by trying to rate limit these, these low value use cases that, but that compete with high value use cases.

B (38:51)

I share Chris's view that that's a bit of a red herring. I think the long term fee budget is a different longer term topic that's not really being raised. I mean presumably some fringe group raised it somewhere. But I don't think most people are concerned mixing these two topics. So I think the, you know, the arguments about the opretone parameter seem to be a bit confused because I think both sides will admit that taproot inscriptions are four times cheaper. So it's unlikely that spammers would be motivated to use opreturn for large data items. I mean they, they would for small data items. And then the second point is even if they did use it in the alternative to using Taproot script hiding. That's actually a good thing because, well, good thing, a less bad thing. Let's be clear that it results in less data and they pay more fees. So you can't have it both ways. Right. Either they're going to use it or they're not. I think we agree they're not. But if they did, why are people fighting so hard to prevent them doing it? Because it would actually be less overhead on the nodes, less data and printable outputs.

A (40:09)

Yeah. So the specific threat is that. So as we know, shitcoiners love to basically do the same thing as before, but with a slight tweak that makes it look novel and then it causes a new hype cycle. So we saw this with inscriptions, we saw this with BRC20, we saw this with runes. You know, BRC20 was like, oh, there's a, there's a fungible token protocol on top of this new data embedding protocol, Inscriptions, which uses ordinals. And so that caused a craze. And then Casey was able to kind of help kill ERC20 by introducing runes. And that was popular because, oh, it's this new way of encoding data that, you know, that was created by the creator of ordinals, you know, and so that caused the hype cycle. It just needs to be be something that appears to be novel. It may not even be that innovative. But as long as it's just a little bit different from what happened before, it will cause another hype cycle. And so the specific threat with removing the operturn filter is that some degen is going to make a meta protocol on top of oper turns. Once we remove the filter, it's inevitable and it's going to cause the same amount of at least high fee spam and maybe also UTXO set low spam. And it might, and it probably will be even worse because now we've rolled out the red carpet for the spammers and we've said, yeah, come on in. You know, all you Ethereum people, come on in, we don't mind.

C (41:19)

Okay, okay.

B (41:20)

So I think that's mischaracterization that anybody wants to spam. The bitcoin developers that you're maligning have been arguing against spam since 2010, maybe before. Right. That's even why the OP return got included in the first place. And I think you have to cast it forward a bit. Right. Because there are other worse ways to spam, which they have been using in the past. You know, the Segway mechanism, the discount, the up return, the temporary rule of the new things, and people were spending before that. And if you.

A (41:54)

But my point is that the majority of the utxo set is BRC 20s. If you look at the UTXO set right now, the majority is BRC twenties. So the worst threat is these Altcoin meta protocols, these Ponzi meta protocols.

C (42:07)

Okay, so actually let me build on that because, Adam, I did want to ask for your side. One of the criticisms that I've seen is that when you add all this data to the blockchain for non priority reasons, that can create an extra burden for the nodes. And so basically that kind of would imperil or yeah, would imperil the centralized decentralization of the network because essentially miners would need to have higher hardware requirements. And so therefore it kind of like blocks out smaller miners. And so, you know, is that a risk that you, that you acknowledge for, for what Core is trying to push through?

B (42:46)

No, not really. Because I mean, the Bitmex research has pointed out, and I believe it's correct, though a bit of a kind of prank comment, that actually lots of big images is a lot lower overhead for a node because the thing that slows the node down at worst is the BRC 20s. Lots of abandoned UTXOs, large UTXOs. So actually a blockchain full of images is actually the simplest and lightest thing for a node to process. Right, but that's nothing anybody wants, so it's kind of.

A (43:18)

Right, but that's not what they do. Right, they create these metaprotocols on top of the images and that's where you get this damage.

B (43:27)

What do you mean? Metaprotocles for images, you mean? But I think we're mixing two things. One is the image span, which is large. The other is these small items like omni counterparty, BRC20 FIG, pub keys, taproot assets, RGB. Right. So if you some filter some of them, you can't. So you know, I think it's instructive to consider the scorched earth, like absolutely strongest fight you could put up to stop spam or to like mitigate, minimize, push them out. Right. And it's pretty dramatic and I'm not ever keen to do it, but you know, you could soft fork out Taproot, you could soft fork out Segwit. Of course you'd have to do that carefully to not lose a bunch of people's money and undo years of work. You'd soft fork out or you know, deprecate op return. And now let's say that the altcoin winter happened. After you've done that, do you think they would stop spamming? I don't think so at all. They would just use the Bitcoin stamps protocol, which is far worse, and they can store arbitrary amounts of data in it. The overhead is not even that high percentage wise and that would really blow out the UTXO set. So I think in a way, even though the image spam is the most gratuitously waste in a looked at in simple way, in some other ways in terms of node overhead and impact on the functionality of Bitcoin, these small data items that are for meme coins are actually more harmful and incrementally pushing down, playing the arms race, it leads to a worse place, right? So yes, everybody wants to control spam, but you have to play chess and think you move it to the head. So if each thing you incrementally do has an obvious counteraction that actually makes things worse for the bitcoin users, for the node runners, then it's sort of, I use this analogy of the, it's a Star Trek thing, right? The Klingons, the Vulcans and the Ferengate. So ultimately, you know, I think there's a lot of people mad about spam and they, you know, they are sort of wanting to fight somebody and so, you know, punching at developers or something. But I think to realistically even do something predictable about spam, you have to think forward about the economic implications and the probable next actions of your opponent. You can't play chess. Not looking more than one step.

C (46:03)

So. So basically, Adam, if I'm understanding your position, it's that you're, you're not for like things like BRC20 data and all that flooding bitcoin, but when you look at all the available choices, you feel like what Core is deciding to do is like the least bad of a number of like unsavory options. Is that kind of the way to think about it? It's futile to fight this, so might as well figure out the best way to allow it that results in the least harm to Bitcoin. Is that a way to summarize it?

B (46:38)

It's not exactly futile, but you gotta be careful that the cure isn't worse than the problem. Right? And that was effectively the frustrating reality that led to the creation of OPReturn in 2014, is that people had tried for four years to persuade people and you know, shout at them, reason with them, give them sample Code to even influence the behavior completely unsuccessfully. And so they figured, well let's, you know, let's at least make a way to do it that's less damaging. Now, you know, in any Internet protocol, since the Internet's existed, it's possible to stuff spam into all kinds of protocol fields. Spam filtering has never worked in the past and it's far harder to do it in bitcoin because bitcoin is decentralized and censorship resistant architecture. Right. Even we get spam in email, which has a central server. So how are we thinking it's going to be easy? So that's not to say it's impossible. I would say what we have to do is do it in a way that is economically rational for the people that we would wish would stop. Right. You have to bear in mind the opponent is a rational economic actor that has about a billion dollars a year budget, a million dollars a day in fees. And it's not realistic to imagine they're just going to stop because we tweaked some parameters. At the end of the day, as long as their consensus valid, they can go to a miner and get their blocks, their transactions processed. And even if you completely, you know, if 100% of the nodes were filtering everything they want to do, they will still do it for the simple reason that they have a lot of money. If no miners would go along with it, they can just rent hash rate and then they can process themselves. And the cost of hash rate is about break even. So it wouldn't even cost them that much money. So that's you cast forward. That's what I'm saying. Like you just make things worse for yourself. You create a lot of risk and you didn't achieve anything. So I take what Chris is saying, that maybe if we punch at them incrementally, they'll give up and go away. But a million dollars a day and a billion dollar industry doesn't seem like it's going to go away.

A (48:49)

Well, but again, this is what worked in 2014. Vitalik left because bitcoiners showed that they were serious about countering every move from the spammers. It's a cat and mouse game, as a lot of people like to say. But it's a game that the, that the cat can kind of easily win. You said that bitcoin is hard to do spam filtration on. I disagree. You know, I think it's easier to do spam filtration on bitcoin than anywhere else because bitcoin also requires A fee per block space. So that makes easier. Yeah, and, and so, but to your broader point, I don't disagree with any of those things. Of course I'm, you know, looking into the future and looking, considering second and third order effects. You know, it's just, I think that the, the second and third order order effects of a friendly stance towards spam is, is much, much worse than the effects of being, being hostile to spam. And so we have weak tools like, like filters and we have strong tools like temporary software or whatever, like you just said. And as you said, we can incrementally hit them harder and harder until they, you know, take the hint and go somewhere else. And again, this is exactly what worked last time, so there's no reason it won't work this time.

C (49:55)

Okay, you guys, we're running out of time, but I have like a few questions I absolutely have to ask you, so we're going to keep moving on. So, Chris, I did want to ask you. Basically, you know, I think the, the side of knots is that, you know, the most important feature of bitcoin is that it's money. And yet, you know, I think some people, when they look at the fact that what knots wants to do would effectively, you know, kind of block things like Citria and Lightning that are. I don't know about lightning, sorry, Citria that are trying.

A (50:25)

Not like.

C (50:26)

Yeah, I'm a lightning master, sorry, Citria that are trying to, you know, broaden the use of bitcoin as money, they find that to be hypocritical. So can you address that criticism?

A (50:38)

Sorry, what do they find hypocritical?

C (50:40)

Oh, that your side wants to prioritize the use of bitcoin as money and Citria would further that use. And yet you are.

A (50:48)

Yeah, yeah. Okay, so my stance on this is a little bit nuanced. So there's, there's things that are applications and things that are layer twos, and I have a little bit of a hard line stance on this. I think that lightning is a real layer two and I think that ARK is a real layer two, and I don't think that Citria is a real layer two. And the reason why Citria is not a real layer 2, whereas Ark and Lightning are, is because arc and lightning has something called unilateral exit or trustless exit, so that it's a completely trustless layer two. So, meaning that you can take your money out of a lightning channel whenever you want without asking anyone else permission. Right, you just take the money. And so I would consider lightning Bitcoin to be in a lightning channel, to be Bitcoin as such. And those really scale Bitcoin, those types of use cases really scale payments. Whereas Citria uses A1 of N trust model. And so this is not trustless, it's almost trustless, but it's not entirely trustless. And so to me, you know, if somebody wants to build that, I don't have a problem with that. I don't have a problem with somebody building Citria. What I do have a problem with is Citria coming in and saying we're going to stuff our data into fake pub keys, which is something that all bitcoiners know is you're just being a jerk if you do that. You're just being hostile if you do that. And then, and then instead of the developers coming back and saying, hey guys, please don't do this, they're ripping out the filter that prevents this, you know, and basically taking something that everybody came to consensus to about in 2014 and just unilaterally raising the limit from 80 to 100,000, which nobody agreed to. So, you know, for an app that isn't even a real Layer two, now if it were a real layer two, then I would be much more excited about accommodating them. But they're not. So I don't see why we need to bend over backwards to filter their. To relay their training.

B (52:36)

They were going to do it anyway. They weren't asking for the change.

A (52:39)

Exactly.

B (52:39)

And sitri and that's exactly the same pattern as opreturn in 2014. People doing things with that permission that were inconvenient for nodes. I don't really accept the argument that it's not a real Layer two. I mean, that's just one person's judgment against somebody else's attempt to build a layer two. It's trying to improve the state of the art in providing secure anchors to more flexible types of Layer two. Right. So it's something that can have a different payload, more like a sidechain kind of payload, or, you know, you can have a Fediment in one of those. I think that'd be pretty cool. Very high scale, very private. So sure.

A (53:18)

I mean, again, all those things are cool and it's fine if they build them. Let's just not redefine Bitcoin.

B (53:26)

I mean, it's exactly the same pattern. I mean, if you're saying you would want to block Citrida 160 bytes or whatever, they take that doesn't make sense to me. That's asking them. That's basically forcing them to do what they were going to do anyway, which is to use fake pub keys. Right. Which.

A (53:42)

No, no one is forcing them to do anything. Like, we all agreed in 2013 is the max. If you want to build something that uses more than that, you need to get everyone's permission. You can't just go do it or you're a jerk.

C (53:52)

Well, okay. I mean, yeah, I mean, I guess, anyway, yeah, part. Part of what I'm hearing, Chris too, it, like, makes me think, you know, who put you in charge of, like, what's a legitimate layer two. And I like you. I hope you're not taking it. I'm just trying to imagine, like, what the critics are saying, like, who's to decide?

A (54:11)

But what I'm saying is Bitcoiners decided when we said 80 bytes is the amount of data that you can put in a transaction. That was the decision. And so if your protocol needs 144 bytes, then you can't build that on Bitcoin without making some people angry. This has been here for 10 years. It's not some new thing. Everybody knows this.

C (54:31)

Yeah. So let's now talk about this disagreement because this is probably the big kahuna part of the episode. So I need to understand something, and this is definitely going to be far more technical than I could do. I tried to kind of gather all the data around this, but I can't make sense of it myself. So if you just go to coindance, which has long been used for these types of, you know, what. What do the miners support type questions in Bitcoin? It kind of looks like Bitcoin knots is at about 22% of support when you just look at the nodes. But as far as I can tell from people who are far smarter than me, they've been talking about using something called as map. I don't know what. What that stands for, but as far as I can tell, it basically allows you to see kind of which nodes are. Sorry, not which nodes, but when nodes are controlling a large number of IP addresses, which would indicate that these nodes are actually one entity. Sort of almost like the concept of a civil attack. So, you know, I don't know. I don't know if that's true, but there are people who are calling this out and who are saying that when they filter for that, then suddenly the number of knots, nodes that they're connected to drops by like 90%. And yeah, so I might have gotten some of the technical details wrong. But I would like to hear from both of you, what do you think is the actual support for knots and how do you figure that out? And then after that we can move on to an even more important question. But tell me how you are figuring that.

B (55:56)

Let me give it a go because I think we may not disagree, which is I think some of those initial reports were too small a sample set to be meaningful. I think it's hard to say. It depends. It doesn't necessarily mean to think. Right. There are some popular cloud hosting platforms that people may be using legitimately. There might be a bit of sibling on both sides, but I think ultimately it doesn't really matter. And I think the bigger point is that even if naughts got to 90% or 99% or 100%, it wouldn't stop the spam.

C (56:27)

Well, okay, but Adam, regardless of. Sorry, yeah, just what do you think is the actual number of how much support there is for knots? Like do you have a way of figuring that out?

B (56:40)

I'm not sure. I mean it's. There's a lot of people that are economically interested that are not running notes and of course the drama, you know, the discover the drama caused more people to run notes, which is generally a good thing if you use a node economically and protect yourself from, you know, hostile forks. If we remember back to 2015 to 2017 discussions that that was the kind of genesis of the run your own node node runner concept, which is generally good. So you know, I mean you've got to bear in mind that Bitcoin's a peer to peer network and like everything on the Internet, people can do what they want, they can run what software they want. I think this debate is more about people trying to influence what software other people can, can run. And so I think the naughts view is that they would like the default to change because they think that has an impact and generally defaults do have impact. And I think the bitcoin developers view is the.

A (57:37)

That's the opposite. That's the opposite. The core devs are trying to change the default and Knots wants to keep it the same.

B (57:42)

No, but the, the default in, in, in the Bitcoin reference implementation they've. As I understand it, the developer's view is that they have a kind of Hippocratic oath to keep the network operating reliably, reacts cautiously to network condition changes, fix bugs, keep the network robust, keep it secure, keep it decentralized and there's an open development process whereby anyone can raise a valid Technical objection. And to my knowledge, NIBDI succeeded to do that. And I even repeat multiple times on Twitter that if anybody can develop.

A (58:20)

Adam, I responded to that on Twitter with some actual technical objections, and you ignored them. And I called you out for ignore, and you still ignored them.

C (58:27)

Okay, so I didn't see them.

B (58:28)

So. But I. My genuine belief, My genuine belief is that there are no valid technical objections. And if somebody wants to raise them, I'll go look at this thread. And if I'm persuaded they're valid and there are lots of other technical people looking at these threads, then that would be enough to pause a release, cause a bug fix, or what have you. But I simply don't think it's true. I think people have got wrapped up in some emotional logic. The only glimmer of truth in this whole thing is that maybe if we, you know, if we play Whack a Mole quickly enough, maybe we'll dishearten the spammers. But the Internet's been around for a long time. There's still people spamming, and in Bitcoin, they have a much higher payoff from spamming. Email spam payoff is incredibly low. The only thing that's really reliably working in Bitcoin is the fee market, which comes down to a block size limit and a market for the fees and proof of work. Right.

C (59:20)

Okay. Okay, Chris answered just briefly and quickly. What percent of support do you think knots actually has? And how do you figure that out?

A (59:27)

Yeah, the. The websites that show the percentages are very accurate because they're looking at a. The widest. Well, so they're looking at listening nodes. So, yeah, there's a reason why the as map thing is how it is. As Adam said, it was a low sample size and subsequent people ran the same. Ran the same exact test.

C (59:45)

Okay, so you think it's like roughly 22%?

A (59:47)

Yes. Oh, and yeah, and there is a. There is a thing with knots where there are fewer knots listening on clearnet. And there's a good explanation for this. It's because a lot of knots runners are hobbyist node runners who use things like Umbrella and Start nine and Raspiblitz and things like that. And those things generally listen over Tor. And so a lot of people who are doing analysis are not taking TOR into account at all.

C (60:09)

Okay, got it. So this is probably the most important question, and I'm sorry that we're going to have to wrap right after this, but I need to understand here. So here we have, you know, potentially a situation in which 78% of the network is going to choose one route, and Then the other 22% will choose another route. So. And they disagree. And this is, like, contentious. So is this, you know, the notion of a contentious hard fork that could result in a cheat split or. Okay, so explain.

B (60:34)

That is just what I was saying, that people on the Internet can run whatever software they want. And so the main damage from running a knots node is it creates a bit of extra load for other, other nodes which are relaying more faithfully what's going on in the network, and it slows down the knots node, but effectively it has nearly zero effect on spam and on the network ultimately. So it's not a fork issue. It's. Some people want to run some filters and some people want to run other filters, and there's nothing we can do to change their mind or stop them doing that. So I think that's fine. Right? People can. The Internet's permissionless. What are you going to do? Right.

C (61:14)

Okay, Chris, do you agree with that outcome?

A (61:16)

No. Yeah, Adam, so you said it again. You said, you know, there's, there's practically nothing you can do to stop the spam. The filters don't do anything. And I'm telling you, look, look at the chart. You know, Cliff, at 80 bytes, it's 99% reduction, going from exactly 80 bytes on up. So. Yeah, and, you know, so Laura, you asked about 20% of the nodes filtering. Adam's correct. That won't do anything other than, okay, we'll slow down propagation a bit for those, for those node runners and maybe for some other people on the network. But it's not, as far as I know, I know a bunch of people that run knots nodes and they run lightning nodes on top of knots nodes, and then they haven't noticed any problems with that. And I know a lot of people mining, you know, doing kind of home mining on top of knots nodes, and they haven't noticed any problems either. And so, you know, the argument is that, well, we need to remove this hopper term limit for your own good. But, you know, we, we understand the risks and we think that they're worth it. And if, you know, and if 80 or 90% of us are running the filters, then we've seen that that's effective. So, I mean, it might take a couple more spam attacks to get there, but I think it's, it's pretty easy. Once, once there's a, once there's a will to stop the spam that we will.

B (62:26)

There's been a Will to stop the spam since the Internet started, since 2009 at Bitcoin, there's a will to stop spam in Bitcoin. Developers and people that want to be pre filtered. The only difference is being practical about it and thinking about the economic incentives.

A (62:43)

So we should look at what worked last time.

B (62:45)

It doesn't work.

A (62:47)

It did.

C (62:48)

Okay, look. All right, so how can you say.

B (62:52)

How can you say it works after the sub one sat for V bites summer where if economically, there were various special circumstances. If economically. But listen carefully to what I'm saying. If economically motivated users want a functionality, I think a million dollars a day counts as economically motivated and miners go along with it. They are de facto going along with it. Even if the miners didn't go along with it, the spammers can rent hash rate. $1 million a day buys a lot of hash rate. If you rent the hash rate, you get to run the node and the policy. So how is that working? It works until it doesn't for something nobody has an incentive to do.

C (63:31)

Okay, Chris, go ahead.

A (63:33)

Yeah, the circumstances were very special in full RBF and subset transactions. Full rbf. The vast majority of node runners agreed with full RBF and were like, yeah, that's fine. These aren't harmful. So it's much easier for if Core is filtering something that's harmless for that filter to go away than for something that. Where Core is filtering something that's harmful for that filter to go away. So substat transactions are not that harmful and full RBF is not that harmful. And that's why Encore was filtering unnecessarily, which is.

C (63:58)

Yeah, but, but, yeah, yeah, you, you.

B (64:01)

Could say the same thing about inscriptions, right? Nobody's going to use Opreturn because they're already using inscriptions. So why is it such a big deal that it changes if they do use it? We just went through this, right? If they do use OP return, it's less bad than if they use inscriptions because it's less data, it's printable, and it costs more per byte. And if they don't use it, what's the problem?

C (64:21)

Okay, okay, you guys, we really have to wrap because we have a second live stream. But you guys, the change is going to be pushed through by Core on Friday. So I think, or at least at this moment, that's what it looks like. They changed the release before, so who knows if they'll change it again. But anyway, point is, I think we'll have to see what happens at that time, but hopefully this gave everybody a good primer of what the arguments are on both sides. Thank you both so much to Chris and Adam for explaining this to our audience. And yeah, we'll, we'll have to see what happens on Friday. All right, all right, all right. Thanks, everyone. Unchained is produced by Laura Shin, with help from Juan Aranovich, Margaret Curia, and Pam Majumdar. Thanks for listening.