Bitcoin Developers debated making Graftroot, a cryptographic signing scheme, optional or removing it altogether. The discussion began with Pieter Wuille via Bitcoin dev:

Given the recent discussions about Taproot and Graftroot, I was wondering if a practical deployment needs a way to explicitly enable or disable the Graftroot spending path… In theory, it seems that this shouldn’t be needed: the key owners are always capable of spending the funds anyway, so them choosing to delegate to others shouldn’t enable anything that isn’t possible by the key owners already.

He continued by pointing out some of the shortcomings of Graftroot:

Accidentally (participating in) signing a script may have more broad consequences. Without Graftroot, that effect is limited to a single transaction with specific inputs and outputs, and only as long as all those inputs are unspent. A similar but weaker concern exists for SIGHASH_NOINPUT. In a multisignature setting (where the top level key is an aggregate of multiple participants), the above translates to the ability for a (threshold satsisfying) subset of participants being able to (possibly permanently) remove others from the set of signers (rather than for a single output). In a situation where private keys are stored in an HSM, without Graftroot an attacker needs access to the device and convince it to sign for every output he wants to steal (assuming the HSM prevents leaking private keys). With Graftroot, the HSM may be tricked into signing a script that does not include itself.

To date, the situation has not been resolved, but various solutions have been presented. Some include embedding bits that flag Graftroot as enabled or disabled and others include restructuring the signature equation that contains Graftroot.

Discussion