Bitcoin Forum

There seems to be a lot of confusion about the upcoming Bitcoin version 30.

Many people fear that one of the changes of this version, called often the "lifting of OP_RETURN size limits",  will lead to a high amount of NFTs, images, and even illegal material being "spammed" on the blockchain.

These fears are mostly unfounded. There is only one effect that could happen and I will talk about this at the end of the post, but it has no technical reason, but more is caused by the cryptocurrency market's social and economic dynamics.

What is OP_RETURN?

Since the genesis block stored by Satoshi in 2009, people have used the Bitcoin blockchain to publish arbitrary data of non-financial nature, like small images, texts, poems and so on.

About 10 years ago, the Bitcoin Core developers created a specific mechanism to publish data in a way they cause the least possible harm to the nodes. This mechanism relies on the opcode (Bitcoin Script command) OP_RETURN.

OP_RETURN means nothing more that everything after this command can be ignored by the nodes. The data is placed behind that command. And if they want, the nodes can process it once and then delete it. [1]

OP_RETURN was necessary because people were publishing images, texts and other media disguising it as financial data. You would see a transaction and think it's a money transfer, but the data actually contained an image. And for several reasons this is actually more harmful and costly for nodes than OP_RETURN, because they can't ignore the data.

What's the change everybody's talking about?

Until Bitcoin 30, Bitcoin Core had a default value of 80 bytes for OP_RETURN outputs.

This means: Nodes which used this default value, would not accept a transaction with data behind of an OP_RETURN command with more than 80 bytes.

However, nodes were always free to change this default value. Miners are free to change that value too. It can be seen as a "recommendation". Transactions obeying this limit are called "standard" transactions.

But the 80 bytes limit only applied to data behind OP_RETURN. Not for other techniques to insert data into the blockchain.

In Bitcoin 30, the default value is set to "unlimited".

This does not mean that data of unlimited size is now "allowed by Bitcoin" and before it was not. Instead it means: If you as a node operator want to limit the OP_RETURN data in transactions your node accepts, you must manually set a limit (using the datacarriersize option).


Why this change?

The OP_RETURN limit increase is justified in the following way by its supporters:

Since 2023, we have seen a wave of transactions using other means to put data in the blockchain, including "fake public keys" and a "Taproot witness method" (also called the "Taproot exploit") used by Ordinals. They have put up to 400 kB of images, NFTs and even audios and videos in a "standard" transaction, and up to 4 MB into a "non-standard" transaction.

These methods are more costly for the nodes to process, and thus they could harm decentralization of the Bitcoin network if they become too widespread. [2]

Developers decided thus to try to encourage those that want to store data on chain, to use the OP_RETURN method. If many nodes accepted OP_RETURN transactions with larger sizes, this could become again thus the "standard method" to store data.

There are other advantages of the change but they are more difficult to understand. For example, block propagation could be improved and maintainance cost of the code could be lower. To understand why the change will probably not affect the level of spam, these reasons aren't important.


Why can't we simply stop the spam and filter all data transactions?

This is the most important part to understand.

The Core developers "could" put a "filter" in place to disallow two methods: OP_RETURN and the "Taproot exploit". But this filter would be ineffective, because the "fake public key" method cannot be blocked this way.

Unfortunately this method is also the most costly for nodes and thus the most harmful for decentralization. Remember why OP_RETURN was introduced? (see above) Because the "fake public key" method and similar techniques were already causing harm around 2014/15.

The Three Doors or why OP_RETURN doesn't open a new door

A very simple way to describe the change:

We have a house with three doors. Outside are 99 monsters who will enter the house by any means. The probability of the monsters to enter the house by any door is the same.

Door 1 is completely open now. Monsters entering this door can go directly into the whole house including the bedrooms and eat the people living there. This is the "fake public key method", the most harmful of all.

Door 2 is mostly open, some people are trying to close it sometimes but with not much luck. Monsters can enter the kitchen, but not the bedrooms, so the house's inhabitants are a bit safer, but still frequently a monster will be able to eat somebody.[3] This is the "Taproot witness method", the second most harmful.

Door 3 is currently only a bit open. Only small monsters can enter it. But even if the door was completely open, the monsters would only reach a guest room almost nobody of the inhabitants uses, and thus only rarely eat somebody. This is OP_RETURN.

We cannot close Door 1 (see above). Door 2 can be closed but the effect would be limited, because the monsters would then use Door 1 and the number of eaten people would even be higher.

We can however open Door 3. The monsters using this door would not cause much harm. Monsters entering via the other two doors could still enter, but we would have 1/3 less deaths.

This is what Core did lifting the OP_RETURN limits. It will probably not cause the spam (monster waves) to stop, but it could reduce their harm, at least a bit.

Economics of the NFT market

There is another reason why Bitcoin 30 would probably not lead to more spam: The NFT market is limited. There are already hundreds of thousands of NFTs on the Bitcoin blockchain, but there are not unlimited people who want to buy a Pepe or whatever as a NFT.

People posting NFTs expect a profit. But if they have to pay transaction fees, then they have to check that they don't pay more than the profit they're able to earn. The only way making publishing NFTs more attractive would be a measure which leads to less transaction fees.

But the lifting of OP_RETURN limits does not make NFTs cheaper in regards of transaction fees. The "Taproot exploit" is still cheaper, and the cost of "fake public keys" is almost similar.

So the lifting of OP_RETURN limits does not change NFT market economics. If a NFT was profitable now, it will be profitable with BItcoin 30, and if not it won't.

What is the effect you mentioned in the first paragraph? Why could we see more data/spam in the blockchain after Core 30 is released?

Technically, it makes not a big difference for those developing and storing NFTs, images, tokens (like Runes, BRC-20 and SRC-20) to use OP_RETURN or another method to store their data. There are lots of tools available, for example the Stampchain / Bitcoin Stamps project uses fake public keys, and Ordinals uses the Taproot witness method.

So why could this change lead to a temporary "data spam" wave?

The reason is that the NFT market could try to market a new type of NFT. The NFT market lives due to trends, fads, "cool collections" and similar reasons, and NFT collection creators often try to exploit the novelty of a method. If OP_RETURN based NFTs become now attractive, then an OP_RETURN  based NFT protocol could try to get attention once Bitcoin Core 30 gets published, like Ordinals did in 2023. And this could lead to a spam wave indeed.

It is also possible that people annoyed by the OP_RETURN change could publish NFTs as a kind of "vengeance attack".

For this reason I personally would have preferred a gradual increment of the OP_RETURN default (standardness) limits and not the complete removal of limits.

But in the long run, it is highly likely that the amount of spam or arbitrary data transactions will not increase as an effect of the OP_RETURN change of Bitcoin 30.

---

Notes: (ELI18)

[1] The nodes only need to process the data to calculate the merkle tree of the transaction and the transaction ID. Then they can in theory delete the data behind the code if they want. The only problem is that they can't transmit the complete transaction in question to other nodes requesting it.

[2] The reason is that the techniques like the "Taproot witness method" used by Ordinals and the "fake public keys" used by Stampchain lead to a lot of UTXOs being created which will never be spent. These UTXOs have to be stored and managed by the nodes in an additional database. This maintenance work is much more costly to simply store the blockchain data.

[3] The analogy here: A "death" by being eaten by a monster is an UTXO which has to be stored by all nodes in their UTXO database forever, because it never will be spent. The fake public key method produces the highest rate of these UTXOs and they are impossible to spend. The "Taproot witness exploit" ocassionally creates dust UTXOs, which can be spent but the fees to do so will be higher than the value transacted. OP_RETURN does only very rarely lead to dust UTXOs and never to completely unspendable UTXOs.

---

Notes: Tips to improve this post are welcome! If I missed something important I'm glad to add it. Only it should not become too technical. People wanting to know more technical details should read Antoine Poinsot's blog post (https://antoinep.com/posts/relay_policy_drama/) detailing his reasons why he proposed the OP_RETURN change.

Would be nice to store a PGP-encrypted message containing SEED phrase in OP_RETURN. With the current OP_RETURN size limit the encrypted message would require more than dozen transactions to accommodate it. First, this is costly. Second, it's inconvenient to reassemble the message for decryption. Lifting this limit would allow the relevant encrypted message to be stored on the blockchain in a single transaction. Real bargain.:)

You have can already use a mechanism like Stampchain (Bitcoin Stamps) to do that (this is mentioned in the OP :) ). Or Ordinals inscriptions if you prefer. Both have tools to inscribe your seed or whatever without having to bother about reassembling the messages.

And of course there are miners who happily will accept transactions which are considered non-standard by most nodes. The fee may be a bit higher, but if your use case justifies this inversion, then I don't think that would make much of a difference.

(But why would you like to store a seed phrase publicly? Don't understand that. You still have to store the key locally to access it ...)

---

I updated the OP adding a section about the NFT market economics which is an important additional aspect I think.

Good thread, perhaps missing a bit of graphics as I've mentioned in the other discussion. Minus points on the formatting, but that's just my personal preferences.  :P

Please don't widely recommend this behavior.  :P Someone might actually do it and then forget that they have done this only to find out their wallet emptied in the long future after the PGP key that they have used gets compromised. In the early days of PGP people thought that the messages are going to be secure for a long time so they wrote a lot of things that they shouldn't have. Some years ago all of these online exchanges have been deciphered, if my memory serves me well.

The change to the OP_RETURN size limit is more like a technical move designed to improve network efficiency and not to actually enable more spam. It is actually  supposed to be a kinda strategic effort to encourage data storage to shift from more harmful methods like those used by Ordinals to a less harmful one.

I think the core of the issue isn't about if data can be stored on the blockchain but kinda about how it's actually stored. The simple truth is, the market for NFTs and other data is kinda limited by what people are willing to pay and this change may not make storing that data any cheaper.
In the end the only real risk of a temporary increase in activity might be a new marketing trend and not really a fundamental technical shift.

Hmm, the only way I see pgp key related to curve25519 becoming compromised is if it’s exposed to the public. Sure, the method of storing the encrypted SEED on blockchain isn’t for those who don’t care about their sensitive information, like private keys, SEEDs, etc., and end up spreading them around. However, responsible users can still use it as long as they take proper care of the relevant pgp key. At least I know one person from Russian local who uses it. He himself came out publicly about it.


These are new protocols whose security has not been time-tested. :-\

You sadly didn't get my point, let me reiterate. I don't remember the exact time period when this happened, so ignore any errors regarding exactly when this occurred. 20-30 years ago people thought the exact same thing about the PGP keys of that time. They thought the key technology of that time would be secure for a very long time. They engaged in direct conversation using public servers, even sharing personal secrets to each other via PGP messages. All these messages were stored, and fast forward into the future it turns out that the keys from that time are no longer safe. Eventually somebody deciphered them all.

The point is, that even if you use the best PGP key derivation scheme it is secure according to what we know today. However, once you store this information on the Bitcoin blockchain it will remain permanently there. If you do this you could run into the same situation that people have already experienced in the past. It is best not to store crucial information in a permanent and public data storage. Don't get me wrong, the risk is really low but I don't like to encourage newbies or retail to engage in things that they barely understand at all. I have not met one retail person who understands PGP, different keys and potential risks of using it. I have met a few who know how to use it.

The argument against this is that the incentive is weak and completely irrelevant to a malicious actor. If they want to spam the UTXO set to damage the Bitcoin blockchain with bloat, they will. People who are against OP_RETURN are not convinced at all by this incentive. While I am not necessarily on their side, this is one argument that I am strongly convinced by. We should work on ways to make the bloat expensive or impossible, not try to persuade bad companies with weak incentives.

Very wrong. Nobody knows the real risks of the future. That's why some advocated for a gradual increase.

Great thread as always.
So if I'm not mistaken core is planning to make OP_RETURN rather than looking like a lady in fitted gowns
Look more like she's on Bikini.

Don't mind my example

What am saying is they are trying to make OP_RETURN an attractive option from the more destructive alternatives.
I believe those that would switch are those that plans on embedding 'honest' data
While does that want to share malicious content would still use the alternatives since they ain't prunable.

---

Michael saylor shared his view on this.
https://x.com/Sr_11ss/status/1968445597083648362?t=tUt4bs9f4YyFTG-iLBf2PQ&s=19

What do you think of his POV?

I have shown, by my test of Bitcoin core v30.0rc1  that this - increasing op_return will not lead to spam idea, is wrong

Check out the thread where I have added a malware zip file into the blockchain (test signature). This caused the blockchain to be identified as malware by clamAV. Anyone who wants to disrupt the network, or short the price has a mechanism of attack by causing fud and disruption.

So, not just for fun but for profit spam - is proved.

This could be done with 80bytes, but it is too small for AV detectors to find in Binaries, whereas with more room we can now insert whole malware programs in compressed (say zip) format, that AV software will detect and quarantine..

Check out my Security issue thread and test it yourself

Indeed. A malicious person would probably use the least prunable option, and that is not OP_RETURN. They would even probably not use the P2PK method I shared here (https://asktom.cf/index.php?topic=5559004.msg65818041#msg65818041). If it can be proven that this public key is fake, then it's too obvious, and the nodes could in theory simply prune that too, although they would need a special pruning feature which currently (I think) doesn't exist.

I wonder to whom the last part of his statement is dedicated. Perhaps to Luke-Jr?

Because as far as I know, the other Core developers discussed this change in a group discussion and agreed, with some (very vocal) disagreements but it wasn't "one well funded developer".

I think there is some truth in what he says, and I could imagine he indeed means Luke-jr. I honestly don't think Luke has bad intentions, he thinks that with his filtering actions he can help combat spam. However, as I have written several times, I doubt that this is effective, and seriously I also don't know how such a knowledgeable guy like Luke doesn't see the dangers of his filter approach -> what I always repeat, this could make the UTXO set explode eventually if the NFT creators use massively the fake public key method.

There's a solution even to an UTXO set explosion -- the new Utreexo technique -- but it could put unnecessary pressure on the developers to implement Utreexo in Core as fast as possible (until now, there are only small client projects having implemented it). See also the scenario I describe here in a thread about Utreexo (https://asktom.cf/index.php?topic=5559008.msg65820723#msg65820723).

Having thought about the Utreexo option I still think a gradual increase of OP_RETURN standardness limit is the best path, and in parallel, accelerate the Utreexo implementation for Core.

@wrapperbandolite: Read the OP again, I think you misunderstood what I meant, it is not about "make spam possible", but to increase spam levels the spam has also to be cheaper, and that's not the case.

And: Isn't your malware injection also possible using fake public keys like demostrated here (https://asktom.cf/index.php?topic=5559004.msg65818041#msg65818041)?

Of course, it was never like a flood of spammers would suddenly join Bitcoin from other networks as soon as Core 30 is released. That part has to be clarified.


I know gmaxwell explained this on a different thread, but I don't see why another implementation (i.e. a house) can't just simply lock all the doors shut, and then use some sort of warp drive to get inhabitants to the other house when something is missing from there. Equivalent to using a cache-miss to retrieve transactions from full nodes to avoid some people from having to keep all those zombie UTXOs on the disk forever.

It is destructive, but it's not a majority who are going to use it so it's fine.

Two quick points on “OP_RETURN won’t increase spam/harm”.

1) What’s new here isn’t “bytes on-chain” — it’s block quarantine.
I showed on Bitcoin Core v30.0rc1 (regtest) that if you embed a ZIP with a known signature via OP_RETURN, a mainstream AV (ClamAV) will quarantine the raw block file (blk*.dat). That’s an operator DoS: I/O errors, stalled nodes, broken backups/NAS scans. This is reproducible with scripts in my thread.

2) Size matters for AV behavior.
The 68-byte EICAR string already fits OP_RETURN, but a valid ZIP containing EICAR does not fit in 80 bytes. Engines commonly carve/scan ZIPs inside large binaries; they are less likely to act on tiny substrings. Raising OP_RETURN increases the ease/frequency of dropping recognizable containers (ZIP, nested archives, multiple signatures), which means more engines will hit and more nodes will be disrupted.

Re d5000’s “use the least-prunable path”: yes, an attacker can use other data paths (fake pubkeys, witness). My point is narrower: expanding OP_RETURN is a policy change that makes AV-trigger payloads trivial and “standard”. It doesn’t eliminate Door 1/2; it just opens Door 3 wider for a specific class of operational incidents.

Re NotATether’s harm analogy: opening the “guest room” door still lets in content that causes external systems (AV/EDR, backup scanners) to quarantine files the node relies on. That’s harm to operations even without code execution.

If anyone wants to verify: v30.0rc1 is out for testing; the Linux/Windows regtest scripts and paste-ready proof are here:
Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain (https://asktom.cf/index.php?topic=5559355.0)

So, as I understood, OP_RETURN is the least harmful way to store data on Bitcoin and since Bitcoin Ordinals are inevitably part of Bitcoin, it is beneficial for us to motivate those spammers to use OP_RETURN instead of using fake public keys and Taproot witness method? Am I right? (By the way, why do we have Taproot?) And they'll use OP_RETURN to temporarily market the Ordinals market to sell more of this spam shit? It will be another thing for them to hype for their own benefit, right?
I also want to know, does it matter for spammers which method they'll use? Fake public keys, Taproot or OP_RETURN?

Yes.


Taproot transactions allow you to combine the signatures of many different input addresses so that you can't reverse-engineer the public keys (and thus break them with quantum computing or kangaroos). You can create transactions in such a matter without requiring everyone else's public key if the Taproot script was designed for that.


No. They will use the one with the lowest fees.

Quick counterpoint on “OP_RETURN is least harmful, so funnel spam there.”

“Least harmful” ignores external systems. I showed on v30.0rc1 (regtest) that embedding a ZIP with a known signature via OP_RETURN causes a mainstream AV to quarantine the raw block file (blk*.dat). That is an operator DoS: I/O errors, stalled nodes, broken backups/NAS scans. It is reproducible and not theoretical.

Cost is not the only driver. Spammers, attackers and griefers pick the path that maximizes impact. Making OP_RETURN larger and “standard” lowers friction to drop recognizable containers (ZIPs, nested archives, multiple signatures) that many engines scan by default. Result: more AV hits, more incidents.

Even if fake pubkeys or witness remain options, opening OP_RETURN wider adds a new and easy route for a specific class of disruption. That is why I argue against increasing OP_RETURN without addressing the operational effect.

Repros and proof here:
Security disclosure: OP_RETURN embedding of Malware signatures into Blockchain (https://asktom.cf/index.php?topic=5559355.0)

I'm not even going to attempt to respond to your retarded OP and it's stupid and childish monster analogy.
Hopefully the readers are aware they are being gaslighted.

See here (https://asktom.cf/index.php?topic=5569189.msg66203284#msg66203284) for more info.

At least OP was kind enough to explain that in the past, spammers had to obfuscate their spam to make it look like a genuine transaction. This was done with fake pubkeys, fake scripthash, and so on.... They had to do this because file sharing and file hosting was never a supported and sanctioned use case on bitcoin. The only sanctioned and supported use case has always been money, and only money.

But that's not the case anymore. Now the spammers no longer need to obfuscate their files and make them look like something else. They no longer need to break up those files into pieces that look like a genuine bitcoin transaction.

Now they can send an entire jpeg, any file they want really, no matter how illegal, disgusting, illicit, or immoral. No need ask a miner for permission anymore. They can just send any file they want and they will be using the network EXACTLY as core designed it for them.

Core effectively made file sharing of any kind, a new supported and sanctioned use case of bitcoin.

And you think that's not going to end in a lot of fuckery? Really?

For other reader,
1. Regular block explorer and wallet doesn't show/decode arbitrary data, whether it's OP_RETURN, witness data or other approach.
2. There are few specialized block explorer that show/decode arbitrary data whether it use OP_RETURN or other approach.
3. With some approach (such as witness data or fake public key), spammer could avoid splitting files into pieces if the TX size isn't higher than 100 vKB.

---

For other reader, such thing is already possible even before SegWit/Taproot exist and OP_RETURN limit raised.

I'm sorry to inform you that OP is full of shit. You've been gaslighted.

- Op_return is some ways is less harmful than other spam methods. But the spammers would lose the segwit and taproot discounts. So they are not likely to switch to taproot. The coretards told us for 4 years that "the fees are the filter" and they are suddenly ignoring their own bullshit claims when it no longer suits them.

- Ordinals are not inevitable. Someone suggested an ordinal filter 2 years ago. Coretards invited a bunch of spammers to bitch about censorship. And they also changed a definition in their documentation. Than they rejected the filter by claiming it's too controversial and based on the new definition they just changed.

- We have Taproot and Segwit mainly as scaling methods. They are both good upgrades. But like all code, they come with bugs and exploits. The problem is that core has refused to fix any of the bugs and exploits of Segwit and Taproot. Mainly because they don't think spam is a thing. Murch (core dev) doesn't know what spam is. And Zhao (head dev) calls it "use cases we have today" instead of calling it spam. And she claims Satoshi didn't have the foresight to plan for those "new use cases we have today".



That is false. File sharing was NEVER a supported use case of bitcoin, until core 30 anyways
You could post a file on bitcoin only by obfuscating it to make it look like a genuine bitcoin transaction. Even OP admits thus much. Thought the rest of his childish and ridiculous monster analogy is pure bullshit.

We're not even emphasizing more on the fragment limits encouraged by OP which updates of recent time such as Bitcoin Core V30 target to either increase or eliminate for the purpose of current demand satisfaction. Can't even neglect the fact that the move caused issues that have left users no option but to move towards more preferred software such as the Knots to fish spam out thereby creating fragmented network, making nodes notice some dealings while others do not really see it.

OP is full of shit bro.

The ridiculous and childish monster invasion analogy is portraying spam as if it was some sort of unstoppable force of nature and nothing we can do can prevent spam.

Well, that's effectively true when you have core head ded shitcoiner Zhao going around promoting spam as "new use cases we have today".
And people like OP claiming a filter doesn't work because it's slowing down the block propagation speed of a block that is full of spam. Completely ommitting that this is precisely the point of the filters: causing trouble to miners who add spam to their blocks.

The world wide demand for cheap forever data storage is infinite. There is no end to it. It's up to us to fight back and use adequate filters.

Just don't count on core to do anything about spam. They have been doing nothing about it, and even going as far as blowing up an existing filter. All to push for their " new use cases we have today"


This is pure bullshit and you know it.
The very purpose of filters is to slow down the block propagation speed for the miner who puts spam in his block. So the filters are a form of speed bump that comes up only for the spam miners.

You are correct in saying that filters are slowing down block propagation. But that's only a problem for a miner who puts spam in his block. And you know this very well. You conveniently omit to tell the whole truth.

Is that your alt account you're talking to, Pepe? ;D Thanks for bumping my thread anyway for free :)

(Seriously, do you think swearing will make your arguments look more intelligent? I'm quite curious about the fundaments of this theory.)

Just some reaction because some uninformed people could think you are bringing some kind of argument on the table:

Erm, it doesn't seem you have understood the compact block mechanism.

The trouble is actually caused to nodes who have too strict datacarriersize configurations, as these have to re-download the transactions they previously "filtered" and then rejected, causing them higher bandwidth costs. Miners? Are fine with Knots and other nodes with different configurations.

Admit that you don't care about nodes at all. :)

I don't believe Bitcoin is particularly cheap as a data storage. Even if you add the "forever" word and limit yourself to blockchains which may be able to compete with paper for longevity. Solana, BSV, and other chains are much cheaper. And judging by the fact that even minuscule altcoins from 10 years ago still are run by some nodes, storing 10 copies on these small altchains, checking regularly and look for a new coin if one gets really offline, should be several orders of magnitude cheaper than on BTC.

Data storage isn't really the problem. The problem are NFT waves, that's different from economics perspective.

We're talking about two different thing. I mentioned there are ways to add arbitrary data (even without SegWit, Taproot or OP_RETURN). But your respond is about whether Bitcoin support file sharing feature.


About obfuscation, i already mentioned most wallet and average block explorer doesn't show/decode arbitary whether it use OP_RETURN or other approach. So to average people, all approach appear to be hidden/obfuscated. In addition, those approach considered as standard transaction, so they don't need to request miner to add their non-standard TX manually or semi manually.

It sounds convenient, but the OP_RETURN size limit is intentionally small to protect Bitcoin’s decentralization. Allowing large encrypted payloads would encourage blockchain bloat, increase long-term storage and bandwidth costs for all nodes, and turn Bitcoin into a general data-storage system. The cost and inconvenience you mention are deliberate disincentives. Also, storing a seed phrase on-chain—even PGP-encrypted—creates a permanent risk if the encryption is ever broken. Safer practice is to keep sensitive data off-chain and, at most, anchor a hash or reference on the blockchain rather than lifting the OP_RETURN limit

As I pointed out in an earlier thread, if you create a model for 'forever' that involves paying into an investment account then using the dividends to pay for S3, -- it turns out that even Amazon S3 'forever' is orders of magnitude cheaper.  Between that and the other blockchains, as you note, it means anyone putting data in Bitcoin is almost certainly motivated by what they consider a compelling reason to do so.  Which is why speedbumps are not very effective, why they're willing and able to just directly pay miners and bypass any relay policy, etc.

This isn't to say that I agree with their motivations or like their motivations-- just that they exist, and their existence overcomes any amount of pepe's spam derangement syndrome.

The biggest of these motivations is that using Bitcoin limits the supply of tokens-- the other alternatives that are much cheaper do not.  Because of this limits in Bitcoin that inhibit NFTs have a real risk of making NFTs in Bitcoin *more* valuable or otherwise just canceling themselves out.

Certainly all the blather about it is an astonishing amount of free advertisement that they couldn't otherwise get at any price-- and that's worth pretty much any amount of transaction fees.  For the last year the biggest promoters of NFT crap have essentially been the ocean-affiliated pro-censorship crowd and their buddies.  This is another big advantage they get by using Bitcoin-- but unlike the limited supply it's one we don't have to give them.

What you are talking about is simple logic. They won't understand what you are talking about.
In order for coretards to understand what you say, you have to think like them. You have to do absolutely nothing about the 4 year long current spam attack, and you have to talk about spam as if it were an unstoppable force of nature.

They think they can't stop spam, while they are actively rejecting new ordinal filters, and blowing up the op_return filter. And so they think the only way to deal with spam is to create more ways to spam.

And most importantly, you have to treat every anti-spam measure as it it were censorship. If anyone tries in any way to stop coretards from posting dickbutt jpegs, that's censorship akin to censoring all Iranian UTXO's or all non-OFAC compliant UTXOs. Because coretards think node runners don't know the difference between dickbutt jpegs and Iranian UTXO's.


If you care about people viewing your stupid monster analogy, you should move it to the General section where 5x more people will see it. Here in the Dev & Tech section a lot less people will see your thread, and they don't care as much about spam in this section.

But the spam promoting mods are likely to move it back to a lesser section again. However since you are promoting spam, your thread has a higher change of not getting moved around.


So you want to promote spam AND you want respect? Sorry cupcake, that's not going to happen. You have to pick one or the other.



The most important duty of the nodes is to regulate the miners. The nodes do that by verifying that the blocks are valid, and by filtering spam.

But you are claiming if the nodes just learn not to filter and to go along with whatever the miners want to mine, no matter how spammy, than the nodes will have an easier job.

This retarded idea that nodes have to go along with miners and bend the knee to spam, it's pure post modernist bullshit.



Call Google and ask them how much they charge to store whatever file you want, until the end of time, even after you die, on 90,000 separate Google servers for redundancy. And tell them that you reserve the right to submit whatever material you want, without them monitoring how illegal/gross/immoral your data is.


They are all scams. Everyone knows it. Spammers want to put their filth on the only legit and original real blockchain. And the coretards ate bent on making it easier for them to do so.

But your idea that spam is not a problem, that miners filling their blocks with spam, that's not a problem either. That the real problem is nodes filtering spam and not going along with what miners want, that falls in line with the core policy they impose on all their nodes.


Wonderful! Now how about you call Amazon and ask them if they will allow you to upload any sort of illicit/immoral/illegal files on 90,000 servers, and keep it forever for you.

Ask them if they moderate child p**n, snuff, rape stuff, and other disgusting stuff.

Because since core 30, bitcoin will do that for you. Thank you, coretards!


You can claim all day that you disagree with spam. But your actions speak louder than your claim.

- You elude that filters are a form of cebsorship. When you, yourself, wrote in some of those filters.
- You shill for core removing a filter.
- You insult and resist every simple attempt at fighting spam

Your actions say it all, you are a spam shill.


That is such bullshit. There are around a dozen filters already running on core since forever. Except the one core just neutered.

And if you look back, you will see that 99.99% of the transactions miners put in their blocks go along with the filters widely applied by nodes. Filters work. Stop repeating this bullshit that they don't work.

In fact the coretard logic is pretty transparent:

- "The filters don't work, but we have to turn off the filters because they prevent us from doing what they are filtering for."

So tell us cupcakes, if the filters don't work, why do we have to turn them off? If the filters don't work, why doesn't citrea just use the large op_return with the filters up?
- Because, obviously, filters work.


Spammers stay on bitcoin because:
- They finance core
- Core did nothing about spam for the last 4 years since it started.
- Core lead dev doesn't even acknowledge there is such a thing as spam. She refers to it as "use cases we have today" and she claims that Satoshi failed to make room for it.
- Core sent as far as blowing up a spam filter.
- You coretards keep parroting that fighting spam is censorship.

---

Here is the reality. All the Amazon servers and Google drives of this world won't allow you to upload illicit, illegal, or sensitive material. They don't want to be held liable for that stuff. So they filter all the content that gets uploaded.

Go ahead, call Amazon and ask them to host child p**n forever on 90,000 Amazon servers. See how much they are willing to charge you for that service.

Because core 30 will do it for you. They'll force the 90,000 nodes to host your filth for free and for eternity. And for practically free too!

That's when the coretards come in and say "They could always do that all along"

Explain how, coretards. Give specific details. Will you break the file into 40 smaller pieces, and obfuscate the 40 pieces to make them look like a genuine transaction? Something that no antivirus and no drive scan will ever recognize as child p**n?

Will you go to a miner and offer him a fee to post your child p**n? Because they won't do that!

Will the file be contiguous, like in a blown up op_return?

I want details, exactly how "that was always possible"?


[moderator's note: consecutive posts merged]

Assuming 0.1 sat/vB, 1 BTC for 1 GB is not "for free".

Not "for eternity", because a lot of nodes are pruned.

Before transaction standardness was introduced, you could use just OP_PUSH, to upload anything in a single chunk. Also, your transaction could have zero fee in 2009, and it was possible to spend coins, which are unspendable today, by using "OP_TRUE OP_RETURN" in your input Script.

Sure, in the old days, your scriptPubKey could contain any garbage, which today could be unspendable, but then, you could move it with "OP_TRUE OP_RETURN". As well as every other coin in the chain, without any signatures. Try 0.1.0 version from Satoshi, if you don't believe me. Of course, to test it, you would need Windows XP, or some virtual machine with it, and at least two connected nodes, even locally.

Also, in the old times, DER signatures could contain any data at the end. They were simply ignored, and accepted as valid.

I said THE NODES are forced to host that shit for free for the rest of time. The miners get paid to add it to their block. But the nodes, regardless of what filter they run, still have to host it.


You are being pedantic. If the chain is, say 5 TB because of the spam in 5 years, you will need a 5 TB drive to download the entire chain before you can prune it. And you still will have to download every single full block before you can prune them. And you are no longer a fully functional full node, which is a centralisation risk.


Let me rephrase my question. The coretards always love to claim that uploading illicit data was always possible. So how would you do it the day before core 30 was released?

Specific step by step details, please. Explain it to me like I'm 8 years old.


V0.1.0 on XP? Are you serious?
Explain in details how you would do it, the day before core 30 release.


Would that be V0.1.0? Or V0.1.1?
Seriously man!

Give me specific details. What wallet would you use the day before core 30 release. Which miner would you call? How would you construct your transaction exactly?

No. Pruning is done continuously. If you set it to 2 GB, then only 2 GB of blocks will ever be saved. Then, old blocks will be removed, to make a room for new ones.

Only in today's version. And even today, many people don't do that. Also, many users use utreexo, or other kinds of nodes, where it is not required.

Not to mention that you need to do it only once. Later, you can trust your own node, because if you cannot, then your whole setup is unsafe.

And even if you assume, that you have to download it, then still: it is not something, which is easily accessible by the outside world, because when your node is in Initial Blockchain Download mode, then it doesn't share blocks outside. It starts doing so, after downloading everything. And if pruning is enabled, then guess what: it will share only the last 288 blocks, or something like that, to the outside world.

Which means, that if some spam has for example 2000 confirmations, and was done two weeks ago, then it will never be shared by pruned node to the outside world. Because even if you set your pruning to 200 GB, then still, only 288 blocks will be shared to the outside world, for privacy reasons.

Stop making excuses. If you run a pruned node, you are running a crippled node that can't do it's full job like a full node does. The network needs more listening full nodes .Not half baked neutered pruned nodes.
 

In don't believe that is correct.

Then, how my node with 40 GB hard disk could be synced? Do you think it magically stored 700 GB with 40 GB capacity somehow?

Also, what prevents a node from removing validated data? If the chain has 100k blocks, then it can be verified with the same algorithm, as if it has 200k blocks. Pruning can be set at any point in time: if there are too many blocks, then they will be removed. If there is not enough, then future blocks will fill that space.

Only because of Initial Blockchain Download. Otherwise, they wouldn't be needed, because each user could store its own transactions, and not care about the rest. Because nodes don't have to store transactions: they only need to know, that the chain is valid. If it wouldn't be the case, then altcoins like Monero wouldn't exist at all.

Still, pruned nodes, or even utreexo nodes, are better than SPV nodes. It is better to provide these half-baked nodes, because otherwise, many users would do, what they always do in such cases: if verification is too complicated, then they just skip it altogether.

It is correct, you can happily bring up and run a node on a system with a 20gb drive today with no issues and you've been able to do so since ~2013.

For all your crying about node resource use that really should be something you care about and know-- it makes me wonder if you've ever used bitcoin or if you really are just some paid disruption and not just the pervert obsessed with non-existing child abuse images that you appear to be on the surface.

I think you're shooting yourself in the feet with that writing style, that's all. People will simply draw their own conclusions.

True, but as long as consensus rules are not changed, nodes can't do anything about blocks which were already mined and are respecting the protocol.

Nodes (like Knots nodes with default configuration) that try to impose their own policy rules, will have to download blocks without the compact block benefit. That's simply how it works, not how I want it to work (or Core). These nodes simply have to accept to have higher bandwidth costs, according to the current protocol.

You would thus need to build a forking option into Knots (or whatever client). But that's not gonna happen. Nobody with a sane mind will run a node with crappy amateur code which only generates chaos confiscating all types of coins, like BIP-444 or "The Cat".

I repeat: Come up with a filtering mechanism based on consensus (not mempool policy) which doesn't confiscate existing coins and doesn't cripple features like Lightning, and we could be talking :)

It's the Bitcoin protocol as Satoshi envisioned it (yeah, I know, shameless namedropping). Get over it :D

I have purposefully not mentioned any cloud based solutions so this comment is pointless.

I even agree with this, but the incentive mechanisms are there for these chains to be up for decades or even centuries. And I would even say: if big altcoins die, then Bitcoin is also close to die.

No, that's not "my idea", and I have repeated that several times, including in the OP. My point was always: spam is a problem, but dealing with it without harming Bitcoin is a challenge.

Do your accept that challenge? Then work on a proposal like I wrote above: a proposal which makes spam more expensive but without confiscating coins/UTXOs. Or tools to delete meaningless spam UTXOs from nodes (note the difference to "The Cat"). I've already dropped some ideas, or ACK'd ideas from others, like @franky1's idea to enforce dust limits by consensus.

I think you're panicking because everything I wrote in the OP has become true until now, less the part where I expect a small spam wave. So the narrative of you folks is imploding.

That doesn't mean such a spam wave couldn't still happen. Some in that camp are perhaps really that angry that they will now coordinate a spam wave, perhaps when Core 30 share > Knots share (now Knots still has some percenage points more).

Jesus Christ, man! Listen to yourself.

They are removing a spam filter.

THAT WILL RESULT IN MORE SPAM.

They rejected Luke's spam filter based on retarded made up excuses.

THAT WILL RESULT IN MORE SPAM.

They don't even acknowledge there is spam, the core head dev calls it "use cases we have today" that Satoshi failed to foresee.

THAT WILL RESULT IN MORE SPAM.

They removed the definition of bitcoin as money from their documentation and I can't find the word money or currency anywhere in their docs.

THAT WILL RESULT IN MORE SPAM.

The head core dev is giving bitcoin maximalists the thumbs down and giving NFTs the thumbs up.

THAT WILL RESULT IN MORE SPAM.

Every time we say the word spam, they move us to a section with fewer eyeballs.

THAT WILL RESULT IN MORE SPAM.

They called a spam filter that was running for 11 years censorship.

THAT WILL RESULT IN MORE SPAM

They equate Knots' spam filters to censorship.

THAT WILL RESULT IN MORE SPAM.

They are saying that nodes should align their mempool with what miners want to put in their blocks.

THAT WILL RESULT IN MORE SPAM.


Citation needed.


Here's what on my to-do list:
- Mark core as deprecated, they pretty much did it to themselves already.
- Fight spam at all levels, including at the policy level with Knots filters.
- Fight spam at the consensus level, including with BIP 110
- Fight spam at the UTXO set level with The Cat. And go to hell for even suggesting we should play by the rules and be nice to spammers who use fake pubkeys, fake scripthash, and always just above the dust limit to fool the system into thinking they are monetary transactions.

But since you want to fight it strictly at the consensus level, look into BIP 110, and support the raising of the dust limit at consensus level. I personally would prefer to go with 50,000 sats, and to expire in 5 years. But 5,000 sats dust limit would be an easier sell. Still, I guaranty you, coretards and Maxwell will find a way to resist that one too at all levels, like they have for every other attempt to fight spam.


Gosh! Thank you for that info. Now since having the full chain is not important at all, I's going to go chop off most of it on my node and only carry the last 2000 blocks, okay!

And since I also learned from you and the rest of the coretards that filters don't work if there is an economic incentive to go around them, I'm going to turn off all my filters now. Even the ones working for the last 15 years or so. Because, you know, censorship!

And well, without filters, what's the point of even running a mempool? So I'm going to yank that out of my node too!

And as you already pointed out, spammers can get around the consensus rules proposed by BIP 444/110. So, I'm going to yank those too out of my node!

[/sarcasm]

It's a real shame that you and I won the block war over the idea that fully operating nodes are vital to the survival of bitcoin. And now you are going around diminishing every aspect of running a node.


I'm not very smart or knowledgeable, I get by on my looks alone. From your looks, I gather you are a freaking genius.

Well he is a well known programmer, published author, has several patents, amongst other things.
And uses his own name.

You on the other hand claim to be a talking skunk.


-Dave

Sorry to break this to you - talking skunks don't exist.
I know it sucks that you can't attack my person, right?

Greg Maxwell is doing a 180 from the block war small block argument - he is trying to minimize the role of nodes, like the rest of the coretards.

You are all shilling for pruned nodes, because the full blockchain is not important. You are all shilling for the removal of spam filters because 99.9% effectiveness is not good enough. And you are all cheering core in their statement that nodes should align their mempool with what miners want to put in their blocks.

Fight spam at the mempool level? - "NOOO, cant's do that, that's Knotzism!" says the coretard.
Fight spam at the consensus level with BIP 110? - "NOOO, can't do that, that's useless!" says the coretard.
Fight spam at the UTXO set level with The Cat or The Lynx? - "NOOO, can't do that, it's the same as banning Iranian UTXOs!" says the coretard.
"But what is spam, anyways?" says the coretard.

You coretards are so obvious.


Now, re-read the quote above and replace all instances of BitDSN with the word spam.

No, I can't attack you as a person. But, then again I don't want to. Personally you don't matter to me one way or the other.
You seem to be happy being an anonymous troll so that is more or less what you are in my mind.

Your ideas of what you want to do, those I can attack.
You have shown that you want to block some transactions that you do not like.
And that is easy to attack.

You don't like some transactions since they are pictures or whatever and you don't think they should be in the blockchain.
I don't think any transactions going to PepeLapiu should be in the blockchain.
There is zero difference between those 2 things. Someone is paying a miner to put data they want into the blockchain.
Miners, are doing their job and putting in what people pay to put in so long as they are valid TX.

That's it, plain and simple. Pure capitalist economics at it best.

You want some kind of regulated by 'people who know better' socialism where everyone gets space in the chain. Even if they can't pay or don't want to pay more to get in because the current blocks are filled with what you consider spam. I just like the pictures.

-Dave

---

With the amount of post surgical pain killers I'm on, I disagree. They most definitely exist. Heck I just saw some weird alien looking guy muttering something about
"Where's the kaboom? There was supposed to be an Earth-shattering kaboom!"

The head core dev is on record calling spam "the use cases we have today" and I'm the troll?
They blow up a filter that was 99.9% effective at keeping op_return under 83 bytes and claim that it wasn't working, and I'm the troll?
The of the devs said he can't figure out what spam is and I'm the troll?


Bitcoin is money. Bitcoin is here to provide you with monetary freedom. Not to be the redundant free 90,000 servers file sharing platform for any data you want. If you need Satoshi to explain it to you, replace the word "BitDSN" with "inscriptions" in the following Satoshi quote:



That would be a monetary transaction. Spam is non-monetary and bullshit. Spam is junk and constitutes a hatdware/software/moral/legal risk nodes are not interested in taking on.

Bitcoin is not the place to preserve your right to dickbutt jpegs, anymore than your Muslim temple is thebplace to protect your Jewish right to religion.


And nodes are not doing their job to preserve bitcoin as money. You can blame the core spamware for that.


You are clearly a shitcoiner and a lover of spam.
Bitcoin is money. You can use it to buy your dickbutt jpeg or to buy a plate of pancakes.
But neither your dickbutt nor your pancake belong on the bitcoin chain.

Here is what you fail to realize: these people are not users, they are not bitcoiners. They are attackers. They use fake pubkeys, they use fake scripthash, they use the taproot exploit. There is nothing legitimate about what they do. They only put the very minimum amount of bitcoin in those UTXO to get above the dust limit. They do all these tricks to fool the system into thinking their spam is actual real bitcoin transaction. But it's not. And it makes me sick that people like you, and Maxwell, and Back, are fighting so hard for their ability to cheat the system.

No (http://). Yeah, you wrote "will", but we should be seeing slowly some effects if your fears are true.
But the fears are unfounded. Because I repeat again: the incentives are not changed. Given a certain NFT market (and thus a predisposition of NFT/data transaction creators to pay a certain amount of fees on average), then the cost is the same.

You are thus questioning that nodes should accept blocks which are fulfilling all consensus rules of the protocol?

Unfortunately your list doesn't meet the requisites I mentioned for the "challenge". In BIP 110 (ex 444) it is already clarified that it will harm BitVM. BitVM is a technology with potentially big scaling benefit. BIP 110 thus harms scaling, it doesn't improve it.

You (purposefully) "misunderstood" the rules of the challenge.

The challenge isn't to not confiscate coins with fake pubkeys etc. which anyway cannot be spent. But we don't need a consensus change for that. Nodes can simply delete them.
The challenge is to not confiscate legitime, financial transactions with not that conventional scripts, like BitVM.

Okay, finally some constructive ideas, even if they need to be elaborated a bit.

5000 sats are currently a bit less than $5. That looks like an okay value for now, a little bit too high though imo, I'd put it at an equivalent of ~$2 as this would make fake public key JPEGs already quite expensive, and even tokens with mechanisms like SRC-20 would already be affected. However, it would be already a bit much for a $200k Bitcoin which looks possible in the next years. If you always have to fear to lose $10 in any payment because the change is below the dust value, it would be difficult to use Bitcoin for purchases, and basically for any purpose which would not strictly be storing it like "digital gold" and buying/selling on exchanges.

For now I could imagine two options to deal with this:

First, to find an indicator you can tie the dust limit to, to get a relatively stable value measured in USD or purchasing power. Minimum relay tx fee (which is now tied to the dust limit) is a policy value and changed arbitrarily, so it isn't the correct one.

My uneducated guess would be to use the hashrate with an adjustment for Moore's Law. This limit could be set temporary in BIP-110 style and thus be "renewed" each year if it's too high or too low.

Second option is to allow a single output (or at most, two) per transaction with a value below the dust limit. This would not make JPEGs cheaper, and the advantage is that in this case you could indeed set the dust limit higher (to values like the 5000 sats you proposed).

I'm thinking about opening a separate thread for this sub-discussion.

One disadvantage of these approaches based on dust limit is that it would cripple Lightning and make microtransactions on that layer more difficult. However, I see Lightning's final use case as a third-layer technology, the second layer should be sidechains, and sidechains would not be affected (they would be benefitted if BitVM etc. are not crippled).

You conveniently misquote what you are replying to.

The fact and the matter is that core 30 effectively and fundamentally changed bitcoin without consensus and without the support of bitcoiners.

Spam is now a sanctioned and supported use case of bitcoin, Thanx to coretards.


Core 30 spamware is signalling to spammers that we will now cater to them and make spam a use case of bitcoin.

Yes, they could always break up files into little pieces and/or hide them in fake pubkeys or fake scripthash and/or skirt the dust limits and/or pay off a spam miner like Mara to ignore filters.
But since core 30, they don't need to hide anymore. Because spam is a supported and sanctioned use case with core 30.

But that's no surprise to anyone because the core head dev is already on record saying she likes NFTs and she things spam is "use cases we have today" that she thinks Satoshi failed to build for.


Funny how you reject fighting spam as a problem to scaling. That's so cute!
Nobody gives a flying fuck about BitVM. If core can't fix the exploits of earlier upgrades like SegWit and Taproot, I have no desire to entertain any future upgrades.

Let us fix the problems of previous upgrades before plunging head first into future ones.
.

I see. So the UTXO bloat proem was used as a major reason to blow up a spam filter. But now we aee back to pretending UTXO bloat is not really a problem at all because "nodes can simply delete them"?

It's that a bit too convenient? A UTXO bloat problem when in service of blowing up spam filters, but no longer a problem when in service of fighting spam?


I disagree. I would put the dust limit much higher. But I think that would be a hard sell for many others.
Again, in wallet warnings could mitigate the inconvenience and risk. And anyone wanting to do smaller payments could always use L2s.

I can see two ways to go about it:

- 5000 SATs dust limit to expire in 5 years. Which would basically dislodge a lot of the spam industry being built on top of bitcoin. But they could resume after the 5 year expiry.

- 5000 SATs dust limit with a reduction of 15% every year or so. Or a halvening of the dust limit at every halvening. This would hopefully match the price increase and be a more sustained measure over a longer period. But the future price could push this measure to become too extreme or too weak.

For now I could imagine two options to deal with this:


I don't know how to implement that. But it would be interesting to look into it. I think it would be fun to tie the dust limit to the price of a BigMac? 😝😝


I don't like it. It's not strong enough. It leaves too much room.for spammers doing multiple TXs.


Do make sure to put it in the General section, and watch how fast a retarded mod moves it to a less visible section with fewer eyeballs.


Not really. It would only be a problem if you try to open or close a channel with less than 5000 sats. And again, in wallet warnings could mitigate that.


Edit:

I already did just that. Let me know what you think.
https://asktom.cf/index.php?topic=5569843.msg66231224#msg66231224