Question for the core supporters.

[PepeLapiu2]

Okay guys. My phone crapped out so I had to create a new temporary profile.
Given that it's cheaper for jpeg degens to use fake pubkeys and put their stoopit jpeg in Segwit, pretty much everyone agrees they are not likely to use op_return to for their crap.

So what legit user do you think is going to use op_return blown up to 100,000 bytes?

My take is that the only ones who will use that are people willing to put disgusting stuff on the blockchain. I'm talking about malware, child p**n, and snuff stuff.

What other use case can you see for it?

[nutildah]

I don't really understand your argument... You're saying that the particularly bad stuff will be reserved for the OP_RETURN limit increase? That doesn't really make a whole lot of sense.

What other use case can you see for it?

This is a good question. AFAIK, my favorite Bitcoin protocol that uses OP_RETURN (Counterparty) has no plans to integrate the limit raise. But if they did, it could allow for more complex transactions, and for things to be done in 1 step instead of 3.

For example, I could do dividend payments ("airdrops") to holders of multiple tokens instead of just a single token. I could create a token, lock its supply and send certain amounts to certain addresses all within a single transaction.

There will be new protocols coming out based on this limit increase, but I won't be using them. Hopefully they will do something more clever than store jpegs.    We can only hope.

[PepeLapiu2]

I don't really understand your argument... You're saying that the particularly bad stuff will be reserved for the OP_RETURN limit increase? That doesn't really make a whole lot of sense.

No, what I'm saying is that core devs claim blowing the op_return limit from 80 bytes to a staggering 100,000 bytes is supposedly done as "harm reduction" and ask the jpeg degens to post their crap in op_return instead of fake pubkey.
But it's absurd because doing so would be 4x more expensive. I think some of them might do it for a little while to look good, than revert to fake pubkeys as soon as possible.

I think the most likely use case is for child p**n and other filth. Because even Mara I
Is not likely to willingly offer a paid service to fill their blocks with repulsive stuff.

I think it's going to result in child p**n, snuff videos, dick pics, and malware populating the blockchain. You only need to look at what happened to BSV when they did the same thing, blowing up the filters.

There will be new protocols coming out based on this limit increase, but I won't be using them. Hopefully they will do something more clever than store jpegs.    We can only hope.

Given that Bitcoin constitutes a huge threat to the PTB, hope won't carry us very far. Rest assured if/when it happens, core devs better run fast when they see me coming.

[ertil]

So what legit user do you think is going to use op_return blown up to 100,000 bytes?

Nothing, because it is not about increasing what "legit user" could do. Any "legit user" would tweak R-value in a signature, and by consuming zero additional on-chain bytes, "legit user" would commit to any data in a better way, than OpenTimestamps do today.

What other use case can you see for it?

1. Segwit commitment in the coinbase transaction. It is mandatory, unless you want to entirely disable Segwit.
2. Pushing small data (something up to 150 bytes or around it, is cheaper than pushing it into witness space, because only then Segwit discount starts making it cheaper in practice).

If you think, that OP_RETURN should be limited to 520 bytes on consensus level, then support this change: https://groups.google.com/g/bitcoindev/c/YO8ZwnG_ISs

[ABCbits]

Given that it's cheaper for jpeg degens to use fake pubkeys and put their stoopit jpeg in Segwit, pretty much everyone agrees they are not likely to use op_return to for their crap.

Depending on size of the arbitary data, OP_RETURN may be cheaper than using witness data. Fake pubkey always more expensive than OP_RETURN.

My take is that the only ones who will use that are people willing to put disgusting stuff on the blockchain. I'm talking about malware, child p**n, and snuff stuff.

You are another person who worry it will happen, when actually it already happen.

--snip--
It's just an example that i remember right away, there are all kinds of data stored on Bitcoin even since a decade ago[1]. Should i mention that research from few years ago discover some kind of content including hundreds link to child porn[2]? Should i also mention shortly after Ordinal launch, someone use it to add porn/explicit image[3]?

If you run non-pruned Bitcoin full node, your device already store such data.

[1] https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html#ref14
[2] https://fc18.ifca.ai/preproceedings/6.pdf, section 4.3 Investigating Blockchain Files.
[3] https://crypto.news/bitcoin-ordinals-encounters-explicit-images-days-after-launch/

[PepeLapiu2]

1. Segwit commitment in the coinbase transaction. It is mandatory, unless you want to entirely disable Segwit.

I can't tell if you write this out of bad faith or if you actually believe it. The coinbase transaction is only a very very minor part of a block
. And Segwit has worked flawlessly all this time without needing to blow up the op_return to 100,000 bytes.

2. Pushing small data (something up to 150 bytes or around it, is cheaper than pushing it into witness space, because only then Segwit discount starts making it cheaper in practice).

This is absurd. I ask why anyone would need 100,000 op_return data and you talk about a 150 bytes chunk. I don't think you are acting in good faith at this point.

If you think, that OP_RETURN should be limited to 520 bytes on consensus level, then support this change: https://groups.google.com/g/bitcoindev/c/YO8ZwnG_ISs

We are not forking to preserve Bitcoin as money. If you want to turn Bitcoin into a cloud file sharing network you better be prepared to fight us hard, or fork off your own shitcoin filled with spam and filth.

[d5000]

I ask why anyone would need 100,000 op_return data and you talk about a 150 bytes chunk.

The reason is to remove the limit entirely, which simplifies the code. All sizes would be arbitrary. I personally favour something like 512 or 1024 bytes if the limit is still in place, to prevent NFT spammers capitalize from the OP_RETURN drama with a new NFT wave, but the elimination is technically the cleanest way to achieve the goal to incentive switching to OP_RETURN from fake public key and Taproot envelope methods.

The taproot envelope method has a standardness limit of around 400 kB, by the way. Is this better?

And let's not forget that this are standardness values, not consensus limits. This means that miners can, and many will, mine transactions with the values the NFT spammers want, as long as they pay a little bit more fees than normal. Remember that 3,9 MB image in early 2023? It was non-standard but a miner chose to mine a whole block with only one transaction.

Your confusion may derive from the fact that OP_RETURN is the cheapest form of data storage for the node operators, not for those creating transactions. Every single NFT spammer (who would spam anyway) chosing OP_RETURN over the other methods reduces the load on node operators and their cost.

[PepeLapiu2]

You are another person who worry it will happen, when actually it already happen.

There is a really big difference between previous instances and what is being planned.
We were never building to accomodate spammers. They were posting their crap in spite of us. We recognized right away that it was an attack and a problem. We never actually expanded anything to open the door for spammers.

Back in 2017-2018 we recognized that Bitcoin had a scaling problem, which lead to the block war. It was big blockers versus Segwit. Obviously Segwit won. But at the very least we all understood there was a need for more space to scale. Today, core is acting as if scaling is not a problem at all, and they can open the door wide open to "new use cases" aka spam.

And that a few instances happened in the past is irrelevant. It doesn't mean it was a good thing. It doesn't mean we should facilitate more of it.

[PepeLapiu2]

Your confusion may derive from the fact that OP_RETURN is the cheapest form of data storage for the node operators, not for those creating transactions. Every single NFT spammer (who would spam anyway) chosing OP_RETURN over the other methods reduces the load on node operators and their cost.

Nope, you are the confused one.
Op_return is 4x more expensive to the spammers, so they are likely to use op_return only for a little while to play nice guy, only to eventually drop the more expensive op_return all together. There is no incentive to the spammers to use op_return.

[d5000]

Op_return is 4x more expensive to the spammers, so they are likely to use op_return only for a little while to play nice guy, only to eventually drop the more expensive op_return all together. There is no incentive to the spammers to use op_return.

The 4x discount is only relevant for Taproot envelopes. Taproot envelopes actually could be blocked by some kind of filter by consensus. But guess what: Nobody of the anti-OP_RETURN camp has proposed a BIP for that. AFAIK the problem is that there may be several methods to circunvent that filter and it would cost a lot of development work to create a filter that blocks all possible variants.

However the Taproot method has also disadvantages. You need an output of another transaction (and most people create an entire transaction just for that) to accomodate the hash of the script which includes the data. BRC-20 is a completely stupid protocol because you have an overhead of dozens of bytes just to create that additional output, for a transaction which itself does only carry a small JSON snipped (which itself is stupid, because JSON includes a lot of extra characters, compared to protobuf) and thus BRC-20 despite of the witness discount was actually more expensive than e.g. a Counterparty or Omni transaction. Despite of that disadvantage, BRC-20 was actually the main reason for the high fees in 2023 because so many people used it. Not the JPEGs or videos embedded in Ordinals-style taproot envelopes.

This proves that people don't really care about the fees if they smell a profit. And thus it is impossible to predict which protocol they will use, OP_RETURN based, Taproot envelope based, or fake public key based. But the limit removal of OP_RETURN makes it at least more likely that OP_RETURN based protocols could have a higher share in the future, to the detriment of the more harmful protocols (from the node operators' point of view, due to the UTXO set problem). The market size will be however the same (despite of an initial spam wave fueled by the drama is possible).

And if you're right and nobody uses OP_RETURN - well, what's the problem then?

The "illegal material" argument doesn't make sense because everybody can add that now in a Taproot envelope too, or stuff it into fake public keys, or pay a miner to mine a non-standard transaction (if the miner rejects it because he finds out what it contains, they could just encode it ...).

[PepeLapiu]

And let's not forget that this are standardness values, not consensus limits. This means that miners can, and many will, mine transactions with the values the NFT spammers want, as long as they pay a little bit more fees than normal. Remember that 3,9 MB image in early 2023? It was non-standard but a miner chose to mine a whole block with only one transaction.

This is a big problem. When miners are acting in an hostile manner and going against the will of the noddes, it's time to realize the miners are not acting in good faith with adverse incentives.

We have to start fighting them, not cater to them by blowing up op_return and giving them more ways to spam the chain

proves that people don't really care about the fees if they smell a profit. And thus it is impossible to predict which protocol they will use, OP_RETURN based, Taproot envelope based, or fake public key based.

I think we should recognize those are hostile users and treat them as such. Come up with stronger filters and more ways to disincintivize them, not provide them with more ways to spam.

And if you're right and nobody uses OP_RETURN - well, what's the problem then?

I think it's obvious there are no legit use case for 100,000 byte op_return. Unless you want to pollute the chain with filth and illicit stuff as a part of an attack on bitcoin. And an extra reason to go all in against node runners either in the court of law or in the court of public opinion, or both.

The "illegal material" argument doesn't make sense because everybody can add that now in a Taproot envelope too, or stuff it into fake public keys, or pay a miner to mine a non-standard transaction (if the miner rejects it because he finds out what it contains, they could just encode it ...).

Taproot was not created with spam and filth in mind. It was designed with the hope of scaling up bitcoin's   monetary use case. That they are using it for spam tells you they are hostile users hijacking what was not meant for them.

But this time, it's different. They are not hijacking an upgrade to spam us against our will. We are unrolling the red carpet and catering to them by implementing changes to invite them to stay. This is a drastic change in policy. We should worry a great deal about intensions actions of core.


One of the many things that bother me about core is that they keep saying the filters don't work. Okay, let's pretend for a minute that they are correct about that.

Than they go on to claim trying to strenten the filters and try to fight the spam is going to result in censorship of legitimate transactions.

They can only look at it at the two extremes. Either filters don't work all and we might as well cater to spammers and create new use cases especially for them. Or filters work so well that they somehow censor spam and legit transactions.

They can't possibly envision a case where the filters can work well enough to fight spam garbage arbitrary data. It's either filters don't work or they work too well.

If core shitcoiners are not up to the task, we will find someone else who can. Mike drop.


The following needs to be addressed again:

If you think, that OP_RETURN should be limited to 520 bytes on consensus level, then support this change: https://groups.google.com/g/bitcoindev/c/YO8ZwnG_ISs

Core and spammers are trying to blow up the op_return from 80 bytes all the way to 100,000 bytes. A 1250x increase. I'm not bargaining and compromising with this nonsense. If they push too far (and they are) we will push the other way and filter down to 40 bytes or even 0 bytes. If they don't like it they can meet us in the middle at 80 bytes. We don't negotiate or compromise with shitcoiners anymore.

We tried to compromise with them by giving them 80 bytes op_return and now they want to blow it up to 100,000 bytes.

If core shitcoiners want to fundamentally change the approach to spam and arbitrary garbage, they can fork, or go work for b-cash. Bitcoin doesn't need shitcoinery.

[nutildah]

Bro, you just posted in your own thread 4 times in a row. Just FYI, this is against forum rules. If you have something new to say and nobody has posted since your last post, just edit your last post to reflect your new thoughts. Otherwise you run the risk of having your posts deleted by moderators. The reason this rule exists is so its not so easy to manipulate the visibility of threads. Not saying that's what your goal is necessarily but it is a rule that is pretty strictly enforced.

[d5000]

Come up with stronger filters and more ways to disincintivize them, not provide them with more ways to spam.

Okay, then let's make a thought experiment what would happen if we come up with perfect filters (which are probably impossible) for the Taproot envelopes.

Let's say we have a Bitcoin market of 500-1000 NFTs per block.

We close Taproot envelopes completely via a consensus filter, but do not open the "OP_RETURN" door.

Well, then instead of 100 Stampchain NFTs we would have 500-1000 Stampchain and other "fake public key" NFTs per block. Do you know what this would mean for the UTXO set? It would be catastrophic for node operators, (although perhaps it would drive them into Utreexo clients, which would not be that bad, but cause stress to the development process).

The fake public key method can't be blocked. I normally do not use bold letters, allcaps or other stuff to emphasize, but that sentence cannot be emphasized enough and is part of the core problem. It is the reason why OP_RETURN was introduced in 2014, and it has been successful in prevent the more harmful methods.

I would support a consensus-based filter for the Taproot envelopes if they don't cripple other use cases, but then OP_RETURN must be opened, to prevent the "fake public key spam wave" scenario.

And we haven't even entered the compact block problem which also currently increases the cost of node operators, and which would improve if OP_RETURN standardness limits are increased.

BTW: It's time to come up with an IQ test based on the position you take on the OP_RETURN problem

[franky1]

bitcoin never has been permissionless.. bitcoin is built on rules.. its the rules that no one can break that made bitcoin so novel, and excellent in a world where banks break rules all the time

bitcoin always had rules. rules about:
block reward had to be the agreed reward amount.  (the networks permissioned reward amount)  
rules about not being able to spend a utxo without the signature(permission)
rules about the format of a transaction eg utxo, recipient, amount, signature (permitted format)
[and so on]

transactions would fail if they did not meet the rules
however new stupid "standards" allow crap to be put into the blockchain without permitted format/limitation. by using opcodes that allow anything to go in unvalidated. (isvalid, assume valid, bypass tricks)
this then allows more crap to enter the blockchain by pretending there should be no real byte by byte validation/permissions required for certain data

we need to get back to the mentality that transaction data should be lean and every byte should count towards the purest of function of moving people funds.
rules should be strengthened to keep the leanness of transactions and allow more users to transact per block.

by the current system charging more fee for sigops, but less fee for opcode abused crap data. its becoming a system whereby using bitcoin for proving a payment transfer would cost more than crap data which has no intent to permit movement of funds

un-validated/unchecked/'is valid bypass' crap data using special opcodes should be treated as fully counted bytes and also include a exponential multiplier of cost to dis-incentivise its utility to introduce bloated crap data

[PepeLapiu]

then let's make a thought experiment

Okay. Let's do that. Say we have a spam problem and instead of trying to fight them, we create more ways for spammers to post their shit, what do you think will happen? Think fast!

Let's say that we don't do anything about the way they already spam us and we blow up the op_return to offer them note ways to spam....what's going to happen?

The fake public key method can't be blocked.

That is false. Knots can 100% filter out fake pubkeys. But don't expect core devs to tell you it's doable because they are too busy telling you bitcoin "is just a database" and talking down to nodes.

It is the reason why OP_RETURN was introduced in 2014, and it has been successful in prevent the more harmful methods.

They obviously didn't receive the memo because they are now back at using fake pubkeys.

I would support a consensus-based filter for the Taproot envelopes if they don't cripple other use cases, but then OP_RETURN must be opened, to prevent the "fake public key spam wave" scenario.

If we don't do anything about fake pubkeys (or if we tell ourselves we can't do anything about it) and we create more ways for them to spam the network, it's foolish to believe they are going to stop using the cheaper fake pubkeys and only use blown open op_return.
In all likely scenario, they will use op_return for a little while to eventually spam even more everywhere as we just litterally created more ways to get spam.

BTW: It's time to come up with an IQ test based on the position you take on the OP_RETURN problem

Great idea! Question one in the test:
What happens when you do nothing about current ways to spam and you create more ways to spam??


It's so transparent that I think you have to be either evil or dumb to support core at this point.

They are telling us they can't do anything about the current spam. And so they ate going to create more ways to spam while doing nothing about the existing problem.

If you give them more ways to spam, you will get more spam. But since most of you don't even think non-monetary transactions and stoopit jpegs are acceptable and do not constitute spam, than you can keep thinking there is no problem.