Reduced Data Temporary Softfork

dathonohm commented at 9:28 pm on October 24, 2025: none

Due to Bitcoin Core v30 gaining in popularity, it has become necessary to move forward on @luke-jr’s ML proposal to temporarily limit arbitrary data at the consensus level, which so far has 3 weeks with no objections.

Implementation for the “proactive deployment” is under construction, while the “reactive deployment” is feature complete but lacks tests.

Mailing list thread at https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8

Editor note: please post conceptual feedback and meta-commentary on the mailing list thread, and focus here on:

expert technical review of the specification
specific, concrete, helpful proposals for the other sections

(Please refrain from personal or heated commentary, pedantry, and repeating yourself in both venues.)

jonatack added the label New BIP on Oct 24, 2025

in bip-????.mediawiki:187 in 53146356ea outdated

182+
183+===Proactive Deployment===
184+
185+TODO
186+
187+===Reactive Deployment===

jonatack commented at 1:28 am on October 25, 2025:

It’s not clear to me why have these two headers, Proactive Deployment and Reactive Deployment, both here under Activation and below under Deployment.

dathonohm commented at 1:44 am on October 25, 2025:

There is a “rationale” section here, which is more of an FAQ, and a “deployment” section below, which seems customary on softfork bips. I could consolidate these if you like.

in bip-????.mediawiki:219 in 53146356ea

214+'''What is the expected impact on exchanges and other businesses, and how can they prepare?'''
215+
216+Depending on how quickly miners adopt this softfork, there is potential for significant disruption in the short-term.
217+Any econonomic node that continues to process deposits or payments should consider the risk of reversals or double-spending until the situation has fully resolved.
218+
219+The standard, industry-wide security procedure for any chain split event is to temporarily disable deposits and withdrawls until a single, stable chain has been decisively established with significant proof-of-work.

jonatack commented at 1:29 am on October 25, 2025:

0The standard, industry-wide security procedure for any chain split event is to temporarily disable deposits and withdrawals until a single, stable chain has been decisively established with significant proof-of-work.

Edit: will update the spelling linter for the other two false negatives.

dathonohm commented at 2:59 am on October 25, 2025:

Done

in bip-????.mediawiki:17 in 53146356ea

12+  Post-History: https://gnusha.org/pi/bitcoindev/aN_u-xB2ogn2D834@erisian.com.au/T/#mb71350c5dfb119efeb92c5ee738b6c8225bf15b6
13+</pre>
14+
15+==Abstract==
16+
17+Data fields are size-limited at the consensus level temporarily.

jonatack commented at 1:30 am on October 25, 2025:

0Temporarily limit the size of data fields at the consensus level.

dathonohm commented at 2:59 am on October 25, 2025:

Done

Reduced Data Temporary Softfork 3c71823707

dathonohm force-pushed on Oct 25, 2025

rot13maxi commented at 1:08 pm on October 25, 2025: none

I suggest you add an FAQ item for “why block 987424“. If the intent is to have it be a year out, the height might actually move during discussion, and right now its just a magic number in the document.

dathonohm commented at 3:16 pm on October 25, 2025: none

@rot13maxi see the deployment section

portlandhodl commented at 6:29 pm on October 25, 2025: contributor

There is opportunity to also discuss the effect on DoS blocks and the scope of legacy script as a DoS vector.

danielsam commented at 1:28 am on October 26, 2025: none

.

in bip-????.mediawiki:42 in 3c71823707

37+The recent release of Bitcoin Core 30 presents a severe threat to Bitcoin's viability.
38+By formally standardizing rules for large-scale data storage (ie, 100kB OP_RETURNs), it proposes to redefine this behavior from an abuse of the system into a supported use case.
39+The true danger lies not merely in the release existing, but in its adoption.
40+The adoption of this release, even if by a minority of users, risks establishing this harmful redefinition as a new de facto standard for the entire network.
41+
42+This official sanction creates an immediate and severe threat.

jlopp commented at 3:33 am on October 26, 2025:

I suspect many would disagree that there is any such thing as an “official sanction” given that there are no authorities on the Bitcoin network.

BlakeJones9449 commented at 4:23 am on October 26, 2025:

Change of default relay policy settings in the super-majority node client as sanctioned by the official policy maintainer can easily be seen as an official sanction.

jlopp commented at 4:40 am on October 26, 2025:

What makes it “official” - some node clients like libbitcoin don’t even have such policies. Is is not official from them because they have little adoption?

If it’s the level of adoption that makes something official, consider that adoption is voluntary and opt-in, thus the “sanctioning” comes from many independent actors deciding to run the code that enforces said policies.

BlakeJones9449 commented at 5:35 am on October 26, 2025:

100kb OP_RETURN is officially sanctioned by Bitcoin Core with the release of v30 as evidenced by their changing of default settings and accompanying release notes.

BitcoinMechanic commented at 7:36 am on October 26, 2025:

Yes, an “official sanction” is thus (fairly awkwardly) defined as “The default standardness policies of the node software run by the vast majority of the network.”

Simply, if there is relatively little adoption of Core 30 then what it has attempted to invite into mempools/the blockchain are not representative of Bitcoin.

arejula27 commented at 2:02 pm on October 26, 2025:

Yes, an “official sanction” is thus (fairly awkwardly) defined as “The default standardness policies of the node software run by the vast majority of the network.”

At what moment? If the policies of the core 30 are the standard in 6 months, then this proposal would be outdated. Should we modify the consensus again, cuz the policies have changed?

ModusB commented at 4:23 pm on October 26, 2025:

“The default standardness policies of the node software run by the vast majority of the network.”

Should this verbiage be added into the BIP, for clarity?

BitcoinMechanic commented at 5:54 pm on October 26, 2025:

Yes, an “official sanction” is thus (fairly awkwardly) defined as “The default standardness policies of the node software run by the vast majority of the network.”

At what moment? If the policies of the core 30 are the standard in 6 months, then this proposal would be outdated. Should we modify the consensus again, cuz the policies have changed?

No? This proposal is basically working with the assumption that that is what will happen.

arejula27 commented at 6:02 pm on October 26, 2025:

You define standardness based on the current policy and propose a consensus change to match it. But if the definition of standardness changes later, why shouldn’t the consensus rules be changed again?

dathonohm commented at 8:02 pm on October 26, 2025:

Within the consensus rules, it is true that there are no authorities.

However, Bitcoin Core has been seen as an authority since the very beginning, and if it officially sanctions data storage as a supported function of the blockchain, and if such data storage is allowed at the consensus level, then it’s difficult to make the case that it’s not a supported use case, and this massively increases liability for those running Bitcoin nodes, for absolutely no benefit.

The best way to call the authority of Bitcoin Core 30 into question is to move quickly to explicitly softfork in order to distance ourselves as much as possible from the data storage use case. This BIP, just by its very existence, accomplishes this. But we must follow through with activation if we want the world to take us seriously when we say Bitcoin is not for data storage.

I doubt a court of law would accept the argument that a node runner storing and distributing abhorrent content is somehow not liable because “there are no authorities on the Bitcoin network”. The node runner him- or herself needs to have a credible claim to not intending to perform such activity.

Fully supporting this BIP, publicly, could even make a difference.

arejula27 commented at 8:20 pm on October 26, 2025:

Knots has spent the past year defending policy-level filters, which makes it seem contradictory that they’re now proposing to alter the consensus rules. If policy is what truly matters and not enough people choose to run their policy, that suggests they don’t have sufficient pleb support. Trying to force a soft fork by convincing miners instead of users doesn’t seem consistent with following pleb community feeling

in bip-????.mediawiki:44 in 3c71823707

39+The true danger lies not merely in the release existing, but in its adoption.
40+The adoption of this release, even if by a minority of users, risks establishing this harmful redefinition as a new de facto standard for the entire network.
41+
42+This official sanction creates an immediate and severe threat.
43+The threat here is distinct from general spam or economic costs, which are typically handled with policy and the fee market.
44+It allows a malicious actor to mine a single transaction with illegal or universally abhorrent content and credibly claim that Bitcoin itself is a system for distributing it, rather than a system that was merely abused.

jlopp commented at 3:35 am on October 26, 2025:

“illegal or universally abhorrent content” is poorly defined; there are a multitude of legal jurisdictions and a multitude of subjective views on content; Bitcoin as a system does not recognize any of them.

BlakeJones9449 commented at 4:37 am on October 26, 2025:

The motivation section only seeks to outline potential avenues for new risks allowed by Bitcoin Core 30. It is enough to recognize that there is an overlap of illegal data and universally abhorrent data which will put average node operators at unneeded risk. A specific outlining of the content in question is not needed, only a recognition that the risks are there.

Bitcoinfinity commented at 5:23 am on October 26, 2025:

Agree with Blake. Precise definitions were never proposed nor required.

BitcoinMechanic commented at 7:44 am on October 26, 2025:

Without wanting to be crass or sicken anyone with specifics, of course there are files that all decent people would make an effort to not download/store on their devices regardless of their legal status.

The general attempt to widen the scope of Bitcoin from “All financial activity must be treated as equal” to “Thus we must treat all files as just ones and zeroes” has been perplexing to watch as not only is it indefensible, it’s completely unnecessary. Bitcoin can continue to eschew non-financial activity in general and thus not encumber its users with the problems that begin with soliciting it and then either having to attempt to moderate based on file contents or failing to do so and then ultimately getting used as a garbage dump for the world’s most shunned files.

zndtoshi commented at 9:28 am on October 26, 2025:

Nack This change is motivated on outside factors and interpretation of the data (legal and political) and not on how the software functions.

ArmanTheParman commented at 10:38 am on October 26, 2025:

How about… There should be no subjective assessment of arbitrary data’s content/meaning, all arbitrary data (extra data not contributing to the movement of sats on layer 1) can just be rejected indiscriminately based on some limit, eg zero.

I acknowledge not all arbitrary data can be, or needs to be, eliminated, but the principle is objective, and rules based off that can be made. If some arbitrary data cannot be interpreted as being arbitrary, then so be it, it gets on chain.

But having a FIELD dedicated to arbitrary data can easily be objectively blocked.

BitcoinMechanic commented at 11:25 am on October 26, 2025:

Nack This change is motivated on outside factors and interpretation of the data (legal and political) and not on how the software functions.

No it is not. The point is to limit arbitrary data in general and thus the exact opposite: prevent having to start performing the analysis you (and I) do not want.

ekzyis commented at 11:46 am on October 26, 2025:

of course there are files that all decent people would make an effort to not download/store

The “decent” is doing a lot of work in that sentence. Care to define “decent people”? Is bitcoin not for the other ones?

BitcoinMechanic commented at 12:15 pm on October 26, 2025:

of course there are files that all decent people would make an effort to not download/store

The “decent” is doing a lot of work in that sentence. Care to define “decent people”? Is bitcoin not for the other ones?

Bitcoin is not for arbitrary file storage period. In designing it that way, we get the added benefit of not having to store data that is universally disliked.

rencryptofish commented at 3:43 pm on October 26, 2025:

curious if you can point to an opinion from counsel that expands on the legal risks described in the bip

kwsantiago commented at 4:56 pm on October 26, 2025:

“illegal or universally abhorrent content” is poorly defined; there are a multitude of legal jurisdictions and a multitude of subjective views on content; Bitcoin as a system does not recognize any of them.

The point is precisely to avoid having to define or judge specific content. By limiting arbitrary data storage at the protocol level, we sidestep the entire problem. Bitcoin doesn’t need to become a content moderation system. The goal is to preserve Bitcoin’s identity as a monetary network, not to police what data is “bad enough”. This is about protocol purpose, not content judgment.

dathonohm commented at 8:16 pm on October 26, 2025:

There are categories of content that practically all of humanity finds objectionable, and that carry harsh penalties for distributors, including long prison sentences and possibly even execution in some jurisdictions.

I think it is sufficient to acknowledge that such content exists, and that the penalties are sufficiently harsh in at least a few jurisdictions, to recognize that this increased liability will be more than enough to discourage many users from running their own Bitcoin nodes, in order to serve a function that has no relation to permissionless global money.

Bitcoin as a system may not espouse any particular legal or moral code (other than the consensus rules), but individual Bitcoin users absolutely do. This BIP represents a way for the entire bitcoin network to take a meaningful stance regarding the data use case, both collectively and individually.

pakovm-git commented at 10:29 pm on October 26, 2025:

Illegal under which jurisdiction? Does this affect all common law, civil law and religious law jurisdictions equally?

in bip-????.mediawiki:45 in 3c71823707

40+The adoption of this release, even if by a minority of users, risks establishing this harmful redefinition as a new de facto standard for the entire network.
41+
42+This official sanction creates an immediate and severe threat.
43+The threat here is distinct from general spam or economic costs, which are typically handled with policy and the fee market.
44+It allows a malicious actor to mine a single transaction with illegal or universally abhorrent content and credibly claim that Bitcoin itself is a system for distributing it, rather than a system that was merely abused.
45+This directly threatens the ability and/or willingness of common people to run fully validating nodes due to the resulting legal and moral risks.

jlopp commented at 3:37 am on October 26, 2025:

Again, “legal and moral risks” could use much more precise definition.

Bitcoinfinity commented at 5:24 am on October 26, 2025:

Again, precise definitions were never proposed nor required.

jeremyburr commented at 5:39 pm on October 26, 2025:

Again, “legal and moral risks” could use much more precise definition.

The very goal of this proposal is to limit the need to interpret law——not encourage it.

dathonohm commented at 8:17 pm on October 26, 2025:

See #2017 (review)

donaldevine commented at 9:08 pm on October 26, 2025:

Again, “legal and moral risks” could use much more precise definition.

It could be argued that @jlopp is attempting to prevent progress on this BIP by being overly pedantic. To placate him, the BIP could contain detailed definitions of the terms he is questioning. However, I suspect this would not satisfy him and he would continue to find issues with definitions in an attempt to delay this proposal.

jonatack commented at 9:23 pm on October 26, 2025:

I don’t think it’s necessary at this stage to be overly pedantic in the motivation section – or at least provide a concrete, helpful proposal. Suggest focusing more on expert technical review of the specification itself.

jlopp commented at 10:08 pm on October 26, 2025:

Given the coercive tone of the BIP, I believe that providing specifics around the supposed threat are highly warranted.

jonatack commented at 10:22 pm on October 26, 2025:

Marking further meta-commentary as off-topic here – henceforth, please do that in the ML discussion and focus here on technical feedback on the specification (thanks).

in bip-????.mediawiki:49 in 3c71823707

44+It allows a malicious actor to mine a single transaction with illegal or universally abhorrent content and credibly claim that Bitcoin itself is a system for distributing it, rather than a system that was merely abused.
45+This directly threatens the ability and/or willingness of common people to run fully validating nodes due to the resulting legal and moral risks.
46+
47+A core principle of Bitcoin is "don't trust, verify".
48+The nature of Bitcoin requires users to run fully validating nodes, necessarily involving downloading, storing, and transmitting every transaction, even if they are fake/spam "transactions".
49+If the blockchain contains content that is illegal to possess or distribute, node operators are forced to choose between violating the law (or their conscience) or shutting down their node.

jlopp commented at 3:37 am on October 26, 2025:

This has always been the case.

BlakeJones9449 commented at 4:41 am on October 26, 2025:

An acknowledgement that the risks are present should be sufficient to encourage mitigation of risks which exacerbate this risk vector such as those introduced by Core 30.

BitcoinMechanic commented at 7:51 am on October 26, 2025:

See below

csuwildcat commented at 11:05 am on October 26, 2025:

It’s a very bad idea to put text suggesting legal liability into the implementation. Please talk to legal folks as to why, because even elaborating here via discussion of that particular aspect is hazardous.

csuwildcat commented at 11:09 am on October 26, 2025:

The generalized invocation of the ominous need for Bitcoin to ‘follow the law or else’ is concerning, because law can change, and in many places laws are enacted that run against the very principles Bitcoin represents. The open ended ‘appeal to legality’ and its implicit urging to act at the behest of government is something I hope folks reconsider.

BitcoinMechanic commented at 11:28 am on October 26, 2025:

Legal liability exists regardless.

The point is that some files being illegal and others not makes laws essentially arbitrary and thus we should seek to discourage all arbitrary file storage specifically to reject this inevitable issue entirely.

csuwildcat commented at 3:11 pm on October 26, 2025:

Legal liability exists regardless.

The point is that some files being illegal and others not makes laws essentially arbitrary and thus we should seek to discourage all arbitrary file storage specifically to reject this inevitable issue entirely.

There are already images in the chain that violate laws, and even text snippets under the former OP_RETURN policy limit can violate laws in many jurisdictions, so the idea we must do this to dodge government’s wrath just isn’t compelling, given a State actor who feels this is a serious vector to attack Bitcoin would do so using what they already have. This notion gover-daddy is going to be so happy that Bitcoin is trying to signal compliance (‘signal’, because bad content is virtually unstoppable, regardless of OP_RETURN limits), it’ll ‘do us a solid’ by kindly withholding harms it desires to do is the most wishful of thinking.

Adding an explicit declaration that ‘Bitcoin must comply with laws and won’t if you don’t run version __._’, creates other long-term hazards for the project, as it signals it is responsive to government compelled action.

Please do not add statements like this to Bitcoin’s codebase, it is not the right path for the project to go down.

kwsantiago commented at 4:55 pm on October 26, 2025:

This has always been the case.

Yes, the risk has always existed, but Core v30 transforms it from a “system being abused via exploits” to a “system officially supporting this use case”. There’s a crucial difference between someone finding a clever workaround (80-byte limit for years) vs. the reference implementation saying “100 KB is fine”. Consensus rules send a clear message about protocol intent that policy alone cannot.

jeremyburr commented at 7:32 pm on October 26, 2025:

Legal liability exists regardless.

The point is that some files being illegal and others not makes laws essentially arbitrary and thus we should seek to discourage all arbitrary file storage specifically to reject this inevitable issue entirely.

The justification is sound, but the wording is problematic. Explicit calls to avoid illegal content signal intent to comply with the law. It weakens the objective of the proposal itself—to be legally agnostic.

dathonohm commented at 8:19 pm on October 26, 2025:

Yes, but up until Bitcoin Core 30, there was always plausible deniability for users who chose to run nodes, since data storage for more than 80 bytes was always considered an abuse of the system rather than officially sanctioned. Core 30 represents a significant departure from this long-established anti-data stance.

jlopp commented at 10:10 pm on October 26, 2025:

Core v30 transforms it from a “system being abused via exploits” to a “system officially supporting this use case”.

This is a novel theory that is in great need of supporting evidence.

tphyahoo commented at 10:11 pm on October 26, 2025:

This has always been the case.

“The nature of Bitcoin requires users to run fully validating nodes, necessarily involving downloading, storing, and transmitting every transaction, even if they are fake/spam “transactions”.”

“storing and transmitting every transaction” – this is untrue.

utreexod is an example of a fully validating node that downloads and validates but does not store transactions.

https://github.com/utreexo/utreexod

dathonohm commented at 10:38 pm on October 26, 2025:

@csuwildcat I think bitcoiners generally are aware of the legal risks and are fine accepting them because that’s the price for Bitcoin’s existence as permissionless global money.

I don’t the same can be said for permissionless uncensorable data storage, which carries much greater risks, and no benefits.

tphyahoo commented at 10:42 pm on October 26, 2025:

@dathonohm full nodes don’t need to store data, only validate. (see my previous post)

Tokyopapa commented at 1:17 am on October 27, 2025:

Core v30 transforms it from a “system being abused via exploits” to a “system officially supporting this use case”.

This is a novel theory that is in great need of supporting evidence. You own comment on PR 32359 seems to validate the theory that the “system [is] officially supporting this use case.” https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833680770 From the conversation: jlopp commented on Apr 28 Concept ACK. It’s time to come to terms with the fact that Bitcoin is desirable for some people to use as a data anchor and they will find a way to use it as such, thus we should be asking what the preferred means of data anchoring is and how to incentivize it over less preferable options.

kwsantiago commented at 1:37 am on October 27, 2025:

Core v30 transforms it from a “system being abused via exploits” to a “system officially supporting this use case”.

This is a novel theory that is in great need of supporting evidence. @jlopp Core v30 expanded default datacarriersize from 80 bytes to 100,000 bytes (1,250x increase).

Your comment on https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833680770: “Concept ACK… we should be asking what the preferred means of data anchoring is and how to incentivize it over less preferable options.”

You’re treating data storage as a legitimate use case to optimize. That’s “official support”, not “mitigating abuse”.

Patches close exploits. Features expand capacity. v30 expanded capacity.

MarkJelic commented at 9:31 am on October 27, 2025:

Adding an explicit declaration that ‘Bitcoin must comply with laws and won’t if you don’t run version __._’, creates other long-term hazards for the project, as it signals it is responsive to government compelled action.

Please do not add statements like this to Bitcoin’s codebase, it is not the right path for the project to go down.

I see where you are going with this and would generally agree that if we see Bitcoin is nothing more than Money, that we should not in any way care what is legal or not in any given jurisdiction. However, with the changes v30 have made, nobody can say Bitcoin is Only Money any longer and thus the sentence you are referring to does have merit in terms of describing the problem node operators face.

Rather than using the terms “illegal to posses” and “violating the law”, would it be appropriate to use “morally reprehensible to posses” and “violating their conscience (with possible legal consequences)” ?

in bip-????.mediawiki:50 in 3c71823707

45+This directly threatens the ability and/or willingness of common people to run fully validating nodes due to the resulting legal and moral risks.
46+
47+A core principle of Bitcoin is "don't trust, verify".
48+The nature of Bitcoin requires users to run fully validating nodes, necessarily involving downloading, storing, and transmitting every transaction, even if they are fake/spam "transactions".
49+If the blockchain contains content that is illegal to possess or distribute, node operators are forced to choose between violating the law (or their conscience) or shutting down their node.
50+This unacceptable dilemma directly undermines the incentive to validate, leading to inevitable centralization and posing an existential threat to Bitcoin's security model.

jlopp commented at 3:38 am on October 26, 2025:

But this has always been the case…

BlakeJones9449 commented at 4:42 am on October 26, 2025:

Doesn’t mean it needs to stay that way, or that we need to make the situation worse.

Bitcoinfinity commented at 5:27 am on October 26, 2025:

There is general consensus that sketchy content should not be on bitcoin, and that most node operator would support this change.

BitcoinMechanic commented at 7:51 am on October 26, 2025:

This has always been the case

The point is not to make an issue (arbitrary illegality making life harder for nodes) worse by engaging in activity we have no business defending (the uploading/downloading/storage of arbitrary data).

dathonohm commented at 8:19 pm on October 26, 2025:

Bitcoin Core 30 meaningfully changes the situation. See: #2017 (review)

in bip-????.mediawiki:52 in 3c71823707

47+A core principle of Bitcoin is "don't trust, verify".
48+The nature of Bitcoin requires users to run fully validating nodes, necessarily involving downloading, storing, and transmitting every transaction, even if they are fake/spam "transactions".
49+If the blockchain contains content that is illegal to possess or distribute, node operators are forced to choose between violating the law (or their conscience) or shutting down their node.
50+This unacceptable dilemma directly undermines the incentive to validate, leading to inevitable centralization and posing an existential threat to Bitcoin's security model.
51+
52+By enforcing these new rules, this softfork allows the community to reject the standardization of data storage at the consensus level, closing the gap being abused.

jlopp commented at 3:39 am on October 26, 2025:

But it doesn’t stop aforementioned content from ending up on node operator’s machines, so the dilemma remains.

Bitcoinfinity commented at 5:28 am on October 26, 2025:

Dilemma might remain, but the a serious effort in the right direction would be supported by most node operators.

BitcoinMechanic commented at 7:53 am on October 26, 2025:

Could you please explain how it would be possible for the content we are generally alluding to to make it onto node operator’s machines should these new rules be enforced?

kwsantiago commented at 5:08 pm on October 26, 2025:

With these rules enforced, contiguous data >256 bytes becomes consensus-invalid. An attacker could theoretically steganographically encode data across multiple fields, but:

It’s non-contiguous and obfuscated
External code would be needed to reassemble it (making that code responsible, not Bitcoin)
It signals Bitcoin doesn’t support this use case. The difference between “exploit despite protections” vs. “official feature” is crucial for Bitcoin’s reputation and legal standing.

in bip-????.mediawiki:144 in 3c71823707

139+
140+The impact of these restrictions would severely constrain future upgrades, potentially forcing them to be designed as a hardfork instead of a softfork.
141+Some restrictions are also not ideal, but an improved limit would be more complicated to develop and test -
142+by deploying these simpler restrictions now, we avoid making the perfect the enemy of the good enough, while still allowing for upgrading the limits to better variants in the future.
143+
144+Over the next year, interested developers can implement and propose a longer-term solution to address the needs of the protocol without the tradeoffs or blunt/simplified changes.

jlopp commented at 3:40 am on October 26, 2025:

This sounds like a massive assumption; if the default is to relax the rules again, then you are simply re-introducing the “dilemma / vulnerability” by default, which should be unconscionable, correct?

Bitcoinfinity commented at 5:29 am on October 26, 2025:

Incorrect.

jlopp commented at 7:17 am on October 26, 2025:

Feel free to explain why relaxing the rules would not reintroduce the claimed problem.

BitcoinMechanic commented at 7:56 am on October 26, 2025:

Because during the period of temporary restriction, we can elect to extend the period or make it (or some subset of it) permanent should it not prove too restrictive for something beneficial.

dathonohm commented at 8:29 pm on October 26, 2025:

This sounds like a massive assumption; if the default is to relax the rules again, then you are simply re-introducing the “dilemma / vulnerability” by default, which should be unconscionable, correct?

Yes, presumably in a year we would either fork to extend the rules indefinitely, or we would implement something more elegant that allows for some of the use cases this BIP handicaps, such as BitVM, while re-affirming our commitment to prevent block space from being used for data storage.

As the BIP mentions, that could also be a good time to propose activation for output-restriction covenants such as CTV or TEMPLATEHASH, which appear to have broad support among the developer community and could gather sufficient consensus to activate by then.

in bip-????.mediawiki:211 in 3c71823707

206+Generally, softforks do not cause chain splits.
207+However, since we are rejecting an already-mined block proposal, this softfork does indeed cause a chain split.
208+In fact, that is an important part of its purpose:
209+to keep the illegal content storage in block <TODO:hash> out of Bitcoin.
210+
211+To achieve this, the softfork must activate retroactively, invalidating that block and all its descendants.

jlopp commented at 3:46 am on October 26, 2025:

It sounds like this actually introduces a vulnerability of its own. If an attacker wishes to double spend their coins, they could:

Embed a sufficiently controversial piece of data to the blockchain.
Make a transaction, wait for it to confirm and receive something in return.
Reveal to the world that there is controversial data that requires the chain to be invalidated
Upon chain invalidation, RBF their now-unconfirmed transaction to send the funds back to themselves

BlakeJones9449 commented at 5:53 am on October 26, 2025:

I guess that would depend on how quickly the retroactive method could be implemented after it is deemed necessary. As long as the vulnerabilities created by Core v30 remain in place it would behoove a receiver waiting on L1 transaction finality to give it some extra time. The 2013 hardfork was resolved in 24 blocks, about 6 hours.

Where would an attacker hide such data for long enough that they could pull off this double spend attack?

jlopp commented at 7:18 am on October 26, 2025:

Hiding the data would not be a requirement; an attacker could literally publish said data and then transact in the same block or the next block.

BitcoinMechanic commented at 8:01 am on October 26, 2025:

@jlopp You’re correct but that’s a scenario in which alternatives are clearly worse which is why I agree that the preferred approach of the two outlined in this BIP is prophylactic rather than reactive.

zndtoshi commented at 8:27 am on October 26, 2025:

Isn’t the retroactive activation a 51% attack from miners? Wouldn’t such a BIP standardize and make official and endorsed by Bitcoin Core the 51% attacks?

zndtoshi commented at 11:27 am on October 26, 2025:

Who decides which op_return is bad enough to require an invalidation of the said block?

BitcoinMechanic commented at 11:30 am on October 26, 2025:

Who decides which op_return is bad enough to require an invalidation of the said block?

That is not a decision that can be unilaterally made by anyone. It would presumably be something sufficiently terrible enough to cause enough people to come to the same conclusion.

As mentioned above, this is a terrible scenario with no ideal solutions.

zndtoshi commented at 2:19 pm on October 26, 2025:

Would this reorg cover also op_return containing illegal text for example enticing to violence against a certain group of people?

kwsantiago commented at 5:03 pm on October 26, 2025:

Who decides which op_return is bad enough to require an invalidation of the said block?

No one decides unilaterally, which is the whole point. This would only activate reactively if content is severe enough that the community converges on the need to respond (similar to the 2010 inflation bug). The better question is whether we should wait until that happens, or should we close the gap proactively? This BIP does both through a proactive path (Feb 2026) with reactive fallback. The existence of this proposal likely prevents the need for reactive deployment.

dathonohm commented at 8:44 pm on October 26, 2025:

@jlopp There will indeed be much risk for vendors over the next few months of a sudden “reactive” activation of this BIP. Merchants should be prepared to stop accepting on-chain Bitcoin payments and wait for at least a few confirmations, maybe even 100 or so for large payments.

This could be a bumpy ride, but I don’t see a better way.

Ideally we could achieve a BIP8 early activation if miners are eager to activate (if I were running a mining pool, I would be). But there’s a good chance that BIP8 activation code wouldn’t be production-ready fast enough to make a difference, unless we can get a lot of developer support. So the “proactive” deployment of this BIP is a flag day for now.

dathonohm commented at 8:52 pm on October 26, 2025:

As for who will be the authority that will let everyone know which block has objectionable data, I can only say that each node runner should decide for him- or herself whether to reject the block and immediately follow the new rules. I would caution against viewing the material directly, as this could legally implicate the user. But also: don’t trust, verify. Personally I will probably just follow the new chain once it has enough hashpower. Accidental early activation via the “reactive” method would not be the worst thing to happen.

in bip-????.mediawiki:298 in 3c71823707

293+it is an absolute necessity to prevent it from occurring even once.
294+This absolute protection cannot be guaranteed by voluntary policy and can only be provided by consensus rules.
295+
296+'''Isn't this censorship? By rejecting blocks based on data content, aren't you violating the principles of free speech and a neutral, permissionless network?'''
297+
298+Bitcoin is money, not speech.

jlopp commented at 3:50 am on October 26, 2025:

According to Citizens United v. Federal Election Commission, 558 U.S. 310, money is speech.

Normally it would be irrelevant to reference legal rulings in the context of the protocol, but this BIP seems to rely heavily on legality.

Bitcoinfinity commented at 5:31 am on October 26, 2025:

money is speech, but not all speech is money. You must understand the difference, making this comment clearly in bad faith.

BitcoinMechanic commented at 8:04 am on October 26, 2025:

Bitcoin is a monetary protocol. The protocol treats non-monetary usage with appropriate hostility. The pressure to do otherwise is met with insincere appeals to “free speech” which is what L296-L298 addresses. This is not related to legality.

MalachiRevolts commented at 8:22 am on October 26, 2025:

It is not censorship to preserve the intended use-case of Bitcoin, which is monetary.

It looks like some refuse to discourage spam on consensus level because of selfish opportunistic endeavours.

By engaging in opportunistic use-cases which neglect the risk of illegal content they are putting the reputation of Bitcoin on the line and introducing censorship implicitly themselves.

I’ll explain: If Bitcoins reputation would become so bad that regulatory authorities in e.g. Europe take a look at it, exchanges could be forced to close on/off ramps to Bitcoin. Businesses and institutions would not be able to legally buy Bitcoin anymore. That would be censorship.

ArmanTheParman commented at 1:18 pm on October 26, 2025:

Arbitrary data, by definition, is not part of money, in the same way that drawing pictures on a bank cheque is not part of the purpose of the cheque.

kwsantiago commented at 5:05 pm on October 26, 2025:

According to Citizens United v. Federal Election Commission, 558 U.S. 310, money is speech.

This conflates Bitcoin-the-monetary-protocol with Bitcoin-the-arbitrary-data-layer. Citizens United doesn’t say the Federal Reserve must accept crayon drawings on dollar bills. Bitcoin script supports complex financial arrangements (HTLCs, multisig, etc), which is monetary speech. Random JPEGs and videos aren’t monetary expression, they’re an abuse of a monetary system’s infrastructure. The protocol can enforce its intended purpose without violating free speech principles.

JackTyler4444 commented at 7:02 pm on October 26, 2025:

What is ‘money’ is an extremely subjective definition. We can see this by considering the history of it.

Jeremy-coding commented at 7:30 pm on October 26, 2025:

It’s absolutely incredible to find so many people adamant on this PR that their definition of “monetary network” is the objectively correct one for Bitcoin, while they would simultaneously tell you that Bitcoin is NOT a “peer to peer electronic cash system” for “small casual transactions” as outlined in the Bitcoin whitepaper (that was the argument of the big blockers in the Blocksize War).

People are very subjective with their interpretation of definitions to fit their current mood or belief.

dathonohm commented at 8:52 pm on October 26, 2025:

@jlopp I’m not sure why you think that’s relevant. Speech is not money, and Citizens United does nothing to change this.

jlopp commented at 9:59 pm on October 26, 2025:

I just find it odd to claim that Bitcoin is not speech given that a variety of aspects of developing and operating Bitcoin software are, in fact, covered by free speech protections.

On the other hand, the cypherpunk ethos does not really concern itself with the opinions of governments.

dathonohm commented at 10:49 pm on October 26, 2025:

@jlopp You’re overthinking this. Money is speech; speech is not money (except for money, which is a kind of speech).

Therefore, non-financial data is not money and does not belong in the blockchain, nor does it deserve to be stored and distributed, with no way to be censored, until the end of time.

jlopp commented at 10:58 pm on October 26, 2025:

Bitcoin is programmable money; the side effect of that is that people can use it as speech for data publication.

dr0ther commented at 11:21 pm on October 26, 2025:

According to Citizens United v. Federal Election Commission, 558 U.S. 310, money is speech.

Normally it would be irrelevant to reference legal rulings in the context of the protocol, but this BIP seems to rely heavily on legality.

This doesn’t matter as the United States doe not recognize bitcoin as money

jlopp commented at 10:35 am on October 27, 2025:

It also doesn’t matter because Bitcoin does not recognize the United States government.

in bip-????.mediawiki:321 in 3c71823707

316+
317+Performing financial transactions may indeed be illegal, but that is a completely different thing from keeping a record that it occurred.
318+Someone violating OFAC sanctions, for example, may be liable for sending or receiving a payment, but that does not impact the Bitcoin network as a whole.
319+
320+Illegal data is completely different:
321+nodes are not merely recording that it happened, they are active participants in storing and distributing the illegal content itself.

jlopp commented at 3:54 am on October 26, 2025:

The veracity of this claim is highly disputed. https://protos.com/exclusive-lawyers-call-bitcoin-core-v30-csam-concerns-overblown/

BlakeJones9449 commented at 6:24 am on October 26, 2025:

From your cited article: “It is already an issue, yes, and the fact that this kind of attack hasn’t happened yet is a question of luck rather than capability,” they said. “It would be safer for Bitcoin to optimize for content-addressable links to offchain content like an IPFS hash."

The time provided by this temporary softfork would allow for optimization as recommended by your source.

jlopp commented at 7:21 am on October 26, 2025:

Yes, you quote the only 1 of 7 attorneys cited who agrees with your view and they were not even willing to put their name and reputation on the line.

BitcoinMechanic commented at 8:16 am on October 26, 2025:

I assert that the perspective of those lawyers is lacking and that they do not understand what Bitcoin requires in order to function. Pressure placed on nodes to defend the activity mentioned multiple times in other responses above can only weaken Bitcoin as it serves as a disincentive to run one.

For comparison - it is not illegal to consume electricity either, but the framing that “Bitcoin is bad for the environment” has been incredibly harmful and exhausting to counter. The stigma that can be created around running nodes can cause immense damage as people can continue to use Bitcoin without needing to run nodes - ultimately leading to centralization at the enforcement layer which is unquestionably fatal to Bitcoin.

The intent is simple: do not put pressure on people to not run nodes.

BlakeJones9449 commented at 1:51 pm on October 26, 2025:

Yes, you quote the only 1 of 7 attorneys cited who agrees with your view and they were not even willing to put their name and reputation on the line.

I didn’t think a complete breakdown of that article is needed. If people read it they will find that most of the lawyers cited who say they don’t think this will be a problem base their opinion on the fact that it hasn’t been a problem yet. This seems to be the “fingers crossed” method of legal risk analysis.

But assuming the legal concerns are overblown, the social risk of stigma remains. Nakamoto consensus should not be structured such that node runners are required to host large amounts of permissionless, immutable, pseudonymous, non-currency data in order to send and verify their bitcoin transactions.

This BIP allows time to consider ways to address these issues.

kwsantiago commented at 5:10 pm on October 26, 2025:

Even if legal risk is debatable, the reputational risk is clear. Bitcoin’s value proposition is “money for enemies”: neutral, apolitical, monetary infrastructure.

Once Bitcoin becomes known as “a network where people store illegal content”, we lose that neutrality. We’ve spent years fighting “Bitcoin wastes energy”, so imagine fighting “Bitcoin distributes CSAM”. Node operators shouldn’t have to defend hosting arbitrary data just to participate in a monetary network. The stigma alone is a centralization pressure.

dathonohm commented at 9:05 pm on October 26, 2025:

My understanding is that these lawyers are mostly not criminal lawyers and have no relevant experience. But also, note that a majority of the 7 lawyers said there is indeed reason for concern.

jlopp commented at 10:03 pm on October 26, 2025:

“No credible legal authority is seriously considering attaching liability to the automatic process our nodes undertake when dealing with Bitcoin.”

The onus is on the authors and proponents of this BIP to present evidence to the contrary.

in bip-????.mediawiki:350 in 3c71823707

345+
346+The fee market is designed to prioritize transactions based on economic urgency.
347+However, it fails when transactions impose externalities that are not properly weighed against the transaction fee.
348+
349+In this case, the externality is the existential legal and moral liability imposed on every node operator.
350+No transaction fee can compensate for the risk of imprisonment or the moral burden of distributing abhorrent content.

jlopp commented at 3:56 am on October 26, 2025:

“moral liability” and “moral burden” are poorly defined.

Bitcoinfinity commented at 5:32 am on October 26, 2025:

Again, precise definitions were never proposed nor required.

BitcoinMonk commented at 2:08 pm on October 26, 2025:

Regardless of how poorly defined they are it is obvious what that means. Where the line is drawn is irrelevant. Does increasing ‘moral liability’ and ‘moral burden’ help bitcoin in any way?

I would argue not.

I see this proposal as a way to reduce those factors which objectively helps bitcoin by removing that moral dilemma for potential node runners.

ACK

dathonohm commented at 9:06 pm on October 26, 2025:

See #2017 (review)

jlopp commented at 10:14 pm on October 26, 2025:

Bitcoin is already used on a regular basis to conduct immoral and illegal acts; more specification is warranted to clarify why the specific immoral / illegal acts that the BIP posits to prevent are an existential crisis while the others are not.

jonatack commented at 10:29 pm on October 26, 2025:

All, please don’t repeat the same argument after having stated it once, otherwise marking as duplicate. Thanks.

bitcoin deleted a comment on Oct 26, 2025

in bip-????.mediawiki:352 in 3c71823707

347+However, it fails when transactions impose externalities that are not properly weighed against the transaction fee.
348+
349+In this case, the externality is the existential legal and moral liability imposed on every node operator.
350+No transaction fee can compensate for the risk of imprisonment or the moral burden of distributing abhorrent content.
351+
352+Furthermore, fees provide an incentive to miners only, and do not in any case justify forcing the burden on node operators who have not all consented.

jlopp commented at 3:57 am on October 26, 2025:

By running a node you consent to the consensus rules of the network. If you don’t consent, you can simply not run a node.

BlakeJones9449 commented at 5:25 am on October 26, 2025:

Wouldn’t such an approach lead to more node centralization a reduce Bitcoin’s network effects?

Bitcoinfinity commented at 5:32 am on October 26, 2025:

This applies to both pro and con arguments of this BIP and therefore an irrelevant comment.

BitcoinMechanic commented at 8:30 am on October 26, 2025:

@jlopp Not sure the relevance? This fork changes consensus rules.

krynne commented at 8:49 am on October 26, 2025:

By running a node, I am not consenting to the consensus rules of the network, I’m enforcing them. It’s the network’s nodes that determine what the consensus rules are. If you remove all the nodes, there’s no consensus left and no rules to enforce.

ArmanTheParman commented at 1:29 pm on October 26, 2025:

By running a node you consent to the consensus rules of the network. If you don’t consent, you can simply not run a node.

Running a node is not “consenting”, this is the wrong framing; it is drawing a line in the sand about what rules YOU apply to your own money. Consensus forms FROM it, it’s not “enforced”, and there is no “compliance”. This is not Ethereum. If the rules of the networks are wrong and do not reflect the will of the majority, the rules can eventually change.

The PEOPLE decide what their money rules are; the code follows.

It’s not the other way around. Ideology of money is a higher priority than code. Code “codefies” the ideology, and sometimes it’s not precise enough and needs modification.

Bitcoin is money, not an arbitrary data transfer protocol. If arbitrary data happens to tag along, it might not be an issue, so be it - it doesn’t necessarily have to be 100% eliminated, but when it’s becoming an issue, it’s not “censorship” to stop it. This is valid because the purpose of Bitcoin is NOT speech (nor arbitrary data transfer) - instead, free speech protects Bitcoin. These are different things.

It’s exactly the case in law - if the law is wrong, it changes (when the system is working, of course).

dathonohm commented at 9:07 pm on October 26, 2025:

I don’t think we should be creating even more barriers to running a node when so many already exist.

rdouma commented at 1:49 am on October 27, 2025:

By running a node you consent to the consensus rules of the network. If you don’t consent, you can simply not run a node.

Therefore we need to make the consensus rules such that people are willing to consent.

in bip-????.mediawiki:390 in 3c71823707

385+This softfork itself also specifically targets a certain subset of abuse of Bitcoin as an arbitrary data storage and distribution system, which has never been its intended purpose.
386+It does not attempt to impose restrictions on financial activity or the validity of monetary transactions themselves.
387+This clear distinction between mitigating a systemic risk from non-financial data abuse and interfering with actual financial use cases provides a strong barrier against future overreach.
388+
389+The explicitly temporary nature of the softfork further reinforces that this is a targeted intervention to mitigate a specific crisis, not a commitment or proposal of a new direction of development.
390+If no further action is taken by you, it will expire in a year.

jlopp commented at 4:00 am on October 26, 2025:

Needs further rationale as to why it’s safe to automatically remove protections that are supposedly needed to stop an existential crisis.

Bitcoinfinity commented at 5:35 am on October 26, 2025:

Disagree.

BitcoinMechanic commented at 8:34 am on October 26, 2025:

Making the new rules permanent immediately creates the need for a hardfork to ever undo them. It makes sense to do this temporarily for reasons explained elsewhere as they (or a subset of them) can be extended/made permanent if not proven undesirable during the temporary period.

ekzyis commented at 12:45 pm on October 26, 2025:

What could be undesirable effects of this temporary softfork?

kwsantiago commented at 5:12 pm on October 26, 2025:

The temporary nature allows three things:

Immediate protection while better long-term solutions are developed (avoiding “perfect is the enemy of good”)
Evaluation period to see if these limits harm legitimate use cases (if they don’t, make it permanent; if they do, refine)
Avoids forcing future softforks to be hardforks by allowing the community to extend and/or make permanent, otherwise it expires. This is prudent given the BitVM tradeoff and upgrade hook limitations.

dathonohm commented at 9:09 pm on October 26, 2025:

If this BIP gains consensus and activates, it seems likely that, when it expires, there would be consensus at least for extending the restrictions, if no better solutions are found.

jlopp commented at 10:37 am on October 27, 2025:

Speculation is not a great specification.

kevkevinpal commented at 2:23 pm on October 27, 2025:

Can this instead be measured in number of blocks?

it will expire in a year

kevkevinpal commented at 2:27 pm on October 27, 2025:

sorry just saw that it would expire on block 987424 after activation. I suggest mentioning that here.

in bip-????.mediawiki:73 in 3c71823707

68+'''What about OP_RETURN? Why not get rid of it entirely?'''
69+
70+OP_RETURN outputs are provably unspendable, and nodes do not need to store it in the UTXO set.
71+Historically, up to 83 bytes have been tolerated only to avoid unprovably unspendable spam in other output scripts, and no legitimate uses have ever been found.
72+With the advent of pay-to-contract and Taproot, it is now also possible to commit to external data in the Taptree, making even hypothetical use of OP_RETURN deprecated.
73+However, to avoid breaking legacy protocols that still include such outputs, this proposal allows these outputs.

GregTonoski commented at 9:40 am on October 26, 2025:

Also I am raising objection to the fragment of the proposal. I think that the presumption of existence of “legacy protocols” is false. There isn’t any BIP of such a protocol. Also, I haven’t seen any implementation of a hypothetical undocumented one. Last, but not least - arbitrary data storage doesn’t belong to Bitcoin and the “OP_RETURN” bug that is exploited by abusers must be fixed.

dathonohm commented at 9:43 pm on October 26, 2025:

Unfortunately, 80 bytes is the standard on the network now, at least until 100kB OP_RETURNs start being reliably mined, so there are many use cases, including privacy-related protocols, that would break if we set OP_RETURN to zero. Hopefully this BIP will encourage a migration away from such inefficient protocols, but invalidating such uses does nothing to help this BIP’s goals, as 80 bytes is too small for legally risky content.

Also, segwit would break: https://github.com/bitcoin/bips/pull/2017/files/3c718237072c107ced8c3531a487354fbdae55df#r2463933146

ekzyis commented at 11:48 am on October 26, 2025: none

Will or can this softfork affect lightning or currently planned upgrades of it?

btw, fwiw, there’s also some discussion at https://stacker.news/items/1265553 (sorry for the shameless plug, I work at SN)

in bip-????.mediawiki:230 in 3c71823707

225+If the chain split is prolonged, it may be worth considering closing any high-value channels with untrusted counterparties.
226+
227+'''Is this unprecedented?'''
228+
229+No.
230+Bitcoin has deployed emergency softforks, including chain splits, in at least two past occasions:

ekzyis commented at 12:18 pm on October 26, 2025:

Is there an emergency regarding spam on-chain? If there was an emergency, wouldn’t fees be very high?

What am I missing?

Or is this softfork only motivated by legal concerns, not spam?

BlakeJones9449 commented at 12:42 pm on October 26, 2025:

It seems to be motivated by both legal concerns and spam. This is not necessarily something that would be reflected in fees.

MalachiRevolts commented at 12:55 pm on October 26, 2025:

Or is this softfork only motivated by legal concerns, not spam?

I wouldn’t minimize the legal aspect. If you want:

exchanges not to be forced by regulators to close off/on ramps
businesses and institutes to be able to hold Bitcoin on their balances

You should want to support every proposal that protects Bitcoin from regulatory strain or worse.

Why address it now at consensus level? => Because you don’t want regulatory bodies to get the impression you are just allowing something to happen.

What about money laundering? => You can defend money but you can’t defend illegal files.

Bitcoin isn’t designed for files, so it’s no issue => If you allow contiguous file storage, in Bitcoin’s current state, it would be use of the protocol. If, however, you discourage contiguous file storage, and spam happens, it’s abuse of the protocol. Regulatory bodies make the distinction. The social layer also makes that distinction. You don’t want Bitcoin to get a bad reputation if you want more adoption.

There is already bad stuff on the blockchain => Yet another reason to address further use of the blockchain in that way. Times have changed and regulatory actions against platforms that host data happen daily. Saying Bitcoin is immutable wouldn’t help. They’d just go to the exchanges and close the off/on ramp. Nobody should want to risk this.

ekzyis commented at 1:10 pm on October 26, 2025:

This is not necessarily something that would be reflected in fees.

Why would spam not reflect itself in fees?

Because you don’t want regulatory bodies to get the impression you are just allowing something to happen.

I don’t want to give regulatory bodies the impression developers are responsible for what happens on the network

MalachiRevolts commented at 1:28 pm on October 26, 2025:

I don’t want to give regulatory bodies the impression developers are responsible for what happens on the network

They wouldn’t take that path. As I said, they’d go to exchanges and lawmakers to enforce their regulation at that level. So, it’s about navigating Bitcoin through the real world and protect it.

Do we rather want to give opportunists the impression we can make developers do their bidding? Lately it’s going that way and that also ain’t the good path forward.

kwsantiago commented at 5:00 pm on October 26, 2025:

Is there an emergency regarding spam on-chain? If there was an emergency, wouldn’t fees be very high?

The emergency is existential, not economic. Low fees make the attack cheaper, since a malicious actor can embed illegal content for under $10 in fees. Once in the blockchain, it’s permanent and every single node operator is forced to store+distribute it. Ultimately this is not about fee-market spam, it’s about how a single bad actor is able to create legal/reputational liability for every single node operator. That’s a fundamentally different threat model.

dathonohm commented at 10:09 pm on October 26, 2025:

@ekzyis This BIP specifically targets forms of spam that are so legally toxic that having even a single instance in the chain represents a significant legal liability for users who run nodes. It might lead to a reduction of other forms of spam as well, but that would merely be a side effect. Spam without legal risk for users is best fought in policy rather than consensus.

in bip-????.mediawiki:255 in 3c71823707

250+'''Is this like the BIP148 UASF?'''
251+
252+In some ways, yes:
253+it only requires a significant minority to succeed;
254+miners need to upgrade to continue mining, and are incentivised to do so;
255+actual rejection requires a counter-softfork (aka URSF); etc.

Rob1Ham commented at 12:40 pm on October 26, 2025:

How is a counter soft fork required?

I’m not following how following existing consensus would require an additional code change to reject this proposal.

Maybe it will become clear when there is code?

kwsantiago commented at 5:37 pm on October 26, 2025:

How is a counter soft fork required?

Old nodes follow the chain with the most proof-of-work. If upgraded miners build a longer chain enforcing new rules, old nodes automatically follow. To resist requires active counter-measures, such as checkpointing the data-storage chain OR running code that rejects blocks signaling this softfork (URSF). Simply “doing nothing” isn’t enough, same dynamics as BIP148.

average-gary commented at 2:07 pm on October 27, 2025:

From my understanding, a >83byte OP_Return would be considered valid by old nodes but rejected by new nodes? Would this not create a chain split?

Rob1Ham commented at 2:21 pm on October 27, 2025:

From my understanding, a >83byte OP_Return would be considered valid by old nodes but rejected by new nodes? Would this not create a chain split?

Yes, it would cause a chainsplit. The assumption of there not being a chainsplit is all hash rate and most economic nodes to update.

in bip-????.mediawiki:31 in 3c71823707

26+
27+# New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.
28+# OP_PUSHDATA* with payloads larger than 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs.
29+# Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141 nor Taproot/BIP 341) is invalid.
30+# Witness stacks with a Taproot annex are invalid.
31+# Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid.

mononaut commented at 2:16 pm on October 26, 2025:

This would be confiscatory, as there are coins known to be secured by taproot script trees with greater depth, e.g. https://mempool.space/address/bc1pxmvwu0rv0vx6l8m7l5x5fxyjcyypch42d2pym0fuepjkzd0p34nslx2vhh

BitcoinMonk commented at 2:32 pm on October 26, 2025:

Agreed on the confiscation risk. How about a height-based exemption for pre-activation UTXOs? Wouldn’t it be as simple as ‘if (input_height < activation_height) skip_size_limit’?

dathonohm commented at 9:33 pm on October 26, 2025:

@mononaut Unfortunately yes, this proposal in its current form almost certainly will result in funds being at least frozen for a year. I don’t see any easy way around this (other than just loudly warning users to migrate their funds ASAP) but I’m open to suggestions.

Do you happen to know the use case for such a large tree?

bitcoin-eagle commented at 0:30 am on October 27, 2025:

@dathonohm Multisig 6-of-11 or greater implemented as 462 seperate 6-of-6 scripts (all combinations of 6 key subsets from 11 quorum). Which is the efficient way of doing multisig in taproot to save number of checksig operations and to avoid publishing unused pubkeys

I find it a bit ironic to confiscate bitcoin specifically from people that use script in a way to minimize spamming the chain with unused pubkeys in a big multisig

BitcoinErrorLog commented at 2:55 pm on October 27, 2025:

This makes it a non-starter. BIPs should not include confiscatory qualities as it obviously disrupts the user space and undermines all similar use cases reputationally.

Rob1Ham commented at 2:47 pm on October 26, 2025: none

According to BIP-2:

Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the Bitcoin development mailing list.

When will this be posted to the mailing list as its own thread so it can get greater attention & review?

in bip-????.mediawiki:27 in 3c71823707

22+
23+==Specification==
24+
25+Blocks with a height from (TBD) until and including 987424 are checked with these additional rules:
26+
27+# New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.

benthecarman commented at 3:03 pm on October 26, 2025:

this basically does nothing unless you limit the number of op returns on a tx. you would however probably want to make a carve out for the coinbase tx

00w1 commented at 3:26 pm on October 26, 2025:

It increases the cost (multiple outputs) and discourage the use of OP_RETURN for arbitrary data.

dathonohm commented at 9:26 pm on October 26, 2025:

This BIP’s main goal is to require users wanting to store large unencrypted files in the blockchain to disguise the data as financial data and/or break it up into multiple data pushes. Obviously doing so is considered an abuse of bitcoin and should be avoided, but if it does happen, this BIP strengthens the argument that data storage is not a supported use case, thus minimizing legal liability for users who run nodes.

Yes, there will always be ways to hide data in the blockchain, but we don’t need to make it easy by giving users 100kB of OP_RETURN (which is explicitly intended for arbitrary data), and any harmful data that does end up in the chain at least requires third-party software to decode.

However, I wouldn’t be against invalidating multiple OP_RETURN outputs in a single transaction if that has support.

benthecarman commented at 1:42 am on October 27, 2025:

This BIP’s main goal is to require users wanting to store large unencrypted files in the blockchain to disguise the data as financial data and/or break it up into multiple data pushe

if that is the goal, why not just get rid of op_pushdata2/3

00w1 commented at 3:25 pm on October 26, 2025: none

Blocks with a height from (TBD) until and including 987424 are checked with these additional rules:

New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid. OP_PUSHDATA* with payloads larger than 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs. Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141 nor Taproot/BIP 341) is invalid. Witness stacks with a Taproot annex are invalid. Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid. Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid. Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.

It is possible to write the motivation, rationale etc. for these proposed changes without legality non sense. That would make it easier for reviewers and reduce the noise in the pull request.

jonatack commented at 3:50 pm on October 26, 2025: member

When will this be posted to the mailing list as its own thread so it can get greater attention & review?

I reached out yesterday to suggest this and apparently the post is currently in the ML queue for acceptance/publication.

benthecarman commented at 4:14 pm on October 26, 2025: contributor

why no limit on witness or tx size?

in bip-????.mediawiki:32 in 3c71823707

27+# New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.
28+# OP_PUSHDATA* with payloads larger than 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs.
29+# Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141 nor Taproot/BIP 341) is invalid.
30+# Witness stacks with a Taproot annex are invalid.
31+# Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid.
32+# Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid.

Rob1Ham commented at 4:37 pm on October 26, 2025:

This effectively prevents any other soft fork functionality for tap script to occur while this fork is active.

in bip-????.mediawiki:180 in 3c71823707

175+===Activation===
176+
177+Due to the unpredictable nature of the crisis this BIP addresses, we should move to limit on-chain data as quickly and orderly as possible, while being ready to react immediately in case illegal data appears in the chain before the new rules activate.
178+Thus this BIP presents two parallel methods of activation: the first proactive, the other reactive.
179+The proactive method involves a flag day activation of the rules, some time in early 2026. If no troublesome content appears in the chain, this BIP will activate smoothly via this proactive method.
180+If, however, some content appears in the chain that causes significant risks, we can fall back to the reactive method, which is a retroactive chain reorganization to invalidate the offending block (and any subsequent blocks) while immediately activating the new rules.

Jeremy-coding commented at 5:14 pm on October 26, 2025:

This “reactive method” is essentially a preplanned 51% attack, to initiate at an unknown time and according to very vaguely specified triggers?

What data can be produced showing miners will actually support or agree to such a chaotic rollback - especially given their history of apathy/unpredictable behaviour around other previous contentious forks?

Rob1Ham commented at 5:17 pm on October 26, 2025:

Also - what are the conditions of the “reactive method”? Organizing on something that isn’t block height or BIP-113 MTP is hard to coordinate.

Are we relying on one person to give the signal to then have the fork enforcement happen at a moments notice?

kwsantiago commented at 5:35 pm on October 26, 2025:

This “reactive method” is essentially a preplanned 51% attack, to initiate at an unknown time and according to very vaguely specified triggers?

This isn’t a 51% attack, it’s an emergency consensus change with historical precedent: examples being the 2010 inflation bug (16 hour rollback) and the 2013 accidental hardfork (5-day reorg). The trigger here isn’t vague, it’s illegal content creating immediate legal liability for node operators (specific block hash would be identified when/if it occurs). The BIP’s existence likely deters such attacks, likely making reactive deployment unnecessary. The proactive path (Feb 2026 flag day) is primary, while reactive is backup if illegal content appears first. The alternative, which is abandoning node operators facing legal jeopardy, is unacceptable.

what are the conditions of the “reactive method”?

Reactive activation could trigger when:

Contiguous data >10KB (not steganographic)
Severe legal risk (CSAM being clearest example)
Broad community consensus for reorg observed on mailing lists/social media.

This is necessarily subjective since this would be a content-based adversarial attack. Objectivity comes from nodes voluntarily choosing to enforce, and no one can force reorganization.

Jeremy-coding commented at 5:42 pm on October 26, 2025:

This isn’t a 51% attack, it’s an emergency consensus change with historical precedent

Potato, PoTAHto. What you believe is an “emergency consensus change” is someone else’s 51% attack. Both require sudden intervention of a coordinated majority of hashrate under chaotic conditions.

Broad community consensus for reorg observed on mailing lists/social media.

Haven’t altcoin communities been heavily mocked for making use of such “proof of social media” decision making? This seems quite ludicrous for a segment of the BTC community to feel like social-media based polling is ok for determining consensus upgrades (“when we do it, it’s ok/justified/necessary - otherwise it’s centralised shitcoining”).

kwsantiago commented at 5:48 pm on October 26, 2025:

Haven’t altcoin communities been heavily mocked for making use of such “proof of social media” decision making? This seems quite ludicrous for a segment of the BTC community to feel like social-media based polling is ok for determining consensus upgrades (“when we do it, it’s ok/justified/necessary - otherwise it’s centralised shitcoining”).

False equivalence. Altcoins use social consensus for governance decisions (features, monetary policy). This is about coordinating an emergency response to content that’s objectively illegal to possess in virtually all jurisdictions (CSAM). Not “should we add this feature?” but “there’s illegal content creating immediate legal liability, do we respond?”

The same coordination mechanism was used when the community faced the 2010 inflation bug (IRC/forums) and 2013 chain split (mailing lists). Emergency response always requires rapid coordination, the alternative is paralysis while node operators face prosecution.

Jeremy-coding commented at 5:53 pm on October 26, 2025:

Altcoins use social consensus for governance decisions (features, monetary policy). This is about coordinating an emergency response to content that’s objectively illegal to possess in virtually all jurisdictions (CSAM). Not “should we add this feature?” but “there’s illegal content creating immediate legal liability, do we respond?”

This isn’t a real distinction though. The scope of proposed change would certainly impact on BTC’s “features”. I’m not defending those features, I’m not really a fan of them myself (even the ones for supposedly “legitimate Layer 2s”), but it’s undeniable that this change materially impacts elements of BTC outside of CSAM prevention. BitVM is even mentioned in the document as potentially being affected, no doubt there are others too.

So really this is proof of social media.

arejula27 commented at 5:57 pm on October 26, 2025:

Still none defined ilegal content on bitcoin, it should be at least a clear definition not just “everyone knows what is illegal” because people has different ideologies and ethics.

dathonohm commented at 10:01 pm on October 26, 2025:

@Jeremy-coding I think it’s very unlikely that anyone, especially mining pools with large, prominent nodes, will want to stay on the old chain once it activates. Anyone, including mining nodes, is free to stay on the old chain. I just don’t expect that chain to garner much hashpower (nor industry support) once miners understand how much this new rule set lowers their liability with respect to the old chain. @Rob1Ham Indeed, coordinating the reactive method will be difficult. Large mining pools will ideally be paying close attention until this BIP activates, in order to react quickly if needed.

Jeremy-coding commented at 11:03 pm on October 26, 2025:

Maybe, maybe not. The history of Bitcoin is littered with chaos over supposedly predictable things - especially when it comes to any kind of fork (let alone an “emergency” one with an extremely short proposal > activation window).

In the case that the majority of miners ignore this sudden re-org (for their own inscrutable reasons, lack of time to be “properly educated” or whatever), what then? There will be no permanent damage to UTXO holders that are not transacting at the time of the crisis (which could occur at any moment) - but the reflection on BTC’s stability could be considerable. It’s also possible for unfortunate or foolish users to get scammed out of BTC in a variety of ways, ending up on a short-lived withering chain. Surely this kind of change requires not only miner buy-in, but probably also vocal support from exchanges as well - at a minimum?

bitcoin-eagle commented at 1:00 am on October 27, 2025:

Not “should we add this feature?”

This is softfork is confiscatory for taproot scripts.

Confiscation should have even greater depth of understanding and rationale than adding new features.

Currently we don’t even know which taproot scripts are subject to confiscation or how much bitcoin is already in taproot addresses that will become unspendable after this softfork

JackTyler4444 commented at 3:36 am on October 27, 2025:

This is the same template Canada state used to eventually supercede their charter of rights and freedoms and forcefully shutdown lawful protest-emergency act.

MarkJelic commented at 11:46 am on October 27, 2025:

If, however, some content appears in the chain that causes significant risks, we can fall back to the reactive method,

I have some real concerns about this… Who is going to be watching every transaction, detecting if there is a large Op_Return, and then trying to discern what type of data it is (PDF? JPEG? MP4?) and then making the call that it is reprehensible? That is a LOT of effort and transactions could be missed and still end up on the chain.

And then…

the reactive method, which is a retroactive chain reorganization to invalidate the offending block

I’ll be the first to admit that I am unsure of what this entails in full, but it doesn’t sound easy to do or free of cost. And I’d imagine the longer the offending transaction takes to discover, the larger the re-org will need to be.

Meanwhile, while the emergency has not been triggered, I would be very nervous to put any transaction on the chain.

I guess what I’m saying is: Screw this “emergency option”. It causes uncertainty as to how and when it will be activated and if Bitcoin will work during the re-org. I would rather, if the consensus is there, to immediately put it into action. Get it out there. If people are worried about the lockup (confiscation?) of funds for any length of time, then maybe make it shorter than a year… But make it happen ASAP.

We are all holding our breath and crossing our fingers that this doesn’t happen. I am dead set stressed about it. But let’s not “pray for good luck” before v30 gets too broadly deployed and triggers this by someone happening to find it. Let’s implement immediately (as soon as consensus is reached) so there is less anxiety about it, less work for the “watchers”, and send a clear signal to any bad actors.

in bip-????.mediawiki:25 in 3c71823707

20+
21+This document is licensed under the 3-clause BSD license.
22+
23+==Specification==
24+
25+Blocks with a height from (TBD) until and including 987424 are checked with these additional rules:

kwsantiago commented at 5:16 pm on October 26, 2025:

May want to add some language along the lines of:

These rules apply to all transactions equally, regardless of sender, receiver, or content. Enforcement is automatic and content-agnostic.

This preempts “selective censorship” arguments.

in bip-????.mediawiki:271 in 3c71823707

266+No.
267+While it isn't viable to merely continue running old nodes as-is, if users truly wish to reject this softfork (and explicitly endorse forcing other compatible nodes to store and distribute the illegal content in block <TODO:hash>), they can do so simply by checkpointing that block.
268+
269+There are certainly practical concerns to take into consideration:
270+rejecting this softfork may subject you to legal or moral consequences,
271+or could result in you splitting off to a new altcoin like Bcash.

Jeremy-coding commented at 5:22 pm on October 26, 2025:

Suggest “Bcash” -> “Bitcoin Cash (BCH)”

in bip-????.mediawiki:68 in 3c71823707

63+scriptPubKeys must be stored indefinitely in quick-access memory (often RAM) by all fully validating nodes.
64+It generally cannot be pruned.
65+It is also a direct cost to the sender rather than the receiver. For these reasons, modern usage is all 34 bytes or smaller in practice:
66+actual spending conditions have been moved to the witness, and the scriptPubKey simply commits to them in advance with a hash.
67+
68+'''What about OP_RETURN? Why not get rid of it entirely?'''

pinheadmz commented at 5:30 pm on October 26, 2025:

OPRETURN is a required component of Segregated Witness:

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure

in bip-????.mediawiki:86 in 3c71823707

81+'''Won't spammers just spread their data over multiple fields?'''
82+
83+While it is impossible to fully prevent steganography, limiting data sizes ensures such abuses are non-contiguous and obfuscated within another intended meaning (script code, structure, etc).
84+As far as Bitcoin is concerned, the data has some meaning other than the spammers' misinterpretation, and any external code to "reassemble" the unintended data is responsible for producing it
85+(it is possible to write code that transforms *any* data into any other data - what matters is that Bitcoin has a well-defined meaning that is distinct from the unsupported one).
86+This proposal also sends a clear message that data storage abuses in general (legal or otherwise) are unwelcome rather than sanctioned or supported.

thewrlck commented at 5:42 pm on October 26, 2025:

I’m not convinced that restricting or discouraging non-transactional data is the right approach. While limiting data size may reduce certain abuses, it also constrains legitimate use cases that leverage Bitcoin’s data-carrying capabilities (e.g. commitments, metadata, or novel protocols). From a consensus-layer perspective, Bitcoin should remain neutral about how data is interpreted or used, as long as it follows the defined rules and pays the required fees. Imposing normative judgments about “spam” risks introducing subjective policy where objective validation should suffice.

BitcoinMechanic commented at 6:13 pm on October 26, 2025:

It should suffice, but clearly doesn’t.

thewrlck commented at 6:57 pm on October 26, 2025:

Consensus validity plus the fee market are the intended mechanisms for resource allocation. If that model now seems insufficient, the problem may not be with neutrality itself, but with participants expecting consensus to enforce policy preferences.

dathonohm commented at 9:50 pm on October 26, 2025:

“Neutral interpretation” is the precise risk this BIP mitigates. Bitcoin does not, and should not, support arbitrary data storage for anything larger than 80 bytes (and even this is potentially too much. “Support” for up to 80 bytes in OP_RETURN does not exist because Bitcoin officially supports data storage as a use case; it merely exists in order to prevent more harmful methods of data storage, such as fake pubkeys).

All non-OP_RETURN data should be officially interpreted as financial data.

thewrlck commented at 4:55 am on October 27, 2025:

The claim that only “financial” data should be valid assumes a shared definition of “financial”. A hash pre-image in a covenant, a commitment to an external state, or even a Lightning channel anchor is arguably non-transactional data that still underpins monetary functionality.

Bitcoin’s strength lies in not having to interpret these distinctions. Neutrality doesn’t endorse arbitrary storage; it avoids turning consensus into a content filter.

thewrlck commented at 5:45 pm on October 26, 2025: none

I don’t think it’s a good idea to outright prevent content or actions that are not 100% certain spam

in bip-????.mediawiki:189 in 3c71823707

184+
185+TODO
186+
187+===Reactive Deployment===
188+
189+'''Doesn't this proposal activate too soon?'''

arejula27 commented at 5:50 pm on October 26, 2025:

It has deep implications for Tapscript and should be reviewed carefully before merging. Doing things hastily and following predictions from developers without allowing the whole community to analyze the implications is not prudent and should not be done. The BIP does not clearly explain what would happen to current scripts on the chain (as @mononaut pointed out before) or to future Tapscript updates. All implications should be studied and explained to the community instead of trying to quickly propose a soft fork because of developer pressure or perceived urgency

dathonohm commented at 10:04 pm on October 26, 2025:

See reply to @mononaut

in bip-????.mediawiki:402 in 3c71823707

397+
398+If there is community support for reducing block sizes, it should therefore be done separately and calmly, after the network has settled down.
399+
400+'''Why not activate CTV at the same time?'''
401+
402+CTV is still controversial with a minority of the community, and bundling it with an emergency softfork could be seen as an attempt to trick/force it on the network.

shocknet-justin commented at 5:54 pm on October 26, 2025:

This minority comment is backhanded and misleading. CTV has no monetary purpose, it’s only achieves delegation to centralized applications and therefore application stack “Bithereum” use-cases, not monetary ones. The overwhelming majority of the community sees Bitcoin as money, consistent with this BIP.

Rob1Ham commented at 6:27 pm on October 26, 2025:

Factually incorrect, as CTV can be used for vaulting.

BitcoinMechanic commented at 6:36 pm on October 26, 2025:

CTV certainly has monetary uses.

shocknet-justin commented at 6:44 pm on October 26, 2025:

Factually incorrect, as CTV can be used for vaulting.

Vaults are applications, not money.

shocknet-justin commented at 6:45 pm on October 26, 2025:

CTV certainly has monetary uses.

Not a single one, the entire premise is delegation to apps.

Rob1Ham commented at 6:46 pm on October 26, 2025:

Factually incorrect, as CTV can be used for vaulting.

Vaults are applications, not money.

In the sense that lightning isn’t money, but an application of money, and that multisig is an application of money doing joint custody, and in that sense the definition isn’t useful at all.

arejula27 commented at 6:52 pm on October 26, 2025:

Same es rollups and side chains

shocknet-justin commented at 6:58 pm on October 26, 2025:

In the sense that lightning isn’t money, but an application of money, and that multisig is an application of money doing joint custody, and in that sense the definition isn’t useful at all.

If your implication is that ancient past changes justify any and all future changes that’s a logical fallacy. Lightning and multisig are also not centralized applications requiring delegation, a user with control of their own funds has no use for covenants, they are merely a boundary for remote control.

Rob1Ham commented at 7:01 pm on October 26, 2025:

In the sense that lightning isn’t money, but an application of money, and that multisig is an application of money doing joint custody, and in that sense the definition isn’t useful at all.

If your implication is that ancient past changes justify any and all future changes that’s a logical fallacy. Lightning and multisig are also not centralized applications requiring delegation, a user with control of their own funds has no use for covenants, they are merely a boundary for remote control.

That also is untrue, as you can be in control of all keys within a CTV vault.

shocknet-justin commented at 7:07 pm on October 26, 2025:

That also is untrue, as you can be in control of all keys within a CTV vault.

The premise of vaults is clawing back unauthorized remote control, which either complicates Bitcoin’s use as payment or the conditions for accepting it as payment also apply to attackers thereby undermining the vault.

shocknet-justin commented at 7:10 pm on October 26, 2025:

Same es rollups and side chains

Centralized apps. Not money.

dathonohm commented at 10:13 pm on October 26, 2025:

@shocknet-justin This BIP officially offers no stance on CTV, other than to point out that it appears to be popular, and that if it indeed has consensus, a year from now could be a good time to activate it.

bitcoin deleted a comment on Oct 26, 2025

jonatack commented at 8:43 pm on October 26, 2025: member

When will this be posted to the mailing list as its own thread so it can get greater attention & review?

Hi all, a mailing list post by has been published by the BIP author at https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8.

Post conceptual feedback and meta-commentary there, and focus here on:

expert technical review of the specification
specific, concrete, helpful proposals for the other sections

Please refrain from personal or heated commentary in both venues. I’ve attempted some minor moderation here above.

in bip-????.mediawiki:179 in 3c71823707

174+
175+===Activation===
176+
177+Due to the unpredictable nature of the crisis this BIP addresses, we should move to limit on-chain data as quickly and orderly as possible, while being ready to react immediately in case illegal data appears in the chain before the new rules activate.
178+Thus this BIP presents two parallel methods of activation: the first proactive, the other reactive.
179+The proactive method involves a flag day activation of the rules, some time in early 2026. If no troublesome content appears in the chain, this BIP will activate smoothly via this proactive method.

Ali2kCom commented at 8:47 pm on October 26, 2025:

I believe that if this softfork is deployed as a Proactive Deployment with a mandatory Flag Day signaling, we would no longer need to worry about the risk of a chain split in the event of a CSAM incident (or any other large data payload abuse).

petertodd commented at 10:25 pm on October 26, 2025: contributor

NACK

The fact that transaction txid 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c contains the full text of this BIP as of writing, while also being compliant with this BIP shows how utterly ineffective this approach is.

saltduck commented at 11:02 pm on October 26, 2025: none

Concept ACK

NEEDcreations commented at 11:38 pm on October 26, 2025: none

Bitcoin is money!

wizkid057 commented at 1:23 am on October 27, 2025: none

Concept ACK

The fact that transaction txid […] contains the full text of this BIP as of writing, while also being compliant with this BIP shows how utterly ineffective this approach is.

By needing to resort to data obfuscated as code vs using the only sanctioned method of data carrying (OP_RETURN) in order to comply with the BIP, you’ve in fact actually just proven that the BIP can be completely effective at mitigating the outlined risks. So, thanks for proving that point for everyone.

bitcoin-eagle commented at 1:26 am on October 27, 2025: none

NACK confiscatory for existing taproot addresses

Rob1Ham commented at 1:38 am on October 27, 2025: none

I’ve run some initial tests, the miniscript compiler will use OP_IF and OP_NOTIF for taproot descriptors if you don’t break it out spending conditions into specific tapleafs explicitly, so this would be freezing those funds on chain (or confiscating if this was extended indefinitely).

Rob1Ham commented at 1:40 am on October 27, 2025: none

Concept ACK

The fact that transaction txid […] contains the full text of this BIP as of writing, while also being compliant with this BIP shows how utterly ineffective this approach is.

By needing to resort to data obfuscated as code vs using the only sanctioned method of data carrying (OP_RETURN) in order to comply with the BIP, you’ve in fact actually just proven that the BIP can be completely effective at mitigating the outlined risks. So, thanks for proving that point for everyone.

If that was the point, the proposed soft fork would only be narrowly limiting to OP_RETURN, and not MAST and OP_IF.

wizkid057 commented at 1:55 am on October 27, 2025: none

If that was the point, the proposed soft fork would only be narrowly limiting to OP_RETURN, and not MAST and OP_IF.

It’s one point of many.

Addressing simple low hanging fruit currently exploited or that could obviously be exploited makes perfect sense for a soft fork intended to limit arbitrary data.

To be clear as well, there is no confiscation risk here at all. At worst there is a potential inconvenience risk to some outlier edge cases that may or may not exist. But as a temporary soft fork those issues can be addressed without the need to hard fork to refine these changes.

kwsantiago commented at 1:59 am on October 27, 2025: none

I’ve run some initial tests, the miniscript compiler will use OP_IF and OP_NOTIF for taproot descriptors if you don’t break it out spending conditions into specific tapleafs explicitly, so this would be freezing those funds on chain (or confiscating if this was extended indefinitely). @Rob1Ham Important finding. Can you share which miniscript implementations and provide example descriptor/s that generates OP_IF/OP_NOTIF?

Two possible solutions:

Pre-activation UTXO exemption (which could also be used for the taproot control block issue where coins can become unspendable)
Narrow restriction to OP_IF with unexecuted push data >256 bytes (targets spam, not legitimate branching)

Rob1Ham commented at 2:06 am on October 27, 2025: none

I’ve run some initial tests, the miniscript compiler will use OP_IF and OP_NOTIF for taproot descriptors if you don’t break it out spending conditions into specific tapleafs explicitly, so this would be freezing those funds on chain (or confiscating if this was extended indefinitely).

@Rob1Ham Important finding. Can you share which miniscript implementations and provide example descriptor/s that generates OP_IF/OP_NOTIF?

Two possible solutions:

Pre-activation UTXO exemption (which could also be used for the taproot control block issue where coins can become unspendable)

Narrow restriction to OP_IF with unexecuted push data >256 bytes (targets spam, not legitimate branching)

Miniscript as is will use fragments that leverage OP_IF/OP_NOTIF if you don’t break out each spending conditions (where you’d use an OR) into a separate leaf.

If you declare each spending condition to be its own tap leaf, it won’t use OP_IF/OP_NOTIF (from my limited testing, reviewing the rust-miniscript compiler would determine if they do appear with tap script).

OpenSauce21 commented at 4:16 am on October 27, 2025: none

NACK. This proposal provides an economic incentive for on chain CSAM.

A bad actor who wants to conduct a double spend attack, could put CSAM on chain to cause a re-org and succeed with the attack.

BitcoinMechanic commented at 9:17 am on October 27, 2025: none

I think the language needs work.

The original draft offered by Luke assumed a post-hoc fixing of a block containing untenable content which this BIP does not offer as the preferred approach thereby making the multiple references to legal implications needlessly inflammatory.

Therefore I suggest removing them so that we can focus on technical concerns around what these new rules would limit - of which there are a couple but are getting drowned out.

Certainly for me the benefit of reducing arbitrary data is that it makes Bitcoin a more efficient monetary system and helps preserve decentralization of nodes so this BIP makes sense on that basis alone.

BullishNode commented at 11:51 am on October 27, 2025: none

The following are unrelated to the stated motivation of the BIP (and its sense of urgency) which is to address potential issues from OP_RETURN relay policy changes introduced in Bitcoin Core 30

Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141 nor Taproot/BIP 341) is invalid.
Witness stacks with a Taproot annex are invalid.
Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid.
Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid.
Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.

MarkJelic commented at 11:59 am on October 27, 2025: none

The fact that transaction txid 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c contains

Does it? I followed that link to the transaction on Mempool. I can’t see anything other than a lot of inputs into a transaction and it costing $110… How can I see what you are claiming?

MarkJelic commented at 12:01 pm on October 27, 2025: none

A bad actor who wants to conduct a double spend attack, could put CSAM on chain to cause a re-org and succeed with the attack.

If this is the case, then I suggest to implement this ASAP, rather than give a bad actor the ability to plan the attack.

MarkJelic commented at 12:09 pm on October 27, 2025: none

Concept ACK

However, if the Code consensus approved, I suggest deployment immediately, rather than watching (and possibly missing) and waiting for an attack that could well be co-ordinated with a double-spend, in anticipation of the “reactive deployment”. If the code is sound, deploy ASAP.

ArmchairCryptologist commented at 12:57 pm on October 27, 2025: none

Does it? I followed that link to the transaction on Mempool. I can’t see anything other than a lot of inputs into a transaction and it costing $110… How can I see what you are claiming?

That’s the point, isn’t it? This is exactly how the theorized CSAM and any other “illegal data” would look on the blockchain, no matter if it’s encoded in an OP_RETURN, or multiple OP_RETURNs, or in the witness using the OP_FALSE OP_IF trick, or in the 20-of-20 tapscript multisig theorized by Anthony Towns on the mailing list which supposedly is more effective than OP_RETURN but indistinguishable from a “real” tapscript multisig, or any of the other of the myriad of ways you could possibly encode data into a transaction.

You can block some of them, but it is literally impossible to block all of them. And crucially, no matter the method used to encode the data, you would always need some sort of viewer that knows how to assemble and present the data - the only difference is how complicated it would be to reassemble. And without said viewer, you cannot generally be be said to “possess” the data legally.

Fun fact: for any randomly generated data, there exists a decryption algorithm and a decryption key to turn it into literally any data you want. Simplistic example: XOR-based “encryption” with an “encryption key” that is just the random data XOR’ed with the data you want to turn it into.

OpenSauce21 commented at 1:10 pm on October 27, 2025: none

A bad actor who wants to conduct a double spend attack, could put CSAM on chain to cause a re-org and succeed with the attack.

If this is the case, then I suggest to implement this ASAP, rather than give a bad actor the ability to plan the attack.

Can you explain how implementing now would stop that from happening?

Also the problem goes beyond the one hypothetical attacker. Anyone that transacted in blocks that get re-orged can also double-spend their transaction with RBF, not just the attacker.

MarkJelic commented at 1:36 pm on October 27, 2025: none

Can you explain how implementing now would stop that from happening?

As I have stated, I cannot review the Code itself. But assuming the Code works as intended, without any detriment… Then doesn’t implementing it immediately remove any uncertainty as to how the chain is being constructed from that point forward? Am I missing something?

Also the problem goes beyond the one hypothetical attacker. Anyone that transacted in blocks that get re-orged can also double-spend their transaction with RBF, not just the attacker.

Agreed. And hence it is best to just make it Go Live immediately (assuming Code is good) rather than waiting for some objectionable material to surface and hoping it gets detected/caught quickly.

OpenSauce21 commented at 1:45 pm on October 27, 2025: none

Can you explain how implementing now would stop that from happening?

As I have stated, I cannot review the Code itself. But assuming the Code works as intended, without any detriment… Then doesn’t implementing it immediately remove any uncertainty as to how the chain is being constructed from that point forward? Am I missing something?

Also the problem goes beyond the one hypothetical attacker. Anyone that transacted in blocks that get re-orged can also double-spend their transaction with RBF, not just the attacker.

Agreed. And hence it is best to just make it Go Live immediately (assuming Code is good) rather than waiting for some objectionable material to surface and hoping it gets detected/caught quickly.

The detriment comes from the proposal itself. There is currently no economic incentive to put illegal material on chain. Activating this would change that. So i’m not sure how activating immediately would address this. Again this creates a much larger surface area than a single attacker(anyone who transacts in the re-org block).

Rob1Ham commented at 1:52 pm on October 27, 2025: none

Why does this request not block P2PK & P2MS for future spends?

Putting data in raw pubkeys using these payment methods is the most harmful way of embedding arbitrary data by bloating the utxo set.

in bip-????.mediawiki:398 in 3c71823707

393+'''Why not reduce the block weight/size limit too?'''
394+
395+It is possible this softfork may activate before miners have fully upgraded.
396+To ensure continuity of Bitcoin through a potentially low-hashrate period, we must assume there's a possibility of each block taking 10 times as long as intended (ie, ~2 hours per block), which would mean 4 MWU per block would be a mere 333 kWU per 10 minutes.
397+
398+If there is community support for reducing block sizes, it should therefore be done separately and calmly, after the network has settled down.

kevkevinpal commented at 2:24 pm on October 27, 2025:

I think the wording at the end is fairly subjective. And the community can still fork not calmly, and if the network has not settled down.

0If there is community support for reducing block sizes, it should therefore be done separately.

BitcoinErrorLog commented at 2:47 pm on October 27, 2025: contributor

NACK

I move to remove this BIP from consideration due to breaking the user space, explicitly requiring a hard fork, being obviously contentious, being anti-consensus, and being entirely motivated by subjective and speculative predictions about how uninvolved entities may behave outside of the protocol.

BIPs are for specifying methods of applying Bitcoin and adding rules to its protocol afaik. This BIP, and Ocean’s efforts, are about disrupting Core, bringing attention to the Ocean team, and legitimizing a need for regulation on miners.

If it doesn’t already exist, BIP reviewers should be obligated to define & enforce policies that reject BIPs that are toxic, without alienating BIPs that are merely unpopular.

I am not convinced that anyone here cares about spam or lawyers, or that there is a spam problem at all.

If they want a hard fork, they can also hard fork this BIP repo for their new blockchain and stay out of this one.

Please close this, thank you for your patience and work.

in bip-????.mediawiki:3 in 3c71823707

0@@ -0,0 +1,437 @@
1+<pre>
2+  BIP: ?
3+  Layer: Consensus (soft fork)

BitcoinErrorLog commented at 2:52 pm on October 27, 2025:

Adding then removing rules requires a hard fork.

Rob1Ham commented at 2:55 pm on October 27, 2025:

I think technically, to have a soft fork with a predetermined height for how long it is active is a soft fork. Because the loosening of the rules are predefined in the tightning of the rules aspect of the BIP.

That said, any soft fork activated during this ~1 year window this BIP would be active using an OP_SUCCESS, the annex, larger op_returns, or tap trees larger than 128 leaves during this window WOULD be a HARD fork when they would otherwise be a soft fork.

in bip-????.mediawiki:4 in 3c71823707

0@@ -0,0 +1,437 @@
1+<pre>
2+  BIP: ?
3+  Layer: Consensus (soft fork)
4+  Title: Reduced Data Temporary Softfork

BitcoinErrorLog commented at 2:52 pm on October 27, 2025:

Temporary Soft Fork AND Hard Fork

in bip-????.mediawiki:37 in 3c71823707

32+# Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid.
33+# Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.
34+
35+==Motivation==
36+
37+The recent release of Bitcoin Core 30 presents a severe threat to Bitcoin's viability.

BitcoinErrorLog commented at 2:57 pm on October 27, 2025:

Subjective judgements are off-topic to BIP specifications, particularly lacking evidence. There is no consensus this is true. Fallacious.

Reduced Data Temporary Softfork #2017