1
0
mirror of https://github.com/bitcoin/bips.git synced 2026-06-29 17:39:57 +00:00

BIP-110: advance to Complete status; emphasize UTXO grandfathering; restore OP_IF byte-saving note

This commit is contained in:
Dathon Ohm
2026-06-24 15:42:44 -06:00
parent 861e235e93
commit f952fd1fc0
2 changed files with 9 additions and 5 deletions

View File

@@ -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
@@ -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.
Once the softfork expires, UTXOs of all heights are once again unrestricted.
===GetBlockTemplate===
@@ -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.
'''Isn't the limit on Taproot control blocks too restrictive?'''