Thread

What does he mean that relaying transactions is not part of the network design? What are nodes relaying txs for then? Honest question

Your gut instinct is correct he is spewing bullshit. Tx relaying is an integral part of the network and a crucial part for censorship resistance. In fact, arguing against filters is arguing for tx relaying.

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.

Its BS. Blocks are created rougly every 10 minutes. What is his benefit to get all transactions of a block in 2 minutes or in 3 or in 4? Is he going to win the lottery? Or he just like collecting spam and csam. Lets see my incentives of running a Bitocin Knots node. 1. First of all I own Bitcoin and having a full node gives me the security to trust only my node and be able to freely transact. Its highest degree of security. 2. I have read Satoshi Nakamoto white paper and my view of Bitcoin is that its P2P Freedom Money. So I vote with my node what Bitcoin is. 3. Full nodes also secure the Bitcoin network so in addition to my own benefits I do altruistical work too. 4. I help with Bitcoin decentralization 5. All incentives allign. I help the network by helping myself. I have no incentive to relay spam or csam. I have no incetive some shitcoiners to turn Bitcoin into failed shitcoin like Ethereum, XRP or Cardano. I have no incentive of Bitcoin getting more centralized. It will get if nodes start to require huge resources. I have no incentive Bitcoin to die and to continue with fiat inflation theft and central banks financial slavery. What is his "idea" about the Bitcoin Nodes' part in the design of the network?

Watched only the short clip as I don't use X any more.

I listened to the first hour. If I understand you correctly, you’d ideally want users, through their relay policies, to prevent certain transactions from ending up in blocks at all. So let’s say you get your way. Would you agree that this can also be used to block any other (type of) transaction, including monetary transactions? If so, would this be a good thing or a bad thing in your mind?

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

I think an important distinction is: 1. filter based on transaction format 2. vs. filter based on transaction content format filters are trivial. content filters are difficult. imho filtering based on content or even intent requires centralizing complexity in filtering, while format based filters are trivial for everyone.

Can you define "consensus" for me in this context please? (If some users want to send certain transactions -- *even if* dickbutts in OP_RETURNs -- doesn't that automatically imply there is no consensus to block this?)

Why do you think that? I'm sure it would be trivial to create a filter for (say) OFAC-listed addresses. Not materially different from filtering on format.

hm, fair enough. the point is that anyone can add filters based on format, because simple rules can be used by anyone, no matter how small the miner. content based filtering needs e.g. content recognition and classification, which can only be pulled of by large miners and puts small ones out of business if that is required, thus centralizing. you bring up a third case, where e.g. the content based filtering (e.g. ofac) is done by a large third party provider and everyone is required to query them to aplly their derived rules. still. transaction format is different from transaction content. transaction content is a specific bitcoin address. its also an uphill battle, because addresses change and folks can make new addresses all the time, unlike bank accounts, where it is harder ...so i think your ofac still falls under content filtering

basically, OFAC would require the ability to filter based on content as well. the process to classify is still impossible by individual miners unless they pull in the classification from big centralized services, so i would recommend ro ensure content based filtering stays unsupported 🙂

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."

Ok I find using the term "consensus" a bit confusing in this context, since that could also be just one or two guys :) What you're really saying is that anyone should be free to run whatever filters they want, which I not only agree with but also matches factual reality right now. (People decide what node software to run.) I believe it would take some ~95% of nodes to filter certain transactions before it meaningfully stifles their ability to make it to miners over the p2p network. Is that what you have in mind when you say you'd ideally want users to prevent what ends up in blocks? (To be clear my question is about the method-- not about the exact number as long as you agree it's a reasonable approximation; it could also be 90% or 99% as far as I'm concerned.)

> 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.

What you're describing is a centralizing effect. (Less stale blocks and/or more fees for larger miners versus smaller ones.) That's not a concern for you? (Why not?)

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.

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?)

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.)

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

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? 🙂

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

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