隔離見證將輸入金額包含在 SignatureHash 中。這可以防止哪些可能的攻擊？
遺留交易僅包含 中的交易成分
SignatureHash，但 segwit 交易還添加了 中的輸入量SignatureHash。隔離見證簽名將每個輸入引用的值（數量）包含在簽名的雜湊中。以前，離線簽名設備（例如硬體錢包）必須在簽署交易之前驗證每個輸入的數量。這通常是通過流式傳輸有關作為輸入引用的先前交易的大量數據來實現的。由於金額現在是已簽名的承諾雜湊的一部分，因此離線設備不需要以前的交易。如果金額不匹配（被受損的線上系統歪曲），簽名將無效。
引用該段：
如果金額不匹配
多少金額？在什麼情況下？
我在這裡不明白的是，交易無論如何都沒有輸入金額。它僅在隔離見證後進行散列。但是，如果它是散列的，那不會在交易驗證中增加任何價值，因為之前的輸出是在之前的交易中籤名的，我們要麼擁有之前交易的價值來檢查沒有發生“印鈔”，要麼我們沒有。無論如何，它都不能以明文形式添加到驗證中。
如果輸入中的數量不是 的一部分，可能會發生哪些攻擊或瓶頸
SignatureHash？有人可以詳細解釋這個場景，因為我看不到全貌。
考慮一個有 2 個輸入和 1 個輸出的交易。假設輸入都是 1 BTC，輸出是 1.5 BTC。這意味著該交易需要支付 0.5 BTC 的費用，這很荒謬。
考慮一個不知道區塊鏈狀態的硬體簽名者，但它仍然需要知道這些輸入值才能在簽署交易之前向使用者顯示。讓我們假設硬體簽名者有一個更有效的協議，其中主機提供交易以及正在花費的 UTXO（腳本和金額）。
如果主機是誠實的，它將提供正確金額的交易和花費的 UTXO。使用者會看到他們花費了 2 BTC 並丟棄了 0.5 BTC 作為費用，因此他們會拒絕交易。
但是如果主機是惡意的呢？假設主機正確地提供了 1 個 UTXO，但第二個 UTXO 的數量錯誤 - 1.59999 BTC 而不是 2 BTC。現在，當硬體簽名者向使用者顯示他們正在發送 1.5 BTC 時，費用為 0.000001。這將是一個合理的交易，因此使用者批准交易並將其簽署並發送。但他們實際簽署的是一筆交易，交易費用為 0.5 BTC。
對於非隔離見證腳本，上述情況是可能的，因此為了防止這種情況，硬體簽名者要求非隔離見證輸入提供整個先前的交易，以便可以計算交易 id 並將其與給定的交易 id 進行比較消費交易。這保證了金額是正確的，就好像它不是，交易ID會不同。但這可能是大量數據，因此效率不高。
但是，使用隔離見證，給定輸入的金額已簽名，因此無需提供完整的先前交易。在惡意情況下，使用者接受交易並且硬體簽名者對其進行簽名。然而，當它簽署它時，它會送出輸入的數量，因此它會送出錯誤的輸入數量 1.59999 而不是 2。當這個交易被廣播時，節點將驗證簽名並發現它是無效的，因為它們將使用正確的輸入量 2。因此 segwit 可以防止這種攻擊起作用。
…除了不完全。部署隔離見證後，我們發現有一種方法可以繞過它。假設惡意主機能夠說服使用者兩次簽署同一個交易——也許在第一次聲稱有錯誤並且使用者需要再試一次之後。
在這種情況下，主機可以為第一次簽名嘗試提供第一個輸入的正確金額和第二個輸入的不正確金額。這將為第一個輸入生成一個有效的簽名，而為第二個輸入生成一個無效的簽名。然後它提示使用者再次簽名，這次它為第一次輸入提供了不正確的金額，為第二次輸入提供了正確的金額。現在惡意主機對第二個輸入也有一個有效的簽名。它可以結合這兩個簽名並產生一個有效的交易，交易費用為 0.5 BTC。
在這種新的攻擊場景下，一些硬體供應商決定在簽署隔離見證輸入時要求整個先前的交易，就像他們對傳統輸入所做的那樣。
但是 Taproot 解決了第二個問題的解決方案。解決方案是承諾所有花費的 UTXO 的金額。不僅僅是簽名將在 scriptSig 中的特定 UTXO 的數量，所有其他 UTXO 的數量都將包含在簽名中。這意味著更改一個金額將導致交易中的所有簽名無效，因此這種新的攻擊無法奏效。只是為了更好地衡量，Taproot 還承諾所有 UTXO 的所有腳本。