Taproot 在接下來的 2 週內啟動。什麼可能出錯，可以做些什麼來降低這些不良情況的發生機率？
根據taproot.watch，在撰寫本文時（2021 年 11 月 4 日），Taproot 在大約 10 天（塊 709632）內啟動。在壞情況或最壞情況下會出現什麼問題？在這個後期階段，礦工或使用者可以做些什麼來降低這些事情發生的可能性，或者只是在發生這些事情之一的情況下保護自己？
以前的軟分叉啟動在過去發生了哪些糟糕的情況？
在啟動時（或啟動後的塊中）我們應該注意什麼來檢查啟動是否順利？
不引起關注的場景
場景：有效或無效的 Taproot 支出在啟動之前將其變為已開採區塊（區塊 709632）。它只是被視為任何人都可以消費，因為網路上沒有人在執行 Taproot 規則，直到塊 709632。這已經發生了（由 0xB10C 執行）。
糟糕的情況（不太可能發生）
場景：大多數礦工（儘管之前幾個月前表示準備就緒）沒有升級到在啟動時強制執行 Taproot 規則的完整節點版本。無效的 Taproot 花費會在啟動後將其變為已開采的區塊，並在重新組織時創建大型重組。
監控：可能不清楚執行的是什麼全節點版本的礦池。但是，如果他們在啟動後探勘的區塊中包含有效的 Taproot 支出（沒有無效的 Taproot 支出），這表明他們正在正確執行 Taproot 規則。
場景：第二層協議由於 Taproot 升級遇到不可預見的問題，需要修復。Laolu Osuntokun 最近在比特幣開發郵件列表的測試網上討論了一個與 Neutrino 輕客戶端協議相關的 Taproot問題。
監控：這真的取決於監控什麼的問題，但任何問題都可能在比特幣開發和閃電開發郵件列表中討論。
最壞的情況（極不可能發生）
在 Taproot 實現程式碼中發現了一個錯誤，我們需要一個硬分叉來修復錯誤或逆轉軟分叉更改。
以前的軟分叉啟動在過去發生了哪些糟糕的情況？
Bitcoin Optech 在這裡回顧了軟分叉啟動的歷史。已經有許多緊急啟動共識更改以解決錯誤，儘管這些不是像 Taproot 這樣的預先計劃的軟分叉。當然，儘管 SegWit 軟分叉最終在 2017 年順利啟動，但啟動之前的幾個月並不順利（您可以在Jonathan Bier的The Blocksize War 中了解 SegWit 啟動之前的幾個月）。唯一在啟動時遇到問題的預先計劃的軟分叉啟動是 2015 年的 BIP 66 軟分叉。正如 Optech 所述：
在區塊高度 359,753 處達到了 75% 的門檻值。2015 年 7 月 4 日，在第 363,725 個區塊達到 95% 的門檻值，所有執行比特幣核心版本 0.10.0 或更高版本（或兼容實施）的節點開始執行新規則。然而，在區塊高度 363,731 處，未升級的礦工生成的區塊不包含正確的區塊版本，因此在新的 ISM 啟動規則下無效。其他礦工建立在這個無效區塊之上，最終產生了一個包含六個無效區塊的鏈。這意味著未升級的節點和許多輕量級客戶端將第一個無效區塊中的 96 筆交易視為有 6 次確認，即使當時它們在有效區塊中甚至沒有被確認一次。最終，開發人員能夠聯繫礦池運營商並讓他們手動重置他們的軟體以返回有效鏈。第二天發生了第二起此類事件，為交易提供了三個虛假確認。令人高興的是，來自 6 塊和 3 塊無效鏈的所有正常交易後來都在有效塊中得到確認，這意味著沒有普通使用者賠錢。