Reduced Data Temporary Softfork #2017
Conversation
|
|
||
| TODO | ||
|
|
||
| ===Reactive Deployment=== |
There was a problem hiding this comment.
It's not clear to me why have these two headers, Proactive Deployment and Reactive Deployment, both here under Activation and below under Deployment.
There was a problem hiding this comment.
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.
dathonohm
force-pushed
the
reduced-data
branch
from
5314635 to
3c71823
Compare
|
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. |
|
@rot13maxi see the deployment section 
|
|
There is opportunity to also discuss the effect on DoS blocks and the scope of legacy script as a DoS vector. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
| The true danger lies not merely in the release existing, but in its adoption. | ||
| 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. | ||
|
|
||
| This official sanction creates an immediate and severe threat. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
"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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
|
|
||
| This official sanction creates an immediate and severe threat. | ||
| The threat here is distinct from general spam or economic costs, which are typically handled with policy and the fee market. | ||
| 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. |
There was a problem hiding this comment.
"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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Agree with Blake. Precise definitions were never proposed nor required. Lopp's comments are rejected.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Nack
This change is motivated on outside factors and interpretation of the data (legal and political) and not on how the software functions.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
curious if you can point to an opinion from counsel that expands on the legal risks described in the bip
There was a problem hiding this comment.
"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.
| This official sanction creates an immediate and severe threat. | ||
| The threat here is distinct from general spam or economic costs, which are typically handled with policy and the fee market. | ||
| 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. | ||
| This directly threatens the ability and/or willingness of common people to run fully validating nodes due to the resulting legal and moral risks. |
There was a problem hiding this comment.
Again, "legal and moral risks" could use much more precise definition.
There was a problem hiding this comment.
Again, precise definitions were never proposed nor required.
There was a problem hiding this comment.
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.
|
|
||
| A core principle of Bitcoin is "don't trust, verify". | ||
| 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". | ||
| 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. |
There was a problem hiding this comment.
This has always been the case.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Agreed. The phrasing should focus on minimizing legal scope in general.
| A core principle of Bitcoin is "don't trust, verify". | ||
| 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". | ||
| 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. | ||
| This unacceptable dilemma directly undermines the incentive to validate, leading to inevitable centralization and posing an existential threat to Bitcoin's security model. |
There was a problem hiding this comment.
But this has always been the case...
There was a problem hiding this comment.
Doesn't mean it needs to stay that way, or that we need to make the situation worse.
There was a problem hiding this comment.
There is general consensus that sketchy content should not be on bitcoin, and that most node operator would support this change.
There was a problem hiding this comment.
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).
|
|
||
| '''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?''' | ||
|
|
||
| Bitcoin is money, not speech. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
money is speech, but not all speech is money. You must understand the difference, making this comment clearly in bad faith.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| 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. | ||
|
|
||
| Illegal data is completely different: | ||
| nodes are not merely recording that it happened, they are active participants in storing and distributing the illegal content itself. |
There was a problem hiding this comment.
The veracity of this claim is highly disputed. https://protos.com/exclusive-lawyers-call-bitcoin-core-v30-csam-concerns-overblown/
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| However, it fails when transactions impose externalities that are not properly weighed against the transaction fee. | ||
|
|
||
| In this case, the externality is the existential legal and moral liability imposed on every node operator. | ||
| No transaction fee can compensate for the risk of imprisonment or the moral burden of distributing abhorrent content. |
There was a problem hiding this comment.
"moral liability" and "moral burden" are poorly defined.
There was a problem hiding this comment.
Again, precise definitions were never proposed nor required.
There was a problem hiding this comment.
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
| In this case, the externality is the existential legal and moral liability imposed on every node operator. | ||
| No transaction fee can compensate for the risk of imprisonment or the moral burden of distributing abhorrent content. | ||
|
|
||
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Wouldn't such an approach lead to more node centralization a reduce Bitcoin's network effects?
There was a problem hiding this comment.
This applies to both pro and con arguments of this BIP and therefore an irrelevant comment.
There was a problem hiding this comment.
@jlopp Not sure the relevance? This fork changes consensus rules.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
If the rules of the networks are wrong and do not reflect the will of the majority, the rules can eventually change.
This is exactly what an ETH guy would tell you about Ethereum.
| 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. | ||
|
|
||
| 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. | ||
| If no further action is taken by you, it will expire in a year. |
There was a problem hiding this comment.
Needs further rationale as to why it's safe to automatically remove protections that are supposedly needed to stop an existential crisis.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
What could be undesirable effects of this temporary softfork?
There was a problem hiding this comment.
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.
| OP_RETURN outputs are provably unspendable, and nodes do not need to store it in the UTXO set. | ||
| 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. | ||
| 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. | ||
| However, to avoid breaking legacy protocols that still include such outputs, this proposal allows these outputs. |
There was a problem hiding this comment.
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.
|
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) |
| '''Is this unprecedented?''' | ||
|
|
||
| No. | ||
| Bitcoin has deployed emergency softforks, including chain splits, in at least two past occasions: |
There was a problem hiding this comment.
Is there an emergency regarding spam on-chain? If there was an emergency, wouldn't fees be very high?
However, fees seem to be at all time lows
What am I missing?
Or is this softfork only motivated by legal concerns, not spam?
There was a problem hiding this comment.
It seems to be motivated by both legal concerns and spam. This is not necessarily something that would be reflected in fees.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| # 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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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'?
|
According to BIP-2:
When will this be posted to the mailing list as its own thread so it can get greater attention & review? |
|
|
||
| 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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
It increases the cost (multiple outputs) and discourage the use of OP_RETURN for arbitrary data.
This comment has been minimized.
This comment has been minimized.
I reached out yesterday to suggest this and apparently the post is currently in the ML queue for acceptance/publication. |
| 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. | ||
| Thus this BIP presents two parallel methods of activation: the first proactive, the other reactive. | ||
| 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. | ||
| 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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").
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. You think it is, because it supports a change you want. But 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, calling it a "false equivalence" is just cope the exact same way that altcoiners find some reason to justify to themselves that their social-media driven forks are permissible.
There was a problem hiding this comment.
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.
| In some ways, yes: | ||
| it only requires a significant minority to succeed; | ||
| miners need to upgrade to continue mining, and are incentivised to do so; | ||
| actual rejection requires a counter-softfork (aka URSF); etc. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
| # 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. |
There was a problem hiding this comment.
This effectively prevents any other soft fork functionality for tap script to occur while this fork is active.
| 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. | ||
| Thus this BIP presents two parallel methods of activation: the first proactive, the other reactive. | ||
| 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. | ||
| 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. |
There was a problem hiding this comment.
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?
|
|
||
| A core principle of Bitcoin is "don't trust, verify". | ||
| 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". | ||
| 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. |
There was a problem hiding this comment.
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.
|
|
||
| This official sanction creates an immediate and severe threat. | ||
| The threat here is distinct from general spam or economic costs, which are typically handled with policy and the fee market. | ||
| 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. |
There was a problem hiding this comment.
"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.
| '''Is this unprecedented?''' | ||
|
|
||
| No. | ||
| Bitcoin has deployed emergency softforks, including chain splits, in at least two past occasions: |
There was a problem hiding this comment.
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.
| In fact, that is an important part of its purpose: | ||
| to keep the illegal content storage in block <TODO:hash> out of Bitcoin. | ||
|
|
||
| To achieve this, the softfork must activate retroactively, invalidating that block and all its descendants. |
There was a problem hiding this comment.
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.
|
|
||
| '''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?''' | ||
|
|
||
| Bitcoin is money, not speech. |
There was a problem hiding this comment.
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.
| 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. | ||
| This unacceptable dilemma directly undermines the incentive to validate, leading to inevitable centralization and posing an existential threat to Bitcoin's security model. | ||
|
|
||
| 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. |
There was a problem hiding this comment.
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.
| 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. | ||
|
|
||
| Illegal data is completely different: | ||
| nodes are not merely recording that it happened, they are active participants in storing and distributing the illegal content itself. |
There was a problem hiding this comment.
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.
| 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. | ||
|
|
||
| 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. | ||
| If no further action is taken by you, it will expire in a year. |
There was a problem hiding this comment.
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.
|
|
||
| ==Specification== | ||
|
|
||
| Blocks with a height from (TBD) until and including 987424 are checked with these additional rules: |
There was a problem hiding this comment.
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.
|
|
||
| There are certainly practical concerns to take into consideration: | ||
| rejecting this softfork may subject you to legal or moral consequences, | ||
| or could result in you splitting off to a new altcoin like Bcash. |
There was a problem hiding this comment.
Very ironic to slander BCH as "Bcash" while proposing a critical emergency fork with a rushed activation on the premises that otherwise Bitcoin will imminently die. Nothing in this BIP protects activators from being the ones ending up on the minority chain (nor can it, that's a social/economic problem only resolvable in practice once it happens).
In the interests of professionalism at least, recommended to update to "Bitcoin Cash (BCH)".
| 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: | ||
| actual spending conditions have been moved to the witness, and the scriptPubKey simply commits to them in advance with a hash. | ||
|
|
||
| '''What about OP_RETURN? Why not get rid of it entirely?''' |
There was a problem hiding this comment.
OPRETURN is a required component of Segregated Witness:
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure
| '''Why limit other data to 256/257 bytes?''' | ||
|
|
||
| With modern compression, it is plausible to represent objectionable images (often illegal to even possess) in as few as 300-400 bytes. | ||
|
|
||
| 256 bytes (2048 bits) is also more than sufficient for reasonably large numbers that might be potentially needed in legitimate cryptography, reinforcing Bitcoin's intended purpose as a financial network. | ||
|
|
||
| '''Won't spammers just spread their data over multiple fields?''' | ||
|
|
||
| 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). | ||
| 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 | ||
| (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). | ||
| This proposal also sends a clear message that data storage abuses in general (legal or otherwise) are unwelcome rather than sanctioned or supported. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
It should suffice, but clearly doesn't.
There was a problem hiding this comment.
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.
| The true danger lies not merely in the release existing, but in its adoption. | ||
| 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. | ||
|
|
||
| This official sanction creates an immediate and severe threat. |
There was a problem hiding this comment.
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?
|
|
||
| ===Reactive Deployment=== | ||
|
|
||
| '''Doesn't this proposal activate too soon?''' |
There was a problem hiding this comment.
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
|
|
||
| '''Why not activate CTV at the same time?''' | ||
|
|
||
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Factually incorrect, as CTV can be used for vaulting.
There was a problem hiding this comment.
CTV certainly has monetary uses.
There was a problem hiding this comment.
Factually incorrect, as CTV can be used for vaulting.
Vaults are applications, not money.
There was a problem hiding this comment.
CTV certainly has monetary uses.
Not a single one, the entire premise is delegation to apps.
There was a problem hiding this comment.
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.
|
This is pleb slop |
31 participants
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.