policy: uncap datacarrier by default #32406

Retains the -datacarrier* args, marks them as deprecated, and does not require another startup argument for multiple OP_RETURN outputs.

If a user has set -datacarriersize the value is "budgeted" across all seen OP_RETURN output scriptPubKeys. In other words the total script bytes stays the same, but can be spread across any number of outputs. This is done to not introduce an additional argument to support multiple outputs.

I do not advise people use the option with custom arguments and it is marked as deprecated to not mislead as a promise to offer it forever. The argument itself can be removed in some future release to clean up the code and minimize footguns for users.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32406.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #29954 (RPC: Return permitbaremultisig and maxdatacarriersize in getmempoolinfo by kristapsk)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Concept ACK

I think I'd prefer keeping the option until #32401 is addressed. Clearly there seems to be at least some demand for mining on charitable templates. If this is worth the additional code and maintenance is another discussion, and in the meantime I'd also support it being marked for future removal.

Concept NACK Reasons outlined on mailing list and other PR

Concept NACK. Nodes have no incentive to become free relays between those who want to store arbitrary data and miners. Setting defaults to the opposite effect just results in distrust of Core and migration away from it (as we have witnessed over the last week - although of course not Sybil resistant, seems genuine.)

@BitcoinMechanic

no incentive

Fee estimation and block propagation to name a few: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/3WVL60u6EQAJ

@BitcoinMechanic

no incentive

Fee estimation and block propagation to name a few: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/3WVL60u6EQAJ

It does no harm to fee estimation or block propagation. Nodes can and do cache transactions they reject from their mempools making compact blocks just as quick to verify regardless of if some of their contents was filtered.

As for fee estimation, it does not require knowledge of "the" mempool and there can never be such a thing.

The efforts to design Bitcoin Core around the increased reliance on mempool homogeneity are misguided and a trend in the wrong direction.

More high level - if nodes can configure their own mempool policies it obviously doesn't break things and demonstrably never has.

Concept ACK. This adds a deprecation step to #32359, which seems fine from a technical point of view, and was requested by regular contributors as well.

It will re-invite the brigading when the actual code is removed, but it will be easier to point to earlier discussion.

Code looks reasonable at first glance, when compared to #32359, but will re-review it.

3ba7449f6c335026b752366c53f9c309f09e6c64 could be split between a commit that allows multiple outputs and one that switches the default.

There's no need to Concept N(ACK) this if all you're going to do is repeat comments from #32359. They're not votes. Any actual reviewer of this PR (including maintainers) can read those arguments there.

Concept NACK.

For the same reasons mentioned in #32359.

Concept NACK

If fee estimation, block propagation etc has issues with mempool diversity specially for defense against spam/DoS then the position of not fixing that or making a future economic judgement based on theoretical assumptions is a fallacy. This broad position of Bitcoin Core can clearly increase spam and centralization regardless of economic incentives of miners which are all speculations and projections to modify how Bitcoin works instead of being realistic about the end goal of Bitcoin network. It's disappointing where this is headed.

FWIW I will not engage in meta discussion here. I will respond to any deficiencies in the code itself.

https://github.com/bitcoin/bitcoin/commit/3ba7449f6c335026b752366c53f9c309f09e6c64 could be split between a commit that allows multiple outputs and one that switches the default.

Touching tests twice is kind of annoying, but I can do if it makes code history easier and others agree.

@nsvrn this PR specifically enables users to have a divergent mempool. I don't understand the use case for that, but the proposal here addresses feedback on #32359 and adds a feature specifically for users who do not want their mempool to anticipate miner behavior.

@Sjors this is materially different from the other PR as it at least allows users the ability to configure. Not sure it's appropriate to invoke same reasoning in both cases?

@nsvrn this PR specifically enables users to have a divergent mempool. I don't understand the use case for that

The use case for users maintaining control over their mempools is self evident.

@BitcoinMechanic wrote:

allows users the ability to configure

It briefly retains it, typically deprecation is followed by removal one release later.

So if you're opposed to direct removal, then everyone will understand that you're also opposed to deprecation, so there's nothing new to say.

cACK

I like this approach, is far less problematic than #32359 Not going to add any more argument than the ones given there.

Left two small non-blocking comments

Concept ACK on relaxing the maximum capacity of the OP_RETURN size to the current transaction standardness limit.

1. This change will improve fee estimation in Bitcoin Core, as users will now be able to see the fee pressure from "data-carier" transactions that were previously broadcast out of band.

2. It will also improve block propagation time and make mining fairer, as data carrier transactions below standardness limit will now be relayed in nodes' mempools before being included in block templates. Nodes that already have these transactions can validate new blocks faster and relay them to peers and potentially other miners. If I understand correctly, Bitcoin's incentives require miners to learn about new blocks as quickly as possible so this is a positive change.

3. This could also potentially reduce the reliance on "out-of-band" services that collect data carrier transactions at high fees and possibly earn more revenue than other miners.

However, I still believe that while Bitcoin Core's transaction relay policy rules have significant advantages, they leave room for out-of-band services like those in point 3. As long as new innovations seek to utilize create transactions that violate those policies, we may continue to see these services persist.

This leads us to repeat the same process of relaxing rules to address issues 1, 2, and 3.

In my opinion, policy rules are an "easy way out" but limited solution. If we truly want to prevent issues 1, 2, and 3, those rules should be part of the consensus layer.

On Deprecating this feature: I will like to see this option not being deprecated and let's give users the ability to have a datacarier limit as they see fit; even though it is a footgun; we have a far worst option available i,e -blocksonly mode; in blocks only mode fee estimation is disabled. The work in #30157 allows a node to also detect when it's mempool is roughly not in sync with miners and prevent serving fee rate estimate.

Concept NACK

I've read the justifications but remain unconvinced the timing as well as the decision to altogether remove the option to configure is the right one.

Increasing the default and giving node runners the option to change that is the right way to go. And a few versions layers maybe the discussion to remove it altogether can be restarted. Current PR is way too sudden. It seems we did not learn the lesson from the unintentional effect lifting the witness script size limit had on the quantity of arbitrary data getting stored in the block.

Yes, I am aware it was possible to store data even before that, but it became economically lucrative since that specific change of removing the 10kb limit. Instead of capping that somehow, we are on a path to remove any and all data size configuration option the node runners currently have.

Besides, removing this option doesn't even help in a major way to remove utxo bloat because segwit discount will still be preferred for data above a certain size threshold.

Earnestly urge the project maintainers to rethink this one and implement it in more gradual changes. Thank you.

Concept ACK.

I believe this is a marginal improvement over #32359. It's better to err on the side of a normal deprecation path with more knobs rather than fewer, especially since this knob (-datacarriersize) was previously available. Its removal has been a specific point of controversy, explicitly described by some as core compelling speech. However, this conceptual change will likely affect only a small percentage of previous NACKers, since the intent and outcome seem clear and unchanged imo. At best, it provides hypothetical hope that if the option proves beneficial during the deprecation period, it might not ultimately be removed.

Concept NACK. Already been over this on multiple PRs. Spamming it with immaterial minor differences won't change the fundamental insanity and malice of the concept.

@moth-oss config options are not removed in this pull request.

Concept ACK with 1 nit

My issue with previous PR was largely due to removal vs deprecation of config options.

Needs a release note.

ACK c164064c266c518588d9d9175f9b14140ee751b6

Manually tested that the -datacarriersize limit does in fact match on a two OP_Return output transaction of the expected size, and that the resulting transaction was propagated to other nodes as expected.

Of course, I still (weakly) prefer my version. But this is acceptable too.

The code suggested uses the InitWarning and handles the errors on the failing test stoping the nodes manually

@moth-oss config options are not removed in this pull request.

This config option is, however, marked for future removal and is being marketed for future removal by the author of the PR by being defined as "DEPRECATED". I assume this will mean the removal of this toggle eventually when the controversy has died down and people aren't paying attention.

I believe this "DEPRECATED" definition is up for debate. Marking a toggle that has worked for my mempool policy and will work for my mempool policy in the future as "DEPRECATED" is FALSE & MISLEADING. It still works.

On that basis alone, I'm going to have to concept NACK this PR.

Concept ACK

Leaving the knob in but changing its default is a good approach.

After reading all comments and reviewing code.

utACK https://github.com/bitcoin/bitcoin/pull/32406/commits/3b3fafdb1c7eca8010194d0063579d44d555d546

I believe this "DEPRECATED" definition is up for debate. Marking a toggle that has worked for my mempool policy and will work for my mempool policy in the future as "DEPRECATED" is FALSE & MISLEADING. It still works.

Deprecation isn't a value judgment but a statement that it will be removed in a future version.

ACK 8c360d78b13fa7136db8d6e1e0af5d05f5141a64

The GUI popup can be fixed in a followup (before v30).

Deprecation isn't a value judgment but a statement that it will be removed in a future version.

Deprecation doesn't even always mean it will actually be removed in a future version; see #32423 eg.

Concept ACK / Approach ACK, wrote the reason in the other PR

Concept and code-review ACK 8c360d78b13fa7136db8d6e1e0af5d05f5141a64

Concept NACK for the same reason as #32359. Why would you remove a feature with a valid use case?

Code ACK, conceptual NACK purely on option deprecation (comments here and in the mailing list; the justifications for deprecating/removing these options appear faulty to me).

Edit to summarize the points already made, because there's discussion going on here now, with some claiming arguments they're making which have been addressed haven't been, often repeating points they already made elsewhere without adding anything new:

1. Any delay in a miner receiving a compact block because nodes along the shortest (time) path for that compact block to reach them are missing transactions in that block can be entirely removed. Compact block relay doesn't need to be delayed by mempool filters. See mailing list.
2. Globally consistent mempool policy is not possible, but you don't need it for transactions with larger-than-80-byte OP_RETURNS to be relayed. You just need enough nodes with more permissive relay policy. Librerelay is already an option you could be pushing people to run, and this change would allow people to achieve the same using Core without deprecating and removing options noderunners have had for years to manage their own resources. Deprecation and removal of these flags achieves absolutely nothing (besides encouraging users to run alternative implementations).
3. Downloading a transaction twice is not the same as downloading it once, and uploading it N times, even where N is 1. Upload bandwidth is not download bandwidth. On many residential networks, and particularly cellular, upload bandwidth is significantly lower. I can download 30x as much as I can upload in any given period. See linked comment.
4. A 'new' point I've only made away from the ML and GitHub: no, missing some transactions from your mempool doesn't make all that much of a difference when setting fees. You still have a view of what's getting confirmed, and a view of all the non-filtered transactions at the top of your own mempool. As somebody who has actually run a filtered mempool during periods where those filters were excluding many transactions being included within the next few blocks, it wasn't difficult to set fees. Made other points in the above linked comment, but not yet relevant to the discussion going on in this PR.

@BitcoinMechanic It does no harm to fee estimation or block propagation. Nodes can and do cache transactions they reject from their mempools making compact blocks just as quick to verify regardless of if some of their contents was filtered.

This is the first I have heard about this caching of non-standard transactions. If this is indeed the case, then the small-block-propagation-performance-degradation argument is largely invalidated, but this requires that the cache be sufficiently large and long-lived that the cache + mempool will effectively match a mempool without the standardness restrictions. What are the characteristics of this caching behavior, and does it actually prevent degradation of small block propagation in practice?

Concept NACK We should create more (and possibly easier) avenues that help node operators express their will. This PR is moving us in the opposite direction.

@k98kurz It's not generally true, that buffer is limited to 100 txns total, with no ratelimiting whatsoever. Please take the time to do some background reading: https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052

re-ACK c164064c266c518588d9d9175f9b14140ee751b6

Since my last review it adds MAX_SCRIPT_ELEMENT_SIZE to the test and uses a larger payload for it.

Concept NACK, for the same reasons stated in #32359 and #28130

ACK c164064c266c518588d9d9175f9b14140ee751b6

I believe this PR makes the following changes:

• allows multiple data carrier outputs in a single transaction (removing multi-op-return standardness failures)
• puts multiple data carrier outputs under the same limit (giving a new datacarrier standardness failure when the limit is exceeded instead of scriptpubkey)
• increases the limit's default from 83 to 100,000, making the limit irrelevant
• deprecates the two datacarrier settings
• simplifies some tests (that would otherwise fail due to the warning about setting the deprecated option)
• adds some tests for the new multi-datacarrier behaviour

I think I'd slightly favour not deprecating the options, and only increasing the limit to cover the real use cases we know of, so perhaps 160 bytes. I'm not sure I'd even rate those as a nit, though.

I don't see any issue with allowing multiple op-returns -- only using one where possible is already encouraged via it being cheaper in fees, and there's otherwise no significant impact on nodes that I can see.

I don't think this PR will have any impact on fee estimation (the only way that would occur is if a large majority of the mempool were transactions with multiple OP_RETURN outputs or an OP_RETURN output larger than 83 bytes, and that's not the case).

I think the impact of this PR on block relay is likely to also be very small; probably slightly negative in the short term, as more blocks are mined with txs with more/larger OP_RETURNs before many nodes in the network include such txs in their mempool, and slightly positive in the long term, as more nodes in the network do include those txs in their mempools.

Based on citrea's Clementine design, I think this will slightly lower how much the utxo set gets spammed -- trying to get every bit of data published on the blockchain moved to the witness or reduced to a commitment still seems possible to me, but given the complexity of BitVM-style protocols and bridges in general, I suspect it's unlikely that developers of those protocols will be willing to spend much time shaving off bytes here and there like we might otherwise like. Given that, it seems better to make the easiest solution one that also minimises long term harm, and leave the incentive for shaving off bytes to just be minimising fees.

@1ma @iicuriosity I could not find your comment with justification in the other PR. Please edit and add a link to your concept NACK

re-ACK c164064c266c518588d9d9175f9b14140ee751b6

(test-only change since my previous ACK; as per git diff 8c360d78 c164064c, the review comments #32406 (review) ff. were addressed)

reACK https://github.com/bitcoin/bitcoin/commit/c164064c266c518588d9d9175f9b14140ee751b6

Last review: #32406 (comment)

Concept ACK, if this won't be merged, actors will mine their non-standard transactions by contacting the miners directly and not via the p2p network.

in this way anyone willing to change their own mempool policy is still able to do it

Concept NACK, same rationale as #32359 (comment)

@donaldevinev1 (just in case this isn't an LLM review) there are no quadratics introduced here, downstream parsers doing bizarre things is not in scope for this PR.

Bitcoin’s success hinges on its decentralization and accessibility.

Moreover, out-of-band services that cater to data-carrier transactions are not inherently harmful to the network. They exist because Bitcoin was intentionally not designed as a general-purpose data storage layer, but rather as a secure payments system. Private markets offering these services reflect a willingness to pay for non-standard transactions, and this market demand does not justify altering Bitcoin’s core design to subsidize these use cases.

These two statements are incongruent with each other, as out-of-band services directly undermine the decentralization and accessibility of the network by eroding the transparency of the fee market as well as miner rewards.

@xstoicunicornx It's LLM spam

@moth-oss config options are not removed in this pull request.

It is deprecating the option though. I don't think deprecating it now is the right move. Increase the default (ideally not disabled/max) and see how things go before making the decision to deprecate it.

Reminder that this project's current moderation guidelines describe what we expect of contributors to this repository.

To keep it productive, especially on threads like these please:

• Stay on-topic: discuss the patch, not Bitcoin in general.
• Critique ideas, not motives.
• Contribute new signal: avoid repeating arguments already made earlier (these will start being marked as duplicate, to make the thread easier to navigate).

Note that this repository is not a general bitcoin discussion board. It's one step removed from general discussions as contributors here discuss changes via commenting on new revisions of the source code. For protocol-wide chat use the mailing list, Delving Bitcoin, Reddit, X, etc. There are now many conversations taking place on this very topic :)

If you think your comment has been moderated incorrectly, edit your comment (or not) and raise your concern in bitcoin-core/meta.

@moth-oss config options are not removed in this pull request.

It is deprecating the option though. I don't think deprecating it now is the right move. Increase the default (ideally not disabled/max) and see how things go before making the decision to deprecate it.

Deprecation notice can last for years: #32406 (comment)

Concept NACK.

While appearing to be a compromise, this PR uniquely does not achieve even partial success of the desired outcomes of either faction as stated in #32359) and as such is ineffective.

You might say this is the nature of a compromise, but I find this "splitting the difference" strategy to be uniquely harmful in its result.

This PR achieves none of the stated benefits of #32359 which were:

• better fee estimation/ unification of mempool state
• reduction of harm through the use of OP_RETURN rather than witness storage
• reduction of mining centralization through incentivizing use of "honest" data use case

It also substantially changes mempool filter behavior such that nodes with default configurations will have a significant relay change.

The ultimate result of this particular PR will be:

• further fracturing of the mempool policies
• further mining centralization as a means of reducing cost of non-standard transactions
• fee estimation continuing to be limited in scope
• continued use of witness data field for arbitrary data incentivized by lower cost from witness discount

For these reasons, I think it is unwise to handle these changes piecemeal and would advocate for closing this PR and revisiting mempool transaction standardness policy when transaction consensus cleanup has been successfully achieved. This makes the most sense since proponents of both sides of this argument say they don't want arbitrary data in the blockchain and that mempool policy should be tightly coupled with consensus policy.

@moth-oss config options are not removed in this pull request.

It is deprecating the option though. I don't think deprecating it now is the right move. Increase the default (ideally not disabled/max) and see how things go before making the decision to deprecate it.

Deprecation notice can last for years: #32406 (comment)

Deprecation is a clear signal that a feature will be removed in the future. Having an unspecified timeline till deprecation isn’t not an argument against OP’s point.

if the intention is that a feature may or may not be removed in the future, than deprecating it now is incorrect.

Concept NACK.

There clearly is no consensus, moving forward now will completely destroy the core reputation.

@BootsStribling

This PR achieves none of the stated benefits of #32359 which were:

• reduction of harm through the use of OP_RETURN rather than witness storage

The ultimate result of this particular PR will be:

• continued use of witness data field for arbitrary data incentivized by lower cost from witness discount

The harm reduction argument is that OP_RETURN use allows L2 users an alternative to stuffing arbitrary data into non-provably unspendable outputs that bloat the UTXO set. The witness data bloat was the focus of a PR from several years ago by luke-jr that added additional data-carrier filters, not this or the related PR by petertodd. The origin of this is an L2/sidechain use case that requires 144 bytes of ZKP data in transaction outputs -- they cannot rely upon stuffing it into witness data because so many nodes already filter out such transactions. The argument is that the current OP_RETURN filter incentivizes more harmful UTXO bloat compared to larger OP_RETURN outputs which can be dropped from the UTXO set.

I find that argument somewhat persuasive; however, after reading more arguments and giving it a bit more thought, concept NACK for deprecating the option instead of just changing the default configuration to fit the specific use case that started this whole controversy. From a UX design perspective, software should have sane defaults but not prevent power users from tuning, experimenting, and/or breaking their own systems.

Concept NACK

Deprecating the feature is an indication that the feature could be removed in the future without discussion. It is not different enough to just removing the feature entirely today, thus is isn't a compromise. Some are saying that features can stay deprecated for years but that's a false equivalence because those features are not as controversial as the OP_RETURN limit.

Increasing the default OP_RETURN limit to 100,000 is also contentious and should not be merged without further discussion on the mailing list. Forcing node runners to do extra setup work to limit data carrier transactions is against the preference of a significant group of node runners. Increasing the default limit still incentivizes them to migrate to alternative node implementations that don't require extra setup steps. Keeping the default OP_RETURN limit at 80 bytes or a somewhat sensible 144 bytes is a better compromise. Data usage above 144 bytes is less expensive in witness data anyway because of the discount so no reason to raise the default limit above 144 bytes.

utACK while I'm doubtful my comment should carry much weight, I'm wary of the public presentation weight up vacuous opposition, which ought count for nothing, against an absence of positive comments (because the choice is obvious enough that little need be said)... and the most effective thing I can do on that point is to get counted.

I have a slight preference for the closed PR that removes it completely. This is primarily because removing it completely avoids some predictable meta-abuse (e.g. the same people who deceived others about this PR existing, claiming they narrowly saved the day when no great doom happens). Also I have some small concern that if/when the contributors decide total removal would be best that they'll refrain from doing so out of a justified fear of another public abuse campaign, which could be avoided by just doing it now. That said, since these aren't points that go to the substance of the change itself, the other PR is currently closed, I don't think they matter much and I wouldn't fault someone for saying such reasoning should be completely disregarded. I'll refrain for further meta-points, though I think they are worth at least some consideration because they are akin to technical debt created by the proposal (but they are political rather than technical). As far as actually when the settings are removed after this PR, if ever, I think that is mostly just the judgement of the maintainers in terms of combinatorics testing cost and codebase cleanliness.

I am November Alpha Charlie Kilo (drat bot!) on suggestions that leave the limit slightly increased for some user or another (as mentioned by @ariel-lore @ajtowns and the later @k98kurz comment) unless they come with a credible argument that ~all the hashpower will enforce the same limit. Without that, a increased limit but still less than what many miners will do leaves the harmful gap between relay and mining policy. I think it would be an obviously poor choice that undermines much of the principled argument for making the change at all. (and to be clear, I would agree that all substantive discrepancies ought to be closed either by convincing miners to change behavior or removing the restrictions, and if a discrepant rule is hiding a DOS vulnerability it must be fixed either in code or consensus rules). If there were a serious argument that progress could be made getting most hashpower to enforce some other limit, then I would agree with trying to achieve that. My understanding however is that there is no real prospect of that.

Turning to the substance above, @k98kurz advances an argument that rejected transactions are cached as a reason relay/mining mismatches don't hurt block propagation. @instagibbs provides a technically correct response that the caching is insignificant and demonstratively doesn't avoid the problem, but I think it's important to give a broader answer in the context of this PR and the default relay policy of Bitcoin Core: If the transaction is never relayed to you because all your peers dropped it then no amount of caching can help.

Caching, when it is successful, reduces the bandwidth inflation from transmitting the txn twice (once to just throw it out, the second when it shows up in a block) and it may diminish the block relay harm caused by a small number of mining-inconsistent nodes. Improving that caching might help a little but especially in terms of widely deployed policy it can't help much because nodes simply won't see the transactions. Steel-manning the opposition a little: It could be argued that block relay could be improved to be less sensitive to missed transactions. I agree that it could and should, but doing so is very technically complex, unlikely to be accomplished safely in the social climate exhibited in these PRs, and that even at it's best is inherently inferior to already having the transaction and having already validated it. The best improvements we know of also trade more bandwidth usage to diminish the huge round trip delays, so keeping the discrepancy as small as can be is important to them. Some rare discrepancy is unavoidable, but filtering transactions that will get mined is an entirely unforced error.

[And as co-designer of the block relay mechanism: the extras pool is intended to deal with replacement races-- when a new replacement comes in for a little while it's anyone's guess which one a just found block will have. Depending on the ordering the miner saw the transactions a block could have any version, even when replacement would be denied by the replacement rules. Most of the time in the Bitcoin p2p network we took an assumption that relay and mining policy would not have any persistent substantive differences.]

The comment of @BootsStribling appears to be disconnected from reality in a manner characteristic of LLM hallucinations. It takes a number of positions which would be interesting if they were true or substantiated in any way by the comment. I don't think there is any serious dispute that this PR will not make the default behavior more consistent with what gets mined.

As far as fee estimation goes, the actual estimator is designed to be robust against missed transactions (they're basically ignored)-- but I know that I and many other people I know look at an actual mempool to make decisions on what to bid against... and having transactions unknown to us that will likely show up in the next block makes it harder to make a good decision. Again, I don't think there is any serious dispute on this point.

There are a number of other easily addressed fallacious points I've seen raised in opposition to this elsewhere, but since they haven't (yet) been raised here I won't (yet) readdress them, I don't think they're useful even as steelmanning the opposition because none of my counters on those have been countered. If anyone has any interest they can go follow my recent reddit traffic (u/nullc) which has been ~exclusively on this subject.

Cheers.

[And if anyone wants to respond to me but can't do so here for whatever reason, please reach out directly... my email is available to anyone!]

Concept ACK, the code looks sensible from brief look, though it's unclear what the intention of the parameter was.

I'd also like to ask the opposition to address the numerous arguments about the limit driving centralization and causing long-term storage problems as well as causing the size of the chain to increase in the mailinglist. I haven't seen a single person attempting to do that yet.

@FractalEncrypt you can use python to create a transaction with multiple OP_RETURN, fundrawtransaction to add inputs, signrawtransactionwithwallet to sign and sendrawtransaction to broadcast it later. It will be listed in the output for getrawmempool once broadcasted.

from bitcoin.core import CTransaction, CTxOut, CScript, b2x
from bitcoin.core.script import OP_RETURN

inputs = [] 
outputs = [
    CTxOut(0, CScript([OP_RETURN, b'deadbeef'])),
    CTxOut(0, CScript([OP_RETURN, b'cafebabe']))
]

tx = CTransaction(inputs, outputs)

raw_tx = b2x(tx.serialize())
print(raw_tx)

Example tx:

010000000001019eee1ba28a55abf31bd52501515d5c701478ea7edc27ba0b5e8a299e61bb81260000000000fdffffff0300000000000000000a6a08646561646265656600000000000000000a6a086361666562616265c0eb052a010000002251203e9d78540e0bb81dbb409b0ef517c11e2cb94d1ffab46ace3bcc45ccee39a1e80247304402205ae327bf416966d9e1567d4c141a7e408ed53e2863c2400023345bc3ce7d0d35022067f00d09a499e4282d33598c76f0bfa3d34b3c52810a5e39f61d100a607499ed0121020ead75a237556f4986a78e815700c3b4215679ffca5f25539f06ef38b766282900000000

<details>

{
  "txid": "3d0f6a1d4b0854968b9af9f8d8f477271adec96e85266e9c49ef08eec35970db",
  "hash": "c2765e5146a7cc07a81294ebea71c57b30b3083947460d7412f2f00115fe62a2",
  "version": 1,
  "size": 241,
  "vsize": 160,
  "weight": 637,
  "locktime": 0,
  "vin": [
    {
      "txid": "2681bb619e298a5e0bba27dc7eea7814705c5d510125d51bf3ab558aa21bee9e",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "304402205ae327bf416966d9e1567d4c141a7e408ed53e2863c2400023345bc3ce7d0d35022067f00d09a499e4282d33598c76f0bfa3d34b3c52810a5e39f61d100a607499ed01",
        "020ead75a237556f4986a78e815700c3b4215679ffca5f25539f06ef38b7662829"
      ],
      "sequence": 4294967293
    }
  ],
  "vout": [
    {
      "value": 0.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_RETURN 6465616462656566",
        "desc": "raw(6a086465616462656566)#2yjnw38t",
        "hex": "6a086465616462656566",
        "type": "nulldata"
      }
    },
    {
      "value": 0.00000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_RETURN 6361666562616265",
        "desc": "raw(6a086361666562616265)#kgaw0u9z",
        "hex": "6a086361666562616265",
        "type": "nulldata"
      }
    },
    {
      "value": 49.99998400,
      "n": 2,
      "scriptPubKey": {
        "asm": "1 3e9d78540e0bb81dbb409b0ef517c11e2cb94d1ffab46ace3bcc45ccee39a1e8",
        "desc": "rawtr(3e9d78540e0bb81dbb409b0ef517c11e2cb94d1ffab46ace3bcc45ccee39a1e8)#2q3qw2vr",
        "hex": "51203e9d78540e0bb81dbb409b0ef517c11e2cb94d1ffab46ace3bcc45ccee39a1e8",
        "address": "bcrt1p86whs4qwpwupmw6qnv80297prcktjngll26x4n3me3zuem3e585qf6mmjg",
        "type": "witness_v1_taproot"
      }
    }
  ]
}

</details>

Concept ACK

ACK c164064c266c518588d9d9175f9b14140ee751b6. I've left a few nits, but nothing blocking, especially in a PR with this much activity.

With the new default, I think users disabling or lowering datacarriersize are mostly reducing the performance of their own node, so I am in support of removing it completely. However, some people seem really keen on continuing to be able to do so, so pragmatically I think the approach taken in this PR is sensible. Changing the default is what's really important here.

Concept NACK

There should be freedom and sovereignty on what users relay on their nodes mempool. To marked them as deprecated sets the precedent that in the future node runners wont be able to configure this.

Thanks to everyone who gave thoughtful review, I hopefully addressed all code-related questions, if not let me know.

Concept ACK for this and Concept ACK for #32359 unless @luke-jr/Knots argues convincingly that the removal of these config options in Core makes maintaining them in Knots an excessive amount of work.

The objectives of Core's mempool policy and Knots mempool policy are totally different. Knots is trying to filter what it defines as spam and Core isn't. I don't know if it makes sense for Core to try catering to Knots' objectives when they clash with Core's objectives. It makes more sense for Core to direct users who want to attempt to filter spam-like transactions to run Knots instead.

That might be anathema to some but mempool policy isn't consensus critical and consensus compatible forks like Knots are there for those who strongly disagree with the merge decisions or the direction of travel of Core on non-consensus changes. I don't think anyone needs or wants this kind of discussion every time Core makes a change to mempool policy.

Anyway, my two cents for what it is worth.

re-ACK 35bcd8eed38130445aef5ebe217ab42248fa6f18

Smaller code code changes can be left to followups, as it's tedious to keep track of actual code review comments in this PR due to continued brigading.

unless @luke-jr/Knots argues convincingly that the removal of these config options in Core makes maintaining them in Knots an excessive amount of work

It really shouldn't be. After this PR it's a matter of changing the default. After we actually drop the deprecated option, it would be a matter of reverting that one commit.

I don't know if it makes sense for Core to try catering to Knots' objectives

In general Bitcoin Core provides very limited catering to forks, whether that's altcoins, modified implementations or even just experimental features. We do have e.g. CLIENT_NAME "Bitcoin Core" that's easy to override, and a CI flag SKIP_BRANCH_PUSH which replaced a hardcoded gui repository name. But those require some convincing to include, as I've experienced myself with #29274.

It probably does not help (in motivating reviewers) if your fork's main marketing message is to discredit upstream. @gmaxwell wrote:

I have a slight preference for the closed PR that removes it completely.

So do I conceptually, but at this point this PR has had more code review and some subsequent improvements, so I'd rather not switch back.

Bitcoin is a digital currency that OP_RETURN should NOT EXIST ever since the beginning. You all turning bitcoin to shitcoin. Look what you all did these years, just fix bugs and CVEs please.

re-ACK 35bcd8eed38130445aef5ebe217ab42248fa6f18

No changes except addressing review feedback:

• squashing commits
• improving release notes
• test style changes

Smaller code code changes can be left to followups, as it's tedious to keep track of actual code review comments in this PR due to continued brigading.

Agreed. Leaving nits here just for reference but they shouldn't block progress.

re-ACK 35bcd8eed38130445aef5ebe217ab42248fa6f18

utACK 35bcd8eed38130445aef5ebe217ab42248fa6f18

All nits that can be done in a follow-up.

ACK https://github.com/bitcoin/bitcoin/pull/32406/commits/35bcd8eed38130445aef5ebe217ab42248fa6f18

I have tested this branch with transactions having multiple OP_RETURN. Steps are shared in this comment marked as off-topic: #32406 (comment)

I am interested to see the usage of multiple OP_RETURN after v30 if this pull request gets merged. Written a post about their usage in coinjoin and other thoughts are shared on delving.

Last review: #32406 (comment)

Concept NACK for changing an existing default and deprecating an existing feature that take control away from the people's nodes.

Concept NACK

there is no clear need for this change. Use cases expressed are minor, with only hope of future usage. Expressed use cases can be accommodated in a simpler way with a minor size change. If Core would like this op return change for the future, do the work and convince node runners to change their defaults. Arguments for block propagation speed and fee estimates, though technically sound, are potentially minor compared to forcing the default size to max. Slow this down and move towards this goal if this is what you ultimately think is best, but gradually, allowing node runners to respond instead of being forced.

Definitely do not deprecate

Did the NACK/ACK bot break? Doesn't seem to be updating? @DrahtBot

Did the NACK/ACK bot break? Doesn't seem to be updating? @DrahtBot

This is a known issue. See https://github.com/maflcko/DrahtBot/issues/51. edit: fixed

@gmaxwell drahtbot has categorized your comment as nack instead of ack

code review ACK 35bcd8eed3

left one small comment to avoid further discussions...

drahtbot has categorized your comment as nack instead of ack

<details><summary>off-topic reply</summary>

When a comment contains both ack and nack (in uppercase), the bot just picks one. Obviously, it is off-topic to discuss here, but I think there is a misunderstanding what the goal of the summary comment by the bot is. The goal is not to have everyone "register" their "vote". It is simply a best-effort overview to have a clickable link to every reviewer's most recent review comment. The technical content of those review comments is what matters, not how many are registered in what category. This is also explained in the comment above the table: "See the guideline for information on the review process."

</details>

ACK 35bcd8eed38130445aef5ebe217ab42248fa6f18 -- only minor tweaks since previous review

I wrote:

I don't think this PR will have any impact on fee estimation (the only way that would occur is if a large majority of the mempool were transactions with multiple OP_RETURN outputs or an OP_RETURN output larger than 83 bytes, and that's not the case).

gmaxwell wrote:

As far as fee estimation goes, the actual estimator is designed to be robust against missed transactions (they're basically ignored)-- but I know that I and many other people I know look at an actual mempool to make decisions on what to bid against... and having transactions unknown to us that will likely show up in the next block makes it harder to make a good decision.

Prior to this discussion, there were only 61 txs included in blocks in the prior ~11 months (blocks 846,000 to 894,000) that this PR would allow to be relayed (using up ~0.004% of blockspace during that period). Since this discussion started, that's increased, eg to ~0.16% with ~11,800 txs (in blocks 894,000 to 896,528), though that rises to 3.1% of blockspace if you only count the blocks that actually included such txs. Those levels seem pretty easy to cope with, no matter how you calculate fees. (Only 3 of the 61 txs had multiple OP_RETURNs, 33 had a single OP_RETURN scriptPubKey between 84 and 160 bytes, and there were an additional six OP_RETURNs in txs larger than 100kvB which will still be non-standard if this PR is merged, one of which was also 0 fees)

gmaxwell also wrote:

I would agree that all substantive discrepancies ought to be closed either by convincing miners to change behavior or removing the restrictions,

I don't disagree with this in principle, but I don't think the level of non-standard OP_RETURNs that we were seeing prior to this topic being raised for discussion (ie 61 txs over a period of 48,000 blocks) should be counted as a "substantive" discrepency.

If it were to be counted, I think that's a goal that's pretty unlikely to be achievable -- eg Mara's slipstream has a transaction privacy policy ("Before they are mined, yes. Your transactions are not broadcasted to the Bitcoin network until they have received at least one confirmation") which is advertised as being particularly useful to prevent token mints being sniped. Violations of other standardness rules (particularly tx size/weight) or using replace-by-feerate policies versus replace-by-fee ones also seem likely to remain sources of occasional discrepencies.

makes more sense to change the default to be larger or whatever not deprecate the option. have we been seeing a lot of non-standard transactions with large op_returns? 61 out of 48,000 is kind of small and probably anomalous. this pull request should come with some evidence that this is necessary to keep standardness in line with usage

It seems if you want people to actually use this much OP RETURN data by relaxing the filter it'd make sense to simultaneously prevent "inscriptions" with this https://github.com/bitcoin/bitcoin/pull/28408

It seems if you want people to actually use this much OP RETURN data by relaxing the filter it'd make sense to simultaneously prevent "inscriptions" with this #28408

You can ACK this pull request if you agree with the changes and open a new issue or pull request for #28408

Concept NACK

Nodes shouldn’t relay arbitrary data on the network. Removing the cap on the default datacarriersize makes that easier. We’ve already seen a clear signal that people don’t want this, with a noticeable migration from Bitcoin Core to Bitcoin Knots over the past three weeks. And since PR [#32359](/bitcoin-bitcoin/32359/) was closed by @glozow a few days ago, I’d expect this one to be closed too.

@blockdyor Unclear to me why the other PR being closed in favor of this one implies this one should be closed. Going to keep this open, thanks!

We’ve already seen a clear signal that people don’t want this, with a noticeable migration from Bitcoin Core to Bitcoin Knots over the past three weeks.

It’s clear we’ve agreed to disagree: people who prefer arbitrary filters will run Bitcoin Knots, and people who prefer harmless, consensus-valid transactions will run Bitcoin Core.

Concept ACK. Tested on top of current master, no issues observed. Looks good to me.

We’ve already seen a clear signal that people don’t want this, with a noticeable migration from Bitcoin Core to Bitcoin Knots over the past three weeks.

It’s clear we’ve agreed to disagree: people who prefer arbitrary filters will run Bitcoin Knots, and people who prefer harmless, consensus-valid transactions will run Bitcoin Core.

Part of the motivation for this PR is that large OP RETURNs are less harmful than fake pub keys, with the understanding that both are still harmful.

wouldn't it be reasonable to make the cap a "little bigger by default" as a conservative change, and just to see if it causes an uptick in average op_return sizes and uses as storage?

its not so urgent to allow 10kb op_returns

and data carrier limits are more about protecting the p2p and mempool layers - not protecting from inclusion in blocks

the knock-on effects of arbitrary data at the p2p layer could be severe in ways that have nothing to do with block storage

On Fri, May 23, 2025 at 5:38 PM BitcoinMechanic @.***> wrote:

BitcoinMechanic left a comment (bitcoin/bitcoin#32406) https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2906118037

We’ve already seen a clear signal that people don’t want this, with a noticeable migration from Bitcoin Core to Bitcoin Knots over the past three weeks.

It’s clear we’ve agreed to disagree: people who prefer arbitrary filters will run Bitcoin Knots, and people who prefer harmless, consensus-valid transactions will run Bitcoin Core.

Part of the motivation for this PR is that large OP RETURNs are less harmful than fake pub keys, with the understanding that both are still harmful.

— Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2906118037, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMUN7P7NTVQH2CZJJQYL2765R3AVCNFSM6AAAAAB4KKCMJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMBWGEYTQMBTG4 . You are receiving this because you commented.Message ID: @.***>

and data carrier limits are more about protecting the p2p and mempool layers - not protecting from inclusion in blocks

Simply not true. The only motivation for the rule is to nudge people to not store arbitrary data on chain when it can be avoided.

the knock-on effects of arbitrary data at the p2p layer could be severe in ways that have nothing to do with block storage

There is zero reason to think this. Transactions can be up to 100kvB in any other shape or form, and the p2p needs to somehow handle that with or without this change.

There is zero reason to think this. Transactions can be up to 100kvB in any other shape or form, and the p2p needs to somehow handle that with or without this change.

Zero reason, like using the p2p layer as a command and control system for botnets by allowing long strings of arbitrary data? I guess it can be done with steganography anyway.

On Sat, May 24, 2025 at 7:45 AM Gregory Sanders @.***> wrote:

instagibbs left a comment (bitcoin/bitcoin#32406) https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2906870658

and data carrier limits are more about protecting the p2p and mempool layers - not protecting from inclusion in blocks

Simply not true. The only motivation for the rule is to nudge people to not store arbitrary data on chain when it can be avoided.

the knock-on effects of arbitrary data at the p2p layer could be severe in ways that have nothing to do with block storage

There is zero reason to think this. Transactions can be up to 100kvB in any other shape or form, and the p2p needs to somehow handle that with or without this change.

— Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2906870658, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMULYL2BUFA5HF7RLMTD3ACAYFAVCNFSM6AAAAAB4KKCMJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMBWHA3TANRVHA . You are receiving this because you commented.Message ID: @.***>

Zero reason, like using the p2p layer as a command and control system for botnets by allowing long strings of arbitrary data

They have used output amounts in the past to encode IP address: https://www.akamai.com/blog/security/bitcoins--blockchains--and-botnets

They can use Libre Relay for OP_RETURN. Bitcoin Core policies can't stop botnets from making consensus-valid transactions.

ACK 35bcd8eed38130445aef5ebe217ab42248fa6f18

For anyone interested, I posted a detailed explanation on Delving of why I am against this proposal: https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697/2?u=cguida

very detailed and accurate thanks

On Sat, May 24, 2025, 3:14 PM Chris Guida @.***> wrote:

chrisguida left a comment (bitcoin/bitcoin#32406) https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2907189059

For anyone interested, I posted a detailed explanation on Delving of why I am against this proposal: https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697/2?u=cguida

— Reply to this email directly, view it on GitHub https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2907189059, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMUL4XKDGDKP4KKETIXT3ADVLHAVCNFSM6AAAAAB4KKCMJOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMBXGE4DSMBVHE . You are receiving this because you commented.Message ID: @.***>

Code Review ACK 35bcd8eed38130445aef5ebe217ab42248fa6f18

Concept ACK, arbitrary restrictions won't stop how people are currently using the network already.

ACK 35bcd8eed38130445aef5ebe217ab42248fa6f18

Concept

I understand node runners feeling like their agency would be restricted by deprecating and later removing this limit. However, I have not encountered any strong technical or incentive compatible argument in favor of keeping it. Deprecating and giving a little bit more opportunity for such an argument to appear before removal seems like a diplomatically acceptable solution.

I don't feel strongly enough about this to have kicked this hornets nest of a debate in the first place. However, we hopefully already paid most of the cost for this debate in energy and trust in the short term, so getting closer to removal should free up energy in the long term.

Spammers can use networks like Libre Relay with preferential peering to circumvent this limit anyway.

Relaying OP_RETURNs between ~80-~140 bytes does not substantially change the economics for spammers using witness data today.

Gist for more in-depth arguments with attempt to steel-man opposition: https://gist.github.com/hodlinator/501ed81c61b06b6e082663ca646655eb

Approach

Thorough. Only one inline nit.

rebase required due to silent merge conflict

edit: Since the arg is deprecated now and used in a new spot in master, the newly touched test was failing, requiring touching the commits. Sorry!

re-ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

No changes since 35bcd8eed38130445aef5ebe217ab42248fa6f18 except rebasing and removing the -datacarriersize=100000 no-op in mempool_updatefromblock.py that would cause the test to fail just for using a deprecated option.

<details> <summary> git range-diff 35bcd8eed38130445aef5ebe217ab42248fa6f18...a189d636184b1c28fa4a325b56c1fab8f44527b1</summary>

  1:  496c5c2e92 = 285:  9f36962b07 policy: uncap datacarrier by default
  2:  af9f354c5a ! 286:  63091b79e7 test: remove unnecessary -datacarriersize args from tests
    @@ test/functional/mempool_truc.py: class MempoolTRUC(BitcoinTestFramework):
              self.log.info("Test that TRUC inheritance is checked within package")
              node = self.nodes[0]

    + ## test/functional/mempool_updatefromblock.py ##
    +@@ test/functional/mempool_updatefromblock.py: class MempoolUpdateFromBlockTest(BitcoinTestFramework):
    +     def set_test_params(self):
    +         self.num_nodes = 1
    +         # Ancestor and descendant limits depend on transaction_graph_test requirements
    +-        self.extra_args = [['-limitdescendantsize=1000', '-limitancestorsize=1000', f'-limitancestorcount={CUSTOM_ANCESTOR_COUNT}', f'-limitdescendantcount={CUSTOM_DESCENDANT_COUNT}', '-datacarriersize=100000']]
    ++        self.extra_args = [['-limitdescendantsize=1000', '-limitancestorsize=1000', f'-limitancestorcount={CUSTOM_ANCESTOR_COUNT}', f'-limitdescendantcount={CUSTOM_DESCENDANT_COUNT}']]
    +
    +     def create_empty_fork(self, fork_length):
    +         '''
    +
      ## test/functional/mining_basic.py ##
     @@ test/functional/mining_basic.py: class MiningTest(BitcoinTestFramework):
                  assert tx_below_min_feerate['txid'] not in block_template_txids
  3:  1ade56661f = 287:  0b4048c733 datacarrier: deprecate startup arguments for future removal
  4:  1c4bf434db = 288:  a141e1bf50 Add more OP_RETURN mempool acceptance functional tests
  5:  35bcd8eed3 = 289:  a189d63618 add release note for datacarriersize default change

</details>

re-ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

Just a rebase and minor test tweak since my previous review.

re-ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

Just a rebase due to silent merge conflict since my prev review

re-ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

(as per $ git range-diff 35bcd8ee...a189d636)

re-ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

<details> <summary>Signature</summary>

<pre> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 re-ACK a189d636184b1c28fa4a325b56c1fab8f44527b1 -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQSSUwYqT5LWNFkIXKYtIwUgISpZAQUCaDoHIwAKCRAtIwUgISpZ AXfEAQCLt/Tzit+ZxCmsP0BkCi4zG+4OyFHcvzytQ6SJFQuUjwD/TsjUydeA06Ft RcJvG/+brpVM8NV3Ga/trp74dg67NQE= =xtxJ -----END PGP SIGNATURE----- </pre>

</details>

Previous review: #32406#pullrequestreview-2838300949

re-ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

Changes since previous review (https://github.com/bitcoin/bitcoin/pull/32406#pullrequestreview-2870311100):

• Resolved silent merge conflict with 47894367b583c06c53d568dc4a984d27bac8f742 by same author.

ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

I would have also had a slight preference for "removing the (ineffective) knob" a.k.a the previous iteration of this PR, but removing the limited default along with a notice of intended deprecation works for me too.

Why is this pr still open?

"It's abundantly clear that this PR is controversial and, in its current state, has no hope of reaching a conclusion that is acceptable to everyone." -Achow101

#28408 (comment)

reACK a189d636184b1c28fa4a325b56c1fab8f44527b1

reNACK. 100 kilobyte OP RETURNS add absolutely nothing to Bitcoin.

They'd have to actually be happening out of band currently for the concerns about fee estimation/block propagation/mining centralization to actually be relevant here, even then they'd be massively overblown.

There are currently almost no OP RETURNs greater than 80 bytes. All this PR will do is open up another spam-highway along a route that is thankfully not practical with this filter left alone like it should be.

reNACK. 100 kilobyte OP RETURNS add absolutely nothing to Bitcoin.

NACK doesn't need to be reposted if there is no new information added in the rationale. ACKs are reposted because they are linked with commits and become stale after rebase or update.

Sure, but I'm still marked as "Concept A%C*K" here for some reason?

reNACK. 100 kilobyte OP RETURNS add absolutely nothing to Bitcoin.

NACK doesn't need to be reposted if there is no new information added in the rationale. ACKs are reposted because they are linked with commits and become stale after rebase or update.

Sure, but I'm still marked as "Concept ACK" here for some reason?

Probably the bot misunderstood your previous comment based on the regex used.

ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

re-ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

Nits in things like the exact wording of the release notes can be handled in a followup pull-req if necessary. The basic functionality clearly works.

@AMoynahan89

Why is this pr still open?

"It's abundantly clear that this PR is controversial and, in its current state, has no hope of reaching a conclusion that is acceptable to everyone." -Achow101

Pretty much every change to Bitcoin Core is controversial in the sense that there's someone out there who doesn't want the change to happen, or wants it to happen in a different way. Segwit, for example, was extremely controversial in that sense, even to the point of large companies holding meetings to try to replace Bitcoin Core with their own dev team. Not to mention Craig Wright's lawsuits.

Controversy needs to be weighed against the reasonableness of that controversy, and where the controversy is coming from. Here, we have good consensus among reasonable devs that actively contribute to Bitcoin Core that this change is a good idea. Secondly, the people who still disagree with this change are welcome to run an alternative fork such as Knots.

Pretty much every change to Bitcoin Core is controversial in the sense that there's someone out there who doesn't want the change to happen, or wants it to happen in a different way.

Statement that's "technically" true but leaves out critical context. This PR is the reason Core dropped from 97% to below 90% adoption. It's not trivial disagreement, far from it.

Controversy needs to be weighed against the reasonableness of that controversy, and where the controversy is coming from. Here, we have good consensus among reasonable devs that actively contribute to Bitcoin Core that this change is a good idea. Secondly, the people who still disagree with this change are welcome to run an alternative fork such as Knots.

Translation: there's an established pecking order in here and only a few get to define what "reasonable" means. In this instance, reasonable means follow the experts, and if you don't like it, run something else.

At the risk of stating the obvious, any "trust the experts" approach necessarily implies centralized decision-making and flies directly in the face of open-source development principles.

dropped from 97% to below 90% adoption

flies directly in the face of open-source development principles. @maluquices this is a contradiction. Open source means anyone can fork the code, change it, release it, and use it. Bitcoin Core has been discussed, reviewed and maintained by hundreds of experts for over a decade and turned an idea into a two trillion dollar asset. Everyone is free to use Bitcoin Core, or to use software reviewed and maintained by any other group of people of any size.

@pinheadmz a "technically" accurate gotcha attempt that ignores the deeper issue. The adoption drop signals a real erosion of trust, not just a casual exercise of open-source freedom. When a change pushes away a substantial portion of the user base, dismissing it as "just fork it" ignores a practical reality. Open-source principles are a little more evolved than "the code is public" and require transparent decision-making that respects diverse input. When "reasonable" is defined by the few and dissenters are told to fork off, it stifles meaningful community participation. I like to think most contributors in this repo agree on this fundamental principle.

@maluquices all I'm trying to say is, don't drag "open source" into this conversation. Every single word has been open, as well as years of historical merit of the author and reviewers.

Concept NACK.

After careful review, I must conclude that the PR doesn't accomplish the objectives.

@petertodd you’re loading up with the logical fallacies which demonstrates the need for politics in the absence of a genuine need to change the code at this time.

Here, we have good consensus among reasonable devs that actively contribute to Bitcoin Core that this change is a good idea.

Ignoring however you choose to define “good consensus” and “reasonable”, you’re employing several logical fallacies: Appeal to Authority, Appeal to Popularity, Appeal to Tradition, and I’m sure some others.

Secondly, the people who still disagree with this change are welcome to run an alternative fork such as Knots.

They already are, along with a notable increase in the number running Knots since this debacle has begun.

Perhaps go back to “selling” it with actual needs and use cases that node runners are asking for, NOT miners and other corporate organizations.

ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

Concept NACK. I have to disagree with the the concept of removing user control over mempool policies and the potential for massive increases in blockchain bloat. The 83-byte limit isn't arbitrary - it's there to prevent people from turning Bitcoin into a data storage service. We need to think of the possible worst case scenarios of this change, e.g. data hoarders filling up blocks with data, pushing out actual Bitcoin payments. The fee market gets completely screwed up when you mix payment transactions with data storage. Someone storing a file can wait days. But someone trying to buy something on-chain needs that transaction to go through now. Here's the thing that really gets me: we're removing the user's choice about this stuff. Right now, if you want to run a node that doesn't relay huge data blobs, you can do that. This change forces everyone to participate in the data storage business whether they want to or not. That's the opposite of what Bitcoin is supposed to be about. If we actually cared about fixing fee estimation or block propagation, we'd improve the algorithms that handle those things. Instead, we're ripping out protections that have worked fine for years and hoping it somehow makes things better. That's not engineering - that's wishful thinking.

I'd really appreciate it if @DrahtBot was manually updated to reflect my Concept NACK - currently it says I approve and I'd rather not go down in history as having been in favour of this terrible idea.

update: I see it has been fixed now - thank you

I'd really appreciate it if @DrahtBot was manually updated to reflect my Concept NACK

You can fix it yourself, as it clearly states in the comment:

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

@BitcoinMechanic: I’m not sure what you expect DrahtBot to do, but it just parses comments and links to the last comment per user that contains a relevant string. So, when you make comments like this, what do you think should happen?

You fixed it yourself, congrats:

Concept ACK a189d636184b1c28fa4a325b56c1fab8f44527b1.

I prefer the approach from #32359 because i believe that exposing the option is at best misleading to users. However i am fine with any approach (including this one) which gets rid of the poor incentive unnecessarily set by the existing limit.

Since this change has created a significant amount of confusion among bitcoiners, i have compiled a list of objections and concerns raised by the community and addressed them all in a single post. This post notably contains all objections that were raised on the original PR (#32359). I won't reproduce the whole content here but here is a list of the objections addressed in the post:

• "Schrödinger filters: there is a double standard whereby 'Core' is claiming that filters don’t work but actually they do because we need to change the OP_RETURN limit."
• "Nirvana argument: this change is being pushed by people who believe the lack of a perfect solution to fight arbitrary data storage onchain means we should give up fighting it altogether."
• "OP_RETURN was only ever made standard at all as a tolerated form of data carrying to prevent more harmful forms of data carrying (fake pubkeys/script hashes/bare multisig/etc). To serve that purpose, it only needs to be ~40 bytes. The ~80 byte allowance is beyond sufficient for its intended purpose."
• "The proper response to a spam attack is not to cave to the spammers."
• "People won’t move from using fake pubkeys to op_return to be nice to us is ludicrous because it’d cost them 4x more. This is just bluff to kill the filters."
• "Removing all limits on OP_RETURNs creates a perverse incentive: transactions can now carry large, non-economic payloads while avoiding long-term storage costs."
• "A given quantity of data stored in a op_return output has a far larger negative externality on the throughput than the same data stored in a witness."
• "Boiling frog: Core developers are trying to gradually make Bitcoin a universal database instead of just money, one step at a time."
• "Core is trying to accommodate the Taproot Wizards who are a self-declared attack on Bitcoin which tries to corrupt the ecosystem."
• "Core contributors actually believe that Bitcoin should be used for anything rather than just money. They should argue that instead of rationalizing with dishonest arguments such as UTxO bloat which is not the real reason they are pushing it."
• "Antoine Poinsot paid Peter Todd to open the pull request to Bitcoin Core."
• "Taking a step back from the technical details, Core is trying to push a contentious change that obviously everybody is annoyed with."
• "As the reference implementation, Core has a responsibility of steering away from controversy as much as possible. It is irresponsible for Core to merge this change because of the number of people objecting to it on the Github pull request."
• "The way this is being rushed is a red flag."
• "This is making changes for the sake of making changes when nobody asked for this."
• "This proposal won’t allow to reach the stated goal (limiting the misuse of witness data)."
• "Introducing filters is what Satoshi did, this is a departure from his legacy."
• "This type of change should be treated with no less scrutiny than a hard fork, because that’s essentially what this is"
• "That may sound like hyperbole, but it really isn’t. If this PR is merged, Bitcoin as we know it changes forever in the most fundamental way imaginable: the reference implementation explicitly turning the Bitcoin network into an arbitrary data storage system, instead of evolving it as a decentralized currency."
• "While provably unspendable outputs are preferable to dust outputs in some contexts, the absence of any guardrails could make it easier for bad actors to stress the network, especially in combination with existing vulnerabilities."
• "Data stored in an OP_RETURN output doesn’t need to be chunked like it does in an inscription. This presents a risk for node runners as it allows anyone to store unobfuscated data on their disk."
• "Considering the floodgates of absolutely horror this PR is going to bring upon Bitcoin node runners, there absolutely needs to be a way for existing users to protect themselves and retroactively apply this on-disk obfuscation to existing node data."
• "This PR lowers the bar for storing large contiguous chunks arbitrary data on the systems of thousands of node runners worldwide from “you must get a miner to mine this for you” down to “you have to broadcast it and pay a fee”."
• "I think the bar to bypass IsStandard is very underestimated. The fact that we don’t see huge OP_RETURNs all the time proves its overall effectiveness in protecting the network as a first line of defense."
• "The -datacarrier option should be kept on Bitcoin Core regardless of whether the default is changed."
• "As a node runner I should be allowed to configure my mempool and not have it filled with what I consider spam. This can make running a node very RAM expensive."
• "This PR is completely pointless from a technical and incentives perspective unless combined with something like #28408 to make OP_RETURN the “proper” way to store data."
• "I am also concerned that in the future we might see a large scale bypassing of the Core standarness rules, but it’s unclear whether we’ve reached that point yet. We can always reconsider dropping the OP_RETURN limit once it becomes truly problematic - but, and this is a genuine question, are we there yet?"
• "Raising UTxO bloat as a concern is beyond ironic when considering applications like Citrea may only cause trivial amount of bloat while inscriptions, which Core refuses to filter, are responsible for over 8 GiB of bloat in the past couple of years."
• "Bitcoin Core dev should rather focus on Bitcoin as money."
• "Bitcoin Core lifting the OP_RETURN limit is sending a signal that data storage is welcome, whereas before it was only tolerated."
• "Increasing the size of OP_RETURN is an existential threat to Bitcoin."
• "If you don’t upgrade Core devs are going to accuse you of censorship."

Then there were multiple objections and concerns raised around inscriptions and large amounts of onchain data storage, which lifting the OP_RETURN standardness limit has no bearing on. Here is the list of objections i addressed in this post, in a collapsible section as it is tangential but off-topic for this thread.

<details> <summary>Click to see list of objections to not filtering inscriptions / JPEGs</summary>

• "Bitcoin always had filters. Not reacting to inscriptions is departing from 15 years of precedent."
• "Relay filters have historically been successful at preventing 'spam'."
• "Raising UTxO bloat as a concern is ironic when considering applications like Citrea may only cause trivial amount of bloat while inscriptions, which Core refuses to filter, are responsible for over 8 GiB of bloat in the past couple of years." (inscription version)
• "See, inscription respect the dust limit therefore filters are working!"
• "Filtering will reduce supply and therefore suppress demand for inscriptions by increasing the cost of using them."
• "Bitcoin should not try to optimize for more things than being money. Anything else is diluting focus."
• "We should not be bidding for block space against non-monetary usecases."
• "This is the first step toward preventing arbitrary data storage at the consensus level. The threat of making it consensus invalid may be enough to deter usage entirely."

</details>

One new objection i can see in the thread here that is not covered in my Delving post is one raised by @moth-oss and then @earonesty here that we should favour bumping the default limit instead of doing with it entirely. I offered a steelman of this argument on the mailing list and Greg Maxwell offered a rebuttal. TL;DR: the cat is already out of the bag, miners already include arbitrarily large OP_RETURN outputs in their block templates, therefore Bitcoin Core should do it (and relay such transactions) by default. In addition i think there is a social aspect to this: this limit is unnecessary and only exists for historical reasons. We should just get rid of it and doing it in multiple steps just leaves more opportunities for people creating confusion among bitcoiners on this topic to weaponize it again.

Hi @darosior -

As you are well aware, your "list" here is nowhere close to a steelman of the opposition to this PR.

You have yet to address anything in my responses to your Delving post.

I remain a firm Concept NACK.

Hi @darosier nowhere in your comprehensive rebuttal do you mention that >99% of OP RETURNs in the chain fit within the limit imposed by the existing filter

That is despite the fact that people are deliberately trying to demonstrate how "useless" filters are by going out of band to get miners to manually add this stuff to their block templates.

It's very simple: before you merge this PR, most OP RETURNs will be limited to 80 bytes or less.

If it gets merged, there will be a massive increase in OP RETURNs larger than that.

Magically everyone in Bitcoin Core has managed to get cause and effect the wrong way around.

BitcoinMdchanic:

As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead.

Obviously we are hoping for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs.

Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return.

On June 7, 2025 1:00:38 AM GMT+02:00, BitcoinMechanic @.***> wrote:

BitcoinMechanic left a comment (bitcoin/bitcoin#32406)

Hi @darosier nowhere in your comprehensive rebuttal do you mention that >99% of OP RETURNs in the chain fit within the limit imposed by the existing filter

That is despite the fact that people are deliberately trying to demonstrate how "useless" filters are by going out of band to get miners to manually add this stuff to their block templates.

It's very simple: before you merge this PR, most OP RETURNs will be limited to 80 bytes or less.

If it gets merged, there will be a massive increase in OP RETURNs larger than that.

Magically everyone in Bitcoin Core has managed to get cause and effect the wrong way around.

BitcoinMdchanic: As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead. Obviously we are hoping for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs. Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return. … On June 7, 2025 1:00:38 AM GMT+02:00, BitcoinMechanic @.***> wrote: BitcoinMechanic left a comment (bitcoin/bitcoin#32406) Hi @darosier nowhere in your comprehensive rebuttal do you mention that >99% of OP RETURNs in the chain fit within the limit imposed by the existing filter That is despite the fact that people are deliberately trying to demonstrate how "useless" filters are by going out of band to get miners to manually add this stuff to their block templates. It's very simple: before you merge this PR, most OP RETURNs will be limited to 80 bytes or less. If it gets merged, there will be a massive increase in OP RETURNs larger than that. Magically everyone in Bitcoin Core has managed to get cause and effect the wrong way around.

This is not a Citrea node - nor is it a Citrea client. This is a Bitcoin node, the purpose of which is Bitcoin transaction verification. Might I suggest you modify a different blockchain or create a brand new blockchain? Then you can fill all the blocks with Citrea or non-monetary data. You can even increase the block size. As I disagree with you, I suspect that you will delete this comment and block me. I would suggest you don't do that. This is a valid argument and I am not brigading. You may not like it but this is an open source community and we don't block free speech.

BitcoinMdchanic: As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead. Obviously we are hoping for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs. Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return. … On June 7, 2025 1:00:38 AM GMT+02:00, BitcoinMechanic @.***> wrote: BitcoinMechanic left a comment (bitcoin/bitcoin#32406) Hi @darosier nowhere in your comprehensive rebuttal do you mention that >99% of OP RETURNs in the chain fit within the limit imposed by the existing filter That is despite the fact that people are deliberately trying to demonstrate how "useless" filters are by going out of band to get miners to manually add this stuff to their block templates. It's very simple: before you merge this PR, most OP RETURNs will be limited to 80 bytes or less. If it gets merged, there will be a massive increase in OP RETURNs larger than that. Magically everyone in Bitcoin Core has managed to get cause and effect the wrong way around.

Than make a PR for a reasonable change to OP RETURN size limit. One that accounts for potential future usage by companies like citrea.

“We’re removing all limits because we don’t ever want to revisit this or have to increase the limit again” isn’t a great argument when it comes to making changes to standardness/relay policy.

Looking for a little sanity here.

BitcoinMdchanic: As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead. Obviously we are hoping for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs. Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return. … On June 7, 2025 1:00:38 AM GMT+02:00, BitcoinMechanic @.***> wrote: BitcoinMechanic left a comment (bitcoin/bitcoin#32406) Hi @darosier nowhere in your comprehensive rebuttal do you mention that >99% of OP RETURNs in the chain fit within the limit imposed by the existing filter That is despite the fact that people are deliberately trying to demonstrate how "useless" filters are by going out of band to get miners to manually add this stuff to their block templates. It's very simple: before you merge this PR, most OP RETURNs will be limited to 80 bytes or less. If it gets merged, there will be a massive increase in OP RETURNs larger than that. Magically everyone in Bitcoin Core has managed to get cause and effect the wrong way around.

Yes, I'm well aware of the rationalization here.

As long as it continues to ignore the implication - that if a filter is annoying enough to prevent > 80 byte ORs then it can be just as annoying to witness abuse too - then you don't have a serious discussion about mitigation of harmful effects of non-monetary use of Bitcoin. Rather, it's a farce in which "discussion" is just cherry picking in service of an agenda to facilitate more of it.

@1440000bytes please keep comments on topic, there are many subscribers here.

Comments about maintainers, other specific individuals, "drama" etc. are not on topic here in this thread. You can take that over to bitcoin-core/meta, if you so desire.

Failure to keep future comments focused on review of the proposed changes will result in a temporary ban. If you want to debate this comment please also do so on https://github.com/bitcoin-core/meta/, and not here. See the moderation guidelines for more information on this policy.

I know this is a long thread, and I'm basically a totally new face on this project. Nevertheless, I'd like to put down some thoughts.

Overall, I think it's good UX for Bitcoin Core to perform the best fee estimation, which means relaying the most relevant transactions to that estimation.

Sounds like this PR looks to do that by configuring Bitcoin Core to relay large "data carrier" transactions, which are currently actually being mined but getting relayed using out-of-band software. This seems like a good idea to me, since it brings a Core instance's view of the pending transactions closer to the true set that exist.

These "data carrier" transactions are not relevant to Bitcoin's use as a currency, and with respect to Bitcoin's use as a currency, are spam. However, the protocol allows them and so they must be taken into account. If the validity of these non-financial transactions is considered a bug, then IMO fixing that bug is a separate issue from providing the best fee estimation.

I would add, transaction fees are not the only incentive that miners have. If mining "spam" lowers Bitcoin's value, then miners are incentivized to mine other transactions. I think they're incentivized to mine the transactions that give them the most spendable value, not strictly those that give them the most Bitcoin.

tldr; ACK

BitcoinMechanic:

There is a big difference between a filter being annoying enough that you choose to use unspendable outputs instead of OP_Return, and a filter annoying enough that you just give up on your project with millions of dollars of funding.

BitVM being a good example: even though their oversized transactions cost on the order of $15k to get mined, and aren't standard, BitVM use-cases were able to negotiate deals with miners to mine these non-standard, oversized transactions.

Bitcoin Core is not in a position to stop use cases with that kind of demand through mere "filters".

And frankly, taken charitably, this seems to be what this debate is really about: you and others agree that removing the OP_Return limits will just allow some UTXO-using use-cases to migrate to OP_Return instead; this pull-req is not a significant change. But you don't want to give up even one inch, because your real goal is to add "filters" to Bitcoin Core that will block many more transaction types with real economic demand.

Bitcoin Core has clearly decided not to go down that path: https://bitcoincore.org/en/2025/06/06/relay-statement/

All I can suggest is that Knots is welcome to try something different. But we both know that Knots isn't going to be effective at preventing transactions from being mined even if it gets, say, 50% of nodes and 25% of hash power. You need Bitcoin Core on board to have any chance of success; Bitcoin Core doesn't want to further centralize mining by wrecking the profitability of the P2P transaction relay network.

On June 7, 2025 8:57:00 PM GMT+02:00, BitcoinMechanic @.***> wrote:

BitcoinMechanic left a comment (bitcoin/bitcoin#32406)

BitcoinMdchanic: As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead. Obviously we are hoping for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs. Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return. … On June 7, 2025 1:00:38 AM GMT+02:00, BitcoinMechanic @.***> wrote: BitcoinMechanic left a comment (bitcoin/bitcoin#32406) Hi @darosier nowhere in your comprehensive rebuttal do you mention that >99% of OP RETURNs in the chain fit within the limit imposed by the existing filter That is despite the fact that people are deliberately trying to demonstrate how "useless" filters are by going out of band to get miners to manually add this stuff to their block templates. It's very simple: before you merge this PR, most OP RETURNs will be limited to 80 bytes or less. If it gets merged, there will be a massive increase in OP RETURNs larger than that. Magically everyone in Bitcoin Core has managed to get cause and effect the wrong way around.

Yes, I'm well aware of the rationalization here.

As long as it continues to ignore the implication - that if a filter is annoying enough to prevent > 80 byte ORs then it can be just as annoying to witness abuse too - then you don't have a serious discussion about mitigation of harmful effects of non-monetary use of Bitcoin. Rather, it's a farce in which "discussion" is just cherry picking in service of an agenda to facilitate more of it.

@petertodd

filter annoying enough that you just give up

They don't need to give up, they can pivot to something less annoying or to another chain. Which is what you're assuming they will do if the PR gets merged

BitVM use-cases were able to negotiate deals

I was already fully aware that filters cause spammers to have to go to these additional lengths, you don't need to keep convincing me and it doesn't in any way justify nodes helping them out.

Bitcoin Core is not in a position to stop use cases with that kind of demand through mere "filters"

Just an obvious lie. If they weren't explain TRUC.

what this debate is really about

Yes, you optimize for monetary use or you optimize for non-monetary use. Relaying OP RETURNs 1000x the size we do now is the latter. Claims about saving the UTXO set put in any real context aren't serious due to lazy attitudes about spam causing it to triple in the last 2 years. If you care about UTXO bloat, you filter inscriptions, you don't blow up datacarriersize in the hopes that a few BitVM fail-cases use OP RETURN instead of fake pub keys resulting in a few kb a year more bloat than the 8GB that have been added due to inscriptions.

this pull-req is not a significant change

Then why not close the PR as controversial as per #28408 ?

All that's being done by ramming this through is making it impossible to deny some hidden agenda.

Knots

Thanks for the advice. I'd rather Core change course and stop undermining the network by forcing through changes so widely detested in service of turning nodes into free relay services for miners wanting to fill the chain up with trash.

@petertodd worse, the opposition can't even keep a coherent message about what they're in favor of censoring. They claim non-financial transactions but then go on and on about wanting to block citria or bitvm which are indisputably transactions transferring bitcoin value and not mere collateral use. And certainly not spam in any traditional sense as the parties to the transaction are eagerly consenting.

This seems to always be the trajectory of censors in traditional system were access could always be overridden by the admin based on his judgment call weighing principle against other concerns, or at the behest of his superiors.

Who knows if any of it is good (... after all, most ideas are trash. :P), but one of the major reasons for Bitcoin existing is that no one gets to pass that kind of judgement. If Bitcoin itself needed someone's permission to exist it never would have. Bitcoin takes advantage of the nature of information being easy to spread and hard to stifle.

Censors protest "it's not censorship to block spam". It's an appealing argument on the surface, but only until you realize that the next step is to just define everything they don't like or don't understand as "spam" or whatever other quality that they've rationalized blocking (in one recent discussion on this subject my counterpart instantly lost the debate by accusing me of being in favor of child-abuse photos! think of the children: block transactions!). That inevitability is why Bitcoin was designed to take away, or at least radically diminish, that judgement in the first place. And that's not even going into the shortsightedness of making yourself responsible for the conduct of others.

When John Gilmore wrote "The Net interprets censorship as damage and routes around it", it was more aspirational than true. But we substantially made it true in Bitcoin and I'm happy to see that the Bitcoin Core project working to preserve and expand that accomplishment including in this otherwise pretty unremarkable PR.

@gmaxwell It doesn't matter who wrote what quote about internet, Bitcoin onchain can't sustain prolonged micropayments/spam. May be instead of writing essays go check out the chainstate db, it's full of dust outputs that may never get consolidated. Only solution you've to that is some form of roundabout technical solution that will increase trust in the system to remediate future IBD bottlenecks.

@nsvrn to whatever extent larger OP_RETURNS (the subject of this PR!) are used, they will speed up IBD-- because they avoid putting data in the chainstate database, because they are less weight dense so effectively reduce the size of blocks when used, and because they require very little processing compared to other transaction data that would otherwise be in their place.

@gmaxwell then ask John Gilmore to fix the inscription bug and come back with a solution because this PR isn't one and it changes nothing other than encouraging more micropyament uses that are not necessary for Bitcoin onchain regardless of these outputs are spendable or not. Let's not forget the history of OP_RETURN, from v0.9 when it was made standard(and was made clear that it's not an endorsement to store arbitrary data) and later increased to 80 bytes by a colored coin advocate, that is more than enough to store hashes.

@gmaxwell

@nsvrn to whatever extent larger OP_RETURNS (the subject of this PR!) are used, they will speed up IBD-- because they avoid putting data in the chainstate database, because they are less weight dense so effectively reduce the size of blocks when used, and because they require very little processing compared to other transaction data that would otherwise be in their place.

This is a major flaw in the reasoning in support of this pr. Claiming IBD speed will go up due to this change means that you are assuming that data going in op_return will be data that would have been put somewhere else. You can't guarantee that.

The opposite is just as likely. The levels of data being stored in other ways could remain the same while completely new uses for a bigger op return emerge.

Then you just have more bloat.

@AMoynahan89 you misunderstand my comment. It's not likely to see significant usage, but if it did it would the usage would either move fake outputs to opreturn thus improving UTXO set effects or it would be displacing other usage which would make blocks smaller, because OP_RETURN is 100% non-witness data it counts for more weight than typical transactions.

It's like how if you have a bag which is normally filled with mostly rubber ducks and limited to 4 kg and you add some ball bearings while keeping the same weight constraint the bag with some ball bearings will have lower volume than a bag with smaller amount.

The opposite is just as likely. The levels of data being stored in other ways could remain the same while completely new uses for a bigger op return emerge.

The block weight is limited, so op_return (being denser than typical transactions) will reduce block sizes or have no effect.

This is a major flaw in the reasoning in support of this pr.

No one here, my self included has advanced this as a reasons for the PR. I was responding to someone complaining of IBD bottlenecks and pointed out that the actual use of op_return itself won't make IBD worse-- since its the easiest thing that can go in blocks IBD wise it could even make it better by displacing other things that are IBD-worse. It's not a reason for this PR because it's unlikely for the usage to be significant enough to matter. (Also making IBD faster at the expense of fewer transactions is mostly the position advanced by Luke-jr who wants to reduce blocks to 300kb still and certainly not myself)

@gmaxwell then start to learn to stay on topic, this PR is also not about internet or John Gilmore. Next thing we know someone comes up with a "use-case" for a 4MB tx(in fact ppl have) and they would like do it in less harmful way(unspendable) else they will do it in witness, will you start making changes to Bitcoin to accomodate that or censor their use case? because lifting cap on op_return won't satiate that demand at all.

Concept ACK

After weighing the technical arguments for/against this change and considering the objections [0], I believe this is ready for merge. Below is my handwritten summary outlining why I think so. I’m including (non-exhaustive list of) links where possible, so if you’d like to analyze the same sources without my personal bias, please do.

The concept was discussed here, #32359, #28130, #32381, the mailing list / google group [1], delving [2][3][4], stacker news [5], twitter, etc.

The primary motivation for this PR is to correct a mismatch between the harmfulness and standardness of data storage techniques. It makes the (prunable) OP_RETURN option available so that data is not stuffed into unprunable outputs. While proponents of the PR aren’t enthusiastic about data storage as a use case, the existing standard methods (e.g. bare pubkeys) involve bloating the UTXO set, representing a long term cost to the network. This concern is not merely theoretical, as there are examples of designs and transactions that utilize the more harmful techniques [1].

Another motivation is to support Bitcoin’s public, decentralized market for blockspace, by not making transaction relay policy stricter than what is reliably mined [14]. The OP_RETURN limits are among very few policy rules that exist solely to discourage use. These restrictions push people - e.g. ones who don’t want to bloat the UTXO set - towards direct-to-miner submission, which harms mempool utility and creates centralization pressure. This is consistent with the rationale to change the default value of -mempoolfullrbf to 1.

To elaborate, the PR helps avoid a world in which an economically relevant volume of transactions is sent using direct submission. We move closer to that world when large economic actors (L2s, exchanges, etc.) choose to build direct relationships with large miners in order to get nonstandard transactions mined. If widely used, central submission services undermine the permissionless design of PoW-based consensus, hurt the censorship resistance and privacy of transaction broadcast, and destroy the fast block propagation our network has enjoyed for many years… all while not preventing the nonstandard transactions we dislike. Such services exist and are in use today; it is worth trying to reduce reasons to use them. [6][7]

These are strong motivations to change the default. I also believe all of the objections have been adequately addressed [0]. Summarized below:

(1) Some users want options to control what kinds of data-carrying transactions they allow on their nodes.

This PR, replacing #32359, doesn’t remove the -datacarrier or -datacarriersize options. Contrary to what many are saying, the PR does not force the user to accept larger datacarrier transactions in transaction relay. Setting -datacarrier=0 still turns it off, and -datacarriersize=83 gives you the original default (the same amount of data but across 1 or more outputs).

Some developers still believe the option should be removed, but there is consensus for waiting at least 1 release like we did for -mempoolfullrbf. No timeline is set for removal.

The options are deprecated in this PR, meaning they remain usable without any extra steps, but are discouraged through a warning message. This discouragement comes from the development philosophy that all user options should either come with clear recommendations for how to use them or, if no recommendation can be made, they should not exist or be discouraged. In essence, “don’t offer users footguns”. It seems that not all frequent contributors agree with this philosophy, but I think the conversation can be deferred until there is a proposal for removal of the option.

(2) Disapproval of the “arbitrary data storage use case” on the Bitcoin network (there are many many tweets that I am not linking here, but yes I did see them) [11][12][13]

(2a) Belief that Bitcoin Core default policy should be used to prevent certain kinds of use cases.

It is not possible for Bitcoin Core to prevent certain kinds of transactions from being mined. It is software run only voluntarily by users (which may include miners). Demanding that Bitcoin Core prevent certain transactions from being mined reflects a misunderstanding of the relationship between open source software users and developers.

In earlier years, mempool policy helped shape wallet behavior proactively when miner and user software was more homogeneous. Once transactions are regularly mined, restrictive policy has the effect of blinding nodes to transactions that are later included in blocks. This rationale was used to change the default of -mempoolfullrbf in #30493.

(2b) Even if Bitcoin Core cannot prevent certain use cases, it should still not relay transactions that are not in service of its monetary purpose to discourage them.

First, there is nontrivial harm in blinding a node to transactions that are likely to be mined, as described above.

Other Bitcoin clients consider filtering non-monetary uses of Bitcoin in transaction relay as one of their development priorities, which is their prerogative. Some people have also opened pull requests to “fix the filters” within Bitcoin Core (e.g. #28408, #29520, #29187).

The reactions to these pull requests did show that, in general, using mempool policy to “filter” transactions is controversial amongst contributors.

Briefly summarized: these kinds of policy rules are impossible to implement comprehensively, are not appropriate for protocol-level code, and cannot compete with economic demand. The “spam” applications operate on hype cycles and can change storage methods instantly; policy changes take at least 6 months to be deployed and even longer to be widely adopted (if they are at all). Ultimately, people who work on Bitcoin to enable censorship resistant payments likely don’t want to work on code that judges transactions based on their use case.

While Bitcoin Core aims to have no central authority directing it, the project’s direction is decided by its contributors, and the vast majority of them don’t seem to hold this priority. [14].

Similarly, another Bitcoin client could focus on hyper-optimizing for performance on specific hardware and drop support for others; Bitcoin Core’s contributors might not pursue that due to their priority of making node running highly accessible. Another project might prioritize rapid response to security vulnerabilities and build in auto-updates; Bitcoin Core’s contributors would likely reject this kind of developer-user relationship. (There aren’t collective statements about these beliefs, I’m just giving examples that I personally think are plausible).

(2c) Concerns that this encourages more arbitrary data storage, either because it is made cheaper, standardness represents what is “kosher,” or there is an ulterior motive to purposefully enable it. “The filters work, so don’t remove them.”

The purpose of this PR is not to encourage people to flood blocks with OP_RETURNs, just as changing the default of -mempoolfullrbf to 1 was not a signal that people should try to cheat zeroconf merchants. The commentary across all platforms is overwhelmingly in favor of Bitcoin’s monetary use case, even amongst those who think that arbitrary data storage is useful. Software users should look for projects whose developers demonstrate commitment to the monetary use case through their work, not through social media virtue signaling.

The on-chain cost has not changed. OP_RETURNs are more expensive than non-Bitcoin perpetual storage methods. Within Bitcoin, OP_RETURNs cost proportionally more than typical payments that benefit from the witness discount. While it is true that the (small) additional cost of using private mempool services may be saved, as summarized above, it is important that miners don’t make significant extra money from mining these transactions.

(3) Belief that large OP_RETURNs are spam, harmful, abusive, or dangerous to the network and should be discouraged in transaction relay on those grounds [15].

There are categories of transactions that policies should discourage: upgradeable fields, security and DoS problems, and transactions that make it too difficult to assess incentive compatibility [16][17]. OP_RETURN isn’t expensive to validate, doesn’t impact incentive compatibility assessment, has no potential for UTXO set pollution, etc. which is why it does not meet these criteria. Instead, people seem to use the term “spam” as an inaccurate name for undesirable transactions [18].

The introduction of the limits was indeed intended to protect network resources at a time when these outputs were not prunable, blocks were mostly empty, and 1sat/vB was almost free [19]. Contrast that with today’s environment, where prunable outputs represent a relatively low cost to the network and there exists a substantial economic deterrent to filling blocks with OP_RETURNs.

One significant cost to Bitcoin is reputational (many of us dislike the association with popular uses of OP_RETURN). But this is far outweighed by other goals like compact block reconstruction and mempool utility.

(4) Consideration for the approach of only raising the limit slightly, for example to the threshold at which OP_RETURN becomes more expensive than inscriptions [20][21].

Going back to the primary principle of not restricting policy further than what miners are confirming (unless there is another reason like DoS), a small increase would not achieve this PR’s intended purpose [22].

[0] https://datatracker.ietf.org/doc/html/rfc7282#page-7 [1] https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/mJyek28lDAAJ [2] https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697 [3] https://delvingbitcoin.org/t/op-return-limits-pros-and-cons/1645/6 [4] https://delvingbitcoin.org/t/a-comprehensive-op-return-limits-q-a-resource-to-combat-misinformation/1689 [5] https://stacker.news/items/971277 [6] https://x.com/mononautical/status/1920221641948246081 [7] https://x.com/oomahq/status/1930401993341776173 [8] https://stacker.news/items/971277?commentId=971285 [9] https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697#p-5007-the-datacarrier-option-should-be-kept-on-bitcoin-core-regardless-of-whether-the-default-is-changed-26 [10] https://x.com/GrassFedBitcoin/status/1921219038430015758 [11] https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/-QPhqSMwEQAJ [12] https://x.com/wk057/status/1917235710781690171 [13] https://x.com/GrassFedBitcoin/status/1921219038430015758 [14] https://bitcoincore.org/en/2025/06/06/relay-statement/ [15] https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/yoSAe-aaDgAJ [16] https://bitcoinops.org/en/blog/waiting-for-confirmation/#policy-for-protection-of-node-resources [17] https://bitcoinops.org/en/blog/waiting-for-confirmation/#network-resources [18] https://delvingbitcoin.org/t/the-spam-problem-of-bitcoin-and-unpermissioned-broadcast-networks-in-general/1692/2 [19] https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/GRKe8kq-EgAJ [20] https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/6PYyNG6UAQAJ [21] https://bitcoin.stackexchange.com/questions/122321/when-is-op-return-cheaper-than-op-false-op-if [22] https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/lP69f0KaAQAJ

Thank you to sipa for helping review this.

There was no clear consensus on this, and therefore should have been never merged ! This action will set in motion a movement against this project. Well done, you just destroy your reputation ! Bravo

This is a disgraceful precedent. There is no consensus for this change. It is clear that the maintainers of this repo have been corrupted. We will leave no stone unturned in getting to the bottom of this. We will discover the truth and take appropriate action.

I don't think people understand that this is by default. You can still just set your own limits in your config. If you disagree, you can just change it on your nodes.

This was technically the correct thing to do, even if all the bots on X said otherwise. This whole thing should've been a big nothingburger. Most of you all commenting on the issue aren't understanding the effect of the changes at all. Mob behaviour towards devs should not be tolerated.

I don't think people understand that this is by default. You can still just set your own limits in your config. If you disagree, you can just change it on your nodes.

This was technically the correct thing to do, even if all the bots on X said otherwise. This whole thing should've been a big nothingburger. Most of you all commenting on the issue aren't understanding the effect of the changes at all. Mob behaviour towards devs should not be tolerated.

The real change was allowing multiple OP_RETURNs in a single transaction, this change was made surreptitiously. The net effect of these, and related changes, is to slowly turn Bitcoin from a monetary network to a non-monetary network.

this change was made surreptitiously

It's described in the first line of the pull-request, and its the whole subject of the second paragraph along with the reason it works that way. It's about half the total text of the pull-request message.

No one here, including you, has raised any specific issue with it.

I don't think people understand that this is by default. You can still just set your own limits in your config. If you disagree, you can just change it on your nodes.

This was technically the correct thing to do, even if all the bots on X said otherwise. This whole thing should've been a big nothingburger. Most of you all commenting on the issue aren't understanding the effect of the changes at all. Mob behaviour towards devs should not be tolerated.

It's on Core to have sane defaults for obvious reasons. Saying "you can change it!" or "it's open source, go run something else!" is a lame excuse that immediately sounds a loud alarm that the maintainers of this project don't understand the responsibility they have.

Also - referring to those who disagree with you as "twitter bots" or - as @glozow continually does (even in formal statements) that we're just using LLMs is not just frustrating and disrespectful to those who disagree with you, but makes you all look like elitist snobs.

I don't think people understand that this is by default. You can still just set your own limits in your config. If you disagree, you can just change it on your nodes. This was technically the correct thing to do, even if all the bots on X said otherwise. This whole thing should've been a big nothingburger. Most of you all commenting on the issue aren't understanding the effect of the changes at all. Mob behaviour towards devs should not be tolerated.

It's on Core to have sane defaults for obvious reasons. Saying "you can change it!" or "it's open source, go run something else!" is a lame excuse that immediately sounds a loud alarm that the maintainers of this project don't understand the responsibility they have.

Also - referring to those who disagree with you as "twitter bots" or - as @glozow continually does (even in formal statements) that we're just using LLMs is not just frustrating and disrespectful to those who disagree with you, but makes you all look like elitist snobs.

So true

Also - referring to those who disagree with you as "twitter bots" or - as @glozow continually does (even in formal statements) that we're just using LLMs is not just frustrating and disrespectful to those who disagree with you, but makes you all look like elitist snobs.

Both sides have engaged in loaded language; for instance, calling consensus-valid transactions “spam.” I have likewise seen disrespect from the pro-filter camp, including personal attacks on Core developers and on anyone who supported this PR.

I'm not even sure that data carrier transactions are spam in the first place. The blockchain is an immutable structure that can store arbitrary data trustlessly - maybe block space is the product. and bitcoins are the tokens you can use to buy block space. Maybe thinking of bitcoin as a pure "currency" in the first place was wrong, and it's actually a tool for recording information immutably in the public domain.

You can architect the blockchain to be able to store data at some rate, for some fee. But you can't make it impossible to store data. Even if users couldn't store arbitrary bytes, they could use an encoding based on the number of satoshis sent to themselves or something.

So really we have to figure out how best to implement data storage. How much should users be able to store, and how expensive should it be compared with transferring bitcoins between addresses? One constraint is that it can't be made more expensive than it would be to use some encoding based on your choice of valid transactions.

Also - referring to those who disagree with you as "twitter bots" or - as @glozow continually does (even in formal statements) that we're just using LLMs is not just frustrating and disrespectful to those who disagree with you, but makes you all look like elitist snobs.

Both sides have engaged in loaded language; for instance, calling consensus-valid transactions “spam.” I have likewise seen disrespect from the pro-filter camp, including personal attacks on Core developers and on anyone who supported this PR.

Spam is always protocol-level valid on any protocol. I don't know what you are imagining "spam" to be conceptually if it must violate protocol rules as opposed to violating the intentions of those dealing with abusive-but-technically-valid usage of a protocol.

But you can't make it impossible to store data.

Of course you can. Nobody implemented it yet, but technically, it is possible.

Even if users couldn't store arbitrary bytes, they could use an encoding based on the number of satoshis sent to themselves or something.

Transactions can be compressed. Currently, to perform Initial Blockchain Download, you need to know the whole history, from 2009, up to today. But technically, there is no need to structure things in that way. If you can create equivalent proofs, that a chain of signatures was correct, then you don't have to store data behind transactions, but only proofs, that they are correct. Then, if someone can fake a proof, you can make it cryptographically equivalent to breaking ECDSA or SHA-256 in the first place, which means, that you can store less data, and reach equivalent security assumptions.

How much should users be able to store

Being able to store data forever does not scale. Sooner or later, if blockchain will be too bloated, there will be more and more nodes, working on proofs, instead of providing all historical data for everything. If users will post copyrighted materials, wrapped in Bitcoin transactions, and node runners will be sued because of that, then there will be more pruned nodes than today. And later, nodes will share more and more proofs, instead of revealing plaintext data, if the situation will require them to do so.

But technically, there is no need to structure things in that way. If you can create equivalent proofs, that a chain of signatures was correct

You aren't just validating signatures when you validate the chain.

Being able to store data forever does not scale. Sooner or later, if blockchain will be too bloated, there will be more and more nodes, working on proofs, instead of providing all historical data for everything.

Existing pruning is a better (though still non-ideal) solution.

If users will post copyrighted materials, wrapped in Bitcoin transactions, and node runners will be sued because of that

No, they won't be. There's established precedent that intent is required for criminal proceedings for storing or relaying data. I can encode information in the logs of any internet-exposed service which logs connections. The internet would be broken if I could make you criminally or civilly liable by sneaking data onto your computer.

But yes, blockspace is a limited resource. The way to mange that is to use it as efficiently as possible. There are upgrades which will enable increased efficiency for real financial transactions, like CISA, but using blockspace with maximum efficiency for transactions doesn't slow chain growth if blocks are being filled up.

As long as we allow people to abuse blockspace, until/unless anyone who wants to waste it is completely priced out (worth noting that things like batched CISA transactions could move the needle in that direction with enough demand for blockspace, while dampening the impact of increased feerate on individuals), blockspace will be wasted, and that cost will be incurred by anybody catching up in the future for all time.

For that reason, we should be taking said waste far more seriously than we are now. NFT crap is bad enough, but writing definitionally ephemeral data to blocks is a whole other level of waste.

Spam is always protocol-level valid on any protocol. I don't know what you are imagining "spam" to be conceptually if it must violate protocol rules as opposed to violating the intentions of those dealing with abusive-but-technically-valid usage of a protocol.

Sure, but spam has always referred to an unsolicited message. Using that word for Bitcoin’s mempool or consensus policy is a stretch: a transaction is only spam if nobody wants it. Once a consensus-valid transaction is included in a block, at least one participant has decided it has value, so it isn’t spam. Given miners’ incentive to collect fees, we can be pretty sure that consensus-valid transactions will eventually be mined.

Sorry if this is a dumb question, but is there a threat (which this PR having removed the cap might make easier for a random actor to actualize) of someone encoding a well-recognized virus into OP_RETURN, causing malware protection on various OS versions (for example, everyone running Core on Windows) to recognize a threat, corrupt the blockchain database, and render the node defunct? I thought about trying it on testnet, but then thought twice about the legality issues if it actually were to cause the outcome that I'd be testing for.

Once a consensus-valid transaction is included in a block, at least one participant has decided it has value, so it isn’t spam.

The same you can say about any kind of spam: if you receive unwanted e-mail, then the sender also "has decided it has value, so it isn’t spam". Running blockchain in its current design is like running an e-mail, where you have to receive and process all mails from all of your neighbours, to read your own. It is far from being scalable, and it will be re-shaped in the future, if some people will abuse it too much.

Given miners’ incentive to collect fees, we can be pretty sure that consensus-valid transactions will eventually be mined.

Mined? Of course. Confirmed? Yes. But broadcasted forever by all nodes? I am not so sure about that. When nodes will stop sharing the full history from 2009, up to today, and will focus on just proving, that the system is honest, then the incentive for spamming the chain will decrease, because users will no longer see the content of their transactions, if they won't be willing to keep them locally.

Many users, which make non-monetary transactions, don't care about fees. They don't care about coin amounts at all. They care only about pushing some on-chain data, sometimes even without having it protected with any public keys or signatures (which is also why Ordinals never cared about enforcing ownership properly, and why it is completely disconnected from sighashes, or other consensus-checked rules like that).

Which means, that when all transactions will be confirmed, but the effort required to retrieve data will be moved from nodes to users, then the network will be more resistant to spam. And solutions like that are possible to implement, but so far, people simply didn't produce enough spam, to make some developers angry enough, to force them to implement such rules.

Sorry if this is a dumb question, but is there a threat (which this PR having removed the cap might make easier for a random actor to actualize) of someone encoding a well-recognized virus into OP_RETURN, causing malware protection on various OS versions (for example, everyone running Core on Windows) to recognize a threat, corrupt the blockchain database, and render the node defunct? I thought about trying it on testnet, but then thought twice about the legality issues if it actually were to cause the outcome that I'd be testing for.

Paul raises an excellent point about the potential issues of the data that could get onto OP_RETURN. Not only the example he provides of the data could trigger a false positive in anti-virus software, but also there is the possibility of illegal data (not going to state that here obviously). But someone could put text that is illegal (in certain jurisdictions) in OP_RETURN and that data could be stored on someone's node in that jurisdiction. Obviously, this issue is going to get ignored or simply brushed off as irrelevant because the sponsors really want to get this change in regardless of any issues that might arise. However, I urge you not to discount this issue.

@lordnakamoto see #28052

This is a very old concern, is not affected by this PR and is also asked and answered on bitcoin.stackexchange.com

also https://github.com/bitcoin/bitcoin/issues/4069

@paulscode this is a fair concern, although it was addressed multiple times already (including in this very thread).

I addressed it in my writeup about community concerns as the following.

Data stored in an OP_RETURN output doesn’t need to be chunked like it does in an inscription. This presents a risk for node runners as it allows anyone to store unobfuscated data on their disk.

Onchain data is obfuscated by Bitcoin Core when stored on disk. Bitcoin Core only started doing so recently, and an existing block chain on disk will not be obfuscated when upgrading. Therefore old nodes may store unobfuscated OP_RETURN data that ends up onchain. However this is already possible at a trivial cost to an attacker: for instance as i write this post Slipstream’s feerate is 6 sats/vb so storing a 10k bytes malware file in an OP_RETURN would cost only ~$60 to an attacker (at $100k/BTC). Note this cost is the total cost, not just the premium. This total cost is also lower than it would have been if the attacker had to pay the past 5 years average feerate. Therefore this change does not materially affect this concern.

This change would however directly affect mempool data (which is also stored on disk) since a large OP_RETURN would previously not be accepted in a Bitcoin Core node’s mempool. But mempool data is now always obfuscated when stored to disk, therefore this is not an issue.

@darosior Thanks for the quick response, and the quick summary explanation (rather than pointing me to a long separate thread). I figured this may have already been considered, but wanted to make sure (and didn't want to risk testing it myself..)

Anytime.

Paul raises an excellent point about the potential issues of the data that could get onto OP_RETURN. Not only the example he provides of the data could trigger a false positive in anti-virus software, but also there is the possibility of illegal data (not going to state that here obviously). But someone could put text that is illegal (in certain jurisdictions) in OP_RETURN and that data could be stored on someone's node in that jurisdiction. Obviously, this issue is going to get ignored or simply brushed off as irrelevant because the sponsors really want to get this change in regardless of any issues that might arise. However, I urge you not to discount this issue.

The maintainers here don't care. I brought this up months ago and was told it was fine because the data is obfuscated now in recent versions. Apparently obfuscating illegal data on your system with an XOR key magically makes it perfectly ok to store and widely distribute! Who would have thought! (/sarcasm)

This PR is merged. Core devs clearly aren't unmerging it no matter what happens and what arguments are brought up at this point. So, I'm honestly surprised @glozow didn't just lock it at that time.

@wizkid057 I sure hope it is more sophisticated than in XOR key.. otherwise the obvious way around is to XOR the virus before adding it to the transaction.

@wizkid057 I sure hope it is more sophisticated than in XOR key.. otherwise the obvious way around is to XOR the virus before adding it to the transaction.

It is an XOR key, but it's unique per install.

Still, if you obfuscate something illegal on your machine... pretty sure it's still illegal.

The great thing about opreturn data is that it can be pruned. Deleted. If you are concerned about illegal data like this you should be looking for ways to disincentivize users from inserting arbitrary data permanently in the utxo set.

The great thing about opreturn data is that it can be pruned. Deleted. If you are concerned about illegal data like this you should be looking for ways to disincentivize users from inserting arbitrary data permanently in the utxo set.

So I can fully sync and validate the blockchain without ever touching this OP_RETURN data?

Can I ask nodes not to send it to me?

Can I run a full node that actually benefits the Bitcoin network in helping to relay and propagate blocks without sending the OP_RETURN data?

Can I keep the whole blockchain, prune all of the OP_RETURN data, and then other people can still fully sync and verify the blockchain from my node?

The answer to all of the above is "No."

Once the OP_RETURN data is in a block, we (as in, the network as a whole) must keep it forever in order to be able to fully validate the chain and to bootstrap others wanting to do the same.

Saying it's a non-issue because "it can be pruned" is a pretty bad and disingenuous take.

To add to the above, saying OP RETURNs can be pruned, is a lie by omitting the fact that this disables a tonne of other functions for which a person might run a node.

Most notably almost all wallet software wont connect directly to a node, requiring an intermediary Electrum server which won't work without archival data.

They aren't just "can be pruned" they are always pruned from the utxo set, they can't be put it it at all no matter how the node is configured, and no functionality is lost. This is largely unrelated to the "prune" setting, which removes all transaction data before its horizon. What's left is things in the UTXO set, which -- as mentioned OP_RETURN -- content never is and never can be.

While it's no great sin to suffer an misunderstanding, the "lie" accusation is both unprofessional and abusive and so if it's an accusation you made in error it would be polite to withdraw it. @wizkid057 the "illegal data" issue exists independently of this and isn't stopped by it and isn't stopped by the op_return limit. Particularly, since the attack is substantially a 1/0 attack rather than a question of volume and the attacker can just mine a block or use the miner bypass apis (as darosior points out above). It can be mitigated by encrypt in place in the sense that at least stops scanning (and thus completely answers the anti-virus point above), the legal question of its status appears to be unanswered in the US but there is a little positive evidence that the DOJ wouldn't prosecute (as they didn't prosecute freenet nodes that merely stored encrypted data with no functional access while in the process of prosecuting the parties that actually were requesting it). Pruning, as mentioned, elimates the storage of it on pruned nodes unless the material is in an output (which it can never be for op_return). Proposals like asstumetxo, various zkp schemes, are more complete answers but are also on a longer time horizon.

There have also been some middleground proposals which e.g. encrypt transaction data such that the user holding it cannot decrypt it themselves, while still not impeding sync. But at least I've been told that some people who sought advice on the subject were told that the local encryption and lack of any interface to go dig it up is sufficient.

Regardless, this is an issue which exists-- to the extent it does-- entirely independently of this pull request making this all rather off-topic. But I thought it relevant to mention since bystanders might not be aware, as you should be, that the issue has been extensively considered for many years.

They aren't just "can be pruned" they are always pruned from the utxo set, they can't be put it it at all no matter how the node is configured, and no functionality is lost.

I’m not sure if this is a response to Mechanic.. the two or three comments before your reply all point out the problems with a pruned node (the only way to not store op return data.) Your response was odd to say the least. op return data does not contribute to the utxo set, but it is stored permanently in the blockchain. These are two different things. And the points about a pruned node stands. So I’m not exactly sure who or what you are addressing here?

The answer to all of the above is "No."

The full answer is "not yet". People implement features, when they have enough skills to do so, or when they have no other choice. Satoshi made Bitcoin, because rules in fiat currencies made him angry enough to do that. Here, the situation is similar: nothing will be done with spam, as long as people can handle it on their machines. If nodes will start running out of resources, only then some protections will be implemented, and only by those, who will care about it. The rest of the network will use the current version, which is not resistant to spam.

Which means, that if you think, that Bitcoin will be protected globally from being spammed, then I think you are wrong. Nobody will wire that kind of code into consensus rules. Instead, people will optimize things only on their end, while keeping them compatible with the original network, and then, you will have a choice: use some implementation, which can deal with spam, or use the official one, which will process everything, and always, no matter how spammy or costly it would be.

And then, people caring about Bitcoin being money, will naturally switch to less spammy version, because they will want to transact, and not send JPEGs to other nodes. Which means, that instead of sending "here is your JPEG" message, they will send "here is a proof, that this transaction is valid" instead, and starting a new node will be possible only if you accept that proof, because such nodes will simply ignore any requests to send plaintext version, because they won't have it (also because they don't need it to be convinced, that all consensus rules are followed).

we (as in, the network as a whole) must keep it forever in order to be able to fully validate the chain and to bootstrap others wanting to do the same

Storing everything is not hard-wired into consensus rules. You have to do that, because the current implementation requires you to do so. But you can stay compatible with the current network, even if your node won't do that.

They aren't just "can be pruned" they are always pruned from the utxo set, they can't be put it it at all no matter how the node is configured, and no functionality is lost. This is largely unrelated to the "prune" setting, which removes all transaction data before its horizon. What's left is things in the UTXO set, which -- as mentioned OP_RETURN -- content never is and never can be.

While it's no great sin to suffer an misunderstanding, the "lie" accusation is both unprofessional and abusive and so if it's an accusation you made in error it would be polite to withdraw it.

@wizkid057 the "illegal data" issue exists independently of this and isn't stopped by it and isn't stopped by the op_return limit. Particularly, since the attack is substantially a 1/0 attack rather than a question of volume and the attacker can just mine a block or use the miner bypass apis (as darosior points out above). It can be mitigated by encrypt in place in the sense that at least stops scanning (and thus completely answers the anti-virus point above), the legal question of its status appears to be unanswered in the US but there is a little positive evidence that the DOJ wouldn't prosecute (as they didn't prosecute freenet nodes that merely stored encrypted data with no functional access while in the process of prosecuting the parties that actually were requesting it). Pruning, as mentioned, elimates the storage of it on pruned nodes unless the material is in an output (which it can never be for op_return). Proposals like asstumetxo, various zkp schemes, are more complete answers but are also on a longer time horizon.

There have also been some middleground proposals which e.g. encrypt transaction data such that the user holding it cannot decrypt it themselves, while still not impeding sync. But at least I've been told that some people who sought advice on the subject were told that the local encryption and lack of any interface to go dig it up is sufficient.

Regardless, this is an issue which exists-- to the extent it does-- entirely independently of this pull request making this all rather off-topic. But I thought it relevant to mention since bystanders might not be aware, as you should be, that the issue has been extensively considered for many years.

Completely misses the fact that this PR lowers the barrier to entry for such garbage infinitely, but again, that doesn't seem to matter to anyone here along with any of the other adverse issues causes by this PR.

Still confused as to why this thread isn't locked.

Completely misses the fact that this PR lowers the barrier to entry for such garbage infinitely, but again, that doesn't seem to matter to anyone here along with any of the other adverse issues causes by this PR.

gmaxwell made a great point earlier in this thread, which has been repeated in Antoine's post that the entry barrier for garbage is already lower in witness data -- it's 1/4 the cost of an opreturn and my guess is, the jpegs will continue to live in the cheap data. The projects that were using (or planning on using) unspendable tx outs were bitcoin rollups with the goal of increasing bitcoin transaction throughput with novel off-chain protocols.

Still confused as to why this thread isn't locked.

Anyone is free to mute the thread, I imagine contributors that were only participating for code review and not conceptual discussion have done so. There's no need to lock it as long as users are still discussing the issue -- clearly there needs to be more places where, for lack of better categories, "users" and "developers" can directly interact.

the entry barrier for garbage is already lower in witness data -- it's 1/4 the cost of an opreturn and my guess is, the jpegs will continue to live in the cheap data

Assuming we're not prepared to filter it. Filtering it would work fantastically of course given that fact that < 1% of OP RETURNs manage to make their way around the filter this PR is haphazardly removing.

Just worth pointing out that everything being done in this repo is not because you can't mitigate spam using mempool filters, it's because the majority of contributors do not wish to mitigate spam.

While it's no great sin to suffer an misunderstanding, the "lie" accusation is both unprofessional and abusive and so if it's an accusation you made in error it would be polite to withdraw it.

Happy to withdraw this by the way as I wasn't aware of the double-usage of the term "pruned" in Bitcoin.

There is some miscommunication happening here that I think is worth clearing up.

The first thing to mention is that the word "prune" has two completely different meanings in bitcoind. One refers to pruning data from the chainstate database (utxoset) and the other refers to pruning blocks from the block database.

This has been an endless source of confusion when discussing this project and I wish we could just come up with different ways to talk about these things.

Normally, when discussing OP_RETURN, we are referring to the former type of pruning, where data does not need to be stored in the utxoset.

However, I was surprised to see @pinheadmz suggest that users can simply do the latter type of pruning (block pruning) in order not to have to store OP_RETURN data forever:

The great thing about opreturn data is that it can be pruned. Deleted.

If I understand this claim correctly, he is saying that users who don't want to store OP_RETURN data can simply run a pruned node (i.e. delete old blocks) in order to avoid storing it forever.

This suggestion beggars belief. I'm wondering if @pinheadmz has actually ever attempted to run a pruned node with a Lightning node or with Sparrow Wallet, or if he simply uses bitcoin-qt and nothing else.

Pruned nodes are notoriously difficult to do anything useful with, unless you are simply running bitcoin as a standalone desktop application (which is not very useful), and not trying to run an electrum server, a Lightning node, or a block explorer on top. Also, it is worth mentioning that pruning should generally be discouraged because pruned nodes are useless for helping new nodes bootstrap, and thus the higher the proportion of the network that prunes, the more centralized bitcoin's blockchain storage becomes. @BitcoinMechanic was correct to point out the rather absurd nature of this suggestion:

To add to the above, saying OP RETURNs can be pruned, is a lie by omitting the fact that this disables a tonne of other functions for which a person might run a node.

Most notably almost all wallet software wont connect directly to a node, requiring an intermediary Electrum server which won't work without archival data. @gmaxwell then jumped in to correct Mechanic:

They aren't just "can be pruned" they are always pruned from the utxo set, they can't be put it it at all no matter how the node is configured, and no functionality is lost. This is largely unrelated to the "prune" setting, which removes all transaction data before its horizon. What's left is things in the UTXO set, which -- as mentioned OP_RETURN -- content never is and never can be.

While it's no great sin to suffer an misunderstanding, the "lie" accusation is both unprofessional and abusive and so if it's an accusation you made in error it would be polite to withdraw it.

I don't think Greg realized that @BitcoinMechanic was responding to the "block pruning" suggestion from @pinheadmz, which, to be fair to Greg, I didn't realize either at first glance. I assumed that @BitcoinMechanic was referring to the "utxoset pruning" feature of OP_RETURN, which is the "pruning" most commonly meant in an OP_RETURN context.

It would be unfair to call someone a liar for saying "OP_RETURN data is pruned", since this is actually correct for utxoset pruning, though it would completely be fair to say that the suggestion is misleading, since it makes it sound like you can simply delete OP_RETURN data entirely after validating, never mind "pruning" it from the utxoset. This is (partly) the objection that @wizkid057 raised.

In this case @pinheadmz is neither being a liar nor misleading, since he is not even talking about utxoset pruning. He is talking about pruning blocks in order to avoid storing OP_RETURN data, which is just... kind of absurd.

I suspect that one reason for the growing divide between the users of this software and its maintainers is that users have pivoted to running entire stacks of bitcoin services on top of their bitcoind's rpc (and sometimes peer, as with btcpay) interface, while many core contributors appear to still just be running bitcoind or bitcoin-qt as a standalone app.

This evolution has been propelled by the popularity of "easy self-hosted Bitcoin/Lightning node" software packages such as Start9, Umbrel, and Raspiblitz. Pruned nodes are very difficult to use for these server systems, because they just don't seem to be designed with downstream applications in mind. There has recently been some encouraging movement towards improving this, but the state of pruned nodes is really not such that "just run a pruned node" is a realistic suggestion for most users. In this context I think one can at least understand where Mechanic was coming from with his "lie by omission" statement, though that may have been a bit over the top.

You can run a lightning node with a pruned backend, LND has supported this since version 0.13.

As far as what data a user can delete, conceptually, and without using the word "prune", what I meant is precisely this: The most minimal purpose of a full node is to provide the user with confidence that money they receive will be accepted by other users in the future for their own payments. That confidence is represented as a number of confirmations on payments received by the user. This function requires at a bare minimum: the header chain and the utxo set.

There is one exception to this which is the storage of "undo data" which is needed to rewind a portion of the blockchain during a reorg. Pruned nodes today store a minimum of 288 blocks of undo data which means that if there were ever a chain reorg deeper than that (in addition to the epic implications of such an event!) all those pruning nodes would instantly be bricked.

Bitcoin Core has more options than any other piece of software I've ever used. It's insane how many use cases it can accommodate. If you are running a node in a jurisdiction where even storing a specific 16 byte number is against the law you'd probably need to at least run a pruning node to reduce the opportunity for such a 16-byte number to end up on your machine. You could still send and receive bitcoin payments!

If you are trying to run a block explorer with a tx index and address index and compact block filter index and cool bells and whistles like that... you're going to need to make sure you run that node in a jurisdiction that will not prosecute you if someone on the internet sends your machine an illegal number.

If some government out there decides that 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f is an illegal number we are all going to have a bad time.

@pinheadmz:

Yes, I am aware that LND claims to be usable with a pruned node. When I worked at Start9 we enabled this functionality briefly before turning it off again because it was too unreliable (compared to running the S9 fork of btc-rpc-proxy, which has the same fetch-old-blocks-from-peers functionality). It's possible that this has been improved since then, but I'm curious if you yourself or anyone you know has tried it. It's one thing to say "using a pruned node for a shop is possible", but a completely different thing for someone to actually do it, especially someone non-technical.

In my personal experience, it is the exception rather than the rule for bitcoin and lightning devs to actually have even a small shop they run on top of their node to sell stuff for bitcoin.

As a side note, Core Lightning does not support pruning in an ergonomic way, and LND does not support bolt12, dual funding, or splicing. So either way you are making compromises if you choose to prune.

The most minimal purpose of a full node is to provide the user with confidence that money they receive will be accepted by other users in the future for their own payments. That confidence is represented as a number of confirmations on payments received by the user. This function requires at a bare minimum: the header chain and the utxo set.

Yes, and my point in my previous comment is, your suggestion to "run a pruned node if you don't want to store opreturns" is the same thing as saying "run a bare minimum node if you don't like storing opreturns". Don't you see how that might come off as a bit... presumptuous?

My larger point is, of course, that IMO a "bare minimum bitcoin node" is not the use case that this project should be targeting. The use case bitcoin core should be targeting is the merchant use case, as this is the most effective way to incentivize better node decentralization and make bitcoin a better medium of exchange.

Back before full blocks and Lightning, it was possible to run just a regular bitcoin node (even pruned!) as a merchant. But now that the blocks are usually full, accepting on-chain bitcoin at a shop is absolutely nonviable (to be honest it was never viable anyway because you either needed to accept zeroconf, which is insecure, or wait for at least one confirmation, which is a terrible UX).

And running a Lightning node is much more difficult than running just an L1 node. But it needs to be as easy as we can make it, otherwise people will not use bitcoin as a medium of exchange, and being simultaneously a good store of value and a good medium of exchange is what sets bitcoin apart from all other money in history. And again, we need merchant nodes so that node runners can continue to be a counterweight to the miners in the consensus process.