BIP-110: advance to Complete status#2201
Conversation
…estore OP_IF byte-saving note
jonatack
added
BIP Update by Owner
There was a problem hiding this comment.
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)."
| # 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. |
There was a problem hiding this comment.
On-chain transparency of spending conditions is a well known use case.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
The fact that a use case is possible does not mean it is practical. All use cases invalidated by BIP-110 are accordingly pathological.
|
Hi @jonatack:
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.
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).
Does this include past changes, or just changes made from this point moving forward? |
Good idea.
Up to you, I think. |
|
@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. |
|
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. |
|
@jonatack - pushed. |
3 participants
Also emphasize UTXO grandfathering and restore OP_IF byte-saving note.