When the block size limit was replaced for the block weight limit (and therefore de facto increased from 1MB to 4MB worst case), the general consensus seemed to be that that was acceptable. And if you're running a Segwit-compatible node, I'd say that is in fact what you opted in to.

If you think increasing the block size/weight limit was a mistake (not an unreasonanle position imo) I'd say the solution is to decrease it altogether. (Or maybe run a pre-Segwit node...)

But let's leave that aside, at least for a moment?

You blame the spammers and these miners for the centralizing effect on mining. Fair enough. But the spammers probably don't care, and these miners even benefit.

So what does blaming them solve? (Or is that maybe beside the point; are you not interested in finding a solution for this?)

Reply to this note

Please Login to reply.

Discussion

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?

So polite

No that was me addtessing your node centralization concern.

I think they are more-or-less seperate topics that are probably best discussed seperately, which is why I suggested we park that issue for a moment and focus on the mining centralization issue first.

But we can also explore the node centralization issue first if you prefer?

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.

Right, so if I’m understanding you correctly, you think that if blocks are consistently full, that creates too much centralization pressure on nodes?

In that case, it doesn’t really matter if blocks are full with monetary transactions or dickbutts though, right? (If anything, I think dickbutts would be better in this specific context, because these are actually easier for nodes to process than monetary transactions with signatures etc.)

Sounds like you misunderstood my argument, which is not that *standard* transactions create additional centralization pressure on nodes, but that *spam* transactions do

I think it matters that some blocks are full of dickbutts. It matters in a similar manner to this: imagine you ran a popular forum for discussing Justin Bieber. But one day you visit your forum and see a bunch of posts containing jpeg dickbutts, and learn that instead of discussing Justin Bieber, a bunch of spammers decided to use your server as a file storage for their NFTs. It would be strange to say, "Well that's no concern of mine, if people want to use my server for dickbutts, great!"

If people use your server for something contrary to what you intend it for, it's a technical problem. I think there are a lot of bitcoiners who want their blockchain to store *standard* transactions, not dickbutts, and they want their mempool to *relay* standard transactions, not dickbutts. Filters effectively help. Specifically, they stop your mempool from relaying the most common formats used to share dickbutts on nodes, and when widely used, they also disincentivize at least small miners from mining dickbutts. That is a technical solution to a technical problem. Which is why I think filters are good and important.

My Justin Bieber forum is already completely centralized, fewer or more dickbutts does not affect *that* aspect whatsoever...

Let's find some common ground here.

Do we agree that block size and decentralization are inversely correlated?

Bigger blocks = more node centralization

Smaller blocks = less node centralization

(I'm simplifying a bit here, but I believe I'm simplifying in favour of your argument.)

Yes

Do we also agree that *for the purpose of node decentralization* it makes no difference whether a block contains 1MB of monetary transaction data or 1MB of OP_RETURN data?

(Again simplifying a bit, but I believe in favour of your argument.)

No, I think 1MB of OP_RETURN data creates additional centralization pressure that 1MB of monetary transaction data does not

Why would that be the case?

Because spam discourages users from running nodes

I used the analogy of a Justin Bieber forum to highlight this: users want their server software to do the things they had in mind when they started running it. If "storing NFTs for use in altcoin marketplaces" is not one of those things, and yet other people are in fact using their server software to do that, then that is a technical problem. If they see no way to remedy the situation, it may very well discourage them from continuing to run that server.

In the case of a Justin Bieber forum, I think its host *wants* to serve the text of posts about Justin Bieber *without* becoming a file storage system for NFTs. In the case of bitcoin, I think it varies more, but a large number of its node runners want to serve monetary transactions without becoming a file storage system for NFTs. If their server is filled with monetary transactions and very little spam, they will probably be delighted that their server software is working well and doing what they want. But the more spam there is on their server, they may become increasingly dissatisfied with the software, and stop running it. Just like a Justin Bieber server might just quit running the server if it gets filled with too much spam.

On a related note, some node runners seem more willing to tolerate storing and relaying spam if it bets mined into blocks, and I suspect part of the reason for that is because "undoing" the spam-inclusion would require expending lots of hashpower, and it doesn't seem worth it. But in *your own mempool,* you can exclude most spam from that pretty easily, and spam filters help you do so. They help solve a technical problem in an effective way. It is therefore no surprise that when Core announced its intention to remove the large-op-return filter, many users switched to software that keeps it.

Ok, so now you’re inferring why other people may or may not want run nodes, which is a largely unfalsifiable claim— though I would point out that the data we have available suggests that users don’t mind: node count has risen in recent years despite all the Inscriptions nonsense.

We can speak for ourselves, however.

For me it makes no difference whether it’s 1MB of monetary data or 1MB of dickbutts. My node operates the same from my perspective. (Even slightly better if it’s dickbutts, but we can leave that aside for now.)

Does it make a difference to you?

> Does it make a difference to you?

Yes

> users [may not] mind: node count has risen in recent years

Maybe some of them don't. But about 20% of them have switched to using software that reduces the amount of spam on their system. That's telling.

It's also possible for a person to be discouraged by the spam but not yet so discouraged that he stops running his node, or refuses to start. And yet if the discouragement continues to build, it may dissuade new people from starting and long-time node runners from continuing.

Does it make a difference to you if it's 1MB of dickbutts in OP_RETURN or 1MB of dickbutts in Inscriptions?

why not introduce policies to make it much less likely for inscriptions to succeed, or even a soft fork to redefine whats standard and valid here?

so instead of asking whether OP_RETURN or Inscriptions, why not instead fight both and solve this issue more thoroughly? 🙂

Yes, I think such spam is more harmful in op_returns than in inscriptions. Op_returns consume more base blockspace than inscriptions do, and as more of that blockspace is consumed by spam, there is less and less room for non-spam transactions.

Ok I think I’m getting close to understanding your perspective, and this also gets back to your OP.

I run a node _primarily_ for myself, and only secondarily to help others.

It sounds like you’re saying you _primarily_ run a node to help others.

Is this correct?

I do not say I run a node primarily to help others. I do say that filtering spam helps me (it reduces the negative impact of spam on my node), and, if widely used, filters also incentivize miners not to mine spam (which improves the health of the network, and thus helps others).

So you run a node primarily for yourself?

Yes

Ok… so would you then agree that from a purely selfish perspective, it’s better to have…

- 1MB of dickbutts in an OP_RETURN

versus

- 1MB of dickbutts in an Inscription + 1MB of monetary data

For purely selfish reasons, 1MB of jpegs in op_returns are worse than 1MB of jpegs in inscriptions, because op_returns take up more base space, which is the more expensive part of blockspace. My transactions must use some base space, as a transaction that *only* uses the less-expensive witness space would be invalid.

As a result, I prefer *less* of that base space to be consumed by jpegs, so that I can use that space; and therefore, even if I had purely selfish motives, I would consider it worse for 1MB of jpegs to be embedded in op_returns instead of inscriptions.

That said, my motivations include both self-interest and interest in others. If you want to see what outcome would ensue if I changed my motivations (e.g. "what if you were only interested in yourself") you could prompt the pro-spam position much more efficiently by asking about more directly pro-spam motivations -- e.g. "what if you were interested in seeing more spam on the network." If you tune the motivations properly, you can get any response you like.

I think your first answer is kind of changing the topic, since we were discussing node centralization.

Is your concern node centralization, or is it fee pressure, or both?

Sorry for not replying sooner

I think there are at least two downsides of op_returns: (1) their purpose is to store arbitrary data, which discourages node running the more it is used, and thus increases node centralization; (2) they store that arbitrary data in a relatively precious location -- base space -- which drives up fees more than alternatives like inscription envelopes.

No worries.

1. But this is making assumptions on why other people run nodes, right? Since you acknowledge that _you_ primarily run a node for your own benefit (and not taking your tx fees into account; that’s the next point), I don’t think you can honestly argue that 1MB of OP_RETURNs is worse for the performance of your node than 1MB (or more) of data in any other part of a block?..

2. Do you think spam will persistently outbid monetary transactions for block space?

Thanks for taking the time, I know this has been dragging on for a while now…

> 1. But this is making assumptions on why other people run nodes, right?

Yes. The specific assumption is: some people run a node with a mempool to help relay some other transactions on the network, but do not want to extend that help to spam transactions.

> I don't think you can honestly argue that 1MB of OP_RETURNS is worse for the performance of your node than 1MB (or more) of data in any other part of a block?

If the data was identical, and if I was excluded from using the argument about base space being more valuable than witness space (to be considered in the next paragraph), then I would not object to the statement that 1MB of OP_RETURNS do no further harm to a node's performance than the same data in another part of a block.

> Do you think spam will persistently outbid monetary transactions for block space?

I do not think so because I do not think I am a reliable predictor of the future. But if I thought I could reliably predict that nothing will change, then I would also predict that spam will often outbid monetary transactions in the future, because I think they often do so in the present.

just love your work and eyeing up some of your projects for deployment #mustdeploy

Ok I think we’ve probably made it to the end of our argument tree: the “agree to disagree stage”!

I’ll post my responses; feel free to rebut them if you feel like you can and want to— or not. Up to you :)

1. Since both you and me run a node primarily for our own benefit, I think it’s reasonable to extrapolate that to other users as well. Since data in OP_RETURN would not discourage you or me from running a node (versus data in other parts of a transaction) I don’t think increasing the OP_RETURN relay default will have a centralizing effect.

2. I think over time monetary transactions will be outbid by other monetary transactions— spam will barely enter the equation, if at all. (Maybe if it’s very compact, Open Timestamps style, in which case it’s also not a big problem.) Also see: nostr:nevent1qqs8tpwm4jzknwcllmujqtw8rr6hlwx5rlzp0sdhhjz3h4a62wkq4lsp9dmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9aex2mrp0yh8xmn0wf6zuum0vd5kzmqzyr5dvlzrtf99jvzwzs2zsr549mlp00jz2n72y7gkha3lnae72j46gqcyqqqqqqgmh5vw9

Ah yes, “Peer to Peer Electronic Dickbutt System” is better. What are you smoking?

Masterpiece. Aaron, come on man, stop humiliating yourself.