No, not even "full nodes" need to store spam

You probably heard about the OP_RETURN and spam wars, where bitcoin core wants to enable more spam in some bitcoin protocol output instruction, to incentivize spammers to stop polluting the utxo set (basically, the minimal set of data any node, even pruned nodes, are allowed to have so that they can verify spends in new transactions). Sure, blocking spam from the mempool is great. Maybe I'll turn to bitcoin email list if no one cares here, but I expect a big amount of hostility because I would love to go super aggressive on spam and burn the spam down to the ground, to the point where even miners will say "what's the point, I'm not gonna do it". Do I know what I'm talking about? Do I understand the tech? I believe so. I've been coding blockchains for almost a decade, and I even have some contributions to bitcoin core and I understand bitcoin core very well to a very recent time. So what do I propose? A new format of nodes, besides full and pruned. We call it "spamless". I don't think all full nodes need to store spam outputs (large ones, like in the picture I attached, that is). Here is how this can be done: Blocks Currently, blocks are stored in raw files with the pointers to each block in the files stored in leveldb. My proposal is: To avoid storing full blocks, we store block headers + transactions in a special format, an object that can be either a transaction or an identifier indicating the hash of the transaction. Programming wise, such an object is called a "variant" in C++, a "union" in C and an "enum" in Rust. Reconstructing blocks don't need to have all the transactions in the block, because all we need to verify transactions in blocks is merkle trees. If we store the hash of spam transactions, we're good. If a subset of outputs contains spam, the same thing described above can be done for outputs, while maintaining the hash of the transaction. Utxo set It's very easy to identify outputs that are not spendable. These can be automated, or picked by hand, detected by the community, and added to a public list by volunteers (these lists already exist). These lists can be loaded as a "default list" in ChainParams (the basic configuration of the bitcoin network in bitcoin core node software), or can be a list the user can control. Or can be activated in bitcoin core with a command line argument --spamless. Because these outputs are not spendable, they can be excluded from the utxo set over time. What do full nodes do about spam transactions? They basically stop providing them through their public interfaces. Obviously, the full block can be requested in p2p communication (not from spamless nodes though), but software like Electrum and similar can also implement the blocking of these transactions. Why do I want this? Because I WANT to run a full node (not pruned, full, with mempool.space and Electrum server included). I want to incentivize everyone around me to run a full node. But now with storage requirements nearing 1 TB and memory sky rocketing, and exceeding 1 TB when Electrum is included, it's becoming harder and harder. I'm a nerd with over 100 TB storage in my servers, but none of my friends are like that. They're normal, busy people. If this plan trims the blockchain back to 400 GB, we've solved a huge problem for the future. Outcome Everyone will be disincentivized to put spam on the blockchain, because no one will want to serve it or store it. No more free cloud storage for parasites filling the blockchain with garbage. This isn't an easy plan to implement, but I believe it's totally doable. It can be done over the course of a months or years. My hope I hope the bitcoin community takes this and thinks about it. Maybe my literal plan is not perfect. But the idea that we have to store unspendable utxos in our blockchain storage is ridiculous and any software engineer can think about it and find a solution. We can do this! Thank you, and apologies for the long post. submitted by /u/TheQuantumPhysicist [link] [comments]

Jun 26, 2025 - 22:38

No, not even "full nodes" need to store spam

You probably heard about the OP_RETURN and spam wars, where bitcoin core wants to enable more spam in some bitcoin protocol output instruction, to incentivize spammers to stop polluting the utxo set (basically, the minimal set of data any node, even pruned nodes, are allowed to have so that they can verify spends in new transactions).

Sure, blocking spam from the mempool is great. Maybe I'll turn to bitcoin email list if no one cares here, but I expect a big amount of hostility because I would love to go super aggressive on spam and burn the spam down to the ground, to the point where even miners will say "what's the point, I'm not gonna do it".

Do I know what I'm talking about? Do I understand the tech?

I believe so. I've been coding blockchains for almost a decade, and I even have some contributions to bitcoin core and I understand bitcoin core very well to a very recent time.

So what do I propose?

A new format of nodes, besides full and pruned. We call it "spamless". I don't think all full nodes need to store spam outputs (large ones, like in the picture I attached, that is). Here is how this can be done:

Blocks

Currently, blocks are stored in raw files with the pointers to each block in the files stored in leveldb. My proposal is: To avoid storing full blocks, we store block headers + transactions in a special format, an object that can be either a transaction or an identifier indicating the hash of the transaction. Programming wise, such an object is called a "variant" in C++, a "union" in C and an "enum" in Rust. Reconstructing blocks don't need to have all the transactions in the block, because all we need to verify transactions in blocks is merkle trees. If we store the hash of spam transactions, we're good.

If a subset of outputs contains spam, the same thing described above can be done for outputs, while maintaining the hash of the transaction.

Utxo set

It's very easy to identify outputs that are not spendable. These can be automated, or picked by hand, detected by the community, and added to a public list by volunteers (these lists already exist). These lists can be loaded as a "default list" in ChainParams (the basic configuration of the bitcoin network in bitcoin core node software), or can be a list the user can control. Or can be activated in bitcoin core with a command line argument --spamless.

Because these outputs are not spendable, they can be excluded from the utxo set over time.

What do full nodes do about spam transactions?

They basically stop providing them through their public interfaces. Obviously, the full block can be requested in p2p communication (not from spamless nodes though), but software like Electrum and similar can also implement the blocking of these transactions.

Why do I want this?

Because I WANT to run a full node (not pruned, full, with mempool.space and Electrum server included). I want to incentivize everyone around me to run a full node. But now with storage requirements nearing 1 TB and memory sky rocketing, and exceeding 1 TB when Electrum is included, it's becoming harder and harder. I'm a nerd with over 100 TB storage in my servers, but none of my friends are like that. They're normal, busy people. If this plan trims the blockchain back to 400 GB, we've solved a huge problem for the future.

Outcome

Everyone will be disincentivized to put spam on the blockchain, because no one will want to serve it or store it. No more free cloud storage for parasites filling the blockchain with garbage.

This isn't an easy plan to implement, but I believe it's totally doable. It can be done over the course of a months or years.

My hope

I hope the bitcoin community takes this and thinks about it. Maybe my literal plan is not perfect. But the idea that we have to store unspendable utxos in our blockchain storage is ridiculous and any software engineer can think about it and find a solution. We can do this!

Thank you, and apologies for the long post.

submitted by /u/TheQuantumPhysicist
[link] [comments]