Re: [bitcoindev] Re: The Cat, BIP draft discussion.

64 views
Skip to first unread message

Nona YoBidnes

unread,
Jan 15, 2026, 7:48:17 AMJan 15
to bitcoin-dev...@googlegroups.com, bitco...@googlegroups.com
Hi list.


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. 

Are you using spamware like OpenRelay or SlipStream to bypass the policy of the 90,000 nodes? If so, you are spamming bitcoin. You are trying to skirt the only use case of bitcoin. 

Now, some spammers have tried to claim they have paid their miner fee. Of course they did, but that's like saying the sender of the Nigerian prince email paid his internet, therefore it's not spam.   

If you are confused about what constitutes spam on bitcoin, please explain. While I'm sure there are some transactions that could be tricky and controversial to identify as spam, I"m sure we can all agree that inscriptions, stamps, jpegs, fake pubkeys, fake scripthash, unusually large Segwit data, ordinals, runes, etc, are all clearly spam. 

it's also very hard to define it in a discussion forum like this one. 

I just did it, see above. It really wasn't that hard. How are you confused about the definition of spam as it pertains to bitcoin?

But ultimately, it does not belong to devs to decide what is spam. Don't think that just because you know C++, that somehow gives you authority to decide what direction bitcoin should be taking, and what spam is.

That decision belongs to the nodes. And it's clear that the nodes are not given the tools to decide for themselves what spam is or what spam isn't, with comprehensive user configurable spam filters.

Making suggestions which *I* think are terrible, or detrimental, on a list like this, should never be disallowed here.

For the record, this email is the 14th attempt to send to the list. Censorship and suppression of opinions are here. Notice also how Claire barely posts anything on this thread, her own thread, but not for the lack of trying.   

Notions of motivation of contributors (such as they are paid by such and such a company) should not be relevant.

Are you suggesting that conflict of interest is not a thing? If someone is advocating against any and all measures against spam, I would really like to know where their interests lie.

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.

Greg Maxwell just hates and rejects every single attempt to resist spam. His idea of censoring "confiscatory" proposals never came up when Peter Todd proposed confiscation though what he called "demorage" or when Peter Wuille proposed seizing Satoshi's coin. 

Disclaimer: I own bitcoin, I run a bitcoin business in El Salvador. I own no inscriptions or spam of any kind, and I don't invest in any spam related companies.

Cheers, Pepe


Nona YoBidnes

unread,
Jan 18, 2026, 8:19:41 PMJan 18
to bitcoin-dev...@googlegroups.com
Hi list.

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. 

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.  

Now, some spammer defenders have tried to claim they have paid their miner fee. Of course they did, but that's like saying the sender of the Nigerian prince email paid his internet, therefore it's not spam.   

If you are confused about what constitutes spam on bitcoin, please explain. While I'm sure there are some transactions that could be tricky and controversial to identify as spam, I"m sure we can all agree that inscriptions, stamps, jpegs, fake pubkeys, fake scripthash, unusually large Segwit data, ordinals, runes, etc, are all clearly spam. 

it's also very hard to define it in a discussion forum like this one. 

I just did it, see above. It really wasn't that hard. How are you confused about the definition of spam as it pertains to bitcoin? Because bitcoin is money, they have to obfuscate their spam to make it look like a legitimate monetary transaction to the system. So you could make the case that it's harder to distinguish spam from a real monetary transaction. But defining spam on it's own is pretty easy.  

But ultimately, it does not belong to devs to decide what is spam. Don't think that just because we know C++, that somehow gives us authority to decide what direction bitcoin should be taking, and what spam is.

That decision belongs to the nodes. And it's clear that the nodes are not given the tools to decide for themselves what spam is or what spam isn't, with comprehensive user configurable spam filters.

Notions of motivation of contributors (such as they are paid by such and such a company) should not be relevant.

Are you suggesting that conflict of interest is not a thing? If someone is advocating against any and all measures against spam, I would really like to know where their interests lie.

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.

This comes across as a thinly veiled attempt to censor anyone who wants to combat spam, and their employees/employers. This idea of censoring "confiscatory" proposals never came up when someone proposed confiscation though what he called "demorage" or when someone proposed seizing Satoshi's coin. 

If you want to buy or sell pancakes, or JPEgs, or anything else for that matter, bitcoin is here to serve you. But your pancakes and your JPEGs don't belong on the bitcoin chain.

Disclaimer: I own bitcoin, I run a bitcoin business in El Salvador. I own no inscriptions or spam of any kind, and I don't profit from any spam related companies.

40% of the UTXO set is dust spam UTXOs that contains less than 0.0017% of the total bitcoin issued. This constitutes an attack on bitcoin. I think we all should start acknowledging the problem, and stop asking ourselves dismissive questions like "What is spam anyways?" and use that question as an excuse to pretend there is no problem.

Cheers, Pepe



PepeHodler

unread,
Jan 26, 2026, 6:04:29 PMJan 26
to bitcoin-dev...@googlegroups.com, Bitcoin Development Mailing List
Hi Galois, Chris, Greg, the list.


For Galois Field <galoisf...@gmail.com>:
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.


That is not correct. Bitcoin is money, read the white paper tittle if you are in doubt: "A Peer-to-Peer Electronic Cash System" [1]. You don't need to "interpret" anything, it's not written in Chinese, but in plain English for you to read and understand: "A Peer-to-Peer Electronic Cash System" [1] And so, as such, if you are not sending, receiving, or saving money, you are not using bitcoin properly. If you are using fake pubkeys, that is not a legitimate use of bitcoin. Pubkeys are not intended as a jpeg storage system. You are not a bitcoiner, you are an attacker, a grifter, and a spammer. If you are using fake scripthash, you are not using scripthash in a legitimate way. You are not a bitcoiner, you are an attacker, a grifter, and a spammer. If you are using the Segwit exploit to obfuscate a jpeg and make it look like an actual transaction witness, that is not a legitimate use of Segwit. Segwit stands for segregated witness, it does not stand for segregated jpeg. You are not a bitcoiner, you are an attacker, a grifter, and a spammer. Same with the Taproot exploit. Taproot was designed to scale bitcoin and increase privacy, it was never designed as a discount coupon for jpegs. You are not a bitcoiner, you are an attacker, a grifter, and a spammer.  Now, I know that you don't think of it as spam. You want to think of it as new use cases I just happen not to like. And you can't be faulted to think that way when the head core maintainer doesn't even acknowledge that spam exists. She just refers to spam as "use cases we have today" and she implies Satoshi was at fault for failing to account for her "use cases we have today". [2] But in reality, Satoshi did account for exciting new use cases and attempts at expanding bitcoin use cases beyond money. And here is what Satoshi had to say when someone suggested a new use case called BitDSM:
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]


You need to understand that these protocols work very hard at obfuscating their spam to make it look like a legitimate monetary transactions. They do this with fake pubkeys, fake scripthash, fake witness in the Segwit discount, sats amounts just above the dust limit, and likely other methods I am not aware of. They have to make their spam look like a genuine bitcoin transaction because they know full well money is the only supported and sanctioned use case of bitcoin. 
Filter whatever you want on your node. That's your right and policy rules exist for this. 


Unfortunately, filtering is not enough anymore. With core having a centralized mempool policy they impose on all their nodes, increased miner centralization, and services like SlipStream and OpenRelay, all in service of more spam by bypassing the mempool policy of the 90,000 nodes, filtering is no longer enough. And even Shinobi along with many others agree with me on this, until we started to actually take them at there word: "These filters existing do not prevent miners creating private mempools (...) do it at the consensus level." [4]
Spam prevention in the codebase (like the witness data checks in validation.cpp) exists to prevent DoS vectors, not to judge transaction purpose. 


Filters are there to prevent harmful and undesirable use of bitcoin. There are around a dozen different filters in core. The op_return filter core is attempting to break, along with other filters, were created to prevent harm, not solely for DoS attacks. Your assertion that they exist solely for DoS attacks is false.
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.


I don't like what they are used for, Satoshi didn't like what they are used for, the majority of nodes have no incentive to put that spam in their mempool, relay it, an store it for eternity. 
For Chris Riley <cri...@gmail.com>:
The issue with defining all non-monetary data as spam is that it eliminates functionality Bitcoin has relied on since inception.


If bitcoin requires the data to function as money, it is by definition monetary data, and not spam. Furthermore, this BIP only addresses non-monetary data that is harmful to bitcoin as money.  Please demonstrate what part of this proposal would prevent any non-monetary data that is required for bitcoin to function as money.
Time-locked contracts (nLockTime) have existed since v0.1 and underpin CLTV/CSV-based constructions, including the Lightning Network, DLCs, and off-chain adjudication.


This BIP would not prevent any of those from being fully functional. The BIP would only attack spam UTXOs not required for bitcoin to function, and in fact harmful to bitcoin as money.
Sidechain anchoring and systems like OpenTimestamps depend on Bitcoin’s immutability as a distributed order of events. 


OpenTimeStamps is spam data, and not required for bitcoin to function. And this BIP does not prevent either OpenTimeStamps or sidechains from functioning as normal and as usual. 
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.


We are running around in circles here. The Cat would not prevent any of these things from functioning as usual. This BIP only addresses UTXOs with dust amounts of under 1000 sats which have been indexed and catalogued as spam by the spam sites themselves.
For Greg Maxwell:
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).  


I was at first resistant to this idea. But after careful consideration, I think it's actually a great idea, but with one caveat: it must be retroactive. If anyone in the last 10 days or in the last 10 years has engaged in a confiscatory proposal, they should be banned, along with their employees and/or employers.  But keep in mind that I can list at least 3 confiscatory proposals in the last 10 years, an they were all presented by people who were at the time contributors..... Cheers, Pepe [1] https://bitcoin.org/en/bitcoin-paper [2] https://youtu.be/ctks7f-gpaU?si=WPFRi9KeBZtwXVus [3] https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917 [4] https://www.youtube.com/watch?v=gbQvU-woY14

Nona YoBidnes

unread,
Jan 31, 2026, 1:53:45 PMJan 31
to bitcoin-dev...@googlegroups.com
Hi Galois, Chris, Greg, the list.


For Galois Field <galoisf...@gmail.com>:
 
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.


That is not correct. Bitcoin is money, read the white paper tittle if you are in doubt: "A Peer-to-Peer Electronic Cash System" [1]. You don't need to "interpret" anything, it's not written in Chinese, but in plain English for you to read and understand: "A Peer-to-Peer Electronic Cash System" [1] And so, as such, if you are not sending, receiving, or saving money, you are not using bitcoin properly. If you are using fake pubkeys, that is not a legitimate use of bitcoin. Pubkeys are not intended as a jpeg storage system. You are not a bitcoiner, you are an attacker, a grifter, and a spammer. If you are using fake scripthash, you are not using scripthash in a legitimate way. You are not a bitcoiner, you are an attacker, a grifter, and a spammer. If you are using the Segwit exploit to obfuscate a jpeg and make it look like an actual transaction witness, that is not a legitimate use of Segwit. Segwit stands for segregated witness, it does not stand for segregated jpeg. You are not a bitcoiner, you are an attacker, a grifter, and a spammer. Same with the Taproot exploit. Taproot was designed to scale bitcoin and increase privacy, it was never designed as a discount coupon for jpegs. You are not a bitcoiner, you are an attacker, a grifter, and a spammer.  Now, I know that you don't think of it as spam. You want to think of it as new use cases I just happen not to like. And you can't be faulted to think that way when the head core maintainer doesn't even acknowledge that spam exists. She just refers to spam as "use cases we have today" and she implies Satoshi was at fault for failing to account for her "use cases we have today". [2] But in reality, Satoshi did account for exciting new use cases and attempts at expanding bitcoin use cases beyond money. And here is what Satoshi had to say when someone suggested a new use case called BitDSM:
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]


You need to understand that these protocols work very hard at obfuscating their spam to make it look like a legitimate monetary transactions. They do this with fake pubkeys, fake scripthash, fake witness in the Segwit discount, sats amounts just above the dust limit, and likely other methods I am not aware of. They have to make their spam look like a genuine bitcoin transaction because they know full well money is the only supported and sanctioned use case of bitcoin. 
Filter whatever you want on your node. That's your right and policy rules exist for this. 


Unfortunately, filtering is not enough anymore. With core having a centralized mempool policy they impose on all their nodes, increased miner centralization, and services like SlipStream and OpenRelay, all in service of more spam by bypassing the mempool policy of the 90,000 nodes, filtering is no longer enough. And even Shinobi along with many others agree with me on this, until we started to actually take them at there word: "These filters existing do not prevent miners creating private mempools (...) do it at the consensus level." [4]
Spam prevention in the codebase (like the witness data checks in validation.cpp) exists to prevent DoS vectors, not to judge transaction purpose. 


Filters are there to prevent harmful and undesirable use of bitcoin. There are around a dozen different filters in core. The op_return filter core is attempting to break, along with other filters, were created to prevent harm, not solely for DoS attacks. Your assertion that they exist solely for DoS attacks is false.
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.


I don't like what they are used for, Satoshi didn't like what they are used for, the majority of nodes have no incentive to put that spam in their mempool, relay it, an store it for eternity. 
For Chris Riley <cri...@gmail.com>:
 
The issue with defining all non-monetary data as spam is that it eliminates functionality Bitcoin has relied on since inception.


If bitcoin requires the data to function as money, it is by definition monetary data, and not spam. Furthermore, this BIP only addresses non-monetary data that is harmful to bitcoin as money.  Please demonstrate what part of this proposal would prevent any non-monetary
data that is required for bitcoin to function as money.

Furthermore, I don't believe anyone here is claiming that "all arbitrary data is spam". The coinbase inscription most often used for the miner to identify the block as his own, might be considered spam by some, but nobody is really objecting to it. Because it doesn't really add any data to the chain. If the miner leaves it alone, it just gets replaced by random data. And the coinbase inscription is also where Satoshi wrote the genesis block famous message to the world. 

Time-locked contracts (nLockTime) have existed since v0.1 and underpin CLTV/CSV-based constructions, including the Lightning Network, DLCs, and off-chain adjudication.


This BIP would not prevent any of those from being fully functional. The BIP would only attack spam UTXOs not required for bitcoin to function, and in fact harmful to bitcoin as money.
Sidechain anchoring and systems like OpenTimestamps depend on Bitcoin’s immutability as a distributed order of events. 


OpenTimeStamps is spam data, and not required for bitcoin to function. And this BIP does not prevent either OpenTimeStamps or sidechains from functioning as normal and as usual. 
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.


We are running around in circles here. The Cat would not prevent any of these things from functioning as usual. This BIP only addresses UTXOs with dust amounts of under 1000 sats which have been indexed and catalogued as spam by the spam sites themselves.
For Greg Maxwell:
 
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).  


I was at first resistant to this idea. But after careful consideration, I think it's actually a great idea, but with one caveat: it must be retroactive. If anyone in the last 10 days or in the last 10 years has engaged in a confiscatory proposal, they should be banned, along with their employees and/or employers.  But keep in mind that I can list at least 3 confiscatory proposals in the last 10 years, an they were all presented by people who were at the time Core contributors. But I fear your ban suggestion is an attempt to silence and censor a specific group you don't like. 
Cheers, Pepe

Reply all
Reply to author
Forward
0 new messages