I don't understand the arguments for Bitcoin Core v30

[Ambatman]

I can see now why using OP RETURN is less costly for nodes and safer than fake pubkeys or inscriptions. but i’m wondering, does this incremental limit 512 → 1024 really make a big difference? i mean, if an attacker really wants to, they could just pay the fees and send multiple OP RETURNs anyway also, since some wallets or L2 solutions can batch or compress OP RETURN data the node impact can already be somewhat controlled does this limit actually change much?

It wouldn't change much.
But this is the beauty and horror of subtleness. It makes changes easier to accept.
 

Even OP Return full limit being removed wouldn't change much since it still can't stop spams that can't be prunned

protocols needing unprunable data for permanence may increase their use of using fakepubkey outputs if demand grows

[d5000]

I can see now why using OP RETURN is less costly for nodes and safer than fake pubkeys or inscriptions. but i’m wondering, does this incremental limit 512 → 1024 really make a big difference? i mean, if an attacker really wants to, they could just pay the fees and send multiple OP RETURNs anyway also,

Currently there is a limit for one OP_RETURN output per transaction. In my "ideal scenario" I would preserve this limit for the next 2-3 Bitcoin versions. So the attacker (or NFT creator) would have to send several transactions to encode an image or video, and that would generate a lot of overhead for them.

It wouldn't make sense to develop a NFT protocol first for 512 bytes transactions, then 1024 and so on. At least, it would be very difficult to initiate a NFT fad (like the Ordinals fad in 2023/24) in this fashion. They would rather choose to use the existing fake public keys or the Taproot envelope format.

since some wallets or L2 solutions can batch or compress OP RETURN data the node impact can already be somewhat controlled does this limit actually change much?

Here I don't understand what you mean with L2s batching OP_RETURN data. But in general you are correct: the computational impact on nodes is low also if the limit is removed completely. My post was about the fears that a new NFT fad with thousands of junk transactions could develop right after the v30 publication. See also my conversation with @gmaxwell.

[kano]

I'm really having difficulty understanding why people are against this change.

As many have already explained here (and in the other thread):
1) it's not allowing something new - you can already do it and it's often done
2) it also suggests to use OP_RETURN to reduce adding permanent data to the UTX0 set

Many of the against arguments seem to ignore 1) and don't understand 2) at all.
Or worse come up with some other unrelated comparison that isn't BTC (e.g. BSV is not the same as BTC in this regard)

Proof of 1) has been given clearly by theymos in the other thread, which is a 984587 byte jpg picture stored in a transaction in the current blockchain in block 896722 about 5 months ago
https://bitcointalk.org/index.php?topic=5557375.msg65811236#msg65811236

2) while it doesn't force the fix, it gives an option to reduce data added to the UTX0 set, as an added bonus

The repeated arguments against, telling how it will allow something, that is already allowed, seem to suggest there is some misunderstanding.

[Satofan44]

I'm really having difficulty understanding why people are against this change.

As many have already explained here (and in the other thread):
1) it's not allowing something new - you can already do it and it's often done
2) it also suggests to use OP_RETURN to reduce adding permanent data to the UTX0 set

The communication of Core has failed on this subject and then others like luke-jr abused this opportunity to spread misinformation. The response from Core or Core followers made things even worse, not better. Every now and then I still find myself in chatrooms trying to dispel the idea that this turns Bitcoin into a data storage method. I'm following the explanation given by gmaxwell that this is merely aligning the limits with the practical reality of the network and that the data shows that miners mostly already bypass it. In practice not much changes then. Still there is a lesson here to be learned on communication and they should strive to improve it and not take the high road.

2) while it doesn't force the fix, it gives an option to reduce data added to the UTX0 set, as an added bonus

Some proposals and ideas regarding spam protection would be worthwhile instead of the "whoops, this problem is not fully solvable so we don't do anything at all - deal with it ¯\_(ツ)_/¯" approach.

[d5000]

The repeated arguments against, telling how it will allow something, that is already allowed, seem to suggest there is some misunderstanding.

Apart from what @satofan44 wrote -- although I think that the "anti-Core" side is more to blame for the communication problems, but that was discussed in detail here -- there are some arguments that do have some merit:

1) The OP_RETURN "limit lift" could encourage new NFT business models because it communicates that "data storage" is an "official feature" of Bitcoin now.
2) It makes it easier to upload contiguous large data blobs, including malware.

But there are also quite simple counter arguments:

1) NFTs benefit from a scarcity - cost relation. Cost (transaction fees) will not be decreased with this update, and "being an official Bitcoin feature" could even be detrimental for the "scarcity" aspect.
2) Is probably not relevant enough because the existing protocols (those using fake public keys and Taproot envelopes) provide already a selection of tools to easily upload data. @gmaxwell has already debunked the malware argument here. And as written in the mailing list, if an image in an OP_RETURN is problematic then it will be also be problematic in a Taproot envelope, and probably also if stuffed into fake public keys.

Thus for me these arguments do not diminish the advantages the change has.

[renee25]

I'm really having difficulty understanding why people are against this change.
....

If ain't broken don't fix it.

https://x.com/NickSzabo4/status/1973548206245261549

IMHO what should be done is standardizing ways to store ordinals, NFT, whatever, OFFchain or in ANOTHER chain,
 
NOT relaying them thru the bitcoin network AT ALL.

A tiny conection to bitcoin, with a merkle root for each of those chains, like the hash linking NAMECOIN to BITCOIN for MERGE MINING can be done at block level, with a merkle root . AND without any mining or new coin. sidechains has been proven to work. you basically store the data in their a DHT and use LIGHTING for to pay for to store data there.

[mcdouglasx]

So this is a typical case of "let's make a wider path for cyclists on the road so they don't have to invade the car lane and hinder vehicular traffic"

Although this in itself doesn't resolve the ethical issues surrounding what data should and shouldn't be allowed, at least from my point of view, it improves data traffic within the blockchain by redirecting it to a non-spendable zone where it can be easily identified.

[tofinard]

Bitcoin's main strength is its simplicity and robustness. The fork with BCH was "legitimate": satoshi himself wondered if increasing the size was a good idea... In the case of version 30, I wonder if the coders aren't just jealous of ETH's possibilities.... Hey guys... if you're going around in circles, Vitalik is waiting for you!!! Why pave the way for a heavier blockchain and all the crap that can be written in the blockchain in plain text?

[satscraper]

If you've updated your Bitcoin Core to version 30, add the following entry to your bitcoin.conf file:

Code:

datacarriersize=80

This helps reduce the spread of malware relevant instructions, spam ^{such as inscriptions}, and other garbage on bitcoin network.

For reference, the datacarriersize configuration option was "undeprecated" two weeks prior to the release of Bitcoin Core v30, according to achow101 response  in this pull request.

[Satofan44]

Bitcoin's main strength is its simplicity and robustness. The fork with BCH was "legitimate": satoshi himself wondered if increasing the size was a good idea...

It is not legitimate, it is a scam that is used to trick gullible idiots like yourself.

In the case of version 30, I wonder if the coders aren't just jealous of ETH's possibilities.... Hey guys... if you're going around in circles, Vitalik is waiting for you!!! Why pave the way for a heavier blockchain and all the crap that can be written in the blockchain in plain text?

If you write something like this that clearly demonstrates that you don't know anything about anything. In terms of technology Bitcoin is the most superior chain. There is not a single other blockchain where people are refusing features by choice. Bitcoin could be made much more capable than ETH within 1 year, but because it is not developed by wannabe experts posing as tech gurus stupid features are not introduced on the base layer. Core 30 does not introduce any new behavior.

If you've updated your Bitcoin Core to version 30, add the following entry to your bitcoin.conf file:

Code:

datacarriersize=80

This helps reduce the spread of malware relevant instructions, spam ^{such as inscriptions}, and other garbage on bitcoin network.

For reference, the datacarriersize configuration option was "undeprecated" two weeks prior to the release of Bitcoin Core v30, according to achow101 response  in this pull request.

It is the best compromise that we are going to get, it is better than nothing.

[d5000]

IMHO what should be done is standardizing ways to store ordinals, NFT, whatever, OFFchain or in ANOTHER chain,

The problem is that the NFT guys "want" to eternize themselves on the BTC "OG" chain. In their logic, that increases the value of their garbage.

RGB (or Taro) could be used for BRC-20 style tokens, to trade them on Lightning. Because really, for meme tokens there is no reason to be issued on-chain. Perhaps eventually that will take off when people realize they save lots of fees.

For Ordinals in the proper sense (sats which "carry value"), perhaps also some offchain mechanism could be found.

This helps reduce the spread of malware relevant instructions, spam ^{such as inscriptions}, and other garbage on bitcoin network.

Thanks for the news about datacarriersize, imo a good decision. However, IMO 80 bytes is too low. I'd put it on 256 or 512 -- still too small for any image (which will then continue to use Inscriptions), but large enough for sidechain commitments.

[gmaxwell]

For reference, the datacarriersize configuration option was "undeprecated" two weeks prior to the release of Bitcoin Core v30, according to achow101 response  in this pull request.

To be clear the setting was *always* available at every instant. The thing that happened two weeks pre-release is that the note that it might be removed in the future was removed.  If it does get removed or not will depend on people using it, so far it was looking like literally no one would use it since all the posts are just telling people to not run core 30 at all.  Congrats on being the first to advocate otherwise!

It was foolish or at least premature to have declared to deprecated so quickly before knowing if people would use the setting-- but I guess the devs were trying to appease many people (including myself) who preferred the whole thing and its associated complexity just be removed entirely.  The nature of the setting is such that I think it probably will eventually be removed, but not if its actually being used.  It just probably won't see use for a long time as people realize that all it does is harm their node and its peers.

(and while I don't agree with your particular advice, I think it's really good you posted it and it's at least better advice than not running 30 at all-- thus the merit!)

The problem is that the NFT guys "want" to eternize themselves on the BTC "OG" chain. In their logic, that increases the value of their garbage.

RGB (or Taro) could be used for BRC-20 style tokens, to trade them on Lightning.

The BRC-20 stuff literally comes from BSV-- a fork of a fork of Bitcoin with 'unlimited' blocksizes and effectively zero fees.  It's a BSV standard, created by Calvin Ayre funded BSV companies.  What I've been told and believe is that they got a ton of money to deploy it on Bitcoin as part of some kind of ludicrous "death spiral attack" where they'd drive up fees and difficulty, then the halving would happen, then they'd withdraw the fees and bitcoin would "die" with no blocks being found and miners being unwilling to mine at a loss, plus (depending on who I'm listening to) also with their imaginary "satoshi" to finally prove his identity by moving coins and pick up all the BSV faithful in the great flippening rapture.  Of course, that didn't work--  and these grifters have found that it's more profitable to get money from a lot of little suckers rather than one big sucker.

In any case, all these things would have a much easier and cheaper time being on litterally any other chain.  The fact that they are on Bitcoin shows that they have reasons even if they are stupid or evil ones.  Which is also why "give them something else" won't work-- or rather it has worked AMAZING well, what we left is just that tiny residual part that won't do something else.

Thanks for the news about datacarriersize, imo a good decision. However, IMO 80 bytes is too low. I'd put it on 256 or 512 -- still too small for any image (which will then continue to use Inscriptions), but large enough for sidechain commitments.

You might as well set your node blocks only if you don't want a mempool that reflects what is getting mined! You'll save a lot of bandwidth for yourself and your peers by doing that.