[BIP Proposal] Reduced Data Temporary Softfork

366 views
Skip to first unread message

dath...@proton.me

unread,
Oct 26, 2025, 3:43:57 PM (17 hours ago) Oct 26
to bitco...@googlegroups.com
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

unread,
Oct 26, 2025, 4:49:14 PM (16 hours ago) Oct 26
to dath...@proton.me, bitco...@googlegroups.com
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

unread,
Oct 26, 2025, 6:43:26 PM (14 hours ago) Oct 26
to dath...@proton.me, bitco...@googlegroups.com
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
signature.asc

dath...@proton.me

unread,
1:36 AM (7 hours ago) 1:36 AM
to Peter Todd, bitco...@googlegroups.com
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

unread,
1:36 AM (7 hours ago) 1:36 AM
to Jameson Lopp, bitco...@googlegroups.com
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

Reply all
Reply to author
Forward
0 new messages