BIP draft: 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.

[murchandamus]

I gave this proposal a quick first pass.

Overall, key issues with this proposal are that it:

• Breaks user space and introduces confiscatory surface
• Is missing proper motivation and rationale
• Fails to address backward compatibility
• Does not obviously represent a net improvement

Several sections are underdeveloped:

• The Abstract fails to describe the issue being addressed and does not provide a proper overview of the proposal
• The Motivation section is insufficient to explain why this BIP is being written, how the existing situation presents a problem and how this proposal improves the situation.
• The Specification needs to describe the exact syntax and semantics of all the newly introduced rules.
• The Rationale should be extended to discuss alternative approaches. Multiple reviewers have suggested simpler changes that could achieve goals stated by the author in this pull request, and this proposal does not make a case of why exactly the proposed protocol changes are sufficient, necessary, or most likely to achieve the intended outcome. Several reviewers have suggested alternative approaches or pointed out gaps in the proposed rules.
• The Backwards Compatibility section insufficiently addresses that this document intentionally breaks user space in multiple ways. These incompatibilities must be described explicitly, and the document must provide instructions on how implementers and users should deal with these incompatibilities.

For the readability of this pull request, please mark review comments as resolved when you have fully addressed them.

[murchandamus]

It is not clear why the possibility to commit to data in a Taptree is supposed to “make even hypothetical use of OP_RETURN deprecated”.

[moonsettler]

If anything replaces OP_RETURN in use, it would be the Annex. Taptree requires pre-commitment, same as witness script payloads.

[dathonohm]

@murchandamus There is a technique called "pay-to-contract" or "pay-to-contract-hash" which tweaks a public key with a hash, enabling data to be anchored into a payment with no additional data storage requirements. I can track down more info if you like.

@moonsettler This proposal invalidates the annex.

[petertodd]

@dathonohm "anchoring" is an ill-defined term that should not be used, especially in technical contexts.

What you are talking about is a commitment. Commitments are notoriously insufficient for many use-cases. For example, for Lightning to work there is a hard requirement to publish data in HTLCs. Mere commitments are insufficient. If you take away OP_Return and the Taproot annex, people will simply publish data in scriptPubKeys instead - the exact issue that lead to the creation of the OP_Return mechanism in the first place.

[dathonohm]

What you are talking about is a commitment.

This demonstrates that you understood what I meant.

Commitments are notoriously insufficient for many use-cases.

Use cases that need more than 80 bytes of arbitrary data have been rejected by the Bitcoin network since 2014.

for Lightning to work there is a hard requirement to publish data in HTLCs. Mere commitments are insufficient.

The HTLC preimage is 32 bytes, so it meets the limits decided in 2014. Hashes are generally also 32 bytes.

If you take away OP_Return and the Taproot annex, people will simply publish data in scriptPubKeys instead - the exact issue that lead to the creation of the OP_Return mechanism in the first place.

This should be dealt with in policy. The BIP explains this already.

[murchandamus]

This paragraph is false. There are wallets that use script leaves with OP_IF in their default wallet setup (e.g., Liana) and more wallets that support Miniscript which makes use of OP_IF. This breaks user space and has confiscatory potential.

[dathonohm]

As I've stated elsewhere, I am open to amending this BIP's spec if a single example of a pre-RDTS use case that uses pre-signed transactions with Taptrees deeper than 7 levels or OP_IF/NOT_IF can be demonstrated.

If not, I don't think it is valid to claim that this proposal "breaks userspace" in any harmful way.

[murchandamus]

I was corrected on Liana using OP_IF by default in Tapscript. OTOH, @Rob1Ham already reported two weeks ago:

I've run some initial tests, the miniscript compiler will use OP_IF and OP_NOTIF for taproot descriptors if you don't break it out spending conditions into specific tapleafs explicitly, so this would be freezing those funds on chain (or confiscating if this was extended indefinitely).

And it is my understanding that at least Ledger, Bitbox, Coldcard, BDK, Specter, MyCitadel, Liana, Nunchuk, Bitcoin Keeper, Blockstream Jade, AnchorWatch, and Bitcoin Core have support for Miniscript. I’m not sure how many of these support Tapminiscript, but it is hard to fathom that the proposed protocol change doesn’t create undue problems for any of these wallets and services.

Claiming that “OP_IF is redundant” is insufficient to address this concern.

[Rob1Ham]

Indeed, the miniscript compiler will use OP_IF & OP_NOTIF, as shown here on signet.

Specific tapleaf here.

On that list of companies murch, to my understanding the following use tapminiscript:

• Ledger
• Bitbox
• Coldcard
• BDK
• Liana
• Nunchuk
• Bitcoin Core

[dathonohm]

Thanks for the investigation @Rob1Ham and @murchandamus.

I remain open to amending the spec if any wallet software habitually creating Tapleaves with OP_IF are found.

If not (and potentially if so), I believe it should be sufficient to warn wallet developers to avoid doing this in the near future.

[dathonohm]

I should note that @mononaut discovered what appears to be a valid use case for an HTLC-like construction using OP_IF in a Tapleaf, which raises concerns.

Hopefully this was just a one-off experiment, and not something that is likely to occur again.

If anyone has more detailed information about what software created this and whether users might commonly be using it, that would be extremely helpful.

[dathonohm]

Also note that Liana wallet developers say that the current version of Liana does not generate Tapscripts with OP_IF, so I think as long as they don't proceed to implement that, we are fine.

[bitcoin-eagle]

That's incorrect. Here is a counter example. Liana devs just don't understand miniscript compiler because it's not their job to.
https://x.com/pythcoiner/status/1988478857876529648

[murchandamus]

This document has failed to demonstrate threats to either of these. Please substantiate the cited threats.

[dathonohm]

Again, you seem to have just jumped right over my arguments, which I think were well constructed. Bitcoin node operators store the blockchain forever because that's absolutely mandatory in order for Bitcoin to be money. If Bitcoin degrades into something that is no longer money, then the incentive to run a node disappears. If incentives to run a node disappear, then so do nodes. If nodes disappear, then so does decentralization.

[murchandamus]

This is false. This softfork proposal proposes to restrict established wallet descriptor patterns.

[dathonohm]

Again, no non-pathological, pre-RDTS, real-world examples have been demonstrated.

[john-moffett]

Care to edit/delete this comment in light of #2017 (comment)?

[murchandamus]

The Backwards compatibility section needs to address how the deliberate breaking of established wallets' modus operandi should be addressed.

[dathonohm]

Again #2017 (comment)

[bitcoin-eagle]

That's not sufficient answer.

1. People need to validate if their wallet is BIP444 compatible.
2. They need to migrate to BIP444 compatible wallet if they are using incompatible
3. They need to actively prevent receiving new coins to BIP444 incompatible wallet (both change and receive addresses)
4. There needs to update to miniscript compiler

https://x.com/mononautical/status/1988953736774053920

[bitcoin-eagle]

Sometimes OP_IF makes transaction smaller
https://x.com/salvatoshi/status/1989270625454584132

[michaelfolkson]

I can only speak for myself but I am personally dead set against temporary consensus changes. If a consensus change is worth doing and has overwhelming community consensus then why not make it permanent? It doesn't impact the finalization of this BIP but just stating that I'd personally be against an attempted temporary consensus change activation regardless of the proposal. If the community is unsure whether it should be activated and this is the reason it is temporary then I don't think it should be activated at all. Mempool and transaction relay policy can be changed on the fly, especially in an implementation like Knots, but consensus changes are a totally different animal.

[moonsettler]

Hmm. It has to be temporary, because it disables a whole bunch of upgrade hooks and upgrade paths that are already planned to be used. I would hard NĀCK-it as a permanent change and I think I'm not alone. However, while they are not yet in use, they allow for arbitrary payloads into blocks which this proposal tries to restrict. It would be seen as an extremely destructive and hostile move proposed as a permanent change. As a temporary change it could in theory be gradually reduced in scope to give way to new features activated that otherwise restrict those upgrade hooks.

This is not an endorsement, just an explanation.

[dathonohm]

I've warmed to the idea of temporary soft forks since I first heard about them. They seem particularly effective for discouraging spam, which is a cyclical phenomenon that is nonetheless very sensitive to community sentiment.

The danger of permanent forks, of course, is that if there are non-pathological use cases that are affected, then people's money is permanently burned, rather than just temporarily frozen.

Permanently forking also means that we would need to hardfork in order to get those use cases back. Though this could probably be worked around with new Segwit/Tapscript versions.

But if the community wants this change to be permanent, then I'm not necessarily opposed.

[dathonohm]

There has never been a soft fork (in post Satoshi's time at least) that was motivated by spam.

Indeed, this would be the first, since perhaps the 2010 Great Script Disabling. But it is not completely without precedent. I think it is a positive rather than harmful precedent to occasionally fork in order to amend the consensus rules because of problems introduced in previous forks. This precedent allows the Bitcoin community to be more confident adding new functionality, preventing permanent ossification.

There are chain split risks every time you make a consensus change (bug in the code, bug in the activation code, clients with different activation methods, UASF/URSFs etc).

Chain split risks are a very valid concern and forks should be approached with the utmost caution.

It starts to resemble consensus rule changes on other blockchains like Ethereum where a small number of protocol developers make regular changes on everything from difficulty bombs to the monetary policy/mining rewards.

Avoiding turning Bitcoin into something resembling Ethereum is indeed a primary goal of this proposal.

I don't think this temporary softfork creates a significant precedent of more frequent forks. If the proposal's rules prove unpopular after a year, the expiry will not create a fork and will not require coordination, as all old node software will simply revert to the unrestricted rule-set upon expiry.

I do share your concern that the proposal sets a precedent of creating temporary softforks in urgent situations, to then be amended upon expiry with a more permanent fix. I agree that this could be undesirable; however, I think this situation is unique in that the maintainers of the most popular node software blindsided the community by suddenly switching from anti-spam to pro-spam. As long as this never happens again, I don't see a valid reason emerging that would justify it being used again. We should always attempt to remain vigilant to make sure we catch and filter data abuse early, rather than letting it metastasize into a well-funded industry as it did this time.

But I'm not convinced that temporary softforks aren't a useful tool to have just in case.

[petertodd]

This draft continues to disable OP_IF/OP_ELSE/OP_ENDIF in Tapscript for no particular reason. The response by to me using my decade old, pre-segwit, https://github.com/petertodd/python-bitcoinlib/blob/master/examples/publish-text.py script to publish the BIP contents in a BIP-compatible way was to say that the objective is to ensure that data is non-contiguous. For that objective, all that is necessary is to limit the size of contiguous data.

Why is the confiscatory removal of OP_IF still in this BIP?

Indeed, I have to ask the same question about the disabling of OP_Success: that has nothing to do with contiguous data, and addresses no common transaction pattern. The only thing it accomplishes is to delay further soft-forks.

And again, why is the taproot annex entirely disabled, rather than length limited? Again, the only goal this BIP could possibly achieve is to restrict the length of contiguous data. If the taproot annex is, say, limited to 256 bytes that goal would still be achieved.

[dathonohm]

Hi @petertodd -

Why is the confiscatory removal of OP_IF still in this BIP?

OP_IF in Tapscript is responsible for a more than doubling of the size of the UTXO set, and a spam flood that prevented normal monetary usage of Bitcoin for more than a year.

This proposal does not "confiscate" anyone's funds as far as I am aware. I am still investigating a few cases of what appear to be experimental usage from several months ago. But the fact that UTXOs created before the softfork activates are exempt from the rules means that it's very unlikely anyone's funds will be frozen, let alone "confiscated".

But even if a few sats are frozen for a year, the community may find this tradeoff worth it in order to eliminate the spam industry that has parasitically attached itself to Bitcoin.

Indeed, I have to ask the same question about the disabling of OP_Success: that has nothing to do with contiguous data, and addresses no common transaction pattern. The only thing it accomplishes is to delay further soft-forks.

Arbitrary data can be inserted into a Tapscript after an OP_SUCCESS, because no data afterwards is checked, and no size limits enforced.

And again, why is the taproot annex entirely disabled, rather than length limited? Again, the only goal this BIP could possibly achieve is to restrict the length of contiguous data. If the taproot annex is, say, limited to 256 bytes that goal would still be achieved.

I will consider this proposal.

EDIT: I don't think the added complexity of limiting the annex to 256 is worth it, since it's already not being used for anything. What is your argument for keeping it?

EDIT2: OP_SUCCESS allows uncapped contiguous arbitrary data, so your claim to the contrary is wrong. And the fact that it disables upgrading Tapscript while the deployment is active is already addressed in the BIP.

[john-moffett]

OP_IF in Tapscript is responsible for a more than doubling of the size of the UTXO set

To be clear, OP_IF itself has little to nothing to do with the ability to push arbitrary data efficiently. With OP_IF under the rest of the rules of this draft, you can insert approximately 396,393 bytes of arbitrary data payload in a standard tx. Without it, that only drops down to approximately 395,640 bytes, a ~0.25% decrease.

But the fact that UTXOs created before the softfork activates are exempt from the rules means that it's very unlikely anyone's funds will be frozen, let alone "confiscated".

This does not address the risk of chains of presigned transactions being confiscated/lost.

in order to eliminate the spam industry that has parasitically attached itself to Bitcoin

This draft does not even significantly increase the burden for spammers let alone eliminate the entire industry.

[dathonohm]

Hi all -

I've updated the BIP document to address the feedback so far.

• The Abstract and Motivation sections have been extended a bit per @murchandamus' request.
• The Specification section clarifies some details.
• The Deployment section has been removed. I am leaning toward an MASF with a long signaling window, to give the ecosystem more time to prepare.

Next I will extend the Rationale section with more alternative approaches, again as requested by @murchandamus.

Here are the "alternative approaches" I gathered. Please let me know if I have missed any:

1. Ban pushdata instead of limiting pushdata size
2. Apply a length limit to the Annex instead of invalidating it
3. Add limits on overall witness or transaction sizes
4. Make softfork permanent rather than temporary
5. Change activation to miner-activated
6. Removing the witness discount/making OP_RETURN cheaper

I will also update the Backwards Compatibility section to address some monetary use cases that are potentially affected. So far it seems the biggest concern is OP_IF being used by Miniscript, though thankfully it seems as though no popular wallet software is generating such scripts currently. Liana was the one wallet mentioned as most likely to include such scripts, and its developers have confirmed that it does not do this.

However, @mononaut discovered what look like HTLCs that use OP_IF in Tapscript from several months ago, and I am requesting more information about this use case if anyone has it, to determine whether it is likely still being used today.

Depending on the result of the investigation, this could end up affecting the spec of this BIP, or the community might decide to accept the risk that some small amounts in such constructions could be affected.

In any case, I think the longer activation timeline will mitigate practically all concerns about confiscation/freezing risk.

I am grateful to everyone for your feedback and support so far.

[murchandamus]

Especially in this early draft phase and the immense count of comments, it would be common courtesy to avoid force pushes since it makes it unnecessarily arduous for your reviewers to keep track of whether their review comments have been addressed. Please instead add commits to evolve your draft. The commit history can be squashed before the merge, if found to be advantageous.

[dathonohm]

@murchandamus Understood.

[pinheadmz]

Serious question: why not just prohibit the magic bytes in data fields? FFD8FFE000104A4649460001 is astronomically unlikely to "occur naturally" in a bitcoin transaction, and prohibiting this exact sequence of bytes would by definition keep the blockchain clear of jpgs forever.

[petertodd]

Prohibiting magic bytes can be used adversarially in multi-party protocols, e.g. to make it impossible to recover funds in Lightning. For example, by using that prohibited sequence in a HTLC, or in a scriptPubKey in the commitment transaction. You can't just rely on chance for this. The problem isn't random failure. It's targeted attack.

…

On November 13, 2025 8:33:14 AM CST, Matthew Zipkin ***@***.***> wrote: pinheadmz left a comment (bitcoin/bips#2017) Serious question: why not just prohibit the [magic bytes](https://en.wikipedia.org/wiki/List_of_file_signatures) in data fields? `FFD8FFE000104A4649460001` is astronomically unlikely to "occur naturally" in a bitcoin transaction, and prohibiting this exact sequence of bytes would by definition keep the blockchain clear of jpgs forever.