Removing OP_return limits seems like a huge mistake

[philipma1957]

Look As I person that still mines high fee blocks are very desirable to me.

But as a person running a full unpruned node I do not want to be charged with distributing

illegal data.

It seems to me that as much as I read this I need to not run the node as I can not be assured that the node does not carry criminal data and there is no plan in action to stop that issue if it explodes in our faces in a few epochs or is that 1/2ings.

So if un limited op_return will raise block fees and keeping current limits keeps fees lower I have to go with larger or unlimited op_return.

It looks like I can not run a node anymore for my own legal safety.


Am I looking at this wrong?

Yes I am miner biased. but I do not see BTC as a p2p money system as hodl turned it into a store of wealth.


Wish I was in the hodl camp years ago oh well

[gmaxwell]

I firmly believe that simpler is better. I Removing OP_return limits is definitely a huge mistake.

Simpler is better ... so removing complexity from the bitcoin codebase is a huge mistake?  ?

by not living up to promises made in the New York agreement [...] and fulfill their 2017 obligation that was made

(added hyperlink)

Hi Og, I made an agreement with another forum poster that you would give me all your assets.  Of course, your participation was expressly and explicitly excluded from our negotiation, but none the less you have obligations and aren't living up to them right now. Pay up!  I'll let you keep a cardboard box to sleep in, and if you're nice a swamp cooler. I'm sure you wouldn't want to fail to live up to your obligations.  

But as a person running a full unpruned node I do not want to be charged with distributing
illegal data.

That risk sucks but it exists today and isn't changed by alterations to opreturn filtering on nodes.

You can mitigate the risk by setting "prune=1" in your bitcoin.conf.  This won't actually prune any blocks, but will behave to the outside world as if you have-- so it won't serve any historic blocks more than about two days old.  You can also make sure your block files are new enough that they're encrypted so that scanning tools won't flag anything in them.

It's important to keep some perspective:  No one has ever gotten in trouble with this and it's only one of many fringe theoretical risks.  Life just has risks--  someone could relay a north korean transaction through your node and authorities could potentially try blaming you for it or just come to seize your node to try to get logs to determine the transaction's origin.  Also very not likely.  You could be sued for patent infringement by Craig Wright's co-scammer business partners as they've repeatedly claimed Bitcoin violates their patents the fact that they're full of shit doesn't mean that they couldn't cause you bankrupting levels of legal expenses.

But if you don't run your own node maybe you're the last straw that otherwise would have helped hold back a bad consensus change.

Basically if you're going to commit yourself to worrying then there is no end to it.   The best you can do is be aware of more significant risks, mitigate what you can affordably mitigate and deal with problems as they arise.  Only the dead are invulnerable to risk.

I can not be assured that the node does not carry criminal data and there is no plan in action to stop that issue

It's not that there is no plan, it's that it's a fundamental issue that appears to be largely unsolvable.  It also isn't unique to bitcoin-- anyone who publishes anything could accidentally transmit illegal data that someone snuck in, even if they were engaging in editorial oversight.

Beyond the block file and utxo set encryption bitcoind/bitcoin-qt doesn't provide any facilities to decode/display these embedded things, quite intentionally, to avoid any argument that the node operator meaningfully had access.  Also the P2P protocol got encryption a while back, though I worry that drama adverse behavior is delaying developers doing the right thing and offering an option to only use encrypted connections.  I have a patch available that I made for a friend if you want one, it's required no revisions to apply cleanly for more than a year now.

There are also ideas like assumeutxo which will allow people to bring up a full node without validating (thus downloading) the far past that would help.  Though of course this comes with a security tradeoff in that you only have 'assumevalid' like security of the part you didn't validate... but it's another way Bitcoin has worked on mitigating risk from illegal content.

I'm also a bit in conflict with this part of the PR, even if I (as I wrote above) also understand the arguments in favour of removing that possibility mentioned by @gmaxwell.
I also want to point out that if the datacarriersize parameter is removed, then the incentive to use alternative implementations like Knots could increase. This would create additional complexity: Now both versions are in conflict regarding a relatively minor issue like standardness. But in the future it's possible that alternative implementations, encouraged by increased use, could move towards protocol changes, like the reduction of block size to something like 150 kB proposed by the Knots main developer.

There are two PRs, one which leaves a setting but unlimits it by default.  Of course, most people 'following' the debate don't even know that...

It's less advanced in development in part because its a somewhat harder change.  I'm not really that opinionated on leaving a useless option in, though because of the character of the response I do lean towards removing it: Removing it is simpler, results in less complexity.  Perhaps less good reasons, conceding to an attack driven by misinformation or collateral concerns creates ongoing risk.  For people who intentionally have exaggerated the issue a concession just amplifies their social clout.  Some people running some other version isn't inherently bad, and if they're doing it because they've been bamboozled then the solution is education. If they're doing it because they're so angry at other uses that they'd harm bitcoin in order to harm the other uses, I'd rather they go off and do their own thing and not distort future development priorities with future unreasonable demands.

Also running another version is overkill for this, this is exactly the kind of small change that it ought to be easy to carry a local patch for.  The ecosystem would be better off if more people felt comfortable doing that.  True, I believe this is a silly and unhelpful thing to carry a local patch for.. but if it causes people to learn how and not be afraid of it, then that sounds like a winning outcome to me.

It's extremely easy to drum up or even outright fake public outrage... more sybil vulnerable than even P2P.  If developers are going to be diverted from what they think is best via that kind of attack, then that is a really serious and concerning vulnerability.  That doesn't mean they shouldn't listen-- they should, but all that should matter is good arguments that go directly to the issue in question, and not unfocused outrage or abusing the subject as a proxy issue.

[xmrhopium]

That should be the point of Bitcoin Core, remain the Core, stick to the basics, and do not add any complexity in the name of innovation.

By that metric, that's what the PR does. It removes more complex code than it adds.


I don't understand why everyone is flaming us for someone who doesn't frequently contribute to Core opening a PR advocating for a change they'd like to see. Just because there is a PR doesn't mean that it's a good idea or that will be merged.

Well even if you don't use core you are still going to suffer the impact of whatever Core does. Say im running Knots now as my full node, im still going to complain about things Core does that I think are not good for BTC, because Core is a main part of the network as it stands, so even if I run Knots, if Core screws up along the way, the price is the same for everyone involved in running nodes irrespective of what software you are running.

What now we have isn’t great, core by necessity gatekeeps much of ‘what is Bitcoin’ so anything vaguely controversial turns into a flame war because we have to decide on one solution/approach, effectively. Knots and btcd help a bit, but not much. Especially as Knots is highly opinionated itself (fine if there are dozens of node implementations, not really fine if it’s kinda the only other one).

It’s a pretty big satoshi blunder that Bitcoin was a piece of software not a protocol spec, so working out of the current state of things is very difficult.

[tvbcof]

Seems to me that people who wish to leverage the Bitcoin blockchain for various pet data projects would/could/should just peg out to a dedicated sidechain.  Unlike in earlier days (back before the earth stopped cooling) such technologies have been developed, and are working pretty well as best I can see.

Seems to me that a dedicated  sidechain would be a better choice than the Bitcoin blockchain since it wouldn't be being spammed by BTC transactions and there is a lot of unrelated cruft which could be left behind.

At first blush, somehow 'needing' to crud up the BTC blockchain seems more like an attack than a legitimate solution to a real problem.  Where is my thinking wrong here?

[ABCbits]

But as a person running a full unpruned node I do not want to be charged with distributing

illegal data.

Such illegal data already embedded into Bitcoin blockchain far before Ordinals exist. We better hope government keep being sensible, since you can't access such data without additional software which enable parsing, listing and searching such data.

Seems to me that people who wish to leverage the Bitcoin blockchain for various pet data projects would/could/should just peg out to a dedicated sidechain.  Unlike in earlier days (back before the earth stopped cooling) such technologies have been developed, and are working pretty well as best I can see.

Seems to me that a dedicated  sidechain would be a better choice than the Bitcoin blockchain since it wouldn't be being spammed by BTC transactions and there is a lot of unrelated cruft which could be left behind.

At first blush, somehow 'needing' to crud up the BTC blockchain seems more like an attack than a legitimate solution to a real problem.  Where is my thinking wrong here?

Sidechain and other L2 already exist far before Ordinals created. But almost no one use it despite both Liquid network and Rootstock have smart contract capability and developer behind it promote it support NFT/token. I also have seen Ordinals supporters say they only want to use Ordinals since their arbitrary data guaranteed to be immutable.

[pooya87]

As I've already written before, "fixing what's being exploited", is simply not possible. If you filter / block use cases like Ordinals you would direct the same spam into potentially more harmful mechanics.

Sadly I somewhat agree with this, which is what I've warned about before; and it's only because the core devs didn't act when they should have acted!
If they had fixed the exploit in a patch shortly after the Ordinals Attack was introduced, it would not have grown so much to "fester" and establish a market. After all before this attack began we weren't seeing people spamming or using "other more harmful mechanics" to inject arbitrary data into the chain at large scale. So preventing it would have never led to it either.

But I still don't see how encouraging people to inject arbitrary data of any size and without limit into bitcoin blockchain which would be treating it like cloud storage is a good idea. It sounds like a disaster not a solution.

As gmaxwell already wrote those who exploit Taproot via Ordinals usually do that with a profit expectation.
demand from this market could be directed significantly more into the OP_RETURN "channel" instead of the Taproot and "fake address" channels.

They are indeed driven by profit, and to make profit from the garbage they create they'd look to minimize their costs. Even more so during the mempool congestion times where fee rates shoot up significantly. Using the exploit to inject their large date into witness is significantly cheaper compared to using OP_RETURN. I doubt they can be directed to using it instead.

And like I always say bitcoin is not a cloud storage, so we should make it harder for them to use it as such not easier (ie. removing OP_RETURN limit).

[tvbcof]

...

Seems to me that people who wish to leverage the Bitcoin blockchain for various pet data projects would/could/should just peg out to a dedicated sidechain.  Unlike in earlier days (back before the earth stopped cooling) such technologies have been developed, and are working pretty well as best I can see.

Seems to me that a dedicated  sidechain would be a better choice than the Bitcoin blockchain since it wouldn't be being spammed by BTC transactions and there is a lot of unrelated cruft which could be left behind.

At first blush, somehow 'needing' to crud up the BTC blockchain seems more like an attack than a legitimate solution to a real problem.  Where is my thinking wrong here?

Sidechain and other L2 already exist far before Ordinals created. But almost no one use it despite both Liquid network and Rootstock have smart contract capability and developer behind it promote it support NFT/token. I also have seen Ordinals supporters say they only want to use Ordinals since their arbitrary data guaranteed to be immutable.

They couldn't figure out how to make their sidechain(s) 'immutable'?  Yeah, right.

It certainly seems that there is something rotten in Denmark.

It also looks like there is a compelling reason to get back to running some full nodes and building out some mining capacity.  For most of the time over the last 14 years, I did not see a real need to do so.

If these 'core' people can convince me that Bitcoin has been, or will be, taken over by bankster creeps and it's time to take it out back and shoot it in the head (which would not be impossible), that's one thing.  If, however, some contingent of 'core' were flipped by the powers that be and induced to introduce toxins into the codebase (or are doing it for their own gain), that's quite another.

Maybe there is an effort at another BCH-style fork to take some profits off one side?

[gmaxwell]

Sidechain and other L2 already exist far before Ordinals created. But almost no one use it despite both Liquid network and Rootstock have smart contract capability and developer behind it promote it support NFT/token. I also have seen Ordinals supporters say they only want to use Ordinals since their arbitrary data guaranteed to be immutable.

I think I adequately explained why the NFT bullshit doesn't use alternatives (I mean forget sidechains, they could just spin up another blockchain or use bcash or whatever).  If it wasn't clear you can ask questions.

Of course, there is also always the potential for collateral motivations but if you pick through them the most likely sound like ones trying to divide up the Bitcoin community, or trying to prove out points of control or that transaction censorship works. ... but you don't need alternative motivations to explain the shitcoining, it's just that even when one is sufficient others can be true too.


and, yet again,  nft shitcoining stuff is mostly orthogonal to opreturn. If it wanted to use outputs it would just be using fake outputs.

and it's only because the core devs didn't act when they should have acted!

I think that's debatable at best, but if they had it would have been a huge drama fire-- and the failure of the community to manage that drama fire is a huge pressure to NOT do it.  So here again we see a huge drama fire and this one is over a real nothing burger.  You're not sending a message that they *can* act.  If you want to send that message you should help douse dramafires.  

I care about this opreturn issue because:

1. The block propagation problem needs to get fixed and this is one of the (nearly) required steps.  (I say nearly because the alternative is some massive rocket science improvement in block propagation that the project is not healthy enough to undertake, and which still won't do as good a job as fixing relay to relay everything that gets mined).

2. That people are bashing the shit out of bitcoin core over a PR that wasn't even initiated by a regular contributor, that rightfully should have been done a year ago but likely got delayed because of not wanting to deal with drama. ... so people leaving core out to dry is resulting in them not putting out their best effort.  The bitcoin project feeling free to make controversial changes which they believe are correct would have been an absolute prerequisite to them doing something about the NFT-shitcoin spam. (I don't believe they would have for fact specific reasons, but it would have at least required feeling able to do so).

3. The influencers who are outright lying to the public[1] should not gain a win from this and validate their manipulation techniques.


[1] Like saying "core did this" and "core ignored the community" basically the moment a project outsider made a PR.  Like telling people that they're taking away the choice, without mentioning that there is another PR that keeps the option or mentioning that since miners don't enforce the limit, that it is ineffectual at blocking spam (See also: 3183bd6ceebc2d39c0a3cfa0d06eb84d1161eaac1c26605e2eab62bfe48c1420 ).  Like lying to people and saying that core contributors want NFT garbage when the tech people hate that stuff, have expressly said they don't like it.  In reality the change is popularly supported among those in the know because this filter no longer works (see also my see also above) and it causes collateral harm, and the NFT garbage encodes their data a different and unrelated way.   And so on.  All these things are just outright lies and inexcusable omissions and they are poisoning public discussion.  And the people making them are just getting away with it.

  

[jaybny]

...

i get your sound logic.. but these terrible anti-pattern protocols hurt to look at.. simply from a comp sci perspective - making these immutable on chain is a crime against humanity (jk)

https://x.com/mononautical/status/1919758548310823213

https://x.com/mononautical/status/1919758548310823213

[tvbcof]

I think I adequately explained why the NFT bullshit doesn't use alternatives (I mean forget sidechains, they could just spin up another blockchain or use bcash or whatever).  If it wasn't clear you can ask questions.

...

From my perspective (going back a long ways) real sidechains such as liquid ARE 'bitcoin'.  What they peg out is protected by all of the proof of work of Bitcoin proper.  They can also leverage a lot from basic operations within Bitcoin proper without fucking it up so much.  I always viewed sidechains (even before they were developed) as the escape valve for entities who wanted so leverage real Bitcoin (instead of some shitcoin), but enhance it's capabilities.

So, I don't think it exactly appropriate to say 'forget sidechains'.  (Sidechains in my mind are basically a viable shitcoin PLUS some credibility via a BTC peg.)

Now it must be said that I basically ignored Bitcoin developments since the blocksize wars a decade ago and have not been very interested or in-the-loop.  As back then, I feel OK as long as blocksize growth is _predictable_.  As I understand things this OP_RETURN change does _not_ in and of itself increase growth rates (though it looks like a stepping-stone to me).  It mostly just makes it more practical to buy 10 minutes +/- of the Bitcoin world's time in one transaction.  Same thing could be done, I guess, with the existing OP_RETURN or via other more objectionable methods, but it would be a little bit more of a pain-in-the-ass perhaps?

I don't see a technical reason to give the spammers what they want on a silver platter in part because with the sensible rates which have been more-or-less preserved since the infamous 1MB commit, we really don't need ultimate efficiency in mempool or pruning.  (Moore's law is BS, but hardware capabilities are improving.)

As with 10 years ago, I would argue that it is worthwhile to educate people that if shitcoiners attack and transactions are delayed for hours/days, it's doesn't mean that the sky is falling.  The spammers will get tired of spending millions/day in order to choke things up.  Just set on-chain transaction expectations accordingly and use other (much better) sidechain options for day-to-day transactions.

On out-of-band miner buying, seems to me that two could play at that game.  The 'two' could be legitimate/efficient sidechain operators who could only have to cover the difference between the natural block reward and the extra which the spammers are offering in order to keep their business model operative.

[NickofTime]

A bit late to the party. I don't know if removing the filter was a mistake, this only time will tell. A few things on my mind:

Motivation: this was not properly addressed. From this discussion alone it seems that the choice of imposing no limit on OP_RETURN was for the benefit of the network. This is not what happened. This is not why the pull request was made. I refer you to a post by Peter Todd himself on stacker.news

For the record, this pull-req wasn't my idea. I was asked to open it by an active Core dev because entities like Citrea are using unprunable outputs instead of OP_Return, due to the size limits. And yes, that's the thing that has changed since.

https://stacker.news/items/971277?commentId=971434

Was this really for the benefit of the network or for the benefit of Citrea? Why did this anonymous developer go through Todd for the PR? Am I the only one seeing red flags here?

[gmaxwell]

From my perspective (going back a long ways) real sidechains such as liquid ARE 'bitcoin'.

I didn't mean that in the sense of anything negative, I mean you don't need to wonder about anything that complicated. The NFT/shitcoin stuff could just use some other much cheaper chain or whatever.  They don't because reasons that I discussed upthread-- sidechains wouldn't help those reasons, they'd hurt. The value to the shitcoiner is that it's expensive to make their tokens.

Motivation: this was not properly addressed. From this discussion alone it seems that the choice of imposing no limit on OP_RETURN was for the benefit of the network. This is not what happened. This is not why the pull request was made. I refer you to a post by Peter Todd himself on stacker.news

For the record, this pull-req wasn't my idea. I was asked to open it by an active Core dev because entities like Citrea are using unprunable outputs instead of OP_Return, due to the size limits. And yes, that's the thing that has changed since.

https://stacker.news/items/971277?commentId=971434

Was this really for the benefit of the network or for the benefit of Citrea? Why did this anonymous developer go through Todd for the PR? Am I the only one seeing red flags here?

I'm glad you asked that-- I hadn't seen any of that discussion and I totally get why you find it concerning.

You're missing context:  Petertodd's pull request points to this mailing list post: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/mJyek28lDAAJ  So no anonymity.  And why Petertodd?  Because it's simply a reintroduction of a pull request he made previously:  https://github.com/bitcoin/bitcoin/pull/28130   Petertodd just copy and pasted his older change-- kind of the obvious thing to do when someone has submitted a change before that you think should be made now is to ask them to resubmit it.

(also jesus man, can Petertodd not manage to say anything without somehow causing drama? )

As far as citrea: they already make "fake address" outputs.  I don't see how the change *benefits* them, it would however make their traffic less harmful to Bitcoin which seemingly they'd prefer.  Though apparently these transactions only happen when their channels fail or something it's an exceptional and not frequent case for them so not terribly important.

And if I could be so bold to make a totally wild ass guess, I'd guess that Antoine Poinsot looked into citrea saw it producing fake outputs, asked them to stop and got pointed to the op_return limit... but I dunno the history there.  I do know that in the past I've done similar things may times:  found some user doing something apparently dumb, asked them to change for the benefit of the network, learned of the reason for their behavior, then went to go get it fixed.

And you can see from the fact that it's been proposed before that citrea is not the driver of this.  Maybe from Petertodd's perspective it's what triggered someone to ask him to try again.  But the reason that people support it (including petertodd) isn't limited to or even related to that triggering event.

And FWIW.  I learned about this whole thing via drama on reddit where people were posting saying Coredevs wanted to turn bitcoin into NFTs/Shitcoins, which is pretty ridiculous.  I'd personally never heard of citria and commented in support of this change before even learning what it was... because it's pretty obviously the right thing to do, and I think that's probably true for many other people.  I don't know enough about it to give an opinion on it. I understand it's supposed to be a payment channel thing, which is good, but a lot of the recent ones of those have a shitcoin.  I haven't checked if it does, 'cause a good change is a good change even if a piece of shit likes it.  (and you *have* to adopt that perspective, or otherwise enemies can harm you by liking things that are good for you )

So from my perspective this is a change that is massively overdue.  And the thing that has changed over time that matters is that now large miners are reliably accepting unlimited opreturn via direct submission, have been doing it for a long time, and are clearly not going to stop.  That differences changes the filter from net-neutral or somewhat net positive to net-harmful.
 

[d5000]

There are two PRs, one which leaves a setting but unlimits it by default.

Thanks for the info. Imo that makes sense ...

I'm not really that opinionated on leaving a useless option in, though because of the character of the response I do lean towards removing it: Removing it is simpler, results in less complexity.

I wonder if there are stats about the usage of the datacarriersize parameter. It should be possible to estimate it at least. If it is popular then in my opinion it isn't useless. I think even if it is technically useless because miners would normally mine these transactions anyway, people could simply "feel better" if they can keep out some things from their mempools (even if their nodes would broadcast happily PEPEs and other JPEGs created with Stampchain). It's however debatable if these nodes should be called "full" nodes.

Perhaps less good reasons, conceding to an attack driven by misinformation or collateral concerns creates ongoing risk.

I think I understand your reasoning here, but I think perhaps a concession can also be helpful sometimes to calm the waters. I'll try to read a bit about how the block propagation problem and the OP_RETURN limits are connected, as this is still a "hole" for my understanding of the whole context.

Sadly I somewhat agree with this, which is what I've warned about before; and it's only because the core devs didn't act when they should have acted!

No, that's not what I meant.
A "patch" like the one Luke-jr proposed is just the kind of code I don't want to see in Bitcoin Core, ever. It is a hardcoded "filter" which would only target a specific format of Ordinals inscriptions, and they could come up all the time with new versions which also would have to be patched, this is what @gmaxwell probably refers to as a "whack-a-mole" game.

I guess if the Ordinals wave would have begun, and Core "patched" it let's say in March or April 2023, then the Ordinals folks would have massively switched to Stampchain (which was already around in early to mid 2023) for NFTs and existing protocols like Counterparty (not a harmful method, but could have created a similar spam wave) for tokens -- take into account that the big majority of the "spam wave" was due to BRC-20 tokens which doen't need the "extended Taproot witness size" to work. Stampchain later even created a token protocol (SRC-20), and we can really happy that that one never really took off, it would have caused even more stress to the UTXO set.

But I still don't see how encouraging people to inject arbitrary data of any size and without limit into bitcoin blockchain which would be treating it like cloud storage is a good idea.

First, OP_RETURN data must also respect the general size limit for transactions even if the standard setting is set to "unlimited". As the maximum limit is 400k WU, this puts OP_RETURN (where afaik 4 WU are "consumed" by each byte) still not on better terms than the Taproot witness method (where up to 400 kB are considered "standard").

And second, why should the least harmful method to store data be the most limited one? As you can see it would still be more limited than the Taproot method, but at least it would be on similar terms with Stampchain which nowadays is at advantage regarding OP_RETURN.

And like I always say bitcoin is not a cloud storage, so we should make it harder for them to use it as such not easier (ie. removing OP_RETURN limit).

What exactly becomes easier if the OP_RETURN limit is lifted? There are lots of tools to use the Taproot exploit now, and also lots of tools to use Stampchain. It's not hard at all to use these methods. Nothing of this becomes easier if the OP_RETURN limit is lifted.

Again, it's only to put the least harmful method, OP_RETURN, on similar terms to the more harmful methods like Stampchain.

[NickofTime]

From my perspective (going back a long ways) real sidechains such as liquid ARE 'bitcoin'.

I didn't mean that in the sense of anything negative, I mean you don't need to wonder about anything that complicated. The NFT/shitcoin stuff could just use some other much cheaper chain or whatever.  They don't because reasons that I discussed upthread-- sidechains wouldn't help those reasons, they'd hurt. The value to the shitcoiner is that it's expensive to make their tokens.

Motivation: this was not properly addressed. From this discussion alone it seems that the choice of imposing no limit on OP_RETURN was for the benefit of the network. This is not what happened. This is not why the pull request was made. I refer you to a post by Peter Todd himself on stacker.news

For the record, this pull-req wasn't my idea. I was asked to open it by an active Core dev because entities like Citrea are using unprunable outputs instead of OP_Return, due to the size limits. And yes, that's the thing that has changed since.

https://stacker.news/items/971277?commentId=971434

Was this really for the benefit of the network or for the benefit of Citrea? Why did this anonymous developer go through Todd for the PR? Am I the only one seeing red flags here?

I'm glad you asked that-- I hadn't seen any of that discussion and I totally get why you find it concerning.

You're missing context:  Petertodd's pull request points to this mailing list post: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/mJyek28lDAAJ  So no anonymity.  And why Petertodd?  Because it's simply a reintroduction of a pull request he made previously:  https://github.com/bitcoin/bitcoin/pull/28130   Petertodd just copy and pasted his older change-- kind of the obvious thing to do when someone has submitted a change before that you think should be made now is to ask them to resubmit it.

(also jesus man, can Petertodd not manage to say anything without somehow causing drama? )

As far as citrea: they already make "fake address" outputs.  I don't see how the change *benefits* them, it would however make their traffic less harmful to Bitcoin which seemingly they'd prefer.  Though apparently these transactions only happen when their channels fail or something it's an exceptional and not frequent case for them so not terribly important.

And you can see from the fact that it's been proposed before that citrea is not the driver of this.  Maybe from Petertodd's perspective it's what triggered someone to ask him to try again.  But the reason that people support it (including petertodd) isn't limited to or even related to that triggering event.

And FWIW.  I learned about this whole thing via drama on reddit where people were posting saying Coredevs wanted to turn bitcoin into NFTs/Shitcoins, which is pretty ridiculous.  I'd personally never heard of citria and commented in support of this change before even learning what it was... because it's pretty obviously the right thing to do, and I think that's probably true for many other people.  I don't know enough about it to give an opinion on it. I understand it's supposed to be a payment channel thing, which is good, but a lot of the recent ones of those have a shitcoin.  I haven't checked if it does, 'cause a good change is a good change even if a piece of shit likes it.  (and you *have* to adopt that perspective, or otherwise enemies can harm you by liking things that are good for you )

So from my perspective this is a change that is massively overdue.  And the thing that has changed over time that matters is that now large miners are reliably accepting unlimited opreturn via direct submission, have been doing it for a long time, and are clearly not going to stop.  That differences changes the filter from net-neutral or somewhat net positive to net-harmful.
 

Thanks. Your posts are informative as always. I will continue to use Core then and will advise others to do the same.

[lonko]

@gmaxwell, wouldn’t it be more reasonable to just increase the OP_RETURN limit by 5x or 10x rather than making it unlimited? I get the need to unblock legit use cases, but completely removing the cap still feels like opening the door to potential abuse. A higher-but-bounded limit could be a safer compromise that avoids pushing harmful patterns into unprunable outputs.

[gmaxwell]

@gmaxwell, wouldn’t it be more reasonable to just increase the OP_RETURN limit by 5x or 10x rather than making it unlimited? I get the need to unblock legit use cases, but completely removing the cap still feels like opening the door to potential abuse. A higher-but-bounded limit could be a safer compromise that avoids pushing harmful patterns into unprunable outputs.

I don't think it makes sense because miners are already not limiting it at all (well except in so far as transaction sizes are limited) and have refused requests to limit it... much of the reason to remove it comes from a disconnect between default node and miner behavior, so setting some other limit preserves that inconsistency.   I think there is even an extent that the extremely angry filtering faction has poisoned the well, so much so that when miners have unintentionally removed anti-dos filters that no one wants to violate and only expose vulnerabilities it's been a little challenging to get passed being dismissed as a "pro-censorship" crank.

If someone only cared about that citrea thing then sure, then it could be set to whatever it needed-- but as I said I don't think for most people in support the motivation really cares about that particular user.

My opinion on this might be different e.g. if miners were like "oh if the default were 800 bytes we would just not change it" -- but the fact his miners are even letting users bypass transaction size limits of hundreds of KB.

I don't regard this as a bad thing-- bitcoin's premise is that miners are income maximizing, it's part of where the censorship resistance comes from... and it's an expected part of the transition from fees not mattering to fees being important.

I don't expect that they'd allow stuff that was unambiguously causing harm still, but as you're aware there is a lot of dispute over the NFT/shitcoin stuff being legitimate or spam... and to the extent that large miners might make a decision I consider an error, I'm happy that it's in the direction of including instead of excluding!

Opinions might differ from mine, if I haven't convinced you that a 5x or 10x increase wouldn't be better, feel free to attempt to sell people.

[Wind_FURY]

I knew there were people trying to turn Bitcoin into a general purpose Ethereum-style shitcoin thing for years, but I always assumed cool heads would prevail and common sense would reject those things. Well it turns out this one now is picking some traction. They basically want to allow non-Bitcoin things into Bitcoin. I don't see what the benefits of doing this is. It will just bloat the blockchain. The point of Bitcoin is to move money from A to B, everything else is bloat.

Although you're right that dick pics and fart sounds could make it more expensive to run a full node, I probably will disagree that there's absolutely no benefit if the transactions that you don't like happen in Bitcoin will happen in Bitcoin. Because sometimes when I check the mempool, I see this,



 👀

The core benefit is incentives for the miners through fees.

[ABCbits]

Sidechain and other L2 already exist far before Ordinals created. But almost no one use it despite both Liquid network and Rootstock have smart contract capability and developer behind it promote it support NFT/token. I also have seen Ordinals supporters say they only want to use Ordinals since their arbitrary data guaranteed to be immutable.

I think I adequately explained why the NFT bullshit doesn't use alternatives (I mean forget sidechains, they could just spin up another blockchain or use bcash or whatever).  If it wasn't clear you can ask questions.

Of course, there is also always the potential for collateral motivations but if you pick through them the most likely sound like ones trying to divide up the Bitcoin community, or trying to prove out points of control or that transaction censorship works. ... but you don't need alternative motivations to explain the shitcoining, it's just that even when one is sufficient others can be true too.


and, yet again,  nft shitcoining stuff is mostly orthogonal to opreturn. If it wanted to use outputs it would just be using fake outputs.

I've seen your post and it's clear enough. I was just mentioning justification of Ordinals supporter (which IMO is ridiculous) and the fact Sidechain/L2 isn't popular option for NFT/token (and in general).

I guess if the Ordinals wave would have begun, and Core "patched" it let's say in March or April 2023, then the Ordinals folks would have massively switched to Stampchain (which was already around in early to mid 2023) for NFTs and existing protocols like Counterparty (not a harmful method, but could have created a similar spam wave) for tokens -- take into account that the big majority of the "spam wave" was due to BRC-20 tokens which doen't need the "extended Taproot witness size" to work. Stampchain later even created a token protocol (SRC-20), and we can really happy that that one never really took off, it would have caused even more stress to the UTXO set.

I was about to say OmniLayer also exist, but it's class A&B TX are considered more harmful and almost no one use it back in 2023.

[Ambatman]

Edited

Okay let me see if I understand what you have stated so far

1. The focus on OP RETURN, rather than Taproot, stems from its role as a prunable and miner-aligned mechanism for embedding data.

2. Using Taproot to close the door is more risky and delicate than working on OP_RETURN

3. Citrea’s need for larger OP RETURN data is one of many use cases driving the debate. A company that wants Bitcoin to test the territory Ethereum is manning.

4. The proposal could benefit miners and indirectly solve the issue of fees not been enough to encourage miners.

5. Placing an higher limit wouldn't change much since it won't stop miners from bypassing the limit and cause inconsistency with nodes 

6. Removing the OP RETURN limit could reduce reliance on less efficient data-embedding methods like Taproot Inscriptions, relying on  its prunable nature.

7. A way but doesn't solve the issue of fake UTXO bloat especially to users that would prefer the functionality and privacy of TapRoot.

8. Removing the OP RETURN Limit Reinforces Bitcoin’s Censorship Resistance by Trusting Miner Incentives.

9. Formalizes embedding data on the blockchain.

 

[OgNasty]

Core developers are taking payments to submit pull requests. That is the state of development for Bitcoin at the moment. I have a feeling as time goes by we’re going to discover more and more bad behavior. People are tired of the way things have been going. There’s too much money behind Bitcoin for developers to be so easily paid for.