BIP draft: Reduced Data Temporary Softfork #2017

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.

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.

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.

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?

“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?

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.

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.

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.

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.

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.

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?

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.

“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.

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.

good news is that Bitcoin was designed to be censorship resistant

You forgot to include the “peer-to-peer electronic cash system”. The accurate sentence is “good news is that Bitcoin was designed to be a peer-to-peer electronic cash system that is censorship resistant”. Taking into the account, an “electronic cash system censorship resistant will be resistant to attempts to censor financial transactions, and not resistant to censor unrelated content which is out of the scope of the primary purpose of the protocol.

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.

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.

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.

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.

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.

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.

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.

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

@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.

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.

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.

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)” ?

Rationally, you can only define all, or none, of the transactions as spam. The only ones I actually care about are the ones coming to and from me. Delete the rest! /s

An effort to subjectively define spam results in goalpost-moving every time people find an excuse to fill cheap blockspace. It also results in a culture and potential obligation around identifying and censoring objectionable txns.

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).

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

1. It’s non-contiguous and obfuscated
2. External code would be needed to reassemble it (making that code responsible, not Bitcoin)
3. 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.

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.

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

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

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?

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.

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.

@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.

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.

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.

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.

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.

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.

@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.

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

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

On the other side of the coin, limiting a node from being able to filter the mempool as the node operator desires is a limitation on their right to speak (transmit) their beliefs.

Por outro lado, limitar a capacidade de um nó de filtrar o mempool conforme o operador do nó deseja é uma limitação ao seu direito de falar (transmitir) suas crenças.

Good thing Core didn’t do that

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.

We all agree that Bitcoin is a decentralized monetary protocol. Most will also agree that we should limit as much as possible the non-monetary transactions (aka spam). That said, IMO the filters or this soft fork only buys us some time; a market-based “permanent” solution is needed.

Assuming the growth of genuine money use (savings, remittances, settlements) naturally outbids spam, how do we grow BTC adoption from SoV primarily to one that not only includes but promotes MoE?

Otherwise, users will keep treating Bitcoin as a vault, not a medium of exchange — leaving block space underutilized and open to spammy exploitation — a potential issue both Jack Dorsey and Jeff Booth have warned us about.

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.

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.

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.

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.

“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.

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

“Won’t this hurt miners by reducing the fee revenue they could earn from large data transactions?”

Another extra point I see here is if a miner has collected (instead of discarding/rejecting) an offending transaction, mined and processed a block, then pushed/distributed it to all other nodes where they can’t do anything about it (aside from shutting their node down for good), all so they can get a little bit more revenue, there is now evidance that they have commited this potential crime where they are now at high risk of having their operation shut down, potentially having their equipment and funds seized, and potentially face jail/prison time.

With this in mind, the potential financial positives for miners are minuscule in comparison to the financial destruction that they’d face.

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).

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.

The temporary nature allows three things:

1. Immediate protection while better long-term solutions are developed (avoiding “perfect is the enemy of good”)
2. Evaluation period to see if these limits harm legitimate use cases (if they don’t, make it permanent; if they do, refine)
3. 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.

Can this instead be measured in number of blocks?

it will expire in a year

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

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?

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.

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

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.

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.

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

i’d like to add that there is a third risk: allowing large op_returns will cause mempool congestion. if legitimate monetary transactions take longer to get written, we will be heading towards a second blocksize war.

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?

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.

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.

@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?

@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

this proposal in its current form almost certainly will result in funds being at least frozen for a year

“At least” is a big hedge, since you could absolutely lose funds. For example, if you had to spend a leaf to claim funds after a hash-reveal, but it’s too deep to actually spend from, your counterparty might be able to key spend (or shallow-leaf spend) a ‘refund’ before the temporary window ended.

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.

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

Invalidates signed but unbroadcast txs with P2PK or bare P2MS outputs (compressed or not). P2PK is currently standard, and so is bare P2MS up to x-of-3.

P2PKH has a bigger lifetime size footprint than P2PK.

Invalidates signed but unbroadcast txs with P2PK or bare P2MS outputs (compressed or not). P2PK is currently standard, and so is bare P2MS up to x-of-3.

P2PKH has a bigger lifetime size footprint than P2PK.

what if instead of a hard 43 bytes, we do the following:

1. OP_RETURN: Limited to 83 bytes (as proposed)
2. Taproot witness data: Limited to reasonable script sizes (~400 bytes?)
3. Ban specific inscription patterns (OP_FALSE OP_IF …) in Taproot
4. All other transaction types: Unchanged

Rationale:

• Ordinals/inscriptions use specific patterns in Taproot - we can target those
• No need to restrict ALL scriptPubKeys to 34 bytes
• P2PK, bare multisig continue working
• Pre-signed transactions remain valid
• Implementation is simpler (pattern matching vs size checking all outputs)

what if instead of a hard 43 bytes, we do the following:

1. OP_RETURN: Limited to 83 bytes (as proposed)

2. Taproot witness data: Limited to reasonable script sizes (~400 bytes?)

3. Ban specific inscription patterns (OP_FALSE OP_IF ...) in Taproot

4. All other transaction types: Unchanged

As @portlandhodl pointed out in his own mailing list post a few weeks back a natural limit for witness data could be 520 bytes since it’s downstream from the max script element size.

Though NACK on eliminating OP_FALSE & OP_IF. These are fundamental script primitives. Justifying eliminating them because they’re ‘specific inscription patterns’ seems foolhardy since it’s set the precedence that any future storage pattern should also have contributing op codes eliminated.

Invalidates signed but unbroadcast txs with P2PK or bare P2MS outputs (compressed or not). P2PK is currently standard, and so is bare P2MS up to x-of-3.

If someone can show me a pre-RDTS example of someone actually doing this, I will consider amending the BIP.

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?

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?

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:

1. Contiguous data >10KB (not steganographic)
2. Severe legal risk (CSAM being clearest example)
3. 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.

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.

3. 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”).

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.

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.

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?

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

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.

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.

OPRETURN is a required component of Segregated Witness:

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

“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.

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.

Factually incorrect, as CTV can be used for vaulting.

Vaults are applications, not money.

CTV certainly has monetary uses.

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

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.

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.

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.

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.

Same es rollups and side chains

Centralized apps. Not money.

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.

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.

A soft fork narrows the valid block set (S -> S′). Reverting back expands it (S′ -> S). Expansions are hard forks. It doesn’t matter if the expansion is predefined. Consensus isn’t about intentions in a BIP, it’s about what nodes actually enforce at that time.

Once the temporary rules are active, nodes are validating under S′. When the window ends, those same nodes will reject blocks valid under S unless they upgrade. That’s coordination risk, and a hard fork in practice.

Consensus changes are economic not semantic. The market decides what’s valid. Any rule that requires synchronized expiry or scheduled reversal is governance, not consensus.

So … adding rules is a soft fork. Removing them later is a hard fork.

@BitcoinErrorLog I think right in your conclusion that the proposal isn’t well considered or constructed. But it does appear to limit its scope “Blocks with a height from (TBD) until and including 987424 are checked with these additional rules”.

This means that if blocks past 987424 don’t apply those rules they will be accepted by this proposal. In effect it is never ‘removed’ but becomes inactive. And so it isn’t a relaxing of a rule but a limitation on scope of the rule, temporally.

Of course, without an implementation there is uncertainty in what an implementation actually would do– perhaps there is another way to read the text.

It is not subjective judgment because it can be logically deduced by analyzing the statement:

• “release of Bitcoin Core 30”. What this release does? Expand default settings in such way that it makes it easier to include large arbitrary data in a transaction output.
• “Bitcoin’s viability”: What is it? It means the set of factors that make Bitcoin viable to exist. For example, if Bitcoin had a rule that require mines to be mined every 10 seconds instead of 10 minutes, this would lead to extreme network requirements for nodes to be synced and make it not a viable peer-to-peer decentralized system. Therefore, anything that makes it harder for the p2p system to exist (such as rules that make the network unstable, or that make it harder to run a node, or harder for nodes to sync) makes it less viable.
• “threat to Bitcoin’s viability”: What is this? It is any factor that will contribute to make the Bitcoin network less viable, as discussed in previous item.

The release of Bitcoin Core 30 introduces default settings which facilitate the insertion of arbitrary content in transaction outputs, which makes it more likely that such content will occur and consequently increasing the blockchain size with non-financial data, which puts more storage requirements for node runners, more time for the node to validate the blocks, and more network requirements. Besides, it also adds legal risks for some (not all) node runners that could be legally pressured or prevented to run a node. It also introduces the potential for mining pools to actively monitor and asses content of transactions, which may eventually be used as an opportunity for governments to try to force mining pool organizations under their control to censor any sort of transaction. All of this contributes to make Bitcoin less viable.

Thus, one can only conclude that “release of Bitcoin Core 30 presents a severe threat to Bitcoin’s viability” is an objective statement and not subjective interpretation. No one is saying “this is good or this is bad”. It says the release introduces threat for the Bitcoin system to become viable, which some may think “this is actually good” and others may think “this is bad”, but it does not change the fact the statement itself is objectively accurate.

If it’s an objective statement– it’s simply a false one. As during the discussion about increasing the op_return default many people demonstrated that it was trivial to get such op_returns mined already as major miners had already removed the limit (and many such examples can be found in the blockchain too). E.g. https://blockstream.info/tx/3183bd6ceebc2d39c0a3cfa0d06eb84d1161eaac1c26605e2eab62bfe48c1420

BIPs should not contain known falsehoods either, so arguing that it’s fact not opinion here. I don’t think it’s reasonably disputable that it was trivial to get larger op_returns mined before Bitcoin Core did anything. The project’s actions were a reaction to a reality that had already changed.

A document doesn’t need to list its authors or proponents every thought on the subject, and a successful document will avoid dubious or controversial claims unless they’re absolutely acceptable. If someone wants to write an opinion piece one the subject– even one with dubious claims– they should feel free to do so on their blog… but not in a BIP.

Reactive - This means it would “activate and enforce”, correct?

I think the emergency activation is very risky. To simplify, I actually suggest removing that as an activation path. But if you don’t prefer that, here are some additional questions and comments.

1. A time frame will certainly exist where some miners would be running the software, but not a majority. a. Is there a minimum block height for this emergency activation? Or a signaling for readiness to enforce?
   b. Offending block identification would be done manually or in code? I assume in code because I can’t think of a way to make it work otherwise. c. How would an offending block be identified in code? How to ensure everyone is running the same rules identifying the offending trigger block?

2. Need a mitigation for someone intentionally triggering the emergency activation, either to do so before it’s ready (minority of hashrate) to cause a hard fork/general chaos, or to trigger it at a specific time in order to double spend.

3. What would the end block height be in case of emergency activation?

Proactive -

As of right now, I would say there is high risk of loss of funds related to the activation path.

Activation is challenging, but also crucially important to get it right. The intention of my comments are to try to get this to a state where I could say there is zero risk of loss of funds.

1. Mandatory signaling. I suggest removing the mandatory part of the signaling (which would eliminate over half of my concerns), but if you don’t prefer that for your PR, here are some questions or comments related to that a. is this a 2 step process with activation and enforcement happening at 2 different blockheights? I assume mandatory means enforcement occurs whether or not signaling is in place? b. The mandatory nature of it assumes that a supermajority of hashrate would be running the update by the enforcement date, correct? c. If it’s assumed a supermajority would be running the update (and if we’re wrong anyone running the update would be forked off). If we are confident about it, does it need to be mandatory, or could it just rely on signaling? d. Or alternatively, why have signaling at all if it is mandatory? e. Do you have a reasonable belief that a supermajority of miners will choose to run the software (considering they would be forked off and lose money if they are running the software, but a majority is not)? I.e. a letter from a majority of hashrate in support of the proposal, or at least stating that they will acquiesce. Have there already been discussions? Doing a mandatory enforcement without hearing some input from big hashrate seems risky to the point of being a non-starter. f. Is a majority of hashrate in agreement with the timeline? Do they have enough time to make code updates and do sufficient testing (since it seems many of them run custom software, they would need to integrate this)? g. Is a majority of hashrate in agreement with the specific rules to enforce. If there is any difference in rules, activation block height, end block height, it’s almost a guaranteed accidental hard fork.

2. General hard fork concern. a. What mitigations are there if node runners start running the software and enforce, but miners do not enforce. It is not reasonable to assume 100% of noderunners who update would be able to roll back the software. They would be at high risk of losing funds a chain split. b. The more complex the rules for data reduction, the more risky the activation is. I have some general questions about the rules: what percentage of transactions would be excluded by the new rules? What percent of fees would be excluded by the new rules? Which major protocols would be affected?

3. Temporary I understand the reasoning behind making the rules temporary, but I think it actually increases the risk in some ways - additional coordination and testing needed before the update is released. The block start and block end numbers can’t be change after it’s released. A few options might be to either only make rules which have a very high likelihood to have no impact (or have some other benefit like portlandhodl’s DOS block) and just make the changes permanent, or to push for opt-in activation by miners but not enforcement, and no enforcement by noderunners.

4. Noderunner pre-emptive update Something to consider is if a noderunner updates the software too early, like a pre-release version of the code or something like that, and started enforcing before the rest of the network/miners, they would end up forking themselves off. There are some mitigations that could be done for this but I wanted to mention it just to try to reduce any source of risk.

5. A little game theory. a. The safest approach for miners would be to either do nothing, or activate but not enforce. Doing nothing reduces the risk of being “the first to jump off a bridge”; why not just wait until everyone else has done it first. Activating without enforcing could lose some income (omitting some transactions), but would not introduce a hard fork risk for them or the network. Enforcing, especially being the first 49% to enforce, there is a fork risk for themselves and for the network. b. Noderunners however, can only either enforce or not. They don’t get the activation choice since they aren’t putting the block together. The safest thing for noderunners would be to not update (not enforce). If miners enforce, everything is good. If miners don’t enforce, they are still good. Whereas if a noderunner runs the update (to enforce) and miners don’t enforce, noderunners would lose money. Or even if miners did enforce and then had to rollback due to a bug or major breakage, again noderunners running the update would lose money.

Let me know if I’m off base on my assumptions or fork understandings here.

Why are you wasting your time here while you could be investing your time running K , The decentralized social network based on PoW network (https://github.com/thesheepcat/K)?

a hug.

It’s unclear if multiple OP_PUSHDATA of 256 bytes each are allowed or not.

Also:

0OP_PUSHDATA Is this
1OP_PUSHDATA contiguous?
2OP_PUSHDATA Would OCEAN
3OP_PUSHDATA laywers allow
4OP_PUSHDATA this?