BIP-Taproot (BIP 341) 提案中有哪些不同的可升級特性？
BIP-Taproot (BIP 341)提案中有哪些不同的可升級特性？
為什麼有這麼多可升級路徑？有沒有附件可以做而葉子版本不能做的事情？
James Prestwich 在Twitter 上提出了這個問題。
有附件、葉子版本、ext_flag、OP_SUCCESS、未知的 pubkey 類型，您可能也可以包括現有的見證版本。我相信這份清單是詳盡無遺的。
ext_flag 本身並不是一個擴展機制。更多的結構允許安全地重用 sighashing 程式碼（而不是需要一個新的標籤或其他機制來避免碰撞）。
- 葉版本：用於修改腳本語義
- OP_SUCCESSx：用於新的操作碼，不協調新版本
- 公鑰類型：用於新的 sighash 標誌/加密，而不需要大量新的操作碼
- 附件：用於有效添加新欄位，如 nLockTime
葉子版本的添加實際上只是因為我們在控制塊中有一些空閒的位，並且保留它們似乎很浪費。我認為它們主要是一種便利，因為 OP_SUCCESSx 可以實現相同的效果（添加 OP_V2 等）。
由於 scriptPubKey 不承諾附件，因此它更像是一種擴展見證可能性的方式，而不是直接添加新語義的方式。
那麼有沒有附件可以做而新的葉子版本不能做的事情呢？我認為它們是正交的。
例如，您可以限制 tx 僅在包含某個塊雜湊的鏈中有效的功能。它不能用葉子版本來完成，因為它是一個簽名時間的事情。我相信附件不能用來引入新的腳本條件。一個新的葉子版本可以引入它自己的類似附件的東西，但這不能適用於舊的葉子版本。
附件的激勵範例是這樣的。想像一下添加了一個新的操作碼，它需要很少的字節但 CPU 成本很高。您需要每個此類操作碼的高權重預算，但這可能需要實際向見證人填充虛擬數據以獲得必要的預算。相反，如果輸入上只有一個標記說“將表觀權重（和相應的操作預算）增加 N”，而不佔用 N 個字節，那就太好了。從邏輯上講，如果只有在已用輸出可用時才能解析該標記，那將很煩人。附件在沒有上下文的情況下也可以辨識，主要是利用關於哪些見證人對 v0 有效的巧合（最後一個見證人堆棧項的第一個字節只能採用某些字節值）。我認為，這不能用新的葉子版本來完成。
Pieter Wuille 在Twitter 上回答了這個問題。