Hi Paul
Can you comment on this twatter post that I just seen?
This is Peter making the tired argument that you cannot block all methods of steganographicly embeding abitrary data into the block-chain. He basically chunked the data into multiple <520 byte chunks and stuck it into scriptSig inputs. It misses two important points:
- The method used was not a sanctioned spot specificially designed for dumping data
- Nobody is claiming that all spam can be blocked 100%. We are simply saying we can block methods that gain large-scale adoption (like inscriptions) and grow to a sufficient size that they can be targeted directly
I would also add that this is why after BIP110, we need to seriously consider the Cat or something similar for freezing historical spam transactions. Some rando inventing a novel steganographic method of embedding something on the blockchain is very different than an entire spam community and ecosystem being built around a well-defined and agreed on method of embedding data. For the latter we can make such an enterprise unprofitable by cutting them off at the knees using their own published rules for how their data is encoded to identify and freeze them.
1 Like
BTW, the transaction in question is 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c
You can see that it is camouflaged as a “consolidation” transaction (like someone doing UTXO management), were he stuck a chunk of the PDF into each input. He also wasted around 97k sats to make his ridiculous point.
Actually, Dathon’s response when Peter pulled this stunt is probably better than mine:
Peter -
Thank you for demonstrating what non-contiguous data looks like.
I trust you when you say that you can parse the BIP’s contents from this transaction, but all it looks like to me (and the Bitcoin network) is a UTXO broken into 31 pieces then (mostly) re-consolidated into a 0-length OP_RETURN, sending all ~100 USD in fees to the miner.
Since legally hazardous content can be generated from any input data, including your 30-input consolidation transaction (as long as the correct third-party program is used), it would not make sense to hold node operators legally responsible for storing and distributing such input data.
However, if Bitcoin provides an officially supported method of storing arbitrary data (i.e., OP_RETURN), and the capacity of that method is large enough to store hazardous content in a contiguous format (an increase to 100kB is currently underway as Bitcoin Core 30 gains adoption), then one does not need to misinterpret the data in order to view the content. In that case, node operators could conceivably be held responsible for possession and distribution.
Since arbitrary data storage does nothing to benefit Bitcoin as permissionless money, there is no good reason to force this additional legal risk on node operators, who already face enough challenges as it is.
Best,
Dathon
1 Like
Thanks for this Paul I have posted your replies on the Mayan bitcoin site which was were the twatter post was first posted. The guy in question is still skeptical about BIP 110 and the 3 AI LLMs that he has run it by all came out against BIP 110.
This is the chatgpt response to my guys query on BIP 110
Make a dialectic analysis with your recommendation at the end on whether BIP110 should go thru or not?BIP-110 is a proposed temporary soft fork for Bitcoin, introduced in early December 2025 primarily associated with the Bitcoin Knots implementation (maintained by developers like Luke Dashjr and others concerned about network health). It aims to reimpose strict consensus-level limits on arbitrary/non-monetary data in transactions for a one-year period (with potential for extension or modification based on feedback).
Key proposed restrictions include:
Limiting most transaction output data to 34 bytes (except OP_RETURN, capped at 83 bytes).
Restricting “inscriptions” (e.g., Ordinals-style data via SegWit witness) to 256 bytes.
Overall goal: curb blockchain spam (inscriptions, junk data pushes) that bloats the UTXO set, increases node costs, and distorts incentives away from Bitcoin’s core purpose as sound money.
The proposal is framed as a temporary intervention to refocus development and usage on monetary transactions while market mechanisms (fees) and future improvements address data issues long-term.
Thesis: Arguments in Favor (Pro-BIP-110)
Proponents argue Bitcoin faces an existential threat from unrestricted data inscription spam (accelerated since ~2023 Ordinals/BRC-20 boom and relaxed OP_RETURN policies in Bitcoin Core). This has led to:
Rapid UTXO set growth and blockchain bloat → higher resource demands for full nodes (storage, bandwidth, validation costs).
Risk to node decentralization: Fewer people can afford to run validating nodes → centralization pressure.
Distorted incentives: Miners profit from high-fee spam transactions, but the network bears long-term costs (worse money properties).
Bitcoin’s purpose as “peer-to-peer electronic cash” (and increasingly sound money/store of value) is undermined when the chain becomes a general-purpose data store competing with cheaper alternatives like Ethereum/Arweave.
BIP-110 is positioned as:
Temporary (1 year) → not a permanent rule change, giving time to observe effects and adjust.
Consensus-enforced → polite requests/filtering in mempools aren’t enough; spammers bypass them.
Gaining rapid grassroots momentum: Significant node signaling (reports of ~2-3%+ of detectable nodes running signaling versions as of late January 2026, with vocal support from Bitcoin OGs and communities rallying around “protecting Bitcoin as money”).
Videos and posts describe it as “nothing stops this train,” with calls for miner-activated soft fork (MASF) if needed.
Antithesis: Arguments Against (Anti-BIP-110)
Opponents view BIP-110 as a dangerous precedent:
Subjective censorship at consensus level: Defining “spam” or “non-monetary” is inherently political. Who decides what qualifies? Inscriptions/Ordinals have real economic demand (users pay high fees), and restricting them breaks permissionlessness/neutrality.
Not a true soft fork in spirit: Some (especially in r/btc / BCH-aligned circles) argue it functions more like a hard fork by invalidating previously valid transactions retroactively in effect, or at least misleadingly labeled.
Market should decide: Fees already price out low-value spam during congestion. If data usage is valuable, users will pay; if not, it fades. Consensus changes to filter content set a slippery slope (what next—filter other “undesirable” uses?).
Centralization risk in opposite direction: Enforcing subjective rules could alienate users/developers, fragment the ecosystem, or concentrate power in the hands of a few devs/node runners pushing their vision.
Low miner interest so far: No major mining pools signal support, and activation requires broad consensus (e.g., 55%+ in some models). Grassroots node signaling is noisy but not decisive without miner/economic node buy-in.
Precedent for more interventionist changes undermines Bitcoin’s conservative, ossification-oriented philosophy.
Critics see it as moralizing over “junk” rather than letting emergent market/order handle it.
Recommendation
BIP-110 should not go through in its current form or via contentious activation.
While the concerns about spam, UTXO bloat, and node costs are legitimate and growing, enforcing subjective data limits at the consensus layer (even temporarily) represents too great a risk to Bitcoin’s core properties: permissionlessness, neutrality, and resistance to centralized moral filtering.
Bitcoin has historically thrived by letting fees and market dynamics regulate usage rather than top-down rules about “valid” content. The temporary nature is a weak safeguard—extensions are easy to justify once precedent exists, and activation paths (e.g., aggressive UASF-style campaigns) could lead to chain splits or prolonged contention worse than the spam itself.
Better paths forward:
Continue improving node efficiency (pruning, better validation).
Rely on fee markets to price out low-value data.
Develop side protocols/layer-2 solutions for data-heavy use cases.
If spam truly threatens decentralization, pursue objective, non-content-based mitigations (e.g., UTXO age/fee discounts, dust limits adjustments) rather than “arbitrary data” bans.
The momentum behind BIP-110 reflects real frustration, but the cure risks being worse than the disease. Bitcoin should remain as dumb and neutral as possible at layer 1—spam fades when expensive; censorship endures.
Hello Bernard this is Grok’s
No.
Because BIP110 moves a policy problem into consensus, and that creates systemic risk (chain splits and coordination failures) that is objectively larger than the problem it tries to solve.
Data-driven reasoning, stripped down:
• The issue it targets (large arbitrary data / inscriptions) is already controllable at the mempool/relay policy layer without changing consensus rules.
• Consensus changes are the highest-risk lever in Bitcoin; even a small chance of a contentious activation can cause chain splits, exchange halts, and economic loss, which historically are far more damaging than higher blockspace demand.
• The proposal is temporary and prescriptive, which weakens Bitcoin’s credibility as stable, neutral money and sets a precedent for “mission-based forks.”
• It constrains future contract design space (Taproot/witness limits) for uncertain benefit.
So objectively:
Cost of consensus intervention > benefit of discouraging data storage.
Therefore: No, it should not go through. This is C-GPT