Re: Remove arbitrary limits on OP_Return (datacarrier) outputs #32359

[pinheadmz]

Moderation actions regarding bitcoin/bitcoin#32359 will be discussed here.

If your comment was removed and/or you were banned temporarily because of a comment on this PR READ THIS:

This PR is the result of a very long discussion. Please do not add any comments to the pull request until you have read every word of the previous discussion: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ

As well as all previous comments left by other reviewers on the PR.

[pinheadmz]

@Turtlecute33

bitcoin/bitcoin#32359 (comment)

Hey, I’d like to ask why my comment above (bitcoin/bitcoin#32359 (review)) was marked as a duplicate. I believe it includes some technical points that weren’t cited earlier, for example, that allowing more OP_RETURN usage doesn’t necessarily mean spammers will stop using witness-discounted Taproot outputs.
(cc @pinheadmz)

Appreciate the comment by @polespinasa who explained that the removed comment did not add any new information to the discussion:

That's in the mailing list, not that direct sentence but cost comparison with witness-discount and multiple op_returns use cases.

[Turtlecute33]

Great point, so why aren't you hiding all the duplicate comments that say ACK, repeating the same concepts?

I've been polite and concise. I discussed many topics only partially covered in a different context on the mailing list while you're keeping ACK messages that are pure duplicates. I deserve the same treatment.

[pinheadmz]

I'll review your comment again and unhide if I can, if it adds value. Moderating that thread is hard because many comments are mixed repetition, new ideas, and personal drama combined. Some comments remain because they add a shred of value despite their inclusion of cruft. My goal as moderator is to help out the maintainers and make the whole page easy and efficient to read. Keep in mind ACK and NACK are not votes. PRs don't get merged just because a hundred GitHub accounts write ACK. What's important is information. If you see comments on that thread that do not add any information let us know and we'll review them as well.

[ryanofsky]

Just an idea, but I think it might be helpful if people participating in this debate could organize together a little and write position statements stating:

1 - what their preferred approach to dealing with spam is
2 - what benefits of the approach are
3 - what possible drawbacks might be, what possible limits might be (for example if you want more spam protection, what forms of it you might not want)
4 - what responses or rebuttals there are to claims made by opponents of the approach

An example where position statements like this were used before was in the debian init system debate before it adopted systemd, https://wiki.debian.org/Debate/initsystem, and there are several example statements linked there.

I think a more organized format like this could make the different points of view clearer, make sure alternatives are considered and represented, and make sure points that were raised are addressed, or make it obvious when they haven't been.

[pinheadmz]

This sounds so nice. How did they actually organize the groups?

[ryanofsky]

I don't know, but debian seems to have an open wiki so I imagine different people just wrote up the position statements there and invited others to help improve them.

In our case, I'd think someone who favors the PR could write up a position statement making a persuasive case for it and addressing the various criticisms that have been made. They could post the statement in a wiki or gist or other document and invite like-minded people to comment and help improve it. Then people who favor alternate approaches (if there are multiple) could similarly write up position statements and we could link to them at the top of the PR.

This way positions could be directly compared against each other, and it should be possible for someone to develop an informed opinion by just looking at the quality and persuasiveness of the statements instead of needing to read through fragmented, repetitive, and disorganized discussion history.

[pinheadmz]

@owenstrevor

Can you please just edit out the comments about PEOPLE and leave the comments about CODE

bitcoin/bitcoin#32359 (comment)

[willcl-ark]

I've hidden this for now as it's still unaddressed.

I could be mistaken but it feels like a mixture of (mainly) AI, perhaps mixed with some original thoughts/references.

Please ping here when you've a) edited out the personal comments, and ideally b) ensured you have some original thoughts in it that haven't already been discussed previously.

[pinheadmz]

@matthew-ellis @billylindeman your comments are not adding any new information to the thread, please read all the existing discussion and then decide if you have any more INFORMATION to add. ACK and NACK are not just "votes".

In particular, this is not a block size issue and network throughput (ability for underpowered hardware to sync a node) is not at stake.

[pinheadmz]

@sonoranai you as well, do not need to mention storage costs, this PR does not propose a block size increase

[pinheadmz]

@sonoranai blocked for 24 hours but you can argue in this meta thread if you think that was a mistake and your comment was actually new, and correct, information:

Bitcoin’s economic viability isn’t solely determined by fees but also by node operability and decentralization.

Removing OP_RETURN limits opens the door to systematic blockchain bloat, disproportionately burdening smaller operators and eroding decentralization over time.

Bandwidth and storage costs aren’t theoretical—they directly influence the network’s accessibility and resilience.

Bitcoin’s flexibility must remain balanced by thoughtful protocol constraints, not simply delegated to fee markets that often lag behind systemic risk.

[pinheadmz]

@Kakar21 @Ali2kCom

it's not a block size increase

[Kakar21]

It lets more transactions hit the full 4 MW, so the average block size rises and chain growth accelerates. Functionally the same as a size increase.

[sonoranai]

I’d reply in kind, but I’ve been blocked for dissenting opinions lol.

…

On Tue, Apr 29, 2025 at 12:19 PM, Matthew Zipkin ***@***.***(mailto:On Tue, Apr 29, 2025 at 12:19 PM, Matthew Zipkin <<a href=)> wrote: ***@***.***(https://github.com/sonoranai) you as well, do not need to mention storage costs, this PR does not propose a block size increase — Reply to this email directly, [view it on GitHub](#18 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/BRHA4KROWNWBERFYELPR7GD237GFFAVCNFSM6AAAAAB4CT5EWKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEOJYGQ3DEMQ). You are receiving this because you were mentioned.Message ID: ***@***.***>

[donaldevine]

It seems to me that discussions of the negative long term implications of this change are too easily dismissed - by stating that this is a simple 'technical' change. I think we need to understand the long term implications of this change. As with any good testing strategy we need to model the worst case scenarios.

[pinheadmz]

More people are leaving off topic comments in the github issue tracker. @inkhaton @husaria-labs refer to specific types of data that may be illegal in certain jurisdictions. I want to remind everyone that all these concerns have been addressed over and over again. Below is my "saved reply" with links to all those resources. Please do not add comments to the github issue tracks that do not ADD ANYTHING new or useful.

This is a duplicate of issues bitcoin/bitcoin#33298 and bitcoin/bitcoin#33240 Not to mention extensive discussion in pull requests bitcoin/bitcoin#32381 bitcoin/bitcoin#32359 bitcoin/bitcoin#32406 and the meta discussion #18 and also the mailing list post.

Additional op_return concerns were already addressed at length here, here and here.

In addition please keep in mind the Bitcoin Core issue tracker is used for bug reports and feature requests for this software implementation. Please see https://github.com/bitcoin-core/meta for moderation guidelines about what is considered on or off topic comments.

[pinheadmz]

@ellenkampguus

[pinheadmz]

Another great response to this common question by sipa: https://bitcoin.stackexchange.com/a/127903/3667

[pinheadmz]

@Rev-9T