BIP 110: Reduced Data Temporary Softfork

[dathonohm]

Mailing list thread at https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8

---

Editor note: please post conceptual feedback and meta-commentary on the mailing list thread, and focus here on:

• expert technical review of the specification
• specific, concrete, helpful proposals for the other sections

Please refrain from personal or heated commentary, trolling, pedantry, and repeating yourself. As this PR now has many comments, please only comment if you are adding new valuable information to the discussion.

[rot13maxi]

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.

[dathonohm]

@rot13maxi see the deployment section

[portlandhodl]

There is opportunity to also discuss the effect on DoS blocks and the scope of legacy script as a DoS vector.

[GregTonoski]

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.

[ekzyis]

Will or can this softfork affect lightning or currently planned upgrades of it?

_{btw, fwiw, there's also some discussion at https://stacker.news/items/1265553 (sorry for the shameless plug, I work at SN)}

[Rob1Ham]

According to BIP-2:

Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to the Bitcoin development mailing list.

When will this be posted to the mailing list as its own thread so it can get greater attention & review?

[jonatack]

When will this be posted to the mailing list as its own thread so it can get greater attention & review?

I reached out yesterday to suggest this and apparently the post is currently in the ML queue for acceptance/publication.

[benthecarman]

why no limit on witness or tx size?

[thewrlck]

I don't think it's a good idea to outright prevent content or actions that are not 100% certain spam

[jonatack]

When will this be posted to the mailing list as its own thread so it can get greater attention & review?

Hi all, a mailing list post by has been published by the BIP author at https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8.

Post conceptual feedback and meta-commentary there, and focus here on:

• expert technical review of the specification
• specific, concrete, helpful proposals for the other sections

Please refrain from personal or heated commentary in both venues. I've attempted some minor moderation here above.

[dathonohm]

Hi all -

I have pushed another minor update. All feedback is now addressed, to the best of my knowledge.

Please let me know what is the next step to get a number assigned, and for the BIP to be merged.

Thanks again for your feedback and support!

[jonatack]

Assigned 110.

Note that assignment does not represent evaluation by the editors whether the proposal is likely to be adopted.

Please update the file names and BIP draft headers, including "Created: 2025-12-03" for the date of assignment, and add an entry to the README.

[dathonohm]

@jonatack Done.

[cryptoquick]

I'm generally supportive of the changes in this BIP. Aside from minor nitpicks in language, the 34 byte scriptPubKey restriction I think will prove to be quite valuable in addressing the larger concern of DoS blocks / poison blocks that impose such high computational costs on nodes that a single block would take 30 minutes to verify on decent hardware instead of taking about a second. This is an even larger threat to Bitcoin than either CSAM or quantum, because I've read that CSAM has already been present on Bitcoin for a very long time, and quantum computers aren't anywhere near good enough to be a threat, and may never be, whereas DoS blocks could be introduced by miners who take direct submissions without sufficient checks at any time.

It's been pointed out that disabling OP_SUCCESS in Tapscript would conflict with adding new signature verification opcodes in future BIPs that might use them to add quantum resistance, but I would point out that the semantics around existing opcodes could simply be altered to preserve compatibility with BIP 110. For example, instead of creating new sets of OP_CHECKSIG opcodes to support new signature schemes, the semantics of existing OP_CHECKSIG opcode could simply be adjusted to accept imperatively inputs of varying lengths, a form of overloading / polymorphism / or duck typing. While it could be argued that a more declarative approach is superior in cryptographic contexts, I don't weight that concern as heavily as the larger concern over DoS blocks, and as such, I'm supportive of this approach.

My only major objection is that this is temporary. I'm not very comfortable with either temporary soft forks or default node expiry because it forces users to act instead of delaying action, which I think delaying action is perfectly fine and reasonable as the protocol matures. It also reminds me too much of the "difficulty bomb" based monetary policy used to coerce Ethereum miners to adopt new code from the Ethereum foundation or else. That said, if BIP 110 were activated as is, I would still be supportive, and I would also support reactivating it in the future as a more permanent feature of Bitcoin.

At a high level, this proposal reminds me in spirit of early versions of my original P2QRH proposal. I just think it could use a little more polish, but I see it as being directionally correct.

[cryptoquick]

Actually, this is a common misconception about the UTXO set database. It is implemented as a Log Structure Merge tree data structure which allows for flexibility in where the data resides. It can be stored in various levels, including slower hard drives, which is why it's called LevelDB. Fortunately it is a very performant and battle tested embedded key value store that can scale well even on commodity non-server grade hardware. While the UTXO set needs to be checked with every transaction to prevent double spends, it does not need to be held entirely in memory.

[cryptoquick]

I would object to the statement that no legitimate use for OP_RETURN has been found when timestamping of documents in the 2023 Guatemalan elections helped prevent disputes of the outcome of that contentious election to prevent fraud by using Bitcoin as a source of truth.

https://bitcoinmagazine.com/business/how-bitcoin-can-protect-public-records-with-simple-proof-2

That said, timestamps can fit within the 83 byte OP_RETURN exception made in this BIP.

[murchandamus]

Also as pointed out here in October, OP_RETURN is mandated in Coinbase transactions for Segwit’s commitment structure: https://github.com/bitcoin/bips/pull/2017/files?diff=unified&w=0#r2463933146

[moonsettler]

I would object to the statement that "timestamping of documents" is a legitimate use, it does not prove anything about the validity of the statements. You can absolutely timestamp lies. It's also possible to timestamp conflicting predictions and reveal the one that turned out to be justified, making you look smarter than you are. Some people keep mistaking timestamping with "proof of publication" which is also wrong. Timestamps don't prove that the document is actually published at that time.

They only really prove one thing: someone had the preimage at an earlier time than present.

[cryptoquick]

@moonsettler None of the points you made contradict the value Simple Proof and Open Timestamps had in the example I provided.

[moonsettler]

Heard that story, but still don't understand why people think timestamping proves anything about the authenticity of the data. It's a weird assumption that if the integrity and source of the data can be verified somehow it's valuable to also verify when it was created in general.

The point about compromised or backdated PGP keys is harder to dismiss. Feels like there might be some value there for a decentralized "unforgeable" timestamps server.

[petertodd]

On Fri, Jan 30, 2026 at 12:07:54PM -0800, moonsettler wrote: I would object to the statement that "timestamping of documents" is a legitimate use, it does not prove anything about the validity of the statements. You can absolutely timestamp lies. It's also possible to timestamp conflicting predictions and reveal the one that turned out to be justified, making you look smarter than you are. Some people keep mistaking timestamping with "proof of publication" which is also wrong. Timestamps don't prove that the document is actually published at that time.

There are plenty of examples where merely knowing that data existed in the past is sufficient to prove something about the validity of that data. For example, various Bitcoin Core contributors both PGP-sign and timestamp their git commits and releases; e.g. tag v28.1 is PGP signed and timestamped by Ava Chow. The value there is that if Ava Chow's PGP key is later compromised at a roughly known time, we can still validate PGP signatures made well prior to the compromise, via the assumption that the attackers do not have a time machine. https://petertodd.org/2016/opentimestamps-git-integration Anyway, if somehow OP_Return was made unusable, OpenTimestamps would simply switch to another commitment mechanism like fake, unspendable, pubkeys. That would bloat the UTXO set. But there's no good way to stop that short of whitelisting.

[murchandamus]

This document has received a substantial amount of review and public discussion. The author appears to have made a reasonable effort to collect and respond to objections and alternative approaches.
As work on this proposal had slowed down for several weeks, and now an activation client is being advertised for mainnet adoption, the author appears to be satisfied with their proposal, even while reviewers continue to be in disagreement about whether objections have been adequately addressed.

While I still perceive this proposal’s Specification to be unsatisfactorily motivated and to exhibit an unusually rushed and careless approach to Bitcoin protocol development, proposals may be further refined after they are published as Draft. It would seem in the interest of the Bitcoin community that this proposal be published in Draft status once the remaining formatting issues are addressed to facilitate community-wide consideration.

A subsequent publication should neither be construed as an endorsement, nor as the BIP Editors expecting this proposal to be adopted.

[murchandamus]

Please update the Preamble to conform with BIP 3.

Suggested change

	Author: Dathon Ohm <[email protected]>
	Comments-Summary: No comments yet.
	Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0110
	Status: Draft
	Type: Standards Track
	Created: 2025-12-03
	License: BSD-3-Clause
	Post-History: https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8
	Authors: Dathon Ohm <[email protected]>
	Status: Draft
	Type: Specification
	Assigned: 2025-12-03
	License: BSD-3-Clause
	Discussion: https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8

[murchandamus]

Suggested change

	| Standard
	| Specification

[murchandamus]

Also as pointed out here in October, OP_RETURN is mandated in Coinbase transactions for Segwit’s commitment structure: https://github.com/bitcoin/bips/pull/2017/files?diff=unified&w=0#r2463933146

[murchandamus]

The Deployment deviates at least in three ways from BIP9. While the lower threshold is explicitly addressed, the absence of a timeout and the newly introduced term max_activation_height are insufficiently explained and an explanation of the mechanism that leads to activation at max_activation_height wholly absent.

I would suggest clarifying, e.g.:

• The mandatory activation appears to be inspired by BIP8’s lockinontimeout, but no timeout is specified and BIP8 is not referenced. timeout is used in BIP9 to limit the latest acceptable height to enter LOCKED_IN and to otherwise transition to FAILED. Without a timeout, what would happen if miners were to signal above the threshold after this deployment expires? Does max_activation_height prevent future transitions to LOCKED_IN instead of timeout? Since the idea that a softfork could expire is novel to this BIP, perhaps clarify the state transitions that succeed ACTIVE.
• In BIP8, the deployment advances to LOCKED_IN on the timeout. When does this deployment lock in for the forced activation?
• Does this deployment use a mandatory signaling period as BIP8 does, or does it simply activate at the max_activation_height?
• If this deployment does use a mandatory signaling period, what rules does this mandatory signaling period follow?