Reduced Data Temporary Softfork #2017
Conversation
|
|
||
| TODO | ||
|
|
||
| ===Reactive Deployment=== |
There was a problem hiding this comment.
It's not clear to me why have these two headers, Proactive Deployment and Reactive Deployment, both here under Activation and below under Deployment.
There was a problem hiding this comment.
There is a "rationale" section here, which is more of an FAQ, and a "deployment" section below, which seems customary on softfork bips. I could consolidate these if you like.
dathonohm
force-pushed
the
reduced-data
branch
from
5314635 to
3c71823
Compare
|
I suggest you add an FAQ item for “why block 987424“. If the intent is to have it be a year out, the height might actually move during discussion, and right now its just a magic number in the document. |
|
@rot13maxi see the deployment section 
|
|
There is opportunity to also discuss the effect on DoS blocks and the scope of legacy script as a DoS vector. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
| The true danger lies not merely in the release existing, but in its adoption. | ||
| The adoption of this release, even if by a minority of users, risks establishing this harmful redefinition as a new de facto standard for the entire network. | ||
|
|
||
| This official sanction creates an immediate and severe threat. |
There was a problem hiding this comment.
I suspect many would disagree that there is any such thing as an "official sanction" given that there are no authorities on the Bitcoin network.
There was a problem hiding this comment.
Change of default relay policy settings in the super-majority node client as sanctioned by the official policy maintainer can easily be seen as an official sanction.
There was a problem hiding this comment.
What makes it "official" - some node clients like libbitcoin don't even have such policies. Is is not official from them because they have little adoption?
If it's the level of adoption that makes something official, consider that adoption is voluntary and opt-in, thus the "sanctioning" comes from many independent actors deciding to run the code that enforces said policies.
There was a problem hiding this comment.
100kb OP_RETURN is officially sanctioned by Bitcoin Core with the release of v30 as evidenced by their changing of default settings and accompanying release notes.
There was a problem hiding this comment.
Yes, an "official sanction" is thus (fairly awkwardly) defined as "The default standardness policies of the node software run by the vast majority of the network."
Simply, if there is relatively little adoption of Core 30 then what it has attempted to invite into mempools/the blockchain are not representative of Bitcoin.
|
|
||
| This official sanction creates an immediate and severe threat. | ||
| The threat here is distinct from general spam or economic costs, which are typically handled with policy and the fee market. | ||
| It allows a malicious actor to mine a single transaction with illegal or universally abhorrent content and credibly claim that Bitcoin itself is a system for distributing it, rather than a system that was merely abused. |
There was a problem hiding this comment.
"illegal or universally abhorrent content" is poorly defined; there are a multitude of legal jurisdictions and a multitude of subjective views on content; Bitcoin as a system does not recognize any of them.
There was a problem hiding this comment.
The motivation section only seeks to outline potential avenues for new risks allowed by Bitcoin Core 30. It is enough to recognize that there is an overlap of illegal data and universally abhorrent data which will put average node operators at unneeded risk. A specific outlining of the content in question is not needed, only a recognition that the risks are there.
There was a problem hiding this comment.
Agree with Blake. Precise definitions were never proposed nor required. Lopp's comments are rejected.
There was a problem hiding this comment.
Without wanting to be crass or sicken anyone with specifics, of course there are files that all decent people would make an effort to not download/store on their devices regardless of their legal status.
The general attempt to widen the scope of Bitcoin from "All financial activity must be treated as equal" to "Thus we must treat all files as just ones and zeroes" has been perplexing to watch as not only is it indefensible, it's completely unnecessary. Bitcoin can continue to eschew non-financial activity in general and thus not encumber its users with the problems that begin with soliciting it and then either having to attempt to moderate based on file contents or failing to do so and then ultimately getting used as a garbage dump for the world's most shunned files.
There was a problem hiding this comment.
Nack
This change is motivated on outside factors and interpretation of the data (legal and political) and not on how the software functions.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Nack This change is motivated on outside factors and interpretation of the data (legal and political) and not on how the software functions.
No it is not. The point is to limit arbitrary data in general and thus the exact opposite: prevent having to start performing the analysis you (and I) do not want.
There was a problem hiding this comment.
of course there are files that all decent people would make an effort to not download/store
The "decent" is doing a lot of work in that sentence. Care to define "decent people"? Is bitcoin not for the other ones?
There was a problem hiding this comment.
of course there are files that all decent people would make an effort to not download/store
The "decent" is doing a lot of work in that sentence. Care to define "decent people"? Is bitcoin not for the other ones?
Bitcoin is not for arbitrary file storage period. In designing it that way, we get the added benefit of not having to store data that is universally disliked.
| This official sanction creates an immediate and severe threat. | ||
| The threat here is distinct from general spam or economic costs, which are typically handled with policy and the fee market. | ||
| It allows a malicious actor to mine a single transaction with illegal or universally abhorrent content and credibly claim that Bitcoin itself is a system for distributing it, rather than a system that was merely abused. | ||
| This directly threatens the ability and/or willingness of common people to run fully validating nodes due to the resulting legal and moral risks. |
There was a problem hiding this comment.
Again, "legal and moral risks" could use much more precise definition.
There was a problem hiding this comment.
Again, precise definitions were never proposed nor required.
|
|
||
| A core principle of Bitcoin is "don't trust, verify". | ||
| The nature of Bitcoin requires users to run fully validating nodes, necessarily involving downloading, storing, and transmitting every transaction, even if they are fake/spam "transactions". | ||
| If the blockchain contains content that is illegal to possess or distribute, node operators are forced to choose between violating the law (or their conscience) or shutting down their node. |
There was a problem hiding this comment.
This has always been the case.
There was a problem hiding this comment.
An acknowledgement that the risks are present should be sufficient to encourage mitigation of risks which exacerbate this risk vector such as those introduced by Core 30.
There was a problem hiding this comment.
It's a very bad idea to put text suggesting legal liability into the implementation. Please talk to legal folks as to why, because even elaborating here via discussion of that particular aspect is hazardous.
There was a problem hiding this comment.
The generalized invocation of the ominous need for Bitcoin to 'follow the law or else' is concerning, because law can change, and in many places laws are enacted that run against the very principles Bitcoin represents. The open ended 'appeal to legality' and its implicit urging to act at the behest of government is something I hope folks reconsider.
There was a problem hiding this comment.
Legal liability exists regardless.
The point is that some files being illegal and others not makes laws essentially arbitrary and thus we should seek to discourage all arbitrary file storage specifically to reject this inevitable issue entirely.
| A core principle of Bitcoin is "don't trust, verify". | ||
| The nature of Bitcoin requires users to run fully validating nodes, necessarily involving downloading, storing, and transmitting every transaction, even if they are fake/spam "transactions". | ||
| If the blockchain contains content that is illegal to possess or distribute, node operators are forced to choose between violating the law (or their conscience) or shutting down their node. | ||
| This unacceptable dilemma directly undermines the incentive to validate, leading to inevitable centralization and posing an existential threat to Bitcoin's security model. |
There was a problem hiding this comment.
But this has always been the case...
There was a problem hiding this comment.
Doesn't mean it needs to stay that way, or that we need to make the situation worse.
There was a problem hiding this comment.
There is general consensus that sketchy content should not be on bitcoin, and that most node operator would support this change.
There was a problem hiding this comment.
This has always been the case
The point is not to make an issue (arbitrary illegality making life harder for nodes) worse by engaging in activity we have no business defending (the uploading/downloading/storage of arbitrary data).
|
|
||
| '''Isn't this censorship? By rejecting blocks based on data content, aren't you violating the principles of free speech and a neutral, permissionless network?''' | ||
|
|
||
| Bitcoin is money, not speech. |
There was a problem hiding this comment.
According to Citizens United v. Federal Election Commission, 558 U.S. 310, money is speech.
Normally it would be irrelevant to reference legal rulings in the context of the protocol, but this BIP seems to rely heavily on legality.
There was a problem hiding this comment.
money is speech, but not all speech is money. You must understand the difference, making this comment clearly in bad faith.
There was a problem hiding this comment.
Bitcoin is a monetary protocol. The protocol treats non-monetary usage with appropriate hostility. The pressure to do otherwise is met with insincere appeals to "free speech" which is what L296-L298 addresses. This is not related to legality.
There was a problem hiding this comment.
It is not censorship to preserve the intended use-case of Bitcoin, which is monetary.
It looks like some refuse to discourage spam on consensus level because of selfish opportunistic endeavours.
By engaging in opportunistic use-cases which neglect the risk of illegal content they are putting the reputation of Bitcoin on the line and introducing censorship implicitly themselves.
I'll explain: If Bitcoins reputation would become so bad that regulatory authorities in e.g. Europe take a look at it, exchanges could be forced to close on/off ramps to Bitcoin. Businesses and institutions would not be able to legally buy Bitcoin anymore. That would be censorship.
| 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.
| 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.
| 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.
| 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.
| 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.
"no legitimate uses have ever been found" for OP_RETURN, but also this BIP doesn't want to break "legacy protocols that still include such outputs". Why the contradiction?
So the "legacy protocols" are accepted as a "legitimate use" of OP_RETURN?
PS: there are multiple clearly-monetary "legitimate uses" of OP_RETURNs, contradicting the false claim in this section
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? |
| '''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?
17 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.