Unchained - Bitcoin Core vs Knots: Why Developers Are Fighting Over a Coming Change - Ep. 918

Episode Date: October 7, 2025

On Monday, bitcoin hit a new all-time high of over $126,000, but Bitcoin’s biggest fight right now isn’t about price; it’s about purpose.  Since 2023, image files and meme tokens have clogged the network, spiking fees and making everyday payments expensive. Bitcoin Core wants to lift an 80-byte data limit that's existed since 2014. Bitcoin Knots disagrees — and has built code to enforce a different limit. Should Bitcoin stay a payments network, or evolve into a platform that stores everything from NFTs to memecoins to experimental layer 2 protocols? Blockstream CEO Adam Back and Bitcoin and Lightning developer Chris Guida debate whether removing limits on OP_RETURN protects Bitcoin from what they call “spam,” or opens the floodgates to it. Plus: the real lesson from 2014 when Vitalik Buterin left Bitcoin, why miners can bypass any filter by renting hash rate, and whether 22% of nodes running different code actually matters in a decentralized network. Thank you to our sponsors! Mantle Aptos Guests: Chris Guida, Bitcoin and Lightning Ecosystem dev and Educator Adam Back, CEO of Blockstream Timestamps: 🎬 0:00 Intro ⚙️ 1:37 What the Core vs. Knots debate is really about 🧩 4:46 Why “spam” filtering and “censorship” aren’t the same 💾 7:28 How NFTs, ordinals, and BRC-20s created the “spam” problem 🧱 8:51 The Genesis block message vs. today’s onchain data 🔍 13:27 What op_return does and why its size limit matters ⚔️ 22:04 Why the proposed change has split the Bitcoin community 📈 26:25 Can Bitcoin stay censorship-resistant while filtering “spam”? 💣 30:26 Do economic incentives make “spam” filters useless? 🧰 34:17 Why some believe filters still work to protect blockspace 💰 36:05 Would higher fees from non-payment data help miners secure Bitcoin? 🧮 42:06 Does more data make it harder to run a node? 🧭 46:04 Can Bitcoin fight storage data without hurting its core principles? ⚡ 50:37 What counts as a “real” layer 2 on Bitcoin 🧱 55:55 How much support the Knots software actually has 🧩 1:00:35 Could this debate cause a Bitcoin chain split? 🔚 1:04:22 Closing thoughts on what’s next for the network Learn more about your ad choices. Visit megaphone.fm/adchoices

If Bitcoin has to be saved by cramming data into blocks and 100% of the activity on Bitcoin is data and 0% of the activity on Bitcoin is payments, then can you really call Bitcoin money anymore? I think there's a lot of people mad about spam and they are 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 look in more than one step. Of course. Hi, everyone. Welcome to Unchained, your no-hype resource for all things crypto. I'm your host,

Laura Shin. Today's episode is brought to you by Mantle and Optos. Mantle is pioneering blockchain for banking of revolutionary new category at the intersection of Tradfi and Web3. Follow Mantle underscore official. to learn more. Aptos is the no-compromise infrastructure for global financial markets, fast, reliable, and 100 times more cost-efficient than other blockchains. See for yourself why Aptos is the chain of choice for institutions, users, and developers alike at the Aptos Experience, October 15th and 16th in Brooklyn.

Today's episode is about Bitcoin Core versus Bitcoin knots. Here to discuss are Chris Guida, Bitcoin and Lightning 8, system dev and educator and Adam back, CEO of Blockstream. Welcome, Chris and Adam. Laura, thanks for having me. Bye, everyone. So the Bitcoin Core versus Bitcoin Nod's debate has been brewing for some time. And the two of you are on opposing size of this debate. But before we get to the debate portion, let's make sure that the audience has the necessary background to follow the conversation. Can you each give your perspective on what the debate is about and how it started? And Adam, why don't we start with you?

Well, spam is probably as old as the internet itself and sort of an arms race, if you will, like it seems impossible to outright stop it. And so people engage in various attempts to fight it. And the attempts to fight spam can have side effects. And how are you defining spam in this situation? Well, I mean, that's an interesting question in the Bitcoin context, right? But an uncontroversial one that I think most people dislike, apart from, of course, the

Span industrial complex that is spending with Indolzei on fees is the image span because it's grotesquely inefficient, right? So of course, there are other kinds of spam which get increasingly gray, but maybe we can look at the image span because that's something more. plausible that you could do something about. And by there, you're talking about things like ordnals or any kind of NFT-ish type thing on blockchain on the Bitcoin. And I mean, like to my mind to be super strict about it, it would probably be anything

that's like a non-transaction information on the Bitcoin blockchain. Would that be like more comprehensive? I mean, it's a little gray because there are 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 coin join type things, the samurai wallet uses something. So there time time is not necessarily

financial related but the rest are financial property I think where people start to push on Aldenals well sort of

other assets on top of Bitcoin gets pretty grey right because there are many brocars going back to MasterCoy on me which tether rides on and probably some of it's kind of body, everything.

Yeah. 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 Nots versus KOR is about? Yeah. Cool.

So, yeah, thanks for you. 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 span filtration could be seen as an attempt to censor. And just to, so because you are on this side of. nots, which, you know, for people who have been following this, they would consider that side as more kind of pro-censorship-ish. You can dispute that if you want, but as a point is,

how does your side define spam on Bitcoin? 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. And would you agree with Adam that the kind of main catalyst, because, you know, 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?

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, you know, for lack of a better term, shitcoins or as like I like to call them, on altcoin Ponzi's. And these cause a lot of disruption on Bitcoin because they cause something called UTXO set bloat, which maybe you're 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, for example. And just to explain the UT explode, like basically, I saw this in a, you know, so I'm going to say 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 like what they're trying to do is to not have that waste anymore.

That's like part of the change that they want. Yes. Yeah. Basically, there was a thing called BRC20 that happened during 2020 and 2024. And it was basically, yeah, an alt-coin Ponzi protocol for NFTs or FT's, hundredable 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, you know, if we just raise it to 100 kilobytes,

I mean, there's all sorts of other nasty things that might happen as well. And one last thing that I wanted to ask because, you know, famously Satoshi in the very first block of the Bitcoin blockchain included something that was like non-transaction data, which is the message, the headline from the Times of London. And I wondered, does that fall on the same category of things that we're talking about or no? It doesn't. So in one sense, it's sort of a superficial sense it does because it is data that is in the blockchain. But in sort of a relevant sense, it's completely different because it's not spam. 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 is this chancellor on the brink statement. So, I mean, yeah, 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 it really, there's no way for it to be abused for spam in the same way that these alt-coin ponzisies are doing. 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, you know, what you think this debate is about. and hopefully your internet is a little bit better. Yeah, my internet's plenty fast, so I try 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 unobiguously 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 masterquiretimore. One, labor branded to Omni, Counterparty, recently BSC20 Rooms, which carried a bunch of Neme coins, I think, over 100 million outputs, probably mostly abandoned when they got rub-pulled, and about 3.5 million images. And also, you shouldn't forget, RGB and taproot assets. So, you know, the knots is blocking some of those. And I think it gets pretty great because some of them can be used to carry tether, probably some bank, you know, demo or actual...

Which ones? Which ones is not blocking? So one of the BRC 20 or Roon, I think they set the... I mean, they block a bunch of stuff, right? They block lightning truck fix. They block one of BSC20 or ruins because the other one is less wasteful. They block some samurai. 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. 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, and mine them, then 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 Nott's, you know, before the spam drama has been having some kind of pedantic argument with samurai wallet and block in their mixed protocol.

So Nott's get to, you know, just, I'm just saying it's gray. And it's not clear which is worse, actually, because, you know, we're focusing on the image span because just clearly an ambiguously wasteful of block resources. But just to be clear, Nott's is not blocking whirlpool transactions, like the privacy related transactions intentionally. That's not intentional. That's just an artifact of the privacy guys being a bit hard to deal with. I've actually had conversations with them on Twitter like, hey, you know, how much space do you need? 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 you're not actually yeah let's just say it takes 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 that's about the spam yeah let's so I feel like you guys are getting a little in the weeds. So let's just keep zoomed out just for one more question. So basically what is happening is, 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 op code. And op codes, you know, are kind of like sort of the instructions for how the Bitcoin blockchain is coded. And it's called Op Return. And this would allow, you know, arbitrary data or messages to be embedded in Bitcoin. blockchains and in Bitcoin transactions. And this is kind of at the center of what this Bitcoin

Core versus Knott's 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 Nots is against that. So maybe Adam, why don't you explain like what Bitcoin Core is going to do? And then Chris, you can explain what Knott opposes and prefers. I mean, I think it's a bit of a red herry, really, because OPP return has been standard one megabyte. Well, actually, sorry, I should say consensus valid. So that's 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 rule really. It's not enforced by minors or four notes. So it's pretty easy to bypass it if somebody really wants to. And so then the recent wave of spam, which, you know, agitate people, basically started in the old coin winter when Bitcoin VC funding doubled, an old coin VC funding dried up. And so a number of old coins relabeled themselves as Bitcoin layer twos and bought

their kind of meme coins and NFT collections to Bitcoin. You're talking about starting in 2022? 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 any time 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 original introduction of operatin in this format in 2014 was reactive to people, spamming or more like lazy application developers putting app, small app messages in inefficient ways. And one of the most inefficient ways to heart 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 in an address. And that actually is pretty bad because it gums up the UTXSysnet, which is the least scalable part of running a node.

So that will overload you a node faster than anything else. And so they, you know, this debate in 2014 has already 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 my node up. point of the up return is it doesn't need to go in the UTXA. And so it's less novel.

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 BitVie. protocol and they wrote up a paper implementation saying well they were going to store 80 bytes and the policy limit and then two fake pub keys because what they had their anchor didn't fit and so you 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 will take off or not, it's a new protocol.

But once people implemented things, they weren't generally want to change them for backwards compatibility reasons. And so they proposed 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. So a full RBF was one example, 98% of minors were. Mining those before Bitcoin adapted policy, before the code adapted the policy to catch up. And the fee rate, minimum fee rate drop and below one sap of V byte, is another great example. We could talk about that more. That's also recent and another feature in Bitcoin 30. And so then the reaction to increase the op return is to say, well,

up 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 descriptions. Because preferable, we don't do it at all, but given that we don't see it, but prevent that, particularly in a decentralized and 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 our return. 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 worst thing. Okay, wait. That's the start. Yeah, you explain 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 return, sorry, the op return limit, I think currently is 83 bytes. Am I correct about that? That's the pulse at limit, yeah. 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 put a camp on a, which would effectively raise it to four megabytes. So for, again, non-technical people, that's raising it basically from 83 to essentially 4 million, which is like a huge... One million. If I'm wrong at that, or what?

One megabyte. Oh, it's one megabyte. Oh, okay, okay. Well, still, 83 to 1 million. 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 works. And wait a second.

And we're also getting things across the bit because if people care about the filters and policy, there's 100 kiloby limit on transaction size, but realistically, policy doesn't prevent that much. That's what people have learned over the last few years. So I have a lot of responses to all of those things. Okay, go ahead, Chris. I don't think that's a correct. Well, okay, so you, the CoreDabs 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 puts 64 bytes into the UTXO set. And, you know, and the BRC 20 put like seven gigabytes into the UTXO set. So, and furthermore, if you look at how the Citrius BitVM bridge works, that transaction is never supposed to happen. So the rationale for creating the, for ripping out this very useful filter, the operator filter, which has existed for decades without any side effects. I know that you say there are side effects, but I haven't seen any evidence for these side effects. But so anyway, the rationale is, okay, they might put 64 bytes into the UCXO set.

So we're going to completely remove this filter that prevents, you know, that generally prevents spam and discourages people from spamming. And it doesn't fix the problem. The problem that is being solved is tiny and effectively non-existent. And then the fix is much, much, much worse than the disease that it purports to cure. And wait, I'm sorry, Chris. So why is it so much worse? Just to explain why you guys are so opposed?

Yeah. So what happened is in 2014, as Adam said, we agreed that we would give these applications, this lazy application developers, a little space of 80 bytes where they could put, they could put arbitrary data to build their applications. And that was the limit. That was nobody wanted, you know, 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 Rodhamor found a hack, which is called the inscriptions hack, or the inscriptions. It's called inscribing, I guess. And it's a way,

it's a different way of putting arbitrary data in the chain, which is not filtered, right? He found a way to sneak data in a way that notes would still relay, even though it violated that lead-bite limit that everybody agreed to in 2014. And so what happened is there was a bunch of spam. There were a bunch of alt-coin Ponzi's that launched on top of this new type of embedding data, and this caused a bunch of UTSO blow, even, you know, even though inscriptions are not stored in the UCCO set. So this, oh, you know, operturns are not stored in the UTXO set, so they won't cause UTXO 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, be merchant nodes or lightning routing nodes were struggling to sink 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 Iquencore could have completely prevented this, if they had just filtered inscriptions in the same way that operturn is being filtered. And so, you know, this went on for three years.

It's got more expensive to run. And then finally, court notices that there is UCX-O-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 operterner. out but 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, you know, the reason why I left Bitcoin and went and made my own blockchain is because the Bitcoin core devs would be at work. And so, you know, 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 operturn limit is the opposite of that. It encourages the spam. Okay. I 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 know, what a lot of people. Spam. Spam. Spatification 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 very difficult to censor Bitcoin even with widescrypt. Even if everybody, you know, 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, but what you can see, 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, so censorship and span filtration are different things. Censorship is trying to entirely block a transaction. As Adam already noted, this is impossible in Bitcoin. You can't be like, you know, somebody can't put that piece of data on the blockchain and just like 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, you know, 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 opertern filter results in 99% fewer operterns 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. Let me. Let me.

I shouldn't assume bad facts. I can debunk all of that. So the point is that because Bitcoin is a censorship-resistant network, as we just described, it's floodfill. So there are many routes through the network. And so consequently, it's going to be pretty hard for filtering to work. So it's distinguishing policy and filtering. So it should be clear that there are some policies that work quite well in the network. 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, you know, the sort of filter on the maximum size of an op return is another common policy. And those policies have, you know, changed de facto in the network in pretty dramatic or remarkable ways that loss be used. So, for example, full RBA. If that was a policy that completely broke, basically miners and users decided 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 13. I mean, so Bitcoin 30 has three major features. One is truck, which is a fix for a lightning painting attack also implemented as a policy. Another is the sub 1SAP 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 1Sat but V byte. So there's some interesting facts with the Bitcoin network. Each node is connecting to lots of other notes and say what has been observed in Pyrically 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, you know,

there's many ways that data can wrap through the network, and just organically connecting at random, that means that a sort of tolerant minority can change a policy or a filter from working to not working. And that was the case with the one 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 it 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 full, Bitcoin price has gone up, one sap of V byte was too high. So minors went along with it. They changed their nodes. And what do you know? No, 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-on-sat per V-by change, and that's one of the changes in Bitcoin Core. Full RBF, I mentioned that happened in the past, and the Bitcoin developers felt that they were behind the times. It got to 90% 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 Rop returns is effectively 100 kilobytes. Right? 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 big those show possible. And we'll be right back.

Mantle leads the establishment of blockchain for banking as the next frontier. YouR is the access layer that transforms Mantle Network into a purpose-built vertical platform, the blockchain for banking that enables financial services on chain. You are unifies and vertically aligns Mantle's focus on payments, trading, and assets. MI4, METH Protocol, Functions FBTC, supported by developer grants, ecosystem incentives, and the industry-leading distribution platform through the UR app, Reward Station, and By-Bit 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 Mantle underscore official to learn more. Over 3.4 billion transactions processed without disruption, more than $1 billion in stable coins circulating, over $720 million 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 DM project at Meta, APDOS is what blockchain performance looks like when it's built for global financial markets. Discover why global institutions like BlackRock, Franklin Templeton, and NBC Universal are building on APDOS,

and see for yourself at the APDOS 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. Okay, yeah, I'll try to be brief. Can you hear me? Yeah. All right, perfect. Yeah. So Adam introduced two examples where filters that were filtered by default in Bitcoin Core were circumvented and eventually core sort of surrendered and ended up turning off the filter. And this was full RBS in 2021, 2022, something like that. And then much more recently sub-sat 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 will 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 counter example to the claim that filters never work, of course, is the operand 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 existence since 2014. It has attenuated the amount of operturns 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 base a high volume spam attack of the type that we saw on inscriptions, obviously, because inscriptions were standard and being were being relayed. Nobody would make an alt-point Ponzi meta protocol on top of this. operturns right now because opposites are not standard and those transactions would not get relayed. So I think it's time for poor to stop saying filters don't work. I think a much more interesting conversation is filters work sometimes. And then we can have a discussion about when do they work and when did it not work. And I think there are very good explanations for why those two examples

have brought up happened that way. 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, you know, everybody knows that there is this question about the sustainability of fees, transaction fees for Bitcoin. You know, obviously, like the block reward will continue to be produced until like 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 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 not. Yeah, I think that's fud. I don't see a reason 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 fees in two different ways. There's a block subsidy, which is new bitcoins. Right now is three and an eighths, uh, every block. And the fees are much, much, much, much, much lower than that. Um, so, so there's a subsidy and there's the fees. And those are

the two ways that miners get, get, um, get fees. And as, as, as you mentioned, Laura, um, over time, as the, as the, as the havings continue to happen, eventually the subsidy is going to go from three to three to three and eighth to zero, you know, hundred 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 not really a, that's not really a thing that can happen. Like if all the miners are earning less fees, then their hash rate 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 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 cramming data into blocks and, you know, 100% of Bitcoin of the activity on Bitcoin is data and zero percent of the activity on Bitcoin is payments, then can you really call Bitcoin money anymore? I mean, at that point, it's not money.

So, I mean, I think it's really important that money and pay. payments the dominant use case. And the only way to ensure that is by trying to rate limit these low value use cases that compete with high value use cases. I share Chris's view that that's a bit of 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 that the, you know, the arguments about the op return parameter seem to be a bit confused because I think both sides will admit that type rate inscriptions are four times cheaper, so it's unlikely that spammers would be motivated to use op return for large data items. I mean, they would for small data items, fish. And then the second point is, even if they did use it in the alternative to using tap root 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 know, 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 nose, less data, and printable else. pose. Yeah. So the specific threat is that, so as we know, shit coiners 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 the descriptions. We saw this with BRC20. We saw this with Rooms. You know, BRC20 was like, oh, there's a fungible token protocol on top of this new data embedding

protocol inscriptions, which uses ordnals, and so that caused a craigs. And then Casey was able to kind of help kill VRC20 by introducing Rooms. And that was popular because, oh, it's this new way of encoding data that was created by the creator of ordinals. And so that caused the hype cycle. It just needs to 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 opertern filter is that some D-Gen is going to make a meta-protacle on top of operterns 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 load, I mean. And it probably will be even worse because now we've rolled out the red carpet for the spammers. And we said, yeah, come on in. You know, all you Ethereum people, come on in. We don't, we don't mind. Okay. I think that's mischaracterization that anybody wants to spam.

The Bitcoin developers that your maligning have been arguing against spam since 2010, maybe before, right? That's even why the operative 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 operett, the taproot rules with new things, and people were spamming before that. And if you were- 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-20s. So the worst threat is these Alt-C-Metoproticles. Well, I mean-Fetroval. Okay, so actually, let me think. 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 centralization 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 acknowledge for for what core is trying to push through 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 of a lot lower overhead for a node because the thing that slows a node down at worst is the BRC 20s, lots of abandoned UTX is, large UTXA set. So actually, you know, an image, a, a blockchain full of images is actually the simplest and the lightest thing for a node to process, right? But that's nothing anybody wants.

So it's kind of a, right? But that's not what they do, right? They create these meta protocols on top of the images. And that's where you get these, um, this damage. Uh, what do you mean metapro? Because of split images? You mean, but I think we're mixing two things. the image span which is large the other is these small items like omni counter party bc20

fake pub keys taproot assets rgb right so if you 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 taparoo, you could soft fork out Segware, because 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, you know, deprecate operant. And now let's say that the old coin 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 EGXO sets. I think in a way, even though the image spam is the most gratuitously waste in a look at in simple way, in some other ways in terms of node overhead and an impact on the functionality of Bitcoin,

these small data items that are for meme coins are actually more harmful. And, you know, pushing, you know, incrementally pushing down and 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 rise, then it's sort of, you know, I use this analogy of the Star Trek thing, right? their Klingons, the Vulcans, and the Ferengades. 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 look at more than one step. Of course. So basically, Adam, if I'm understanding a position, it's that you're not for, like, things like BRC 20 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, unsafery options. Is that kind of the way to think about it? It's like it's futile to fight this. So might as well figure out the best way to, you to, to, um, allow it that, you know, results in the least harm to Bitcoin. Is that a way to summarize it? It's not exactly futile, but you've got to be careful that the cure isn't worse than the problem, right? And that's, that is effectively the frustrating reality that led to the creation of Opper Return 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 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 an architecture, right? It's 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 the bearing minds that 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 transactions processed. And even if you completely, 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 rates and then they can process themselves. And the cost of cash 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. 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 cat can kind of easily win. You said that Bitcoin is hard to do spam filtration on. I disagree. 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 the filter less easier. Yeah. And so, but to your broader point, I don't disagree with any of those things. Of course, some, you know, looking into the future and, and looking, considering second and third order of effects. You know, it's just, I think that the second and third order effects of, um, uh, a friendly stance towards spam is, uh, is much, much worse in the effects of, uh, being, being hostile to spam. And so we have weak tools like, like filters and we have strong tools like a temporary software or whatever, um, 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. 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 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 Nott's wants to do

would effectively, you know, kind of block things like Citria. and lightning that are, or I don't know about lightning, sorry, Citria that are trying to, yeah, I'm a lightning right, 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? Sorry, what do they find hypocritical? Oh, that your side wants to prioritize the use of Bitcoin as money and Citria would further that use, and yet you're, yeah, yeah, okay. So my stance on this. is a little bit nuanced. So there's things that are applications and things that are layer twos.

And I have a little bit of a hardline stance on this. I think that lightning is a real layer two, and I think that arc 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 two, whereas Arc and Lightning are, is because Arc and Lightning has something called unilateral exit or trustless exit. So that it's a completely trustless layer, too. 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 a one 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 Citriac, is Citriac, coming in and saying, we're going to stuff our data into fake pub keys, which is something that all Bitcoins know is you're just being a jerk if you do that. You're just being hostile if you do that. 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. And basically taking something that everybody came to concesses 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, you know, accommodating them, but they're not. So I don't see why we need to bend over backwards to filter their, to relay their traffic. They were going to do it anyway. They weren't asking for the change. Exactly.

And Citri and that's exactly the same pattern as Ophreturn in 2014. people doing things without 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 slide chain kind of payload, or, you know, if you have a fetament in one of those, think that'd be pretty cool, very high-scale, very private. Sure, I mean, again, all those things are cool, and it's fine if they build them.

Let's just not redefine Bitcoin. I mean, it's exactly the same pattern. So, I mean, if you're saying you would want to block Citri-at in 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 a fake pub keys, right? No, no one is forcing them to do anything. Like, we all agreed in 2019, the 85 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. Well, okay. I mean, yeah, I mean, I guess. Yeah, 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.

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. You know, like, and this has been here for 10 years. It's not some new thing. You know, everybody knows this. Yeah. So let's not talk about this disagreement, because this is probably the big cahoona 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 try to kind of gather all the data around this, but I can't make sense of it myself. So if you just go to Coin Dance, which has long been used

for these types of, you know, what did the minor support type questions in Bitcoin? It kind of looks like Bitcoin Notts is at about 22% of support when you just look at the notes. But as far as I can tell from people who are far smarter than me, they've been talking about using something called ASMAP. I don't know 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 so, yeah, so I might have gotten some of the tactical 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 it out. Let me give it a go, because I think we may not disagree, which is, I think some of those initial reports were two smaller samples that to be meaningful.

I think it's hard to say, it depends. It doesn't necessarily. And they 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, you know, even if Nauts got to 90% or 99% or 100%, it wouldn't stop the span. Well, okay, but Adam, regardless of, of, sorry, yeah, just how, how, what, so what do you think is the actual number of how much support there is for Nott's? Like, do you have a way of figuring that out? I'm not sure.

I mean, it's a lot of people that are economically interested. They're not running notes. And, of course, the drama, you know, the discovery of the drama, cause 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-2017 discussions, 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 pay-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 run. And so I think the Nauts view is that they would like the default to change because they think that has impact. And generally, defaults do have impact. And I think the Bitcoin developers view is the... That's the opposite. That's the opposite. The core devs are trying to change the default and not wants to keep it the same. No, but the default in the Bitcoin reference implementation, as I understand it, the developer's view is that they have a kind of hypocritic oath to keep the network operating reliably.

It reacts cautiously to network condition changes, fix bugs, keep the network report. first, 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, nobody's succeeded to do that. And I even repeat multiple times on Twitter that if anybody can develop. I responded to that on Twitter with some actual technical objections and you ignored them. And I called you out for your record and you still ignore them.

Okay. So, Chris, my genuine belief, my genuine belief is that there are no valid technical objections. And if somebody wants to raise in it, I'll go look at this thread. And if I'm persuaded, they're valid and they're lost all the technical people looking at these threads, then that would be enough to pause a release, to cause a bug fix or whatever. 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 them all quickly enough, maybe we'll disarm the spammers. But, you know, 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? Okay. Chris, answered just briefly, what percent of support do you think Knotts actually has, and how do you figure that out? Yeah, the websites that show the percentages are very accurate because they're looking at the widest. Well, so they're looking at listening nodes. So, yeah, there's a reason why the ASMAP thing is how it is.

As Adam said, it was a low sample size. And subsequent people ran the same exact test. Okay, so you think it's like roughly 22%. Yes. Oh, okay. And yeah, and there is a thing with knots where there are fewer knots listening in clear net. And there's a good explanation for this.

It's because a lot of knots runners are hobbyist node runners who use things like umbril and start nine and raspyblitz and things like that and those things uh generally listen over tour and so a lot of people who are doing analysis are not taking tour into account at all there's 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 70% of the network is going to choose one route and then the other 22% will choose another route so that 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 slit or, okay, so explain that. It's 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 nodes which are relaying more faithfully, what's going on in the node 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? Okay, Chris, do you agree with that outcome? No, yeah, Adam, so you said it again. You said, you know, there's practically nothing you can do to stop the spam, the filters don't do anything.

And I'm telling you, look at the chart, you know, I think that's no the opposite. The 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. Adams correct that won't do anything other than, okay, we'll slow down

propagation a bit 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 Nots on top of Nots nodes 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 NOS nodes and they haven't noticed any problems either. And so that, you know, the argument is that, well, we need to remove this hopper term limit for your own good. But, you know, we understand the risks and we think that they're worth it. And if, you know, and if 80 or 90 percent 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 pretty easy once there's a, once there's a will to stop the spam. that we will. There's been a will to stop the spam since the internet started. Since 2009 of Bitcoin, there's a will to stop spam in Bitcoin developers, and if people that want to be pre-filter, the only difference is being practical about it and thinking about the economic incentives. We should look at what worked last time. It doesn't work.

Okay, okay. All right, so I, you guys. How can you say, how can you say it works after the, the sub one sap of V-byte to summer, where if economically... There were various special circumstances there. If economically, but listen carefully is 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. One million dollars a day buys a lot of hash rate. If you rent the hash rate, you get to run the node. in a policy. So how is that working? It works until it doesn't for something nobody has an incentive to do. Okay, Chris, go ahead. Cool. Yeah, the circumstances were very special in full RBF and subset transactions.

Full RBF, the vast majority of node runners agreed with full RVF, and we're 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, then for where Core is filtering something that's harmful for that filter can go away. So subset transactions are not that harmful and full RBS is not that harmful. And that's why, and Core was filtering unnecessarily, which is why. Yeah, you could say the same thing about inscriptions, right? Nobody's going to use up return 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 prunable, and it costs more per byte. And if they don't use it, what's the problem? 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 woman, 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 like what the, you know, arguments are on both sides. Thank you both so much to Chris and Adam for explaining this to our audience. And yeah, we'll have to see what happens. on Friday. All right. All right.

Thanks, everyone. Unchained is produced by Laura Shin with help from Juan Oranovich, Margaret Curia and Pam Majumdar. Thanks for listening.