Skip to content

BIP-110: advance to Complete status #2201

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jonatack merged 3 commits into from
Jun 28, 2026
Merged

BIP-110: advance to Complete status #2201

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f952fd1
BIP-110: advance to Complete status; emphasize UTXO grandfathering; r…
dathonohm Jun 24, 2026
422fca7
BIP-110: Add Test vectors and Changelog sections
dathonohm Jun 26, 2026
b0a1a27
BIP-110: Add test vectors JSON and generator script
dathonohm Jun 26, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions README.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -624,13 +624,13 @@ users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority
| Gavin Andresen
| Specification
| Closed
|-
|- style="background-color: #ffffcf"
| [[bip-0110.mediawiki|110]]
| Consensus (soft fork)
| Reduced Data Temporary Softfork
| Dathon Ohm
| Specification
| Draft
| Complete
|- style="background-color: #cfffcf"
| [[bip-0111.mediawiki|111]]
| Peer Services
Expand Down
10 changes: 7 additions & 3 deletions bip-0110.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
Layer: Consensus (soft fork)
Title: Reduced Data Temporary Softfork
Authors: Dathon Ohm <dathonohm+bip@proton.me>
Status: Draft
Status: Complete
Type: Specification
Assigned: 2025-12-03
License: BSD-3-Clause
Expand All @@ -30,7 +30,11 @@ Blocks during a temporary, one-year deployment are checked with these additional
# Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid.
# Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.

Inputs spending UTXOs that were created before the activation height are exempt from the new rules.
===UTXO grandfathering===

'''Inputs spending UTXOs that were created before the activation height are exempt from all of the new rules.'''
This grandfathering ensures that no existing coins can be frozen or rendered unspendable by this softfork: any UTXO confirmed before activation can always be spent exactly as it could before, throughout the entire deployment.
The new rules apply only to UTXOs created at or after the activation height.
Comment thread
jonatack marked this conversation as resolved.
Once the softfork expires, UTXOs of all heights are once again unrestricted.

===GetBlockTemplate===
Expand Down Expand Up @@ -177,7 +181,7 @@ Yes:

# Limiting Taproot control blocks to 257 bytes directly constrains the size of the on-chain, consensus-enforced script tree. This could complicate or possibly even impede advanced smart contracting like BitVM, which relies on a large number of executable scripts. In the worst case scenario, these use cases may just need to wait until this softfork expires. As they are still in early development, testnet and sidechains should be sufficient for the next year while a more scalable rule is implemented.
# Upgrade hooks are not available for other softforks. As softforks adding new opcodes typically need at least a year to activate, this shouldn't be a practical issue.
# Some wallet software such as Miniscript habitually creates Tapleaves containing OP_IF. To mitigate the risk of these funds being frozen for a year, this proposal exempts inputs that spend outputs that were created before activation, and provides a two-week grace period between lock-in and activation, to give users time to prepare.
# Despite there being no known use case that requires it, some wallet software such as Miniscript habitually creates Tapleaves containing OP_IF, which in some hypothetical cases can require less data than the equivalent construction using additional Tapscripts. If such a use case is discovered, this simply increases the fee for that construction until the softfork expires.

@lifofifoX lifofifoX Jun 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On-chain transparency of spending conditions is a well known use case.

@dathonohm dathonohm Jun 25, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is theoretical, and there are no known non-experimental implementations, to my knowledge.

Besides, P2WSH already allows on-chain transparency of spending conditions, for fewer bytes.

@lifofifoX lifofifoX Jun 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is it theoretical? It's literally how it works. IMO, you should try to use Bitcoin a bit more often under real life constraints.

@dathonohm dathonohm Jun 26, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fact that a use case is possible does not mean it is practical. All use cases invalidated by BIP-110 are accordingly pathological.


'''Isn't the limit on Taproot control blocks too restrictive?'''

Expand Down