Pieter Wuille argued that Graftroot delegation is not strictly less powerful than using a normal transaction because it enables delegation in a way that cannot be fixed in the chain. However, there may be practical implications to consider. The conversation also explored the similarities between Graftroot and SIGHASH_NOINPUT, and proposed making Graftroot spending a special sighash flag. It was suggested that the actual signature should still be different to avoid malleability issues.The concept of Graftroot signatures was brought up in a recent Bitcoin development discussion. These signatures commit to a single outpoint, making it impossible for them to be used to spend all outpoints that pay to the same public key. However, if a graftroot signature cannot be made independent of the outpoint, it greatly reduces its functionality. The main benefits of grafts are the ability to delegate before coins exist and making the transfer atomic compared to pre-signing a transaction.Pieter Wuille and Tim Ruffing discussed the design of the Graftroot signature. It was pointed out that the safety of the construction does not solely depend on consensus rules but also on how it is used. The discussion also touched on the compatibility of Graftroot with certain use cases and potential interference with applications adopting such outputs.Johnson Lau and Pieter Wuille had a debate about the safety of the Graftroot design. While Johnson Lau argued that if the design is dangerous, then the existing signature checking rules must be equally dangerous, Pieter Wuille emphasized that the safety of a construction depends on more than just consensus rules. He mentioned that having the option of Graftroot being non-optional is not required, as signers can use other methods.Pieter Wuille expressed concerns about the deployment of Taproot and Graftroot in an email to the Bitcoin developers' mailing list. He suggested that a practical deployment may require explicit enablement or disablement of the Graftroot spending path. Various approaches were listed to address this issue, but they were considered less efficient or private compared to allowing Graftroot spends directly. The compatibility of Graftroot with certain use cases and potential interference with applications adopting such outputs was also emphasized.In a separate discussion, the topic of accountability for funds held in a P2SH address was raised. The concern was that collusion among parties involved in signing a transaction could undermine the original purpose of the fund. The possibility of using Graftroot to pay funds to a public key without constraint was mentioned. It was agreed that it should be possible to send funds constrained by a script without a public key ever existing.The need for an explicit enable or disable feature for the Graftroot spending path in Taproot and Graftroot deployment was discussed. Suggestions included including a flag to choose in advance whether the script will be static or "editable" and including proof-requiring committed transactions to prevent unauthorized withdrawals. Concerns were raised about potential problems if Taproot and Graftroot were used to withdraw funds without showing in the published script. The importance of being able to prove that a transaction isn't using Taproot and Graftroot was highlighted.Andrew Poelstra raised concerns about Graftroot potentially breaking blind signature schemes but later explained a way to maintain unique keys for every output while retaining the same private key. A scheme for blind signatures was proposed but noted its vulnerability to Wagner's attack. Key-prefixing was suggested to enhance security by making the messagehash unique per-utxo and committed in the chain.ZmnSCPxj proposed modifying the Taproot equation to make Graftroot optional and combining Taproot and Graftroot. This would involve using a one-level Merkle tree where one branch enables or disables Graftroot and the other branch represents an ordinary script. Concerns were raised about signing arbitrary messages and ensuring that the simple-signing case does not become a vulnerability for wallets.The discussions surrounding Taproot and Graftroot have prompted questions about the need for explicit enablement or disablement of the Graftroot spending path in practical deployments. The safety of always permitting both types of script spending paths is being debated, as accidental signing of a script could have broader consequences without Graftroot. In a multisignature setting, the presence of Graftroot could allow a subset of participants to remove others from the set of signers. The discussions highlight the importance of considering potential reasons why certain applications may not adopt these outputs.