Hello all,
Given the recent discussions about Taproot [1] and Graftroot [2], I
was wondering if a practical deployment needs a way to explicitly
enable or disable the Graftroot spending path. I have no strong
reasons why this would be necessary, but I'd like to hear other
people's thoughts.
I'm definitely in favor of the suggestion of requiring a flag to allow the usage of these in a transaction, so that you get to choose in advance if the script will be static or "editable".
Consider for example a P2SH address for some fund, where you create a transaction in advance. Even if the parties involved in signing the transaction would agree (collude), the original intent of this particular P2SH address may be to hold the fund accountable by enforcing some given rules by script. To be able to circumvent the rules could break the purpose of the fund.
The name of the scheme escapes me, but this could include a variety of proof-requiring committed transactions, like say a transaction that will pay out if you can provide a proof satisfying some conditions such as embedding the solution to a given problem. This fund would only be supposed to pay out of the published conditions are met (which may include an expiry date).
To then use taproot / graftroot to withdraw the funds despite this possibility not showing in the published script could be problematic.
I'm simultaneously in favor of being able to have scripts where the usage of taproot / graftroot isn't visible in advance, but it must simultaneously be possible to prove a transaction ISN'T using it.