Taproot是一個旨在提高比特幣隱私性及靈活性的擬議協議升級，目前該方案正處於開發的後期階段，Bitcoin Core的貢獻者一致認為，Taproot升級將使得比特幣受益，截至目前，該方案似乎也受到了更廣泛的比特幣生態的歡迎。因此，Taproot很可能會被納入Bitcoin Core協議，而其它比特幣提議也可能會隨之推出。
但仍有一個問題：比特幣網路應該如何進行升級？Taproot是共識協議層的一個改變，這意味著比特幣節點必須以某種方式從舊規則切換到新規則，並且要避免網路的分裂。由於各種原因，這在過去被認為是一個挑戰。
目前，比特幣開發者們正在考慮改進啟用協議升級的策略。
以前的軟分叉和BIP 9
好訊息是Taproot的實施會是一次軟分叉。這種型別的升級增加或收緊了規則，而硬分叉則是刪除或放鬆規則。新增或收緊規則的好處是，升級節點認為有效的任何內容，在非升級節點看來也會是有效的。（如果舊節點同時接受交易型別A和B，但新規則只允許交易型別A，則舊節點將在執行新規則的網路上保持相容。）
比特幣最早的軟分叉是透過截止日（flag days）機制啟用的。開發者（特別是中本聰）在一個新的比特幣軟體客戶端的程式碼中嵌入了一個未來日期，指定了升級後的節點將執行新規則的時間點。礦工和使用者被鼓勵在此日期之前升級，以避免網路分裂。（注：在那些日子裡，礦工和使用者往往是重合的，這與今天是不同的）
由於未升級的節點仍然與新規則相容，因此軟分叉的一個好處是，如果大部分算力強制升級，整個比特幣網路會就其區塊鏈版本達成共識。這也意味著，在實施新的協議規則時，不需要立即升級所有節點，從而允許使用者具有一定的靈活性。
自2012年左右以來，軟分叉已越來越多地利用算力作為協調機制，以協調向新規則的轉換。透過在區塊中嵌入一些資料，礦工可以向其它礦工和網路的其餘部分發出訊號，告知他們已升級軟體的資訊，從而準備好實施新的規則。一旦有足夠的算力訊號支援，所有升級的節點都會被觸發以執行新規則。
經過幾次升級，這一戰略演變成BIP 9（比特幣改進提議）。例如，BIP 9就是用來啟用比特幣上一次隔離見證（SegWit）軟分叉升級的機制。礦工們有一年的時間來啟動升級，要求在任何難度區間內95%的區塊都包含就緒訊號位。如果一年後沒有發生這種情況，啟用期就會過期，升級就會失敗。（當然，可以簡單地再試一次）
然而，對於隔離見證（SegWit）來說，BIP 9的執行並不順利。與以前的某些升級一樣，有些礦工可能由於漠不關心而在一段時間內沒有進行升級（通常沒有太大的動力促使礦工快速升級）。但一個更大的問題是，一些礦工已開始將訊號傳遞過程理解為一種對升級的投票，他們不會發出準備就緒的訊號，而是就是否支援表示投票意見。更糟糕的是，一些礦工最終利用這一“投票權”阻止升級，以試圖在比特幣開發過程中獲得政治影響力，或者他們可“投票”反對升級，以暗中獲益。
經過長時間的激烈爭吵，隔離見證（SegWit）最終確實激活了，但只有在其他比特幣客戶端包含新的啟用方案之後。一些使用者執行的BIP 148客戶端中包含的BIP 148，被程式設計為僅接受截止日（flag day）後支援協議升級的區塊。同時，btc1客戶端中包含的BIP 91，有效地將算力要求從95%降低到75%。面對潛在的網路分裂和可能的收入損失情況，一直在阻撓的礦工們讓步了。
但對於大多數Bitcoin Core開發者來說，BIP 9已暴露出它是一個次優的解決方案，因此，開發者們已開始考慮替代方案。
BIP 8
BIP 8是BIP 9的早期替代方案，它是由BIP 148的作者Shainfry和Bitcoin Knots，以及Bitcoin Core貢獻者Luke-jr提出的，它最初與BIP 9相似，但關鍵的區別在於：一年後若算力支援不足，升級並不會因此失敗，它會做完全相反的事情，即在那個時間點啟用軟分叉。與截止日（flag day）類似，所有升級的節點將從那時起開始實施新規則。而那些仍未能升級的礦工，其挖取的區塊，將冒著被升級的礦工和使用者拒絕的風險。
BIP9背後的主要思想是，假設使用者進行了升級，礦工們就無法阻止軟分叉，因此無法利用這種投票權來謀取利益。他們可以加快啟用速度並幫助協調順利的協議升級，但是即使他們自己不啟用升級，升級也最終會發生。
BIP 8的最新草案，包含了一些顯著的變化。首先，當訊號期即將到期時，BIP 8允許為節點配置兩種不同的策略：如前兩段所述，強制啟用，或者像BIP 9一樣不強制啟用。此外，節點（如果這樣配置的話）實際上並沒有啟用升級本身，而是為升級發出訊號。而不表示支援升級的區塊，將被拒絕。這兩個變化的結合有一個有趣的特性，即如果比特幣算力的大部分都被迫發出訊號支援升級，即使沒有配置為強制執行訊號的BIP 8節點也將隨升級一起進行。
反對BIP 8及其強制訊號（或自動啟用）的一個論點是，它可能會有風險，尤其是在較短的時間內。如果算力佔多數，且至少有部分使用者不升級，則該方案會造成升級節點網路和未升級節點網路分裂。假設大多數使用者支援升級，這可能最終會有利於網路的升級部分。但在此期間，未升級的使用者將面臨資金損失的風險，而未升級的礦工將浪費掉算力，從而有損比特幣的安全性。
最好的辦法是提供足夠的時間進行升級。不幸的是，每個人對時間的長度看法是不同的，一些人認為強制訊號可能在一年內開始，另一些人則認為需要幾年時間。
BIP 8存在的另一個複雜問題是，設定強制訊號的預設值。如果在預設情況下關閉強制訊號，使用者可能會發現自己不協調，從而增加網路分裂的風險。另一方面，如果在Bitcoin Core客戶端中，強制訊號被選為預設設定，則歷史上廣泛採用的Bitcoin Core實際上就保證了升級將會發生。一些人認為，這會使Bitcoin Core開發者對比特幣的協議規則產生太大的影響。出於這個原因，BIP 8的合著者Luke-jr傾向於透過特殊的客戶端專門部署帶有強制訊號的BIP 8，類似於BIP 148客戶端。
另一些人則認為，Bitcoin Core開發者始終會根據自己的最佳判斷髮布軟體，同時牢記使用者需求並避免有爭議的升級，設定BIP 8預設值也不例外。如果有人不同意Bitcoin Core開發人員的最終選擇，他們可選擇不升級到新版本，甚至分叉Bitcoin Core程式碼，以推出競爭版客戶端。
現代軟分叉啟用
雖然Bitcoin Core開發者確實會考慮使用者需求，並嘗試避免有爭議的升級，但並不是所有人都相信這是可能的。也許在這次釋出之後，會出現全新的問題。或者，Bitcoin Core開發者可能遺漏了一些東西。
這就是為什麼Bitcoin Core貢獻者Matt Corallo提出了一項被稱為“現代軟分叉啟用”策略的原因。現代軟分叉啟用包括三個步驟，它基本上實現了BIP 9（或沒有強制訊號的BIP 8）和帶有截止日啟用的BIP 8的組合（儘管強制訊號可能是一種選擇）。
作為第一步，BIP 9將允許礦工透過算力啟用軟分叉。如果礦工們在一年內沒有啟用它，第一個啟用視窗就會過期。然後，作為第二步，開發者們需要一些時間來分析啟用失敗的原因，如果他們確實發現了問題，就重新考慮這個提議。但是，如果他們發現方案沒有問題，則第三步是重新部署軟分叉，這一次使用BIP8和flag day啟用：礦工們有另一次機會用算力啟用方案，但如果他們再次失敗，軟分叉將在第二個訊號週期結束時啟用。（Bitcoin Core貢獻者AJ Towns表示，在第二個訊號週期內，算力啟用閾值也可能隨著時間的推移逐漸降低）
Corallo相信，如果提議沒有錯的話，這種方案將提供BIP9的好處，而不會帶來負面影響。如果礦工願意，他們可以協調一次平穩的升級，並且沒有強制啟用，如果啟用最初失敗，開發者可以花時間重新考慮提議。同時，由於沒有充分的理由，礦工從阻止升級中獲得的收益要少得多，因為眾所周知，升級最終仍將繼續進行。
反對現代軟叉啟用的主要論點是，如果沒有礦工的合作，這個過程將花費相對較長的時間，有些人認為BIP 9步驟完全是在浪費時間。Corallo最初的提議，包含1年的BIP 9訊號，以及隨後6個月的重新考慮期，最後是在自動啟用前2年的BIP 8訊號期，也就是說，總共有3年半的時間。雖然這個時間表尚未確定，但將不同步驟縮短太多，會減少重新考慮或升級的時間（即會增加網路分裂的風險）。
由於距離潛在的強制啟用還有很長時間，一些人認為，礦工終究可以嘗試獲得一些政治權力，他們可以將升級推遲數年的時間。
BIP 8 + BIP 91
另一個最近被提出來的建議，也許最好被描述為BIP 8和現代軟分叉啟用的一個組合，至少在精神上是這樣的。這項不具名的提議，將部署一個很長的BIP 8訊號週期，可能與現代軟分叉啟用的三年半時間一樣長，之後強制觸發訊號。然而，如果一年後升級還沒有啟動，開發者將需要一些時間重新考慮這個提議，就像他們使用現代軟分叉啟用一樣。
如果開發者發現該提案沒有問題，並斷定該提案只是由於礦工的漠不關心或其他無效原因而沒有啟用，則他們可以選擇部署隔離見證（SegWit）啟用期間使用的BIP 91風格的新軟分叉。這將有效地降低啟用的算力閾值，從而可能加快過程。
另一方面，如果開發人員最終發現提案是有問題的，他們可以部署一個新的軟分叉來解決問題，甚至完全撤銷原來的軟分叉（這裡是指Taproot）。假設現代軟分叉啟用在強制訊號發出之前有三年半的時間線，那麼應該有足夠的時間來處理這個問題。
反對這一提議的主要論點可能是，部署軟分叉（如果需要）來撤消另一次軟分叉是有爭議的。更具體地說，它要求礦工和使用者在截止日期之前升級到新版本，否則就有分裂網路的風險。
Sporks
最後，Bitcoin Core貢獻者Jeremy Rubin提出，他發明了一個名為機率比特幣軟分叉（或稱“Sporks”）的概念，這可能比典型的算力強制軟分叉更具激勵相容性。
Rubin認為，BIP 9 的核心問題在於，礦工可以在不付出代價的情況下推遲升級，這可能會給他們帶來政治權力。
而在Sporks方案中，就緒訊號不再是來自礦工在其開採的區塊中包含的一點資料，而是來自區塊頭雜湊：它們透過投入時間和資源而隨機生成的工作量證明。升級後的節點會同意，有效區塊頭算力的一小部分（統計上每六個月左右才能找到一次）將觸發升級。
根據雜湊的隨機性，礦工將無法控制他是生成常規區塊頭雜湊，還是升級啟用區塊頭雜湊。從統計意義上講，他只是偶爾生成一個區塊頭雜湊。所以，如果他投入的資源碰巧生成了一個升級啟用區塊頭雜湊，那麼他有兩個選擇。要麼將其釋出到比特幣網路，獲得區塊獎勵，並激活軟分叉。或者，在我們的示例中，由於不釋出而將軟分叉平均延遲了大約六個月……但這樣做也意味著礦工放棄了區塊獎勵，也就是說，推遲升級將付出巨大的代價。
目前，Sporks的主要問題，可能在於它是一個相對較新的想法，尚未有可用的程式碼，更不用說測試了。儘管有些人確實認為這一概念很有趣，但它並不是啟用Taproot的有力競爭者。