pull down to refresh

ICYMI: Jimmy Song debated Peter Todd over the topic of spam filters at Plan ₿ Lugano 2025. You can see the video here, starting at around 7:25:00 (yes--the video is 10 hours long)
Jimmy took the pro-filter position, and Peter took the anti. The format was 6 minute introductions followed by 3 minute rebuttals, followed by a more open discussion.

Opening statements

The moderator led off by asking the audience their pre-existing positions. About 40% of the room was pro-filter, 20% anti-filter, and 40% undecided. Jimmy's position clearly has the popular support.
Jimmy then entered into a polished 6 minute intro. His main points were:
  • Filters do work. Many nodes already perform filtering whether you know it or not, like not forwarding txs with data in the taproot annex, or tx with P2PKH outputs <546 sats. Yet, they are consensus valid and you can find them in blocks. But they're rare precisely because filters work.
  • No filters at the relay level doesn't mean the network is censorship resistant. It just means that censorship is in the hands of the miners, potentially leading to even more centralization.
To summarize: Jimmy's position is that filters do work, and that node preferences with regard to what counts as spam or not should be respected.
It was then Peter Todd's turn. Unfortunately, he did not seem to have prepared a proper opening statement, which was disappointing. I would have liked to see a more formal argument.
Instead, Peter opened by asking Jimmy to define spam. Jimmy said "non-monetary transactions". Peter then highlighted that some of the txs that nodes currently filter are monetary transactions; moreover, there is no single definition of what counts as a monetary transaction. Peter brought up Luke trying to censor SatoshiDICE, which were clearly monetary transactions. Core's position, therefore, is to not take a stance on what is and isn't spam. Peter also argued that relay filters make it harder for small mining pools to find the most profitable txs, putting them at a disadvantage relative to larger mining pools, leading to centralization. He ended with the statement that he "just wants to build systems that are resilient to how other people choose to use bitcoin," which did earn him some applause.

Rebuttals

During rebuttals, Jimmy restated his assertions that filters work, but Peter brought up a good point in that they might work in a "narrow" sense, but that it won't stop people from finding creative ways around them. This gets to the heart of the whole OP_RETURN debate, where Core's position is that while OP_RETURN filters may work to filter out large OP_RETURNs, they haven't actually worked to prevent people from publishing arbitrary data. Peter did say that it would be more productive if this debate actually moved to the protocol level, rather than the node implementation level, which was interesting.

Cross X

Jimmy asked Peter if he would support LibreRelay or Core v31 relaying 1 sat outputs. Peter said yes, but that this should really be solved at the protocol level, like pruning dust outputs. Jimmy then accused Peter of supporting spam because 1 sat outputs are clearly not monetary transactions. Peter said there are technical things you can accomplish on the blockchain with 1 sat outputs that help support monetary transactions; I didn't follow his explanation that well, but it's related to L2 protocols. Jimmy then said that Peter is assuming good use cases for 1 sat outputs, and ignoring that they'll also be used for spam. Jimmy said the developers are not thinking adversarially, that they're assuming the possibility space will only be used for good, but that expanding OP_RETURN actually opens up a huge attack surface. This earned him some applause. Peter rejected the notion that Core isn't thinking adversarially, and accused Jimmy of fear mongering. Jimmy brought up how removing the data limit in Taproot v1 is what gave rise to the millions of monkey jpegs, and used that as an example of Core not thinking adversarially. Peter said that Jimmy is simply wrong, that it was possible to put unlimited data in standard tx even before Taproot. (I don't know who's right). Jimmy said that the issue is, you don't know that would have been put in filters weren't in place. Peter went back to the assertion that even if you put in the filters, people will find ways to get around them. At this point the discussion felt like it was going in circles.

Closing statements

Nothing really new. Jimmy re-asserted that nodes should be allowed to do what they want with their nodes, and that filters are effective. Jimmy also said that it's bitcoin's monetary, not technological properties, that give it value; therefore its functioning as a purely monetary network should be preserved.
Peter said that Jimmy's vision wouldn't work because even if a bunch of nodes filter, other nodes won't, and the disfavored txs will find a way. Peter also asked what the difference is between a world in which nodes are choosing their own filters and a world in which nodes are obeying the OFAC sanctions list. (This earned applause, but I personally thought it was a bit of a straw man). Peter then said, if relay filters ultimately don't work, people will start going after the miners, and what then? Will we now demand censorship from the miners? Peter reiterated that he'd rather fix these issues at the consensus protocol level.

My thoughts

Overall, I thought Jimmy was more prepared, and my sense is that the audience was on his side (he garnered more applause). But I think I agree with Peter's position more---in the sense that I don't think this debate should be being had at the node implementation/relay level.
In the end, I don't think it's super productive to have this debate, because Core can do what Core wants---and if you don't like it you're free to use another implementation. I don't think Core's position has ever been you're not allowed to run your own filters, it's we don't want our implementation to have these filters.
Ultimately, I find myself agreeing with certain points on both sides. With Peter, i'd agree that a segmented mempool is undesirable, and that it's too hard to define what spam is. With Jimmy, i'd agree that Core could be more careful, and remember that Bitcoin is primarily a monetary network, not a technology platform. I do think filters work, but only in the narrow sense of filtering out transactions that don't conform to rules, but not in the broader sense of filtering out undesirable spam. I agree with Peter that it's better to have a debate about consensus protocol than relay filters.
Thanks for writing this up! I was going to watch this debate, but I much more enjoyed reading your recap + thoughts. You did a very nice job.
I realize that bringing up OFAC and censorship can be a straw man, but I do think there is a logical argument there. Here is how I would make it:
IF filters are effective at reducing and/or preventing certain kinds of valid transactions from making being confirmed in blocks
THEN a filter that is designed to reduce and / or prevent transactions involving OFAC sanctioned addresses would also be effective
AND we (the good Bitcoiners) would be powerless to fight it if even a single actor deployed a lot of nodes
BECAUSE the cost of deploying nodes is near zero
HOWEVER: I think proof of work mechanism in Bitcoin was developed to solve exactly this problem:
See this from the whitepaper: "If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs" is Satoshi explaining why node filtering doesn't work. He introduced proof of work to fix this.
One of the reasons someone can only add new transactions to the chain is by demonstrating proof of work is to avoid relying on a central authority or relying on whoever has the most nodes.
What do you think? (I hope I'm not running off on some tangent that actually has nothing to do with how Todd used the OFAC argument. Personally, I've tried to make the case I made here and had people claim I was diverting or straw manning.)
reply
222 sats \ 6 replies \ @optimism 16h
I'm just going to braindump something I've been worried about for a while now:
IF filters are effective at reducing and/or preventing certain kinds of valid transactions from making being confirmed in blocks THEN [cut]
[paste] CSW was right that devs have a meaningful role in the network and the courts will fuck up devs.
reply
100 sats \ 3 replies \ @ek 4h
I mentioned that here.
Because you don't want regulatory bodies to get the impression you are just allowing something to happen.
I don't want to give regulatory bodies the impression developers are responsible for what happens on the network
They wouldn’t take that path. […]
reply
100 sats \ 2 replies \ @optimism 1h
Yeah it's been on my mind for a while now.
They wouldn’t take that path. […]
Imagine being wrong in that assessment when dealing with published, signed commits. Or not seeing the full spectrum of potential damage that can be done by concern trolling, predatory litigation and "modern activism" 1. And how that influences politicians, who then direct functionaries and enforcement, who then fuck you up because they hold the guns.
Perhaps, the only feasible path out of this is to break the monopoly deployment in the field of Bitcoin Core. I thought that that's exactly what knots was supposed to be doing? No need for a consensus change, just run knots if you wanna run knots. But the past couple of weeks I've been thinking that maybe the greatest favor we can do to Bitcoin Core maintainers is to fork their software and offer a viable alternative, perhaps optimized for watchtower functionality, which is the opposite of knots. I'm not sold on this yet, but it may be worth the effort if it means they get less shit and can focus on building important features.

Footnotes

  1. I had written 6 paragraphs lamenting the misuse of the wonderful direct borderless communication the internet has given us, where instead of organizing to do things, humanity organizes to tell other people what to do, as if we're all little dictators in our own right... but I'm going to save that one for later.
reply
100 sats \ 1 reply \ @ek 1h
But the past couple of weeks I've been thinking that maybe the greatest favor we can do to Bitcoin Core maintainers is to fork their software and offer a viable alternative
I think most of what @justin_shocknet talks about is wrapped in a lot of BS but this is def one of his better ideas
reply
Haha. I'm fearful of labeling what Justin says as bs, even when it feels counter-intuitive, because he's been right in hindsight too often for that; I'm keeping an open mind. In the spirit of not telling other people what to do, I'd not pursue telling someone else to archive their repo though. If that comes, it comes through success of other efforts.
reply
ok, yeah, I follow.
Doesn't look like the courts will, so far, but rather cough cough, BIP-444, delusional clowns
reply
100 sats \ 0 replies \ @optimism 16h
We agree that BIP-444 is bullcrap. What I'm worried about is that some statements made in the past to get out under fiduciary duties impact decisions made now.
reply
Hmm, yes we've had some of this conversation before.
The part I'm most unsure about is this: "powerless to fight it if even a single actor deployed a lot of nodes". I'm not sure how effective deploying a lot of nodes is, I think network topology matters and I don't know the peering rules governing the protocol.
reply
60 sats \ 4 replies \ @Scoresby 18h
Sure, but then isn't this also true for filters? It's not so much the filter that matters as who you peer with. Well, no matter that cat and mouse filter game, the people being filtered will always just circumvent via network topology.
Result: filters always end up being useless in the face of sustained demand.
reply
Result: filters always end up being useless in the face of sustained demand.
Yeah, I basically agree with that. That's why I say that filters work in a "narrow sense". You can filter out OFAC sanctioned addresses for example, but not necessarily OFAC sanctioned people, know what I mean?
So you can filter out >83 byte op_returns, but you can't filter out JPEGs
But you do increase the cost. Just, is it worth the collateral damage caused by mempool segmentation, side channels, unreliable fee rate estimation, etc.
reply
30 sats \ 2 replies \ @Scoresby 18h
But you do increase the cost.
For how long though? I'd argue that even this increase is ephemeral unless the demand for such transactions is really quite low.
reply
I guess in the end it doesn't really matter what we believe will happen, what matters more is what we think people should do. I'm personally not too interested in doing anything regarding this debate. I think I have a solid enough grasp of the clash points already. I'm more interested in talking about how people can use bitcoin more in their everyday lives haha
I will say, though, that I think the people spouting off about CSAM are playing a very dangerous game. I think they should stop. @theariard's post today (#1269237) I think makes good points about this.
reply
30 sats \ 0 replies \ @Scoresby 17h
well said, sir.
reply
Thanks for writing this up! I was going to watch this debate, but I much more enjoyed reading your recap + thoughts. You did a very nice job.
indeed he did. Nice little snippets but also accurately and fairly portraying both sides
reply
THANKS FOR SUMMARIZING! <3
Unfortunately, he did not seem to have prepared a proper opening statement, which was disappointing. I would have liked to see a more formal argument.
Me too, this was really pathetic... dude, nobody told him how to debate or what a formal debate looks like...? C'mon, BROOO.

This gets to the heart of the whole OP_RETURN debate, where Core's position is that while OP_RETURN filters may work to filter out large OP_RETURNs, they haven't actually worked to prevent people from publishing arbitrary data. Peter did say that it would be more productive if this debate actually moved to the protocol level, rather than the node implementation level, which was interesting.
Same, lots of this surrounds "I don't like what other people are doing with our shared monetary database." It's like, cool... what else is new; also, go away -- disagreement over usage is obvious and what Bitcoin is here to make redundant and irrelevant.

Peter went back to the assertion that even if you put in the filters, people will find ways to get around them. At this point the discussion felt like it was going in circles.
100%. Same old, same old.
reply
Thanks for summarizing, since there's no way I was going to watch it.
To your point at the end about trying to address the issue at the protocol level, I've seen Knotzis argue that it needs to be at the relay level because of the dynamic nature of spam that the Coremunists point out.
It sounds like Jimmy didn't touch on what I consider to be the most important part of this whole thing, which is that it's at the relay level that we don't have prices to act as deterrents. Bad actors can freeride on the relay network to transmit illicit material that's never intended to wind up in blocks, at least as I understand the situation.
reply
42 sats \ 3 replies \ @Scoresby 18h
How is a bad actor free-riding on the relay network different than a person who is bidding against you for blockspace?
Wouldn't any rational noderunner refuse to relay all transactions but their own?
(My personal opinion is that the relay network was designed to benefit miners, and noderunners are willing to participate because it's in their interest for mining to be a game anyone can easily jump in to.)
reply
Obviously correct whatever I get wrong, but the difference is that you can intentionally put in an uncompetitive bid if you just want your arbitrary data broadcast.
It's kind of to Jimmy's point about assuming good actors. There will be people who just want to take advantage of this free transmission system who have no interest in getting their transaction confirmed. I think many people would like to support the monetary network but don't want to be subsidizing the proliferation of CSAM.
reply
47 sats \ 1 reply \ @Scoresby 17h
the fee they include doesn't really matter does it? it doesn't go to the noderunner in either case.
There will be people who just want to take advantage of this free transmission system who have no interest in getting their transaction confirmed.
To what end? What does it achieve to broadcast a valid bitcoin transaction that you intend not to get confirmed? Even if it's some kind of encoded image, who is scanning their mempool to look at such images? I don't understand how the broadcaster of such a transaction benefits in any way. If the goal is to attack: it's an attack a noderunner won't even notice unless they are actively looking for it.
I've been running an always-on node for years. I'm sure in that time there have been many transactions that showed up in my mempool and disappeared without getting mined. I don't really care though, because I have a limit on the total size of my mempool (so my node can't be DOS'd). But mostly I don't know because it's not like I'm sitting here analyzing the contents of my mempool. Node software itself doesn't even let you see much beyond the raw transaction data. Not like it comes with an image decoder...
The argument that people are using the Bitcoin transaction relay network to proliferate vile images is weird to me. I don't see it as any kind of serious threat to bitcoiners and I certainly don't see that we should be designing Bitcoin in reaction to it. Do we even have any evidence that it is happening?
reply
So, I'm not claiming it's a threat to bitcoin or that we should design bitcoin around it. I realize there are people taking those positions, though.
When you ask "to what end?", isn't it the same as whyever people broadcast this stuff over any other network. As to who is scanning for it, the answer would presumably be whoever is seeking to use the network for this purpose.
There are lots of people who consume and share child pornography already. I don't understand why they wouldn't use our network to freely broadcast it, if that's an option. Supposedly, that's exactly what happened to BSV when they increased the amount of arbitrary data that could be included.
I can't at all speak to the technical difficulties or ease of actually viewing such data as an image.
reply
To your point at the end about trying to address the issue at the protocol level, I've seen Knotzis argue that it needs to be at the relay level because of the dynamic nature of spam that the Coremunists point out.
Oh, actually the moderator did ask Jimmy what he thinks about that. I just didn't mention that in my review. I think Jimmy basically agrees with the Knots position there, that dynamic relays are needed to keep up in the cat & mouse race against spam.
at the relay level that we don't have prices to act as deterrents
actually the whole issue of the economic incentives to run a node is a big problem. I don't see enough people talking about that. Yes, the core devs do pay attention to trying to make it as easy to run a node as possible, but lowering cost is only going to do so much when the benefit is pretty minimal.
reply
30 sats \ 2 replies \ @optimism 16h
I couldn't even get past the first 20 seconds or so of Peter's turn - I guess he didn't agree with the format up-front.
reply
Maybe this isn't fair, but Peter strikes me as the kind of guy who would wing something like this. The smart guy who gets by on his talent but doesn't really prep... we all know people like that!
reply
30 sats \ 0 replies \ @optimism 16h
I'm like that. Except when I have to do a talk. Then I prep for a month.
reply
30 sats \ 1 reply \ @000w2 10h
I think the main point that is being overlooked (intentionally or not) when trying to move the debate to the consensus level is this:
Filters can adjust dynamically to counter spam as it finds new ways around old filter rules. This adaptation in real time is not something that can/should be done at consensus level.
reply
This actually did come up in the debate but I forgot to mention it, because it was primarily an interaction between Jimmy and the moderator, not with Peter
reply
I agree with Peter that it's better to have a debate about consensus protocol than relay filters.
The end conclusion will be more or less the same: it's not possible to prevent arbitrary data onchain. Trying to do so will hurt monetary use cases, and may cause collateral damage to node runners too by pushing arbitrary data publishers to cause various forms of bloat e.g. in unspendable addresses.
The solution, as ever, is to outbid the spammers. Anything else is delusion and cope.
reply
bitcoiners are duped by the definitions of words that were implanted into their heads; the words money, spam, technology, etc. are not clearly defined or understood, yet there is a lot of emotion surrounding the debate about which term is more appropriate;
people don't understand what bitcoin is, they don't understand their own language, and they go in circles like rats in a maze with no exit; the language of humans has been manipulated by the conquerors from the very beginning; once u start looking up origins and original meanings of words, u start seeing what i am talking about;
until then, people keep on using a hammer thinking it's a fork;
reply
The issue, in my opinion, and the reason we generally have the spam to begin with... is because blockspace is being underutilized.
Most of the day every day fees aren't 1 sat/vbyte. They are (.2) sat/vbyte or less in other words practically free. The spam is free. So no wonder you get blocks full of it.
I would support a block-size decrease soft-fork before I supported bip-444 or whatever... people dumping data into the Witness field isn't the problem. The problem is that they have almost nothing else (no other demand) to compete with.
No Demand? Free blockspace? Expect to get junk. More valuable space? That people have to bid for? Get more valuable transactions.
Smaller blocks would force the market to reprice blockspace... take up less hard-disk space, and ultimately make the network more efficient. It wouldn't require goofy 'emergency activation' or 'chain rollbacks' if it were widely agreed to.
Keep the witness discount but just reduce block size by like... 50%. It's simple. It's good for nodes too. Wouldn't that be better than a contentious bip?
reply