Which brings me to my disagreement, which I know is not shared by a number of contributors here: just as it is hard to define spam on Bitcoin
I don't understand how anyone could be confused about the concept of spam on bitcoin. Bitcoins is "A Peer-to-Peer Electronic Cash System" according to the white paper. As such, anything not intended as a monetary transaction is spam.
If you are using fake pubkeys to store data on chain, that is an unsupported and unsanctioned use of bitcoin. You are a spammer and an attacker, not a bitcoiner.
Same with fake scripthash used to store arbitrary data, unsupported and unsanctioned use of bitcoin. You are a spammer and an attacker, not a bitcoiner.
And the same goes for the Segwit exploit and the Taproot exploit. You are exploiting bitcoin to store arbitrary data in an unsanctioned way.
When Segwit and Taproot were implemented, nobody, absolutely nobody was welcoming those upgrades as a way to store jpegs and other garbage on chain. That is not what bitcoin, Segwit, and Taproot were built for.
When there are hundreds of millions of UTXOs at exactly 330 sats or 546 sats, just enough to be above the dust limit to pass off as a genuine monetary transaction, that is not what bitcoin is intended for.
When there are blocks like this one:
https://mempool.space/block/00000000000000000000ed962f87a0c350b1401fe546db60e6d78e34ab549378
Over 60% of the transactions in that block are not sending or receiving a single sat. It's all op_returns with no sats in them. That is not what bitcoin with designed or sanctioned for.
These people are not users, they are attackers and spammers. How can you look at inscriptions, runes, ordinals, fake pubkeys, fake scripthash, stamps, and op_return with 0 sats in them and wonder if those are legit bitcoin monetary transactions?
Now, some have tried to claim "My ordinal is a consensus valid transaction". And of course it is, otherwise it would not have been added to a block. But that's like saying the Nigerian prince email followed all the SMTP and POP protocols of email, therefore it's not spam.it's also very hard to define it in a discussion forum like this one.
Making suggestions which *I* think are terrible, or detrimental, on a list like this, should never be disallowed here.
Notions of motivation of contributors (such as they are paid by such and such a company) should not be relevant.
Everything should be open to discussion which is implementation-technical (so obviously not e.g. threats of violence or things that bring legal liability to participants or have zero relevance to Bitcoin's technical development) even if it's philosophy-motivated. And blocking should be reserved either as an anti-DOS measure if volume gets out of control, or if it brings dangers as per the previous parenthetical.
Which brings me to my disagreement, which I know is not shared by a number of contributors here: just as it is hard to define spam on Bitcoin
I don't understand how anyone could be confused about the concept of spam on bitcoin. Bitcoins is "A Peer-to-Peer Electronic Cash System" according to the white paper. As such, anything not intended as a monetary transaction is spam.
The use of fake pubkeys to store data on chain, that is an unsupported and unsanctioned use of bitcoin. That spam, and an attack, not a monetary transaction.
Same with fake scripthash used to store arbitrary data, unsupported and unsanctioned use of bitcoin. That spam, and an attack, not a monetary transaction.
And the same goes for the Segwit exploit and the Taproot exploit. That is exploiting bitcoin to store arbitrary data in an unsanctioned way, spam, an attack on bitcoin.
When Segwit and Taproot were implemented, nobody, absolutely nobody was welcoming those upgrades as a way to store jpegs and other garbage on chain. That is not what bitcoin, Segwit, and Taproot were built for.
If you are making use of OpenRelay and/or SlipStream to bypass the policy of the majority of nodes, you are a spammer and an attacker, not a bitcoiner. You are trying to skirt the only use case of bitcoin.
When there are blocks like this one:
https://mempool.space/block/00000000000000000000ed962f87a0c350b1401fe546db60e6d78e34ab549378
Over 60% of the transactions in that block are not sending or receiving a single sat. It's all op_returns with no sats in them. That is not what bitcoin was designed or sanctioned for.
These people are not users, they are attackers and spammers. How can you look at inscriptions, runes, ordinals, fake pubkeys, fake scripthash, stamps, and op_return with 0 sats in them and wonder if those are legit bitcoin monetary transactions?
Now, some have tried to claim "My ordinal is a consensus valid transaction". And of course it is, otherwise it would not have been added to a block. But that's like saying the Nigerian prince email followed all the SMTP and POP protocols of email, therefore it's not spam.it's also very hard to define it in a discussion forum like this one.
Notions of motivation of contributors (such as they are paid by such and such a company) should not be relevant.
Everything should be open to discussion which is implementation-technical (so obviously not e.g. threats of violence or things that bring legal liability to participants or have zero relevance to Bitcoin's technical development) even if it's philosophy-motivated. And blocking should be reserved either as an anti-DOS measure if volume gets out of control, or if it brings dangers as per the previous parenthetical.
The problem is that you're redefining "spam" to mean "transactions I don't like" rather than using the technical definition: transactions that DoS the network.
Piling every proof-of-work quorum system in the world into one dataset doesn't scale. Bitcoin and BitDNS can be used separately. Users shouldn't have to download all of both to use one or the other. BitDNS users may not want to download everything the next several unrelated networks decide to pile in either. The networks need to have separate fates. BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices. [3]
Filter whatever you want on your node. That's your right and policy rules exist for this.
Spam prevention in the codebase (like the witness data checks in validation.cpp) exists to prevent DoS vectors, not to judge transaction purpose.
But advocating for protocol-level censorship of consensus-valid, fee-paying transactions because you don't like what they're used for is far more dangerous than any jpeg in witness data.
The issue with defining all non-monetary data as spam is that it eliminates functionality Bitcoin has relied on since inception.
Time-locked contracts (nLockTime) have existed since v0.1 and underpin CLTV/CSV-based constructions, including the Lightning Network, DLCs, and off-chain adjudication.
Sidechain anchoring and systems like OpenTimestamps depend on Bitcoin’s immutability as a distributed order of events.
Protocol upgrades themselves rely on non-monetary signaling via version bits and miner flags. As stated in the whitepaper, the proof-of-work chain is a solution to distributed timestamping and majority decision-making. Monetary transactions depend on this ordering. If all non-monetary data is defined as spam, Bitcoin cannot function as Bitcoin. The opcodes in v0.1 clearly show that it was intended to do more than "Send X from A->B"-and they weren't disabled due to philosophical opposition, but DOS, consensus etc concerns. Please note, this does not imply that bulk data storage belongs on L1, merely that "spam is easy to as anything non-monetary" isn't as easy as one might think.
I think the list should adopt a 1 year ban on parties *and their* employer(s) (if known) for any coin confiscation proposal on the list going forward (after, of course, making the rule clear on the signup page).
The problem is that you're redefining "spam" to mean "transactions I don't like" rather than using the technical definition: transactions that DoS the network.
Piling every proof-of-work quorum system in the world into one dataset doesn't scale. Bitcoin and BitDNS can be used separately. Users shouldn't have to download all of both to use one or the other. BitDNS users may not want to download everything the next several unrelated networks decide to pile in either. The networks need to have separate fates. BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices. [3]
Filter whatever you want on your node. That's your right and policy rules exist for this.
Spam prevention in the codebase (like the witness data checks in validation.cpp) exists to prevent DoS vectors, not to judge transaction purpose.
But advocating for protocol-level censorship of consensus-valid, fee-paying transactions because you don't like what they're used for is far more dangerous than any jpeg in witness data.
The issue with defining all non-monetary data as spam is that it eliminates functionality Bitcoin has relied on since inception.
Time-locked contracts (nLockTime) have existed since v0.1 and underpin CLTV/CSV-based constructions, including the Lightning Network, DLCs, and off-chain adjudication.
Sidechain anchoring and systems like OpenTimestamps depend on Bitcoin’s immutability as a distributed order of events.
Protocol upgrades themselves rely on non-monetary signaling via version bits and miner flags. As stated in the whitepaper, the proof-of-work chain is a solution to distributed timestamping and majority decision-making. Monetary transactions depend on this ordering. If all non-monetary data is defined as spam, Bitcoin cannot function as Bitcoin. The opcodes in v0.1 clearly show that it was intended to do more than "Send X from A->B"-and they weren't disabled due to philosophical opposition, but DOS, consensus etc concerns. Please note, this does not imply that bulk data storage belongs on L1, merely that "spam is easy to as anything non-monetary" isn't as easy as one might think.
I think the list should adopt a 1 year ban on parties *and their* employer(s) (if known) for any coin confiscation proposal on the list going forward (after, of course, making the rule clear on the signup page).