Clarification of my thoughts and a brief explanation of how I get to where I am currently for anyone interested: Miners and nodes were originally pretty much the same thing. They aren't now. What happens when the incentives of miners and the incentives of nodes become misaligned? Miners want to get revenue from any source imaginable - stuffing spam into blocks is potentially lucrative. Nodes of course do not have any immediate incentive to relay this stuff and certainly don't benefit from storing it or competing with it and paying higher transaction fees as a result. The theme coming from @darosior is that Core must do what is incentive compatible for *miners* - i.e pay attention to what it is spammers want to store in the chain and quickly or preemptively adapt Bitcoin Core as quickly as possible to relay this to prevent any large miner soliciting it out-of-band and developing a competitive edge against miners who are "stuck" with the transactions being relayed around the network. His concern compounds with the idea that if Core fails to do this, it will be unadopted and lose market share to an implementation that does. However we have seen significant migration away from Core, for perhaps the first time ever, to Knots, which takes a different approach - it concerns itself with the incentives of people running those nodes who, as mentioned, do not wish to be relaying junk data around the network and storing it for free. So if we are concerning ourselves with the incentive compatibility of Bitcoin Core, why is the incentive the actual users of that software to not participate in spam not a part of the discussion when it is so clearly relevant? Knots has jumped to about 10% of the listening nodes over the course of May from less than 2% before that. This, I believe, is where the rift between Core and those angry with Core formed because Core's response to this is generally to say that nodes are being short-sighted. Their desire to reject spam is going to undermine more subtle things in the longer term. This was expressed initially in a crude and insulting manner which further deepened the rift but - no matter how much we might want to dismiss them as genius devs somehow missing the forest for the tress - are they correct? More simply - are nodes doing themselves a disservice by opting out of the relaying of spam in the hopes that at the very least, they aren't participating in the hypershitcoinization of Bitcoin? How bad are the tradeoffs for nodes if they do this? 1. If Core is "incentive incompatible" (at least with regard to miners/spammers who both clearly want to use Bitcoin to store non-Bitcoin stuff) is there going to be un-adoption of Core? So far the only un-adoption we have seen is a (from my perspective) a few thousand nodes switching from Core to Knots - this isn't really fakeable like some suggest with AWS because you'd have need to have spun up Core nodes far in advance of this battle in order to send this signal by having them switch. The "incentive compatible" alternative is Libre Relay - this of course does the opposite of what Knots and its updated filters permit - it preferentially peers with fellow trash-enjoying nodes in what is (to my mind) a misguided effort to fight what they call censorship. Of course I fundamentally believe that censorship resistance doesn't come in the shape of nodes relaying what is against their own interest. Libre Relay is nowhere near as widely adopted as Knots. So Core, if wanting to maintain marketshare must take more into consideration what has actually happened to Core as a result of its incentive incompatible design (from the perspective of *nodes* rather than *miners*). They must convince us that Knots users are making a mistake in philosophy, not just more immediate concerns around practicalities and risks of running something that isn't Core. Those are valid of course but let's assume Core and Knots are of equivalent standard and reliability and just focus on differences in approach and design philosophy here as its what is relevant to this discussion. 2. If we filter spam, fee estimation will get worse. It can get better actually, assuming there is one decently sized miner on the network respecting those filters. There is of course - most of the DATUM miners on OCEAN use Knots with fairly close to default policy so this can prevent you from *overpaying* fees. The worsening of fee estimation in the other context - accidentally underpaying because there's so much unconfirmed spam that you just aren't aware of - is much easier to correct for. Simple RBF will suffice. I don't think it's anything anyone can really care about due to the unpredictable nature of the blockchain anyway. You have no idea if you'll be in the next block or not. The extent to which you do is the extent to which we "know" what *should* be in the next block which is basically just an artifact of centralization and a mistaken celebration of that fact. You don't know who will find the next block, what will be in it, how long it will take, or how many other people are going to jump in "the" queue after you broadcast your transaction. Core's heuristic around fees work well without knowledge of other people's mempools, this is by design. Thus, I have widely asserted that concerns around fee estimation are nonsense with the above reasoning and I have yet to have anyone dunk on me with some superior understanding. 3. Block Propagation will be slower if we filter spam. Mining will centralize in general. Slower block propagation sucks for small miners trying to be part of the big club as Antoine points out. The big boys will have a private intra-relay network - a walled garden in which you must belong to not be at a disadvantage with necessarily slower verification times. Firstly - if you filter something that still generally makes its way around the network, you'll cache it and your verification speed will be just as quick as if you didn't filter so this is a non-argument. I genuinely think most people, including Core devs are just unaware of `blockreconstructionextratxn` so they believe there to be an issue that there just isn't. But what if the filters are so effective that the private club has to solicit this stuff out-of-band and it never existed in the first place to the filtering nodes? Then I say we are screwed. These miners control the blockchain at that point. We have concerns orders of magnitude more significant. They can reorg the chain, make double spends and generally wreak havoc. The fact that they haven't is not something we can rely on hence the need to actually decentralize mining not just screw around and make a gesture of concern in relaxing spam filters in the hopes that it doesn't get slightly worse. We are at this point already so I have no idea why we are discussing inconsequential factors such as spam mitigation vs enthusiastic relaying as though it has any relevance here. Foundry can already 51% attack the network. --------- This is roughly how I end up at my position - being a vocal advocate for putting the incentives of those running nodes over anyone else in the ecosystem. I do not consider spammers to be "Bitcoiners" but even I did, their needs would be always placed further down the food chain than those of nodes. Just as they were with those who wanted huge blocks for permanently cheap transactions. The rate at which I am having to revise and reevaluate my position has rapidly decreased compared to a few weeks ago where admittedly I was making far more technical inaccuracies than now. Everything I read from Greg Maxwell or other long standing and respected developers in the space goes along familiar lines at this point and fails to justify this new, laissez-faire approach to spam attacks that carries a heavy burden of proof versus adhering (as Knots does) to Bitcoin's historical precedent where folks none other than Greg himself would propose extreme counter measures to spam should some new protocol for shitcoining-on-bitcoin suddenly hit escape velocity and start creating a genuine problem for Bitcoin nodes.