As most of the bitcoiners know that scammers have been spamming the bitcoin for more than year now.
I have seen some good arguments in support of filtering the spam to disincentive the behavior.
Time for the post on strawman and steelman arguments on spam.
Strawman: - What is your definition for scam? While I agree 99% of the trading is done because of speculation and will cause many to lose money. The scams are only projects lying to their customers to run out with their money, which there are many, but much less than speculate traders.
Steelman: - Just because you want to have sex doesn't mean you're justified in raping people who don't consent.
Strawman: - But aren’t they within the consensus rules and therefor it’s not rape? They found an exploit! Ok. Filter. Won’t they find another exploit? Wouldn’t it be better to focus on the monetary use cases? And people will choose to use it as SOV?
Steelman: - What if I find a way to steal anybody’s bitcoin within the consensus rules. Will you fix the bug? I will let him steal my Bitcoin as long as it is in consensus rules.
Strawman: - Ya I probably would want that fixed. But 1) how would someone steal bitcoin and still be within consensus? And 2) how are cat jpegs on blockchain the same as stealing someone’s bitcoin? That’s a clear issue needing addressed.
Steelman: - 1) people thought that the supply limit was 21m until someone found out how to violate it within the code's consensus engine. There's no know way to steal today, but the question is about how you would react if such a hypothetical vulnerability was discovered in the future - the exact mechanics of the exploit don't matter for the hypothetical. 2) cat jpegs on chain and steal someone's Bitcoin are the same issue because there isn't consensus for either one of them.
Strawman: - Is the 'exploit' that the code was written just fine, operates just as expected, and is being used in a different but anticipated way, but at an unanticipated rate? Or is there more?
Steelman: - Bitcoin script was not intended for unlimited arbitrary data storage, therefore it is not operating as expected.
Strawman: - Seems like Casey expected OP_FALSE, _IF, _PUSH, _ENDIF to operate that way. Do you mean he just guessed? Storage is still bound by block size(not unlimited) and the 'scammers ran out of fiat for their attack', ie fees operated exactly as we all expected them to do.
Steelman: - You're describing every single exploit/hack/crack in computer software history. The people who designed OpenSSL intended it to be a library for HTTPS security. The people who designed the Heartbleed hack expected to break OpenSSL so, you think Heartbleed wasn't an exploit and OpenSSL was just fine? This is clown-world logic.
Steelman: - In information security terminology, a "bug" is a problem found in the software. Some bugs are also "vulnerabilities", meaning that you can leverage them to cause unintended or unexpected behavior by the software. Leveraging them is the "exploit" of the vulnerability.
Strawman: - I can convince myself it's an exploit (semantically) but I still struggle to see the bug. Everything is operating as expected, but some users are using those operations (in an obvious way) to do something others for whatever reason didn't expect.
Steelman: - The bug is the datacarriersize is not properly counting data carried inside op_false op_if
Strawman: - ty! (although begs the q what is meant by 'properly') Was there a reason it was ignored? Was this deliberate decision? A non-concern? My (crude) understanding was some initially used this for commenting, as it doesn't execute anything.
Steelman: - When datacarriersize was first introduced in 0.9 it was done so simultaneously with op_return. Prior to 0.9 people had started to use ridiculously inefficient methods to embed small amounts of arbitrary data in transactions, so a consensus emerged to create a strictly limited, but TOLERATED way to add arbitrary data to transactions - that's what op_return was. To limit the amount of arbitrary data per transaction, datacarriersize was added. For the next 10 years, all was happy. Then in early 2023 someone discovered a way to add arbitrary data to a transaction outside of op_return, and bypass the datacarriercheck matching heuristic. This bug was critical for inscriptions to work because it meant that they could bypass the existing spam filters to add any amount of arbitrary data up to the block weight limit. In mid-2023, the bitcoin core managers closed the issue about the bug, claiming that discussing the github topic was "too controversial" In August 2023, a Bitcoin core maintainer changed the documentation/comments in the source code which defined arbitrary data. Since then the core team has been unwilling to acknowledge that this is a bug.
Strawman: - Also remember that a property of OP_RETURN is that it creates a provably unspendable utxo, which can be safely pruned if you don't want to store the arbitrary data on your node.
Steelman: - This isn't an argument against spam, though. Pruning just adds to the work of a full node, it doesn't eliminate it. And Inscriptions are all equally prunable.
Steelman: - OP_RETURN is a top symbol of altcoining mindset, such mindset classic 'solution' is a BAND-AID to pretend the problem does not exist and life goes on. As hash-anchoring to TXs is possible, the question needs to be: how to make it VERY cumbersome. NOT apply a band-aid on top.
As you can see clearly from some of these arguments that legitimate bug is being exploited by some bad actors in the #bitcoin community.
I would strongly suggest running @BitcoinKnots
to disincentivize this behaviour and if you are miner then send your hash to @ocean_mining
.
If this bug doesn't get fixed then I wouldn't be surprised if we have to reconsider the blocksize limit since spam (sorry scam) has been bloating bitcoin blockchain and UTXO set like never before.
It will drive up the cost to run your own node hence we may need to think about reducing the blocksize limit as you can see most of the mempool is filled with garbage (to scam the people)
Maybe 300kb-400kb limit would be optimal blocksize limit. It will at least keep the cost of running your own node low for a very long time.
If you want to see bitcoin getting succeed, you don't want to see NGU in only #bitcoin price but NGU in node runners as well and current spamming condition will severely affect the NGU in node runners (in the long run for sure).
cc @Bitcoin Mechanic @Luke Dashjr @npub16s0g...8ky6 @Giacomo Zucco
As you can see clearly from some of these arguments that legitimate bug is being exploited by some bad actors in the #bitcoin community.
I would strongly suggest running @BitcoinKnots
to disincentivize this behaviour and if you are miner then send your hash to @ocean_mining
.
If this bug doesn't get fixed then I wouldn't be surprised if we have to reconsider the blocksize limit since spam (sorry scam) has been bloating bitcoin blockchain and UTXO set like never before.
It will drive up the cost to run your own node hence we may need to think about reducing the blocksize limit as you can see most of the mempool is filled with garbage (to scam the people)
Maybe 300kb-400kb limit would be optimal blocksize limit. It will at least keep the cost of running your own node low for a very long time.
If you want to see bitcoin getting succeed, you don't want to see NGU in only #bitcoin price but NGU in node runners as well and current spamming condition will severely affect the NGU in node runners (in the long run for sure).
cc @Bitcoin Mechanic @Luke Dashjr @npub16s0g...8ky6 @Giacomo Zucco
In this P2SH method, data chunks are added sequentially to the unlocking script, then "dropped" from the script's memory after they've been verified. It's like writing a long message on a series of puzzle pieces, then scattering the pieces for someone else to find and reassemble.
For example, David wants to store a large document on the blockchain. He breaks the document into small chunks and creates a P2SH transaction where each chunk is "dropped" into the unlocking script in order. When the transaction is spent, the chunks are reassembled to recreate the original document.
There is a new type of scam token introduced by Xitter account MikeInSpace which is called SRC-20 tokens that MIGHT BE USING P2SH transactions to spam the #bitcoin network.
Since they might have started with new tokens, we haven't seen dramatic rise (YET) in P2SH UTXO set but it's something we would like to keep an eye on in the future.
These transactions can be quite large, especially for bigger files. If many users start storing large amounts of data this way, it could significantly increase the size of the blockchain & UTXO set, making it harder for average users to run full nodes.
As you can see in this picture, they are blatantly saying that you can't even prune these transactions by scamming people in the name of immutability and permanence.
In conclusion, while the Bitcoin blockchain offers a temptingly permanent and censorship-resistant platform for monetary transactions only, methods like inscriptions, SRC-20 & BRC-20 tokens create unspendable UTXOs that bloat the UTXO set, while OP_RETURN doesn’t bloat the UTXO set but contribute to overall blockchain bloat. This bloat can make it more expensive to run a Bitcoin node, which could lead to centralization as fewer users can afford to store the full blockchain. It also puts extra strain on the network, potentially slowing down transaction processing and increasing fees for everyone.
If you really want to disincentivize this behavior and reduce inscriptions on #bitcoin blockchain , then I would strongly recommend running Knots instead of original #bitcoin core.
If you are miner then point your hash to 
Let me try to explain one more type of spamming method in #bitcoin network (to the best of my knowledge).
Pay-to-Multisig(P2MS)
In this method, data is hidden in one or more fake public keys in a multisig transaction. It's like having a secret compartment in a safety deposit box that requires multiple keys to open.
The most common method for using P2MS locking scripts is to wrap them in a P2SH or P2WSH. P2MS has no address format and P2MS is limited to 3 public keys.
The locking script of a P2MS can get pretty sizeable with all the public keys so, it’s limited to 3 to prevent too much data being store in the UTXO set.
A lot of bitcoiners who think that spam helps (bad) mining pools/miners to get more fees but free market is screaming at us and showing that spam doesn't help with fees.
In fact, almost all of the block space is being filled with a lot of garbage and mining pools'/miners' main source of income is still block subsidy (aka 3.125 bitcoin/block mined). Moreover, it's increasing the cost of running your own full node.
Do not forget that spammers are exploiting legitimate bug in the #bitcoin script to add garbage data and rationalizing it with "it helps miners/mining pools" or "They are valid transactions".
As 
Let's deep dive into one more method of spamming the #bitcoin network.
IT'S CALLED OP_RETURN METHOD.
OP_RETURN is a special transaction output type that allows embedding a small amount of data (up to 83 bytes) directly into a transaction.
This data is not part of the transaction's inputs or outputs, but is included as a separate, provably unspendable output hence it does not bloat UTXO set but hold on, I will explain you later in this thread how it's still bad for #bitcoin network.
OP_RETURN is like attaching a sticky note to a bank-cheque.
For example, Carol wants to post a short message on the #bitcoin blockchain for all to see. She creates a transaction with an OP_RETURN output containing her message: "I love Bitcoin" This message is now part of the blockchain record, visible to anyone who examines the transaction.
To understand how spam works in the #bitcoin blockchain, let's start with a simple analogy. Imagine a huge public bulletin board where anyone can post messages. Once a message is posted, it can't be removed or altered. That's essentially what the Bitcoin blockchain is, but instead of physical messages, it stores digital data.
Let's dive into the one of the different ways spam can be added to the blockchain and the problems they can cause.
Pay to Witness Public Key Hash (P2WPKH) & Pay to Taproot (P2TR) & addresses (with the help of Segwit upgrade witness discount)
P2TR and P2WPKH are newer address formats that take advantage of SegWit (Segregated Witness) to reduce transaction sizes and fees. However, spammers are abusing the witness discount feature. It's like a store offering a discount on shipping large items, but someone exploits it to ship tons of useless junk for cheap.
SegWit is one of the #bitcoin upgrades which was first introduced in December 2015. It was introduced with the intention to scale #bitcoin but spammers decided to misuse this upgrade to scam the people
The witness discount gives a ~75% discount on fees for the witness data portion of transactions using these address types. Spammers stuff arbitrary data into the witness to get cheaper spam. Imagine a mail service that charges $1 per ounce, but only 25¢ for each ounce of the envelope. Spammers would send heavy junk mail in huge envelopes to save money.
For example, a spammer can create a P2WPKH transaction with a 1 KB witness containing random garbage data. Instead of paying full fees for 1 KB, they only pay for ~250 bytes due to the discount. It's like sending a 1-pound box of rocks but only paying postage for 1/4 pound because the box itself is discounted. This allows spammers to bloat the blockchain and mempool with junk data at a fraction of the cost compared to regular transactions. It's an exploit of a legitimate feature, like someone abusing a "buy one get one free" sale to hoard items they don't need.
Spammers are also using P2TR addresses which have a same discount formula and can be abused similarly by stuffing the witness with junk to reduce fees. It's like finding another shipping loophole to exploit, such as a discount for certain box sizes that can be filled with useless filler.
These spam attacks not only bloat blockchain size, but can clog up nodes and mempools, degrading network performance for legitimate users. Imagine a post office overwhelmed by a flood of junk mail, delaying normal letters and packages. While the witness discount is well-intentioned to make SegWit transactions cheaper, spammers found a way to game the system and make their attacks more cost-effective. It's like a store's generous return policy being abused by people who wear and return clothes repeatedly to save money.
Almost all the inscriptions (aka one type of scam) use these 2 addresses to bloat the bitcoin blockchain and UTXO set. Inscriptions aren’t directly stored in the UTXO’s set but they leave the dust behind which bloats the UTXO set.
Just look at the growth of UTXO set (with P2TR & P2WPKH addresses). As you can see in this chart, how Inscription is becoming one of the major attack vectors for #bitcoin (in the long run) It's already severely affecting low cost nodes by bloating UTXO set.
Ordinals don’t exist on bitcoin blockchain it’s just a dumb way to count individual Satoshi which has been inscribed into bitcoin blockchain by inscriptions. Some centralized systems count this rare Satoshi in the name of Ordinals which doesn’t exist in the first place.
1> How are fees calculated for transactions on the Bitcoin network?
Fees are calculated based on the amount of data in a transaction, not the amount of #bitcoin being moved. Each byte of data in a transaction requires a certain fee to be included in a block.
2> What is arbitrary data and why would it be considered spam?
Arbitrary data, or "arb data," refers to data that is not directly related to a #bitcoin transaction. When the fees for including this data are higher than the value being moved, it doesn't make economic sense and is likely spam.
Example: Imagine someone sending a bitcoin transaction with a 1 KB message attached, paying a $10 fee to do so, while only moving $1 worth of bitcoin. This would be considered arbitrary data and spam.
3> How can you disincentivize the insertion of arbitrary data (spam) into the Bitcoin network?
You can disincentivize arbitrary data insertion by implementing filters in your #bitcoin node. These filters can stop relaying transactions that contain unnecessary data (aka spam).
4> How can you disincentivize the insertion of arbitrary data (spam) into the #bitcoin network AS A MINER?
Miner(s) can disincentivize this behavior by sending your hash power to @ocean_mining
since they are the only single mining pool who let miners choose multiple templates. They charge minimal to no fee if you decide to mine with them with spam/data free template(s).
