Reduced Data Temporary Softfork #2017
Conversation
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.
"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?
There was a problem hiding this comment.
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.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
|
|
||
| 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.
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.
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.
There was a problem hiding this comment.
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.
|
|
||
| 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.
@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.
There was a problem hiding this comment.
@dathonohm full nodes don't need to store data, only validate. (see my previous post)
There was a problem hiding this comment.
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."
bitcoin/bitcoin#32359 (comment)
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.
There was a problem hiding this comment.
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 bitcoin/bitcoin#32359 (comment):
"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.
There was a problem hiding this comment.
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)" ?
| 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).
There was a problem hiding this comment.
Bitcoin Core 30 meaningfully changes the situation. See: #2017 (comment)
|
|
||
| '''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.
It also doesn't matter because Bitcoin does not recognize the United States government.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Policy is local, which means anyone can change it to anything they want, which means they have no actual limitation. Anyone sincerely motivated to customize local policy can do so without restraint.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
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.
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.
| 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.
There was a problem hiding this comment.
My understanding is that these lawyers are mostly not criminal lawyers and have no relevant experience. But also, note that a majority of the 7 lawyers said there is indeed reason for concern.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
| 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
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
There was a problem hiding this comment.
All, please don't repeat the same argument after having stated it once, otherwise marking as duplicate. Thanks.
There was a problem hiding this comment.
"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.
| 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.
I don't think we should be creating even more barriers to running a node when so many already exist.
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.
Therefore we need to make the consensus rules such that people are willing to consent.
| 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.
There was a problem hiding this comment.
If this BIP gains consensus and activates, it seems likely that, when it expires, there would be consensus at least for extending the restrictions, if no better solutions are found.
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
| 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.
There was a problem hiding this comment.
@ekzyis This BIP specifically targets forms of spam that are so legally toxic that having even a single instance in the chain represents a significant legal liability for users who run nodes. It might lead to a reduction of other forms of spam as well, but that would merely be a side effect. Spam without legal risk for users is best fought in policy rather than consensus.
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.
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.
| # 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'?
There was a problem hiding this comment.
@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?
There was a problem hiding this comment.
@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
There was a problem hiding this comment.
This makes it a non-starter. BIPs should not include confiscatory qualities as it obviously disrupts the user space and undermines all similar use cases reputationally.
There was a problem hiding this comment.
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.
|
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
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.
@Jeremy-coding I think it's very unlikely that anyone, especially mining pools with large, prominent nodes, will want to stay on the old chain once it activates. Anyone, including mining nodes, is free to stay on the old chain. I just don't expect that chain to garner much hashpower (nor industry support) once miners understand how much this new rule set lowers their liability with respect to the old chain.
@Rob1Ham Indeed, coordinating the reactive method will be difficult. Large mining pools will ideally be paying close attention until this BIP activates, in order to react quickly if needed.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
This is the same template Canada state used to eventually supercede their charter of rights and freedoms and forcefully shutdown lawful protest-emergency act.
There was a problem hiding this comment.
If, however, some content appears in the chain that causes significant risks, we can fall back to the reactive method,
I have some real concerns about this... Who is going to be watching every transaction, detecting if there is a large Op_Return, and then trying to discern what type of data it is (PDF? JPEG? MP4?) and then making the call that it is reprehensible? That is a LOT of effort and transactions could be missed and still end up on the chain.
And then...
the reactive method, which is a retroactive chain reorganization to invalidate the offending block
I'll be the first to admit that I am unsure of what this entails in full, but it doesn't sound easy to do or free of cost. And I'd imagine the longer the offending transaction takes to discover, the larger the re-org will need to be.
Meanwhile, while the emergency has not been triggered, I would be very nervous to put any transaction on the chain.
I guess what I'm saying is: Screw this "emergency option". It causes uncertainty as to how and when it will be activated and if Bitcoin will work during the re-org. I would rather, if the consensus is there, to immediately put it into action. Get it out there. If people are worried about the lockup (confiscation?) of funds for any length of time, then maybe make it shorter than a year... But make it happen ASAP.
We are all holding our breath and crossing our fingers that this doesn't happen. I am dead set stressed about it. But let's not "pray for good luck" before v30 gets too broadly deployed and triggers this by someone happening to find it. Let's implement immediately (as soon as consensus is reached) so there is less anxiety about it, less work for the "watchers", and send a clear signal to any bad actors.
| In 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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
| # 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.
Suggest "Bcash" -> "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.
There was a problem hiding this comment.
"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.
There was a problem hiding this comment.
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.
| 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
|
I'm concerned about this PR. I've been told by someone present at recent closed room meetings that this PR is being tendered on behalf of Ocean Mining but that they've used another account to conceal their involvement. In a further conflict of interests, luke-jr now proports to have assigned it a BIP number entirely out of process and is gunning for some emergency merge. Directed more squarely to its subject: The PR message makes numerous unambiguously false claims such as asserting that it had no opposition when it does. (just to give a few examples note the posts pointing to the confiscatory treatment of presigned transactions, and the posts demonstrating the ineffectiveness of the proposal at the goal of preventing data embedding). Legal representatives associated with ocean are now also contacting and acting coersively towards other miners and using the false claims on this PR as backing "information" for their claims. As such I believe leaving this PR open is contributing to fraudulent claims and conduct, and it should be promptly closed. Discussion can obviously continue on the list. |
|
@luke-jr, would you please close this pull request for now? I would do it myself but I think closing the pull request would be more meaningful to the bitcoin community if you did it & this action would give time for the proponents of this proposal to revise (or collaborate on other ideas) in response to the discovery of the abovementioned technical issues and other problems with BIP PR 2017. Thanks! |
|
|
||
| ===Proactive=== | ||
|
|
||
| We propose a flag day startheight of 934864 (2026-02-01), with mandatory signaling leading up to activation. This implies an expiry day stopheight of 987424 (2027-02-01). These heights were extrapolated from block 920464 which occurred near 00:00 UTC on 2025-10-24. |
There was a problem hiding this comment.
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.
-
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. -
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? -
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. -
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. -
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.
|
|
||
| ===Reactive=== | ||
|
|
||
| We propose, in the event of an emergency, for miners to reject the offending block and immediately activate the new rules. In this case the new rules are effective on the very next block confirmed at the same height as the rejected block, and the soft fork expires at the same height as in the proactive case; that is, block 987424. |
There was a problem hiding this comment.
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.
-
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? -
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.
-
What would the end block height be in case of emergency activation?
| Blocks with a height from (TBD) until and including 987424 are checked with these additional rules: | ||
|
|
||
| # New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid. | ||
| # OP_PUSHDATA* with payloads larger than 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs. |
There was a problem hiding this comment.
It's unclear if multiple OP_PUSHDATA of 256 bytes each are allowed or not.
Also:
OP_PUSHDATA Is this
OP_PUSHDATA contiguous?
OP_PUSHDATA Would OCEAN
OP_PUSHDATA laywers allow
OP_PUSHDATA this?
Are consecutive data pushes considered contiguous for legal/moral purposes?
This comment was marked as off-topic.
This comment was marked as off-topic.
The BIP draft here credits @luke-jr. I agree that it would have been better for Luke to open it himself, but his involvement doesn't seem overly concealed.
I proposed 444 to the editors for feedback and made an entry in the internal notes. Unless an assignment is made publicly here on the PR, I don't consider it formally assigned, including now. I am not aware of plans by any of the BIP editors to do some emergency merge.
I am not aware of such actions. Best for Luke or Ocean to respond there.
I agree that much of the discussion we are seeing on this PR would be better sent to the list. I've repeatedly suggested above to please focus here on technical review. |
|
I've provisionally locked this as too heated for now to give people time to cool down. |
|
Re-opening the discussion. Please read the mailing list thread and send conceptual feedback and general commentary there, and focus here on:
In the list thread at https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8/m/dfWJd1puAwAJ, @dathonohm wrote: "I am working on a new draft of the BIP that will hopefully address everyone's concerns" Please consider beforehand whether a new comment will add new signal or noise, and perhaps give the author the opportunity to update in response to the existing feedback. Comments that do not add new signal or that do not follow the guidelines in the PR description will likely (reluctantly) be moderated. |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@dathonohm Please keep that for the mailing list and wait for the queue to be processed. Here on the PR, I would humbly suggest (feel free to ignore):
|
|
Hi @jonatack - Apologies for the misstep, and thanks for the advice. As I mentioned earlier, I'm working on a new draft. I'm planning to put together a focused discussion group for this BIP, to make sure everyone's concerns are heard and addressed. Rough consensus is absolutely the goal. |
Given the "reactive activation method", I'd advise getting a pull request based off a recent version of Core (and knots as I assume that is the client you run) as your most urgent priority. There will not be rough consensus to chain split/roll back the chain using the reactive activation method without well reviewed code that has been available for some time. |
|
If anyone is interested, a few weeks go we did a risk analysis of Bitcoin Core v30 implementation with the possible introduction of malicious data on the Bitcoin blockchain. Here is the report |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
The BIP claims that OP_IF/etc. need to be removed due to their use for data publication. If that is in fact true, then indeed, many other opcodes with clear use for data publication need to be removed as well (note how my BIP-compliant transaction was constructed as a commit reveal, similar to how lightning HTLCs work).
On the other hand, if the real motivation is simply to ensure that "naughty bytes aren't contiguous", then the only thing that needs to be done is to ban long pushdatas and similar constructs; banning opcodes is unnecessary.
|
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
This comment has been minimized.
This comment has been minimized.
This comment was marked as duplicate.
This comment was marked as duplicate.
|
Hi all, given that the guidelines in the OP and in #2017 (comment) are generally not being followed, and to save everyone's time, let's lock this until @dathonohm posts to the list that they are ready to push a significant update. I understand that people with conceptual or general commentary need an outlet to be heard, but here on the PR, where actual technical review needs to be possible, isn't a good place. The PR discussion is already slow to load (at least, for me, making it difficult to follow) with several hundred comments, and the author already has plenty of feedback above to work with. Thanks for your understanding. |
75 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.
Mailing list thread at https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8
Editor note: please post conceptual feedback and meta-commentary on the mailing list thread, and focus here on:
(Please refrain from personal or heated commentary, pedantry, and repeating yourself in both venues.)