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)."
|
|
||
| '''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. |
There was a problem hiding this comment.
Do you wish to wait for review feedback on this change to the Specification, before updating to Complete?
There was a problem hiding this comment.
It's not a change, just a clarification. Many commenters were apparently unaware of UTXO grandfathering, so I decided to make it more prominent.
| # 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.
|
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. |
3 participants
Also emphasize UTXO grandfathering and restore OP_IF byte-saving note.