精通比特幣：程式設計開放區塊鏈（第三版）

我（Andreas）第一次接觸比特幣是在 2011 年中。我的第一反應基本上是「切！宅宅的錢！」然後我忽略了它六個月，未能理解它的重要性。這是我在許多我認識的最聰明的人身上看到的反應，這讓我感到一些安慰。第二次我在一個郵件列表的討論中遇到比特幣時，我決定閱讀中本聰（Satoshi Nakamoto）撰寫的白皮書，看看它到底是什麼。我仍然記得讀完那九頁時的那一刻，當時我意識到比特幣不僅僅是一種數位貨幣，而是一個信任網路，可以為遠不止貨幣的事物提供基礎。「這不是錢，這是一個去中心化的信任網路」的認知，開啟了我四個月的旅程，瘋狂地吞噬我能找到的每一條關於比特幣的資訊。我變得痴迷和著迷，每天花 12 個小時或更長時間盯著螢幕，閱讀、寫作、編碼，並盡可能多地學習。我從這種出神狀態中走出來時，因為缺乏規律的飲食而瘦了超過 20 磅，決心將自己投入到比特幣的工作中。

兩年後，在創建了許多探索各種比特幣相關服務和產品的小型新創公司後,我決定是時候寫我的第一本書了。比特幣是驅使我進入創作狂熱並佔據我思想的主題；它是我自網際網路以來遇到的最令人興奮的技術。現在是時候與更廣大的受眾分享我對這項驚人技術的熱情了。

本書主要面向程式設計師。如果你會使用程式語言，本書將教你加密貨幣如何運作、如何使用它們，以及如何開發與它們配合運作的軟體。前幾章也適合作為非程式設計師的深入介紹——那些試圖理解比特幣和加密貨幣內部運作的人。

切葉蟻（Leafcutter Ant）是一種在群體超級有機體中表現出高度複雜行為的物種，但每隻螞蟻都按照一套由社交互動和化學氣味（費洛蒙）交換驅動的簡單規則運作。根據維基百科：「除了人類之外，切葉蟻形成了地球上最大和最複雜的動物社會。」切葉蟻實際上不吃樹葉，而是用它們來種植真菌，這是蟻群的中心食物來源。明白了嗎？這些螞蟻在種田！

儘管螞蟻形成了基於階級的社會，並有一隻蟻后負責繁殖後代，但在蟻群中沒有中央權威或領導者。由數百萬成員組成的群體所表現出的高度智慧和複雜行為，是社交網路中個體互動的湧現屬性。

大自然展示了去中心化系統可以具有韌性，可以產生湧現的複雜性和令人難以置信的精密性，而無需中央權威、階層或複雜的部件。

比特幣（Bitcoin）是一個高度複雜的去中心化信任網路，可以支援無數的金融流程。然而，比特幣網路中的每個節點都遵循一些簡單的規則。許多節點之間的互動導致了複雜行為的湧現，而不是任何單一節點中的任何固有複雜性或信任。就像蟻群一樣，比特幣網路是一個由遵循簡單規則的簡單節點組成的韌性網路，它們一起可以在沒有任何中央協調的情況下做出驚人的事情。

本書使用以下排版慣例：

所有程式碼片段都可以在大多數作業系統上使用最少安裝對應語言的編譯器和直譯器進行複製。在必要時，我們提供基本的安裝說明和這些指令輸出的逐步範例。

一些程式碼片段和程式碼輸出已針對印刷進行了重新格式化。在所有此類情況下，行已被反斜線（\）字元分割，後跟換行字元。在轉錄範例時，請移除這兩個字元並再次連接這些行，你應該會看到與範例中顯示的相同結果。

所有程式碼片段在可能的情況下都使用真實的值和計算，因此你可以從一個範例建構到另一個範例，並在你編寫的任何程式碼中看到相同的結果來計算相同的值。

這本書是為了幫助你完成工作。一般來說，如果本書提供了範例程式碼，你可以在你的程式和文件中使用它。除非你重現了程式碼的重要部分，否則你不需要聯絡我們以獲得許可。例如，編寫一個使用本書中幾個程式碼塊的程式不需要許可。銷售或分發 O’Reilly 書籍中的範例需要許可。透過引用本書和引用範例程式碼來回答問題不需要許可。將本書中大量範例程式碼合併到你的產品文件中確實需要許可。

我們感謝但不要求署名。署名通常包括 標題、#作者、出版商和 ISBN。例如：「Mastering Bitcoin，第 3 版，作者 [.keep-together]#Andreas M. Antonopoulos 和 David A. Harding（O’Reilly）。Copyright 2024 David Harding，ISBN 978-1-098-15009-9。」

本書的某些版本以開源授權提供，例如 CC-BY-NC，在這種情況下，該授權的條款適用。

如果你認為你對程式碼範例的使用超出了合理使用或上述許可的範圍，請隨時透過 [email protected] 聯絡我們。

A particular focus in the third edition has been modernizing the 2017 second edition text and the remaining 2014 first edition text. In addition, many concepts that are relevant to contempory Bitcoin development in 2023 have been added:

本書中使用的比特幣地址、交易、金鑰、QR 碼和區塊鏈資料大部分是真實的。這意味著你可以瀏覽區塊鏈，查看作為範例提供的交易，使用你自己的腳本或程式檢索它們等。

然而，請注意，用於構建地址的私鑰要麼已印在本書中，要麼已被「燒毀」。這意味著如果你將錢發送到這些地址中的任何一個，錢將永遠丟失，或者在某些情況下，任何可以閱讀本書的人都可以使用此處印刷的私鑰取走它。

我們獨特的專家和創新者網路透過書籍、文章和我們的線上學習平台分享他們的知識和專業知識。O’Reilly 的線上學習平台讓你可以隨選存取現場培訓課程、深入學習路徑、互動式編碼環境，以及來自 O’Reilly 和 200 多家其他出版商的大量文字和影片。有關更多資訊，請造訪 https://oreilly.com。

請將有關本書的評論和問題寄給出版商：

我們為本書設有網頁，列出勘誤表、範例和任何其他資訊。你可以在 https://oreil.ly/MasteringBitcoin3e 存取此頁面。

有關我們的書籍和課程的新聞和資訊，請造訪 https://oreilly.com。

在 LinkedIn 上找到我們：https://linkedin.com/company/oreilly-media。

在 Twitter 上關注我們：https://twitter.com/oreillymedia。

在 YouTube 上觀看我們：https://youtube.com/oreillymedia。

在 Facebook 上關注 Andreas： https://facebook.com/AndreasMAntonopoulos。

在 Twitter 上關注 Andreas： https://twitter.com/aantonop。

在 LinkedIn 上關注 Andreas： https://linkedin.com/company/aantonop。

非常感謝所有透過每月捐款支持 Andreas 工作的贊助者。你可以在此關注他的 Patreon 頁面： https://patreon.com/aantonop。

有關 Mastering Bitcoin 以及 Andreas 的開放版和翻譯的資訊，請造訪 https://bitcoinbook.info。

你可以在 David A. Harding 的個人網站上聯絡他： https://dtrt.org。

作者：Andreas M. Antonopoulos

這本書代表了許多人的努力和貢獻。我感謝朋友、同事，甚至完全陌生人提供的所有幫助，他們與我一起努力撰寫這本關於加密貨幣和比特幣的權威技術書籍。

不可能區分比特幣技術和比特幣社群，這本書既是該社群的產物，也是一本關於技術的書。從一開始到最後，整個比特幣社群都鼓勵、支持和獎勵了我在這本書上的工作。最重要的是，這本書讓我成為一個美好社群的一部分兩年，我感謝你們接納我進入這個社群。有太多人需要按名字提及——我在會議、活動、研討會、聚會、披薩聚會和小型私人聚會上遇到的人，以及許多透過 Twitter、reddit、bitcointalk.org 和 GitHub 與我交流的人，他們對這本書產生了影響。你在本書中找到的每個想法、類比、問題、答案和解釋，在某個時刻都受到我與社群的互動的啟發、測試或改進。感謝你們所有人的支持；沒有你們，這本書就不會誕生。我永遠感激。

成為作者的旅程當然早在第一本書之前就開始了。我的第一語言（和學校教育）是希臘語，所以我不得不在大學第一年參加補救英語寫作課程。我要感謝 Diana Kordas，我的英語寫作老師，她在那一年幫助我建立了信心和技能。後來，作為一名專業人士，我發展了關於資料中心主題的技術寫作技能，為 Network World 雜誌撰稿。我要感謝 John Dix 和 John Gallant，他們給了我在 Network World 擔任專欄作家的第一份寫作工作，以及我的編輯 Michael Cooney 和我的同事 Johna Till Johnson，他們編輯了我的專欄並使其適合出版。每週寫 500 字，持續四年，給了我足夠的經驗，最終考慮成為一名作家。

還要感謝那些在我向 O’Reilly 提交書籍提案時透過提供推薦信和審查提案來支持我的人。具體來說，感謝 John Gallant、Gregory Ness、Richard Stiennon、Joel Snyder、Adam B. Levine、Sandra Gittlen、John Dix、Johna Till Johnson、Roger Ver 和 Jon Matonis。特別感謝 Richard Kagan 和 Tymon Mattoszko，他們審查了提案的早期版本，以及 Matthew Taylor，他編輯了提案。

感謝 O’Reilly 書籍 DNS and BIND 的作者 Cricket Liu，他將我介紹給 O’Reilly。還要感謝 O’Reilly 的 Michael Loukides 和 Allyson MacDonald，他們花了幾個月的時間幫助實現這本書。Allyson 在錯過截止日期和延遲交付成果時特別有耐心，因為生活干預了我們計劃的時間表。對於第二版，我感謝 Timothy McGovern 指導流程，Kim Cofer 耐心編輯，Rebecca Panzer 繪製了許多新圖表。

前幾章的前幾稿是最困難的，因為比特幣是一個難以解開的主題。每次我拉動比特幣技術的一條線，我都必須拉動整個東西。我反覆陷入困境，有點沮喪，因為我努力使主題易於理解，並圍繞這樣一個密集的技術主題創建敘事。最終，我決定透過使用比特幣的人的故事來講述比特幣的故事，整本書變得更容易寫了。我要感謝我的朋友和導師 Richard Kagan，他幫助我解開故事並度過了寫作障礙的時刻。我感謝 Pamela Morgan，她審查了第一版和第二版中每章的早期草稿，並提出了困難的問題使它們更好。此外，感謝舊金山比特幣開發者聚會小組的開發者以及 Taariq Lewis 和 Denise Terry 幫助測試早期材料。還要感謝 Andrew Naugler 的資訊圖形設計。

在書籍開發期間，我在 GitHub 上提供了早期草稿並邀請公開評論。提交了一百多條評論、建議、更正和貢獻作為回應。這些貢獻在 早期發布草稿（GitHub 貢獻） 中得到明確承認，並表示感謝。最重要的是，我真誠感謝我的志願 GitHub 編輯 Ming T. Nguyen（第 1 版）和 Will Binns（第 2 版），他們不知疲倦地工作以管理、管理和解決 GitHub 上的拉取請求、問題報告並執行錯誤修復。

書籍起草後，經過了幾輪技術審查。感謝 Cricket Liu 和 Lorne Lantz 的徹底審查、評論和支持。

幾位比特幣開發者貢獻了程式碼範例、審查、評論和鼓勵。感謝 Amir Taaki 和 Eric Voskuil 提供的範例程式碼片段和許多精彩評論；Chris Kleeschulte 貢獻了關於 Bitcore 的資訊；Vitalik Buterin 和 Richard Kiss 幫助橢圓曲線數學和程式碼貢獻；Gavin Andresen 的更正、評論和鼓勵；Michalis Kargakis 的評論、貢獻和 btcd 撰寫；以及 Robin Inge 提交的勘誤表改進了第二次印刷。在第二版中，我再次從許多 Bitcoin Core 開發者那裡得到了很多幫助，包括 Eric Lombrozo，他揭開了隔離見證的神秘面紗，Luke Dashjr 幫助改進了交易章節，Johnson Lau 審查了隔離見證和其他章節，還有許多其他人。我要感謝 Joseph Poon、Tadge Dryja 和 Olaoluwa Osuntokun，他們解釋了閃電網路（Lightning Network），審查了我的寫作，並在我遇到困難時回答了問題。

我對文字和書籍的熱愛來自我的母親 Theresa，她在一個每面牆都排列著書籍的房子裡撫養我。儘管自稱是技術恐懼症患者，我的母親還是在 1982 年給我買了第一台電腦。我的父親 Menelaos 是一位土木工程師，剛剛在 80 歲時出版了他的第一本書，他教會了我邏輯和分析思維以及對科學和工程的熱愛。

感謝你們所有人在這段旅程中支持我。

作者：David A. Harding

Schnorr 簽章 中對非互動式 schnorr 簽章協議的介紹，首先描述了互動式 schnorr 身份協議，這受到 Gregory Maxwell 和 Andrew Poelstra 的「Borrommean Ring Signatures」（2015）中對該主題的介紹的重大影響。我對他們每個人在過去十年中免費提供的所有協助深表感激。

Jorge Lesmes、Olaoluwa Osuntokun、René Pickhardt 和 Mark "Murch" Erhardt 對本手稿的草稿提供了寶貴的技術審查。特別是，Murch 令人難以置信的深入和富有洞察力的審查，以及他願意評估同一文本的多次迭代，已將本書的品質提升到超出我最高期望的水平。

我還要感謝 Jimmy Song 建議我參與這個專案，感謝我的合著者 Andreas 允許我更新他的暢銷書，感謝 Angela Rufino 指導我完成 O’Reilly 的作者流程，以及 O’Reilly 的所有其他員工，使第三版的寫作成為一次愉快和富有成效的經歷。

最後，我不知道如何感謝所有幫助我走過這段旅程的比特幣貢獻者——從創建我使用的軟體，到教我它如何運作，再到幫助我傳遞我所獲得的一點知識。你們人數太多，無法列出你們的名字,但我經常想起你們，並知道如果沒有你們為我所做的一切，我對本書的貢獻是不可能的。

許多貢獻者為 GitHub 上的早期發布草稿提供了評論、更正和補充。感謝你們所有人對本書的貢獻。

以下是著名的 GitHub 貢獻者名單，包括他們的 GitHub ID（括號中）：

熱門的區塊鏈瀏覽器包括以下內容：

每個瀏覽器都有一個搜尋功能，可以接受比特幣地址、交易雜湊、區塊編號或區塊雜湊，並從比特幣網路檢索相應的資訊。對於每個交易或區塊範例，我們將提供一個 URL，以便你可以自己查詢它並詳細研究它。

Alice在上一章中介紹過，是一位剛剛獲得她的第一批比特幣的新使用者。在 取得你的第一個比特幣 中，Alice 與她的朋友 Joe 會面，用一些現金交換比特幣。從那時起，Alice 又購買了額外的比特幣。現在 Alice 將進行她的第一筆支出交易，從 Bob 的線上商店購買高級播客節目的存取權限。

Bob 的網路商店最近開始接受比特幣支付，方法是在其網站上新增比特幣選項。Bob 商店的價格以當地貨幣（美元）列出，但在結帳時，客戶可以選擇以美元或比特幣支付。

Alice 找到她想購買的播客節目並進入結帳頁面。在結帳時，除了常規選項外，還向 Alice 提供了使用比特幣支付的選項。結帳購物車以美元顯示價格，同時也以比特幣（BTC）顯示，按比特幣的當前匯率計算。

Bob 的電子商務系統將自動建立一個包含發票的 QR 碼（發票 QR 碼。）。

與僅包含目標比特幣地址的 QR 碼不同，此發票是 QR 編碼的 URI，其中包含目標地址、支付金額和描述。這允許比特幣錢包應用程式預填用於傳送付款的資訊，同時向使用者顯示人類可讀的描述。你可以使用比特幣錢包應用程式掃描 QR 碼以查看 Alice 會看到的內容：

Alice 使用她的智慧型手機掃描顯示幕上的條碼。她的智慧型手機顯示向 Bob's Store 支付正確金額的付款，她選擇傳送以授權付款。在幾秒鐘內（大約與信用卡授權相同的時間），Bob 在收銀機上看到交易。

你可以使用區塊瀏覽器檢查區塊鏈資料，例如 Alice 向 Bob 支付的 交易。

在以下部分中，我們將更詳細地檢查此交易。我們將看到 Alice 的錢包如何構建它，它如何在網路上傳播，它如何被驗證，以及最終 Bob 如何在後續交易中花費該金額。

簡單來說，交易告訴網路某些比特幣的所有者已授權將該價值轉移給另一個所有者。新所有者現在可以透過建立另一筆交易來花費比特幣，該交易授權轉移給另一個所有者，依此類推，形成一條所有權鏈。

Alice 的錢包應用程式包含所有用於選擇輸入和生成輸出以根據 Alice 的規範建構交易的邏輯。Alice 只需要選擇目的地、金額和交易手續費，其餘的在錢包應用程式中發生，而她看不到詳細資訊。重要的是，如果錢包已經知道它控制哪些輸入，即使完全離線，它也可以構建交易。就像在家裡寫支票並稍後在信封中將其傳送到銀行一樣，交易不需要在連接到比特幣網路時構建和簽署。

Alice 的交易現在在比特幣網路上傳播。在它被包含在一個稱為 mining 的過程的區塊中並且該區塊已被完整節點驗證之前，它不會成為 blockchain 的一部分。有關詳細說明，請參閱 挖礦與共識。

比特幣的防偽保護系統基於計算。交易被捆綁成 blocks。區塊有一個非常小的標頭，必須以非常特定的方式形成，需要大量的計算才能做對——但只需要少量的計算就可以驗證為正確。挖礦過程在比特幣中有兩個目的：

挖礦在成本和獎勵之間取得了微妙的平衡。挖礦使用電力來解決計算問題。成功的礦工將以新比特幣和交易手續費的形式收集 reward。但是，獎勵只會在礦工僅包含有效交易時收集，比特幣協議的 consensus 規則決定什麼是有效的。這種微妙的平衡為比特幣提供了安全性，無需中央權威機構。

挖礦被設計為去中心化彩票。每個礦工都可以透過建立包含他們想要挖掘的新交易加上一些額外資料欄位的 candidate block 來建立自己的彩票。礦工將其候選者輸入到專門設計的演算法中，該演算法對資料進行加擾（或「雜湊」），產生看起來與輸入資料完全不同的輸出。這個 hash 函數對於相同的輸入總是產生相同的輸出——但沒有人可以預測對於新輸入，輸出會是什麼樣子，即使它與先前的輸入只有微小的不同。如果雜湊函數的輸出與比特幣協議確定的模板相符，礦工就贏得了彩票，比特幣使用者將接受帶有其交易的區塊作為有效區塊。如果輸出與模板不符，礦工會對其候選區塊進行小的更改並再次嘗試。截至撰寫本文時，礦工在找到獲勝組合之前需要嘗試的候選區塊數量約為 168 億兆。這也是雜湊函數需要執行的次數。

但是，一旦找到獲勝組合，任何人都可以透過執行一次雜湊函數來驗證區塊是有效的。這使得有效區塊需要難以置信的工作量才能建立，但只需要微不足道的工作量就可以驗證。簡單的驗證過程能夠機率證明工作已完成，因此生成該證明所需的資料——在這種情況下，區塊——稱為 proof of work (PoW)。

交易被新增到新區塊中，首先按最高手續費率交易和一些其他標準排序。每個礦工在從網路接收到先前的區塊後立即開始挖掘新候選交易區塊的過程，知道其他一些礦工贏得了該輪彩票。他們立即建立一個帶有對先前區塊的承諾的新候選區塊，用交易填充它，並開始計算候選區塊的 PoW。每個礦工在其候選區塊中包含一個特殊交易，該交易將區塊獎勵加上候選區塊中包含的所有交易的交易手續費總和支付給他們自己的比特幣地址。如果他們找到一個使候選者成為有效區塊的解決方案，他們在成功的區塊新增到全局區塊鏈並且他們包含的獎勵交易變得可花費後，將收到此獎勵。參與挖礦池的礦工已設定他們的軟體來建立將獎勵分配給池地址的候選區塊。從那裡，獎勵的一部分按照他們貢獻的工作量的比例分配給池礦工的成員。

Alice 的交易被網路接收，並包含在未驗證交易池中。一旦由完整節點驗證，它就被包含在候選區塊中。在交易首次由 Alice 的錢包傳輸後大約五分鐘，一名礦工為該區塊找到解決方案並將其公佈到網路。在每個其他礦工驗證獲勝區塊後，他們開始新的彩票以生成下一個區塊。

包含 Alice 交易的獲勝區塊成為區塊鏈的一部分。包含 Alice 交易的區塊被計為該交易的一次 confirmation。在包含 Alice 交易的區塊在網路中傳播後，建立帶有 Alice 交易的不同版本的替代區塊（例如不支付給 Bob 的交易）將需要執行與所有比特幣礦工建立全新區塊所需的工作量相同的工作量。當有多個替代區塊可供選擇時，比特幣完整節點選擇具有最多總 PoW 的有效區塊鏈，稱為 best blockchain。為了讓整個網路接受替代區塊，需要在替代區塊之上挖掘額外的新區塊。

這意味著礦工有選擇。他們可以與 Alice 合作製作她向 Bob 付款的交易的替代方案，也許 Alice 向礦工支付她先前支付給 Bob 的一部分錢。這種不誠實的行為將要求他們花費建立兩個新區塊所需的努力。相反，誠實行為的礦工可以建立單個新區塊，並收到他們包含在其中的交易的所有手續費，加上區塊補貼。通常，不誠實地建立兩個區塊以獲得少量額外付款的高成本遠不如誠實地建立新區塊有利可圖，這使得已確認交易不太可能被故意更改。對於 Bob 來說，這意味著他可以開始相信來自 Alice 的付款是可靠的。

在包含 Alice 交易的區塊廣播後大約 19 分鐘，另一名礦工挖掘了一個新區塊。因為這個新區塊建立在包含 Alice 交易的區塊之上（給 Alice 的交易兩次確認），Alice 的交易現在只能在兩個替代區塊被挖掘後才能更改——加上在它們之上建立的新區塊——總共需要挖掘三個區塊才能讓 Alice 取回她傳送給 Bob 的錢。在包含 Alice 交易的區塊之上挖掘的每個區塊都算作額外的確認。隨著區塊一個接一個地疊加，逆轉交易變得更加困難，從而為 Bob 提供越來越多的信心，即 Alice 的付款是安全的。

在 Alice 的交易包含在區塊中。 中，我們可以看到包含 Alice 交易的區塊。在它下面是數十萬個區塊，在區塊鏈中相互連結（區塊鏈）一直回到第 0 個區塊，稱為 genesis block。隨著時間的推移，隨著新區塊的「高度」增加，整個鏈的計算難度也會增加。按照慣例，任何超過六次確認的區塊都被認為很難更改，因為它需要大量的計算來重新計算六個區塊（加上一個新區塊）。我們將在 挖礦與共識 中更詳細地檢查挖礦過程以及它如何建立信心。

Bitcoin 是一個 開源 專案，原始碼在開放（MIT）授權下可用，可免費下載並用於任何目的。不僅僅是開源，比特幣是由一個開放的志願者社群開發的。起初，該社群僅由中本聰（Satoshi Nakamoto）組成。到 2023 年，比特幣的原始碼已有 1,000 多位貢獻者，其中約有十幾位開發者幾乎全職從事程式碼工作，還有幾十位兼職開發者。任何人都可以為程式碼做出貢獻—包括你！

當中本聰創建比特幣時，軟體在白皮書發表之前大部分已經完成（在 比特幣白皮書 作者：中本聰 中複製）。中本聰想確保實作在發表論文之前有效。第一個實作，當時簡稱為「Bitcoin」，已經過大量修改和改進。它已經演變成所謂的 Bitcoin Core，以區別於其他實作。Bitcoin Core 是比特幣系統的 參考實作，這意味著它為技術的每個部分應該如何實作提供參考。Bitcoin Core 實作了比特幣的所有方面，包括錢包、交易和區塊驗證引擎、區塊構建工具，以及比特幣點對點通訊的所有現代部分。

Bitcoin Core 架構（來源：Eric Lombrozo）。 顯示了 Bitcoin Core 的架構。

儘管 Bitcoin Core 作為系統許多主要部分的參考實作，但比特幣白皮書描述了系統的幾個早期部分。自 2011 年以來，系統的大多數主要部分已在一組 比特幣改進提案（Bitcoin Improvement Proposals，BIPs）中記錄。在本書中，我們按其編號引用 BIP 規範；例如，BIP9 描述了用於比特幣幾個主要升級的機制。

如果你是開發者，你將希望設定一個開發環境，其中包含用於編寫比特幣應用程式的所有工具、函式庫和支援軟體。在這個高度技術性的章節中，我們將逐步完成該過程。如果材料變得太密集（並且你實際上沒有設定開發環境），請隨時跳到下一章，它不那麼技術性。

Bitcoin Core 的原始碼可以作為存檔下載，也可以透過從 GitHub 克隆原始碼儲存庫來下載。在 Bitcoin Core 下載頁面上，選擇最新版本並下載原始碼的壓縮存檔。或者，使用 Git 命令列從 GitHub Bitcoin 頁面建立原始碼的本地副本。

在這裡，我們使用 git 命令建立原始碼的本地副本（「克隆」）：

當 Git 克隆操作完成後，你將在目錄 bitcoin 中擁有原始碼儲存庫的完整本地副本。使用 cd 命令切換到此目錄：

比特幣的點對點網路由網路「節點」組成，主要由個人和一些提供比特幣服務的企業執行。執行比特幣節點的人對比特幣區塊鏈有直接和權威的看法，並擁有所有可花費比特幣的本地副本，這些副本由他們自己的系統獨立驗證。透過執行節點，你不必依賴任何第三方來驗證交易。此外，透過使用比特幣節點完全驗證你的錢包收到的交易，你為比特幣網路做出貢獻並幫助使其更加強大。

但是，執行節點需要最初下載和處理超過 500 GB 的資料，以及每天約 400 MB 的比特幣交易。這些數字是 2023 年的，並且可能會隨著時間的推移而增加。如果你關閉節點或與網際網路斷開連接幾天，你的節點將需要下載它錯過的資料。例如，如果你關閉 Bitcoin Core 10 天，下次啟動時你將需要下載約 4 GB。

根據你選擇是否索引所有交易並保留區塊鏈的完整副本，你可能還需要大量磁碟空間——如果你計劃執行 Bitcoin Core 幾年，至少需要 1 TB。預設情況下，比特幣節點還會將交易和區塊傳輸到其他節點（稱為「對等點（peers）」），消耗上傳網際網路頻寬。如果你的網際網路連接受限、具有低資料上限或按流量計費（按 GB 計費），你可能不應該在其上執行比特幣節點，或以限制其頻寬的方式執行它（請參閱 配置 Bitcoin Core 節點）。你可以將節點連接到替代網路，例如像 Blockstream Satellite 這樣的免費衛星資料提供商。

儘管有這些資源需求，數千人仍在執行比特幣節點。有些在像 Raspberry Pi（35 美元的卡片大小電腦）這樣簡單的系統上執行。

如果你正在閱讀本書並對強大的安全性、卓越的隱私或開發比特幣軟體感興趣，你應該執行你自己的節點。

Bitcoin Core 將在每次啟動時在其資料目錄中尋找配置檔案。在本節中，我們將檢查各種配置選項並設定配置檔案。要找到配置檔案，請在終端中執行 bitcoind -printtoconsole 並查看前幾行：

確定配置檔案的位置後，你可以按 Ctrl-C 關閉節點。通常配置檔案位於使用者主目錄下的 .bitcoin 資料目錄內。在你喜歡的編輯器中開啟配置檔案。

Bitcoin Core 提供 100 多個配置選項，可修改網路節點的行為、區塊鏈的儲存以及其操作的許多其他方面。要查看這些選項的列表，請執行 bitcoind --help：

以下是你可以在配置檔案中設定或作為 bitcoind 的命令列參數的一些最重要的選項：

完全索引節點的範例配置 顯示如何將前面的選項與完全索引節點組合，作為比特幣應用程式的 API 後端執行。

資源受限系統的範例配置 顯示在較小伺服器上執行的資源受限節點。

編輯配置檔案並設定最能代表你需求的選項後，你可以使用此配置測試 bitcoind。使用 printtoconsole 選項執行 Bitcoin Core，以在前台執行並將輸出到控制台：

一旦你對它正在載入正確的設定並按預期執行感到滿意，就可以按 Ctrl-C 中斷該過程。

要在後台作為程序執行 Bitcoin Core，請使用 daemon 選項啟動它，例如 bitcoind -daemon。

要監視比特幣節點的進度和執行時狀態，請在守護程式模式下啟動它，然後使用命令 bitcoin-cli getblockchaininfo：

這顯示一個區塊鏈高度為 0 個區塊和 83,999 個區塊頭的節點。節點首先從其對等點取得區塊頭，以找到具有最多工作量證明的區塊鏈，然後繼續下載完整區塊，並在執行時驗證它們。

一旦你對選擇的配置選項感到滿意，你應該將 Bitcoin Core 新增到作業系統的啟動腳本中，以便它持續執行並在作業系統重新啟動時重新啟動。你將在 Bitcoin Core 的原始碼目錄下的 contrib/init 中找到各種作業系統的許多範例啟動腳本，以及顯示哪個系統使用哪個腳本的 README.md 檔案。

Bitcoin Core 實作了一個 JSON-RPC 介面，也可以使用命令列助手 bitcoin-cli 存取。命令列允許我們互動式地試驗也可透過 API 以程式設計方式使用的功能。首先，呼叫 help 命令以查看可用的 Bitcoin Core RPC 命令列表：

這些命令中的每一個都可能需要許多參數。要獲得額外的幫助、詳細描述和有關參數的資訊，請在 help 後新增命令名稱。例如，要查看有關 getblockhash RPC 命令的幫助：

在幫助資訊的末尾，你將看到 RPC 命令的兩個範例，使用 bitcoin-cli 助手或 HTTP 客戶端 curl。這些範例示範了你可以如何呼叫命令。複製第一個範例並查看結果：

結果是一個區塊雜湊，在後續章節中有更詳細的描述。但現在，此命令應該在你的系統上返回相同的結果，證明你的 Bitcoin Core 節點正在執行，正在接受命令，並且有關於區塊 1,000 的資訊要返回給你。

在接下來的部分中，我們將示範一些非常有用的 RPC 命令及其預期輸出。

在比特幣生態系統中有許多替代客戶端、函式庫、工具包，甚至完整節點實作。這些以各種程式語言實作，為程式設計師提供其首選語言的本機介面。

以下部分列出了一些最好的函式庫、客戶端和工具包，按程式語言組織。

公鑰密碼學（public key cryptography）是在 1970 年代發明的，是現代計算機和資訊安全的數學基礎。

自從公鑰密碼學發明以來，已經發現了幾個合適的數學函數，例如質數指數運算和橢圓曲線乘法。這些數學函數在一個方向上很容易計算，但在相反方向上使用當今可用的計算機和演算法進行計算是不可行的。基於這些數學函數，密碼學能夠創建無法偽造的數位簽章。比特幣使用橢圓曲線加法和乘法作為其密碼學的基礎。

在比特幣中，我們可以使用公鑰密碼學來創建一個金鑰對（key pair），用於控制對比特幣的存取。金鑰對由私鑰和從私鑰衍生的公鑰組成。公鑰用於接收資金，私鑰用於簽署交易以花費資金。

公鑰和私鑰之間存在數學關係，允許私鑰用於生成訊息的簽章。這些簽章可以在不洩露私鑰的情況下針對公鑰進行驗證。

比特幣錢包包含一組金鑰對，每個金鑰對由一個私鑰和一個公鑰組成。私鑰（k）是一個數字，通常從隨機選擇的數字衍生而來。從私鑰開始，我們使用橢圓曲線乘法，一種單向密碼函數，來生成公鑰（K）。

雖然原始比特幣白皮書的插圖（原始比特幣白皮書中的交易鏈）顯示直接使用公鑰（pubkeys）和簽章（sigs），但比特幣的第一個版本實際上是將支付發送到稱為輸出腳本（output script）的欄位，並透過稱為輸入腳本（input script）的欄位授權花費這些比特幣。這些欄位允許除了（或代替）驗證簽章與公鑰對應之外執行額外的操作。例如，輸出腳本可以包含兩個公鑰並要求在支出輸入腳本中放置兩個相應的簽章。

稍後，在 交易腳本和腳本語言 中，我們將詳細學習腳本。現在，我們只需要理解比特幣被接收到一個輸出腳本，該腳本的作用類似於公鑰，而比特幣支出由輸入腳本授權，該腳本的作用類似於簽章。

我們已經確定 Alice 可以透過將她的一些比特幣分配給 Bob 的一個公鑰來支付 Bob。但是 Alice 如何獲得 Bob 的一個公鑰呢？Bob 可以直接給她一個副本，但讓我們再看一下我們在 公鑰 中使用的公鑰。請注意它相當長。想像一下 Bob 試圖透過電話向 Alice 讀取它：

比特幣軟體的最早版本不是直接輸入公鑰，而是允許支付者輸入接收者的 IP 地址，如 透過 網際網路檔案館 查看早期比特幣的發送畫面 所示。這個功能後來被移除了——使用 IP 地址有很多問題——但對它的快速描述將幫助我們更好地理解為什麼某些功能可能已被新增到比特幣協定中。

如果 Alice 在 Bitcoin 0.1 中輸入了 Bob 的 IP 地址，她的完整節點將與他的完整節點建立連線，並從 Bob 的錢包接收一個新的公鑰，該公鑰他的節點以前從未給過任何人。這是一個新的公鑰很重要，以確保支付 Bob 的不同交易不能被某人透過查看區塊鏈並注意到所有交易都支付相同的公鑰而連結在一起。

使用她的節點從 Bob 的節點接收的公鑰，Alice 的錢包將構建一個支付非常簡單的輸出腳本的交易輸出：

Bob 稍後將能夠使用完全由他的簽章組成的輸入腳本花費該輸出：

要弄清楚輸出和輸入腳本在做什麼，您可以將它們組合在一起（輸入腳本在前），然後注意每個資料片段（以尖括號顯示）被放置在項目清單的頂部，稱為堆疊（stack）。當遇到操作碼（opcode）時，它從堆疊中使用項目，從最頂部的項目開始。讓我們從組合的腳本開始看看它是如何工作的：

對於此腳本，Bob 的簽章被放在堆疊上，然後 Bob 的公鑰被放在它的頂部。OP_CHECKSIG 操作消耗兩個元素，從公鑰開始，然後是簽章，將它們從堆疊中移除。它驗證簽章對應於公鑰，並且還承諾（簽署）交易中的各個欄位。如果簽章正確，OP_CHECKSIG 在堆疊上用值 1 替換自己；如果簽章不正確，它用 0 替換自己。如果在評估結束時堆疊頂部有一個非零項目，腳本就通過了。如果交易中的所有腳本都通過，並且關於交易的所有其他細節都有效，那麼完整節點將認為該交易有效。

簡而言之，前面的腳本使用了原始白皮書中描述的相同公鑰和簽章，但增加了兩個腳本欄位和一個操作碼的複雜性。這在這裡似乎是額外的工作，但當我們查看下一節時，我們將開始看到好處。

這種輸出類型今天被稱為支付到公鑰（pay to public key），或簡稱 P2PK。它從未被廣泛用於支付，而且幾乎十年來沒有廣泛使用的程式支援 IP 地址支付。

輸入您想要支付的人的 IP 地址有許多優點，但也有許多缺點。一個特別的缺點是接收者需要他們的錢包在他們的 IP 地址上線上，並且需要從外部世界可存取。對於很多人來說，這不是一個選項。他們在晚上關閉計算機，他們的筆記型電腦進入睡眠狀態，他們位於防火牆後面，或者他們使用網路位址轉換（NAT）。

這讓我們回到像 Bob 這樣的接收者必須向像 Alice 這樣的支付者提供長公鑰的問題。早期比特幣開發者已知的最短版本的比特幣公鑰是 65 位元組，當以十六進位書寫時相當於 130 個字元。然而，比特幣已經包含了幾個資料結構，遠大於 65 位元組，需要在比特幣的其他部分使用最小量的安全資料進行安全引用。

比特幣透過雜湊函數（hash function）來實現這一點，雜湊函數是一種函數，它接受可能大量的資料，對其進行加擾（雜湊），並輸出固定量的資料。密碼雜湊函數在給定相同輸入時將始終產生相同的輸出，並且安全函數還將使某人無法選擇產生先前看到的輸出的不同輸入。這使得輸出成為對輸入的承諾（commitment）。這是一個承諾，實際上只有輸入 x 會產生輸出 X。

例如，想像我想問您一個問題，並以您無法立即閱讀的形式給您我的答案。假設問題是「中本聰是哪一年開始研究比特幣的？」我將以 SHA256 雜湊函數輸出的形式給您我答案的承諾，這是比特幣中最常用的函數：

稍後，在您告訴我您對問題答案的猜測之後，我可以揭示我的答案並向您證明我的答案作為雜湊函數的輸入，產生與我之前給您的完全相同的輸出：

現在想像我們問 Bob 這個問題：「您的公鑰是什麼？」Bob 可以使用雜湊函數給我們一個對他公鑰的密碼學安全承諾。如果他後來揭示他的金鑰，我們驗證它產生與他之前給我們的相同承諾，我們可以確定這是用於創建該早期承諾的完全相同的金鑰。

SHA256 雜湊函數被認為非常安全，並產生 256 位元（32 位元組）的輸出，不到原始比特幣公鑰大小的一半。然而，還有其他稍微不太安全的雜湊函數，產生更小的輸出，例如 RIPEMD-160 雜湊函數，其輸出為 160 位元（20 位元組）。出於中本聰從未說明的原因，原始版本的比特幣透過首先使用 SHA256 雜湊金鑰，然後使用 RIPEMD-160 雜湊該輸出來對公鑰進行承諾；這產生了對公鑰的 20 位元組承諾。

其中 K 是公鑰，A 是結果承諾。

現在我們了解了如何對公鑰進行承諾，我們需要弄清楚如何在交易中使用它。考慮以下輸出腳本：

以及以下輸入腳本：

它們一起形成以下腳本：

正如我們在 IP 地址：比特幣的原始地址（P2PK） 中所做的，我們開始將項目放在堆疊上。Bob 的簽章首先放入；然後將他的公鑰放在堆疊的頂部。OP_DUP 操作複製頂部項目，因此堆疊上的頂部和次頂部項目現在都是 Bob 的公鑰。OP_HASH160 操作消耗（移除）頂部公鑰並用使用 RIPEMD160(SHA256(K)) 雜湊它的結果替換它，因此現在堆疊的頂部是 Bob 公鑰的雜湊。接下來，對 Bob 公鑰的承諾被新增到堆疊的頂部。OP_EQUALVERIFY 操作消耗頂部兩個項目並驗證它們相等；如果 Bob 在輸入腳本中提供的公鑰與用於創建 Alice 支付的輸出腳本中承諾的公鑰相同，則應該如此。如果 OP_EQUALVERIFY 失敗，整個腳本就失敗了。最後，我們剩下一個僅包含 Bob 簽章和他的公鑰的堆疊；OP_CHECKSIG 操作碼驗證它們彼此對應，並且簽章承諾交易。

雖然這個支付到公鑰雜湊（pay to public key hash, P2PKH）的過程可能看起來複雜，但它允許 Alice 對 Bob 的支付僅包含對他公鑰的 20 位元組承諾，而不是金鑰本身，在原始版本的比特幣中金鑰本來是 65 位元組。對於 Bob 必須向 Alice 傳達的資料來說，這要少得多。

然而，我們還沒有討論 Bob 如何將這 20 個位元組從他的比特幣錢包傳遞到 Alice 的錢包。有常用的位元組值編碼，例如十六進位，但複製承諾時犯的任何錯誤都會導致比特幣被發送到無法花費的輸出，導致它們永遠丟失。在下一節中，我們將研究緊湊編碼和可靠的檢查和。

為了以緊湊的方式表示長數字，使用更少的符號，許多計算機系統使用基數（或進位）高於 10 的混合字母數字表示。例如，傳統的十進位系統使用 10 個數字，0 到 9，而十六進位系統使用 16 個，字母 A 到 F 作為六個額外的符號。以十六進位格式表示的數字比等效的十進位表示更短。更緊湊的 base64 表示使用 26 個小寫字母、26 個大寫字母、10 個數字，以及 2 個更多的字元，例如「+」和「/」，以透過基於文字的媒體（如電子郵件）傳輸二進位資料。

Base58 是與 base64 類似的編碼，使用大寫和小寫字母以及數字，但省略了一些經常相互誤認且在某些字體中顯示時可能看起來相同的字元。具體來說，base58 是 base64 去掉 0（數字零）、O（大寫 o）、l（小寫 L）、I（大寫 i）以及符號「+」和「/」。或者更簡單地說，它是一組小寫和大寫字母以及數字，但沒有剛才提到的四個字元（0、O、l、I）。比特幣的 base58 字母表 顯示了完整的 base58 字母表。

為了增加對打字錯誤或抄寫錯誤的額外安全性，base58check 包含一個以 base58 字母表編碼的檢查和（checksum）。檢查和是新增到正在編碼的資料末尾的額外四個位元組。檢查和源自編碼資料的雜湊，因此可用於偵測抄寫和打字錯誤。當呈現 base58check 程式碼時，解碼軟體將計算資料的檢查和並將其與程式碼中包含的檢查和進行比較。如果兩者不匹配，則引入了錯誤，base58check 資料無效。這防止了錯誤輸入的比特幣地址被錢包軟體接受為有效目的地，否則會導致資金損失。

要將資料（數字）轉換為 base58check 格式，我們首先向資料新增一個前綴，稱為「版本位元組」（version byte），用於輕鬆識別編碼的資料類型。例如，前綴零（十六進位的 0x00）表示資料應用作傳統 P2PKH 輸出腳本中的承諾（雜湊）。[base58check_versions] 顯示了常見版本前綴的清單。

接下來，我們計算「雙 SHA」檢查和，這意味著我們對前一個結果（前綴與資料串接）應用兩次 SHA256 雜湊演算法：

從產生的 32 位元組雜湊（雜湊的雜湊）中，我們僅取前四個位元組。這四個位元組用作錯誤檢查碼或檢查和。檢查和被附加到末尾。

結果由三個項目組成：前綴、資料和檢查和。此結果使用先前描述的 base58 字母表進行編碼。Base58check 編碼：一種 base58、帶版本和檢查和的格式，用於明確編碼比特幣資料 說明了 base58check 編碼過程。

結合公鑰、基於雜湊的承諾和 base58check 編碼，公鑰到比特幣地址：公鑰轉換為比特幣地址 說明了公鑰轉換為比特幣地址的過程。

當比特幣最初編寫時，其開發者只知道如何創建 65 位元組的公鑰。然而，後來的開發者意識到公鑰的替代編碼僅使用 33 位元組，並且與當時所有比特幣完整節點向後相容，因此無需更改比特幣協定。這些 33 位元組的公鑰被稱為壓縮公鑰（compressed public keys），而原始的 65 位元組金鑰被稱為未壓縮公鑰（uncompressed public keys）。使用較小的公鑰會產生較小的交易，允許在同一區塊中進行更多支付。

正如我們在 公鑰 一節中看到的，公鑰是橢圓曲線上的點 (x, y)。因為曲線表達了一個數學函數，曲線上的點代表方程式的解，因此，如果我們知道 x 座標，我們可以透過求解方程式 y² mod p = (x³ + 7) mod p 來計算 y 座標。這允許我們僅儲存公鑰點的 x 座標，省略 y 座標並將金鑰的大小和儲存所需的空間減少 256 位元。在每筆交易中幾乎 50% 的大小減少隨著時間的推移累積了大量節省的資料！

這是我們在 公鑰 中創建的私鑰生成的公鑰：

以下是顯示為 520 位元數字（130 個十六進位數字）的相同公鑰，前綴為 04，後跟 x 然後是 y 座標，格式為 04 x y：

而未壓縮公鑰的前綴為 04，壓縮公鑰以 02 或 03 前綴開頭。讓我們看看為什麼有兩個可能的前綴：因為方程式的左側是 y²，y 的解是平方根，可以有正值或負值。視覺上，這意味著產生的 y 座標可以在 x 軸上方或下方。正如您可以從 橢圓曲線 中的橢圓曲線圖中看到的，曲線是對稱的，這意味著它像鏡子一樣被 x 軸反射。因此，雖然我們可以省略 y 座標，但我們必須儲存 y 的符號（正或負）；換句話說，我們必須記住它是在 x 軸上方還是下方，因為這些選項中的每一個都代表不同的點和不同的公鑰。在質數階 p 的有限域上以二進位算術計算橢圓曲線時，y 座標是偶數或奇數，這對應於之前解釋的正/負符號。因此，為了區分 y 的兩個可能值，如果 y 是偶數，我們使用前綴 02 儲存壓縮公鑰，如果是奇數，則使用 03，允許軟體正確地從 x 座標推導出 y 座標並將公鑰解壓縮為點的完整座標。公鑰壓縮 說明了公鑰壓縮。

以下是在 公鑰 中生成的相同公鑰，顯示為以 264 位元（66 個十六進位數字）儲存的壓縮公鑰，前綴 03 表示 y 座標是奇數：

這個壓縮公鑰對應於相同的私鑰，這意味著它是從相同的私鑰生成的。然而，它看起來與未壓縮公鑰不同。更重要的是，如果我們使用 HASH160 函數（RIPEMD160(SHA256(K))）將此壓縮公鑰轉換為承諾，它將產生與未壓縮公鑰不同的承諾，導致不同的地址。這可能會令人困惑，因為這意味著單個私鑰可以產生以兩種不同格式（壓縮和未壓縮）表示的公鑰，它們產生兩個不同的比特幣地址。然而，對於兩個比特幣地址，私鑰是相同的。

壓縮公鑰現在是幾乎所有比特幣軟體的預設值，並且在使用後來協定升級中新增的某些新功能時是必需的。

然而，某些軟體仍然需要支援未壓縮公鑰，例如從舊錢包匯入私鑰的錢包應用程式。當新錢包掃描區塊鏈以查找舊 P2PKH 輸出和輸入時，它需要知道是掃描 65 位元組金鑰（以及對這些金鑰的承諾）還是 33 位元組金鑰（及其承諾）。未能掃描正確的類型可能導致使用者無法花費其全部餘額。為了解決這個問題，當從錢包匯出私鑰時，用於表示它們的 WIF 在較新的比特幣錢包中實作方式略有不同，以表明這些私鑰已用於產生壓縮公鑰。

正如我們在前面的章節中看到的，接收比特幣的人（如 Bob）可以要求支付給他的款項在其輸出腳本中包含某些約束。Bob 在花費這些比特幣時需要使用輸入腳本來滿足這些約束。在 IP 地址：比特幣的原始地址（P2PK） 中，約束僅僅是輸入腳本需要提供適當的簽章。在 P2PKH 的傳統地址 中，還需要提供適當的公鑰。

2012 年對比特幣協定的 BIP16 升級允許輸出腳本承諾贖回腳本（redemption script，redeem script）。當 Bob 花費他的比特幣時，他的輸入腳本需要提供與承諾匹配的贖回腳本，以及滿足贖回腳本所需的任何資料（例如簽章）。讓我們從想像 Bob 想要兩個簽章來花費他的比特幣開始，一個來自他的桌面錢包的簽章，一個來自硬體簽署設備的簽章。他將這些條件放入贖回腳本中：

然後，他使用與 P2PKH 承諾相同的 HASH160 機制創建對贖回腳本的承諾，RIPEMD160(SHA256(script))。該承諾使用特殊範本放入輸出腳本中：

當 Bob 去花費他收到的對其腳本承諾的支付時，他使用包含贖回腳本的輸入腳本，將其序列化為單個資料元素。他還提供滿足贖回腳本所需的簽章，按照它們將被操作碼消耗的順序放置它們：

當比特幣完整節點收到 Bob 的支出時，它們將驗證序列化的贖回腳本是否雜湊到與承諾相同的值。然後它們將用其反序列化的值在堆疊上替換它：

腳本被執行，如果它通過並且所有其他交易細節都正確，則交易有效。

P2SH 的地址也使用 base58check 創建。版本前綴設定為 5，這會導致編碼地址以 3 開頭。P2SH 地址的範例是 3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM。

P2PKH 和 P2SH 是使用 base58check 編碼的僅有的兩個腳本範本。它們現在被稱為傳統地址，並且隨著時間的推移變得越來越不常見。傳統地址被 bech32 地址家族所取代。

2017 年，比特幣協定進行了升級。當使用升級時，它防止交易識別碼（txid）在沒有支出使用者同意（或當需要多個簽章時的簽署者仲裁）的情況下被更改。這個升級稱為隔離見證（segregated witness，或簡稱 segwit），還為區塊中的交易資料提供了額外的容量以及其他幾個好處。然而，希望直接存取 segwit 好處的使用者必須接受對新輸出腳本的支付。

如 支付到腳本雜湊 中所述，P2SH 輸出類型的優勢之一是支付者（如 Alice）不需要知道接收者（如 Bob）使用的腳本的細節。segwit 升級設計為使用這種機制，允許使用者透過使用 P2SH 地址立即開始存取許多新好處。但是，要讓 Bob 存取所有好處，他需要 Alice 的錢包使用不同類型的腳本向他支付。這將需要 Alice 的錢包升級以支援新腳本。

起初，比特幣開發者提出了 BIP142，它將繼續使用帶有新版本位元組的 base58check，類似於 P2SH 升級。但是，讓所有錢包升級到帶有新 base58check 版本的新腳本預計需要幾乎與讓它們升級到全新地址格式一樣多的工作，因此幾位比特幣貢獻者著手設計可能的最佳地址格式。他們識別了 base58check 的幾個問題：

為 segwit 開發地址格式的開發者在一種名為 bech32（發音為軟「ch」，如「besh thirty-two」）的新地址格式中找到了這些問題的每一個的解決方案。「bech」代表 BCH，這是 1959 年和 1960 年發現 bech32 所基於的循環碼的三個人的首字母縮寫。「32」代表 bech32 字母表中的字元數（類似於 base58check 中的 58）：

在以下章節中，我們將研究進階形式的金鑰和地址，例如靚號地址和紙錢包。

簡單的錢包資料庫包含接收比特幣的公鑰和允許創建授權花費這些比特幣所需的簽章的私鑰。其他錢包的資料庫可能僅包含公鑰，或僅包含授權支出交易所需的部分私鑰。它們的錢包應用程式透過與外部工具（例如硬體簽署設備或多重簽章方案中的其他錢包）協作來產生必要的簽章。

錢包應用程式可以獨立生成它以後計劃使用的每個錢包金鑰，如 非確定性金鑰生成：儲存在錢包資料庫中的獨立生成金鑰集合 所示。所有早期的比特幣錢包應用程式都這樣做，但這需要使用者在每次生成和分發新金鑰時備份錢包資料庫，這可能與每次生成新地址以接收新支付一樣頻繁。未能及時備份錢包資料庫將導致使用者失去對接收到未備份金鑰的任何資金的存取。

對於每個獨立生成的金鑰，使用者需要備份大約 32 位元組，加上開銷。一些使用者和錢包應用程式試圖透過僅使用單個金鑰來最小化需要備份的資料量。儘管這可能是安全的，但它嚴重降低了該使用者以及與他們交易的所有人的隱私。重視自己和同伴隱私的人為每筆交易創建新的金鑰對，產生的錢包資料庫只能合理地使用數位媒體進行備份。

現代錢包應用程式不獨立生成金鑰，而是使用可重複（確定性）演算法從單個隨機種子衍生它們。

現代錢包的開發者可以從各種不同的技術中進行選擇，以幫助使用者創建和使用備份——並且每年都會出現新的解決方案。我們不會詳細介紹本章前面描述的每個選項，而是將本章的其餘部分集中在我們認為截至 2023 年初在錢包中最廣泛使用的技術堆疊上：

所有這些標準都是從 2014 年或更早開始使用的，您將毫無問題地找到使用它們的其他資源。然而，如果您感到大膽，我們確實鼓勵您調查可能提供額外功能或安全性的更現代的標準。

在 探索和解碼交易 中，我們使用啟用了 txindex 選項的 Bitcoin Core 檢索了 Alice 支付給 Bob 的副本。讓我們再次檢索包含該付款的交易，如 Alice 的序列化交易 所示。

Bitcoin Core 的序列化格式很特殊，因為它是用於對交易進行承諾並透過比特幣 P2P 網路中繼它們的格式，但除此之外，程式可以使用不同的格式，只要它們傳輸所有相同的資料。然而，Bitcoin Core 的格式對於它傳輸的資料來說相當緊湊且易於解析，因此許多其他比特幣程式使用此格式。

Alice 的序列化交易 中以十六進位顯示的交易在 Alice 交易的位元組對映。 中複製為位元組對映。請注意，需要 64 個十六進位字元來顯示 32 個位元組。此對映僅顯示頂層欄位。我們將按照它們在交易中出現的順序檢查每個欄位，並描述它們包含的任何其他欄位。

序列化比特幣交易的前四個位元組是其版本。比特幣交易的原始版本是版本 1（0x01000000）。比特幣中的所有交易都必須遵循版本 1 交易的規則，其中許多規則在本書中描述。

版本 2 比特幣交易在 BIP68 軟分叉變更中引入到比特幣的共識規則中。BIP68 對序列欄位施加了額外的限制，但這些限制僅適用於版本 2 或更高版本的交易。版本 1 交易不受影響。BIP112 是與 BIP68 相同軟分叉的一部分，升級了一個操作碼（OP_CHECKSEQUENCEVERIFY），如果它作為版本低於 2 的交易的一部分進行評估，現在將失敗。除了這兩個變更之外，版本 2 交易與版本 1 交易相同。

截至撰寫本文時，開始使用版本 3 交易的提案正在被廣泛考慮。該提案不尋求更改共識規則，而僅更改比特幣完整節點用於中繼交易的策略。根據該提案，版本 3 交易將受到額外的限制，以防止我們將在 交易固定 中討論的某些拒絕服務（DoS）攻擊。

範例序列化交易的接下來兩個欄位是作為隔離見證（segwit）軟分叉變更的一部分新增到比特幣共識規則中的。這些規則根據 BIP 141 和 143 進行了更改，但_擴展序列化格式_在 BIP144 中定義。

如果交易不需要見證堆疊，則標記和標誌不得存在。這與比特幣交易序列化格式的原始版本相容，現在稱為_傳統序列化_。詳情請參見 傳統序列化。

在傳統序列化中，標記位元組將被解釋為輸入數量（零）。交易不能有零個輸入，因此標記向現代程式發出正在使用擴展序列化的信號。標誌欄位提供類似的信號，並且還簡化了未來更新序列化格式的過程。

輸入欄位包含幾個其他欄位，因此讓我們首先在 Alice 交易的輸入欄位中位元組的對映。 中顯示這些位元組的對映。

交易的輸出欄位包含與特定輸出相關的幾個欄位。就像我們對輸入欄位所做的那樣，我們將從查看 Alice 支付給 Bob 的範例交易的輸出欄位的特定位元組開始，在 Alice 交易中輸出欄位的位元組映射。 中顯示為這些位元組的映射。

在法庭上，見證人是證明他們看到重要事情發生的人。人類見證人並不總是可靠的，因此法庭有各種程序來訊問見證人，以（理想情況下）只接受來自可靠者的證據。

想像一下數學問題的見證人會是什麼樣子。例如，如果重要的問題是 x + 2 == 4 並且有人聲稱他們見證了解決方案，我們會問他們什麼？我們想要一個數學證明，顯示一個可以與 2 相加等於 4 的值。我們甚至可以省略對人的需求，只使用建議的 x 值作為我們的見證人。如果我們被告知見證人是 two，那麼我們可以填入方程式，檢查它是否正確，並決定重要的問題已經解決。

在花費 bitcoin 時，我們想要解決的重要問題是確定花費是否得到控制這些 bitcoin 的人或人們的授權。執行 Bitcoin 共識規則的數千個完整節點無法訊問人類見證人，但它們可以接受完全由用於解決數學問題的資料組成的_見證_。例如，2 的見證將允許花費由以下腳本保護的 bitcoin：

顯然，允許任何能解決簡單方程式的人花費您的 bitcoin 是不安全的。正如我們將在 數位簽章 中看到的，不可偽造的數位簽章方案使用一個方程式，該方程式只能由擁有他們能夠保密的某些資料的人來解決。他們能夠使用公開識別符號引用該秘密資料。該公開識別符號稱為_公鑰_，方程式的解稱為_簽章_。

以下腳本包含一個公鑰和一個操作碼，該操作碼要求相應的簽章承諾花費交易中的資料。就像我們簡單範例中的數字 2 一樣，簽章是我們的見證：

見證，用於解決保護 bitcoin 的數學問題的值，需要包含在使用它們的交易中，以便完整節點驗證它們。在用於所有早期 Bitcoin 交易的傳統交易格式中，簽章和其他資料放置在輸入腳本欄位中。然而，當開發人員開始在 Bitcoin 上實作合約協議時，例如我們在 基於序列的原始交易替換 中看到的，他們發現將見證放在輸入腳本欄位中存在幾個重大問題。

序列化交易中的最後一個欄位是其鎖定時間。此欄位是 Bitcoin 原始序列化格式的一部分，但最初僅由 Bitcoin 的選擇要挖掘哪些交易的策略執行。Bitcoin 最早已知的軟分叉添加了一條規則，從區塊高度 31,000 開始，禁止在區塊中包含交易，除非它滿足以下規則之一：

每個區塊中的第一筆交易是一個特殊情況。大多數較舊的文件稱這為_生成交易_，但大多數較新的文件稱其為 coinbase 交易（不要與名為「Coinbase」的公司建立的交易混淆）。

Coinbase 交易由包含它們的區塊的礦工建立，並賦予礦工選擇索取該區塊中交易支付的任何手續費的選項。此外，直到區塊 6,720,000，礦工被允許索取由以前從未流通過的 bitcoin 組成的補貼，稱為區塊補貼。礦工可以為一個區塊索取的總金額——手續費和補貼的組合——稱為_區塊獎勵_。

coinbase 交易的一些特殊規則包括：

coinbase 交易可以具有在正常交易中有效的任何其他輸出。然而，花費其中一個輸出的交易在 coinbase 交易收到 100 次確認之前不能包含在任何區塊中。這稱為_成熟規則_，並且還沒有 100 次確認的 coinbase 交易輸出稱為_未成熟_。

大多數 Bitcoin 軟體不需要處理 coinbase 交易，但它們的特殊性質確實意味著它們有時可能是未設計為預期它們的軟體中不尋常問題的原因。

每個 Bitcoin 區塊在可以包含的交易資料量上受到限制，因此大多數 Bitcoin 軟體需要能夠測量它建立或處理的交易。Bitcoin 的現代測量單位稱為_權重_。權重的替代版本是 vbytes，其中四個權重單位等於一個 vbyte，提供與傳統 Bitcoin 區塊中使用的原始_位元組_測量單位的簡單比較。

區塊限制為 400 萬權重。區塊頭佔用 240 權重。一個額外的欄位，交易計數，使用 4 或 12 權重。所有剩餘的權重可用於交易資料。

要計算交易中特定欄位的權重，將該序列化欄位的大小（以位元組為單位）乘以一個因子。要計算交易的權重，將其所有欄位的權重加在一起。交易中每個欄位的因子顯示在 [weight_factors] 中。為了提供一個範例，我們還計算了本章中從 Alice 到 Bob 的範例交易中每個欄位的權重。

選擇這些因子以及應用它們的欄位是為了減少花費 UTXO 時使用的權重。這有助於阻止建立 不經濟的輸出和不允許的粉塵 中描述的不經濟輸出。

本章開頭 Alice 的序列化交易 中 Alice 的交易以權重單位表示，顯示在 Alice 交易的位元組映射。 中。您可以通過比較兩個圖像中各個欄位之間大小的差異來看到因子的作用。

在撰寫本書時，本章中描述的序列化格式用於大多數新的 Bitcoin 交易，但較舊的序列化格式仍用於許多交易。該較舊的格式稱為_傳統序列化_，必須在 Bitcoin P2P 網路上用於任何具有空見證結構的交易（這僅在交易不花費任何見證程式時有效）。

傳統序列化不包括標記、標誌和見證結構欄位。

Bitcoin的原始版本引入了一種稱為 Script 的新程式語言，一種類似 Forth 的基於堆疊的語言。放置在輸出中的腳本和花費交易中使用的傳統輸入腳本都是用這種腳本語言編寫的。

Script 是一種非常簡單的語言。它需要最少的處理，並且不能輕易完成許多現代程式語言可以完成的花哨事情。

當傳統交易是最常用的交易類型時，透過 Bitcoin 網路處理的大多數交易都具有「支付給 Bob 的 Bitcoin 地址」的形式，並使用稱為支付到公鑰雜湊（P2PKH）腳本的腳本。然而，Bitcoin 交易並不僅限於「支付給 Bob 的 Bitcoin 地址」腳本。實際上，腳本可以編寫為表達各種各樣的複雜條件。為了理解這些更複雜的腳本，我們必須首先理解交易腳本和 Script 語言的基礎知識。

在本節中，我們將展示 Bitcoin 交易腳本語言的基本組件，並展示如何使用它來表達花費條件以及如何滿足這些條件。

多重簽章腳本設置一個條件，其中在腳本中記錄了 k 個公鑰，並且至少必須提供其中 t 個來花費資金，稱為 t-of-k。例如，2-of-3 多重簽章是一個列出三個公鑰作為潛在簽署者的簽章，並且必須使用其中至少兩個來建立簽章，以使交易花費資金有效。

設置 t-of-k 多重簽章條件的輸出腳本的一般形式是：

其中 k 是列出的公鑰總數，t 是花費輸出所需簽章的閾值。

設置 2-of-3 多重簽章條件的輸出腳本如下所示：

前面的輸出腳本可以用包含 [.keep-together]#簽章的#輸入腳本滿足：

或來自與三個列出的公鑰相對應的私鑰的兩個簽章的任何組合。

兩個腳本一起將形成組合驗證腳本：

執行時，如果輸入腳本具有來自對應於設置為限制條件的三個公鑰中的兩個的私鑰的兩個有效簽章，則此組合腳本將評估為 TRUE。

目前，Bitcoin Core 的交易中繼策略將多重簽章輸出腳本限制為最多三個列出的公鑰，這意味著您可以執行從 1-of-1 到 3-of-3 多重簽章或該範圍內的任何組合。您可能想檢查 IsStandard() 函數以查看網路當前接受的內容。請注意，三個金鑰的限制僅適用於標準（也稱為「裸」）多重簽章腳本，不適用於包裝在另一個結構（如 P2SH、P2WSH 或 P2TR）中的腳本。P2SH 多重簽章腳本受策略和共識限制為 15 個金鑰，允許最多 15-of-15 多重簽章。我們將在 支付到腳本雜湊 中學習 P2SH。所有其他腳本在共識上受限於每個 OP_CHECKMULTISIG 或 OP_CHECKMULTISIGVERIFY 操作碼 20 個金鑰，儘管一個腳本可能包含多個這些操作碼。

支付到腳本雜湊（P2SH）於 2012 年引入，作為一種強大的新型操作，大大簡化了複雜腳本的使用。為了解釋 P2SH 的需求，讓我們看一個實際範例。

Mohammed 是一位總部位於杜拜的電子產品進口商。Mohammed 的公司在其公司帳戶中廣泛使用 Bitcoin 的多重簽章功能。多重簽章腳本是 Bitcoin 進階腳本功能最常見的用途之一，是一個非常強大的功能。Mohammed 的公司對所有客戶付款使用多重簽章腳本。客戶支付的任何款項都以這樣的方式鎖定，即需要至少兩個簽章才能釋放。Mohammed、他的三位合夥人和他們的律師每人都可以提供一個簽章。這樣的多重簽章方案提供了公司治理控制，並防止盜竊、挪用或損失。

生成的腳本相當長，看起來像這樣：

儘管多重簽章腳本是一個強大的功能，但使用起來很繁瑣。給定前面的腳本，Mohammed 必須在付款之前將此腳本傳達給每個客戶。每個客戶都必須使用具有建立自訂交易腳本能力的特殊 Bitcoin 錢包軟體。此外，生成的交易將大約是簡單支付交易的五倍大，因為此腳本包含非常長的公鑰。額外資料的負擔將以額外交易手續費的形式由客戶承擔。最後，像這樣的大型交易腳本將在每個完整節點的 UTXO 集中攜帶，直到它被花費。所有這些問題都使得在實踐中難以使用複雜的輸出腳本。

P2SH 的開發旨在解決這些實際困難，並使複雜腳本的使用與支付到單金鑰 Bitcoin 地址一樣容易。使用 P2SH 支付，複雜腳本被承諾（密碼雜湊的摘要）替換。當稍後呈現嘗試花費 UTXO 的交易時，它必須包含與承諾相符的腳本，以及滿足腳本的資料。簡單來說，P2SH 意味著「支付給與此雜湊相符的腳本，該腳本將在稍後花費此輸出時呈現」。

在 P2SH 交易中，被雜湊替換的腳本稱為_贖回腳本_，因為它在贖回時呈現給系統，而不是作為輸出腳本。[without_p2sh] 顯示沒有 P2SH 的腳本，[with_p2sh] 顯示使用 P2SH 編碼的相同腳本。

從表中可以看出，使用 P2SH，詳細說明花費輸出條件的複雜腳本（贖回腳本）不會呈現在輸出腳本中。相反，輸出腳本中只有它的雜湊，贖回腳本本身稍後作為輸入腳本的一部分在花費輸出時呈現。這將手續費和複雜性的負擔從支出者轉移到交易的接收者。

讓我們看看 Mohammed 的公司、複雜的多重簽章腳本和生成的 P2SH 腳本。

首先，Mohammed 公司用於所有來自客戶的傳入付款的多重簽章腳本：

可以透過首先應用 SHA256 雜湊演算法，然後對結果應用 RIPEMD-160 演算法，將整個腳本表示為 20 位元組密碼雜湊。例如，從 Mohammed 的贖回腳本的雜湊開始：

P2SH 交易使用特殊的輸出腳本範本將輸出鎖定到此雜湊而不是較長的贖回腳本：

如您所見，這要短得多。P2SH 等效交易不是「支付給這個 5 金鑰多重簽章腳本」，而是「支付給具有此雜湊的腳本」。向 Mohammed 公司付款的客戶只需在其支付中包含此短得多的輸出腳本。當 Mohammed 和他的合夥人想要花費這個 UTXO 時，他們必須呈現原始贖回腳本（其雜湊鎖定了 UTXO）和解鎖它所需的簽章，如下所示：

兩個腳本分兩個階段組合。首先，檢查贖回腳本是否與輸出腳本相符以確保雜湊匹配：

如果贖回腳本雜湊匹配，則執行贖回腳本：

Bitcoin的分散式和時間戳區塊鏈具有超越支付的潛在用途。許多開發人員嘗試使用交易腳本語言來利用系統的安全性和彈性，用於諸如數位公證服務等應用程式。將 Bitcoin 的腳本語言用於這些目的的早期嘗試涉及建立在區塊鏈上記錄資料的交易輸出；例如，以這樣的方式記錄對文件的承諾，即任何人都可以透過引用該交易在特定日期建立該文件的存在證明。

達成了一項妥協，允許以 OP_RETURN 開頭的輸出腳本向交易輸出添加非支付資料。然而，與使用「假」UTXO 不同，OP_RETURN 運算子建立一個明確的_可證明不可花費_的輸出，該輸出不需要儲存在 UTXO 集中。OP_RETURN 輸出記錄在區塊鏈上，因此它們消耗磁碟空間並有助於區塊鏈大小的增加，但它們不儲存在 UTXO 集中，因此不會使完整節點承擔更昂貴的資料庫操作成本而膨脹。

OP_RETURN 腳本如下所示：

資料部分通常表示雜湊，例如來自 SHA256 演算法的輸出（32 位元組）。一些應用程式在資料前面放置一個前綴以幫助識別應用程式。例如，https://proofofexistence.com[Proof of Existence] 數位公證服務使用 8 位元組前綴 DOCPROOF，在十六進位中編碼為 ASCII 為 44 4f 43 50 52 4f 4f 46。

請記住，沒有與 OP_RETURN 相對應的輸入腳本可以用來「花費」OP_RETURN 輸出。OP_RETURN 輸出的全部意義在於您不能花費鎖定在該輸出中的錢，因此它不需要作為潛在可花費的保存在 UTXO 集中：OP_RETURN 輸出是_可證明不可花費_的。OP_RETURN 輸出通常具有零金額，因為分配給此類輸出的任何 bitcoin 實際上永遠丟失。如果 OP_RETURN 輸出在交易中作為輸入引用，則腳本驗證引擎將停止驗證腳本的執行並將交易標記為無效。執行 OP_RETURN 本質上會導致腳本以 FALSE 「RETURN」並停止。因此，如果您意外地在交易中引用 OP_RETURN 輸出作為輸入，則該交易無效。

Bitcoin Script 更強大的功能之一是流程控制，也稱為條件子句。您可能熟悉各種程式語言中使用 IF...THEN...ELSE 結構的流程控制。Bitcoin 條件子句看起來有點不同，但本質上是相同的結構。

在基本層面上，Bitcoin 條件操作碼允許我們建立一個有兩種解鎖方式的腳本，具體取決於評估邏輯條件的 TRUE/FALSE 結果。例如，如果 x 為 TRUE，則執行的程式碼路徑為 A，ELSE 程式碼路徑為 B。

此外，Bitcoin 條件表達式可以無限期地「嵌套」，這意味著條件子句可以包含另一個子句，而另一個子句又包含另一個子句，依此類推。Bitcoin Script 流程控制可用於建立具有數百種可能執行路徑的非常複雜的腳本。嵌套沒有限制，但共識規則對腳本的最大大小（以位元組為單位）施加了限制。

Bitcoin 使用 OP_IF、OP_ELSE、OP_ENDIF 和 OP_NOTIF 操作碼實作流程控制。此外，條件表達式可以包含布林運算子，例如 OP_BOOLAND、OP_BOOLOR 和 OP_NOT。

乍一看，您可能會發現 Bitcoin 的流程控制腳本令人困惑。這是因為 Bitcoin Script 是一種堆疊語言。就像 1 {plus} 1 在表示為 1 1 OP_ADD 時看起來「倒退」一樣，Bitcoin 中的流程控制子句也看起來「倒退」。

在大多數傳統（程序）程式語言中，流程控制如下所示：

在像 Bitcoin Script 這樣的基於堆疊的語言中，邏輯條件在 IF 之前，這使得它看起來「倒退」：

在閱讀 Bitcoin Script 時，請記住正在評估的條件在 IF 操作碼_之前_。

在本節中，我們將本章中的許多概念組合到一個範例中。

Mohammed 是杜拜的公司老闆，經營進出口業務；他希望建立一個具有靈活規則的公司資本帳戶。他建立的方案根據時間鎖需要不同級別的授權。多重簽章方案的參與者是 Mohammed、他的兩位合夥人 Saeed 和 Zaira，以及他們的公司律師。三位合夥人根據多數規則做出決定，因此三個中的兩個必須同意。但是，如果他們的金鑰出現問題，他們希望他們的律師能夠使用三位合夥人簽章之一來收回資金。最後，如果所有合夥人一段時間都不可用或無行為能力，他們希望律師在獲得資本帳戶交易記錄的存取權限後能夠直接管理帳戶。

帶有時間鎖的可變多重簽章 是 Mohammed 設計的贖回腳本以實現此目的（已添加行號前綴）。

Mohammed 的腳本使用巢狀的 OP_IF...OP_ELSE 流程控制子句實現了三個執行路徑。

在第一個執行路徑中，這個腳本作為一個簡單的 2-of-3 多重簽章運作，由三個合夥人控制。這個執行路徑由第 3 和 9 行組成。第 3 行將多重簽章的法定人數設定為 2（2-of-3）。可以透過在輸入腳本的末尾放置 OP_TRUE OP_TRUE 來選擇這個執行路徑：

第二個執行路徑只能在 UTXO 創建後 30 天後使用。在那時，它需要律師的簽章和三個合夥人中的一個的簽章（1-of-3 多重簽章）。這是透過第 7 行實現的，它將多重簽章的法定人數設定為 1。要選擇這個執行路徑，輸入腳本應該以 OP_FALSE OP_TRUE 結尾：

最後，第三個執行路徑允許律師單獨支付資金，但只能在 90 天後。要選擇這個執行路徑，輸入腳本必須以 OP_FALSE 結尾：

試著在紙上執行這個腳本，看看它在堆疊上的行為。

使用 OP_IF，您可以授權多個不同的支付條件，但這種方法有幾個不理想的方面：

然而，Bitcoin 已經使用了一種稱為默克爾樹的資料結構，它允許驗證元素是集合的成員，而無需識別集合的每個其他成員。

我們將在 默克爾樹 中更多地了解默克爾樹，但基本資訊是，我們想要的資料集的成員（例如，任何長度的授權條件）可以傳遞到雜湊函數中以創建一個短的承諾（稱為默克爾樹的_葉子_）。然後將這些葉子中的每一個與另一個葉子配對並再次雜湊，創建對葉子的承諾，稱為_分支_承諾。可以以相同的方式創建對一對分支的承諾。對分支重複此步驟，直到只剩下一個識別符，稱為_默克爾根_。使用我們來自 帶有時間鎖的可變多重簽章 的範例腳本，我們在 具有三個子腳本的 MAST。 中為三個授權條件中的每一個構建一個默克爾樹。

我們現在可以創建一個緊湊的成員資格證明，證明特定的授權條件是默克爾樹的成員，而無需披露默克爾樹的任何其他成員的任何詳細資訊。請參見 其中一個子腳本的 MAST 成員資格證明。，並注意陰影節點可以從使用者提供的其他資料計算出來，因此不需要在支付時指定。

在此範例中節省 29 位元組（7%）並不能完全捕捉潛在的節省。默克爾樹的二元樹性質意味著您每次將集合中的成員數量（在這種情況下為授權條件）加倍時，只需要額外的 32 位元組承諾。在這種情況下，有三個條件，我們需要使用三個承諾（其中一個是默克爾根，需要包含在授權資料中）；我們也可以有四個承諾以相同的成本。額外的承諾將給我們最多八個條件。僅使用 16 個承諾（512 位元組的承諾），我們就可以擁有超過 32,000 個授權條件，遠遠超過可以在充滿 OP_IF 語句的整個交易區塊中有效使用的數量。使用 128 個承諾（4,096 位元組），我們理論上可以創建的條件數量遠遠超過世界上所有計算機可以創建的條件數量。

通常情況下，並非每個授權條件都同樣可能被使用。在我們的範例案例中，我們預計 Mohammed 和他的合夥人會經常支付他們的錢；時間延遲條件僅在出現問題時才存在。我們可以使用這些知識重組我們的樹，如 將最可能的腳本放在最佳位置的 MAST。 所示。

無論樹如何構建，我們都可以在前面的範例中看到，我們只揭示實際使用的授權條件。其他條件保持私密。條件的數量也保持私密：樹可以有一個條件或一萬億個條件——對於僅查看單個交易的鏈上資料的人來說，沒有辦法分辨。

除了略微增加 Bitcoin 的複雜性之外，MAST 對 Bitcoin 沒有顯著的缺點，在發現改進方法（我們將在 Taproot 中看到）之前，有兩個可靠的提案，BIP114 和 BIP116。

正如我們在 公共子金鑰衍生 中看到的，橢圓曲線密碼學（ECC）的數學允許 Alice 使用私鑰衍生她給 Bob 的公鑰。他可以將任意值添加到該公鑰以創建衍生公鑰。如果他將該任意值給 Alice，她可以將其添加到她的私鑰以衍生衍生公鑰的私鑰。簡而言之，Bob 可以創建子公鑰，只有 Alice 可以創建相應的私鑰。這對於 BIP32 風格的階層確定性（HD）錢包恢復很有用，但它也可以服務於另一個用途。

讓我們想像 Bob 想從 Alice 那裡購買東西，但他也想能夠在以後證明他支付了什麼，以防有任何爭議。Alice 和 Bob 就正在出售的商品或服務的名稱達成一致（例如，「Alice 的播客劇集 #123」），並透過雜湊並將雜湊摘要解釋為數字來將該描述轉換為數字。Bob 將該數字添加到 Alice 的公鑰並支付它。這個過程稱為_金鑰調整_，該數字稱為_調整_。

Alice 可以透過使用相同的數字（調整）調整她的私鑰來花費資金。

稍後，Bob 可以透過揭示她的基礎金鑰和他們使用的描述來向任何人證明他支付給 Alice 的內容。任何人都可以驗證支付的公鑰是否等於基礎金鑰加上對描述的雜湊承諾。如果 Alice 承認該金鑰是她的，那麼她收到了付款。如果 Alice 花費了資金，這進一步證明她在簽署支付交易時知道描述，因為只有在她知道調整（描述）的情況下，她才能為調整後的公鑰創建有效的簽章。

如果 Alice 和 Bob 都決定不公開揭示他們使用的描述，他們之間的支付看起來就像任何其他支付一樣。沒有隱私損失。

因為 P2C 預設是私密的，我們無法知道它用於其原始目的的頻率——理論上每筆支付都可以使用它，儘管我們認為這不太可能。然而，P2C 今天以稍微不同的形式被廣泛使用，我們將在 Taproot 中看到。

在 腳本化多重簽章 中，我們查看了需要來自多個金鑰的簽章的腳本。然而，還有另一種方法需要多個金鑰的合作，這也令人困惑地稱為_多重簽章_。為了在本節中區分這兩種類型，我們將涉及 OP_CHECKSIG 風格操作碼的版本稱為_腳本多重簽章_，另一個版本稱為_無腳本多重簽章_。

無腳本多重簽章涉及每個參與者以與創建私鑰相同的方式創建自己的秘密。我們將這個秘密稱為_部分私鑰_，儘管我們應該注意它與常規完整私鑰的長度相同。從部分私鑰，每個參與者使用我們在 公鑰 中描述的用於常規公鑰的相同演算法衍生部分公鑰。每個參與者與所有其他參與者共享他們的部分公鑰，然後將所有金鑰組合在一起以創建無腳本多重簽章公鑰。

這個組合的公鑰看起來與任何其他 Bitcoin 公鑰相同。第三方無法區分多方公鑰和單個使用者生成的普通金鑰。

要花費受無腳本多重簽章公鑰保護的比特幣，每個參與者生成一個部分簽章。然後將部分簽章組合以創建常規完整簽章。有許多已知的創建和組合部分簽章的方法；我們將在 數位簽章 中更多地討論這個主題。與無腳本多重簽章的公鑰類似，此過程生成的簽章看起來與任何其他 Bitcoin 簽章相同。第三方無法確定簽章是由一個人創建的還是一百萬人相互合作創建的。

無腳本多重簽章比腳本多重簽章更小且更私密。對於腳本多重簽章，放置在交易中的位元組數會隨著涉及的每個金鑰和簽章而增加。對於無腳本多重簽章，大小是恆定的——一百萬個參與者每個都提供自己的部分金鑰和部分簽章，在交易中放入的資料量與使用單個金鑰和簽章的個人完全相同。隱私的情況也是如此：因為每個新金鑰或簽章都會向交易添加資料，腳本多重簽章會披露有關正在使用多少金鑰和簽章的資料——這可能使得很容易弄清楚哪些交易是由哪組參與者創建的。然而，因為每個無腳本多重簽章看起來都像其他無腳本多重簽章和每個單簽章一樣，所以不會洩漏減少隱私的資料。

另一個缺點是閾值簽署不會揭示誰簽署了。在腳本閾值簽署中，Alice、Bob 和 Carol 同意（例如）他們中的任何兩個簽署都足以花費資金。如果 Alice 和 Bob 簽署，這需要將他們每個人的簽章放在鏈上，向任何知道他們金鑰的人證明他們簽署了，而 Carol 沒有。在無腳本閾值簽署中，Alice 和 Bob 之間的簽章與 Alice 和 Carol 或 Bob 和 Carol 之間的簽章無法區分。這對隱私有利，但這意味著，即使 Carol 聲稱她沒有簽署，她也無法證明她沒有簽署，這對於問責制和可審計性可能是不利的。

對於許多使用者和用例，多重簽章始終減少的大小和增加的隱私超過了其偶爾創建和審計簽章的挑戰。

人們選擇使用 Bitcoin 的一個原因是可以創建具有高度可預測結果的合約。由法院執行的法律合約部分取決於參與案件的法官和陪審員的決定。相比之下，Bitcoin 合約通常需要其參與者採取行動，但否則由數千個運行功能相同的程式碼的完整節點執行。當給予相同的合約和相同的輸入時，每個完整節點將始終產生相同的結果。任何偏差都意味著 Bitcoin 被破壞了。人類法官和陪審員可以比軟體靈活得多，但當不需要或不需要靈活性時，Bitcoin 合約的可預測性是一項重大資產。

如果合約中的所有參與者都認識到其結果已變得完全可預測，則實際上他們不需要繼續使用合約。他們可以做合約強迫他們做的任何事情，然後終止合約。在社會中，這是大多數合約終止的方式：如果相關方感到滿意，他們永遠不會將合約提交給法官或陪審員。在 Bitcoin 中，這意味著任何將使用大量區塊空間來結算的合約也應該提供一個允許透過相互滿意來結算的條款。

在 MAST 中，使用無腳本多重簽章，相互滿意條款很容易設計。我們只需將腳本樹的頂層葉子之一設為所有相關方之間的無腳本多重簽章。我們已經在 將最可能的腳本放在最佳位置的 MAST。 中看到了幾方之間具有簡單相互滿意條款的複雜合約。我們可以透過從腳本多重簽章切換到無腳本多重簽章來使其更加優化。

這是相當有效和私密的。如果使用相互滿意條款，我們只需要提供一個默克爾分支，我們揭示的只是涉及簽章（可能來自一個人，也可能來自數千個不同的參與者）。但開發人員在 2018 年意識到，如果我們也使用支付到合約，我們可以做得更好。

在我們之前在 支付到合約 (P2C) 中對支付到合約的描述中，我們調整了公鑰以承諾 Alice 和 Bob 之間協議的文本。我們可以透過承諾 MAST 的根來承諾合約的程式碼。我們調整的公鑰是常規 Bitcoin 公鑰，這意味著它可以需要來自單個人的簽章，或者它可以需要來自多個人的簽章（或者它可以以特殊方式創建以使為其生成簽章變得不可能）。這意味著我們可以透過來自所有相關方的單個簽章或透過揭示我們想要使用的 MAST 分支來滿足合約。涉及公鑰和 MAST 的承諾樹在 公鑰承諾默克爾根的 taproot。 中顯示。

這使得使用多重簽章的相互滿意條款非常高效且非常私密。它甚至比看起來更私密，因為單個使用者想要透過單個簽章（或由他們控制的多個不同錢包生成的多重簽章）滿足它而創建的任何交易在鏈上看起來與相互滿意支付相同。在這種情況下，一百萬個使用者參與極其複雜的合約或單個使用者只是花費他們儲存的比特幣之間沒有鏈上差異。

當可以僅使用金鑰進行支付時，例如對於單個簽章或無腳本多重簽章，這被稱為_金鑰路徑支付_。當使用腳本樹時，這被稱為_腳本路徑支付_。對於金鑰路徑支付，放在鏈上的資料是公鑰（在見證程式中）和簽章（在見證堆疊上）。

對於腳本路徑支付，鏈上資料還包括公鑰，它被放置在見證程式中，在此上下文中稱為 taproot 輸出金鑰。見證結構包括以下資訊：

我們只知道 taproot 的一個重要描述的缺點：想要使用 MAST 但不想要相互滿意條款的合約的參與者必須在區塊鏈上包含 taproot 內部金鑰，增加約 33 位元組的開銷。鑑於幾乎所有合約都預期會從相互滿意條款或其他使用頂層公鑰的多重簽章條款中受益，並且所有使用者都從輸出看起來彼此相似的增加的匿名集中受益，大多數參與 taproot 啟動的使用者並不認為這種罕見的開銷重要。

對 taproot 的支援在 2021 年 11 月啟動的軟分叉中添加到 Bitcoin。

Taproot 啟用 MAST，但僅使用與以前使用的 Bitcoin Script 語言略有不同的版本，新版本稱為 tapscript。主要區別包括：

儘管我們在本章中深入探討了授權和認證，但我們跳過了 Bitcoin 如何認證支付者的一個非常重要的部分：其簽章。我們將在 數位簽章 中看到這一點。

在 1989 年，Claus Schnorr 發表了一篇論文，描述了以他命名的簽章演算法。該演算法並不特定於 Bitcoin 和許多其他應用程式使用的橢圓曲線密碼學（ECC），儘管它今天可能與 ECC 最密切相關。Schnorr 簽章具有許多優良特性：

在本章後面，我們將準確描述 Bitcoin 中使用的 schnorr 簽章演算法，但我們將從其簡化版本開始，並分階段逐步實現實際協議。

在稍後的某個時候，Bob 希望 Alice 透過證明她知道 Bob 之前收到的公鑰（xG）的純量 x 來識別自己。Alice 不能直接給 Bob x，因為那會允許他向其他人識別為她，所以她需要在不向 Bob 洩露 x 的情況下證明她對 x 的知識，稱為_零知識證明_。為此，我們開始 schnorr 身份過程：

讓我們討論互動式 schnorr 身份協議的一些安全功能：

一種簡單的技術，稱為 Fiat-Shamir 轉換（以其發現者命名），可以將 schnorr 互動式身份協議轉變為非互動式數位簽章方案。回想一下步驟 1 和 2 的重要性——包括它們必須按順序執行。Alice 必須承諾一個不可預測的 nonce；Bob 必須只在收到她的承諾後才給 Alice 一個不可預測的挑戰純量。還要回想我們在本書其他地方使用的安全密碼雜湊函數的特性：當給定相同的輸入時，它總是產生相同的輸出，但當給定不同的輸入時，它會產生與隨機資料無法區分的值。

這允許 Alice 選擇她的私有 nonce，衍生她的公共 nonce，然後雜湊公共 nonce 以獲得挑戰純量。因為 Alice 無法預測雜湊函數的輸出（挑戰），並且因為對於相同的輸入（nonce）它始終是相同的，這確保了 Alice 獲得隨機挑戰，即使她選擇 nonce 並自己對其進行雜湊。我們不再需要 Bob 的互動。她可以簡單地發布她的公共 nonce kG 和純量 s，數千個完整節點（過去和未來）中的每一個都可以雜湊 kG 以產生 e，使用它來產生 exG，然後驗證 sG == kG + exG。明確寫出，驗證等式變為 sG == kG + hash(kG) × xG。

我們需要另一件事來完成將互動式 schnorr 身份協議轉換為對 Bitcoin 有用的數位簽章協議。我們不只是想讓 Alice 證明她知道她的私鑰；我們還想讓她能夠承諾一個訊息。具體來說，我們希望她承諾與她想要發送的 Bitcoin 交易相關的資料。有了 Fiat-Shamir 轉換，我們已經有了一個承諾，所以我們可以簡單地讓它額外承諾訊息。我們現在還使用 hash(kG || m) 承諾訊息 m，而不是 hash(kG)，其中 || 代表串聯。

我們現在已經定義了 schnorr 簽章協議的一個版本，但還有一件事我們需要做以解決 Bitcoin 特定的問題。在 BIP32 金鑰衍生中，如 公共子金鑰衍生 中所述，未強化衍生的演算法獲取公鑰並向其添加非秘密值以產生衍生公鑰。這意味著也可以將該非秘密值添加到一個金鑰的有效簽章中以產生相關金鑰的簽章。該相關簽章是有效的，但它未經擁有私鑰的人授權，這是一個重大的安全失敗。為了保護 BIP32 未強化衍生並支援人們想要在 schnorr 簽章之上構建的幾個協議，Bitcoin 的 schnorr 簽章版本稱為 BIP340 secp256k1 的 schnorr 簽章，除了公共 nonce 和訊息之外，還承諾正在使用的公鑰。這使得完整承諾為 hash(kG || xG || m)。

現在我們已經描述了 BIP340 schnorr 簽章演算法的每個部分並解釋了它為我們做了什麼，我們可以定義協議。整數的乘法是_模 p_ 執行的，表示操作的結果除以數字 p（如 secp256k1 標準中定義的），並使用餘數。數字 p 非常大，但如果它是 3 且操作的結果是 5，我們將使用的實際數字是 2（即，5 除以 3 的餘數是 2）。

設置：Alice 選擇一個大的隨機數（x）作為她的私鑰（直接或使用像 BIP32 這樣的協議從大的隨機種子值確定性地生成私鑰）。她使用 secp256k1 中定義的參數（請參見 橢圓曲線密碼學解釋）將生成器 G 乘以她的純量 x，產生 xG（她的公鑰）。她將她的公鑰給每個將來會認證她的 Bitcoin 交易的人（例如，透過將 xG 包含在交易輸出中）。當她準備好花費時，她開始生成她的簽章：

不幸的是，對於 Bitcoin 和許多其他應用程式的未來發展，Claus Schnorr 對他發現的演算法申請了專利，並在近二十年內阻止了它在開放標準和開源軟體中的使用。1990 年代初期的密碼學家在被阻止使用 schnorr 簽章方案時，開發了一種替代構造，稱為_數位簽章演算法_（DSA），並有一個適應於橢圓曲線的版本稱為 ECDSA。

ECDSA 方案和建議的標準化參數在 2007 年開始開發 Bitcoin 時已經在密碼學函式庫中廣泛實現。這幾乎肯定是 ECDSA 從第一個發布版本直到 2021 年 taproot 軟分叉激活之前，成為 Bitcoin 支援的唯一數位簽章協議的原因。ECDSA 今天仍然支援所有非 taproot 交易。與 schnorr 簽章相比的一些差異包括：

正如我們在 Schnorr 簽章 和 ECDSA 簽章 中看到的，簽章生成演算法使用隨機數 k 作為私有/公共 nonce 對的基礎。k 的值並不重要，只要它是隨機的。如果來自同一私鑰的簽章對不同訊息（交易）使用相同的私有 nonce k，那麼任何人都可以計算出簽署_私鑰_。在簽章演算法中重複使用相同的 k 值會導致私鑰洩露！

這不僅僅是理論上的可能性。我們已經看到這個問題導致 Bitcoin 中幾種不同的交易簽署演算法實現中私鑰的洩露。由於無意中重複使用 k 值，人們的資金被盜取。重複使用 k 值的最常見原因是隨機數生成器初始化不當。

為了避免這個漏洞，業界最佳實踐不是僅使用熵種子的隨機數生成器來生成 k，而是使用部分由交易資料本身加上用於簽署的私鑰種子的過程。這確保每筆交易產生不同的 k。用於 ECDSA 的 k 確定性初始化的行業標準演算法在 RFC6979 中定義，由網際網路工程任務組發布。對於 schnorr 簽章，BIP340 推薦預設簽署演算法。

BIP340 和 RFC6979 可以完全確定性地生成 k，這意味著相同的交易資料將始終產生相同的 k。許多錢包這樣做是因為這使編寫測試來驗證其安全關鍵的簽署程式碼是否正確產生 k 值變得容易。BIP340 和 RFC6979 也都允許在計算中包含額外資料。如果該資料是熵，那麼即使簽署完全相同的交易資料，也會產生不同的 k。這可以增加對側通道攻擊和故障注入攻擊的保護。

如果您正在實現一個演算法來簽署 Bitcoin 中的交易，您_必須_使用 BIP340、RFC6979 或類似的演算法來確保您為每筆交易生成不同的 k。

Bitcoin交易中的簽章適用於_承諾雜湊_，該雜湊從交易資料計算得出，鎖定資料的特定部分以指示簽署者對這些值的承諾。例如，在簡單的 SIGHASH_ALL 類型簽章中，承諾雜湊包括所有輸入和輸出。

不幸的是，傳統承諾雜湊的計算方式引入了節點驗證簽章時可能被迫執行大量雜湊計算的可能性。具體來說，雜湊操作相對於交易中的輸入數量大約呈二次方增長。因此，攻擊者可以創建一個具有非常大量簽章操作的交易，導致整個 Bitcoin 網路必須執行數百或數千次雜湊操作來驗證交易。

Segwit 代表了透過更改承諾雜湊計算方式來解決這個問題的機會。對於 segwit 版本 0 見證程式，簽章驗證使用如 BIP143 中指定的改進承諾雜湊演算法。

新演算法允許雜湊操作的數量相對於簽章操作的數量以更漸進的 O(n) 增長，減少了使用過於複雜的交易創建拒絕服務攻擊的機會。

在本章中，我們了解了 Bitcoin 的 schnorr 和 ECDSA 簽章。這解釋了完整節點如何認證交易以確保只有控制接收比特幣的金鑰的人才能花費這些比特幣。我們還檢查了簽章的幾個進階應用，例如無腳本多重簽章和無腳本閾值簽章，可以用來提高 Bitcoin 的效率和隱私。在過去幾章中，我們學習了如何創建交易、如何使用授權和認證保護它們以及如何簽署它們。接下來，我們將學習如何透過向我們創建的交易添加手續費來鼓勵礦工確認它們。

大多數支付系統都涉及某種交易手續費，但這種手續費通常對典型買家是隱藏的。例如，商家可能以相同的價格宣傳相同的商品，無論您是用現金還是信用卡支付，即使他們的支付處理商對信用交易收取的手續費可能高於他們的銀行對現金存款收取的手續費。

在 Bitcoin 中，每次花費比特幣都必須經過認證（通常使用簽章），因此交易不可能在未經支付者許可的情況下支付手續費。交易的接收者可以在不同的交易中支付手續費——我們稍後會看到這種用法——但如果我們希望單筆交易支付自己的手續費，該手續費需要由支付者同意。它無法被隱藏。

Bitcoin 交易的設計使得支付者承諾其支付的手續費不需要在交易中佔用任何額外空間。這意味著，儘管可以在不同的交易中支付手續費，但在單筆交易中支付手續費是最有效率的（因此最便宜）。

在 Bitcoin 中，手續費是一種出價，支付的金額有助於確定交易確認所需的時間。支付的支付者和接收者通常都有興趣使其快速確認，因此通常只允許支付者選擇手續費有時可能是一個問題；我們將在 子支付父（CPFP）手續費提升 中查看該問題的解決方案。但是，在許多常見的支付流程中，最希望看到交易快速確認的各方——也就是最願意支付更高手續費的各方——是支付者。

出於這些技術和實際原因，在 Bitcoin 中，支付者支付交易手續費是慣例。也有例外，例如接受未確認交易的商家，以及不在簽署後立即廣播交易的協議（阻止支付者能夠為當前市場選擇適當的手續費）。我們稍後將探討這些例外。

每筆交易只支付一筆手續費——無論交易有多大都無關緊要。但是，交易越大，礦工能夠在區塊中放入的交易就越少。因此，礦工評估交易的方式與您在市場上比較幾種等效商品時的方式相同：他們將價格除以數量。

您可能將幾種不同袋裝米的成本除以每袋的重量以找到每重量的最低價格（最划算），礦工將交易的手續費除以其大小（也稱為其權重）以找到每權重的最高手續費（最大收入）。在 Bitcoin 中，我們使用術語_手續費率_來表示交易的大小除以權重。由於 Bitcoin 多年來的變化，手續費率可以用不同的單位表示：

我們建議使用 sat/vbyte 或 sat/weight 單位來顯示手續費率。

我們已經確定，如果您願意等待更長時間讓交易確認，您可以支付較低的手續費率，但例外情況是支付太低的手續費率可能導致您的交易永遠無法確認。由於手續費率是區塊空間公開拍賣中的出價，因此不可能完美預測您需要支付什麼手續費率才能在特定時間內確認交易。但是，我們可以根據其他交易在最近過去支付的手續費率產生粗略估計。

完整節點可以記錄其看到的每筆交易的三條資訊：它首次收到該交易的時間（區塊高度）、該交易確認時的區塊高度，以及該交易支付的手續費率。透過將在相似高度到達、在相似高度確認並支付相似手續費的交易組合在一起，我們可以計算確認支付特定手續費率的交易需要多少個區塊。然後，我們可以假設現在支付類似手續費率的交易將需要類似數量的區塊來確認。Bitcoin Core 包含一個使用這些原則的手續費率估算器，可以使用 estimatesmartfee RPC 呼叫，並帶有一個參數，指定您願意等待多少個區塊，交易才有很高的可能性確認（例如，144 個區塊約為 1 天）：

許多基於網路的服務也提供手續費估算作為 API。有關當前列表，請參見 https://oreil.ly/TB6IN。

如前所述，手續費率估算永遠無法完美。一個常見的問題是基本需求可能會改變，調整平衡點並將價格（手續費）提高到新高度或將其降低到最低值。如果手續費率下降，那麼先前支付正常手續費率的交易現在可能支付高手續費率，它將比預期更早確認。您無法降低已發送交易的手續費率，因此您只能支付更高的手續費率。但是，當手續費率上升時，需要有方法能夠提高這些交易的手續費率，這稱為_手續費提升_。Bitcoin 中有兩種常用的手續費提升類型，手續費替代（RBF）和子支付父（CPFP）。

要使用 RBF 手續費提升來提高交易的手續費，您需要創建支付更高手續費的交易的衝突版本。如果兩筆或多筆交易("交易", "衝突"被認為是_衝突交易_，則只有其中一筆可以包含在有效的區塊鏈中，迫使礦工只選擇其中一筆。當兩筆或多筆交易各自嘗試花費相同的 UTXO 之一時，即它們各自包含具有相同輸出點（對先前交易輸出的引用）的輸入時，就會發生衝突。

為了防止有人透過創建無限數量的衝突交易並透過中繼完整節點的網路發送它們來消耗大量頻寬，Bitcoin Core 和其他支援交易替換的完整節點要求每筆替換交易支付比被替換交易更高的手續費率。Bitcoin Core 目前還要求替換交易支付比原始交易更高的總手續費，但這一要求具有不良副作用，開發人員在撰寫本文時一直在尋找消除它的方法。

Bitcoin Core目前支援兩種 RBF 變體：

作為使用者，如果您計劃使用 RBF 手續費提升，您首先需要選擇支援它的錢包，例如在 https://oreil.ly/IhMzx 上列為具有「發送支援」的錢包之一。

作為開發人員，如果您計劃實現 RBF 手續費提升，您首先需要決定是執行選擇性 RBF 還是完全 RBF。在撰寫本文時，選擇性 RBF 是唯一確定可行的方法。即使完全 RBF 變得可靠，也可能會有幾年時間，選擇性交易的替換比完全 RBF 替換確認得稍快。如果您選擇選擇性 RBF，您的錢包將需要實現 BIP125 中指定的信號，這是對交易中任何一個序列欄位的簡單修改（請參見 序列）。如果您選擇完全 RBF，則無需在交易中包含任何信號。與 RBF 相關的其他所有內容對於兩種方法都是相同的。

當您需要提升交易的手續費時，您只需創建一筆新交易，該交易花費至少與您想要替換的原始交易相同的 UTXO 之一。您可能希望在交易中保留支付接收者的相同輸出。您可以透過減少找零輸出的價值或向交易添加額外輸入來支付增加的手續費。開發人員應為使用者提供手續費提升介面，為他們完成所有這些工作，並簡單地詢問他們（或向他們建議）手續費率應該提高多少。

RBF 手續費提升相對於其他類型的手續費提升的優勢在於它可以非常有效地使用區塊空間。通常，替換交易與它替換的交易大小相同。即使它更大，它通常與使用者如果在第一時間支付增加的手續費率時會創建的交易大小相同。

RBF 手續費提升的根本缺點是它通常只能由交易的創建者執行——需要為交易提供簽章或其他認證資料的人或人們。例外情況是透過使用 sighash 標誌（請參見 簽章雜湊類型（SIGHASH））設計為允許添加額外輸入的交易，但這會帶來自己的挑戰。一般來說，如果您是未確認交易的接收者，並且您想讓它更快（或完全）確認，您無法使用 RBF 手續費提升；您需要其他方法。

RBF 還有其他問題，我們將在 交易固定 中探討。

任何收到未確認交易輸出的人都可以透過花費該輸出來激勵礦工確認該交易。您想要確認的交易稱為_父交易_。花費父交易輸出的交易稱為_子交易_。

正如我們在 輸出點 中學到的，已確認交易中的每個輸入都必須引用出現在區塊鏈中較早的交易的未花費輸出（無論是在同一區塊中較早還是在先前的區塊中）。這意味著想要確認子交易的礦工還必須確保其父交易已確認。如果父交易尚未確認，但子交易支付的手續費足夠高，礦工可以考慮在同一區塊中確認它們兩者是否有利可圖。

為了評估挖掘父交易和子交易的獲利能力，礦工將它們視為具有總大小和總手續費的_交易包_，從中可以將手續費除以大小來計算包手續費率。然後，礦工可以按手續費率對他們知道的所有單獨交易和交易包進行排序，並將最高收入的交易包含在他們正在嘗試挖掘的區塊中，直到區塊中允許包含的最大大小（權重）。為了找到更多可能有利可圖的包，礦工可以評估跨多代的包（例如，將未確認的父交易與其子交易和孫交易組合在一起）。這被稱為_祖先手續費率挖掘_。

Bitcoin Core 多年來一直實現祖先手續費率挖掘，並且據信在撰寫本文時幾乎所有礦工都在使用它。這意味著錢包使用此功能透過使用子交易為其父交易支付手續費來提升傳入交易的手續費是切實可行的（CPFP）。

CPFP 相對於 RBF 有幾個優勢。任何收到交易輸出的人都可以使用 CPFP——包括支付的接收者和支付者（如果支付者包含了找零輸出）。它也不需要替換原始交易，這使得它對某些商家來說比 RBF 的干擾性更小。

與 RBF 相比，CPFP 的主要缺點是 CPFP 通常使用更多區塊空間。在 RBF 中，手續費提升交易通常與它替換的交易大小相同。在 CPFP 中，手續費提升會添加一個完全獨立的交易。使用額外的區塊空間需要支付超出手續費提升成本之外的額外手續費。

CPFP 存在幾個挑戰，其中一些我們將在 交易固定 中探討。我們特別需要提到的另一個問題是最低中繼手續費率問題，這由包中繼解決。

早期版本的 Bitcoin Core 對其記憶池（請參見 記憶池和孤兒池）中儲存用於稍後中繼和挖掘的未確認交易數量沒有任何限制。當然，電腦有物理限制，無論是記憶體（RAM）還是磁碟空間——完整節點不可能儲存無限數量的未確認交易。後來的 Bitcoin Core 版本將記憶池的大小限制為大約可容納一天的交易量，僅儲存手續費率最高的交易或包。

這對大多數事情都非常有效，但它創建了一個依賴問題。為了計算交易包的手續費率，我們需要父交易和子交易——但如果父交易支付的手續費率不夠高，它將不會保留在節點的記憶池中。如果節點收到一筆子交易而沒有訪問其父交易的權限，它就無法對該交易做任何事情。

解決此問題的方法是能夠將交易作為包中繼，稱為_包中繼_，允許接收節點在對任何單獨交易進行操作之前評估整個包的手續費率。截至本文撰寫時，致力於 Bitcoin Core 的開發人員在實現包中繼方面取得了重大進展，並且在本書出版時可能會提供其有限的早期版本。

包中繼對於基於時間敏感的預簽交易的協議尤其重要，例如閃電網路（LN）。在非合作的情況下，一些預簽交易無法使用 RBF 進行手續費提升，迫使它們依賴於 CPFP。在這些協議中，某些交易也可能在需要廣播之前很久就創建了，這使得估算適當的手續費率實際上是不可能的。如果預簽交易支付的手續費率低於進入節點記憶池所需的金額，則無法使用子交易提升其手續費。如果這阻止交易及時確認，誠實的使用者可能會損失金錢。包中繼是解決這個關鍵問題的方案。

主要的拒絕服務問題之一圍繞著交易關係的影響。每當交易的輸出被花費時，該交易的識別碼（txid）就會被子交易引用。但是，當交易被替換時，替換具有不同的 txid。如果該替換交易被確認，則其所有後代都不能包含在同一區塊鏈中。可以重新創建和重新簽署後代交易，但這並不保證會發生。這對 RBF 和 CPFP 有相關但不同的含義：

交易固定可能是偶然發生的，但它也代表了對多方時間敏感協議（如 LN）的嚴重漏洞。如果您的交易對手可以在截止日期之前阻止您的交易之一確認，他們可能能夠從您那裡竊取金錢。

協議開發人員多年來一直在努力緩解交易固定的問題。CPFP 分割和錨點輸出 中描述了一個部分解決方案。已經提出了其他幾種解決方案，並且截至本文撰寫時，至少有一種解決方案正在積極開發中——https://oreil.ly/300dv[暫時性錨點]。

理論上，開發人員可以設計他們的交易以允許使用 RBF（使用特殊的 sighash 標誌）或 CPFP 進行手續費提升，但這兩個協議都容易受到交易固定的影響。鑑於所涉及的交易具有時間敏感性，允許交易對手使用交易固定來延遲交易的確認很容易導致惡意方可以用來從誠實方竊取金錢的可重複利用。

LN 開發人員 Matt Corallo 提出了一個解決方案：為 CPFP 手續費提升的規則提供特殊例外，稱為 CPFP 分割。CPFP 的正常規則禁止包含額外的後代，如果它會導致父交易擁有 26 個或更多後代，或者如果它會導致父交易及其所有後代的大小超過 100,000 vbytes。根據 CPFP 分割的規則，即使會超過其他限制，只要單個額外交易的大小最多為 1,000 vbytes，且是沒有未確認祖先的未確認交易的直接子交易，就可以將其添加到包中。

不允許使用 CPFP 分割超過一次，因此它僅適用於兩方協議。已經有提議將其擴展到涉及更多參與者的協議，但對此需求不大，開發人員專注於構建更通用的解決方案來解決交易固定攻擊。

截至本文撰寫時，大多數流行的 LN 實現使用稱為_錨點輸出_的交易模板，該模板旨在與 CPFP 分割一起使用。

交易的資料結構沒有手續費欄位。相反，手續費隱含為輸入總和與輸出總和之間的差額。在扣除所有輸出後從所有輸入中剩餘的任何多餘金額就是礦工收取的手續費：

這是交易的一個有點令人困惑的元素，也是需要理解的重要一點，因為如果您正在構建自己的交易，您必須確保不會因為輸入支出不足而無意中包含非常高的手續費。這意味著您必須計算所有輸入，如有必要，透過創建找零來實現，否則您最終會給礦工一筆非常大的小費！

例如，如果您花費 20 比特幣的 UTXO 進行 1 比特幣的支付，您必須包含 19 比特幣的找零輸出返回到您的錢包。否則，19 比特幣的「剩餘」將被計為交易手續費，並由在區塊中挖掘您的交易的礦工收取。儘管您會獲得優先處理並使礦工非常高興，但這可能不是您的本意。

手續費狙擊是一種理論攻擊情境，其中試圖重寫過去區塊的礦工從未來區塊「狙擊」更高手續費的交易以最大化其[.keep-together]獲利能力。

例如，假設存在的最高區塊是區塊 #100,000。如果一些礦工不是試圖挖掘區塊 #100,001 來擴展鏈，而是試圖重新挖掘區塊 #100,000。這些礦工可以選擇在其候選區塊 #100,000 中包含任何有效交易（尚未被挖掘）。他們不必用相同的交易重新挖掘區塊。事實上，他們有動機選擇最有利可圖的（每 kB 最高手續費）交易包含在其區塊中。他們可以包含「舊」區塊 #100,000 中的任何交易，以及當前記憶池中的任何交易。本質上，當他們重新創建區塊 #100,000 時，他們可以選擇將交易從「現在」拉到重寫的「過去」。

今天，這種攻擊不是非常有利可圖，因為區塊補貼遠高於每個區塊的總手續費。但在未來的某個時候，交易手續費將佔獎勵的大部分（甚至是全部獎勵）。那時，這種情況變得不可避免。

幾個錢包透過創建帶有鎖定時間的交易來阻止手續費狙擊，該鎖定時間將這些交易限制為僅包含在下一個區塊或任何後續區塊中。在我們的情境中，我們的錢包會將其創建的任何交易的鎖定時間設定為 100,001。在正常情況下，此鎖定時間沒有效果——無論如何，交易只能包含在區塊 #100,001 中；這是下一個區塊。

但在重組攻擊下，礦工將無法從記憶池中提取高手續費交易，因為所有這些交易都將被時間鎖定到區塊 #100,001。他們只能使用當時有效的任何交易重新挖掘區塊 #100,000，本質上沒有獲得新的手續費。

這並不能完全防止手續費狙擊，但在某些情況下確實使其獲利較少，並且可以在區塊補貼下降時幫助保持 Bitcoin 網路的穩定性。我們建議所有錢包在不干擾錢包對鎖定時間欄位的其他使用時實現反手續費狙擊。

隨著 Bitcoin 繼續成熟，隨著補貼繼續下降，手續費對 Bitcoin 使用者變得越來越重要，無論是在他們日常使用中快速確認交易，還是在為礦工提供繼續用新的工作量證明保護 Bitcoin 交易的動機方面。

儘管Bitcoin P2P 網路中的完整節點（對等節點）彼此平等，但它們可能根據其支援的功能承擔不同的角色。Bitcoin 完整節點驗證區塊，並可能包含其他功能，例如路由、挖礦和錢包服務。

一些稱為_存檔完整節點_的節點也維護區塊鏈的完整和最新副本。這些節點可以向僅儲存區塊鏈子集並使用一種稱為_簡化支付驗證_（SPV）的方法部分驗證交易的客戶端提供資料。這些客戶端被稱為輕量級客戶端。

礦工透過執行專用硬體來解決工作量證明演算法，以競爭創建新區塊。一些礦工經營完整節點，驗證區塊鏈上的每個區塊，而其他礦工是參與礦池挖礦的客戶端，並依賴礦池伺服器為他們提供工作。

使用者錢包可能連接到使用者自己的完整節點，這在桌面 Bitcoin 客戶端中有時是這種情況，但許多使用者錢包，特別是那些在資源受限裝置（例如智慧型手機）上執行的錢包，是輕量級節點。

除了 Bitcoin P2P 協議上的主要節點類型之外，還有執行其他協議的伺服器和節點，例如專用的礦池協議和輕量級客戶端存取協議。

截至本文撰寫時，執行 Bitcoin P2P 協議的主要 Bitcoin 網路由大約 10,000 個監聽節點組成，這些節點執行各種版本的 Bitcoin Core，以及數百個節點執行 Bitcoin P2P 協議的其他各種實現，例如 BitcoinJ、btcd 和 bcoin。Bitcoin P2P 網路上的一小部分節點也是挖礦節點。各種個人和公司透過執行存檔完整節點與 Bitcoin 網路介接，具有區塊鏈的完整副本和網路節點，但沒有挖礦或錢包功能。這些節點充當網路邊緣路由器，允許在其上建立各種其他服務（交易所、錢包、區塊瀏覽器、商家支付處理）。

儘管緊湊區塊在最小化區塊在網路中傳播所需的時間方面大有幫助，但可以進一步最小化延遲。然而，與緊湊區塊不同，其他解決方案涉及權衡，使它們無法用於或不適合公共 P2P 中繼網路。因此，人們對區塊的私有中繼網路進行了實驗。

一種簡單的技術是預先選擇端點之間的路由。例如，在靠近主要跨洋光纖線路的資料中心執行伺服器的中繼網路可能能夠比等待區塊到達距離光纖線路數公里的某個家庭使用者執行的節點更快地轉發新區塊。

另一種更複雜的技術是前向錯誤更正（FEC）。這允許將緊湊區塊訊息拆分為幾個部分，每個部分都附加了額外的資料。如果其中任何部分未收到，則可以從收到的部分重建該部分。根據設定，如果遺失，最多可以重建幾個部分。

FEC 避免了由於底層網路連接問題而導致緊湊區塊（或其某些部分）未到達的問題。這些問題經常發生，但我們通常不會注意到它們，因為我們主要使用自動重新請求遺失資料的協議。但是，請求遺失的資料會使接收時間增加三倍。例如：

第三種技術是假設所有接收資料的節點在其記憶池中幾乎擁有所有相同的交易，因此它們都可以接受相同的緊湊區塊。這不僅可以節省我們在每跳計算緊湊區塊的時間，而且意味著每跳都可以在驗證之前簡單地將 FEC 封包中繼到下一跳。

前面每種方法的權衡是它們在中心化情況下運作良好，但在去中心化網路中（個別節點無法信任其他節點）則不然。資料中心的伺服器需要花錢，並且通常可以由資料中心的營運商存取，使它們比安全的家用電腦更不可信。在驗證之前中繼資料很容易浪費頻寬，因此只能在私有網路上合理使用，在該網路中各方之間存在一定程度的信任和問責。

開發人員 Matt Corallo 於 2015 年創建了原始的 Bitcoin Relay Network，以實現礦工之間以非常低的延遲快速同步區塊。該網路由託管在世界各地基礎設施上的幾個虛擬私有伺服器（VPS）組成，並用於連接大多數礦工和礦池。

2016 年，隨著("快速網際網路比特幣中繼引擎（FIBRE）"_快速網際網路比特幣中繼引擎_或 FIBRE 的引入，原始的 Bitcoin Relay Network 被取代，該引擎也由開發人員 Matt Corallo 創建。FIBRE 是允許操作基於 UDP 的中繼網路的軟體，該網路在節點網路內中繼區塊。FIBRE 實現了 FEC 和_緊湊區塊_優化，以進一步減少傳輸的資料量和網路延遲。

當新節點啟動時，它必須發現網路上的其他 Bitcoin 節點才能參與。要開始此過程，新節點必須發現網路上至少一個現有節點並連接到它。其他節點的地理位置無關；Bitcoin 網路拓撲沒有地理定義。因此，可以隨機選擇任何現有的 Bitcoin 節點。

要連接到已知的對等節點，節點會建立 TCP 連接，通常連接到埠 8333（通常稱為 Bitcoin 使用的埠），或者如果提供了替代埠，則連接到替代埠。建立連接後，節點將透過傳輸 version 訊息來啟動「握手」（請參見 對等節點之間的初始握手。），該訊息包含基本識別資訊，包括：

version 訊息始終是任何對等節點向另一個對等節點發送的第一條訊息。接收 version 訊息的本地對等節點將檢查遠端對等節點報告的 Version，並決定遠端對等節點是否相容。如果遠端對等節點相容，本地對等節點將確認 version 訊息並透過發送 verack 建立連接。

或者，對網路一無所知的引導節點必須獲得至少一個 Bitcoin 節點的 IP 位址，之後它可以透過進一步的介紹建立連接。命令列參數 -seednode 可用於連接到一個節點，僅將其用作種子進行介紹。在使用初始種子節點進行介紹後，客戶端將與其斷開連接並使用新發現的對等節點。

建立一個或多個連接後，新節點將向其鄰居發送包含其自己 IP 位址的 addr 訊息。鄰居將依次將 addr 訊息轉發給他們的鄰居，確保新連接的節點廣為人知並更好地連接。此外，新連接的節點可以向其鄰居發送 getaddr，要求他們返回其他對等節點的 IP 位址列表。這樣，節點可以找到要連接的對等節點，並在網路上宣傳其存在，以便其他節點找到它。位址傳播和發現。 顯示了位址發現協議。

節點必須連接到幾個不同的對等節點，以便建立到 Bitcoin 網路的多樣化路徑。路徑不可靠——節點來來去去——因此節點必須在失去舊連接時繼續發現新節點，並在其他節點引導時協助它們。只需要一個連接即可引導，因為第一個節點可以向其對等節點提供介紹，並且這些對等節點可以提供進一步的介紹。連接到超過少數幾個節點也是不必要的，並且會浪費網路資源。引導後，節點將記住其最近成功的對等連接，以便如果它重新啟動，它可以快速與其先前的對等網路重新建立連接。如果先前的對等節點都沒有回應其連接請求，該節點可以再次使用種子節點進行引導。

在執行 Bitcoin Core 客戶端的節點上，您可以使用命令 getpeerinfo 列出對等連接：

要覆寫對等節點的自動管理並指定 IP 位址列表，使用者可以提供選項 -connect=<IPAddress> 並指定一個或多個 IP 位址。如果使用此選項，節點將僅連接到選定的 IP 位址，而不是自動發現和維護對等連接。

如果連接上沒有流量，節點將定期發送訊息以維護連接。如果節點在連接上長時間沒有通訊，則假定它已斷開連接，並將尋找新的對等節點。因此，網路動態地適應暫時的節點和網路問題，並可以根據需要有機地成長和收縮，無需任何中心控制。

完整節點是在具有最多工作量證明的有效區塊鏈上驗證每個區塊中每筆交易的節點。

完整節點獨立處理每個區塊，從第一個區塊（創世區塊）之後開始，一直建立到網路中最新的已知區塊。完整節點可以獨立且權威地驗證任何交易。完整節點依賴網路接收有關新交易區塊的更新，然後驗證這些更新並將其納入其本地視圖中，了解哪些腳本控制哪些比特幣，稱為("UTXO（未花費交易輸出）"未花費交易輸出（UTXO）集。

執行完整節點為您提供純粹的 Bitcoin 體驗：獨立驗證所有交易，無需依賴或信任任何其他系統。

有一些完整節點的替代實現，使用不同的程式語言和軟體架構構建，或者做出了不同的設計決策。但是，最常見的實現是 Bitcoin Core。Bitcoin 網路上超過 95% 的完整節點執行各種版本的 Bitcoin Core。它在 version 訊息中發送的子版本字串中被識別為「Satoshi」，並由命令 getpeerinfo 顯示，如我們之前看到的；例如，/Satoshi:24.0.1/。

完整節點連接到對等節點後首先要做的事情是嘗試構建完整的區塊標頭鏈。如果它是一個全新的節點，並且根本沒有區塊鏈，它只知道一個區塊，即創世區塊，該區塊靜態嵌入在客戶端軟體中。從區塊 #0（創世區塊）之後開始，新節點將必須下載數十萬個區塊才能與網路同步並重新建立完整的區塊鏈。

同步區塊鏈的過程從 version 訊息開始，因為該訊息包含 BestHeight，即節點的當前區塊鏈高度（區塊數）。節點將看到來自其對等節點的 version 訊息，知道它們各自擁有多少個區塊，並能夠與它自己的區塊鏈中擁有的區塊數進行比較。對等節點將交換 getheaders 訊息，該訊息包含其本地區塊鏈頂部區塊的雜湊。其中一個對等節點將能夠將接收到的雜湊識別為屬於不在頂部的區塊，而是屬於較舊的區塊，從而推斷其自己的本地區塊鏈比遠端節點的區塊鏈長。

擁有較長區塊鏈的對等節點比另一個節點擁有更多的區塊，並且可以識別另一個節點需要哪些標頭才能「趕上」。它將使用 headers 訊息識別要共享的前 2,000 個標頭。節點將繼續請求額外的標頭，直到它收到遠端對等節點聲稱擁有的每個區塊的標頭。

同時，節點將開始使用 getdata 訊息請求先前收到的每個標頭的區塊。節點將從其每個選定的對等節點請求不同的區塊，這使它能夠斷開與明顯慢於平均速度的對等節點的連接，以便找到較新（可能更快）的對等節點。

例如，假設一個節點只有創世區塊。然後，它將從其對等節點接收 headers 訊息，其中包含鏈中接下來 2,000 個區塊的標頭。它將開始從所有連接的對等節點請求區塊，保持最多 1,024 個區塊的佇列。區塊需要按順序驗證，因此如果佇列中最舊的區塊——節點接下來需要驗證的區塊——尚未收到，節點會斷開與應該提供該區塊的對等節點的連接。然後，它會找到一個新的對等節點，該節點可能能夠在節點的所有其他對等節點能夠提供 1,023 個區塊之前提供一個區塊。

當收到每個區塊時，它會被添加到區塊鏈中，如我們將在 區塊鏈 中看到的。隨著本地區塊鏈逐漸建立，將請求和接收更多區塊，該過程將繼續，直到節點趕上網路的其餘部分。

這個將本地區塊鏈與對等節點進行比較並檢索任何遺失區塊的過程會在節點離線一段時間後發生。

許多Bitcoin 客戶端設計為在空間和功率受限的裝置上執行，例如智慧型手機、平板電腦或嵌入式系統。對於此類裝置，使用_簡化支付驗證_（SPV）方法，允許它們在不驗證完整區塊鏈的情況下運作。這些類型的客戶端稱為輕量級客戶端。

輕量級客戶端僅下載區塊標頭，不下載每個區塊中包含的交易。產生的標頭鏈（不包含交易）比完整區塊鏈小約 10,000 倍。輕量級客戶端無法構建可用於花費的所有 UTXO 的完整圖片，因為它們不知道網路上的所有交易。相反，它們使用稍微不同的方法驗證交易，該方法依賴於對等節點按需提供區塊鏈相關部分的部分視圖。

作為類比，完整節點就像一個陌生城市的遊客，配備了每條街道和每個地址的詳細地圖。相比之下，輕量級客戶端就像一個陌生城市的遊客，在只知道一條主要大道的情況下向隨機陌生人詢問逐轉彎指示。雖然兩位遊客都可以透過訪問街道來驗證街道的存在，但沒有地圖的遊客不知道任何小巷下有什麼，也不知道存在哪些其他街道。站在 23 Church Street 前面，沒有地圖的遊客無法知道城市中是否還有十幾個其他 「23 Church Street」地址，以及這是否是正確的地址。沒有地圖的遊客最好的機會是詢問足夠多的人，並希望其中一些人不是想搶劫他。

輕量級客戶端透過參考其在區塊鏈中的_深度_來驗證交易。完整節點將構建一個完全驗證的鏈，其中包含數千個區塊和數百萬筆交易，一直沿著區塊鏈向下（回到過去）到創世區塊，而輕量級客戶端將驗證所有區塊的工作量證明（但不驗證區塊及其所有交易是否有效），並將該鏈連結到感興趣的交易。

例如，在檢查區塊 800,000 中的交易時，完整節點會驗證從創世區塊到 800,000 的所有區塊，並建立完整的 UTXO 資料庫，透過確認交易存在且其輸出仍未花費來確立交易的有效性。輕量級客戶端只能驗證交易存在。客戶端使用 merkle 路徑（請參見 默克爾樹）在交易和包含它的區塊之間建立連結。然後，輕量級客戶端等待，直到它看到堆疊在包含該交易的區塊頂部的六個區塊 800,001 到 800,006，並透過在區塊 800,006 到 800,001 下建立其深度來驗證它。網路上其他節點接受了區塊 800,000，並且礦工完成了在其頂部產生另外六個區塊所需的工作這一事實，透過代理證明了交易實際存在。

通常無法說服輕量級客戶端交易存在於區塊中（當交易實際上不存在時）。輕量級客戶端透過請求 merkle 路徑證明並透過驗證區塊鏈中的工作量證明來確立交易在區塊中的存在。但是，交易的存在可以對輕量級客戶端「隱藏」。輕量級客戶端絕對可以驗證交易存在，但無法驗證交易（例如同一 UTXO 的雙重花費）不存在，因為它沒有所有交易的記錄。這個漏洞可用於針對輕量級客戶端的拒絕服務攻擊或雙重花費攻擊。為了防禦這一點，輕量級客戶端需要隨機連接到多個客戶端，以增加它與至少一個誠實節點接觸的機率。這種需要隨機連接意味著輕量級客戶端也容易受到網路分區攻擊或女巫攻擊，在這些攻擊中，它們連接到假節點或假網路，無法存取誠實節點或真實的 Bitcoin 網路。

對於許多實際目的，連接良好的輕量級客戶端足夠安全，在資源需求、實用性和安全性之間取得平衡。然而，對於萬無一失的安全性，沒有什麼比執行完整節點更好。

要獲取驗證交易是鏈的一部分所需的區塊標頭，輕量級客戶端使用 getheaders 訊息。回應的對等節點將使用單個 headers 訊息發送最多 2,000 個區塊標頭。請參見 輕量級客戶端同步區塊標頭。 中的插圖。

區塊標頭允許輕量級客戶端驗證任何單獨的區塊屬於具有最多工作量證明的區塊鏈，但它們不會告訴客戶端哪些區塊包含其錢包感興趣的交易。客戶端可以下載每個區塊並檢查，但這將使用執行完整節點所需資源的很大一部分，因此開發人員一直在尋找其他方法來解決這個問題。

在輕量級客戶端引入後不久，Bitcoin 開發人員添加了一個稱為_布隆過濾器_的功能，試圖減少輕量級客戶端了解其傳入和傳出交易所需使用的頻寬。布隆過濾器允許輕量級客戶端接收交易的子集，而無需直接準確地揭示它們感興趣的地址，透過使用機率而不是固定模式的過濾機制。

布隆過濾器是一種機率搜尋過濾器，是一種描述所需模式而無需精確指定它的方式。布隆過濾器提供了一種有效的方式來表達搜尋模式，同時保護隱私。它們被輕量級客戶端用來向其對等節點詢問與特定模式匹配的交易，而無需準確揭示它們正在搜尋哪些地址、金鑰或交易。

在我們之前的類比中，一個沒有地圖的遊客正在詢問前往特定地址「23 Church St.」的方向。如果他們向陌生人詢問前往這條街道的方向，他們就會無意中洩露了他們的目的地。布隆過濾器就像詢問「這個社區有沒有名稱以 R-C-H 結尾的街道？」這樣的問題比詢問「23 Church St.」洩露的目的地資訊稍微少一些。使用這種技術，遊客可以更詳細地指定所需地址，例如「以 U-R-C-H 結尾」，或者不那麼詳細，例如「以 H 結尾」。透過改變搜尋的精確度，遊客會以獲得更多或更少的特定結果為代價來洩露更多或更少的資訊。如果他們詢問一個不太特定的模式，他們會得到更多可能的地址和更好的隱私，但許多結果是不相關的。如果他們詢問一個非常特定的模式，他們會得到更少的結果，但失去隱私。

布隆過濾器透過允許輕量級客戶端為交易指定一個搜尋模式來實現此功能，該模式可以根據精確度或隱私進行調整。更特定的布隆過濾器將產生準確的結果，但代價是洩露輕量級客戶端感興趣的模式，從而洩露使用者錢包擁有的地址。不太特定的布隆過濾器將產生更多關於更多交易的資料，其中許多與客戶端無關，但將允許客戶端維持更好的隱私。