[BIP Proposal] Reduced Data Temporary Softfork

[dath...@proton.me]

Hi list -

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:

https://github.com/bitcoin/bips/pull/2017

The idea is to strongly re-affirm in consensus that bitcoin is money, not data storage. It is implemented as a temporary softfork that can activate in one of two different ways: proactive, or reactive.

After a year, the soft fork expires, giving us time to come up with a more permanent solution.

The timeline is a bit tight, but I think everyone has incentives to support a quick and orderly activation.

Please feel free to leave a comment on the PR or reach out to me over email with any feedback. 

There is much work still to do, so if you have some technical skills and would like to join in the effort with dev/testing, please reach out as well.

Bitcoin is money.

Sincerely,

Dathon Ohm

[Jameson Lopp]

It's quite clear from the PR discussion that there are a multitude of contentious issues at play with this proposal.

Even aside from all of the technical concerns, the underlying implication of using legal coercion to require miners and other network participants to comply with arbitrary legal and moral frameworks makes it a non-starter in my opinion.

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/AWiF9dIo9yjUF9RAs_NLwYdGK11BF8C8oEArR6Cys-rbcZ8_qs3RoJURqK3CqwCCWM_zwGFn5n3RECW_j5hGS01ntGzPLptqcOyOejunYsU%3D%40proton.me.

[Peter Todd]

On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin Development Mailing List wrote:
> Hi list -
>

> Due to Bitcoin Core v30 gaining in popularity, it has become necessary to move forward on [luke-jr's ML proposal](https://github.com/bitcoin/bips/pull/2017) to temporarily limit arbitrary data at the consensus level, which so far has 3 weeks with no objections:
>
> https://github.com/bitcoin/bips/pull/2017

Transaction 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c
contains the full text of this BIP as of writing(1), while simultaneously being
compliant with that BIP.

Clearly, this approach is ineffective.

1) https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[dath...@proton.me]

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

On Sunday, October 26th, 2025 at 4:43 PM, Peter Todd <pe...@petertodd.org> wrote:

> On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin Development Mailing List wrote:
>
> > Hi list -
> >

> > 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:

> >
> > https://github.com/bitcoin/bips/pull/2017
>
>
> Transaction 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c
> contains the full text of this BIP as of writing(1), while simultaneously being
> compliant with that BIP.
>
> Clearly, this approach is ineffective.
>
> 1) https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aP6gYSnte7J86g0p%40petertodd.org.

[dath...@proton.me]

Jameson -

You mention "technical concerns" but don't give any examples. Would you mind sharing one?

You also mention "the underlying implication of using legal coercion to require miners and other network participants to comply with arbitrary legal and moral frameworks", but I don't think the BIP implies this at all.

The BIP merely highlights a legal risk Bitcoin Core 30 has created for node operators for no good reason, and attempts to eliminate it. No "coercion" is implied. You and anyone else who are fine shouldering this risk are free to stay on the old data-friendly chain. I doubt you will have much company, though.

Best,

Dathon

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADL_X_caKFvypdDa2k-Hhy1QCMJgnb6Rc8i0vBRW9%3Dyoq4h2ZA%40mail.gmail.com.

[TheWrlck]

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.

[Jameson Lopp]

On Mon, Oct 27, 2025 at 12:22 AM <dath...@proton.me> wrote:

Jameson -

You mention "technical concerns" but don't give any examples. Would you mind sharing one?

Two of the biggest technical concerns are that the proposed changes are confiscatory for certain scripts and the fact that the reactive chain reorganization logic actually makes it possible for anyone to trivially double spend their coins by triggering a reorganization.

 

You also mention "the underlying implication of using legal coercion to require miners and other network participants to comply with arbitrary legal and moral frameworks", but I don't think the BIP implies this at all.

I quote the BIP:

"rejecting this softfork may subject you to legal or moral consequences"

This vague, hand waving fear mongering is the underlying implication of legal coercion to which I referred. It's not appropriate for a technical specification.

[Jal Toorey]

"bitcoin is money"

The definition of what is money is extremely subjective.  The history of it shows this (not the history saifedean paints). Trying to direct the development to capture a definition of money opens a huge attack vector. It's not different than trying to decide what is spam. 

Also what is the difference between the bashers slogan that bitcoin is p2p money and "bitcoin is money"  They seem like the same thing? 

[Kyle Stout]

Dathon,

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

This seems to be the crux of your argument. I believe it is misleading and technically unsound. It's technical theater that creates a distinction without any meaningful difference.

First, Bitcoin has no concept of a file viewer. To interpret any embedded data other to validate it against Bitcoin's rules, you must use a third party tool. Practically speaking, the differences are negligible in terms of technical difficulty, as humorously demonstrated here: https://x.com/rot13maxi/status/1963318690759192622 . Contiguous or not, you're file carving. 

Second, by definition, you're misinterpreting the data vis-a-vis Bitcoin since it has no native concept of 'image', 'video', etc. Arbitrary bytes are meaningless. The purpose of having OP_RETURN as a standard output is to protect the UTXO set from being abused. It isn't some kind of 'blessing' to store files. That's absurd. As you admit, it's impossible to stop people from writing arbitrary bytes to the blockchain, so this is damage mitigation, not an invitation.

Third, contiguity is not a legally meaningful predicate. "Your honor, we tried to limit the contiguous bytes!" is simply not going to fly. The bytes exist either way, and they must be interpreted by third party software either way. If anything, this path is going to represent a voluntary self-policing that will result in more culpability. Right now, arbitrary bytes don't mean anything in Bitcoin. If it's valid, it's valid. Nodes relay opaque protocol data. If you insist on only accepting 'approved' arbitrary bytes, you're opening the door to a knowledge/intent accusation.

Regards,

Kyle

[Greg Maxwell]

The only consensus normative data encoding in Bitcoin is the order data goes into hashes.  The representations in memory, rpc, in the p2p network, etc. are already different and could be made arbitrarily different without any consensus change.  Case in point:  the data is now normally encrypted on disk and in P2P.  There are also proposals such as BIP 337: https://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki  none of these things are consensus changes-- many aren't even bippable because they don't have interoperability considerations (e.g. representations on disk/memory).

Forget for a moment the (un)likelyhood that the concerns being discussed are meaningfully modulated by exactly how data is represented in p2p, memory, rpc, disk, etc.. for assumption just assume they are.

If so, the correct move would be to change those encodings rather than any consensus rule change--- particularly because any consensus rule method will simply be evaded, and can't provide the level of swizzling that changing the encoding can accomplish.  Encoding changes are also substantially non-coercive: people who think they're valuable can adopt them and leave other people alone.

Good news for everyone except those who consider coercing others to be a terminal goal. 

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/7abf7055-6b85-492f-ada2-e0a517e93cf9n%40googlegroups.com.

[dath...@proton.me]

Hi list -

Thanks for all of the feedback everyone!

I am working on a new draft of the BIP that will hopefully address everyone's concerns and avoid the misunderstandings that have arisen.

I apologize for not being able to respond to all of you, but know that I did indeed read your messages.

Best,

Dathon

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-FgP%2BpehOL8PYhWgewbg%40mail.gmail.com.

[Antoine Riard]

Hi Dathon Ohm,

I did a cursory review of your BIP proposal, not on the technical matter as there
is no reference implementation available, but I did one on the legalities raised
in the text (grep'ing the word "legal" one can find 15 references versus only 2
references to the word "technical").

Under European law, there is a clearly established line of jurisprudences exonerating
internet service providers or hosting operators to have to install a system for
filtering all electronic communications passing via its services which would
apply indiscriminately to all its users for any kind of content (CJUE, 24-11-2011,
aff C-70/10 Scarlet Extended SA c/ SABAM, CJUE, 16-02-2012, aff C-260/10 SABAM c/ Netlog).
Rather to engage in generic filtering on the burden of services providers, courts
have generally yielded decisions asking for fine-grained deletion of a specific content,
as a safeguard of other interest at stake, notably users's right to privacy [0].

Further, in the eventuality of an extended filtering system would have to be put
in place by a service provider, and if said filtering system design would be unable
to dissociate between legal content and illegal content, the introduction of this
filtering system would consistute an infringement of the freedom of expression and
information (CJUE, 26-04-2022, aff C‑401/19). Those judicial decisions are litteraly
encompassing peer-to-peer softwares in their scope, as somehow before Bitcoin, they
was something called Bittorent.

Moreover, this line of jurisprudence underlights that any interference with one's
fundamental right of expression should be lay down under clear and precise rules
governing the scope of the interference. This is not a mere formality, as again
and again too restrictives measures are strike down (CEDH, 02-02-2016, Index.hu/Hungary,
aff. n° 22947/13). As far as I know, I'm not aware of any European continental
country that has made a legislation on how one is allowed to use his right to
the freedom of expression in the context of publishing stuff in a Bitcoin block.

Under the US law, I won't risk making legal comment for now, as for anyone who is
following the work of the Electronic Frontier Foundation from times to times, there
is a pending case in front of the US Supreme Court, Cox Communications, Inc vs. Sony
Music Entertainment specifically on the liability of Internet service providers. But
culturally the US are even more protective on the freedom of expression, which puts
an even higher legal bar for any restriction of it.

I concur with Gregory Maxwell. There is zero need to change the consensus rules.

In the idea one would like to limit one's responsability arising from how bitcoin
consensus data can be encoded or decoded to "obviously" "illegal" content (as strictly
defined by a specific national legislation) [1], fuzzy encoders and decoders for
end-to-end or point-to-point communication could be formalized as BIP documents,
that would put an asymmetric cost on the decoders, with the upper bound being the
impossibility of decoding.

Fuzzy algorithms is not sci-fi tech it's actually what is used for Minisketch.

Best,
Antoine
OTS hash: f0e10776d4e4d32873ca319daf3b76c8e645a0d510a6bb803bb8685292c119d4

[0] "Those addresses are protected personal data because they allow those users to be precisely identified"
[1] This is not a mere technicality, under information theory, one could come up with
a alphanumeric encoding algorithm that could certainly yield text-based religious blaspheme
in a lot of countries in the world from years-old un-reorgable historical blockchain data.
We're all used to "The Times 03 Jan..." in the genesis block, but it's just picking hex
as a decoding algorithm...

[/dev /fd0]

Hi Greg,

> There are also proposals such as BIP 337: https://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki  none of these things are consensus changes-- many aren't even bippable because they don't have interoperability considerations (e.g. representations on disk/memory).

[Compression][0] of raw transactions is interesting although it won't be helpful in this case. I had reviewed the pull request that implemented BIP 337 in bitcoin core and was closed. Maybe we can add it in knots.

> Forget for a moment the (un)likelyhood that the concerns being discussed are meaningfully modulated by exactly how data is represented in p2p, memory, rpc, disk, etc.. for assumption just assume they are.

> If so, the correct move would be to change those encodings rather than any consensus rule change--- particularly because any consensus rule method will simply be evaded, and can't provide the level of swizzling that changing the encoding can accomplish.  Encoding changes are also substantially non-coercive: people who think they're valuable can adopt them and leave other people alone.

I am not sure if encoding or encryption would be the right approach but this is worth trying. I have opened an [issue][1] in knots repository to discuss these ideas and also created a web [page][2] that shows the binary for OP_RETURN in a transaction. 

[0[: https://github.com/bitcoin/bitcoin/pull/29134
[1]: https://github.com/bitcoinknots/bitcoin/issues/229
[2]: https://opreturn01.github.io/

/dev/fd0

floppy disk guy

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-FgP%2BpehOL8PYhWgewbg%40mail.gmail.com.

[Max]

Why don't we just quickly soft fork to disallow large OP_RETURN outputs (i.e. keep them capped to 80 bytes) only, with forward-looking activation (no retroactive block invalidation)? This would give the market a clear and simple way to decide whether such transactions are acceptable or not. It wouldn't have any of the issues mentioned so far in the discussion like creating an incentive to put CSAM or other illegal content to attempt a reorg double spend due to the complex deployment mechanism proposed in BIP-444 or like putting in jeopardy existing Taproot functionality by touching other primitives. We don't actually need to remove all the mechanisms that can be used for embedding data (which has been demonstrated to be impossible). Rather what we need is to give users the opportunity to signal whether arbitrary data is welcome or not.

If the legal concerns are compelling enough to warrant consensus changes, miners should support a clean soft fork immediately. If the market quickly adopts the new consensus-level OP_RETURN restrictions it would announce sufficiently clearly to the world that arbitrary data is not welcome and deter future attempts to bring that to Bitcoin by showing the network's readiness to resist such efforts. I believe that this PR is too dramatic and needlessly complicated for what we need: letting the market decide whether to accept or reject the explicit invitation for arbitrary data storage that Core v30 has created. Technical changes should be limited to this question only and simple enough for people to make a decision without being distracted or overwhelmed by adjacent issues.

[Erik Aronesty]

Case law in the USA regarding illegal content has always rested squarely on those who:

 1 - provide broad public access, in this case a company like OpenSEA (which has had to block content)
 2 - the original author 

if punishing "relays" was a thing, then every CISCO router, SMTP relay and DISCORD server that provided access would be in court all day long

instead, it's the users of the illegal data and the publishers that actually wind up in trouble - not the internet providers

the bitcoin ledger is neither a browser or web server, nor is it an image uploader.  there is zero ability to view images built into the system

and even if it was

the purpose of this software is to be a distributed and effectively uncensorable ledger. 

hopefully it doesn't change because someone launched a meme campaign with vague threats of legal action

if a transaction has /no reasonable expectation of being mined/ (too expensive to validate, too large, too low fees), there's also no reason to relay it

this is probably the best way to set policy