Ah OK. It seems you want to discuss node centralization after discussing mining centralization. I want to discuss them together, for this reason: it seems to me that the principal argument against restoring the op_return limit is that some amount of increased miner centralization pressure is foreseeable if spammers relay their spam through private mempools instead, and this centralization pressure can be reduced by relaying spam through the public network instead. But I think the phrase "the cure is worse than the disease" applies here. Specifically, the amount of centralization pressure such activity is likely to produce is small by comparison with the even worse amount of node centralization that is foreseeable if spam is relayed by default in the most popular node software. Therefore I think the two forms of centralization pressure deserve to be compared with one another, and thus discussed together.

To that end, you asked what is the purpose of properly assigning blame. It is in response to an argument against filters that seems popular to me: that they are bad because they force spammers to use private mempools. E.g. see this letter from a group of bitcoin core devs: "Knowingly refusing to relay [spam]...forces users into alternate communication channels." https://bitcoincore.org/en/2025/06/06/relay-statement/

This argument is false because it commits the false dichotomy fallacy, by asserting that a spammer discouraged from doing bad action A is thereby forced to do bad action B. Thus, the argument blames the discourager for doing a good thing (trying to stop bad action A) when the only one blameworthy is the spammer, since he is the only one who did anything bad.

The fallacy is captured by a famous limmerick:

There was a young man from Darjeeling

Who got on a bus bound for Ealing

It said at the door, "Don't spit on the floor"

So he stood up and spat on the ceiling

The position that Core's former anti-spam mempool policy forced some spammers to use private mempools, and thus the policy should be removed, is equivalent to arguing that the anti-spitting-on-the-floor policy forced the man in the limmerick to spit on the ceiling, and thus the anti-spitting-on-the-floor policy should be removed.

On the contrary, if there is good evidence that the policy helps prevent spam that would otherwise harm the network through node centralization, then I think it should stay and continue doing that, unless the amount of mining centralization foreseeable is worse.

I am glad you are making an informed decision. :)

Also, I recommend ceasing use of bip47. Silent Payments are imo a superior way to do what bip47 does.

Also, I hope a new version of samourai's protocol becomes popular that fixes the part of tx0 that makes it incompatible with the default mempool policy in knots. If their protocol uses an op_return, it shouldn't imo.

I think spam is an important topic in bitcoin

Future me: you want to run a node? Great! There are 2 main kinds: Core and Knots. The main difference between them is how they approach spam. Core takes a welcoming stance toward spam transactions, whereas Knots filters them out as much as possible. Which one do you want to run?

I think you're trying to convey an argument or a question that I'm not properly receiving. You laid quite a bit of stress on segwit's blocksize increase and reasons for thinking I've concented to it. But I don't see how segwit or my consent to it is relevant, or what I might have said to make you bring it up in this context. Do you think it is important to understand your argument or question?

I agree that there is a centralizing effect when large miners mine spam, and I blame that centralizing effect on the people who create spam and the miners who mine it, rather than on the people who filter it.

I also think relaying spam has a centralizing effect because it disincentivizes running a node, and I think the mempool policy adopted in Bitcoin Core is directly responsible for part of that centralizing effect. By contrast, Knots is not responsible for the centralizing effect produced by golks who bypass Knots's filters.

Thus, both approaches involve a centralizing effect, and an important question is, which effect is worse? One is directly attributable to the mempool policy in Bitcoin Core, which welcomes and redistributed spam; the other is directly attributable to spammers and spam-miners who build tools to bypass Knots' filters. I think the former is worse than the latter.

> I believe it would take some ~95% of nodes to filter certain transactions before it meaningfully stifles their ability to make it to miners

I agree, especially with your parenthetical caveat. However, I also think many miners start questioning the wisdom of mining widely filtered transactions well before ~95% filtering is reached. Mining a widely filtered transaction means your block will propagate more slowly than if you did not mine that transaction, which, especially for small miners, increases the likelihood of it becoming a stale block. Making miners think twice about whether it's worth it is, imo, a good thing. Again, the more people run filters, the stronger this effect, but I bet it starts having an effect as early as 50% filtering.

I didn't have a definition in mind, but I don't think Nakamoto consensus applies here. The more people run filters, the more I think there's a consensus that they are a good idea. So I guess by consensus in this context I mean "agreement by the people who opt to run the filtering software."

Yes, it is also important to avoid address reuse, and my example does not do that

Click here to try them: https://supertestnet.github.io/bip157_playground/

If users come to consensus that filtering spam transactions is a good thing, I am in favor of it

If they come to consensus that filtering other types of transactions is a good idea, including monetary ones, then I would want to know what their arguments are for filtering those other transactions

If they are good arguments, then I am in favor of it

My latest invention is the Bip157 Playground. Learn what bip157 filters are, play with them, and consider using them in your next bitcoin privacy project -- all from the comfort of your web browser. https://www.youtube.com/watch?v=INwrf6LF2sc

not that I'm aware of

I don't think they have a recovery tool in place, so you would probably lose your bitcoins forever if the server went down. But in theory, whenever a user sends or receives money, they are supposed to get a set of signed transactions that they can broadcast in order to exit unilaterally with their new balance, without needing further assistance from the server. If the users keep a local cache of these signed transactions (which I do not think is currently being done, but it might be), then the user can broadcast them even if the server disappears, and thus get their balance out.

There is an important caveat, though: when you receive money in this implementation of Ark, the default way that happens is through something called an "out of round payment." In that mode, you *do* get signed transactions that you can broadcast at any time, but they do *not* offer a true unilateral exit. (But it's not as bad as it sounds, keep reading.) The transactions are timelocked, and some of their inputs can be doublespent by the server if he colludes with other users. If he did that, your exit transactions would be invalidated, and you would lose money.

But that is only the "default" way you receive money in this implementation of Ark. There is a second way to receive money, called an "in round payment," and if you receive money *that* way, the server does not have the ability to doublespend the inputs to your exit transactions, so you have a "true" unilateral exit.

Also, I believe this Ark wallet does something called a periodic refresh, and whenever it does this, your coins should automatically change from "out of round" to "in round," thus (eventually) giving you true unilateral exit even for coins received the "default" way. I'm not sure when these periodic refreshes happen. As a further caveat, if you "miss" one of these periodic refreshes (e.g. your wallet was offline), and you don't come online within a grace period after that, I believe your exit transactions become invalid anyway, and the service becomes fully custodial.

I recommend listening to the full podcast, because my interpretation of his opinion is not necessarily accurate. That said, he *seems* to think that a given node is supposed to relay transactions to its peers not for *its peers'* benefit but only for *its own* benefit, namely, so that blocks will get to it faster, since its peers won't have to spend as much time downloading transactions they already have.

I am glad that he seemed to concede that *if* a user wanted to run a node "altruistically," e.g. as a public service to help other people's transactions reach miners, then *for such a user* it makes sense to filter some transactions. I think a lot of users run a node for reasons that include such altruistic motives, and I suspect he thinks that's silly.

Yesterday, on Rearden Code's podcast, we had a productive discussion about the Spam Wars

My favorite clip is this, where he concedes that filtering spam would be a good idea *if* a user wants their node to help relay txs as a public service

https://video.nostr.build/17a5d138386e4358d834f3b5e5c20f3e4c72c41834ea843b3c29d4dd78ec130f.mp4

Full episode: https://x.com/reardencode/status/1981117343070900551

I'm not hal but I'll give it a go anyway

First let me start by saying how my previous browser wallets work:

I typically make two types of wallets, L1 wallets and L2 wallets. L2 wallets use experimental layer two software like the lightning network, and L1 wallets typically "just" use the regular bitcoin blockchain to transact. (I've also made some hybrids of the two.)

For my L1 wallets, I typically have code in the wallet that generates one or more addresses for the user, and somehow I need the wallet to check each address's balance. Normally, I do this by querying something called an "electrum server." Electrum is a wallet for desktop and android that uses a client/server model, where the client (the wallet itself) asks a server (an electrum server) for data about the blockchain. My wallets typically ask the server for data like, "how many sats are in address A? address B? address C?" etc.

But that is bad for user privacy. Electrum servers can easily log your ip address (which is often associated with your real-world identity) and the bitcoin addresses your wallet asked about, and then sell that info to chain analysis companies, who may resell it to other corporate surveillance firms or even law enforcement.

Bip157 and Bip158 are two specifications that were introduced into bitcoin in 2017. Bip157 offers a privacy-protecting way to run a bitcoin wallet, and bip158 offers a way for bitcoin nodes to help bitcoin wallets do that. A bip157 "wallet" does *not* query a server its addresses. Instead, it uses a two-step process to check the balance of its addresses.

The first step is to ask bitcoin nodes for a bit of data called a Compact Block Filter about each bitcoin block created after their wallet was generated -- the "start height." This Compact Block Filter -- also called a CBF filter or a Bip158 filter -- is not a full block, it's only a list of addresses that sent or received money in a block, and bitcoin nodes pass the list through a compression algorithm before giving it to the user, that way it's relatively small -- much smaller than a full bitcoin block.

Once the user has downloaded CBF filters for each block created after their start height, the second step is, they scan through each filter to see if their address is in the list -- i.e. to see if their address sent or received money in that block. If they detect a match, they request the full block from bitcoin nodes so they can see *how much* money their address sent or received in that block.

This process benefits bip157 wallets in two ways: unlike a full node, they don't have to download blocks that aren't relevant to their own wallet, which saves time and bandwidth; and unlike an electrum wallet, they don't have to share their addresses with a server and ask them how much money they contain. The tradeoff is, downloading and scanning CBF filters takes some time, and the user's wallet has to download and scan at least one filter every time a new bitcoin block gets mined. If the user's wallet is off for a few weeks, it takes about a minute to "catch up," depending on how fast the user's device is and how good their internet connection is.

My project is to make a bip157 browser wallet. There are several bip157 wallets for mobile devices and desktop machines, but none that I'm aware of for the browser. So I figured I would make one, and in the above post I'm just sharing my progress.

I hope that helps! Let me know if you have further questions.

I've made lots of progress in my quest to make a bip157 browser wallet! Thanks x.com/guggero for serving bip158 filters in a web-friendly way at block-dn.org, and thanks bcoin.org for providing libraries that let me parse them. Most of the hard parts work now!

For me, I noticed that it's only there if I set an amount

From what I can tell, it does