要想完全理解比特幣開發現狀背後的原因，就不能不瞭解一些歷史事件。本文著重列舉了中本聰離開這個專案前後的歷史事件、軟體釋出和漏洞修復；還額外新增了一個章節敘述比特幣開發的現狀。文章後附的時間線為每一個事件提供了額外的細節。
對於這裡的大部分事件，我都不是親歷者。所以這份時間線的一大部分引自 John Newbery 的一次名為 「比特幣開發的歷史與哲學」 的演講。本文的標題也寫得很清楚了，本文沒有，也做不到包含每一個重要事件。歷史總在不斷變化，如果你認為我遺漏了什麼事件，或想提議我作一些修改，請在開源專案 bitcoin-development-history 中提交一個 issue，這也是我用來附加更多時間線的辦法。
中本聰仍在的時候
這份時間線的起點是 2007 年早期。中本聰開始開發比特幣。這個點對點的電子現金系統沒有受信任的地方。整個系統完全由使用者執行的軟體來控制。
早期，有貢獻者加入了中本聰的工作。除了軟體的開發，這些新來的貢獻者還為軟體新增了 Linux 和 maxOS 作業系統的支援。到了 2010 年夏天，中本聰給軟體做了一些關鍵的修改。比如，引入了 「檢查點」 作為一項安全措施，來對抗傳播低難度鏈的攻擊。使用了這些檢查點的節點會拒絕那些特定高度與特定區塊不符的鏈。檢查點是由中本聰獨自硬編碼的，理論上來說，這讓中本聰可以自己決定整個網路要跟隨哪條鏈。
加入檢查點的幾天後，中本聰在版本 v0.3.3 的軟體中放出了第一個共識機制變更。中本聰敦促使用者升級。在接下來一個月裡，多個小版本更新陸續放出。其中一個修復了一個致命的溢位漏洞。這個漏洞被利用來創造了兩個高價值的 UTXO。中本聰建議礦工們重組包含了惡意交易的區塊。
一週以後，中本聰加入了一個警報系統，來提醒節點運營者網路中出現的類似 bug 和問題。這個警報系統有一個安全模式。這個安全模式一旦觸發，就會禁用整個網路的所有關於貨幣處理的 RPC 方法。只有中本聰能夠用一個私鑰簽名來建立有效的網路警報。一些使用者開始提出質疑：如果其他人，比如某個政府，拿到了這個私鑰，那網路會變成什麼樣呢？
這個時候，中本聰對比特幣網路有太大的權力。但大家主要擔心的不是中本聰會變壞、會摧毀整個網路，而是一個去中心化的網路中不應該存在一個單點故障。
到了 2010 年 10 月，中本聰在 Bitcointalk 論壇上釋出了他的最後一個帖子，宣佈移除這個安全模式。中本聰在他最後留下的電子郵件之一里面寫道：「我準備到別的地方去了。有了 Gavin 和大家，這個專案會得到很好的維護。」 一些人主張，中本聰離開比特幣世界，是他最偉大的貢獻之一。
中本聰離開之後
幾乎同一時間，整個開發流程從 SVN 轉移到了 GitHub 上。BlueMatt、sipa、laanwj 和 gmaxwell 加入了這個專案。在 2011 年中，BIP （比特幣升級提議）流程應運而生。在 2011 年的最後一個季度和 2012 年的第一個月，社羣討論了允許交易的接收者指定花費條件的多個提案。由此，P2SH 交易引入了比特幣。
在 2012 年末，比特幣基金會宣告成立。比特幣基金會（Bitcoin Foundation）模仿的是 Linux 基金會。在公告帖子下面，一些人留言表示擔心開發會變得中心化。
Bitcoin v0.8.0 在 2013 年春天釋出。兩週以後，一場意料之外的硬分叉在網路中升級了和沒升級的節點間爆發。硬分叉很快就被解決了，礦工們都把挖礦算力切換到了對已升級和未升級節點都有效的鏈上。
在 2013 年末，Bitcoin 軟體更名為 Bitcoin Core。在接下來幾年裡，包括 Chaincode 和 Blockstream 在內的公司成立。後來，MIT Digital Currency Initiative 加入了 Chaincode 和 Blockstream，為開發比特幣的開發者和研究者提供報酬。在 2015 年二月，Joseph Poon 和 Tadgw Dryja 放出了閃電網路白皮書的第一份草稿。
第二年，Luke Dashjr 通過 BIP 2 修訂了 BIP 流程；Bitcoin Core 放出了 v0.13.0，加入了 SegWit 作為軟分叉。在 2016 年 11 月，警報系統完全棄用。到了 2017 年 8 月，SegWit 在比特幣網路上啟用。2019 年，又一家公司 Square Crypto 開始資助比特幣開發。在 2019 年 5 月，Pieter Wuille 提出了 BIP Taproot。
比特幣開發的現狀
在過去幾年中，比特幣的開發文化日益去中心化、目標明確而且嚴格。現在 Bitcoin Core 程式碼庫有 6 名維護者，分佈在三個國家。只有他們能夠合併由貢獻者提出的程式碼更改。不過，在內容合併之前，更改的內容還需經過一個審議流程，這個流程也變得嚴格得多。
舉個例子，在比特幣早期，有個與 P2SH 相競爭的提議，叫做 「OP _ EVAL」。有個實現了 OP _ EVAL 的 pull request （「合併請求」）在 2011 年底被合併到了程式碼庫中。即便是這樣對共識有重大變更的程式碼，它也只有一個稽覈人。Russell O’Connor 開了一個 issue 批評了這個實現的一部分，並主張這麼大的、對共識極為關鍵的變更應該得到更多的稽覈和測試。
這件事推動了如何通過更多的測試和稽覈來實現更高質量的程式碼的持續討論。到了今天，每一個合併請求都有多個開發者來稽覈。如果某個改變觸及到了對安全性甚至共識的關鍵部分，稽覈的流程還需要通過更多的稽覈員稽覈，需要大量的測試，通常會花費幾個月的時間。活躍的 Bitcoin Core 貢獻者 John Newbery 告訴我，「只需一個稽覈人員首肯就能合併影響共識的程式碼的事情，已經一去不復返」。
人們也投入了很多精力到自動化的測試中，比如，有 C++ 語言編寫的單元測試和 Python 語言編寫的功能性測試。每一個不簡單的變更都要相應更新現有的測試或者在框架中加入新的測試。在單元測試和功能測試以外，還要在 Bitcoin Core 上做模糊測試，以及建立基準測試框架來度量程式碼的效能。舉個例子，bitcoinperf.com 網路提供了 Grafana 和 codespeed 介面來視覺化週期性的基準測試的結果。
多年努力下來，Bitcoin Core 軟體已經形成了一個清晰的釋出流程。Bitcoin Core 的大版本每 6 個月釋出一次。發行計劃包括一個翻譯流程，一個特性凍結流程，還通常有多個候選版本。近期 Cory Fields 和 Carl Dong 還致力於提高 Bitcoin Core 構建過程的安全性，使用確定性和可引導的構建包。這個新的構建系統可能還沒準備好支援即將在今年秋天釋出的 Bitcoin Core v0.19.0，但未來可以提供更好的構建過程安全性。
結論
十年間，比特幣的開發文化滄海桑田，從圍繞中本聰的高度中心化，變為圍繞幾千名 GitHub 貢獻者（2018 年資料）的去中心化。顯然，程式碼稽覈、程式碼質量和安全性的高標準都是有必要的。這些標準得到了遵循和持之以恆的提高。
我認為，要完全理解比特幣開發現狀背後的哲學，瞭解這些歷史事件是必不可少的。所以我做了一個把更多事件串起來的時間線。
若有進一步的研究需求，建議閱讀 Alex B. 寫的《The Tao Of Bitcoin Development （比特幣開發之道）》、Eric Lombrozo 寫的《The Bitcoin Core Merge Process （Bitcoin Core 程式碼合併流程）》以及 Jameson Lopp 的大作《Who Controls Bitcoin Core？（誰控制著 Bitcoin Core？）》。
致謝
感謝 John Newbery 幫助我梳理並稽覈這篇文章。他在自己的演講《History and Philosophy of Bitcoin Development （比特幣開發的歷史和哲學）》中做了很多歷史考證工作，該演講也是我這篇文章的基礎。此外，我非常感激 Chaincode Labs，他邀請我參加他們的 2019 夏令營（Summer Residency），在那裡我遇見了很多有意思的人，學到了很多東西，也正是在那裡，我開始著手整理時間線和撰寫這篇文章。
