This document evaluates BIP-110 using principles associated with IETF rough consensus and engineering review.
It does not assess any particular activation mechanism, signaling threshold, deployment schedule, or political campaign. Its scope is limited to the technical problem identified by BIP-110, the proposed restrictions, and the substantive objections that have been raised.
BIP-110 proposes temporary consensus restrictions on several mechanisms that can be used to place large quantities of arbitrary data into Bitcoin transactions.
The proposal responds to a long-standing architectural concern: Bitcoin's blockchain is a permanent, globally replicated monetary ledger, not a general-purpose publication or file-storage system. Arbitrary data imposes costs on validating nodes and may create applications and economic dependencies that become progressively harder to remove.
This note concludes that the underlying concern is legitimate and unresolved. BIP-110 provides a concrete, bounded, implemented, and testable response.
Most commonly stated objections do not invalidate the proposal's stated objective. In particular, the continued theoretical possibility of steganographic data insertion does not show that restrictions on convenient, standardized data-storage mechanisms are ineffective.
Some technical questions remain, particularly concerning pre-signed transaction arrangements and temporary restrictions on future script-upgrade mechanisms. These should be evaluated using concrete transaction examples and deployment evidence.
Absent demonstrated material harm to established monetary use cases, such hypothetical concerns should not automatically outweigh the irreversible risk of allowing general-purpose data-storage systems to become load-bearing parts of the Bitcoin ecosystem.
Bitcoin transactions have always been capable of committing to information. The relevant question is not whether all non-payment information can be made impossible.
That objective would be unrealistic.
The relevant architectural question is whether Bitcoin should provide convenient, standardized, and high-capacity mechanisms for publishing arbitrary data into a permanent ledger replicated by every validating node.
This distinction is important.
A system may be unable to eliminate every covert or adversarial encoding while still having sound reasons to remove explicit, efficient, and officially supported mechanisms for that activity.
BIP-110 should therefore be evaluated against its actual objective:
To reduce the convenient, contiguous, and standardized insertion of arbitrary data into Bitcoin transactions, while preserving Bitcoin's primary monetary functions.
It should not be evaluated against the stronger and unattainable requirement of making all arbitrary data mathematically impossible.
RFC 7282 describes rough consensus as an engineering process rather than a popularity contest.
A technical objection does not become valid because it is repeated frequently or supported by prominent participants. Equally, an objection does not need unanimous agreement before it deserves consideration.
The relevant questions are:
- Is the objection specific?
- Does it identify a concrete engineering failure?
- Does it show that the proposal fails one of its stated requirements?
- Has the proposal addressed or mitigated the concern?
- Is the remaining risk material enough to block deployment?
An objection need not be satisfied to the objector's preference. It must be considered and reasonably addressed.
Conversely, the mere existence of an unresolved theoretical possibility does not grant an indefinite veto over a proposal.
Bitcoin's consensus system causes every validating node to receive, validate, and potentially retain information included in the blockchain.
When a transaction is used primarily for payment, the transaction fee participates in Bitcoin's monetary settlement market.
When a transaction is used primarily for permanent data publication, the economic relationship is different.
The miner receives a one-time fee. The wider node network bears the continuing costs of:
- transaction propagation;
- block propagation;
- validation;
- indexing;
- storage;
- backups;
- RPC and REST exposure;
- legal and operational handling;
- indefinite replication by future nodes.
The miner and data publisher therefore do not internalize the full cost of the activity.
This is an externality.
The concern is not only present resource consumption. A further risk arises when applications, businesses, and users begin to depend on permissive data-storage behavior. Once these systems become established, removing them becomes politically, economically, and operationally more difficult.
The decision to permit such an ecosystem to develop is therefore not neutral.
Inaction may progressively constrain Bitcoin's future architectural choices.
The concern that Bitcoin should not become a permanent plaintext publication system is not new.
Satoshi Nakamoto warned that permanently recorded messages would be unwise and described such use as an accident waiting to happen. He suggested that messaging systems should exist separately from the blockchain.
Similar concerns have subsequently been raised by security-oriented members of the Bitcoin community, including Nick Szabo and Luke Dashjr.
These statements should not be treated as arguments from authority. Their relevance comes from the architectural reasoning behind them:
- blockchain data is difficult or impossible to remove;
- publication costs are imposed on third parties;
- abusive uses should be considered before they become entrenched;
- irreversible systems should be designed according to adverse-case assumptions.
In security engineering, a credible warning about an irreversible failure mode deserves consideration before the predicted harm reaches its maximum scale.
It is not necessary to prove that catastrophe is certain before reducing an obvious and unnecessary attack surface.
BIP-110 proposes restrictions on several transaction structures that can be used for arbitrary data publication.
The proposal does not claim that all arbitrary data can be eliminated.
Users may still attempt to:
- divide data into smaller pieces;
- disguise data as keys or signatures;
- encode information in transaction structure;
- use external reconstruction protocols;
- apply steganographic techniques.
The proposal instead raises the cost and complexity of publication and removes convenient, standardized surfaces that make general-purpose blockchain storage straightforward.
This is a conventional security objective.
Security mechanisms commonly seek to:
- reduce attack capacity;
- remove standardized interfaces;
- increase attacker cost;
- limit accidental exposure;
- discourage ecosystem dependence;
- define unsupported behavior.
A mitigation is not ineffective merely because it does not eliminate every conceivable bypass.
Objection: BIP-110 is ineffective because users can fragment, disguise, or encode data through other transaction fields.
Assessment: Addressed.
The objection applies a requirement that BIP-110 does not claim to satisfy.
The proposal aims to restrict convenient and contiguous publication, not to solve the general steganography problem.
Forcing data publishers to fragment, disguise, or externally reconstruct information may provide several benefits:
- higher transaction cost;
- lower usable capacity;
- reduced discoverability;
- weaker application interoperability;
- less standardized tooling;
- clearer absence of protocol endorsement;
- greater difficulty in making the use case load-bearing.
The existence of a bypass does not show that the mitigation has no value.
To become a blocking objection, this argument would need to demonstrate that the restrictions produce no material reduction in capacity, convenience, discoverability, or ecosystem adoption.
Objection: A transaction that pays the required fee should be permitted, regardless of its purpose.
Assessment: Substantially addressed.
This argument assumes that the transaction fee compensates every party that bears the cost.
It does not.
The miner receives the fee. Validating nodes receive no corresponding payment for indefinite replication, storage, indexing, and operational exposure.
The presence of a fee therefore does not establish that the relevant externalities have been internalized.
Bitcoin consensus already imposes structural restrictions that are not determined solely by willingness to pay. The fee market operates within protocol rules. It does not define those rules by itself.
Objection: Arbitrary data should be handled through standardness and relay policy rather than consensus.
Assessment: Partially addressed.
Relay policy is appropriate for ordinary transaction propagation and mining-template policy.
It does not protect validating nodes from blocks produced by miners that deliberately include the restricted structures.
The proposal therefore identifies a threat model that policy alone cannot cover.
A complete objection would need to establish either:
- that deliberate miner inclusion is not a credible threat; or
- that the resulting harm is too small to justify consensus restrictions.
Merely observing that spam is normally handled through policy does not answer the malicious-miner or non-cooperating-miner case.
Objection: Restricting arbitrary transaction data constitutes censorship.
Assessment: Not established as a technical objection.
BIP-110 does not classify transactions according to political viewpoint, identity, jurisdiction, legality, or message content.
It applies content-neutral structural limits to transaction elements.
Bitcoin already contains numerous syntactic and semantic restrictions, including limits on script behavior, execution, transaction structure, and spend conditions.
Describing every protocol restriction as censorship assumes that Bitcoin is obligated to function as a general-purpose publication system. That is the disputed architectural claim, not an established premise.
The legitimate underlying concern is whether consensus rules should distinguish supported monetary functionality from unsupported publication functionality.
That question should be evaluated directly.
Objection: Data restrictions prevent new applications from being developed on Bitcoin.
Assessment: A real tradeoff, but not automatically a blocking objection.
Permissionless innovation does not imply that every application must be supported by Bitcoin's base consensus layer.
Applications may use:
- separate protocols;
- client-side validation;
- off-chain storage;
- cryptographic commitments;
- federated systems;
- overlay networks;
- sidechains;
- other blockchains;
- dedicated publication systems.
A monetary consensus system may deliberately maintain a narrow base layer to preserve validation accessibility, predictability, and decentralization.
An objector would need to show that the affected application is a necessary monetary function, or that it cannot reasonably be implemented without the restricted data surface.
After the preceding objections are disposed of, two areas appear to merit further technical review.
Some Bitcoin constructions depend on transactions being signed before the outputs they spend are confirmed.
A formal compatibility concern would arise if:
- a pre-signed transaction is valid under the rules expected when it is created;
- an intermediate output is confirmed after BIP-110 activation;
- the pre-signed descendant violates a new BIP-110 rule;
- the affected construction cannot safely migrate;
- funds are delayed, frozen, or lost as a result.
This is a legitimate class of concern.
However, a formal objection should identify a concrete construction rather than relying only on theoretical possibility.
A useful objection report should provide:
- the complete transaction sequence;
- scripts and witness data;
- the specific BIP-110 rule violated;
- the reason grandfathering does not apply;
- the protocol or wallet that creates the transaction;
- evidence of present deployment;
- the value or number of users plausibly exposed;
- the reason the construction cannot be migrated before activation.
Without this information, the issue should be recorded as an implementation and compatibility risk requiring investigation, not as demonstrated material breakage.
BIP-110 temporarily restricts some structures designed to support future extensions, including undefined witness versions, annex-related behavior, and OP_SUCCESS mechanisms.
This is an architectural cost.
Extension points are intended to preserve optionality for future soft forks and advanced transaction designs.
The relevant question, however, is not whether flexibility is reduced in the abstract. It is whether a concrete and credible upgrade is likely to require the affected mechanism during the enforcement period.
A temporary restriction may be acceptable when:
- the abuse surface is already active;
- no conflicting upgrade is scheduled;
- the restriction is clearly bounded;
- the mechanism can later be restored or redefined;
- the security benefit outweighs the temporary loss of optionality.
This objection should therefore be evaluated against actual upgrade plans and deployment timelines.
It should not automatically block the proposal solely because an extension mechanism may have hypothetical future uses.
The temporary nature of BIP-110 is relevant to proportionality.
A bounded restriction can serve several purposes:
- interrupting rapid ecosystem entrenchment;
- creating time for measurement;
- allowing alternative designs to emerge;
- testing whether the restricted activity migrates elsewhere;
- preventing an interim behavior from becoming an assumed permanent entitlement.
Expiration does create coordination complexity. Applications must reason about conditions before, during, and after enforcement.
That cost should be documented.
However, temporary enforcement may be more proportionate than an indefinite consensus rule where the long-term optimal design remains uncertain.
A bounded mechanism should not be dismissed merely because it requires later review. Review and reconsideration are appropriate responses to uncertain and evolving security conditions.
For purposes of technical consensus, objections should be divided into the following classes.
An objection is addressed when the proposal provides a technically coherent response, even if the objector continues to prefer a different policy.
This category includes:
- data can still be inserted steganographically;
- users have paid a transaction fee;
- relay policy is normally used for spam;
- syntactic restrictions are inherently censorship;
- every possible application must remain available on the base layer.
An objection requires additional evidence when it identifies a plausible failure but does not establish that the failure is deployed, material, or unavoidable.
This category includes:
- unspecified pre-signed transaction breakage;
- hypothetical future dependence on upgrade hooks;
- generic claims of wallet incompatibility;
- unquantified claims about monetary functionality.
These objections should be accompanied by test vectors or reproducible transaction examples.
An objection may be blocking if it demonstrates that BIP-110:
- makes currently deployed monetary arrangements unspendable;
- creates a material and unavoidable risk of fund loss;
- conflicts with an already agreed protocol upgrade;
- introduces a consensus inconsistency;
- cannot be implemented deterministically;
- fails to achieve any measurable reduction in the targeted behavior;
- imposes costs materially greater than the identified security benefit.
No proposal should be accepted merely because its objective is desirable.
Equally, no proposal should be blocked by unsupported speculation.
The appropriate burden is asymmetric because the relevant outcomes are asymmetric.
Allowing general-purpose blockchain-storage systems to become deeply established may be difficult to reverse. Removing or narrowing an explicit storage surface before that point is comparatively reversible, particularly where the restriction is temporary.
This does not mean that BIP-110 should be accepted without scrutiny.
It means that evaluation should account for the cost of delayed action.
The status quo is not a zero-risk baseline. It permits continuing growth of the disputed behavior and increases the number of users and businesses that may later claim dependence on it.
Accordingly:
- proponents should demonstrate that the proposal is deterministic, implemented, tested, and proportionate;
- objectors alleging monetary breakage should provide concrete transaction examples;
- objectors alleging ineffectiveness should demonstrate that the restrictions do not materially raise cost or reduce capacity;
- objectors preferring policy should address deliberate miner inclusion;
- objectors invoking future extensibility should identify a credible conflicting upgrade.
The following findings appear supportable.
There is a credible architectural and security concern regarding convenient, permanently replicated arbitrary-data publication through Bitcoin's consensus system.
The concern includes:
- uncompensated node externalities;
- permanent operational exposure;
- competition between monetary settlement and data publication;
- growth of load-bearing non-monetary applications;
- reduced future ability to narrow the protocol safely.
BIP-110 is not merely an expression of preference.
It provides:
- defined consensus restrictions;
- an implementation;
- tests;
- activation and expiration behavior;
- a bounded enforcement period;
- explicit acknowledgment of residual steganographic channels.
This is sufficient for substantive engineering review.
The following claims do not, by themselves, invalidate BIP-110:
- arbitrary data remains theoretically possible;
- publishers pay transaction fees;
- relay policy exists;
- applications may prefer larger data capacity;
- some future construction might use an affected mechanism;
- protocol restrictions can be described rhetorically as censorship.
Concrete evidence should still be sought concerning:
- deployed pre-signed transaction chains;
- time-locked recovery arrangements;
- post-activation descendant transactions;
- advanced Miniscript and Taproot constructions;
- scheduled uses of currently undefined upgrade mechanisms.
These questions should be resolved using test cases and implementation evidence.
They should not be treated as permanently blocking solely because a theoretical construction can be imagined.
BIP-110 addresses a legitimate and unresolved Bitcoin architectural concern.
Bitcoin is a permanent, globally replicated monetary ledger. It is not required to provide a convenient general-purpose data-publication layer.
The fact that arbitrary information can never be eliminated completely does not imply that explicit, standardized, and high-capacity publication mechanisms should remain unrestricted.
Removing or constraining such mechanisms can:
- reduce usable publication capacity;
- increase publisher cost;
- reduce discoverability;
- discourage protocol dependence;
- preserve node accessibility;
- maintain a clearer separation between monetary settlement and general data storage.
Most frequently raised objections have coherent answers.
The principal remaining questions concern concrete compatibility with established monetary constructions and temporary limitations on future upgrade hooks. These should be investigated through reproducible examples, not resolved through abstract assertions.
On an IETF-style consensus assessment, the current record supports the following conclusion:
BIP-110 presents a technically credible, bounded, and proportionate response to a pending architectural-security concern. General objections based on bypassability, fee payment, relay policy, or unrestricted application development have been substantively addressed. Remaining compatibility objections should be supported by concrete evidence of material harm. In the absence of such evidence, theoretical edge cases should not automatically outweigh the irreversible risks associated with allowing general-purpose data-storage systems to become entrenched in Bitcoin.
-
RFC 7282, On Consensus and Humming in the IETF https://datatracker.ietf.org/doc/html/rfc7282
-
BIP-110 https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki
-
Satoshi Nakamoto, comments concerning permanently recorded messages https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/239/
NACK
we should keep the IDF away from Bitcoin development