BIP-341：是否應該完全避免僅使用鍵路徑的 P2TR？
考慮BIP-341 “建構和花費 Taproot 輸出”，它說
如果支出條件不需要腳本路徑，則輸出鍵應送出到不可支出的腳本路徑，而不是沒有腳本路徑。
還有這裡的答案，邁克爾·福克森進一步解釋了它，然後：
這是否僅適用於比簡單的單個密鑰更複雜的密鑰路徑花費 - 例如，僅適用於“taproot 輸出密鑰是密鑰聚合”的情況？還是建議完全避免僅包含關鍵路徑支出的輸出？
PS這個答案說“……通常很重要的是能夠證明您選擇的內部公鑰是一個帶有未知私鑰的點……似乎與但我不太確定。 ..
讓我們首先介紹一些術語，因為“僅關鍵路徑”可能意味著不同的東西。說：
原始主根輸出是輸出密鑰（ 中的那個）與錢包的公鑰P
scriptPubKey完全相等的輸出。noscript主根輸出是輸出密鑰為P + hash TapTweak (P)⋅G的輸出，其中P是錢包密鑰（也稱為內部公鑰）。
樹的主根輸出是輸出鍵為P + hash TapTweak (P || m)⋅G的輸出，其中m是已知 Merkle 樹的 Merkle 根。
- OP_FALSE主根輸出是樹主根輸出，其中m = hash TapLeaf (0xc0 || Script(OP_FALSE)) *，*即其腳本樹僅由 OP_FALSE 腳本組成的主根輸出。
（我並不是要把這些作為籠統的術語來介紹，因為我覺得它們太容易掉了，它們只是我將在這個答案中使用的術語）。
上述所有 4 項都可以使用密鑰路徑，因為計算輸出的一方，如果他們知道P的私鑰，也可以計算輸出密鑰的私鑰。Raw、noscript和OP_FALSE主根輸出不能使用任何腳本路徑。對於noscript和OP_FALSE輸出，還可以通過顯示P向第三方證明所述輸出不能使用腳本路徑使用。
如果支出條件不需要腳本路徑，則輸出鍵應送出到不可支出的腳本路徑，而不是沒有腳本路徑。
BIP341 中的此文本建議在不需要腳本路徑成本時始終使用noscript taproot 輸出。
這是否僅適用於比簡單的單個密鑰更複雜的密鑰路徑支出 - 例如，僅在“taproot 輸出密鑰是密鑰的聚合”的情況下？還是建議完全避免僅包含關鍵路徑支出的輸出？
它始終適用於不需要腳本路徑成本的任何場景。但原因不同：
- 在某些情況下，這實際上是一個安全問題。正如 BIP 的腳註 23中所述，當天真地使用 MSDL-pop 密鑰聚合算法時，惡意的共同簽名者可能能夠潛入腳本路徑，而其他共同簽名者則無法。有很多方法可以減輕這種風險，但在沒有腳本路徑的情況下顯式執行 BIP341 密鑰調整（因此使用noscript或OP_FALSE機制）是一種顯而易見的方法。在這種情況下，使用raw實際上可能是不安全的。
- 在某些情況下，可能只是希望能夠證明不存在腳本路徑，即使不存在來自前一個要點的風險（例如，輸出僅由單方建構，或者使用了 MuSig）。所以在這種情況下，使用raw不會不安全，但它不允許證明它不是。noscript和OP_FALSE都是可證明的（只需向第三方透露P加上選擇了哪種機制，他們可以重新計算輸出）。
- 如果只存在一個參與者，或者使用 MuSig，或者採取了其他一些預防措施，並且不需要證明缺少第三方的腳本路徑，則沒有嚴格的理由不使用raw。然而，以標準化計算輸出鍵的單一方法為目標仍然是有用的，以便最大限度地減少實現/測試的組合數量，以及避免需要準確傳達應該在哪些場景中使用哪個組合。BIP341 因此選擇了一種方法，即noscript。它也可以選擇OP_FALSE，但我個人認為將“無腳本”與“1 個或多個腳本”嚴格分開會更乾淨一些（即使後者只是一個不可用的腳本）。
也就是說，BIP341 中的這段文字只是一個建議，選擇raw可能是有原因的：
- 您真的很關心性能，而執行關鍵調整的成本太大了。例如，在計算虛地址時，可能需要放棄調整（無論是否鼓勵案例都留在中間……）。
- 您使用的密鑰聚合算法在簽名時無法處理調整（例如，您使用的是不支持 BIP341 調整的 FROST 簽名庫）。這確實意味著您需要了解與潛入腳本路徑的各方相關的風險，這可能意味著說服自己這種可能性對您的案例無害，或者採取其他加密預防措施（例如與如何生成參與者密鑰有關）來避免他們。
PS這個答案說“……通常很重要的是能夠證明您選擇的內部公鑰是一個帶有未知私鑰的點……似乎與但我不太確定。 ..
這是相反的情況，人們想要一個只能通過腳本路徑花費的主根輸出，並且可能希望能夠證明這一點。