Bitcoin Core

CVE-2024-52911 - Script Interpreter Remote Crash

Tue, 05 May 2026 00:00:00 +0000

After Bitcoin Core 0.14.0 and before Bitcoin Core 29.0, validating a specially-crafted block may cause the node to access previously freed memory.

During validation, necessary data required for checking inputs for each transaction is pre-calculated and cached. For specially crafted invalid blocks, it was possible for this data to be destroyed while it was still being accessed by a background validation thread. An attacker capable of mining a block with sufficient proof-of-work could have exploited this to crash victim nodes. Because of the nature of use-after-free bugs, it is possible that the crash could have been used for remote code execution, though constraints on the input (block) data make this unlikely.

This issue is considered High severity.

Details

By default, script validation for new blocks is dispatched to background threads via a vector of CScriptCheck functors. Each CScriptCheck holds a pointer to a PrecomputedTransactionData object which stores some data needed by each input in the transaction. Because it stores a pointer and not the data itself, care must be taken to ensure that the PrecomputedTransactionData outlives the CScriptCheck.

The script checks lifetime is enforced by an RAII class, CCheckQueueControl. However, the control is intantiated before the precomputed transaction data. Because local objects in C++ are destructed in reverse order of construction, this means the vector of PrecomputedTransactionData is destroyed before the CCheckQueueControl.

This is not an issue when the block is valid, as CCheckQueueControl::Wait() will be called before the function returns and the PrecomputedTransactionData gets destroyed. However, in case of an early return (when a separate check fails) a background script thread may read the precomputed transaction data after it was destroyed. An attacker could exploit this to crash victim nodes at the expense of a valid PoW at tip.

Attribution

Cory Fields (MIT DCI) discovered this vulnerability and responsibly disclosed it in a detailed report containing a proof of concept for reproduction and a proposed mitigation.

Timeline

2024-11-02 Cory Fields privately reports the bug
2024-11-06 Pieter Wuille pushes a covert fix to already open PR #31112 which works around the issue by removing the early returns
2024-12-03 PR #31112 is merged
2025-04-12 Bitcoin Core version 29.0 is released with a fix
2026-04-19 The last vulnerable Bitcoin Core version (28.x) goes end of life
2026-05-05 Public disclosure.

CVE-2025-46597 - Highly unlikely remote crash on 32-bit systems

Fri, 24 Oct 2025 00:00:00 +0000

Disclosure of the details of a bug on 32-bit systems which may, in a rare edge case, cause the node to crash when receiving a pathological block. This bug would be extremely hard to exploit. A fix was released on October 10th 2025 in Bitcoin Core v30.0.

This issue is considered Low severity.

Details

Before writing a block to disk, Bitcoin Core checks that its size is within a normal range. This check would overflow on 32-bit systems for blocks over 1GB, and make the node crash when writing it to disk. Such a block cannot be sent using the BLOCK message, but could in theory be sent as a compact block if the victim node has a non-default large mempool which already contains 1GB of transactions. This would require the victim to have set their -maxmempool option to a value greater than 3GB, while 32-bit systems may have at most 4GiB of memory.

This issue was indirectly prevented by capping the maximum value of the -maxmempool setting on 32-bit systems.

Attribution

Pieter Wuille discovered this bug and disclosed it responsibly.

Antoine Poinsot proposed and implemented a covert mitigation.

Timeline

2025-04-24 - Pieter Wuille reports the issue
2025-05-16 - Antoine Poinsot opens PR #32530 with a covert fix
2025-06-26 - PR #32530 is merged into master
2025-09-04 - Version 29.1 is released with the fix
2025-10-10 - Version 30.0 is released with the fix
2025-10-24 - Public Disclosure

CVE-2025-46598 - CPU DoS from unconfirmed transaction processing

Fri, 24 Oct 2025 00:00:00 +0000

Disclosure of the details of a resource exhaustion issue when processing an unconfirmed transaction. A fix was released on October 10th 2025 in Bitcoin Core v30.0.

This issue is considered Low severity.

Details

An attacker could send specially-crafted unconfirmed transactions that would take a victim node a few seconds each to validate. The non-standard transactions would be rejected but not lead to a disconnection and the process could be repeated. This could be exploited to delay block propagation.

The issue was mitigated in multiple steps by reducing the validation time in different Script contexts.

Attribution

Antoine Poinsot reported this issue to the Bitcoin Core security mailing list.

Pieter Wuille, Anthony Towns and Antoine Poinsot implemented mitigations to reduce the worst case validation time of unconfirmed transactions.

Timeline

2025-04-25 - Antoine Poinsot reports the issue
2025-05-12 - Pieter Wuille opens PR #32473 to mitigate the worst case quadratic signature hashing in legacy Script context
2025-07-24 - Anthony Towns opens PR #33050 to mitigate the worst case hashing in Tapscript context
2025-07-30 - Antoine Poinsot opens PR #33105 to further mitigate the worst case in legacy Script context
2025-08-08 - PR #33105 is merged into master
2025-08-11 - PR #32473 is merged into master
2025-08-12 - PR #33050 is merged into master
2025-10-10 - Version 30.0 is released with the mitigations
2025-10-24 - Public Disclosure

CVE-2025-54604 - Disk filling from spoofed self connections

Fri, 24 Oct 2025 00:00:00 +0000

Disclosure of the details of a log-filling bug which allowed an attacker to fill up the disk space of a victim node by faking self-connections. Exploitability of this bug is limited, and it would take a long time before it would cause the victim to run out of disk space. A fix was released on October 10th 2025 in Bitcoin Core v30.0.

This issue is considered Low severity.

Details

Bitcoin Core would unconditionally log in case of self-connection. This could be exploited by an attacker by waiting for a victim to connect to it and reusing the version message nonce to establish many connections to the victim, causing it to detect those attempts as self-connections. However, exploitability is limited because the initial connection from the victim will timeout after 60 seconds by default.

This issue was fixed by implementing log rate-limiting across the board, also preventing future issues of the same type from happening.

Attribution

Niklas Goegge discovered this bug and disclosed it responsibly.

Eugene Siegel and Niklas Goegge worked on a fix mitigating all types of log-filling attacks.

Credits also to contributor “practicalswift” who previously raised concerns about disk-filling vectors in Bitcoin Core and worked to address them.

Timeline

2022-03-16 - Niklas Goegge reports this issue to the Bitcoin Core security mailing list
2025-05-23 - Eugene Siegel opens PR #32604 to introduce log rate-limiting, based on earlier work from Niklas Goegge
2025-07-09 - PR #32604 is merged into master
2025-09-04 - Version 29.1 is released with the fix
2025-10-10 - Version 30.0 is released with the fix
2025-10-24 - Public Disclosure

CVE-2025-54605 - Disk filling from invalid blocks

Fri, 24 Oct 2025 00:00:00 +0000

Disclosure of the details of a log-filling bug which allowed an attacker to cause a victim node to fill up its disk space by repeatedly sending invalid blocks. Exploitability of this bug is limited, as it would take a long time before it would cause the victim to run out of disk space. A fix was released on October 10th 2025 in Bitcoin Core v30.0.

This issue is considered Low severity.

Details

A node would unconditionally log when receiving a block that fails basic sanity checks, or when receiving a block that branches off prior to the last checkpoint. By repeatedly sending such an invalid block to a victim node, an attacker could cause the victim to run out of disk space.

This issue was fixed by implementing log rate-limiting across the board, also preventing future issues of the same type from happening.

Attribution

Niklas Goegge discovered this bug and disclosed it responsibly. Eugene Siegel independently re-discovered this bug and disclosed it responsibly.

Eugene Siegel and Niklas Goegge worked on a fix mitigating all types of log-filling attacks.

Credits also to contributor “practicalswift” who previously raised concerns about disk-filling vectors in Bitcoin Core and worked to address them.

Timeline

2022-05-16 - Niklas Goegge reports this issue to the Bitcoin Core security mailing list
2025-03-13 - Eugene Siegel reports this issue to the Bitcoin Core security mailing list
2025-04-24 - Eugene Siegel reports to the security mailing list about his research on the worst case disk filling rate.
2025-05-23 - Eugene Siegel opens PR #32604 to introduce log rate-limiting, based on earlier work from Niklas Goegge
2025-07-09 - PR #32604 is merged into master
2025-09-04 - Version 29.1 is released with the fix
2025-10-10 - Version 30.0 is released with the fix
2025-10-24 - Public Disclosure

Bitcoin Core 28.3 版本發布

Fri, 17 Oct 2025 00:00:00 +0000

Bitcoin Core 28.3 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 29.2 版本發布

Tue, 14 Oct 2025 00:00:00 +0000

Bitcoin Core 29.2 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 30.0 版本發布

Fri, 10 Oct 2025 00:00:00 +0000

Bitcoin Core 30.0 版本現已可供下載。請參閱版本說明以了解此版本中的新功能和其他變更。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 29.1 版本發布

Thu, 04 Sep 2025 00:00:00 +0000

Bitcoin Core 29.1 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 28.2 版本發布

Thu, 26 Jun 2025 00:00:00 +0000

Bitcoin Core 28.2 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 開發和交易中繼策略

Fri, 06 Jun 2025 00:00:00 +0000

我們想分享我們對 Bitcoin Core 開發與網路上交易中繼策略之間關係的看法。

Bitcoin 是一個由其使用者定義的網路，他們在選擇使用什麼軟體（完全驗證或非完全驗證）和實作他們想要的任何策略方面擁有最終自由。Bitcoin Core 貢獻者無權規定這些策略是什麼。這反映在我們長期以來避免在軟體中自動更新的做法中。這意味著沒有任何實體可以單方面向 Bitcoin Core 使用者推送變更：變更必須由使用者自己選擇採用新的軟體版本，或者如果他們願意，採用不同的軟體。自由執行任何軟體是網路對抗強制的主要保障。

作為 Bitcoin Core 開發者，我們也認為我們有責任使我們的軟體盡可能有效和可靠地為其目的服務，即在 Bitcoin 點對點網路中驗證和中繼區塊和交易，以便 Bitcoin 作為去中心化數位貨幣取得成功。關於交易中繼，這可能包括新增阻斷服務（DoS）保護和手續費評估的策略，但不會阻止中繼有持續經濟需求且可靠地進入區塊的交易。交易中繼的目標包括：

預測將被挖掘的交易（例如用於手續費估算或手續費提升，但它也是節點軟體內許多 DoS 保護策略的基礎）；
加快我們預期被挖掘的交易的區塊傳播。減少延遲有助於防止大型礦工獲得不公平的優勢；
幫助礦工了解付費交易（這樣他們就不需要依賴破壞挖礦去中心化的頻外交易提交方案）。

明知拒絕中繼礦工無論如何都會包含在區塊中的交易會迫使使用者進入替代通訊管道，破壞上述目標。

交易接受規則過去曾被有效地用於阻止使用區塊空間效率低下的用例的開發，而這樣做非常便宜。然而，這只有在使用者和礦工都對存在的任何替代方案感到滿意時才能有效。當情況不再如此，並且開發出與策略規則衝突的經濟上可行的用例時，使用者和礦工可以直接合作以避免對其活動施加限制的任何外部嘗試。事實上，能夠做到這一點是 Bitcoin 抗審查性的一個重要方面，具有優先對等的其他節點軟體也表明，規避絕大多數節點的過濾器相對容易。鑑於此，我們認為 Bitcoin 節點軟體最好旨在對下一個區塊中最終會包含什麼有一個現實的想法，而不是試圖在同意的交易建立者和礦工之間進行干預，以阻止在技術層面上基本無害的活動。

這不是認可或容忍非金融資料使用，而是接受作為抗審查系統，Bitcoin 可以而且將被用於不是每個人都同意的用例。

雖然我們認識到這一觀點並非所有使用者和開發者普遍持有，但我們真誠地相信這符合 Bitcoin 及其使用者的最佳利益，我們希望我們的使用者同意。我們將繼續作為開發者應用我們的最佳判斷，使交易接受規則與 Bitcoin 的長期健康和礦工的理性自利保持一致，包括特定的技術原因，例如升級安全性、高效的區塊建構和節點 DoS 攻擊。

簽署，

（支援此信的貢獻者列表）

Andrew Toth
Antoine Poinsot
Anthony Towns
Ava Chow
b10c
Bruno Garcia
David Gumberg
fjahr
Gloria Zhao
Gregory Sanders
hodlinator
ismaelsadeeq
Josie Baker
kevkevinpal
l0rinc
Marco De Leon
Martin Zumsande
Matthew Zipkin
Michael Ford
Murch
Niklas Gögge
pablomartin4btc
Pieter Wuille
Pol Espinasa
Sebastian Falbesoner
Sergi Delgado
Stephan Vuylsteke
TheCharlatan
Vasil Dimov
Will Clark
w0xlt

CVE-2024-52919 - Remote crash due to addr message spam (part 2)

Mon, 28 Apr 2025 00:00:00 +0000

Disclosure of the details of an integer overflow bug which causes a crash if a node is getting spammed addr messages continuously for a very long time (years). A fix was released on April 14th 2025 in Bitcoin Core v29.0.

This issue is considered Low severity.

Details

The address manager in Bitcoin Core uses a 32-bit identifier for each entry, incremented on every insertion. An earlier security advisory explained how it enabled an attacker to remotely trigger an assertion failure by spamming a node with addr messages until the 32-bit identifier overflow.

This was partially addressed in Bitcoin Core v22.0 by rate-limiting insertions in the address manager to 1 address per peer every 10 seconds. This made the attack a lot more expensive if not impractical: even with 1000 peers continuously attacking it would still take more than a year to get the 32-bit identifier to overflow.

The remaining, more expensive attack vector was addressed in Bitcoin Core version 29.0 by making the identifier a 64-bit identifier.

Attribution

Credit goes to Eugene Siegel for discovering and disclosing the vulnerability, and to Martin Zumsande for changing the identifier to 64-bit.

Timeline

2021-06-21 - Initial report sent to security@bitcoincore.org by Eugene Siegel
2021-07-19 - Rate limiting is merged in PR #22387
2021-09-13 - v22.0 is released with rate-limiting
2024-07-31 - Publication of the first security advisory
2024-09-20 - Change to 64-bit identifier is merged in PR #30568
2025-04-14 - Bitcoin Core v29.0 is released with the 64-bit identifier
2025-04-28 - Public Disclosure

Bitcoin Core 29.0 版本發布

Mon, 14 Apr 2025 00:00:00 +0000

Bitcoin Core 29.0 版本現已可供下載。請參閱版本說明以了解此版本中的新功能和其他變更。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 28.1 版本發布

Thu, 09 Jan 2025 00:00:00 +0000

Bitcoin Core 28.1 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

CVE-2024-52922 - Hindered block propagation due to stalling peers

Tue, 05 Nov 2024 00:00:00 +0000

Before Bitcoin Core v25.1, an attacker can cause a node to not download the latest block.

This issue is considered Medium severity.

Details

When receiving a new block announcement via a headers or compact blocks message, the delivering peer is requested either the full block or missing transaction details by the receiving node. If the announcing peer then doesn’t respond as the peer to peer protocol requires, the affected Bitcoin Core node will wait up to 10 minutes before disconnecting the peer and making another block download attempt. If the attacker is able to make multiple incoming or outgoing connections, this process can be repeated.

Delaying block delivery can cause network degradation by slowing down network convergence, making mining payouts less fair, and causing liveliness issues.

This issue was further exacerbated by other issues disclosed recently (for instance the inventory build-up), when mempools were relatively heterogeneous, disallowing opportunistic reconstruction of compact blocks by honest peers.

A mitigation was introduced in #27626, introduced in Bitcoin Core v26.0 and backported to v25.1. It ensures that blocks can be requested concurrently from up to 3 high-bandwidth compact block peers, one of which is required to be an outbound connection.

Attribution

Reported and fixed by Greg Sanders.

Timeline

2023-05-08 - Users reporting block timeouts in the #bitcoin-core-dev IRC channel
2023-05-09 - First github issues describing the issue https://github.com/bitcoin/bitcoin/issues/25258#issuecomment-1540028533
2023-05-11 - Mitigation PR opened https://github.com/bitcoin/bitcoin/pull/27626
2023-05-24 - PR merged prior to Bitcoin Core v26.0
2023-05-25 - Backport to Bitcoin Core v25.1 merged https://github.com/bitcoin/bitcoin/pull/27752
2023-10-19 - Bitcoin Core v25.1 Released
2024-11-05 - Public disclosure

Bitcoin Core 27.2 版本發布

Mon, 04 Nov 2024 00:00:00 +0000

Bitcoin Core 27.2 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Disclosure of CVE-2024-35202

Tue, 08 Oct 2024 00:00:00 +0000

Before Bitcoin Core v25.0, an attacker could remotely crash Bitcoin Core nodes by triggering an assertion in the blocktxn message handling logic.

This issue is considered High severity.

Details

When receiving a block announcement via a cmpctblock message, Bitcoin Core attempts to reconstruct the announced block using the transactions in its own mempool as well as other available transactions. If reconstruction fails due to missing transactions it will request them from the announcing peer via a getblocktxn message. In response a blocktxn message is expected, which should contain the requested transactions.

The compact block protocol employs shortened transaction identifiers to reduce bandwidth. These short-ids are 6 byte in size, resulting in a small chance for collisions (i.e. transaction A has the same short-id as transaction B) upon block reconstruction. Collisions will be detected as the merkle root computed from the reconstructed set of transactions will not match the merkle root from the block announcement. Peers should not be punished for collisions as they may happen spuriously, therefore they are handled by falling back to requesting the full block.

Bitcoin Core will create an instance of PartiallyDownloadedBlock whenever a new compact block is received. If missing transactions are requested, the instance is persisted until the corresponding blocktxn message is processed. Upon receiving the blocktxn message, PartiallyDownloadedBlock::FillBlock is called, attempting to reconstruct the full block. In the collision case described above, the full block is requested but the PartiallyDownloadedBlock instance as well as the other state related to the underlying block request is left untouched. This leaves room for a second blocktxn message for the same block to be processed and trigger FillBlock to be called again. This violates the assumption (documented as an assert statement) that FillBlock can only be called once and causes the node to crash.

An attacker does not need to get lucky by triggering a collision, as the collision handling logic can easily be triggered by simply including transactions in the blocktxn message that are not committed to in the block’s merkle root.

Attribution

Credit goes to Niklas Gögge for discovering and disclosing the vulnerability, as well as fixing the issue in https://github.com/bitcoin/bitcoin/pull/26898.

Timeline

2022-10-05 - Niklas Gögge reports the issue to the Bitcoin Core security mailing list.
2023-01-24 - PR #26898 containing the fix is merged.
2023-05-25 - Bitcoin Core 25.0 is released with the fix.
2024-10-09 - Public disclosure.

Disclosure of DoS due to inv-to-send sets growing too large

Tue, 08 Oct 2024 00:00:00 +0000

Before Bitcoin Core v25.0, the per-peer m_tx_inventory_to_send sets could grow too large to a point where sorting these sets when constructing inventory messages would affect the node’s ability to communicate with its peers. Network conditions in early May 2023 triggered this DoS and affected block and transaction propagation.

This issue is considered Medium severity.

Details

As part of transaction relay, Bitcoin Core maintains a per-peer m_tx_inventory_to_send set with transactions that should be announced to the peer. When constructing an inventory message for a peer, the set is sorted by transaction dependencies and feerate to prioritize high-feerate transactions and to avoid leaking the order the node learned about the transactions. Before Bitcoin Core v25.0, when constructing inventory messages, relevant (still in mempool, not yet announced to us by the peer, above the fee filter) transactions were being drained at a rate of 7 transactions per second.

In early May 2023, increased network activity caused the sets to grow faster than they were being drained resulting in significant time spent sorting the sets in the P2P communication thread. Additionally, peers that only listen for transaction announcements but never announce any themselves (commonly referred to as “spy nodes”), amplified this by having huge sets (with transactions they already know about) that take a long time to sort. It was observed that sorting took up nearly the complete time spent in the P2P communication thread, which significantly affected block and transaction propagation as well as keeping connection with peers alive.

This was fixed in #27610 by 1) earlier removing transactions that aren’t in the mempool anymore and 2) by dynamically increasing the set drainage rate depending on the set size.

Attribution

Credit goes to Anthony Towns for working on a fix and to b10c for initially reporting and narrowing the problem down to the slow inv-to-send sorting.

Timeline

2023-05-02 - Problem first observed and reported
2023-05-11 - Fix is merged (#27610)
2023-05-25 - v25.0 is released
2024-10-09 - Public disclosure

CVE-2024-52921 - Hindered block propagation due to mutated blocks

Tue, 08 Oct 2024 00:00:00 +0000

Before Bitcoin Core v25.0, a peer sending mutated blocks could clear the download state of other peers that also announced the block to us, which would hinder block propagation.

This issue is considered Medium severity.

Details

Bitcoin Core treats a block as mutated when, for example, the Merkle root in the header or the witness commitment in the coinbase transaction doesn’t match the transactions in the block.

Before Bitcoin Core v25.0, a peer could clear the block download state of other peers by sending an unrequested mutated block. This was a problem for, for example, compact block relay. After receiving a compact block and while waiting for a response to a getblocktxn request to reconstruct the full block, receiving the mutated block would let Bitcoin Core forget about the compact block reconstruction state. A blocktxn response arriving after the mutated block couldn’t be used to reconstruct the block. This hindered block propagation.

This was fixed in #27608 by making sure that a peer can only affect its own block download state and not the download state of other peers.

Attribution

Credit goes to Suhas Daftuar for noticing the problem and working on a fix.

Timeline

2023-05-08 - A problem with mutated blocks is first reported in the #bitcoin-core-dev IRC channel.
2023-05-10 - Fix is merged (#27608)
2023-05-25 - v25.0 is released
2024-10-09 - Public disclosure

Bitcoin Core 28.0 版本發布

Wed, 02 Oct 2024 00:00:00 +0000

Bitcoin Core 28.0 版本現已可供下載。請參閱版本說明以了解此版本中的新功能和其他變更。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

CVE-2019-25220 - Memory DoS due to headers spam

Wed, 18 Sep 2024 00:00:00 +0000

Before Bitcoin Core v24.0.1, attackers could spam nodes with low-difficulty headers chains, which could be used to remotely crash peers.

This issue is considered High severity.

Details

Bitcoin Core stores the blockchain headers in memory. This makes it susceptible to being DoSed, by having it download and store extremely long chains of headers, even if they are of low difficulty. It is important to note that once crafted, an attack chain could be reused to crash any node on the network.

The possibility of using this to attack nodes has long been known, and was the primary reason why the checkpoint system was still in place: making an attacker start an attack at the last checkpoint makes it far more costly than starting at the genesis block. However, over time, with decreasing hashrate costs, even this mitigation became less effective.

This attack was independently discovered and reported to the Bitcoin Core project in January 2019 by David Jaenson, who suggested introducing newer checkpoints as a practical mitigation. However:

This still leaves nodes performing IBD with no protection before they receive checkpoint blocks.
It relies on the ecosystem semi-regularly adopting updated software with new checkpoints, a practice which Bitcoin Core contributors have long been uncomfortable with.

It later got increased attention when Braydon Fuller posted his “Chain width expansion” writeup to the bitcoin-dev mailing list in October 2019. He had previously responsibly reported it to the Bitcoin Core security list. The suggested approach was not adopted in Bitcoin Core due to concerns about network convergence when limiting the number of parallel chains.

At the time, the computational cost of creating a huge low-difficulty headers chain was equal to about 32.28% of mining one block at the tip. That is a cost of about 4.12 BTC since the block reward then was about 12.77 BTC.

By February 2022, the cost of the attack had dropped further to around 14.73% of the cost of mining a block, and this prompted investigation of alternative solutions. If unaddressed, the cost today (September 2024) would just be 4.44% of a block. These figures translate to a cost of about 1.07 BTC and 0.14 BTC respectively, given the block reward at these dates.

A protection against this DoS was implemented in Bitcoin Core PR #25717, whereby the node will first verify a presented chain has enough work before committing to store it. With that, Bitcoin Core no longer relies on having checkpoints to protect against any known attacks.

Attribution

Credit goes to David Jaenson and Braydon Fuller for independently re-discovering the attack, estimating its cost and suggesting modifications.

Credit goes to Suhas Daftuar and Pieter Wuille for researching a satisfying fix and implementing it.

Timeline

2010-07-17 - Bitcoin 0.3.2 is released, which introduces checkpoints. They protect among other things against low-difficulty block spam.
2011-11-21 - Bitcoin 0.5.0 is released, which skips script validation for blocks before the last checkpoint. This makes the role of checkpoints even more security-critical.
2014-04-09 - Block 295000 is mined, which becomes the last Bitcoin Core checkpoint. The protection offered by checkpoints against block spam starts eroding from this point on as hashrate costs decrease.
2015-02-16 - Bitcoin Core 0.10.0 is released, with headers-first synchronization. This weakens the low-difficulty block spam attack to a block header spam attack.
2017-03-08 - Bitcoin Core 0.14.0 is released, which disentangles the skipping of script validation from checkpoints, leaving them only relevant for protecting against block header spam.
2019-01-28 - David Jaenson reports this issue to the Bitcoin Core security mailing list.
2019-09-18 - Braydon Fuller emails the Bitcoin Core security list with a paper titled “Bitcoin Chain Width Expansion Denial-of-Service Attacks”, which discusses the dangers of block and block header spam, a cost analysis, and a proposed solution.
2019-09-26 - Suhas Daftuar replies to Braydon Fuller that it’s a known issue, and invites him to post his writeup to the bitcoin-dev mailing list.
2019-10-04 - Braydon Fuller sends his paper to the bitcoin-dev mailing list.
2019-10-31 - In response to the above events, Suhas Daftuar opens PR #17332 with an earlier but impractical proof of concept he worked on to improve the situation, with the hope of causing more discussion on the topic.
2022-02 - Suhas Daftuar and Pieter Wuille discuss this issue and estimate that the cost of this attack has now actually become so low that it warrants immediate action, and the need to avoid talking about it publicly.
2022-06-22 - Suhas Daftuar opens PR #25454 as preparatory work toward implementing a fix.
2022-06-22 - Suhas Daftuar messages a group of long-term contributors detailing the attack, its cost and the fix Pieter Wuille and him have been working on.
2022-07-26 - Suhas Daftuar opens PR #25717, co-authored with Pieter Wuille, which implements the fix.
2022-08-30 - PR #25717 is merged.
2022-10-21 - Niklas Gögge’s PR #26355 is merged, which fixes a bug in the headers pre-synchronization step that was introduced in PR #25717. Without this, it would still have been possible to spam block headers. The discovery of this bug, and the possibility of potential undiscovered ones, is the reason why the old checkpoints have not been removed entirely yet.
2022-12-12 - Bitcoin Core 24.0.1 is released with the fix.
2023-12-07 - The last vulnerable version of Bitcoin Core (23.2) goes end of life.
2024-09-18 - Public disclosure.

CVE-2024-52919 - Remote crash due to addr message spam

Wed, 31 Jul 2024 00:00:00 +0000

Disclosure of the details of an integer overflow bug which causes an assertion crash, a fix for which was released on September 14th, 2021 in Bitcoin Core version v22.0.

This issue is considered High severity.

Details

CAddrMan has a 32-bit nIdCount field that is incremented on every insertion into addrman, and which then becomes the identifier for the new entry. By getting the victim to insert 2³² entries (through e.g. spamming addr messages), this identifier overflows, which leads to an assertion crash.

Attribution

Credit goes to Eugene Siegel for discovering and disclosing the vulnerability, and to Pieter Wuille for fixing the issue in https://github.com/bitcoin/bitcoin/pull/22387.

Timeline

2021-06-21 - Initial report sent to security@bitcoincore.org by Eugene Siegel
2021-07-19 - Fix is merged (https://github.com/bitcoin/bitcoin/pull/22387)
2021-09-13 - v22.0 is released
2024-07-31 - Public disclosure

CVE-2024-52917 - Infinite loop bug in the miniupnp dependency

Wed, 31 Jul 2024 00:00:00 +0000

Disclosure of the impact of an infinite loop bug in the miniupnp dependency on Bitcoin Core, a fix for which was released on September 14th, 2021 in Bitcoin Core version v22.0.

This issue is considered Low severity.

Details

Miniupnp, the UPnP library used by Bitcoin Core, would be waiting upon discovery for as long as it receives random data from a device on the network. In addition it would allocate memory for every new device information. An attacker on the local network could pretend to be a UPnP device and keep sending bloated M-SEARCH replies to the Bitcoin Core node until it runs out of memory.

Only users running with the -miniupnp option would have been affected by this bug as Miniupnp is otherwise turned off by default.

Attribution

Credit goes to Ronald Huveneers for reporting the infinite loop bug to the miniupnp project, and to Michael Ford (Fanquake) for the report to the Bitcoin Core project along with a PoC exploit to trigger an OOM and a pull request to bump the dependency (containing the fix).

Timeline

2020-09-17 - Initial report of infinite loop bug to miniupnp by Ronald Huveneers
2020-10-13 - Initial report sent to security@bitcoincore.org by Michael Ford
2021-03-23 - Fix is merged (https://github.com/bitcoin/bitcoin/pull/20421)
2021-09-13 - v22.0 is released
2024-07-31 - Public disclosure

Bitcoin Core 26.2 版本發布

Tue, 09 Jul 2024 00:00:00 +0000

Bitcoin Core 26.2 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

CVE-2024-52913 - Censorship due to transaction re-request handling

Wed, 03 Jul 2024 00:00:00 +0000

An attacker could prevent a node from seeing a specific unconfirmed transaction.

This issue is considered Medium severity.

Details

Before this issue was fixed in PR 19988, the “g_already_asked_for” mechanism was used to schedule GETDATA requests for transactions. The SendMessages() function would send out GETDATAs for transactions recently announced by peers, remembering when that request was sent out in g_already_asked_for. However, this g_already_asked_for was a “limitedmap” data structure, with a bounded size that would forget the oldest entries if it reaches 50000 entries. This makes the following attack possible:

The attacker is the first to announce a legitimate transaction T to the victim.
The victim requests T from the attacker using GETDATA.
The attacker does not respond to GETDATA until close to the time when the victim would request T from other peers (~60 seconds).
Then, the attacker carefully spams the victim with bogus announcements, causing the victim’s g_already_asked_for to evict T.
The attacker announces T again to the victim (due to how the queueing works in m_tx_process_time, this does not need to be timed particularly accurately).
The victim, not finding T in g_already_asked_for will treat it as a new announcement, sending a new GETDATA for it to the attacker.
The attacker again does not respond to GETDATA.
etc.

This way, the attacker can prevent the victim from ever requesting the transaction from anyone but the attacker.

Attribution

Responsibly disclosed by John Newbery, claiming discovery by Amiti Uttarwar and him.

Timeline

2020-04-03 John Newbery reports the bug in an email to Suhas Daftuar and others
2020-05-08 John Newbery suggests an approach to fixing the bug
2020-09-21 Pieter Wuille opens PR #19988 as a comprehensive approach to fixing this and other bugs
2020-10-14 Pieter’s PR is merged
2021-01-14 Bitcoin Core version 0.21.0 is released with a fix
2022-04-25 The last vulnerable Bitcoin Core version (0.20.x) goes EOL
2024-07-03 Public disclosure

CVE-2024-52918 - Crash using malicious BIP72 URI

Wed, 03 Jul 2024 00:00:00 +0000

Bitcoin-Qt could crash upon opening a BIP72 URI.

This issue is considered Medium severity.

Details

BIP72 extends the BIP21 URI scheme with an r parameter to fetch a payment request from. An attacker could simply point the URL contained in the r parameter to a very large file, for which Bitcoin-Qt would try to allocate enough memory and crash.

The victim could get tricked into opening a rogue payment request. The large download would happen in the background with little to no output in the GUI until the application runs out of memory.

Attribution

Credits go to Michael Ford (Fanquake) for responsibly disclosing the issue and providing a PoC.

Timeline

2019-08-12 Michael Ford reports the bug to Cory Fields and Wladimir Van Der Laan
2019-10-16 Michael Ford opens PR #17165 to get rid of BIP70 support entirely
2019-10-26 Michael’s PR is merged into Bitcoin Core
2020-06-03 Bitcoin Core version 0.20.0 is released
2021-09-13 The last vulnerable Bitcoin Core version (0.19.x) goes EOL
2024-07-03 Public disclosure

CVE-2024-52920 - DoS using huge GETDATA messages

Wed, 03 Jul 2024 00:00:00 +0000

A malformed GETDATA message could trigger an infinite loop on the receiving node, using 100% of the CPU allocated to this thread and not making further progress on this connection.

This issue is considered Low severity.

Details

Before Bitcoin Core 0.20.0, an attacker (or buggy client, even) could send us a GETDATA message that would cause our net_processing thread to start spinning at 100%, and not make progress processing messages for the attacker peer anymore. It would still make progress processing messages from other peers, so it is just a CPU DoS with low impact beyond that (not making progress for attacker peers is a non-issue). It also increases per-peer long-term memory usage up by 1.5 MB per attacker peer.

John Newbery opened PR #18808 to fix this issue by only disclosing the lack of progress.

Attribution

Credits to John Newbery for finding this bug, responsibly disclosing it and fixing it.

Timeline

2020-04-29 John Newbery opens #18808
2020-05-08 John Newbery reports his finding by email
2020-05-12 #18808 is merged
2020-06-03 Bitcoin Core version 0.20.0 is released with a fix
2021-09-13 The last vulnerable Bitcoin Core version (0.19.x) goes EOL
2024-07-03 Public disclosure.

CVE-2024-52916 - Memory DoS using low-difficulty headers

Wed, 03 Jul 2024 00:00:00 +0000

After Bitcoin Core 0.12.0 and before Bitcoin Core 0.15.0 a node could be spammed with minimum difficulty headers, which could possibly be leveraged to crash it by OOM.

This issue is considered Medium severity.

Details

Before the introduction of headers pre-synchronisation, nodes relied exclusively on checkpoints to avoid getting spammed by low-difficulty headers.

In Bitcoin Core 0.12.0 a check for headers forking before the last checkpoint’s height was moved to after storing the header in mapBlockIndex. This allowed an attacker to grow the map unboundedly by spamming headers whose parent is the genesis block (which only need difficulty 1 to create), as such blocks bypassed the checkpoint logic.

Attribution

Credits to Cory Fields for finding and responsibly disclosing the bug.

Timeline

2017-08-08 Cory Fields privately reports the bug
2017-08-11 Pieter Wuille opens PR #11028 to fix it
2017-08-14 PR #11028 is merged
2017-09-14 Bitcoin Core version 0.15.0 is released with a fix
2018-10-03 The last vulnerable version of Bitcoin Core (0.14.3) goes end of life
2024-07-03 Public disclosure.

CVE-2024-52915 - Memory DoS using huge INV messages

Wed, 03 Jul 2024 00:00:00 +0000

A node could be forced to allocate a significant amount of memory upon receiving a specially crafted INV message. This was particularly an issue for nodes with little available memory or a large number of connections.

This issue is considered Medium severity.

Details

An INV message filled with 50,000 block items could cause 50,000 getheaders responses to be sent in a single ProcessMessages() call. Each response contains a locator and is around 1 kB. All would be put into the send buffer at once. The attacker could just refuse to receive data to prevent the 50 MB buffer from draining.

John Newbery opened PR #18962 to fix this issue pretexting a bandwidth gain from sending a single GETHEADERS per received INV.

Attribution

Credits to John Newbery for finding this bug, responsibly disclosing it and fixing it.

Timeline

2020-05-08 John Newbery reports his finding by email
2020-05-12 John Newbery opens #18962
2020-05-14 #18962 is merged
2020-06-03 Bitcoin Core version 0.20.0 is released with a fix
2021-09-13 The last vulnerable Bitcoin Core version (0.19.x) goes EOL
2024-07-03 Public disclosure.

CVE-2024-52914 - Significant DoS due to orphan handling

Wed, 03 Jul 2024 00:00:00 +0000

A node could be stalled for hours when processing the orphans of a specially crafted unconfirmed transaction.

This issue is considered High severity.

Details

After accepting a transaction into its mempool, the node would go through its cache of orphan transactions to find if this new accepted transaction makes it possible to accept any. This search was quadratic: for each output in the newly accepted transaction it would go through all cached orphan transactions (limited to 100). By specially crafting the orphan transactions to be invalid yet expensive to validate a node could be stalled for several hours.

The stall was fixed by Pieter Wuille in PR #15644 by interrupting the orphan resolution to process new messages when a match is found (whether the orphan turns out to be valid or not).

Attribution

Credits to sec.eine for responsibly disclosing the bug and providing feedback on the fix.

Timeline

2019-03-19 sec.eine reports the issue to Greg Maxwell by email
2019-03-21 Greg Maxwell responds with information about the proposed patch
2019-03-22 sec.eine gives feedback on the patch (“seems solid and [..] doesn’t attract attention”)
2019-03-22 Pieter Wuille opens PR #15644
2019-04-01 PR #15644 is merged
2019-05-18 Bitcoin Core version 0.18.0 is released with a fix
2020-07-22 The issue is partially disclosed during a PR review club
2020-08-01 The last vulnerable Bitcoin Core version (0.17.x) goes EOL
2024-07-03 Public disclosure.

Disclosure of CVE-2015-3641

Wed, 03 Jul 2024 00:00:00 +0000

A node could be forced to allocate large buffers when receiving a message, which could be leveraged to remotely crash it by OOM.

This issue is considered Medium severity.

Details

Without a tighter bound, received messages’ size was limited by the maximum serialized message size of 32 MiB. An attacker could force a node to allocate this much RAM per connection, which may lead to an OOM.

PR #5843 reduced the size P2P messages can have before receiving the payload. This reduces the per-peer receive buffer memory size a malicious peer can cause. The PR reduced the number from 32 MiB to 2 MiB, which was later increased back to 4 MB as part of the Segwit BIP144 changes.

Attribution

Reported to Greg Maxwell by bitcointalk user Evil-Knievel. Fixed by Pieter Wuille.

Timeline

2015-02-05 Evil-Knievel reports the vulnerability to Greg Maxwell through bitcointalk private messages.
2015-??-?? CVE-2015-3641 is registered for it.
2015-03-01 PR #5843 is opened to fix it.
2015-03-06 PR #5843 is merged.
2015-03-09 The fix is backported to version 0.10.1.
2015-04-27 Bitcoin Core version 0.10.1 is released with a fix.
2015-06-25 A disclosure is pre-announced.
2015-07-07 Disclosure is postponed.
2016-08-23 The last vulnerable Bitcoin Core Version (0.10.x) goes EOL
2024-07-03 Public disclosure.

CVE-2024-52912 - Netsplit due to timestamp adjustment

Wed, 03 Jul 2024 00:00:00 +0000

Disclosure of the details of an integer overflow bug which risked causing a network split, a fix for which was released on January 15th, 2021 in Bitcoin Core version 0.21.0.

This issue is considered Medium severity.

Technical details

A network split vulnerability resulted from two separate bugs in the processing code of version messages:

Signed-integer overflow when calculating the time offset for newly connecting peers.
abs64 logic bug (abs64(std::numeric_limits<int64_t>::min()) == std::numeric_limits<int64_t>::min()), resulting in a bypass of the maximum time adjustment limit.

The two bugs allow an attacker to force a victims adjusted time (system time + network time offset) to be skewed such that any new blocks are rejected for having a timestamp that is dated too far in the future. It should be noted that this attack assumes the attacker is among the first 200 peers to connect to the victim, as only the time offsets from those initial connections are factored into adjusted time.

Attribution

Credit goes to practicalswift for discovering and providing the initial fix for the vulnerability, and Pieter Wuille for the fix as well as general cleanup to the at-risk code.

Timeline

2020-10-10 Initial report send to security@bitcoincore.org
2020-10-13 Fix merged into Bitcoin Core (https://github.com/bitcoin/bitcoin/pull/20141)
2021-01-15 v0.21.0 released
2022-04-25 The last vulnerable Bitcoin Core version (0.20.x) goes EOL
2024-07-03 Public disclosure

Disclosure of CVE-2020-14198

Wed, 03 Jul 2024 00:00:00 +0000

Bitcoin Core maintained an unlimited list of banned IP addresses and performed a quadratic operation on it. This could lead to an OOM crash and a CPU Dos.

This issue is considered High severity.

Details

Bitcoin Core maintained a list of banned IP addresses. This list was not bounded and could be manipulated by an adversary. Adding new entries to this list was particularly cheap for an attacker when considering IPV6. In addition, when receiving a GETADDR message, Bitcoin Core would scan the entire ban list for every single address to be returned (up to 2500).

Attribution

Calin Culianu first responsibly disclosed it. Calin later publicly disclosed the bug in a PR comment.

On the same day Jason Cox from Bitcoin ABC emailed the Bitcoin Core project to share this same report they also received.

Timeline

2020-06-08 Calin Culianu privately reports the bug to the Bitcoin Core project
2020-06-08 Jason Cox privately shares the (same) report sent to Bitcoin ABC with Bitcoin Core
2020-06-08 Calin Culianu publicly discloses the vulnerability on the original PR which introduced the quadratic behaviour
2020-06-09 Pieter Wuille opens PR #19219 which fixes both the unbounded memory usage and the quadratic behaviour
2020-06-16 Luke Dashjr gets assigned CVE-2020-14198 for this vulnerability after his request
2020-07-07 Pieter’s PR is merged
2020-08-01 Bitcoin Core 0.20.1 is released with the fix
2021-01-14 Bitcoin Core 0.21.0 is released with the fix
2022-04-25 The last vulnerable Bitcoin Core version (0.20.0) goes EOL
2024-07-03 (Official) Public Disclosure

CVE-2015-20111 - Remote code execution due to bug in miniupnpc

Wed, 03 Jul 2024 00:00:00 +0000

A buffer overflow enabling a significant data leak was discovered in miniupnpc. Combined with the then recently-disclosed CVE-2015-6031 it enabled an RCE in miniupnpc which could have led to an RCE in Bitcoin Core. This was fixed in Bitcoin Core 0.12, released in February 2016.

This issue is considered Medium severity.

Details

CVE-2015-6031, disclosed in September 2015, made it possible for a malicious UPnP server to remotely crash a Bitcoin Core process on the local network at startup. See here for details. The fix was pulled in Bitcoin Core and released in version 0.11.1, released in October 2015. UPnP was then turned off by default.

CVE-2015-6031 disclosed a buffer overflow, which in addition to enabling a remote crash could have made it possible to remotely execute code on a victim’s machine. While investigating this possibility, Wladimir J. Van Der Laan found another buffer overflow in miniupnpc which enabled a significant data leak. This was fixed by Wladimir in miniupnpc in commit 4c90b87ce3d2517097880279e8c3daa7731100e6. The fix was then pulled into Bitcoin Core and released as part of version 0.12.

This data leak did not disclose secret information (such as the wallet’s private keys) directly. But combined with another stack overflow (such as the one disclosed in CVE-2015-6031) this made it possible to trigger a remote code execution. Wladimir demonstrated this against Ubuntu’s miniupnpc version 1.6-precise. The specific approach used in this exploit was however not directly portable to Bitcoin Core.

Attribution

Credits go to Aleksandar Nikolic for identifying CVE-2015-0035 and to Wladimir J. Van Der Laan for investigating its impact and discovering the second buffer overflow.

Timeline

2015-09-15 CVE-2015-0035 is fixed and disclosed.
2015-10-09 PR #6789 is merged in Bitcoin Core
2015-10-14 Wladimir’s remote code execution by leveraging the second buffer overflow is disclosed to Ubuntu security and Bitcoin developers.
2015-10-15 Bitcoin Core 0.11.1 is released
2015-10-26 The fix for the second buffer overflow is merged into miniupnpc.
2015-12-18 The fix is pulled into Bitcoin Core.
2016-02-23 Bitcoin Core version 0.12 is released.
2017-03-08 The last vulnerable Bitcoin Core Version (0.11.x) goes EOL
2024-07-03 Public disclosure

Bitcoin Core 27.1 版本發布

Mon, 17 Jun 2024 00:00:00 +0000

Bitcoin Core 27.1 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 27.0 版本發布

Tue, 16 Apr 2024 00:00:00 +0000

Bitcoin Core 27.0 版本現已可供下載。請參閱版本說明以了解此版本中的新功能和其他變更。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 25.2 版本發布

Mon, 08 Apr 2024 00:00:00 +0000

Bitcoin Core 25.2 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 26.1 版本發布

Tue, 02 Apr 2024 00:00:00 +0000

Bitcoin Core 26.1 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 26.0 版本發布

Wed, 06 Dec 2023 00:00:00 +0000

Bitcoin Core 26.0 版本現已可供下載。請參閱版本說明以了解此版本中的新功能和其他變更。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 24.2 版本發布

Thu, 26 Oct 2023 00:00:00 +0000

Bitcoin Core 24.2 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 25.1 版本發布

Thu, 19 Oct 2023 00:00:00 +0000

Bitcoin Core 25.1 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 25.0 版本發布

Fri, 26 May 2023 00:00:00 +0000

Bitcoin Core 25.0 版本現已可供下載。請參閱版本說明以了解此版本中的新功能和其他變更。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 23.2 版本發布

Thu, 18 May 2023 00:00:00 +0000

Bitcoin Core 23.2 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 24.1 版本發布

Thu, 18 May 2023 00:00:00 +0000

Bitcoin Core 24.1 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 23.1 版本發布

Wed, 21 Dec 2022 00:00:00 +0000

Bitcoin Core 23.1 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 22.1 版本發布

Thu, 15 Dec 2022 00:00:00 +0000

Bitcoin Core 22.1 版本現已可供下載。請參閱版本說明以了解此版本的錯誤修復詳情。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 24.0.1 版本發布

Mon, 12 Dec 2022 00:00:00 +0000

Bitcoin Core 24.0.1 版本現已可供下載。請參閱版本說明以了解此版本中的新功能和其他變更。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 23.0 版本發布

Mon, 25 Apr 2022 00:00:00 +0000

Bitcoin Core 23.0 版本現已可供下載。請參閱版本說明以了解此版本中的新功能和其他變更。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

Bitcoin Core 22.0 版本發布

Mon, 13 Sep 2021 00:00:00 +0000

Bitcoin Core 22.0 版本現已可供下載。請參閱版本說明以了解此版本中的新功能和其他變更。

如有任何問題，請前往 #bitcoin IRC 聊天室（IRC、網頁版），我們會盡力為您提供協助。

bitcoincore.org 隱藏服務

Fri, 27 Mar 2020 00:00:00 +0000

在多次請求後，本站現在可透過 onion 地址作為 Tor 隱藏服務訪問：

http://6hasakffvppilxgehrswmffqurlcjjjhd76jgvaqmsg6ul25s7t3rzyd.onion/

除了新增另一種抗審查手段外，隱藏服務提供了不依賴憑證授權單位或 DNS 基礎設施的替代信任路徑。

Disclosure of CVE-2017-18350

Fri, 08 Nov 2019 00:00:00 +0000

Nodes were potentially vulnerable to a buffer overflow by malicious SOCKS servers. A fix was released on November 6th, 2017 in Bitcoin Core version 0.15.1.

Technical Details

CVE-2017-18350 is a buffer overflow vulnerability which allows a malicious SOCKS proxy server to overwrite the program stack on systems with a signed char type (including common 32-bit and 64-bit x86 PCs).

The vulnerability was introduced in 60a87bce873 (SOCKS5 support) and first released in Bitcoin Core v0.7.0rc1 in 2012 Aug 27. A fix was hidden in d90a00eabed (“Improve and document SOCKS code”) released in v0.15.1, 2017 Nov 6.

To be vulnerable, the node must be configured to use such a malicious proxy in the first place. Note that using any proxy over an insecure network (such as the Internet) is potentially a vulnerability since the connection could be intercepted for such a purpose.

Upon a connection request from the node, the malicious proxy would respond with an acknowledgement of a different target domain name than the one requested. Normally this acknowledgement is entirely ignored, but if the length uses the high bit (ie, a length 128-255 inclusive), it will be interpreted by vulnerable versions as a negative number instead. When the negative number is passed to the recv() system call to read the domain name, it is converted back to an unsigned/positive number, but at a much wider size (typically 32-bit), resulting in an effectively infinite read into and beyond the 256-byte dummy stack buffer.

To fix this vulnerability, the dummy buffer was changed to an explicitly unsigned data type, avoiding the conversion to/from a negative number.

Attribution

Credit goes to practicalswift for discovering and providing the initial fix for the vulnerability, and Wladimir J. van der Laan for a disguised version of the fix as well as general cleanup to the at-risk code.

Timeline

2012-04-01: Vulnerability introduced in PR #1141.
2012-05-08: Vulnerability merged to master git repository.
2012-08-27: Vulnerability published in v0.7.0rc1.
2012-09-17: Vulnerability released in v0.7.0.
…
2017-09-21: practicalswift discloses vulnerability to security team.
2017-09-23: Wladimir opens PR #11397 to quietly fix vulnerability.
2017-09-27: Fix merged to master git repository.
2017-10-18: Fix merged to 0.15 git repository.
2017-11-04: Fix published in v0.15.1rc1.
2017-11-09: Fix released in v0.15.1.
…
2019-06-22: Vulnerability existence disclosed to bitcoin-dev ML.
2019-11-08: Vulnerability details disclosure to bitcoin-dev ML.

Disclosure of CVE-2018-17144

Thu, 20 Sep 2018 00:00:00 +0000

Full disclosure

CVE-2018-17144, a fix for which was released on September 18th in Bitcoin Core versions 0.16.3 and 0.17.0rc4, includes both a Denial of Service component and a critical inflation vulnerability. It was originally reported to several developers working on Bitcoin Core, as well as projects supporting other cryptocurrencies, including ABC and Unlimited on September 17th as a Denial of Service bug only, however we quickly determined that the issue was also an inflation vulnerability with the same root cause and fix.

In order to encourage rapid upgrades, the decision was made to immediately patch and disclose the less serious Denial of Service vulnerability, concurrently with reaching out to miners, businesses, and other affected systems while delaying publication of the full issue to give times for systems to upgrade. On September 20th a post in a public forum reported the full impact and although it was quickly retracted the claim was further circulated.

At this time we believe over half of the Bitcoin hashrate has upgraded to patched nodes. We are unaware of any attempts to exploit this vulnerability.

However, it still remains critical that affected users upgrade and apply the latest patches to ensure no possibility of large reorganizations, mining of invalid blocks, or acceptance of invalid transactions occurs.

Technical Details

In Bitcoin Core 0.14, an optimization was added (Bitcoin Core PR #9049) which avoided a costly check during initial pre-relay block validation that multiple inputs within a single transaction did not spend the same input twice which was added in 2012 (PR #443). While the UTXO-updating logic has sufficient knowledge to check that such a condition is not violated in 0.14 it only did so in a sanity check assertion and not with full error handling (it did, however, fully handle this case twice in prior to 0.8).

Thus, in Bitcoin Core 0.14.X, any attempts to double-spend a transaction output within a single transaction inside of a block will result in an assertion failure and a crash, as was originally reported.

In Bitcoin Core 0.15, as a part of a larger redesign to simplify unspent transaction output tracking and correct a resource exhaustion attack the assertion was changed subtly. Instead of asserting that the output being marked spent was previously unspent, it only asserts that it exists.

Thus, in Bitcoin Core 0.15.X, 0.16.0, 0.16.1, and 0.16.2, any attempts to double-spend a transaction output within a single transaction inside of a block where the output being spent was created in the same block, the same assertion failure will occur (as exists in the test case which was included in the 0.16.3 patch). However, if the output being double-spent was created in a previous block, an entry will still remain in the CCoin map with the DIRTY flag set and having been marked as spent, resulting in no such assertion. This could allow a miner to inflate the supply of Bitcoin as they would be then able to claim the value being spent twice.

Timeline

Timeline for September 17, 2018: (all times UTC)

14:57 anonymous reporter reports crash bug to: Pieter Wuille, Greg Maxwell, Wladimir Van Der Laan of Bitcoin Core, deadalnix of Bitcoin ABC, and sickpig of Bitcoin Unlimited.
15:15 Greg Maxwell shares the original report with Cory Fields, Suhas Daftuar, Alex Morcos and Matt Corallo
17:47 Matt Corallo identifies inflation bug
19:15 Matt Corallo first tries to reach slushpool CEO to have a line of communication open to apply a patch quickly
19:29 Greg Maxwell timestamps the hash of a test-case which demonstrates the inflation vulnerability (a47344b7dceddff6c6cc1c7e97f1588d99e6dba706011b6ccc2e615b88fe4350)
20:15 John Newbery and James O’Beirne are informed of the vulnerability so they can assist in alerting companies to a pending patch for a DoS vulnerability
20:30 Matt Corallo speaks with slushpool CTO and CEO and shares patch with disclosure of the Denial of Service
20:48 slushpool confirmed upgraded
21:08 Alert was sent to Bitcoin ABC that a patch will be posted publicly by 22:00
21:30 (approx) Responded to original reporter with an acknowledgment
21:57 Bitcoin Core PR 14247 published with patch and test demonstrating the Denial of Service bug
21:58 Bitcoin ABC publishes their patch
22:07 Advisory email with link to Bitcoin Core PR and patch goes out to Optech members, among others
23:21 Bitcoin Core version 0.17.0rc4 tagged

September 18, 2018:

00:24 Bitcoin Core version 0.16.3 tagged
20:44 Bitcoin Core release binaries and release announcements were available
21:47 Bitcointalk and reddit have public banners urging people to upgrade

September 19, 2018:

14:06 The mailing list distributes an additional message urging people to upgrade by Pieter Wuille

September 20, 2018:

19:50 David Jaenson independently discovered the vulnerability, and it was reported to the Bitcoin Core security contact email.

更正關於 Segwit2x 和 btc1 的錯誤資訊

Fri, 18 Aug 2017 00:00:00 +0000

「Segwit2x」，一項對 Bitcoin 網路共識規則進行不相容變更的提案，最近受到越來越多的關注。有人試圖誤導人們相信 btc1 專案（Segwit2x 提案的實作）是現有軟體的必要更新──事實並非如此。相反，它是對現有網路規則的爭議性偏離，其使用者將很快發現自己與網路其他部分在區塊和交易的有效性方面存在分歧。

請注意：

隔離見證（或 Segwit，一種將在未來幾天內啟動的軟分叉）與 Segwit2x 硬分叉無關。隔離見證與所有先前的 Bitcoin 軟體向後相容。對於絕大多數 Bitcoin 使用者來說，不需要採取任何行動。
bitcoincore.org 是官方網站，@bitcoincoreorg 是 Bitcoin Core 專案的官方 Twitter 帳戶。任何其他聲稱代表該專案的網站或 Twitter 帳戶都是欺詐性的。Bitcoin Core 是一個開源專案，歡迎任何人透過其 GitHub 專案貢獻和審查。Bitcoin Core 二進位檔案可以從 bitcoincore.org 取得，並且始終由發布經理的簽署金鑰進行數位簽章。撰寫本文時，Bitcoin Core 的最新版本是 0.14.2。
btc1 與 Bitcoin Core 沒有任何 關聯。沒有常規的 Bitcoin Core 貢獻者支援 btc1 或與該專案有任何聯繫，也沒有參與其提議的硬分叉的設計。
我們強烈建議使用者不要下載任何聲稱是對 Bitcoin 共識規則「升級」的 Bitcoin 全節點軟體，除非仔細考慮提議的變更對 Bitcoin 系統的影響以及社群對它的支援程度。這包括 Bitcoin Core 新版本中提議的共識變更。
雖然很難確定更廣泛的 Bitcoin 社群支援什麼，但要警惕聲稱龐大而多樣化的 Bitcoin 社群在沒有獨立驗證的情況下完全轉向一個分叉或另一個分叉的說法。簽署信已被公司用來聲稱代表其客戶/使用者而未經其同意，並且經常使用不精確和誤導性的語言。過去，Bitcoin XT、Bitcoin Classic 和 Bitcoin Unlimited 以及其他的信件已被傳閱以表明對一個想法的普遍支援，同時被宣傳為不考慮社群考慮而執行軟體的承諾，只會在幾個月後被放棄。
Bitcoin Core 貢獻者和 Bitcoin 社群成員提出的關於 Segwit2x 提案的擔憂尚未得到其支持者的充分解決。該提案的細節是在 Bitcoin 的隔離見證啟動之前以及最近建立 BCH 貨幣之前確定的。在規劃未來時忽略這些事件的結果是不負責任的。例如，我們已經看到了當單個地址在兩條鏈上都有效時產生的混亂，但 Segwit2x 提案打算重複同樣的錯誤。此外，BCH 對強重放保護的實作為 BCH 和 Bitcoin 的使用者提供了顯著的保護，而 Segwit2x 不打算提供這種保護。
Bitcoin 的共識規則應該只在謹慎的情況下並在整個社群的廣泛同意下變更。Segwit2x 在其流程和實作中都受到了許多人的反對。Bitcoin Core 將繼續支援 Segwit 軟分叉，我們期待在未來幾年幫助 Bitcoin 擴展到新的高度。

技術路線圖 - 使用完整區塊 SPV 模式的優先區塊下載

Fri, 31 Mar 2017 00:00:00 +0000

混合式完整區塊 SPV 模式

阻礙一般使用者進一步採用完全驗證軟體的主要障礙之一是，在完全同步整個區塊鏈之前無法使用客戶端的錢包功能。對於引導新節點的使用者來說，這意味著他們無法接收或傳送交易，直到每個區塊都已下載並驗證到鏈的當前尖端。這種行為並非錯誤：Bitcoin Core 參考軟體預設構建為提供 Bitcoin 使用者可以期望的最強安全性和私密性保證，這必然意味著完全驗證以確認歷史區塊鏈資料的完整性。

另一方面，軟體的現有功能（例如標頭優先驗證）提供了改進錢包可用性的機會，前提是使用者願意做出臨時的安全權衡。使用混合式完整區塊 SPV 模式，軟體將根據使用者錢包中最舊的金鑰優先下載區塊。與先前下載的區塊標頭鏈一起，它應該滿足預期的工作量證明難度檢查，客戶端可以立即開始處理相關交易。整個區塊鏈仍然並行下載並最終驗證，但此功能使使用者能夠在背景中進行同步時查看和花費與其錢包相關的 UTXO。

與 SPV 錢包的典型實作相反，此模型不會遭受依賴布隆過濾器和公鑰公開披露的方案所施加的私密性降級。這種好處帶來的權衡是它消耗更多頻寬。另一個警告：在 SPV 模式下收到的確認本質上不如在完全驗證下收到的確認安全。利用混合式 SPV 模式的使用者應該等待多次確認（6+），直到他的付款可以被認為是安全的。

技術路線圖 - Schnorr 簽章和簽章聚合

Thu, 23 Mar 2017 00:00:00 +0000

Schnorr 簽章

用更有效的 Schnorr 演算法替代 Bitcoin 的數位簽章演算法（ECDSA）長期以來一直位於許多 Bitcoin 開發者願望清單的首位。Schnorr 是一種利用橢圓曲線密碼學的簡單演算法，在保留其所有功能和安全假設的同時，實現了對現有方案的多項改進。

值得注意的是，Schnorr 簽章支援「原生多重簽章」，可將多個簽章聚合為一個對其各自輸入的金鑰總和有效的簽章。此功能提供三個重要好處：

無論多重簽章設定中的參與者數量如何，簽章大小都是恆定的。50-of-50 交易的大小實際上與使用單個公鑰和簽章的交易相同。因此，此類方案的效能透過消除單獨驗證每個簽章的原始要求而顯著提高。此外，Schnorr 簽章的驗證比 ECDSA 稍快。
要驗證和透過網路傳輸的資料大小減少也轉化為有趣的容量增益。考慮到下面顯示的多重簽章交易數量的歷史增長，減少這些交易大小的潛力是對現有擴展工作的誘人補充。我們應該預期隨著支付通道的出現和進一步採用，這一趨勢將繼續。
從私密性的角度來看，Schnorr 允許將多重簽章的整個策略隱藏起來，並且與傳統的單個公鑰無法區分。在閾值設定中，參與者也變得不可能透露他們中的哪些人授權或未授權交易。

根據多重簽章設定分佈未花費 P2SH 輸出。來源：p2sh.info

不幸的是，與 ECDSA 不同，Schnorr 演算法自發明以來尚未被標準化，可能是因為對其強制執行的原始專利（現已到期）。雖然系統的一般輪廓在數學上是健全的，但缺乏文件和規範使其實作更具挑戰性。具體來說，它對 Bitcoin 的臨時金鑰對設計的應用涉及需要進一步最佳化的安全考慮。

Pieter Wuille 在他的 Scaling Bitcoin Milan 上關於 Schnorr 簽章的演講中將主要挑戰定義為「抵消」問題。一組使用者建立對其金鑰總和有效的簽章的可能性為對抗性參與者從整體中減去另一個使用者的金鑰開啟了大門。它本質上是這樣運作的：

假設使用輸入公鑰 Q1 和 Q2 的 2-of-2 多重簽章方案。惡意參與者在互動階段期間，不是宣布他們的金鑰為 Q2 以與 Q1 組合，而是可以提供 Q2-Q1 並有效地抵消其他使用者的金鑰。傳送到聯合公鑰的任何資金現在只能由 Q2 金鑰的所有者花費，而 Q1 的所有者甚至不知道發生了什麼。

幸運的是，現在有一個解決方案可用，它涉及在簽章之前將設定期間使用的每個金鑰與基於其自身和所有其他相關金鑰的雜湊相乘。此過程稱為去線性化。此方案的安全性證明目前正在進行同行評審，並將在即將發布的白皮書中正式描述。

在短期內，Schnorr 簽章被認為是 Bitcoin 協定兩個重要功能的可行替代品：OP_CHECKSIG 和 OP_CHECKMULTISIG。

前者目前用於根據交易中的訊息檢查 ECDSA 簽章與其各自的公鑰。透過切換到檢查 Schnorr 簽章而不是 ECDSA 的等效物，該操作碼可用於授權需要多個簽章的支出，這通常需要呼叫 OP_CHECKMULTISIG。使用網路無法觀察到的先驗互動，簽署者集合計算組合的公鑰以及共同簽章，由新的 OP_CHECKSIG 驗證，具有增加私密性和降低成本的好處。

後者涉及閾值情況，其中只需要 n-of-m 簽章來授權交易。OP_CHECKMULTISIG 的當前實作驗證閾值策略所需的所有公鑰和相關簽章。因為計算隨著參與者數量線性擴展，Schnorr 提出了一個更有效的方案，它用單個組合簽章以及所需公鑰的子集替換簽章列表。

在對保護簽署者免受惡意行為者攻擊的去線性化方案進行更多評估之前，Schnorr 簽章的進一步應用可能為時過早，但上述功能的實作有望為在生產中更好地理解該方案鋪平道路。取決於額外的同行評審，Schnorr 簽章實作的 BIP 可以在年底前提出。

簽章聚合

Schnorr 允許在單個輸入上組合多個簽章的屬性也適用於所有交易的多個輸入的聚合。Bitcoin 開發者 Gregory Maxwell 是第一個使用基於 BLS 簽章的先前提案的見解引入這個想法的人。

要正確理解此應用與上述應用之間的差異，有必要考慮在每個各自情況下如何聚合簽章。在原生多重簽章設定中，簽署者彼此合作以計算共同公鑰及其相關簽章。這種互動發生在協定之外，只涉及相關各方。簽章聚合背後的想法是讓系統驗證者（即 Bitcoin 節點）在協定層級為所有交易的每個輸入計算單個金鑰和簽章。

因為此方案將聚合範圍擴展到確定性參與者集合之外，它引入了惡意行為者利用「抵消」錯誤的新攻擊向量。因此，前一節中強調的去線性化修正對於此方法的健全性至關重要。

在實作方面，該提案相當直接：修改 OP_CHECKSIG 和 OP_CHECKMULTISIG，使它們可以堆疊公鑰，對它們進行去線性化，一旦驗證了所有相關輸入，就為它們各自的交易產生組合簽章。

評估如果自創世區塊以來實作簽章聚合可能節省的資源類型相當簡單。假設每個歷史簽章減少到 1 位元組，除了每筆交易一個，分析表明該方法將導致儲存和頻寬至少減少 25%。增加使用 n-of-n 閾值可能會轉化為更多節省，儘管它們未在此分析中考慮。

關於 Schnorr 簽章的更多資訊

關於簽章聚合的更多資訊

鏈上擴容 - Bitcoin 參考軟體歷史性能優化回顧。第 1 部分

Mon, 13 Mar 2017 00:00:00 +0000

以下文章旨在強調多年來幫助 Bitcoin 軟體客戶端使用者保持可靠體驗的開發里程碑。我們展示了幾個關鍵升級，這些升級對於維護網路的去中心化特性和減輕參與者的資源負擔至關重要。我們描述了如何進行數個數量級的優化，使 Bitcoin 網路能夠支援交易活動的增長，而不會大幅增加新使用者和現有使用者的參與成本。最後，我們注意到這些改進都屬於更大的、系統性的協定開發方法的一部分，該方法使用來自 Big-O 複雜度概念的見解，並利用更智慧的演算法來更有效地利用網路資源。

簽名快取

發布版本：Bitcoin-Qt 0.7.0

ECSDA 簽名驗證是在對等節點層級完成的計算量最大的操作之一。因為它們需要對每個交易進行驗證，任何多餘的驗證都會給終端使用者帶來顯著的資源開銷。早期版本的軟體就是這種情況，它們會在交易進入節點記憶池之前和接收到區塊後都驗證簽名。

為了提高效率，開發人員建立了一個快取，允許節點儲存先前驗證過的簽名，並在交易進入已接受區塊後跳過冗餘工作。

此外，簽名快取還減輕了由特別製作的交易可能導致 Bitcoin 客戶端停滯所引入的 DoS 向量。

進一步資訊

Ultraprune + LevelDB

發布版本：Bitcoin-Qt 0.8.0

Ultraprune 是 Bitcoin 軟體的首批主要升級之一，旨在解決與驗證區塊鏈交易資料相關的開銷。Bitcoin 參考客戶端的早期版本維護了所有交易輸出（已花費或未花費）的索引。Ultraprune 透過洞察到您只需要追蹤未花費的輸出，並且輸出一旦被花費就可以完全從索引中刪除，從而顯著減少了該索引的大小。

為了實現這一點，實作了一種新的資料庫佈局，該佈局將未花費交易輸出分配到緊湊的自訂格式，以減少驗證工作所需的資訊大小。

為了進一步優化系統的性能，Ultraprune 與 LevelDB 同時引入，後者取代了舊的 BDB 資料庫技術。總體而言，影響是顯著的：根據其硬體，使用者在驗證區塊鏈資料時可以體驗到至少一個數量級的改進。這種新的資料庫結構也為未來關於修剪和更輕量級的 Bitcoin 全節點實作的工作鋪平了道路。

進一步資訊

平行腳本驗證

發布版本：Bitcoin-Qt 0.8

雖然是一個更微妙的變化，但將腳本驗證轉變為更平行化的過程消除了區塊驗證時間的顯著開銷。早期版本的軟體會在每次 UTXO 提取之間驗證輸入的腳本資料，由於所有操作的線性處理而產生性能問題。這違反了設計高效計算過程的基本原則，該原則規定計算應盡可能與 I/O 作業同時發生。

考慮到這一點，區塊驗證機制被重新設計，以便能夠將腳本檢查分配給平行執行緒，以便即使在客戶端完成從區塊提取所有 UTXO 之前，它們的驗證也可以進行。為了實現這一點，腳本檢查操作在處理交易後儲存在佇列中，並與其他輸入驗證作業分開處理。

因此，透過更有效地利用對等節點的資源，同步到鏈的頂端發生得更快。在實作的測試期間，開發人員注意到與軟體早期版本相比，速度提升了 35% 到 100%。

進一步資訊

平行腳本驗證 #2060

標頭優先同步

發布版本：Bitcoin Core 0.10

為了進一步改善初始區塊下載時間，Core 專案在 2014 年底引入了節點用於與最多工作量有效鏈同步的機制的重要重新架構。

最初，引導新 Bitcoin 客戶端的過程涉及使用者從單個對等節點提取區塊資料，其結果是任何中斷或連接品質下降都會顯著停滯該過程。隨著區塊鏈大小的不斷增加，這將導致同步完成的等待時間有時會很長，很大比例的使用者報告根據其硬體最多需要數天時間。

標頭優先同步使用一種新方法完全緩解了這個問題，該方法涉及節點首先從單個對等節點下載和驗證區塊標頭，然後從眾多其他對等節點平行提取區塊資料。

自 Bitcoin 早期以來，關於初始區塊下載時間的抱怨一直很普遍。透過標頭優先同步，軟體在新使用者的可用性方面邁出了重要一步。節點現在可以利用其整個對等節點網路，而不是在不可靠的同步上浪費許多小時，並顯著縮短引導時間。透過使用更智慧的演算法，對 Bitcoin 長期永續性的這個關鍵方面進行了另一個漸近改進。

進一步資訊

區塊檔案修剪

發布版本：Bitcoin Core 0.11

舊資料修剪是中本聰在其白皮書中首次描述的概念，作為磁碟空間稀缺的潛在解決方案。不幸的是，原始設計不充分，無法按照其創建者的想像實作。七年後，隨著區塊鏈達到超過一百 GB，我們今天所知的區塊檔案修剪的引入為資源有限的使用者帶來了重大福音。

區塊檔案修剪利用了 ultraprune 的先前工作；最初下載並驗證區塊鏈的使用者現在可以丟棄早於 288 個區塊的原始資料。因為這些節點仍然保留完整的 UTXO 集，它們仍然能夠驗證未花費的資料，這足以完全驗證新區塊並防止潛在的雙重花費。

當然，修剪意味著仍然需要足夠數量的存檔節點來提供完整的區塊鏈資料。另一方面，這項創新透過使保持驗證者身份更具成本效益來擴大了驗證者的範圍。總體而言，該解決方案是我們增強網路多樣性可用選項的受歡迎補充。

進一步資訊

Bitcoin-Qt 0.11.0 發布說明

libsecp256k1

發布版本：Bitcoin Core 0.12

經過測量，確定解決區塊鏈下載效率低下問題後的下一步是解決交易驗證及其大量計算負載的瓶頸。Core 專案著手透過使用為 ECDSA 操作的優化性能而設計的新程式庫來做到這一點。ECDSA（橢圓曲線數位簽章演算法）是 Bitcoin 公鑰基礎設施的骨幹，每當使用者透過使用其私鑰簽署訊息來移動幣時都會使用它。這些簽名需要由網路中的每個對等節點驗證，以保持帳本的完整性。

早期開發人員長期以來一直考慮從原始 OpenSSL 程式庫轉換，經過 5 年的設計考慮、測試和同行評審，Pieter Wuille 的 libsecp256k1 程式庫被引入作為其替代品。正如預期的那樣，該實作導致每個 Bitcoin 交易背後的簽名驗證過程的重大加速。基準測試報告比 OpenSSL 實作改進了 5-7 倍。對於使用者來說，這將轉化為節省多達一半通常用於 ECSDA 操作的引導時間，這是從頭開始同步新節點最費力的步驟之一。

考慮到 Bitcoin 交易活動的增長，此升級對於為網路對等節點保持合理的使用者體驗至關重要。再一次，演算法複雜度的降低為使用者提供了更有效的資源使用，並大幅降低了新參與者的進入門檻。

進一步資訊

記憶池限制

發布版本：Bitcoin Core 0.12

Bitcoin 軟體長期存在的漏洞是無法正確處理對等節點記憶池的氾濫。實際上，攻擊者可以傳送大量低價值、低費用的交易，這些交易會在記憶池中累積，直到它會使可用記憶體過載。這將導致具有相對較低 RAM 資源的節點在異常活動期間崩潰。對此唯一有效的措施是增加軟體的最低中繼費用，但這仍然沒有對記憶池的潛在大小設定上限。

為了補救這一點，Core 專案的開發人員實作了嚴格的記憶池最大大小，並具有特定的驅逐策略，按費用對交易進行排序，並首先驅逐支付最低的交易。為了防止具有相同費用的交易重新進入記憶池，節點將增加其有效的最低中繼費率，以匹配最後一個被驅逐交易的費率加上初始最低中繼費率。

最大大小的配置留給使用者，預設大小為 300 MB。此更新為資源有限的節點使用者提供了更強大的體驗，並且總體上使整個網路更加可靠。

進一步資訊

Bitcoin-Qt 0.12.0 發布說明

在第 2 部分中，我們將討論基於上述技術的最新改進，並進一步提高網路的穩健性和擴展潛力。

隔離見證的成本與風險

Fri, 28 Oct 2016 00:00:00 +0000

概覽

簡介

本文是先前關於隔離見證好處文章的補充，概述了透過 BIP141 啟動隔離見證可能產生的技術成本和風險。

目的

在本文中，我們將使用成本來描述如果部署和啟動 segwit 一定會發生的負面結果，使用風險來描述可能不會發生的負面影響，或並非每個人都認為是負面的變更。

在分析風險時，我們考慮為避免風險而採取的步驟（即最小化其發生的機會），以及為減輕風險而採取的步驟（即如果確實發生，如何最小化負面影響）。

本文不嘗試就好處是否超過成本或是否應該部署或啟動 segwit 得出結論，而是透過提供背景資訊來協助利害關係人做出明智的決策。

序列化成本

交易和區塊資訊序列化有三個主要目的：

跨點對點網路傳輸；
將區塊鏈儲存在磁碟上；以及
評估區塊限制。

Segwit 以兩種方式影響序列化：

見證承諾包含在 coinbase 交易中，新增 38 到 47 位元組，約為區塊的 0.005%。（參見 BIP 141 - 承諾結構）
定義了一個包含隔離見證資料的新交易序列化（參見 BIP 141 或 BIP 144）。這為每個交易新增了 2 位元組的額外負擔，以允許輕鬆區分序列化格式，並為每個輸入的見證項目計數新增了 1 位元組的額外負擔。這些結合起來約為每個交易的 1%。

segwit 交易格式（參見 BIP 141 - 見證程式）在序列化時有以下影響：

與 P2PKH 相比，P2WPKH 在 scriptPubKey 中使用更少 3 位元組（-1%），見證位元組數量與 P2PKH scriptSig 相同。
與 P2SH 相比，P2WSH 在 scriptPubKey 中使用額外 11 位元組（6%），見證位元組數量與 P2SH scriptSig 相同。
與 P2PKH 相比，P2WPKH/P2SH 使用額外 21 位元組（11%），因為在 scriptPubKey 中使用 24 位元組，在 scriptSig 中比 P2PKH scriptPubKey 少 3 位元組，見證位元組數量與 P2PKH scriptSig 相同。
與 P2SH 相比，P2WSH/P2SH 使用額外 35 位元組（19%），因為在 scriptPubKey 中使用 24 位元組，在 scriptSig 中比 P2SH scriptPubKey 多 11 位元組，見證位元組數量與 P2SH scriptSig 相同。

上述百分比基於具有一個輸入和一個輸出的 180 位元組交易。隨著輸入/輸出數量的增加，這些比例大致保持不變，但如果使用更複雜的交易腳本（例如多重簽名），則會減少。

理由

交易大小額外負擔是由於兩個因素：

P2WSH 使用 256 位元雜湊而不是 P2SH 的 160 位元雜湊；以及
透過 P2SH 編碼，以便不支援 segwit 的舊錢包可以發送可以使用 segwit 花費的資金，允許接收者獲得 segwit 的好處。

沒有這兩個因素，額外負擔在 P2WPKH 的 -3 位元組和 P2WSH 的 +1 位元組時可以忽略不計。

第一個因素背後的動機在透過 pay-to-script-hash (P2SH) 增加多重簽名的安全性下討論。

第二個因素是個別使用者在發布接收地址時可以做出的權衡，選擇 P2WPKH/P2SH 或 P2WSH/P2SH 的使用者將按額外負擔的比例支付更高的費用。這應該會在長期內自然限制這種額外負擔的影響。

未來減少

透過變更網路和儲存序列化格式，可以使這種額外負擔的大部分消失：完整序列化可以從指示正在使用哪種格式的簡單標誌（P2PKH、P2WPKH、P2WPKH/P2SH 等）以及實際資料（公鑰和簽名）中恢復。（例如，compacted_txn.txt）

區塊驗證成本

使用 segwit，在驗證區塊時引入了額外的處理，以檢查見證默克爾樹和處理 P2SH 編碼的見證交易。這需要每個交易大約五個額外的 SHA256 雜湊，每個 P2SH 編碼的 P2WSH 輸入一個額外的 SHA256，每個 P2SH 編碼的 P2WPKH 輸出一個額外的 HASH160。然而，這僅相當於對最多 4MB 資料進行大約六次 SHA256 執行，或總共大約 24MB 的 SHA256 資料，這在 Raspberry Pi v1 上應該轉化為每個區塊最多額外 15 秒，或在更強大的硬體上不到 1/10 秒。

引入錯誤的風險

segwit 補丁集是對 Bitcoin 的重大變更，並在 Bitcoin Core 0.13.0 中推出，儘管未在主 Bitcoin 網路上啟動。任何這樣的重大變更都會帶來各種風險，包括：

徹底的錯誤：設計或實作中可能犯錯誤，產生意外或有害的結果。例如 PR#8525。
使用者錯誤：對系統的變更可能導致使用者混淆，導致系統的不正確使用，這反過來可能導致有害的結果。
生態系統互動：Bitcoin 生態系統的不同部分可能有硬編碼的假設，這些假設將隨著更新而被違反。例如，解析 bitcoind 的區塊儲存的應用程式將需要更新以理解新的序列化。

避免

為了減少 segwit 啟動時這些風險發生的機會，已採取以下步驟：

同儕審查：segwit 中的所有變更，包括設計和實作，都已公開展示並由多位獨立專家審查；通常會導致建議的改進被採納。

公開展示包括：
- Elements Project
- Scaling Bitcoin 香港
- SF Bitcoin Devs
- Scaling Bitcoin 米蘭
- BIP141、 BIP142、 BIP143、 BIP144 和 BIP145
技術審查包括：
測試案例：如下一步文章中所述，「對共識規則和 P2P 網路程式碼的組合變更包含 1,486 行新增或修改的程式碼。segwit 補丁還包括單元和整合測試中的額外 3,338 行新增或修改的程式碼，這些測試有助於確保 segwit 在 Bitcoin Core 程式的每次完整建置時都能按預期運作。」
測試網路：在開發期間，隔離見證已部署在多個測試網路上，允許程式碼被審查，並且來自更廣泛生態系統的開發者（例如區塊瀏覽器和錢包）確保他們的軟體與隔離見證正確互操作。這些測試網路包括：
- Elements Project – 測試了作為硬分叉實作的隔離見證概念，以及許多其他變更
- segnet1 到 segnet4 – 在 2016 年 1 月至 5 月期間測試了 segwit 作為軟分叉的實作
- testnet3 – segwit 於 2016 年 5 月在標準測試網上啟動
替代實作：segwit BIP 已在 btcd（Go）和 Bcoin（Javascript）中重新實作，以及在各種錢包和程式庫中。獨立重新實作有助於消除設計中未明確的假設和模糊性，並避免可能由此產生的錯誤。

減輕

減輕任何錯誤影響的一個主要因素是 segwit 作為軟分叉實作。這意味著：

Bitcoin 的使用者可以簡單地避免使用新引入的功能，直到他們個人確信它們被正確實作，而不會失去任何功能。
所有有效的 segwit 區塊對於 pre-segwit 軟體也是有效的區塊，因此可以使用不包含 segwit 變更的早期版本 Bitcoin（因此不包含這些變更中引入的任何錯誤）來驗證區塊，以提供針對共識回歸可能性的第二級保證。

此外，「腳本」語言版本控制的可能性引入了修復 Bitcoin 腳本語言中錯誤的可能性，包括預先存在的錯誤以及 segwit 可能引入的任何潛在新錯誤。

與複雜性和技術債務相關的風險

技術債務的概念是，現在的簡單修復可能會在長期內造成足夠的困難和問題，以至於現在花更多的時間和精力將證明更經濟。

在 Bitcoin 的背景下，有兩種類型的技術債務：

醜陋或複雜的程式碼，可以在不影響使用者或共識的情況下重構；以及
不良的設計決策，其中許多必須無限期保留，否則 Bitcoin 使用者將失去對其現有代幣的存取權。

避免

如上所述，segwit 程式碼已經過大量審查，這有助於抵制在程式碼和設計層面引入技術債務。

同樣如上所述，segwit 有多個獨立的重新實作，這有助於在仍可避免的時候發現任何不必要的複雜性和技術債務。

為了支援現有的透過重構和改進 Bitcoin 程式碼庫來償還技術債務的努力，segwit 作為僅程式碼更新合併，作為0.13.0 版本工作的一部分。

減輕

Bitcoin 已經遭受了一些重大的設計債務，segwit 專門設計用於減少這些債務的影響（特別是交易可塑性、簽名雜湊的二次方擴展和未簽名的輸入值）。

segwit 提供的腳本版本控制方法提供了一種優雅的方式，允許未來的軟分叉更新進一步減少設計債務，包括透過修復現有操作碼中的錯誤（例如 CHECKMULTISIG）、重新啟用停用的操作碼（例如 CAT），或切換到優越的驗證方法（例如 Schnorr 簽名或聚合簽名）。

一般來說，Bitcoin 腳本中的設計債務無法完全償還，因為總是有可能存在一些未花費的交易支付到利用「醜陋」功能的 P2SH 地址。停用這些功能將使這些交易無法花費，實際上從使用者那裡竊取資金。腳本版本控制允許減少這種設計債務的「成本」，透過將這種「醜陋」功能劃分為僅適用於「舊」腳本版本，從而允許新的開發工作在很大程度上忽略舊程式碼。

與軟分叉部署相關的風險

軟分叉是對 Bitcoin 共識規則的任何變更，使先前有效的某些交易集無效。處理不當的軟分叉可能在 Bitcoin 生態系統中造成許多問題，並且，因為 segwit 使額外的見證資料對於建立 Bitcoin 的分散式共識至關重要，處理不當的升級可能導致系統以額外的方式失敗。主要的潛在失敗模式包括：

使某些 Bitcoin 持有者無法花費他們的錢
導致舊節點和升級節點對哪些未確認交易有效且可能被挖掘有不同的看法
礦工錯誤地挖掘在新規則下無效的區塊
被啟動，有一些實際使用，然後被撤回
由於 p2p 網路實際上被斷開連接，導致大型區塊鏈分叉，因為透過無法轉發見證資料的舊節點的連接

避免

Bitcoin 中已經啟動了許多軟分叉（包括 BIP 16、34、65、66、68、112 和 113），這種經驗已被編纂在啟動軟分叉的 BIP9 流程中。BIP9 流程用於部署 CSV 軟分叉（BIP 68、112 和 113），並導致該變更的共識規則快速且無問題的升級。

segwit 設計和 BIP9 部署透過以下方式避免了上述問題：

segwit 施加的新限制僅影響目前沒有人會使用的交易，因為：
- 受影響的交易將是非標準的，因此不會被絕大多數節點中繼或被大多數礦工挖掘。
- 任何受影響的交易目前都會被視為明顯的「任何人都可以花費」付款，並且可以立即被任何監控區塊鏈的人領取，因此應該預期會「丟失」。
舊節點將認為花費 segwit 輸出的交易是非標準的，因為明顯違反了 BIP62 CLEANSTACK 規則，因此不會被包含在舊節點的 mempool 中。同樣，具有 P2WPKH 或 P2WSH 輸出（但不是透過 P2SH 編碼的 P2WPKH/P2WSH）的交易也將被視為非標準，因為它是新的輸出類型。

這使得透過舊節點中繼一個交易並透過 segwit 節點中繼不同的交易來實現 segwit 輸出的雙花變得不可能。

然而，這些差異仍然可能被用於嘗試雙花，例如透過在單個交易中組合非 segwit 輸出和 segwit 輸出（該交易將僅透過升級的 segwit 節點中繼），然後嘗試透過僅使用非 segwit 輸出的更高費用交易進行雙花，該交易可能透過舊節點成功中繼。

這些擔憂僅影響 mempool 中的未確認交易；一旦交易被確認並挖掘到區塊中，雙花仍然不可能。現有的監控雙花的方法應該保持同樣有效，前提是監控工具能夠完全追蹤 segwit 花費。
確保礦工挖掘有效區塊顯然是每個人的高度優先事項，並且已經投入了大量工作來保證 segwit 的情況如此。這包括 BIP145 下的直接工作，以及間接工作，例如緊湊區塊（BIP152）。
如果 segwit 軟分叉在啟動後被撤回，這可能允許任何進行 segwit 交易的人損失資金 – 例如，惡意礦工可以在沒有啟用 segwit 的鏈上重播交易，此時它將是任何人都可以花費的，然後礦工可以透過將其花費給自己來竊取資金。segwit 軟分叉在啟動後可以透過兩種方式撤回，同時允許竊取啟用 segwit 的交易：
- 礦工可以放棄啟用 segwit 的鏈，並從 segwit 啟動之前開始挖掘。基於 BIP9 啟動規則，這將需要放棄超過 2016 個區塊（LOCKED IN 期間，加上足夠的區塊以確保未達到 95% 的閾值）。這將要求礦工放棄超過 25,200 BTC 的區塊獎勵，按當前價格計算超過 15,000,000 美元。
- 礦工可以簡單地使用不識別 segwit 規則的軟體（例如 Bitcoin Core 的早期版本）在啟動了 segwit 的鏈頂部挖掘區塊。就 segwit 感知軟體而言，這將是硬分叉，因此使用 segwit 感知驗證節點的 Bitcoin 使用者將忽略這些區塊。如果有足夠多的使用者使用 segwit 節點，這樣的硬分叉將不會比引入新的 alt coin 更有效。
因此，這兩種方法似乎都不太可能。
已經投入了大量工作以確保啟用 segwit 的對等方將形成 Bitcoin P2P 網路的強連接子圖。這包括為啟用見證的節點提供專用的服務位元，並優先連接到這些節點。

由於更大的區塊而產生的風險

Segwit 將 1MB 區塊大小限制更新為 4M 單位區塊權重限制，將序列化的見證資料計為一個單位，將核心區塊資料計為四個單位。隨著使用 segwit 功能的交易開始被使用，此變更將允許每個區塊包含更多資料（如果 100% 的交易使用 segwit 功能，預計每個區塊約 2MB 資料，但在最壞的情況下可能高達每個區塊 4MB 資料）。就其允許更大的交易量而言，可以預期它將更快地增加 UTXO 資料庫（如果 100% 的交易使用 segwit 功能，增長率可能預期大約翻倍；但是因為 segwit 是軟分叉，最壞情況的 UTXO 增長是不變的）。

這些結果可能有積極的屬性（例如更多的交易量允許更多的使用者採用），但也有可能顯著的負面影響：

更大的區塊可能導致更慢的區塊傳輸，導致礦工的孤塊率更高 – 這反過來可能導致更低的安全性（控制網路所需的雜湊算力更少），或更高的中心化（較大的礦工更能夠降低其孤塊率）。
更大的區塊將導致完整節點的資源需求更高，可能導致使用者關閉他們的節點，這將導致更高的中心化。
更大的 UTXO 集將導致礦工的資源需求更高，可能導致礦工共享驗證資源，這將導致更高的中心化。

避免

更大區塊的負面影響以多種方式受到限制：

由於部署 libsecp256k1，區塊的驗證時間已顯著減少。
透過 BIP152 部署緊湊區塊有助於限制更大區塊對區塊傳輸的影響，因此對孤塊率的影響，也減少了完整節點的頻寬使用。
剪除支援允許使用者執行完整節點而無需儲存整個區塊鏈歷史，這允許資源受限儲存的使用者繼續執行完整節點，即使區塊大小更大。
segwit 簽名使用的簽名雜湊演算法的變更以避免二次方擴展，為某些大型交易提供了成本的顯著降低。

增加的 UTXO 增長的負面影響受到以下限制：

將 segwit 部署為軟分叉，以確保最壞情況的 UTXO 增長不會變得更糟。
見證資料的權重降低以重新平衡 UTXO 的生命週期成本，降低引入花費 segwit 輸出的額外輸入的成本，因此（相對地）增加引入建立新 UTXO 的額外輸出的成本，將建立/花費成本比率從約 1:4.5 變更為約 1:2。這應該透過阻止 UTXO 建立和鼓勵 UTXO 花費來適度減少增加 UTXO 集的激勵。

減輕

由於每個區塊的最大資料量上限為不超過當前速率的四倍，因此解決大型區塊引起的問題的減輕工作應該在相對直接的工程工作範圍內。此外，由於預期每個區塊的資料量僅約為當前速率的兩倍，這意味著任何必要的減輕努力應該進一步簡化。
正在進行的工作是改進交易和區塊的磁碟和網路序列化，進一步減少執行完整節點的儲存和頻寬需求。

由於較低費用而產生的風險

Bitcoin 區塊鏈的安全性由雜湊算力提供，該算力由固定的區塊獎勵和來自個別交易的費用獎勵。因此，費用收入的減少有可能減少用於挖掘 Bitcoin 的雜湊算力，這反過來可能降低 Bitcoin 區塊鏈的安全性。

就個別交易費用由市場力量和供需決定而言，segwit 引入的變更可能透過增加供應（假設需求不會也上升，無論是因為還是至少與 segwit 部署同時）來降低價格的風險，較低的個別價格可能導致較低的整體挖礦收入（如果需求的價格彈性在非彈性範圍內）。

此外，segwit 中所做的變更可能使「第二層」解決方案（例如閃電網路）更具吸引力。如果這導致使用者將第二層解決方案視為鏈上交易的替代品，這可能會顯著降低對鏈上交易的需求，這將對交易費用水平施加額外的下行壓力。

避免

費用目前約為每個區塊 0.5 BTC，而區塊補貼為每個區塊 12.5 BTC，約為礦工收入的 4%，因此對礦工收入的潛在影響以及網路安全性在短期內可能很小。

此外，在過去十二個月中，費用在 BTC 計價值（從一年前的每個區塊不到 0.2 BTC）和實際價值（從一年前的每 BTC 不到 300 美元到今天的每 BTC 超過 600 美元）方面都在上漲，因此費用水平的適度下降只會相當於回到最多十二個月前的費用收入，這應該不會是重大影響。

減輕

礦工能夠個別和集體限制供應，無論是透過個別設定他們生產的區塊的最大權重的軟限制（「blockmaxweight」設定，預設為 3M），還是透過集體使用軟分叉透過孤立超過特定權重的區塊來有效降低共識限制。這種方法有可能防止由於供應增加而導致的任何費用減少（或者確實透過減少供應來增加個別費用，儘管這可能不會增加整體收入），但無法防止由於替代效應（例如採用第二層網路）而導致的費用收入減少。

雖然第二層網路可能充當鏈上交易的替代品，但它們無法完全避免鏈上交易，在某些情況下，即使來自第二層網路的這些相對較少的鏈上交易也可以輕易地在啟用 segwit 的情況下飽和鏈上容量。即使只有這些網路價值的非常小的一部分透過鏈上交易費用捕獲，這也可能大大高於當前的費用價值。

與長期擴展相關的風險

如上所述，所有交易完全採用 segwit 預計將容量大約翻倍。這在短期或中期提供了顯著的一次性容量增加，取決於採用速度。此外，透過新增功能以啟用第二層網路，可能實現一些額外的中期和長期擴展。透過修復二次方 sighash 擴展錯誤，segwit 還減少了由於未來容量增加而產生負面影響的風險。

然而，segwit 並沒有提供任何直接機制來進一步擴展鏈上交易量，除了那一次性的翻倍。

這存在長期擴展方法可能被阻止或延遲的風險：利害關係人可能認為 segwit 是「足夠的」擴展並拒絕進行或支援進一步的擴展努力。

避免

避免這種風險的努力包括：

在 2015-12-07 容量增加路線圖中納入「適度區塊大小增加提案」
在同一路線圖中納入「彈性上限或激勵一致的動態區塊大小控制」。
在 segwit 中包含功能以使後期擴展風險更低，特別是簽章操作的線性擴展和邁向單一組合區塊限制。
研究更有效地使用區塊空間的技術，例如使用 Schnorr 簽名和簽名聚合
研究區塊鏈的替代模型，維持去中心化和安全性，但具有更好的可擴展性屬性，例如 Mimblewimble、Braiding 和 Jute Braiding。

此外，使 segwit 允許的規模增加可實現的工作（例如 libsecp256k1 和緊湊區塊）顯然也使進一步的潛在規模增加更可實現。

減輕

Segwit 在任何技術層面上都沒有使進一步的擴展更加困難 – 這裡的風險完全是社會性的。因此，最有效的減輕努力也可能是社會性質的：例如透過讓支援長期擴展的公司投入開發資源來實現這一點。

segwit 使交易量增加到大約當前水平的兩倍也提供了展示擴展的實際影響的機會，例如對節點效能、去中心化和交易需求的影響，以及生態系統升級可以進行的速度。這些資料可以合理地收集並用於支援未來的擴展努力，無論是透過顯示某些擔心的結果不太可能發生，還是透過確認有效的擔憂並允許工作集中於解決這些擔憂。

替代方法

本節提供與實現 segwit 的部分或全部好處的一些替代方法的簡要比較，以及這些不同方法如何可能改變所涉及的成本和風險。

硬分叉的 segwit

任何 segwit 的硬分叉實作都會增加顯著的新成本和風險，因為需要所有節點在啟動之前升級以理解新規則，並有可能分叉成「舊 Bitcoin」和「新 Bitcoin」，從而導致混淆和價值損失。由於 Bitcoin 社群對硬分叉的經驗相對缺乏，可能還會出現意外的風險和成本，儘管這顯然很難分析。

segwit 的硬分叉實作實際上可以以兩種方式進行：

SPV 不可見：如果見證承諾從 coinbase 移至區塊交易默克爾樹，大多數非驗證客戶端和錢包將繼續工作而無需升級。這將節省 coinbase 交易中的 38-47 位元組，但不提供任何其他優勢。
SPV 可見：如果變更交易雜湊的計算以排除 scriptSig，這可能允許更簡單的實作，並減少每個交易的額外負擔；然而，它將使所有現有的 Bitcoin 軟體在更新之前無法處理這些交易。此外，需要保留管理舊式交易的單獨程式碼路徑，增加程式碼複雜性和錯誤的可能性。BIP 134，彈性交易提出了一種替代方法，透過 SPV 可見的硬分叉獲得 segwit 的一些好處。

任何一種硬分叉方法都可能同時大幅改變區塊的共識限制。

更簡單的 segwit

segwit 的許多好處在邏輯上可以分為獨立的變更，並單獨評估和部署。然而，各種功能的實作需求密切相關：

簽章操作的線性擴展：CHECKSIG 和 CHECKMULTISIG 操作碼需要替換。
輸入值的簽名：CHECKSIG 和 CHECKMULTISIG 操作碼需要替換。
透過 P2SH 增加多重簽名的安全性：P2SH 支付格式需要替換。
腳本版本控制：P2SH 支付格式需要替換。

獨立進行這些修復將增加 Bitcoin 程式碼庫的複雜性，因為需要處理在區塊鏈上的不同時間啟動不同功能；而同時部署它們則消除了這種複雜性。

因為由於現有 CHECKSIG 和 CHECKMULTISIG 操作碼的簽章操作的二次方擴展，增加容量是危險的，因此需要對這些操作施加一些限制。由於 segwit 僅允許透過更新的操作碼增加簽名操作，舊操作碼自然保持受限。相反，如果獨立應用容量增加，則需要實作額外的限制以確保增加是安全的，可能會增加挖礦和費用計算的複雜性。

隔離見證升級指南

Wed, 26 Oct 2016 00:00:00 +0000

在 Bitcoin Core 0.13.1 中發布的 segwit 版本經歷了近兩年的迭代設計、開發和測試，過去一年的大部分精力都集中在讓現有的 Bitcoin 使用者、企業、開發者和礦工盡可能輕鬆地升級到 segwit。

初始 segwit 採用需要兩個群體的參與：

礦工代表 95% 或更多的 Bitcoin 網路總算力必須發出支援 segwit 的信號，以便鎖定 segwit 的啟動。
全節點由合理數量的使用者和企業執行以驗證其接收的支付，需要升級到 Bitcoin Core 0.13.1 或更高版本，或另一個 segwit 相容實作，以便在 segwit 啟動後激勵礦工遵循 segwit 的規則。（這是 Bitcoin 的正常激勵機制，礦工只有在遵循所有共識規則時才能獲得區塊收入，一旦 segwit 啟動，這將包括新的 segwit 共識規則。）

segwit 軟分叉的設計允許這兩個群體的個人自願決定是否要採用 segwit，下面為想要採用 segwit 和不想採用的人提供了指南。

如果足夠多的礦工確實決定採用 segwit，它最終將啟動，錢包使用者將能夠開始建立帶有隔離見證的交易。segwit 軟分叉也被設計為與所有常用錢包向後和向前相容，因此錢包開發者和使用者也可以獨立決定是否要採用 segwit 或繼續進行不帶隔離見證的交易。下面為採用和不採用的開發者和使用者提供了指南。

除了說明之外，以下每個指南章節的末尾還提供了一個簡短的推薦列表，列出了您可能遇到的任何 segwit 相關問題的詢問地點。

礦工

本節是為獨立礦工和礦池營運商撰寫的。礦池礦工應聯繫其礦池營運商，以了解他們需要做什麼（如果有的話）才能升級或不升級到 segwit。

BIP9 軟分叉部署機制被用於 segwit——與 2016 年 7 月 4 日啟動的 BIP 68/112/113 軟分叉相同的機制。無論您是否希望升級，您都應該了解升級過程的重要階段：

已開始： Segwit 將在 2016 年 11 月 15 日或之後的第一個重定目標期開始時處於已開始階段，直到它啟動或被認為失敗（根據 BIP9 的政策），在一年內未達到鎖定後。在此期間，願意並能夠強制執行 segwit 新共識規則的礦工將透過在區塊標頭 versionbits 欄位中放置位元 1 來發出他們這樣做的意圖信號。
已鎖定： 如果在 2,016 個區塊的重定目標期間，95% 的區塊發出支援 segwit 的信號，segwit 軟分叉將被鎖定，並計劃在 2,016 個區塊後（約兩週）啟動。
已啟動： 在已鎖定期間結束後，發出準備強制執行 segwit 信號的礦工將開始產生包含帶有隔離見證的交易的 segwit 樣式區塊。

升級

segwit 軟分叉的 BIP9 參數允許礦工在 2016 年 11 月 15 日或之後的第一個重定目標期開始時開始發出支援信號。要發出支援信號，您需要執行以下操作：

將您用於交易選擇和區塊建構的全節點升級到 Bitcoin Core 0.13.1+ 或另一個 segwit 相容的全節點。
將您的挖礦軟體、礦池軟體或兩者都升級到 segwit 相容版本。
開始產生包含 segwit 的 BIP9 versionbit（即位元 1）的區塊。

當 segwit 啟動時，您將希望能夠挖掘和中繼 segwit 樣式區塊。以下挖礦軟體已升級以支援 segwit。

全節點：
- Bitcoin Core 0.13.1 或更高版本
- Bitcoin Knots 0.13.1 或更高版本
- Btcd*
挖礦軟體：
- BFGMiner*
- CGMiner
- libblkmaker*
礦池軟體：
- ckpool
- Eloipool
- Stratum-Mining*
中繼軟體：
- Bitcoin FIBRE

請注意，支援 GetBlockTemplate (GBT) RPC 的軟體必須升級以支援對 GBT 的 BIP9 和 BIP145 變更。上面連結的所有支援 GBT 的程式都已升級。

Segwit 已經在測試網上啟動並強制執行，因此您可能會發現在測試網上使用少量算力進行挖礦來測試您的基礎設施升級很有用。或者，Bitcoin Core 0.13.1 的回歸測試模式（regtest）預設也支援 segwit。

有疑問？ 歡迎獨立礦工和礦池營運商在 irc.freenode.net 的 #bitcoin-mining 中尋求幫助。礦池礦工應聯繫其礦池營運商以了解有關礦池關於 segwit 的政策的任何問題。

不升級

本節描述了如果您不想強制執行 segwit，作為礦工可以做什麼。

在已開始階段，如果您不想採用 segwit，您可以簡單地拒絕升級到 segwit 相容的全節點（例如 Bitcoin Core 0.13.1 或更高版本），以及避免使用任何假設您想要設定 segwit 的 versionbit 位元 1 的挖礦軟體。

如果 segwit 達到已鎖定，您仍然不需要升級，但強烈建議升級。segwit 軟分叉不要求您產生 segwit 樣式區塊，因此您可以無限期地繼續產生非 segwit 區塊。但是，一旦 segwit 啟動，其他礦工可能會產生您認為有效但每個強制執行 segwit 的節點都拒絕的區塊；如果您在這些無效區塊上建立任何區塊，您的區塊也將被視為無效。

因此，在 segwit 達到已鎖定後，建議您升級您的全節點到 Bitcoin Core 0.13.1 或更高版本（或相容的全節點），或者您遵循下面全節點章節中的「不升級」說明，使用 Bitcoin Core 0.13.1 或更高版本作為您 pre-segwit 軟體的過濾器。

全節點使用者

本節是為任何操作全節點的人撰寫的，包括企業和個人。

全節點防止其使用者接受違反任何 Bitcoin 共識規則的任何區塊。在像 segwit 這樣的軟分叉升級中，會新增新規則，任何不升級的節點都不會知道這些新規則。這不是問題：segwit 軟分叉的設計允許未升級的使用者像軟分叉之前一樣繼續使用 Bitcoin。

但是，任何想要使用 segwit 軟分叉啟用的功能的人都會希望知道，足夠數量的全節點使用者已經升級了他們的節點以拒絕違反 segwit 規則的區塊和交易，從而為礦工遵循 segwit 的更新共識規則提供強烈的激勵。

這個系統在過去運作良好，在之前幾個軟分叉啟動之前，至少有 25% 的可達節點（通常為 50% 或更多）已升級（不計算 BIP50 緊急和臨時軟分叉）。沒有理由期望 segwit 軟分叉會有任何不同，升級是支援 segwit 的人幫助鼓勵其採用的簡單方法。當然，對 segwit 不感興趣的人可以簡單地不升級。以下描述了兩種情況的詳細資訊。

升級

要升級到 segwit 相容版本，請下載您的全節點軟體的 segwit 相容版本（例如 Bitcoin Core 0.13.1 版本），確保您下載的檔案是合法的（使用 PGP 或其他方法），停止舊版本的節點軟體，然後啟動新版本的軟體。請注意，如果您在 segwit 啟動後升級，您的節點將需要從啟動點向前下載和重新同步區塊，因為舊版本沒有完全下載它們。

您可以使用 Bitcoin Core RPC getblockchaininfo 來追蹤 segwit 軟分叉的狀態（在 BIP9 樣式軟分叉清單中標記為 segwit）。此資訊包括有多少近期區塊是由發出打算強制執行 segwit 新共識規則的礦工產生的。getblockchaininfo RPC 的結果還將讓您確定 segwit 的軟分叉何時被鎖定（意味著它將在接下來的 2,016 個區塊內啟動）和啟動（意味著它現在由礦工強制執行）。

Bitcoin Core 0.13.1 提供的錢包預設將繼續僅產生非 segwit P2PKH 位址以接收支付。預計後續版本將允許使用者選擇接收支付到 segwit 位址。

如果您是想要產生位址進行測試的開發者或專家使用者，請參閱 segwit dev guide。

有疑問？ 如果您使用 Bitcoin Core 作為您的全節點，請參閱 Bitcoin.org 上的取得幫助頁面以獲取各種支援選項。如果您使用另一個全節點，最好的詢問地點是您的全節點軟體使用者尋求支援的地方。您的軟體維護者至少會熟悉 segwit 背後的想法，他們將能夠告訴您何時會實作它以及它將如何影響您。

不升級

如果您不想升級到 segwit 並且您不是礦工，您可以簡單地繼續使用您當前的全節點軟體。Segwit 實作為軟分叉，因此您不需要升級。您也不需要升級連接到您全節點的任何錢包；它們將像以前一樣繼續工作（有關詳細資訊，請參閱下面的錢包章節）。

但是，如果您接受確認區塊較少的交易（例如一個或兩個區塊），請注意，在軟分叉啟動後，未升級的全節點暫時接受無效區塊的風險會略微增加。隨著升級的礦工繼續強制執行新的 segwit 共識規則，情況將在幾個區塊內自行解決，但不能保證在無效區塊中顯示為已確認的交易將繼續在有效區塊中得到確認。

防止此問題的最簡單方法是升級到 Bitcoin Core 0.13.1 或更高版本，或另一個與 segwit 軟分叉相容的全節點版本。如果您仍然不想升級，可以使用較新的 Bitcoin Core 版本作為較舊 Bitcoin Core 版本的過濾器。

在此配置中，您將當前的 Bitcoin Core 節點（我們稱之為「較舊節點」）設定為僅連接到執行 Bitcoin Core 0.13.1 或更高版本的節點（我們稱之為「較新節點」）。較新節點像往常一樣連接到 Bitcoin P2P 網路。因為較新節點知道 segwit 對共識規則的變更，它不會將無效區塊或交易中繼到較舊節點——但它會中繼其他所有內容。

使用此配置時，請注意，如果較舊節點使用 Bitcoin Core 預設值，它將不會看到使用 segwit 功能的交易，直到這些交易被包含在區塊中。

配置：

對於較新節點，正常啟動它並讓它同步區塊鏈。目前，您不能將修剪節點用於此目的，因為修剪節點不會作為中繼節點。您可以選擇使用以下一個或兩個命令列參數啟動較新節點，以便它將較舊節點視為特殊（這些選項也可以放在 Bitcoin Core 的配置檔案中）：

  -whitebind=<addr>
       綁定到給定位址並將連接到它的對等點列入白名單。使用
       [host]:port 表示法表示 IPv6

  -whitelist=<netmask>
       將從給定網路遮罩或 IP 位址連接的對等點列入白名單。可以
       多次指定。列入白名單的對等點不能被 DoS 封禁
       並且它們的交易總是被中繼，即使它們已經
       在記憶池中，例如對閘道很有用

對於較舊節點，首先等待較新節點完成同步區塊鏈，然後使用以下命令列參數重新啟動較舊節點（這也可以放在 Bitcoin Core 配置檔案中）：

-connect=<較新節點的 IP 位址或 DNS 名稱>

例如，

-connect=192.168.8.8

這將導致較舊節點僅連接到較新節點，以便所有區塊和交易都由較新節點過濾。

錢包使用者

本節是為使用輕量級錢包、網頁錢包、連接到個人全節點的錢包或任何其他錢包的任何人撰寫的。

升級

如果您確實想升級到 segwit，您首先需要等待礦工啟動 segwit，然後您需要一個支援接收和花費 segwit 樣式支付的錢包。這適用於 Bitcoin Core 的錢包、輕量級錢包，以及第三方代表您發送和接收比特幣的錢包（有時稱為網頁錢包）。Bitcoin Core 或其他全節點的使用者也應該閱讀上面有關全節點的章節。

在您的錢包升級以支援 segwit 後，它將產生以「3」開頭的接收位址（P2SH 位址）。有些錢包多年來一直在產生 P2SH 位址，因此這對您來說可能不是變化。

所有常用錢包都能夠支付 P2SH 位址，因此您將能夠從任何常見錢包接收支付，無論它們是否已升級到 segwit。升級到 segwit 後花費您的比特幣時，您仍然能夠支付以「1」開頭的原始類型 Bitcoin 位址（P2PKH 位址），以及能夠支付其他 P2SH 位址的使用者。

使用 segwit 錢包花費您的比特幣時，您會注意到以下情況：

當僅花費您在升級前收到的比特幣時，您應該注意到與升級前建立的交易沒有差異。
當將升級到 segwit 後收到的比特幣花費給尚未升級到 segwit 的人時，他們可能要等到交易被包含在區塊中後才能看到您的交易。這是一個安全功能，可避免向他們顯示他們的錢包不完全理解的交易，直到這些交易得到確認。交易確認後，他們將能夠像正常一樣看到和花費您發送給他們的比特幣。
當花費您升級後收到的新 P2SH 位址的比特幣時，您可能會注意到您支付的交易手續費略低於花費您之前收到的非 segwit 支付時。這是因為包含您簽名的交易部分（「見證」）不需要被 Bitcoin 全節點快速存取，所以 segwit 允許礦工在區塊中儲存最多 4 倍的見證位元組，而不是非見證位元組。這更好地將建立區塊的成本（因此其交易手續費）與操作全節點的實際成本相一致。

有疑問？ 如果您有任何問題，最好的詢問地點是您的錢包使用者尋求支援的地方。您的錢包維護者將熟悉 segwit 背後的想法，他們將能夠告訴您是否會為您的錢包實作 segwit、何時可能發生以及它將如何影響您對錢包的使用。

不升級

如果您不想升級到 segwit，您可以簡單地繼續使用任何尚未新增 segwit 支援的錢包。即使您沒有升級，您也將能夠與已升級到 segwit 的使用者以及像您一樣尚未升級到 segwit 的使用者進行交易。

如果您不升級，您可能會遇到一個差異：如果已升級到 segwit 的人向您付款，您的錢包可能要等到支付被包含在區塊中後才會向您顯示。這是一個安全功能，可防止您的錢包看到它不完全理解的交易，直到它們被礦工確認。

Bitcoin 軟體開發者

本節是為處理交易或區塊的任何 Bitcoin 軟體開發者撰寫的。

所有 Bitcoin 軟體（包括挖礦軟體，前提是它僅選擇遵循預設中繼政策的交易）都應該像以前一樣繼續工作，並且只有在您想要利用 segwit 的新功能時才需要升級您的軟體。

Segwit 在以下文件中為開發者進行了描述：

Segwit 錢包開發者指南： 您需要了解的所有內容的摘要描述，以升級您的錢包以支援 segwit。
BIP141 隔離見證（共識層）： 尋求實作 segwit 任何方面的開發者應閱讀本文件的規範章節。挖礦和全節點軟體的開發者將在部署章節中找到 segwit 的 BIP9 參數。
BIP143 版本 0 見證程式的交易簽名驗證： 希望建立或驗證 segwit 簽名的任何軟體開發者應閱讀本文件的規範章節，並建議使用範例章節進行測試。
BIP144 隔離見證（對等服務）： 尋求透過 Bitcoin P2P 網路發送或接收隔離見證的開發者應閱讀本文件的規範章節。
BIP145 隔離見證的 getblocktemplate 更新： 挖礦和其他產生或使用 GetBlockTemplate RPC 的軟體開發者應閱讀 BIP145 和 BIP9 中的相關 GBT 變更。
BIP147 處理虛擬堆疊元素可塑性： 錢包開發者，尤其是新交易腳本開發者，應該了解這個新的共識規則，它反映了一個長期存在的預設網路中繼政策，禁止將除 OP_0「null」操作碼以外的任何內容作為「虛擬」參數傳遞給 checkmultisig 樣式操作碼。在 segwit 啟動後，這個新的共識規則將適用於使用 segwit 和不使用 segwit 的交易。
VersionBits FAQ： 礦工和挖礦軟體開發者應閱讀此常見問題以獲取有關設定其 versionbits 以發出支援軟分叉的信號的資訊。Segwit 使用位元 1 作為 versionbits。

請注意，BIP142（隔離見證的位址格式）處於延期狀態（如 BIP1 所定義），並未作為標準提出。相反，邀請錢包開發者在 bitcoin-dev 郵件列表上討論建立一個新的 Bitcoin 位址格式，該格式將比當前的 base58check 編碼位址更易於使用。

BIP 141、143、144 和 145 的大多數實作詳細資訊可在 Bitcoin Core PR#8149 中找到。BIP147 的實作可在 Bitcoin Core PR#8636 中找到。

為了在啟用 segwit 的網路上測試變更，測試網（testnet3）已經支援 segwit 數月，並包括大量 segwit 區塊，包括幾乎達到 segwit 允許的最大區塊大小的區塊。Bitcoin Core 的回歸測試（regtest）模式在 Bitcoin Core 0.13.0 和 0.13.1 中預設也支援 segwit。

除了 Bitcoin Core 之外，許多自由和開源軟體 Bitcoin 錢包和套件也已經新增了 segwit 相容性或準備好部署 segwit 相容程式碼，因此，如果它們的著作權授權與您的程式碼相容，您可以使用它們的程式碼變更作為更新您軟體的範例。

有疑問？ Bitcoin 開發問題可以在 irc.freenode.net 的 #bitcoin-dev IRC 聊天室中詢問。問題也可以在 Bitcoin.StackExchange.com 和 BitcoinTalk.org 技術討論板上詢問。

隔離見證：下一步

Fri, 24 Jun 2016 00:00:00 +0000

概覽

背景
如何測試 segwit
緊湊區塊
部署計劃
segwit 將如何影響您
segwit 使未來升級更容易
- Schnorr 簽名
- MAST

隔離見證（segwit）即將發布。本文提供一些背景資訊、關於如何測試 segwit 的詳細資訊、關於升級預期如何進行的資訊，以及 segwit 使實作變得更容易的一些未來功能的描述。

背景

Segwit 是一個提案，允許生產交易的軟體將交易簽名（見證）與交易中的其餘資料分離（隔離），並允許礦工將這些見證放置在傳統區塊結構之外。這提供了兩個直接好處：

消除可塑性：隔離見證允許接收交易的現有軟體和升級軟體在不參照見證的情況下計算使用 segwit 的交易的交易識別碼（txid）。這解決了所有已知的不需要的第三方交易可塑性情況，這是一個使 Bitcoin 錢包軟體程式設計更加困難的問題，並嚴重複雜化了 Bitcoin 智慧合約的設計。
容量增加：將見證資料移至傳統區塊結構之外（但仍在新式區塊結構內）意味著新式區塊可以容納比舊式區塊更多的資料，允許交易資料量的適度增加。

Segwit 還簡化了向 Bitcoin 新增新功能的能力，並提高了完整節點的效率，這提供了長期好處，將在本文件後面更詳細地描述。

有關 segwit 的更多資訊，請參閱我們的 FAQ 或 BIP 141、143 和 144。

如何測試 segwit

Segwit 變更了 Bitcoin 系統的幾個部分，最值得注意的是完整驗證節點用來就 Bitcoin 帳本狀態達成一致的共識規則。如果節點停止就帳本狀態達成一致，那麼接收新的 Bitcoin 交易就變得不安全，因此 Bitcoin 開發者應該謹慎進行任何此類變更，並對任何此類提議的變更進行廣泛的測試。

同樣重要的是用於中繼區塊和交易的點對點網路程式碼的變更。由於 segwit 交易和區塊的組織方式與早期交易和區塊版本不同，因此確保網路實作既可以向 segwit 節點中繼 segwit 資料，也可以向舊節點中繼舊式資料很重要。

這些對共識規則和 P2P 網路程式碼的組合變更包含 1,486 行新增或修改的程式碼。segwit 補丁還包括單元和整合測試中的額外 3,338 行新增或修改的程式碼，這些測試有助於確保 segwit 在 Bitcoin Core 程式的每次完整建置時都能按預期運作。

除了超過 3,000 行新增的自動化測試程式碼外，segwit 還經過 Bitcoin 開發者的廣泛測試。本節僅描述他們在過去一年對不同版本的 segwit 進行的一些嚴格測試。

Segwit 最初由 Pieter Wuille 和其他幾位 Blockstream 開發者在 2015 年 4 月至 6 月在 Elements Project 側鏈上實作，作為不打算與先前 Bitcoin 軟體相容的「從頭開始」版本。這個版本已用於基於 Elements 的側鏈上的每一筆交易。
2015 年 10 月下旬，Luke Dashjr 描述了一種允許在 Bitcoin 中將 segwit 作為軟分叉實作的方法，Wuille 利用他在 Elements 版本方面的經驗開始開發這個新的實作，該實作與所有現有 Bitcoin 軟體向後相容（儘管程式確實需要升級才能完全理解 segwit）。
程式碼在 2015 年 12 月下旬在特殊的 segwit 專用測試網（稱為 segnet）上完全運作，允許實作者和測試者在多使用者環境中執行程式碼，也允許錢包作者測試他們生成 segwit 交易的程式碼。Segnet 經歷了幾次迭代，因為發現並修復了問題，並發現和實作了改進。
2016 年 4 月，經過四個月的積極開發和測試後，Wuille 向 Bitcoin Core 專案提交了一個拉取請求以供審查。
2016 年 5 月，Segwit 在 Bitcoin 的常規測試網上啟用，在那裡它不僅針對預期與 segwit 互動的其他軟體進行測試，還針對在 Bitcoin 測試網上定期測試且尚未為 segwit 升級的所有其他程式進行測試。
同樣在 2016 年 5 月，二十位 Bitcoin Core 開發者在瑞士會面進行（除其他事項外）segwit 程式碼的面對面審查，並確保測試覆蓋率足夠。
2016 年 6 月，在對原始拉取請求進行了近兩個月的非常積極的審查以及在 segnet 和測試網上的擴展運作後，Wuille 建立了一個第二個拉取請求，其中包含對原始拉取請求進行的所有改進，重新基於 Bitcoin Core 開發分支的最新版本，並專門格式化以使最終審查變得容易，並確保對原始拉取請求進行的所有審查保持有效。

隨著 segwit 的原始側鏈實作在過去一年中被許多審查者使用，Bitcoin 軟分叉實作在六個月內獲得嚴格的測試和審查，Bitcoin Core 開發者相信它現在已準備好投入生產。

緊湊區塊

Segwit 將允許 Bitcoin 礦工在他們建立的區塊中包含比現在更多的交易資料。這將增加中繼所有這些資料的 Bitcoin 完整節點的頻寬需求，並增加新區塊發布和節點接收之間的延遲（因為較大的資料量通常需要更長的時間來傳播）。為了幫助減少這些負面副作用，Bitcoin Core 開發者計劃為 Bitcoin Core 0.13 及更高版本提供緊湊區塊中繼。

Bitcoin 完整節點目前下載許多交易兩次：一次是當它們單獨接收交易時，第二次是當交易作為區塊的一部分接收時。緊湊區塊中繼可以透過僅向節點發送它們使用已接收的交易重建區塊所需的資訊來消除大部分（有時是全部）這種重複。

在樂觀情況下，這將節點使用的頻寬減少了近一半。由於 segwit 預期將最大容量增加到大約兩倍，這兩個改進大致相互平衡，使節點頻寬使用保持在大致與現在相同的水平。

更重要的是，緊湊區塊中繼有助於減少峰值頻寬負載。目前，必須一次下載大約 1 兆位元組的新接收區塊；當部署 segwit 時，這意味著可能需要下載 2 兆位元組或更大的區塊。在除最快的連接之外的所有連接上，這些頻寬峰值會損害使用者同時執行的其他服務的效能，例如遊戲或影片串流。使用緊湊區塊，使用者可以以穩定的流接收交易，然後使用區塊的小描述重建每個區塊，消除了給許多使用者帶來不便的頻寬峰值。

最後，透過減少宣布新區塊時需要發送的資料量，緊湊區塊中繼還實現了更好的區塊傳播速度。緊湊區塊中繼透過支援兩種運作模式來特別利用這一點，一種低頻寬模式針對減少頻寬進行了最佳化（儘管在大多數情況下它也提高了速度），一種高頻寬模式顯著提高了速度，並且仍然設法透過僅需要比低頻寬模式平均多 20 千位元組來大大減少峰值頻寬使用。

高頻寬模式被用作點對點區塊中繼最佳化的進一步開發的基礎。它特別適用於需要盡快接收區塊的礦工（特別是如果其他非點對點區塊中繼方法失敗），但具有額外頻寬的使用者也可以啟用此模式，以幫助更快地向礦工中繼區塊，並透過使哪些高頻寬節點由礦工執行和哪些由普通對等方執行變得不那麼明顯來幫助阻止拒絕服務攻擊。

部署計劃

以下計劃描述了 segwit 預期的部署方式。

合併到 master（不含主網啟動程式碼）：在 Bitcoin Core 開發者「ACK」（批准）最終 segwit 拉取請求後，它將被合併到 Bitcoin Core master Git 儲存庫分支中。正在合併的程式碼將包含 segwit 中的所有內容，除了啟動程式碼。這將使開發者可以輕鬆地在 segwit 之上測試其他功能，例如緊湊區塊。測試網上的啟動已經發生，因此使用者和開發者可以在測試網上實驗和測試 segwit。

回移到 0.12 分支：未啟動的程式碼將回移到 0.12 維護分支，回移將獲得自己的測試。

選擇 BIP9 參數：BIP9 是一種軟分叉部署機制，允許礦工發出他們準備好強制執行新共識規則的訊號。使用 BIP9 進行的每個軟分叉選擇礦工何時可以開始為軟分叉發出訊號，如果沒有足夠的礦工為其發出訊號則何時認為軟分叉不成功，以及區塊標頭版本欄位中的哪個位元將由礦工用於發出他們的準備訊號。這些參數將在此時選擇並與在 master 和 0.12 分支上啟動 segwit 的程式碼一起實作。

候選版本階段：在所有開發者測試成功完成後，將向願意測試程式碼的任何人公開提供候選版本（可能命名為 0.12.2RC1）。特別鼓勵礦工、商家和錢包供應商進行測試。如果發現任何問題，將進行修復並發布新的候選版本。這將根據需要重複，直到找到沒有已知問題的候選版本。

二進位發布：最終候選版本將其版本變更為最終發布版本（預期為 0.12.2），並將發布供所有使用者閒暇下載和開始執行（segwit 是軟分叉，因此僅當他們計劃使用 segwit 功能時才需要升級）。

礦工升級：選擇升級到 0.12.2 的礦工將能夠在達到定義為 segwit 的 BIP9 開始日期後開始生成發出準備強制執行 segwit 訊號的區塊。

鎖定：一旦在 2,016 個區塊長的重新定向期間中有 95% 的區塊發出其礦工準備好強制執行 segwit 的訊號，segwit 將鎖定 – 這意味著除非此時區塊鏈回滾，否則 segwit 將變為活躍（見下一點）。

啟動：segwit 鎖定後 2,016 個區塊（約兩週）後，它將啟動。這意味著所有執行 segwit 感知程式碼的完整節點將開始要求礦工強制執行新的 segwit 共識規則。

錢包升級：與 2012 年的 P2SH 軟分叉類似，在 segwit 啟動後，錢包立即升級以支援 segwit 並不安全。那是因為來自 segwit 交易的花費對舊節點來說看起來像不安全的交易，所以如果 segwit 啟動後不久區塊鏈被分叉，這些花費可能會被放置在不受 segwit 規則約束的較早區塊中。因此，建議錢包在 segwit 啟動後幾週內避免升級。允許額外時間過去為錢包使用者提供了額外的安全性，儘管任何想要用他們可以承受損失的少量錢進行測試的人都可以在 segwit 啟動後立即開始花費。使用者也可以使用測試網或 regtest 立即開始測試提議的 segwit 程式碼或（可用時）任何包含 segwit 的版本。

segwit 將如何影響您

礦工選擇執行 segwit 將有責任確保他們準備好透過將其完整驗證節點升級到 segwit 強制執行程式碼來強制執行它。當他們完成此操作並執行他們認為謹慎的任何測試時，他們可以開始發出支援 segwit 的訊號。
完整節點運營商可以繼續使用他們現有的節點，但建議他們升級到 segwit 強制執行版本。如果任何礦工最終在 segwit 啟動後根據 segwit 規則生成無效的區塊，升級的完整節點將自動拒絕這些區塊，確保這些升級的完整節點使用者看到準確的確認計數。

對於任何接受低確認數交易的人（例如企業）來說，此升級特別重要。
Bitcoin Core 錢包使用者可以繼續使用他們現有的節點。即使您升級，除了上述變更外，您也不會看到任何變更。預期在 0.12.2 中發布的程式碼預設不會開始生成 segwit 接收地址。
其他錢包的使用者可以繼續使用他們現有的錢包。建議輕量級錢包使用者在接收大量金錢時總是等待幾次確認，因此這裡不預期需要額外的等待。

當您有機會升級到支援 segwit 的錢包版本時，您可能會發現當您花費升級到 segwit 後收到的 bitcoin 時，您必須支付的交易費用稍低，因為見證是外部的，因此交易大小被計為較小。

segwit 使未來升級更容易

Segwit 是改善 Bitcoin 系統運作的重要一步。除了上述第三方可塑性修復和容量增加外，它還提供了一種機制，允許更輕鬆地升級 Bitcoin 的腳本語言。

自 Bitcoin 0.3.6 以來，腳本語言一直支援十個特殊的 NOP 操作碼，其行為可以在以後的版本中以某些方式重新定義。這十個特殊 NOP 操作碼中的兩個已經用於向系統新增新功能：NOP2 根據 BIP65 變更為 OP_CHECKLOCKTIMEVERIFY (CLTV)，NOP3 根據 BIP112 變更為 OP_CHECKSEQUENCEVERIFY (CSV)。

這些操作需要非常仔細地實作以保留舊節點使用的 NOP 語義，這限制了軟分叉可以做什麼，並可能使以這種方式新增功能變得有點混亂。例如，因為 CLTV 和 CSV 都接受參數，所以每次使用它們時，還必須使用 OP_DROP 操作碼以保持與它們原始 NOP 行為的相容性。這使得使用它們編寫和閱讀腳本都變得更加困難。

Segwit 透過允許 segwit 使用者指定要使用的 Bitcoin 腳本語言的版本來消除所有這些問題。每個版本可以是早期版本的小改進，也可以是完全新的語言 – 而且多個版本可以共存在一起，允許個別使用者指定他們想要用於保護其交易的版本。

例如，segwit 隨附了對 OP_CHECKSIG、OP_CHECKMULTISIG 和相關簽名檢查操作碼的改進，消除了可以透過這些操作碼利用的已知拒絕服務漏洞向量。這不是對該問題的完整解決方案，因為 CHECKSIG 操作碼的先前版本仍可用於非 segwit 交易，但它確實有助於使 segwit 交易比非 segwit 交易更難以濫用。

以下描述了使用此機制進行未來升級的一些想法：

Schnorr 簽名

Bitcoin 使用橢圓曲線數位簽名演算法（ECDSA）。有一種更簡單的數位簽名演算法也使用橢圓曲線，但在 Bitcoin 最初發布前不久之前一直受專利保護。這種演算法稱為 Schnorr，它支援 Bitcoin 使用的 ECDSA 中的所有功能，包括建立安全簽名的能力以及建立 HD 錢包的能力。

Schnorr 簽名已經在 Bitcoin 之外使用。例如，著名的 Ed25519 簽名方案基於 Schnorr。

Schnorr 簽名的驗證比 ECDSA 簽名稍快（這使得執行完整節點更方便），並且簽名可以做得更小，因為目前用於 ECDSA 簽名的 DER 編碼不需要用於 Schnorr（提供適度的容量增加）。

Schnorr 還允許在所有參與者需要簽名的情況下（例如 2-of-2、3-of-3 或任何 n-of-n）進行「原生多重簽名」，允許將所有 n 個公鑰組合成單個總體公鑰，並將所有 n 個簽名組合成單個總體簽名。總體公鑰和簽名的大小與單個原始公鑰和簽名的大小相同，因此可以建立與 1-of-1 交易大小相同的 100-of-100 多重簽名交易。這將非常有用，因為預期網路將看到 n-of-n 多重簽名交易的使用增加（例如，2-of-2 用於許多支付通道交易）。

Schnorr 支援已經在 Bitcoin Core 用於建立和驗證簽名的 libsecp256k1 程式庫中可用，儘管 Bitcoin 目前不以任何方式使用 Schnorr，並且開發者希望在開始使用它之前對程式庫的 Schnorr 部分進行一些變更。這與 segwit 對 Bitcoin 腳本版本控制的支援相結合，應該使新增上述功能變得相當容易。

Schnorr 支援的一個更難新增的功能是簽名聚合。這將變更簽名驗證的工作方式，並允許需要 1-of-2、2-of-3 或任何 m-of-n 簽名的多重簽名交易僅為每個交易建立一個簽名，前提是所有簽名者同時線上。這還允許為每個交易建立一個簽名，無論它有多少輸入（同樣，如果所有簽名者同時線上）。

由於簽名通常是交易的最大單個部分，並且許多交易有兩個或更多輸入，每個輸入至少需要一個簽名，這將顯著減少許多交易的大小，並加快驗證速度（因為總共只需要驗證一個簽名，而不是每個輸入一個簽名）。

一旦實作，簽名聚合可以與 coinjoin 隱私增強技術結合，為使用 coinjoin 花費您的 bitcoin 建立顯著的財務激勵。目前，使用 coinjoin 有輕微的財務激勵，因為將來自不同人的多個個別交易組合在一起的 coinjoin 交易比所有這些個別交易的總大小稍小。使用簽名聚合，組合交易將顯著更小，因為它只需要一個簽名而不是許多簽名。

儘管簽名聚合仍在設計中，但使用 segwit 對不同版本的 Bitcoin 腳本評估語言的支援將很容易為協定新增對它的支援。

MAST

Merkelized Abstract Syntax Trees (MAST) 允許建立 Bitcoin 腳本具有許多不同的條件，但可能只允許將相對少量的資料放入交易中。

它們的工作方式是取一個程式並將其每個條件部分拆分為單獨的片段，然後將這些片段中的每一個放入默克爾樹中。Bitcoin 被花費（encumbered）到默克爾樹的默克爾根。

需要用於最終驗證的最小條件集可以透露給所有完整驗證節點，但不執行的程式碼可以由簡單的雜湊替換，作為部分默克爾分支的一部分，允許腳本的所有部分連接到 encumbrance 中使用的默克爾根，以便可以完成驗證。

這不僅節省空間，而且還可能有助於改善隱私。例如，如果 Alice 希望能夠每天正常花費她的 bitcoin，但也希望她的遺產律師 Bob 能夠在它們閒置一年後花費她的 bitcoin，她可以將這兩個條件放在不同的分支中。當 Alice 進行正常花費時，沒有人可以僅透過查看交易來看到第二個條件是什麼。

可以使用 segwit 啟用的 Bitcoin 腳本版本控制來啟用 MAST。

CSV 軟分叉 - 礦工升級重要指引

Tue, 21 Jun 2016 00:00:00 +0000

概覽

CSV 軟分叉情況
所有礦工請留意
手動設定區塊版本號的礦工請注意
使用或手動設定 Coinbase 交易內 nSequence 參數的礦工請注意
使用或手動設定 Coinbase 交易內 nLockTime 參數的礦工請注意

比特幣的共識規則現正有一項軟分叉進行中，雖然一切看起來均運作正常，礦工和礦池負責人絕對不能忽視以下的重要資訊和工作清單。

礦工和礦池負責人如有任何疑問，歡迎和我們聯絡。

摘要

你必須在區塊419328號產出以前，檢查你的所有節點，確保皆已升級至 Bitcoin Core 0.12.1 或相容軟體。
如果你正在手動設定區塊版本號，你必在區塊419328號產出以前把版本號的0號位元去除。最好的做法是由 bitcoind 自動設定。
Coinbase 交易的 nSequence 值請設定為 0xffffffff，以避免和 BIP68 及 BIP113 出現衝突。
如果你必須使用其它 nSequence 值，你必須小心跟從以下指引。

CSV 軟分叉情況

“CSV” 軟分叉已經達到「鎖定」的要求，將會正式啟動。在415296至417311號一共2016個區塊之中，1946個(96.53%)顯示已準備實施BIP68, BIP112 和 BIP113 (“CSV”) 軟分叉。從417312號區塊(2016-06-21 05:18:58 UTC)開始，CSV 軟分叉進入為時約兩星期的「鎖定」寬限期，直至419327號區塊。之後，BIP68, BIP112 和 BIP113的新規則便會正式實施。該軟分叉已過了臨界點，如非有極大規模的區塊鏈回滾，其實施已不可逆轉。

所有礦工請留意

在寬限期內，所有礦工必須升級至 Bitcoin Core 0.12.1 或任何支持 CSV 軟分叉的相容軟體。實際上，在編寫本文的時間，Bitcoin Core 0.12.1 是唯一支持 CSV 軟分叉的版本。礦工必須再三確認所有負責挖礦的節點以及備用節點皆已升級。

不依從以上指引者可能會產出無效區塊，或會延長無效的區塊鏈，造成區塊鏈分叉，令有關礦工和廣大比特幣使用者蒙受經濟損失。

手動設定區塊版本號的礦工請注意

Bitcoin Core 的預設設定會自動按 BIP9 的要求設定區塊版本，然而我們留意到有些礦工會手動設定區塊版本號，我們強烈建議不要手動設定區塊版本號，因為這會對比特幣系統帶來風險。

如果有礦工設定了一個版本編號，卻沒有實施對應的規則，便可能會產出無效區塊，並會延長無效的區塊鏈。簡單而言，不使用由 bitcoind 提供的預設版本值，可能會令版本編號與實際運作的規則不相符。

和 BIP33/66/65 所使用的 IsSuperMajority 軟分叉不同，在 BIP9 的設計中，沒有區塊會因為不當版本號而被視作無效（根據 BIP65，最低有效版本號為4）。因此，礦工並無誘因去手動設定區塊版本號，因為這只會帶來不必要的維護工作與人為出錯的風險。

然而，如果你並不依從以上建議，仍然是手動設定區塊版本號，你必須作出以下行動。在「鎖定」寬限期內，你必須去除 CSV 的版本號位元，即0號位元。例如，如果你本來的版本號是 0x20000001，你就必須在419328號區塊前改變為 0x20000000，否則你將會令所有支持 BIP9 的節點的日誌出現「未知軟分叉」的警告訊息。詳情請看Version Bits FAQ。

如果你不依從以上指引，你可能會令所有支持BIP9的節點收到升級警報，將會造成很大混亂。

至於讓 bitcoind 自行設定區塊版本號的礦工則無需採取任何行動。請留意，你的節點在419328號區塊之前，仍然會產出0x20000001版本號的區塊，之後0號位元便會自動被去除。

使用或手動設定 Coinbase 交易內 nSequence 參數的礦工請注意

有些礦工可能會用 Coinbase 交易內的 nSequence 參數作為挖礦亂數。在 BIP68 生效之後，這些礦工需要加倍留意。

礦工如以任何形式改動 Coinbase 交易的 nSequence 參數，他們必須肯定 Coinbase 交易的 nVersion 參數 (不是區塊版本號) 必須為1或以下，例如把 nVersion 參數硬性地手動設定為1。

如果你不使用 Coinbase 交易內的 nSequence 參數，但必須手動設定，請設定為 0xffffffff。

不依從以上指引者可能會產出無效區塊，造成區塊鏈分叉，令有關礦工和廣大比特幣使用者蒙受經濟損失。

使用 bitcoind 提供的預設 Coinbase 交易 nSequence 和 nVersion 值的礦工無需採取任何行動。

使用或手動設定 Coinbase 交易內 nLockTime 參數的礦工請注意

這是比較罕見的情況，因為 Stratum 協議並不支持使用 nLockTime 參數作為挖礦亂數。然而任何這樣做的礦工必須留意 BIP113 的新規則。

礦工如以任何形式改動 Coinbase 交易的 nLockTime 參數，他們必須肯定參數值如被視作 UNIX 時間戳(即大或等於500000000)，必須小於過去11個區塊時間戳的中位數，除非 Coinbase 交易的 nSequence 參數同時為 0xffffffff。

如果你不使用 Coinbase 交易內的 nLockTime 參數，但必須手動設定，請設定為 0。

不依從以上指引者可能會產出無效區塊，造成區塊鏈分叉，令有關礦工和廣大比特幣使用者蒙受經濟損失。

使用 bitcoind 提供的預設 Coinbase 交易 nLockTime 值的礦工無需採取任何行動。

礦工版本位元常見問題

Wed, 08 Jun 2016 00:00:00 +0000

概覽

什麼是 版本位元 BIP9？
版本位元 如何啟動？
什麼是軟分叉超時？
啟動工作流程是什麼？
什麼是版本位元？
礦工何時應該設定位元？
它與 ISM 軟分叉有何不同？
礦工必須升級嗎？
誰為不同的升級提案分配版本位元？
進一步閱讀

什麼是版本位元 BIP9？

版本位元 BIP9 系統是一種向 Bitcoin 共識規則引入向後相容規則變更的方法，稱為軟分叉。

版本位元 允許礦工發出訊號表示他們可以驗證軟分叉規則。它還允許同時提出最多 29 個軟分叉。

版本位元如何啟動？

版本位元 不需要啟動，它只是礦工透過在區塊標頭 nVersion 欄位中設定位元來發出對軟分叉準備就緒訊號的一種方式。

什麼是軟分叉超時？

軟分叉有一個開始時間和一個 超時時間，在此期間提案是活躍的。軟分叉只能在 開始時間 和 超時時間 之間啟動。如果軟分叉在 超時時間 之前未被啟動，軟分叉提案失敗，即使發出訊號也不會啟動。

啟動工作流程是什麼？

在 版本位元 下，軟分叉提案經歷一個工作流程：

[DEFINED] -> [STARTED] -> [LOCKED_IN] -> [ACTIVE]

或

[DEFINED] -> [STARTED] -> [FAILED]

Bitcoin 網路每 2016 個區塊重新定向挖礦難度；此時 版本位元 將查看前 2016 個區塊的視窗，以查看有多少區塊為給定的軟分叉發出訊號。如果 95% 的區塊發出軟分叉準備就緒的訊號，狀態將從 [STARTED] 變更為 [LOCKED_IN]。

在 [LOCKED_IN] 之後，規則將在再一次難度重新定向後啟動，即再 2016 個區塊。節點軟體將警告升級正在等待中。

什麼是版本位元？

當沒有軟分叉發出訊號時，礦工應將區塊版本欄位設定為 0x20000000。

礦工何時應該設定位元？

要為軟分叉發出準備就緒訊號，礦工應將相關版本位元與 0x20000000 一起設定。這應該只在軟分叉的 開始時間 之後執行。

如果軟分叉啟動或達到 [FAILED] 狀態，應取消設定位元。

例如：

「alice」軟分叉使用位元 0，即 0x1 + 0x20000000

…

「bob」軟分叉使用位元 1，即 0x2 + 0x20000000

…

要同時為兩個軟分叉發出訊號，使用 0x20000003（即 0x1 + 0x2 + 0x20000000*）

…

注意，如果其中一個在另一個之前啟動，您必須取消設定相關位元並繼續為另一個發出訊號。如果一個未能啟動且超時到期，您也應該取消設定該位元。

它與 ISM 軟分叉有何不同？

IsSuperMajority() 或簡稱 ISM，是一種傳統的軟分叉觸發器，一旦 1000 個區塊中有 950 個挖出發出新區塊版本訊號的區塊，就會啟動新規則。

IsSuperMajority() 軟分叉將在啟動後孤立所有具有先前版本的區塊。例如，如果當前版本是 4，而下一個軟分叉引入版本 5 區塊，那麼在達到啟動（950/1000 個區塊）後，節點將拒絕所有版本 4 區塊。
一旦 版本位元 軟分叉達到啟動，節點將簡單地開始強制執行新規則，並且不會孤立非發出訊號的區塊，除非它違反新規則。
ISM() 在滾動基礎上查看前 1000 個區塊；版本位元 在每次挖礦難度重新定向時查看前 2016 個區塊一次。
ISM() 軟分叉不會過期。版本位元 軟分叉只能在 開始時間 和 超時時間 之間啟動。

礦工必須升級嗎？

不。BIP9 軟分叉不會啟動，除非 95% 的礦工發出準備就緒訊號。如果軟分叉達到 [LOCKED_IN] 狀態，絕大多數礦工已準備好進行變更，剩餘的礦工應該在下一次難度重新定向（大約 2 週）之前升級。

未升級的礦工如果無法驗證新啟動的規則，則有產生無效區塊的風險，這些區塊將被孤立。

誰為不同的升級提案分配版本位元？

軟分叉透過 BIPs 流程提出。活躍的 BIP9 軟分叉提案列在分配頁面上。

進一步閱讀

緊湊區塊常見問題

Tue, 07 Jun 2016 00:00:00 +0000

概覽

摘要
一些有用的基準測試資料是什麼？
如何選擇預期缺失的交易立即轉發？
快速中繼網路如何與此相關？
這會擴展 Bitcoin 嗎？
誰從緊湊區塊中受益？
編碼、測試、審查和部署緊湊區塊傳播的時程是什麼？
如何調整這個以實現更快的 p2p 中繼？
這個想法是新的嗎？
進一步閱讀資源

緊湊區塊中繼，BIP152，是一種減少傳播新區塊至全節點所需頻寬的方法。

摘要

當全節點之間共享許多相同的記憶池內容時，可以使用簡單的技術來減少傳播新區塊所需的頻寬。對等節點向接收對等節點傳送緊湊區塊「草圖」。這些草圖包含以下資訊：

新區塊的 80 位元組標頭
縮短的交易識別碼（txids），其設計目的是防止阻斷服務（DoS）攻擊
一些傳送對等節點預測接收對等節點尚未擁有的完整交易

接收對等節點接著嘗試使用收到的資訊和記憶體池中已有的交易來重建整個區塊。如果仍然缺少任何交易，它將從傳送對等節點請求這些交易。

這種方法的優點是，在最佳情況下，交易只需要傳送一次──即在它們最初廣播時──從而大幅減少整體頻寬。

此外，緊湊區塊中繼提議還提供了第二種營運模式（稱為高頻寬模式），接收節點要求其幾個對等節點直接傳送新區塊而不先請求許可，這可能會增加頻寬（因為兩個對等節點可能同時嘗試傳送同一個區塊），但進一步減少區塊到達高頻寬連線所需的時間（延遲）。

下圖顯示了節點目前傳送區塊的方式與緊湊區塊中繼的兩種營運模式的比較。節點 A 時間軸上的灰色方塊表示它正在執行驗證的期間。

在傳統中繼中，區塊經過節點 A 的驗證（灰色長條），然後向節點 B 傳送 inv 訊息請求傳送區塊的許可。節點 B 回覆一個對區塊的請求（getdata），節點 A 傳送區塊。
在高頻寬中繼中，節點 B 使用 sendcmpt(1)（傳送緊湊）告訴節點 A 它希望盡快接收區塊。當新區塊到達時，節點 A 執行一些基本驗證（例如驗證區塊標頭），然後自動開始向節點 B 傳送標頭、縮短的 txids 和預測缺失的交易（如上所述）。節點 B 嘗試重建區塊並請求它仍然缺失的任何交易（getblocktxn），節點 A 傳送這些交易（blocktxn）。在背景中，兩個節點在將區塊新增到其本機區塊鏈副本之前完成對區塊的完整驗證，保持與之前相同的全節點安全性。
在低頻寬中繼中，節點 B 使用 sendcmpt(0) 告訴節點 A 它希望盡可能減少頻寬使用。當新區塊到達時，節點 A 完全驗證它（因此它不會中繼任何無效區塊）。然後它詢問節點 B 是否想要該區塊（inv），這樣如果節點 B 已經從另一個對等節點接收到該區塊，它可以避免再次下載。如果節點 B 確實想要該區塊，它以緊湊模式請求它（getdata(CMPCT)），節點 A 傳送標頭、短 txids 和預測缺失的交易。節點 B 嘗試重建區塊，請求它仍然缺失的任何交易，節點 A 傳送這些交易。然後節點 B 正常完全驗證區塊。

一些有用的基準測試資料是什麼？

平均完整的 1MB 區塊公告可以由接收節點使用 9KB 的區塊草圖重建，加上接收節點記憶池中沒有的區塊中每個交易的額外開銷。見到的最大區塊草圖最高達到 20KB 以北的幾個位元組。

在「高頻寬」模式下執行即時實驗並讓節點預先填充最多 6 筆交易時，我們可以預期看到超過 90% 的區塊立即傳播而不需要請求任何缺失的交易。即使除了 coinbase 之外不預先填充任何交易，實驗顯示我們可以看到超過 60% 的區塊立即傳播，其餘需要完整的額外網路往返。

由於預熱節點的記憶池和區塊之間的差異很少超過 6 筆交易，這意味著緊湊區塊中繼實現了所需峰值頻寬的顯著減少。

如何選擇預期缺失的交易立即轉發？

為了減少初始實作中需要審查的內容，僅會預先傳送 coinbase 交易。

然而，在所描述的實驗中，傳送節點使用簡單的公式來選擇要傳送的交易：當節點 A 收到一個區塊時，它檢查哪些交易在區塊中但不在其記憶池中；這些是它預測其對等節點沒有的交易。理由是（在沒有額外資訊的情況下）你不知道的交易可能也是你的對等節點不知道的交易。使用這種基本啟發式方法，看到了很大的改進，說明許多時候最簡單的解決方案是最好的。

快速中繼網路如何與此相關？

快速中繼網路（FRN）由兩部分組成：

目前在快速中繼網路中精選的節點集合
快速區塊中繼協定（FBRP）

FRN 中精選的節點集合經過精心選擇，以全球最小中繼為首要優先事項。這些節點的故障將導致浪費算力的顯著增加和挖礦潛在的進一步集中化。今天絕大多數挖礦算力連線到這個網路。

原始的 FBRP 是參與節點如何相互通訊區塊資訊的方式。節點追蹤它們相互傳送的交易，並根據這些知識中繼區塊差異。對於一對一的伺服器-客戶端新區塊通訊，這個協定幾乎是最佳的。最近，一個基於 UDP 和前向錯誤更正（FEC）的協定，名為 RN-NextGeneration，已被部署供礦工測試和使用。然而，這些協定需要一個連線不良的中繼拓撲，並且比更通用的 p2p 網路更脆弱。使用緊湊區塊的協定層級改進將縮小精選節點網路和一般 p2p 網路之間的效能差距。p2p 網路的強韌性提升和整體區塊傳播速度將在網路未來發展中發揮作用。

這會擴展 Bitcoin 嗎？

此功能旨在節省節點的峰值區塊頻寬，減少可能降低終端使用者網際網路體驗的頻寬尖峰。然而，如以下影片所述，挖礦的集中化壓力在很大程度上是由於區塊傳播的延遲。緊湊區塊版本 1 主要不是為了解決該問題而設計的。

https://www.youtube.com/embed/Y6kibPzbrIc

預期礦工將繼續使用快速中繼網路，直到開發出更低延遲或更強韌的解決方案。然而，對基礎 p2p 協定的改進將在 FRN 故障的情況下增加強韌性，並且可能減少私有中繼網路的優勢，使它們不值得營運。

此外，使用第一版緊湊區塊進行的實驗和收集的資料將為我們預期與 FRN 更具競爭力的未來改進的設計提供資訊。

誰從緊湊區塊中受益？

想要中繼交易但網際網路頻寬有限的全節點使用者。如果您只是想在仍然向對等節點中繼區塊的同時節省最多頻寬，從 Bitcoin Core v0.12 開始已經有一個 blocksonly 模式可用。僅區塊模式僅在交易包含在區塊中時接收交易，因此沒有額外的交易開銷。
整體網路。減少 p2p 網路上的區塊傳播時間可以創建一個更健康的網路，具有更好的基準中繼安全邊際。

編碼、測試、審查和部署緊湊區塊傳播的時程是什麼？

緊湊區塊的第一版已被分配 BIP152，有一個工作實作，並正在由開發者社群積極測試。

BIP152: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki
參考實作: https://github.com/bitcoin/bitcoin/pull/8068

如何調整這個以實現更快的 p2p 中繼？

可以對緊湊區塊方案進行額外的改進。這些與 RN-NG 相關，包含兩個方面：

首先，用 UDP 傳輸取代區塊資訊的 TCP 傳輸。
其次，使用前向錯誤更正（FEC）代碼處理丟失的封包並預先傳送缺失的交易資料。

UDP 傳輸允許伺服器傳送資料並由客戶端以路徑允許的速度消化，而不用擔心間歇性丟失的封包。客戶端寧願無序接收封包以盡快構建區塊，但 TCP 不允許這樣做。

為了處理丟失的封包和從多個伺服器接收非冗餘區塊資料，將採用 FEC 代碼。FEC 代碼是一種將原始資料轉換為冗餘代碼的方法，只要一定百分比的封包到達其目的地就允許無損傳輸，其中所需資料僅略大於資料的原始大小。

這將允許節點在接收到區塊時立即開始傳送區塊，並允許接收者重建同時從多個對等節點串流的區塊。所有這些工作都繼續建立在已經完成的緊湊區塊工作之上。這是一個中期擴展，開發正在進行中。

這個想法是新的嗎？

使用布隆過濾器（例如 BIP37 filteredblocks 中使用的）來更有效地傳輸區塊的想法在幾年前就被提出了。它也由 Pieter Wuille（sipa）在 2013 年實作，但他發現開銷使傳輸速度變慢。

[#bitcoin-dev, public log (excerpts)]

[2013-12-27]
09:12 < sipa> TD: i'm working on bip37-based block propagation
[...]
10:27 < BlueMatt> sipa: bip37 doesnt really make sense for block download, no? why do you want the filtered merkle tree instead of just the hash list (since you know you want all txn anyway)
[...]
15:14 < sipa> BlueMatt: the overhead of bip37 for full match is something like 1 bit per transaction, plus maybe 20 bytes per block or so
15:14 < sipa> over just sending the txid list

[2013-12-28]
00:11 < sipa> BlueMatt: i have a ~working bip37 block download branch, but it's buggy and seems to miss blocks and is very slow
00:15 < sipa> BlueMatt: haven't investigated, but my guess is transactions that a peer assumes we have and doesn't send again
00:15 < sipa> while they already have expired from our relay pool
[...]
00:17 < sipa> if we need to ask for missing transactions, there is an extra roundtrip, which makes it likely slower than full block download for many connections
00:18 < BlueMatt> you also cant request missing txn since they are no longer in mempool [...]
00:21 < gmaxwell> sounds like we really do need a protocol extension for this.
[...] 00:23 < sipa> gmaxwell: i don't see how to do it without extra roundtrip
00:23 < BlueMatt> send a list of txn in your mempool (or bloom filter over them or whatever)!

如摘錄中所述，簡單地擴展協定以支援請求交易的個別交易雜湊以及區塊中的個別交易，最終允許緊湊區塊方案更簡單、抗 DoS 且更高效。

進一步閱讀資源

任命新儲存庫維護者

Thu, 14 Apr 2016 00:00:00 +0000

特此宣布 Marco Falke 為 Bitcoin Core 的新測試與 QA 維護者。

測試和 QA 一直對這個專案至關重要，隨著開發速度的加快，它變得比以往任何時候都更加關鍵。

Marco 在過去一年中為專案做出了出色的貢獻，特別是在測試框架和單元測試、提高覆蓋率方面，還透過檢查錢包手續費功能以及審查其他拉取請求。所以這幾乎是他一直在做的事情，考慮讓他擔任這個職位是很自然的。

他將監督並合併 QA 和測試框架的拉取請求，並關注測試的整體品質。

歡迎加入團隊，Marco！

此致，

Wladimir van der Laan

保持更新！

Tue, 15 Mar 2016 00:00:00 +0000

為了加強溝通，我們現在為 Bitcoin Core 的使用者提供選擇性加入、僅公告 資訊，以接收安全問題和新版本的通知。

雖然 Bitcoin Core 專案有多種溝通管道，但已有許多請求要求提供僅接收重要公告的方法。這個新來源旨在極低容量，專注於關鍵通知以及宣布新版本。

如果您使用 Bitcoin Core，請考慮訂閱。

首次成功的零知識或有支付

Fri, 26 Feb 2016 00:00:00 +0000

我很高興宣布在 Bitcoin 網路上首次成功的零知識或有支付（ZKCP）。

ZKCP 是一種交易協定，允許買方使用 Bitcoin 以私密、可擴展、安全且不需要信任任何人的方式從賣方購買資訊：當且僅當付款完成時，預期的資訊才會被轉移。買方和賣方不需要相互信任或依賴第三方的仲裁。

想像一下電影風格的「公事包交換」（一方拿著裝滿現金的公事包，另一方拿著裝有機密文件的公事包），但沒有其中一個箱子裝滿碎報紙以及隨之而來的精彩追逐場景的潛在情況。

一個示例應用是特定品牌電子書閱讀器的所有者合作從倒閉的製造商購買 DRM 主金鑰，以便在供應商的伺服器離線後可以在其閱讀器上載入自己的文件。這種類型的銷售本質上是不可逆的，可能跨越多個司法管轄區，並涉及財務穩定性不確定的各方──這意味著雙方要麼承擔很大的風險，要麼必須做出艱難的安排。使用 ZKCP 可以避免在否則容易出錯的銷售中涉及的重大交易成本。

在今天的交易中，我從 Zcash 團隊成員 Sean Bowe 以 0.10 BTC 的價格購買了一個 16x16 數獨謎題的解決方案，作為在巴貝多舉行的 Financial Cryptography 2016 上現場演示的一部分。我在加州遠端參與了交易。

轉移涉及兩筆交易：

此 ZKCP 實作背後的幾乎所有工程工作都由 Sean Bowe 完成，並得到 Pieter Wuille、我本人和 Madars Virza 的支援。

請參閱現場演示的投影片。

背景

我於 2011 年在 Bitcoin Wiki 上的一篇文章中首次提出 ZKCP 協定，作為 Bitcoin Script 中現有基本運算已經非常強大的示例。

零知識證明

我的 ZKCP 協定需要一個用於任意程式的零知識證明作為構建模組。存在許多類型的專門零知識證明：常見的數位簽章就是一個例子，機密交易中的範圍證明也是如此。

用於 一般計算 的零知識證明是一種密碼系統，它允許人們使用公共和秘密輸入的混合執行任意程式，並向其他人證明此特定程式接受了輸入，而不透露有關其操作或秘密輸入的更多資訊。

如果這看起來像是不可能的魔法，出於教育目的，我提出了一個非常簡單但效率低下的 ZKP 系統，它只使用布林電路和密碼雜湊，或者參見 Matthew Green 的圖著色 ZKP 示例。

正如我最初關於 ZKCP 的文章所指出的，2011 年沒有這樣的系統可用，但人們相信它們是可能的，特別是在特定約束下，這些約束對 ZKCP 有效。

2012 年，Gennaro、Gentry、Parno 和 Raykova 發表了一篇論文（「Quadratic Span Programs and Succinct NIZKs without PCPs」），描述了一種特別有效的構造。從那時起，幾個團隊繼續推進這項工作，創建編譯器、效能改進，最重要的是像 libsnark 這樣的實用工具。GGPR’12 密碼系統需要可信設定，但對於 ZKCP 應用來說，這不是真正的限制，因為買方可以執行它。由於這項工作，ZKCP 現在可以成為一個實用的工具。

進一步閱讀：

因為這些高效的 ZKP 是尖端技術，依賴於新的強密碼假設，它們的安全性尚未確定。但在像 ZKCP 這樣的應用中，我們唯一的替代方案是第三方信任，它們可以以比沒有它們時更嚴格改進的方式使用。

ZKCP 如何運作

如果您接受零知識證明系統作為一個黑盒，ZKCP 協定的其餘部分相當簡單。

買方首先建立一個程式，可以決定給它的輸入是否是買方想要購買的資料。此程式僅驗證資訊，它不產生資訊──買方甚至不必知道如何產生它。（例如，編寫程式來驗證數獨解決方案是否正確很容易，但編寫數獨求解器更困難，數獨是 NP 完全的。這裡的買方只需要編寫解決方案驗證器。）

買方為證明系統執行可信設定，並將產生的設定資訊傳送給賣方。

賣方選擇一個隨機加密金鑰並加密買方希望購買的資訊。

使用 ZKP 系統，賣方證明一個複合陳述：

Ex 是滿足買方程式的輸入的加密。
Y 是 Ex 的解密金鑰的 sha256 雜湊。

賣方將 Ex、Y、證明和他的公鑰傳送給買方。一旦買方的電腦驗證了證明，買方就知道，如果他得知產生雜湊 Y 的 SHA256 輸入，他就可以解密他的答案。

因此，買方最初想購買他程式的輸入，但現在他同樣樂意購買雜湊的原像。事實證明，Bitcoin 已經提供了一種以安全方式出售雜湊原像的方法。

買方將他的付款支付給以下 ScriptPubkey：

OP_SHA256
<Y> OP_EQUAL
OP_IF
  <Seller Pubkey>
OP_ELSE
  <block_height+100> OP_CHECKLOCKTIMEVERIFY OP_DROP
  <Buyer Pubkey>
OP_ENDIF
OP_CHECKSIG

這筆付款的效果是，賣方如果提供 Y 的雜湊原像和他的金鑰簽章，就可以收取它。為了避免永遠鎖定買方的資金，如果賣方在（例如）一天內不收取他的付款，買方可以收回付款。

因此，當賣方收取他的付款時，他被迫透露買方需要的資訊以解密答案。如果他不這樣做，買方會取回他的資金。

此 ScriptPubkey 也與用於跨鏈原子交換或閃電支付通道的相同。

這些交易的錢包支援已在 PR#7601 中為 Bitcoin Core 實作。此錢包支援由數獨 ZKCP 客戶端和伺服器使用，可在 https://github.com/zcash/pay-to-sudoku 取得。

買方的程式可以任意長且複雜，而不會給 Bitcoin 的區塊鏈增加任何額外負擔──唯一的影響是設定和證明所需的時間增加，這一切都發生在 Bitcoin 外部。除了買方或賣方之外，沒有人了解買方的程式（也就是說，他們不了解正在出售的資訊的性質）。

限制和替代方案

這種方法比在區塊鏈內執行智慧合約更具可擴展性和私密性，並且不受 Bitcoin 智慧合約中的任何效能或功能限制的阻礙。

這種方法有兩個主要限制。首先，它是互動式的：買方不能簡單地發出廣播報價，讓任何感興趣的賣方在沒有來回溝通的情況下接受付款。其次，ZKP 系統雖然足夠快以實用，但仍然不是很快。例如，在我們的演示中，ZKP 系統證明了 5 次 SHA256 執行和數獨約束，並且在筆記型電腦上執行大約需要 20 秒。（證明的驗證只需要幾毫秒。）

ZKCP 的一種替代方案是 Peter Todd 2014 年的「paypub」協定。在 Paypub 中，買方不使用零知識證明，而是被展示他們試圖購買的資料的隨機子集，當他們收取付款時，賣方被迫解鎖其餘部分。Paypub 避免了處理零知識證明的複雜性──並且還允許交換只有人類才能驗證的資訊──但代價是對作弊的某些脆弱性，並且只能用於相對較大的隨機可驗證資訊集。

一般來說，我認為像這樣的「無信任」智慧合約在以下情況下最有價值：頻繁的自動化非常低價值的交易──以至於傳統衝突解決方法的開銷剝奪了參與者獲得有意義正義的機會──或對於非常高價值的交換，傳統衝突解決的速度、不可靠性（特別是跨司法管轄區）或缺乏私密性將是不可接受的。

隨著技術變得越來越實用，我期待人們為它們找到令人興奮的應用。

Gregory Maxwell

有關Bitcoin Core溝通渠道的澄清

Thu, 28 Jan 2016 00:00:00 +0000

最初，bitcoin.org是用作放置比特幣白皮書，並成為比特幣軟體的主頁。後來，這網站提供了比特幣教育資訊，但這與現時的Bitcoin Core計劃並無關係。Bitcoin Core的正式網站是bitcoincore.org，而雖然其它網站仍會提供有關Bitcoin Core的資訊，他們的觀點並不代表Bitcoin Core。我們明白這可能令人感到混淆，因此我們正在努力地清楚說明這些關係。

在開發方面，Bitcoin Core主要使用Freenode IRC上的#bitcoin-core-dev，Github，以及bitcoin-dev 電郵列表。

另一方面，在網路上有很多和比特幣有關的論壇，當中可能有Bitcoin Core的貢獻者參與，但Bitcoin Core對這些論壇的政策並不負責，並對比特幣社群應使用哪些論壇沒有正式立場。然而，我們堅信比特幣社群應該可以自由地討論和批評與比特幣相關的所有事情。

當比特幣社群在討論的時候，雖然可能會非常興奮和激烈，但我們必須保持文明的態度。社群不應該採取網路打手，拒絕服務攻擊，以及其它會妨礙正當討論的手段。除非有其它理由，我們應該盡量假設參與討論的人都是懷著善意而來的。

隔離見證的好處

Tue, 26 Jan 2016 00:00:00 +0000

概覽

隔離見證軟分叉（segwit）包含了廣泛的功能，其中許多功能具有高度技術性。本頁總結了這些功能的一些好處。

可塑性修復

Bitcoin 交易透過一個 64 位十六進位雜湊來識別，稱為交易識別碼（txid），該識別碼基於正在花費的代幣和誰將能夠花費交易的結果。

不幸的是，txid 的計算方式允許任何人對交易進行小幅修改，這不會改變其含義，但會改變 txid。這稱為第三方可塑性。BIP 62（「處理可塑性」）試圖以零碎的方式解決這些問題，但實作起來過於複雜而無法作為共識檢查，已被撤回。

例如，您可以向網路提交一個 txid 為 ef74…c309 的交易，但發現第三方（例如網路上中繼您交易的節點，或將您的交易包含在區塊中的礦工）稍微修改了交易，導致您的交易仍然花費相同的代幣並支付相同的地址，但在完全不同的 txid 683f…8bfa 下確認。

更一般地說，如果交易的一個或多個簽名者修改他們的簽名，則交易仍然有效並向相同地址支付相同金額，但 txid 會完全改變，因為它包含了簽名。簽名資料（但不是輸出或輸入選擇）的變更修改交易的一般情況稱為 scriptSig 可塑性。

Segwit 透過允許 Bitcoin 使用者將交易的可塑部分移至交易見證中，並隔離該見證，使見證的變更不影響 txid 的計算，從而防止第三方和 scriptSig 可塑性。

誰受益？

追蹤已花費 bitcoin 的錢包作者：最簡單的監控自己傳出交易狀態的方法是透過 txid 查詢它們。但在具有第三方可塑性的系統中，錢包必須實作額外的程式碼才能處理變更的 txid。
任何花費未確認交易的人：如果 Alice 在交易 1 中向 Bob 付款，Bob 在交易 2 中使用該付款向 Charlie 付款，然後 Alice 的付款被可塑化並以不同的 txid 確認，那麼交易 2 現在無效，Charlie 沒有收到付款。如果 Bob 值得信任，他將重新發出向 Charlie 的付款；但如果他不值得信任，他可以簡單地為自己保留這些 bitcoin。
閃電網路：隨著第三方和 scriptSig 可塑性被修復，閃電網路的實作變得不那麼複雜，並且在區塊鏈上的空間使用上顯著更有效率。移除 scriptSig 可塑性後，也可以執行輕量級閃電客戶端，將監控區塊鏈的工作外包出去，而不是每個閃電客戶端都需要成為完整的 Bitcoin 節點。
任何使用區塊鏈的人：今天的智慧合約（例如微支付通道）和預期的新智慧合約，變得不那麼複雜設計、理解和監控。

注意：只有當隔離見證交易的所有輸入都是 segwit 花費（直接或透過向後相容的 segwit P2SH 地址）時，segwit 交易才能避免可塑性。

進一步資訊

簽章操作的線性擴展

增加 Bitcoin 區塊大小的簡單方法的一個主要問題是，對於某些交易，簽名雜湊的擴展是二次方的而不是線性的。

本質上，將交易的大小加倍可以使簽名操作的數量加倍，以及為了驗證每個簽名而必須雜湊的資料量加倍。這在實際環境中已經出現，其中單個區塊需要 25 秒來驗證，惡意設計的交易可能需要超過 3 分鐘。

Segwit 透過變更簽名的交易雜湊計算來解決這個問題，使得交易的每個位元組最多只需要雜湊兩次。這更有效地提供了相同的功能，因此即使惡意生成或支援更大的區塊（因此更大的交易），也可以生成大型交易而不會遇到簽名雜湊問題。

誰受益？

移除驗證簽名的雜湊資料的二次方擴展使增加區塊大小更安全。在不限制交易大小的情況下執行此操作，允許 Bitcoin 繼續支援向大型群組付款或來自大型群組的付款，例如礦池獎勵的付款或群眾募資服務。

修改後的雜湊僅適用於從見證資料發起的簽名操作，因此來自基礎區塊的簽名操作將繼續需要較低的限制。

進一步資訊

透過 pay-to-script-hash (P2SH) 增加多重簽名的安全性

多重簽名付款目前使用 P2SH，它由 160 位元 HASH160 演算法（SHA256 的 RIPEMD）保護。然而，如果其中一個簽名者希望竊取所有資金，他們可以在作為多重簽名腳本一部分的有效地址與只向他們支付所有資金的腳本之間找到碰撞，只需 80 位元（2⁸⁰）的工作量，這對於資源極其豐富的攻擊者來說已經在可能的範圍內。（作為比較，在持續 1 exahash/秒的情況下，Bitcoin 挖礦網路每兩週完成 80 位元的工作量）

Segwit 透過僅對直接向單個公鑰的付款使用 HASH160（在這種情況下這種攻擊是無用的），同時對向腳本雜湊的付款使用 256 位元 SHA256 雜湊來解決這個問題。

誰受益？

透過 segwit 向多重簽名或智慧合約付款的每個人都受益於為腳本提供的額外安全性。

進一步資訊

腳本版本控制

對 Bitcoin 腳本的變更允許改進安全性和功能。然而，腳本的設計僅允許透過用新的操作碼替換十個額外的 OP_NOP 操作碼之一來實作向後相容（軟分叉）的變更，該新操作碼可以有條件地使腳本失敗，但在其他情況下什麼都不做。這對於許多變更來說是足夠的 – 例如引入新的簽名方法或像 OP_CLTV 這樣的功能，但它既有點 hacky（例如，OP_CLTV 通常必須伴隨 OP_DROP），也無法用於啟用甚至像連接兩個字串這樣簡單的功能。

Segwit 透過為腳本包含版本號來解決這個問題，因此在非 segwit 交易中需要硬分叉才能使用的額外操作碼，可以透過簡單地增加腳本版本來支援。

誰受益？

更容易變更腳本操作碼將使 Bitcoin 中的進階腳本更容易。這包括引入 Schnorr 簽名、使用金鑰恢復來縮小簽名大小、支援側鏈，或使用 Merklized Abstract Syntax Trees (MAST) 和其他研究級想法來建立更智慧的合約等變更。

減少 UTXO 增長

每個驗證的 Bitcoin 節點都維護未花費交易輸出（UTXO）資料庫，以確定新交易是有效還是欺詐。為了網路的有效運作，此資料庫需要非常快速地查詢和修改，並且理想情況下應該能夠放入主記憶體（RAM），因此將資料庫的大小（以位元組為單位）保持在盡可能小的範圍內是有價值的。

隨著 Bitcoin 的成長，這變得更加困難，因為每個新使用者必須至少有一個自己的 UTXO 條目，並且將偏好擁有多個條目以幫助改善他們的隱私和靈活性，或提供作為支付通道或其他智慧合約的支援。

Segwit 透過使不影響 UTXO 集大小的簽名資料成本比影響 UTXO 集大小的資料低 75% 來改善這種情況。預期這將鼓勵使用者偏好使用對 UTXO 集影響最小的交易以最小化費用，並鼓勵開發者以同樣最小化對 UTXO 集影響的方式設計智慧合約和新功能。

因為 segwit 是軟分叉變更並且不增加基礎區塊大小，所以 UTXO 集的最壞情況增長率保持不變。

誰受益？

減少的 UTXO 增長將使礦工、企業和執行完整節點的使用者受益，這反過來又有助於在更多使用者進入系統時維持 Bitcoin 網路的當前安全性。幫助最小化 UTXO 集增長的使用者和開發者將受益於較低的費用，相對於那些忽視其交易對 UTXO 增長影響的人。

進一步資訊

Statoshi UTXO 儀表板

不驗證簽名時的效率提升

歷史交易的簽名可能不如未來交易的簽名有趣 – 例如，Bitcoin Core 預設不檢查最近檢查點之前的交易簽名，而某些 SPV 客戶端根本不檢查簽名本身，信任這已經由礦工或其他節點完成。然而，目前簽名資料是交易的組成部分，必須存在才能計算交易雜湊。

隔離簽名資料允許對簽名資料不感興趣的節點將其從磁碟中剪除，或避免首先下載它，從而節省資源。

誰受益？

隨著更多交易使用 segwit 地址，執行剪除或 SPV 節點的人將能夠以更少的頻寬和磁碟空間運作。

區塊容量/大小增加

由於舊節點只會下載去除見證的區塊，它們只對該資料強制執行 1 MB 區塊大小限制規則。因此，理解包含見證資料的完整區塊的新節點可以用新的限制取代這個限制，允許更大的區塊大小。隔離見證因此利用這個機會將區塊大小限制提高到接近 4 MB，並新增了新的成本限制以確保區塊在其資源使用上保持平衡（這有效地導致有效限制接近 1.6 到 2 MB）。

誰受益？

執行升級錢包的人將能夠透過將簽名移至交易的見證部分來利用增加的區塊大小。

邁向單一組合區塊限制

目前對區塊大小有兩個共識強制執行的限制：區塊不能大於 1MB，並且獨立地，不能在區塊中的交易之間執行超過 20,000 次簽名檢查。

在給定單一限制的情況下，找到要包含在區塊中的最有利可圖的交易集是背包問題的一個實例，可以用簡單的貪婪演算法輕鬆地幾乎完美地解決。然而，新增第二個約束使得在某些情況下找到好的解決方案變得非常困難，而且這個理論問題已在實踐中被利用，迫使區塊以遠低於容量的大小進行挖礦。

在不進行硬分叉或大幅減少區塊大小的情況下，無法解決這個問題。由於 segwit 無法修復這個問題，它選擇不使其惡化：特別是，與其為隔離見證資料引入獨立限制，不如將單一限制應用於 UTXO 資料和見證資料的加權總和，允許兩者作為組合實體同時受到限制。

誰受益？

如果未來的硬分叉將區塊容量限制變更為參數的單一加權總和，最終礦工將受益。例如：

50*sigops + 4*basedata + 1*witnessdata < 10M

這讓礦工輕鬆準確地填充區塊，同時最大化費用收入，這將透過允許使用者更可靠地計算其交易被挖掘所需的適當費用來使使用者受益。

進一步資訊

2016-10-19 更新

本頁的早期版本將「緊湊欺詐證明」列為 segwit 的好處。然而，如實作的那樣，segwit 並沒有使這變得更容易：無論有沒有 segwit，啟用緊湊欺詐證明及其帶來的好處的未來軟分叉都需要包含自己的承諾（例如，在 coinbase 交易中），而不是能夠擴展 segwit 使用的承諾資料。

先前的文字是：

緊湊欺詐證明

隨著 Bitcoin 使用者群的擴大，驗證整個區塊鏈自然變得更加昂貴。為了維持 Bitcoin 的去中心化、無需信任的特性，重要的是允許那些無法負擔驗證整個區塊鏈的人至少能夠以低成本驗證他們能夠負擔的範圍。

Segwit 透過允許未來的軟分叉擴展見證結構以包含承諾資料來改善這種情況，這將允許輕量級（SPV）客戶端強制執行共識規則，例如區塊中引入的 bitcoin 數量、區塊的大小以及區塊中使用的 sigops 數量。

誰受益？

欺詐證明允許 SPV 使用者幫助強制執行 Bitcoin 的共識規則，這將潛在地大大增加整個 Bitcoin 網路的安全性，並減少個別使用者可能受到攻擊的方式。

這些欺詐證明可以作為未來軟分叉的一部分新增到見證資料結構中，它們將幫助 SPV 客戶端強制執行規則，即使是那些不使用 segwit 功能的交易。

2020-06-23 更新

本頁的早期版本將「輸入值的簽名」列為 segwit 的好處。然而，如實作的那樣，segwit 並沒有使這變得安全：無論有沒有 segwit，都需要未來的軟分叉才能依賴簽名的輸入值。

由於每個輸入的值都是單獨簽名的，因此可以以欺騙性的方式操縱表面費用。 (CVE-2020-14199)

先前的文字是：

輸入值的簽名

當硬體錢包簽署交易時，它可以輕鬆驗證總花費金額，但只能透過擁有所有正在花費的輸入交易的完整副本來安全地確定費用，並且必須雜湊每個交易以確保它沒有被餵以虛假資料。由於單個交易的大小最大可達 1MB，因此即使被簽署的交易本身很小，這也不一定是便宜的操作。

Segwit 透過明確雜湊輸入值來解決這個問題。這意味著硬體錢包可以簡單地被給予交易雜湊、索引和值（並被告知使用了什麼公鑰），並且可以安全地簽署花費交易，無論被花費的交易有多大或多複雜。

誰受益？

硬體錢包的製造商和使用者是明顯的受益者；然而，這也可能使在小型嵌入式裝置中安全使用 Bitcoin 進行「物聯網」應用變得更加容易。

此好處僅在花費發送到 segwit 啟用地址（或 segwit-via-P2SH 地址）的交易時可用。

進一步資訊

BIP 143

隔離見證測試網啟動

Thu, 21 Jan 2016 00:00:00 +0000

我們非常高興和興奮地宣布隔離見證測試網的發布！我們鼓勵所有開發者立即開始協助測試和整合工作。

這代表了迄今為止最受期待和令人興奮的發展之一，是許多未來改進和創新的重要基礎。隔離見證透過將交易簽名資料安全地移至交易區塊外的特別指定「隔離見證」資料結構中，釋放了 Bitcoin 區塊鏈上的空間。

這項重大創新使 Bitcoin 區塊鏈的使用效率大幅提升，同時為更廣泛的 Bitcoin 生態系統開啟了令人興奮的新可能性和機會，特別是在智慧合約應用和更快速的交易方面，同時也為未來更進階的功能和可能性奠定了基礎。

這項開發始於 Bitcoin Core 開發者 Dr. Pieter Wuille 的研究工作，最初專注於解決交易可塑性問題，這是一個長期存在且廣為人知的關注點和優先事項。然而，在研究過程中以及在縮小解決方案範圍時，發現了該解決方案的其他特性，這些特性不僅允許增加區塊大小，同時還開啟了一些令人難以置信的次要好處。

這項工作由 Dr. Pieter Wuille 發起，但也包含了許多其他人的貢獻，特別感謝 Eric Lombrozo、Johnson Lau、Alex Morcos、Nicolas Dorier、Bryan Bishop、Gregory Maxwell、Peter Todd、Cory Fields、Suhas Daftuar 和 Luke-Jr。

Bitcoin Core 生態系統

提供者和其他交易所營運者將使用此版本中包含的基礎開發和創新來創造什麼，存在著廣泛的興奮和期待。到目前為止，最受歡迎的錢包和支援程式庫已表示將支援 segwit，包括 Ledger、Trezor、Electrum 和 Bitgo。此外，許多其他程式庫如 bitcoinj、bitcoinjs、pycoin 和 bitcore 的工作已經開始。

「segnet」代幣的水龍頭可在這裡取得。

第三方錢包支援的早期預覽可在以下位置取得：

mSIGNA（錢包原始碼）
Green Address（網頁錢包）

如何參與

請加入 irc.freenode.net 上的 segwit-dev IRC 頻道。

錢包提供者應閱讀遷移指南。

測試

最後也是最重要的，請協助測試隔離見證測試網！

原始碼可以在這裡找到，請 checkout segwit 分支。

編譯完成後，在標準的 bitcoind 和 bitcoin-cli 命令列中加入 -segnet。

其他背景和歷史

技術參考

SegWit BIP

BIP141：隔離見證軟分叉的概述，以及對其好處、向後相容性、共識限制和部署的討論。
BIP143：隔離見證交易中用於簽名驗證的新摘要演算法定義。
BIP144：隔離見證交易的新訊息類型和序列化格式。

參考資料

2015 年核心開發視覺化

Wed, 13 Jan 2016 00:00:00 +0000

以下影片顯示了 2015 年期間 Bitcoin Core 儲存庫中的提交活動。此期間程式碼貢獻者的完整列表可在此處找到。

https://www.youtube.com/embed/FIt7GLxxIpY

2015 年，Bitcoin Core 專案發布了 2 個主要版本的軟體以及 5 個進一步的維護版本。此外，部署並成功啟動了兩個軟分叉升級。第一個 BIP66 修復了 openssl 引入的潛在嚴重安全漏洞；第二個 BIP65 向 Bitcoin 指令碼語言新增了一個新的操作碼 CHECKLOCKTIMEVERIFY。

該專案還完成了下一個主要版本 0.12 的大部分工作，計劃於 2 月發布。0.12 將包含 libsecp256k1，該程式庫已開發了兩年半，並將簽章驗證速度提高了 7 倍，這對於未來提高可擴展性至關重要。

請注意，提交活動僅代表整體開發者活動的一部分，並未記錄同行審查者、程式碼審查者、整合測試人員和翻譯人員的活動。它也沒有準確反映在被接受到程式庫之前進行研究、討論和開發所花費的時間。

我們也想藉此機會感謝迄今為止參與貢獻 Bitcoin Core 並幫助讓 Bitcoin 為每個人變得更好的每一個人。

Bitcoin Core 聲明 -- 2016-01-07

Thu, 07 Jan 2016 00:00:00 +0000

比特幣是「點對點電子貨幣，無需經過任何金融機構，就可以在網上由一人直接付款給另一人」。我們的理想，是把比特幣系統的靈活性擴充至可以有效處理極大規模的交易，而同時保障安全以及去中心化的核心性質，因為這是令比特幣獨一無二的要素。

我們相信比特幣要達到這目標，就要在其之上建立多個層次的服務，並與其它系統接合。除此以外，我們的長遠目標還包括保護及增加比特幣用戶的隱私。

「Bitcoin Core」是一個開源軟體計劃，直接承接了原本的比特幣軟體設定。作為計劃的貢獻者，我們為比特幣社群維護並發行軟體，讓用戶考慮使用。我們致力改進比特幣的共識協定，提出的升級方案，都是按我們所認知的比特幣目標所提出，在技術上可行，而且有合理機會被廣泛支持並應用。

比特幣的共識協定可以透過軟分叉或硬分叉改動 (參與附件A)。軟分叉容許具兼容性的改動，新舊軟體可以在網路上同時存在。通過軟分叉來實現新功能不會造成擾亂，因為只有希望使用新功能的用戶才需要升級，其它用戶可以繼續正常使用原有軟體。

硬分叉則會破壞對所有現有比特幣軟體的兼容性，所有用戶必須在指定期限前升級，否則會有損失金錢的風險。這情況可能逼使不升級的用戶離開網路，並可能令各種下游軟體及應用不能運作，對比特幣的網路效應造成損害。

由於以上原因，Bitcoin Core 強烈地傾向保持兼容性，並相信應該由每個用戶決定是否升級他們正在使用的比特幣軟體。事實上利用軟分叉可以加入幾乎任何新功能。在某些情況下，硬分叉可能有些好處，如果能得到幾乎一致的同意，這些好處或可以勝過其缺點。但除了這些罕有情況，軟分叉仍然是首選。我們相信這是最合乎系統內現在和未來用戶的利益。

隨著比特幣的生態系統的成長，我們亦預計會有更多其它執行比特幣協定的軟體設定，且無可避免地這些軟體計劃可能會提出徹底不同的方案，讓比特幣的生態系統作考慮。最終而言，Bitcoin Core的開發團隊並不決定比特幣的共識規則；相對地，是由比特幣用戶選擇他們自己執行什麼比特幣軟體。因此 Bitcoin Core 刻意地沒有自動升級功能，這確保每次升級都是用戶自願進行，令用戶可以保持選擇執行什麼軟體的權力。

附件 A

硬分叉是指在更改共識規則後，在舊規則下無效的區塊可能會在新規則下變得有效。

軟分叉是指在更改共識規則後，在舊規則下有效的區塊可能會在新規則下變得無效，但所有原來是無效的區塊仍然保持為無效。

系統擴展常見問題解答

Wed, 23 Dec 2015 00:00:00 +0000

概覽

路線圖包括什麼新技術，預期在什麼時候可以使用？
隔離見證軟分叉究竟相當於多少的區塊大小增加？我聽過不同講法，如4MB、2MB、1.75MB。
隔離見證好像很複雜，比特幣生態各環節準備好沒有？
我還是覺得隔離見證很複雜，為什麼不簡單地提高區塊體積？
在實行隔離見證前會有硬分叉嗎？隔離見證方案會本身又會否包括硬分叉？
如果最終還是要硬分叉，為何現在不做？
錢包會如何使用隔離見證？
如果沒有人被逼升級，為何會有人升級？聽說P2SH用了差不多兩年時間才得到廣泛應用。
聽說你們會讓零確認不能再用，這是路線圖內哪一項技術？
在路線圖上弱區塊和IBLT只注明是2016年，你們是否也不知道它們什麼時候才可以完成？
「如果隔離見證不能減少礦工所用的頻寬，儲存空間，和處理時間，為什麼他們要支持？」
我可以怎樣幫忙？

路線圖包括什麼新技術，預期在什麼時候可以使用？

在路線圖提及到以下的技術，在充分的測試後，預計可以在以下時間完成。

2015年12月		隔離見證測試網
2016年2月	0.12.0	libsecp256k1驗證
2016年2月		隔離見證功能完成並作審核
2016年3月*	0.12.x	完成OP_CHECKSEQUENCEVERIFY (BIP68 及 112) + BIP113 並作為首個以 BIP9 versionbits 實施的軟分叉
2016年4月*	0.12.x	完成隔離見證
2016年		弱區塊, IBLTs, 或者二者都實現

* 有星號的日期是預計完成程式碼的時間。程式碼只會在充分審核後才會發表，而軟分叉完成也需要時間。(BIP66經歷數月時間在2015年7月生效，BIP65則只用了五周時間在2015年12月生效)

隔離見證測試網: 一個獨立的測試網，並非平常測試網的一部分。讓 Bitcoin Core 開發員及錢包開發員測試隔離見證功能。
Libsecp256k1驗證: 在x86_64硬體上提升交易驗證速度五至七倍。幫助新節點加入網路並減輕現有節點的負擔。
OP_CHECKSEQUENCEVERIFY: 讓雙向支付通道可以無限期使用，提升效率達25倍。
VersionBits: 允許1至29個軟分叉同時實施，讓系統升級的過程更快，更去中心化。
隔離見證: 允許交易容量上升到1.75至4倍，解決第三方延展性讓智能合約更安全，雙向支付通道效率提升66%，提供欺詐證明讓輕量節點也可以執行系統規則，更容易對腳本系統升級以允許更強大的合約功能。
IBLT及弱區塊: 只需要把總頻寬增加少許，就可以把區塊傳播所必須的頻寬減低90%以上，讓礦工可以在最短時間內把區塊傳播出去，把比特幣廣播網路的好處帶給所有全節點。IBLT及弱區塊可以把全節點所需的頻寬變得更平均，讓將來可以更安全地增加最大區塊容量。

隔離見證軟分叉究竟相當於多少的區塊大小增加？我聽過不同講法，如4MB、2MB、1.75MB。

現在的方案是以軟分叉來實現隔離見證，並把每位元組的見證內容算為0.25位元組，因此最大的區塊體積會是稍低於4MB。

然而，區塊並不應該只有見證內容，而計算非見證內容的體積時不會有折扣，因此並不可能有4MB的體積。

根據Anthony Towns的計算，如果區塊裝滿了標準的單簽名P2PKH交易，體積大概為1.6MB；如果是2-of-2多重簽名交易，則大概為2.0MB。

隔離見證好像很複雜，比特幣生態各環節準備好沒有？

有些想法是容易解釋但執行很難，有些卻是解釋很難但執行容易，隔離見證似乎是後者。

由於隔離見證可以逐步實行而不會破壞兼容性，因此生態內各環節無需特別準備。開發員可以在2015年12月推出的測試網得到實際的使用經驗並同時測試他們的軟體。

最初，只有希望支持隔離見證的礦工需要升級，讓新規則可以在主網實行。現有的應用程式只有需要使用新功能才需要改變。

隔離見證交易收取較低交易費，有更佳的性能，而且支持多重簽名智能合約，如雙向支付通道，可以作大量交易卻無需在區塊鏈作額外紀錄。我們強烈建議錢包升級，但即使不升級，現有錢包仍然可以繼續正常使用。

我還是覺得隔離見證很複雜，為什麼不簡單地提高區塊體積？

在Bitcoin Core有一行程式碼指定區塊最大是 1,000,000 位元組 (1MB)。最簡單的方法是用硬分叉改變這行程式碼，例如變為 2,000,000 位元組 (2MB)。

但硬分叉本身絕不簡單:

我們並沒有經驗: 礦工，商戶，開發員，用戶都沒有硬分叉的經驗，因此讓硬分叉可以安全實行的技術也未經測試。

軟分叉則不同。軟分叉最初由中本聰管理，然後我們又從實行BIP16所遇到的問題中得到經驗，讓我們以改良了的方法實行BIP34，以及後來的BIP66 和 65。在將來的軟分叉，我們正準備使用BIP9 version bits，讓多個軟分叉方案可以同時進行。
強制升級: 硬分叉要求所有全節點升級，而任何使用舊版本節點的人都可能會損失金錢，這不但包括全節點錢包的營運者本身，還包括依靠該全節點提供資料的輕量錢包。
需要其它的改動: 即使只是改一行程式碼來增加最大區塊容量，也會影響到系統內其它程式碼，有些更是不良的影響。例如現在可以制造一個接近1MB的交易，而現代的電腦驗證該交易需時超過30秒 (這樣的交易已存在於區塊鏈上)。在2MB的區塊下，驗證一個2MB的交易需時10分鐘，將成為一個很危險的攻擊方法。為了避免這種攻擊，就有必要改動其它程式碼。

雖然有以上的問題，但只要有充足的準備，硬分叉並不會出現致命問題，而我們也預計將來會有硬分叉。但隔離見證可以用我們更熟悉的軟分叉完成，而且帶來增加交易量以外更多的好處。

和簡單提升區塊體積相比，隔離見證需要在不同的軟體層面作更多改動。但如果我們真的希望比特幣可以擴展，我們無論如何也需要根本性的改動，而隔離見證可以逐漸地鼓勵人們升級至更具擴展性的方案，卻無需強逼他們這樣做。

開發員，礦工，以及社群已對軟分叉有充分經驗，我們相信實行隔離見證所需時間並不比提升容量的硬分叉為多，而且會更安全。

在實行隔離見證前會有硬分叉嗎？隔離見證方案會本身又會否包括硬分叉？

不會，這並非路線圖的一部分。

如果最終還是要硬分叉，為何現在不做？

利用有廣泛共識的軟分叉，我們能夠把系統擴展而沒有硬分叉的副作用，因此即使預期會有硬分叉，這並不是現在就要做的充分理由。

在路線圖提到的改進，除提供額外的交易容量以外，配合其它技術如雙向支付通道，可以讓用戶減少使用區塊鏈，變相提高了比特幣系統的容量，卻不用增加全節點使用的頻寬。例如：

BIP68 及 BIP112 允許無限期的雙向支付通道，可以大為減少紀錄在區塊鏈的交易。
隔離見證允許在關閉支付通道的同時開設新的支付通道，減少因為更換通道所需的區塊鏈空間約66%。
隔離見證允許將來更容易以軟分叉改變比特幣的腳本語言，例如從簽名提取公鑰，或使用Schnorr聯合簽名算法，從而減少交易的平均大小。
實行隔離見證後，當無效區塊出現時就可以產生很簡潔的欺詐證明，這會讓進行簡單交易驗證 (SPV) 的輕量節點的安全性更接近全節點，可以讓整個網路在較少的全節點下仍能運作。

這些技術的實際效果仍然未知，但實行一個具廣泛共識的軟分叉可讓我們立即得益並且測試和評估中期的可能性，以及用這些資料作長期的規劃。

錢包會如何使用隔離見證？

現在支持 P2SH 的錢包可以分兩階段轉移至完整的隔離見證：

第一階段：腳本需要經過兩次雜湊運算，首先是變成256位元組，然後再變成160位元組。這個160位元組的雜湊和現有的P2SH地址兼容，因此已升級的錢包和現有的錢包之間可以互相收付款項。
第二階段：腳本只需一次雜湊運算變為256位元組。這格式和現有錢包不相容，但允許更有效率地使用區塊空間，及提供更強的防碰撞攻擊性能。

如果沒有人被逼升級，為何會有人升級？聽說P2SH用了差不多兩年時間才得到廣泛應用。

在隔離見證交易中，見證部分的每位元組只算為0.25位元組，也就是說這部分的交易費有75%的折扣，但只限於隔離見證的用戶。

David Harding 提供了下表以估計在不同費用和交易類型下可以節省的費用。例如如果一個常見的250位元組交易收費是0.01美元，用隔離見證花費一個P2PK-in-P2SH輸出就可以節省約0.003美元。

交易	節省位元組	$0.01/250B	$0.05/250B	$0.25/250B	$1.00/250B
P2PK-in-P2SH	79/107	$0.003	$0.015	$0.079	$0.316
1-of-1 P2SH 多簽	83/112	$0.003	$0.016	$0.083	$0.332
2-of-2 P2SH 多簽	163/219	$0.006	$0.032	$0.163	$0.652
2-of-3 P2SH 多簽	189/254	$0.007	$0.037	$0.189	$0.756

(費用金額只作參考，我們並不預期交易費會達到上表顯示的最高情況。)

收取固定比例費用 (如免費或1%交易額) 的網頁錢包和交易所會最早應用隔離見證，因為即使每個交易節省很少，每天數以千計的交易加起來都會非常可觀。

聽說你們會讓零確認不能再用，這是路線圖內哪一項技術？

這並不是路線圖的一部分。作為現在 Bitcoin Core 版本的預設設定，在收到一個未確認交易後，就不會再接受其它有相同輸入的交易。有些人認為這表示他們首個見到的交易就是安全的，但其實不是；如果真的是這樣，我們根本不需要區塊鏈。

在現時的預設設定下，人們並不能更新他們未確認的交易。在最初的 Bitcoin 版本，其實是有方法讓使用者表明他希望交易可被更新，但為了防止拒絕服務攻擊，中本聰在2010年關閉了這功能。

最近 Bitcoin Core 的開發員發現只要要求更新交易的同時要求使用者要付出更多的交易費，就可以防止上述的拒絕服務攻擊，因此他們重開了中本聰那個允許交易被替換的機制。這功能會在預計2016年1至2月在 Bitcoin Core 0.12.0 推出，但和中本聰原本的設計一樣，只有希望可以替換交易的使用者才需要選擇使用支持該功能的錢包。

現在並沒有錢包提供這功能，但將來這類錢包可以把多個未確認交易合並以減少所需要的區塊鏈空間，也可以讓用戶提高未確認交易的費用，不會因為之前付費不足讓交易「阻塞」在錢包內。

在路線圖上弱區塊和IBLT只注明是2016年，你們是否也不知道它們什麼時候才可以完成？

弱區塊和IBLT是兩種仍在研究的技術，需要選擇適當的參數，但因為參與的開發員有限，我們難以估計在什麼時候才能推出。

弱區塊和IBLT都只涉及網路改善而不是軟分叉或硬分叉，因此只需要較短的測試時間就可以推出讓節點升級，我們希望可以在2016年內完成。

在推出弱區塊和IBLT後，我們可以利用一個簡單而無爭議的軟分叉來規範交易次序讓它們更有效率，這軟分叉可以透過BIP9 versionBits 推出。

「如果隔離見證不能減少礦工所用的頻寬，儲存空間，和處理時間，為什麼他們要支持？」

其實大部分以前的軟分叉都沒有為礦工帶來這些好處，例如：

BIP16 (P2SH)	新交易種類
BIP30 (重覆交易ID)	要求檢查重覆交易ID
BIP34 (Coinbase 內記錄區塊高度)	讓礦工可用的coinbase空間減少 4 位元組
BIP65 (OP_CLTV)	新腳本命令

在2015年7月正式執行的 BIP66 (嚴格 DER 簽名) 軟分叉讓我們可以轉用libsecp256k1作交易驗證，讓驗證時間大減，讓礦工得益。

而隔離見證可以為其使用者帶來以下好處：

這永久地解決第三方延展性，讓多階段智能合約得以實現；減低交易費；讓比特幣腳本升級更容易，錢包更容易得到新功能。

通過以前的軟分叉和溝通，例如在香港比特幣擴展性會議內的礦工座談會，礦工一再表達了即使他們未必有直接得益，他們也希望比特幣成為一個最有用的系統。隔離見證和路線圖上其它改進可以顯著地提升比特幣的可用性。

另外，隔離見證允許礦工在區塊內加入更多交易，因此也可提升在每個區塊內得到的收入。

我可以怎樣幫忙？

首先閱讀在 Bitcoin.org 上的 Bitcoin Core貢獻者網頁。其中程式碼審閱是實行軟分叉極重要的一部分。

如果你想得到更多有關如何貢獻的建議，請加入#bitcoin-dev IRC 頻道討論。

比特幣系統擴展

Mon, 21 Dec 2015 00:00:00 +0000

我們連署支持比特幣系統擴展路線圖。我們已在Bitcoin Core計劃內為可擴展性工作多年，認為這是最可以延續我們一直以來努力的方向。

有關更多詳情請參閱常見問題解答。

如果你想參與連署，請到#53。

隔離見證影片演示

Mon, 14 Dec 2015 00:00:00 +0000

這是 Pieter Wuille 關於隔離見證的擴展演示。

https://www.youtube.com/embed/NOYNZB5BCHM

Bitcoin 系統容量增加路線圖

Mon, 07 Dec 2015 00:00:00 +0000

以下路線圖最初由 Gregory Maxwell 於 2015 年 12 月 7 日發布到 bitcoin-dev 郵件列表。

香港的 Scaling Bitcoin 研討會剛剛結束。許多令人著迷的提案被展示出來。我認為這是分享我對 Bitcoin 系統容量增加近期發展方向看法的好時機。我相信我們現在處於一個絕佳的位置,社群已經準備好提供一個清晰的前進路徑,並有一個共同的願景來解決系統的需求,同時維護其價值。

我認為首先清楚表達我認為應該指導 Bitcoin 系統持續發展的一些相關原則很重要。

Bitcoin 是點對點電子現金,由於透過去中心化為使用者帶來貨幣自主權,因此相對於傳統系統具有價值。Bitcoin 試圖解決傳統貨幣的根本問題:使其運作所需的所有信任–

– 並不是說正當的信任是壞事,但信任使系統變得脆弱、不透明且運營成本高昂。信任失敗導致系統性崩潰,信任管理創造不平等和壟斷鎖定,自然產生的信任阻塞點可能被濫用以拒絕正當程序的存取。透過使用加密證明和去中心化網路,Bitcoin 最小化並取代了這些信任成本。

使用現有技術,規模和去中心化之間存在基本的權衡。如果系統成本太高,人們將被迫信任第三方,而不是獨立執行系統規則。如果 Bitcoin 區塊鏈的資源使用量相對於可用技術來說太大,Bitcoin 將失去相對於傳統系統的競爭優勢,因為驗證成本太高(將許多使用者定價排除在外),迫使信任重新進入系統。如果容量太低,我們的交易方法效率太低,存取鏈進行爭議解決的成本將太高,再次將信任推回系統。

由於 Bitcoin 是電子現金,它_不是_一個通用資料庫;對廉價高度複製永久儲存的需求是無限的,Bitcoin 不能也不會滿足非電子現金(非 Bitcoin)使用的需求,這並不可恥。幸運的是,Bitcoin 可以與解決其他應用程式的其他系統互操作,而且–憑藉運氣和努力–Bitcoin 系統可以並且將會滿足世界對電子現金的需求。

幸運的是,許多偉大的技術正在開發中,使得導航權衡變得更容易。

首先:經過幾年的開發,Bitcoin Core 最近合併了 libsecp256k1,這導致簽名驗證效能大幅提高。結合其他最近的工作,我們現在在 0.12 中獲得的 ConnectTip 效能比以前的版本高 7 倍。這已經醞釀了很長時間,如果沒有對它的預期和早期工作(如 headers-first),我可能會在去年主張減少區塊大小。這種廣泛可用的生產 Bitcoin 軟體技術水平的改進為一些容量增加奠定了基礎,同時仍在彌補我們的去中心化赤字。這將瓶頸從 CPU 轉移到更強烈地轉移到傳播延遲和頻寬上。

Versionbits (BIP9) 正在接近成熟,將允許 Bitcoin 網路擁有多個進行中的軟分叉。到目前為止,我們必須完全序列化軟分叉工作,而且也沒有真正的方法來處理在核心中合併但被網路拒絕的軟分叉。所有這些都在 BIP9 中得到解決,這應該允許我們加快網路改進的步伐。看起來 versionbits 將準備好在網路上執行的下一個軟分叉中使用。

接下來是,在香港的 Scaling Bitcoin 上,Pieter Wuille 介紹了將隔離見證帶到 Bitcoin。提議的是一個_軟分叉_,透過重組區塊中的資料以單獨處理簽名,從而增加 Bitcoin 的可擴展性和容量,並在此過程中將它們從當前區塊大小限制的範圍中移除。

該特定提案最多相當於 4MB 區塊大小增加。這種分離允許新的安全模型,例如跳過下載您不打算檢查的資料以及改善輕客戶端的效能(尤其是具有高隱私性的客戶端)。該提案還包括欺詐證明,這使得違反 Bitcoin 系統的行為可以用緊湊的證明來證明。這完成了 Bitcoin 白皮書「簡化支付驗證」部分中描述的「警報」願景,並將使輕客戶端能夠執行系統的所有規則(在他們不會與會產生證明的人分離的新強假設下)。該設計具有許多其他功能,例如使進一步的增強更安全並消除簽名可塑性問題。如果廣泛使用,該提案將提供 2 倍的容量增加(如果廣泛使用多重簽名則更多),但最重要的是,它透過提高效率和允許更多權衡(特別是,您可以使用更少的頻寬來換取強大的非分區假設)使該額外容量–以及未來更多的容量–更安全。

在 https://github.com/sipa/bitcoin/commits/segwit 有一個工作實作(儘管它還沒有欺詐證明)。

(Pieter 的演講在: 文字記錄、幻燈片、影片)。

我在 Elements Alpha 側鏈中成功部署了早期(硬分叉)版本的 segwit;現在提議的軟分叉 segwit 是第二代設計。我認為在相對較短的時間內部署它是相當合理的。 segwit 設計要求未來進行與 bitcoinj 相容的硬分叉以進一步提高其效率–但這不是獲得大部分好處所必需的,這意味著它可以按照自己的時間表並以非爭議的方式發生。

超越 segwit,圍繞更高效的區塊中繼一直有相當大的活動在醞釀。有一系列提案,有些源於我受 p2pool 啟發的非正式草圖,有些是獨立發明的,稱為「弱區塊」、「瘦區塊」或「軟區塊」。這些提案建立在高效中繼技術(如中繼網路協定或 IBLT)之上,並在找到區塊之前將區塊的幾乎所有傳輸時間移至之前,從孤塊競賽計算中消除大小。我們在當前區塊大小下已經迫切需要這個。這些尚未實作,但幸運的是路徑似乎很清晰。我至少看到了一個或多或少完整的規範,我預計在幾個月內會看到使用它的東西執行。這個工具將在礦工沒有策略行為的情況下消除傳播延遲成為問題。當礦工策略性地行為時更好地理解他們的行為是一個開放的問題。

同時,有很多關於「非頻寬」擴展機制的活動正在進行。非頻寬擴展機制是像交易切割和雙向支付通道這樣的工具,它們使用聰明的智慧合約而不是增加頻寬來增加 Bitcoin 的容量和速度。關鍵的是,這些方法直接針對容量與自主性權衡的核心,並可能允許我們實現非常高的容量和非常高的去中心化。CLTV (BIP65) 於一個月前部署,現在在網路上活躍,對這些技術非常有用(對於使保留退款工作至關重要);CSV (BIP68 / BIP112) 正在核心中合併的管道中並取得良好進展(並且可能會在 segwit 之前準備好)。正在開發用於非頻寬擴展的進一步 Bitcoin 協定改進:許多這些提案確實需要反可塑性修復(將由 segwit 提供),並且已經提供了 checksig 標誌改進,還有更多正在開發中,使用 segwit 部署會容易得多。我預計在六個月內,我們可以有更多功能準備好部署以啟用這些技術。即使沒有它們,我相信我們在近期容量方面的位置也是可以接受的,但為未來啟用它們很重要。

http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning 是關於 Lightning 所需的一些網路功能的相關演講,Lightning 是一個雙向支付通道提案,許多方現在正在研究;過去討論的其他非頻寬改進包括交易切割,我認為這是理解交易容量如何大於區塊鏈容量的基本直覺的必讀: https://bitcointalk.org/index.php?topic=281848.0,儘管還有許多其他的。)

更遠一點,有幾個與彈性上限或基於允許礦工以某種成本生產更大區塊的激勵對齊動態區塊大小控制相關的提案。這些提案有助於保持礦工和一般節點運營商之間的激勵一致,並防止礦工之間的背叛破壞最終將為安全提供資金的手續費市場行為。我認為現在容量足夠高,所需容量足夠低,我們不會立即需要這些提案,但它們長期來說將是至關重要的。我計劃在接下來的幾個月裡幫助並推動這些提案朝著更具體的方向發展。

最後–在某個時候,上述的容量增加可能還不夠。在中繼改進、segwit 欺詐證明、動態區塊大小控制和其他技術進步上的交付將降低風險,因此降低圍繞適度區塊大小增加提案的爭議(例如 2/4/8 重新調整以尊重 segwit 的增加)。當改進和理解使其風險相對於不部署它們的風險而言被廣泛接受時,Bitcoin 將能夠推進這些增加。在 Bitcoin Core 中,我們應該準備好補丁來實作它們,當需要和意願出現時,以防止基本軟體工程成為限制因素。

我們最近和當前的進展很好地定位了 Bitcoin 生態系統來處理其當前的容量需求。我認為上述內容提出了一些明確可實現的里程碑,以繼續推進 Bitcoin 容量的技術,同時使我們處於進一步改進和演進的良好位置。

TL;DR: 我建議我們立即致力於 segwit 4MB 區塊軟分叉,它增加了容量和可擴展性,最近的加速和即將到來的中繼改進使 segwit 成為合理的風險。BIP9 和 segwit 也將使進一步的改進更容易和更快地部署。我們將繼續為基於非頻寬增加的擴展奠定基礎,同時構建額外的工具,使頻寬增加長期更安全。進一步的工作將為 Bitcoin 準備進一步的增加,當有理由時這將成為可能,同時也提供使它們合理的基礎。

感謝您的時間,

最初由 Gregory Maxwell 於 2015 年 12 月 7 日發布到 bitcoin-dev 郵件列表 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

給 Bitcoin 社群的公開信

Tue, 01 Sep 2015 00:00:00 +0000

作為 Bitcoin 的積極貢獻者,我們分享這封信來傳達我們關於技術共識和 Bitcoin 可擴展性的行動計劃。

Bitcoin 對不同的人有不同的意義。然而,Bitcoin 的開發和維護是一項人類的努力。Satoshi 尋求審查和合作,而 Bitcoin 開發者隨後的工作使系統更加安全,速度提高了幾個數量級。Bitcoin 開發者社群致力於 Bitcoin 的未來,關注網路的健康,追求最高的效能標準,並代表每個人努力保持 Bitcoin 的安全。

我們致力於 Bitcoin,並回應社群的需求。在過去五年中,我們編寫了程式碼並管理了超過 50 個 Bitcoin 版本,並審查了超過 45 個正式提案以改善 Bitcoin 的效能、安全性和可擴展性。技術討論雖然有時激烈,但始終專注於改善 Bitcoin。

在這個領域已經完成了大量工作,從 CPU 瓶頸、記憶體使用、網路效率和初始區塊下載時間的實質性改進,到一般的演算法擴展。然而,仍然存在許多關鍵挑戰,每個挑戰都有許多重要的考慮因素和權衡需要評估。我們多年來一直致力於 Bitcoin 擴展,同時保護網路的去中心化、安全性和無需許可的創新等核心特性。我們致力於確保盡可能多的使用者從 Bitcoin 中受益,而不侵蝕這些基本價值。

不時會有爭議,但 Bitcoin 是一個安全關鍵系統,擁有數十億美元的使用者資產,一個錯誤可能會危及這些資產。為了減輕潛在的存在風險,我們所有人都應該花時間評估已經提出的提案,並透過共識建立過程就最佳解決方案達成一致。

在未來幾個月,兩個開放研討會將把社群聚集在一起探討這些問題。第一個 Scaling Bitcoin 研討會將於 9 月 12-13 日在蒙特婁舉行。第二個研討會計劃於 12 月 6-7 日舉行,並將在香港舉辦,以更包容 Bitcoin 的全球使用者群體。

我們請求社群不要預先判斷,而是透過現有流程和支援研討會協作達成最佳結果。很高興看到對活動的廣泛興奮和參加的技術參與者的高度集中。

我們相信透過共同努力,我們可以就最佳行動方案達成一致。我們相信這是前進的方向,並加強了迄今為止很好地服務於 Bitcoin 開發社群(以及一般的 Bitcoin)的現有審查流程。

我們歡迎您的參與,因為我們繼續努力將 Bitcoin 帶入未來。

簽署:

(支持這封信的技術貢獻者名單)

Wladimir J. van der Laan

Pieter Wuille

Cory Fields

Luke Dashjr

Jonas Schnelli

Jorge Timón

Greg Maxwell

Eric Voskuil

Amir Taaki

Dave Collins

Michael Ford

Peter Todd

Phillip Mienk

Suhas Daftuar

R E Broadley

Eric Lombrozo

Daniel Kraft

Chris Moore

Alex Morcos

dexX7

Warren Togami

Mark Friedenbach

Ross Nicoll

Pavel Janík

Josh Lehan

Andrew Poelstra

Christian Decker

Bryan Bishop

Benedict Chan

฿tcDrak

William Swanson

Charlie Lee

Jeremy Rubin

Esteban Ordano

Manuel Araoz

Ruben de Vries

更多簽名可以在 change.org 找到。

這封信最初於 2015 年 9 月 1 日發表在 Bitcoin Magazine 上,網址為 https://bitcoinmagazine.com/articles/open-letter-bitcoin-community-developers-1441146317。