BIP-110: advance to Complete status #2201

dathonohm commented at 4:32 AM on June 25, 2026: contributor

Also emphasize UTXO grandfathering and restore OP_IF byte-saving note.

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

jonatack added the label BIP Update by Owner on Jun 25, 2026

jonatack added the label Metadata Update on Jun 25, 2026

jonatack commented at 2:28 PM on June 25, 2026: member

Test vectors missing or planned to be added? Per BIP 3:

"Specification BIPs must come with or refer to a working reference implementation and comprehensive test vectors before they can be moved to Complete. Subsequently, the BIP’s content should only be adjusted in minor details, e.g., to improve language, clarify ambiguities, backfill omissions in the specification, add test vectors for edge cases, or address other issues discovered as the BIP is being adopted."

Edit: I suppose that updating the tests to pass in the reference implementation could fulfill this, but has test coverage specific to the changes been added?

Consider also if you think any non-minor changes to the Specification may still be needed before advancing the status to complete.

Finally, consider if you want to add a changelog. BIP 3 states that "Version 1.0.0 is used to label the promotion to Complete. A Changelog section may be introduced during the Draft phase to record significant changes (using versions 0.x.y)."

in bip-0110.mediawiki:37 in f952fd1fc0 outdated

  29 | @@ -30,7 +30,11 @@ Blocks during a temporary, one-year deployment are checked with these additional
  30 |  # Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid.
  31 |  # Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.
  32 |  
  33 | -Inputs spending UTXOs that were created before the activation height are exempt from the new rules.
  34 | +===UTXO grandfathering===
  35 | +
  36 | +'''Inputs spending UTXOs that were created before the activation height are exempt from all of the new rules.'''
  37 | +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.
  38 | +The new rules apply only to UTXOs created at or after the activation height.

jonatack commented at 2:33 PM on June 25, 2026:

Do you wish to wait for review feedback on this change to the Specification, before updating to Complete?

dathonohm commented at 7:44 PM on June 25, 2026:

It's not a change, just a clarification. Many commenters were apparently unaware of UTXO grandfathering, so I decided to make it more prominent.

in bip-0110.mediawiki:184 in f952fd1fc0 outdated

 180 | @@ -177,7 +181,7 @@ Yes:
 181 |  
 182 |  # 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.
 183 |  # 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.
 184 | -# 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.
 185 | +# 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 commented at 6:20 PM on June 25, 2026:

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

dathonohm commented at 7:45 PM on June 25, 2026:

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 commented at 8:58 PM on June 25, 2026:

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 commented at 1:29 AM on June 26, 2026:

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

dathonohm commented at 8:04 PM on June 25, 2026: contributor

Hi @jonatack:

Edit: I suppose that updating the tests to pass in the reference implementation could fulfill this, but has test coverage specific to the changes been added?

Yes, there is a test file in the reference implementation that specifically targets the spec: https://github.com/dathonohm/bitcoin/blob/uasf-modified-bip9/test/functional/feature_rdts.py. I can update the BIP document to point there, if you like.

All unit and functional tests have been passing since December.

Consider also if you think any non-minor changes to the Specification may still be needed before advancing the status to complete.

The spec has been public and under active review since October, and stable since ~January. A seventh of the network is already running this spec and mandatory signaling begins in a month and a half; changing the spec now would be highly disruptive, so I don't think it's a good idea, unless there is some kind of severe flaw discovered (unlikely because of how simple the changes are).

Finally, consider if you want to add a changelog. BIP 3 states that "Version 1.0.0 is used to label the promotion to Complete. A Changelog section may be introduced during the Draft phase to record significant changes (using versions 0.x.y)."

Does this include past changes, or just changes made from this point moving forward?

jonatack commented at 8:12 PM on June 25, 2026: member

Yes, there is a test file in the reference implementation that specifically targets the spec: dathonohm/bitcoin@uasf-modified-bip9/test/functional/feature_rdts.py. I can update the BIP document to point there, if you like.

Good idea.

Does this include past changes, or just changes made from this point moving forward?

Up to you, I think.

BIP-110: Add Test vectors and Changelog sections 422fca742a

dathonohm commented at 4:36 AM on June 26, 2026: contributor

@jonatack - I've pushed the Changelog and Test vectors sections.

I've also generated some test vectors and a script that verifies them against a node (as well as instructions to the reviewer for how to run the script). I have verified the vectors against the reference implementation (merged into Knots a few weeks ago) and also the port to Core (not merged).

I wasn't sure if it would be useful to have the BIP-110 spec rules in JSON format so I put them on a separate branch. I can push those changes here if you think it's worth it.

jonatack commented at 5:29 PM on June 26, 2026: member

The test vectors and script wouldn't hurt. This PR appears otherwise fine as-is, or you can add them first before advancing here to Complete. Let me know.

BIP-110: Add test vectors JSON and generator script b0a1a27602

dathonohm commented at 5:32 AM on June 27, 2026: contributor

@jonatack - pushed.

jonatack commented at 1:22 PM on June 27, 2026: member

Thanks for updating. The new additions look well-documented.

in bip-0110.mediawiki:10 in b0a1a27602

jonatack commented at 1:26 PM on June 27, 2026:

I overlooked to mention to please add a Version: 1.0.0 header on the line after Discussion.

BIP 3: "After a BIP receives a Changelog, the Preamble must indicate the latest version in the Version header."

jonatack commented at 1:30 PM on June 27, 2026:

(We should add a CI check for missing Version header when a Changelog is present in scripts/buildtable.pl)

jonatack commented at 8:34 PM on June 28, 2026:

Doing these as a follow-up.

jonatack commented at 8:02 PM on June 29, 2026:

Added a Version header in #2203 (edit: and further details to the changelog entry)

dathonohm commented at 4:14 AM on June 30, 2026:

Thank you!

jonatack merged this on Jun 28, 2026

jonatack closed this on Jun 28, 2026