---
title: "Bitcoin 難度調整：目標值、重新定標與限制"
description: "Bitcoin 每 2,016 個區塊重新設定一次工作量證明門檻，使長期平均出塊間隔趨近十分鐘。應分別分析目標值、緊湊編碼、時間戳記視窗、限幅、網路規則與機率結果。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Bitcoin 難度調整：目標值、重新定標與限制
> 僅供協定分析教育參考。顯示的難度、算力估算或調整預測本身不能證明獲利能力、確認安全性、去中心化程度或未來網路狀況。
## 直接回答
Bitcoin 難度調整是一項確定性的共識規則，它會定期改變可接受的最大工作量證明雜湊值，即`目標值`，從而在活躍算力變化時使長期平均出塊間隔趨近十分鐘。在主網上，目標值通常在 2,016 個區塊內保持不變，並為下一週期重新計算。每個驗證節點都根據先前區塊標頭推導出同一個必需目標值；礦工不對此投票，區塊瀏覽器也不設定它。
只有當區塊標頭雜湊按整數解讀後小於或等於其 32 位元 `nBits` 欄位編碼的目標值時，該區塊標頭的工作量證明才有效。目標值越小，符合條件的雜湊越少，因此預期嘗試次數越多。按慣例，難度是與目標值成反比的相對數：
`D = T₁ / T`
其中 `T` 是目前目標值，`T₁` 是難度 1 的參考目標值。因此目標值和難度方向相反。兩者都不是對機器數量、能耗、礦工身分或觀測算力的直接測量。
十分鐘是期望值，不是時間表。雜湊嘗試與區塊到達具有隨機性，因此即使算力和目標值穩定，兩個區塊也可能僅相隔數秒，或一小時都沒有新區塊。重新定標是跨週期的延遲回饋：它能減少出塊頻率的持續偏移，卻無法消除短期變異，也不能即時回應算力衝擊。
難度調整會影響按區塊高度觸發事件的時間節奏，包括補貼減半，但它並不定義補貼金額、210,000 區塊的減半間隔或最終供應規則。它本身也不負責選擇規範鏈。Bitcoin 的分叉選擇在驗證區塊標頭和區塊後比較累計鏈工作量；單一區塊顯示的難度不是累計工作量。
## 如何分析重新定標
1. **確定網路與規則集。** 主網、舊版測試網、Testnet4、signet 和 regtest 並非共享所有例外。記錄鏈、軟體規則集、候選高度，以及是否啟用重新定標或特殊最低難度區塊。
2. **解碼宣告的目標值。** 把候選區塊標頭的緊湊 `nBits` 值展開為目標值 `T`。拒絕負數、零、溢位或高於 `powLimit` 的目標值，再要求區塊標頭雜湊滿足 `≤ T`。
3. **定位調整邊界。** 在主網上，當候選高度可被 2,016 整除時必須使用新目標值。其他高度必須繼續沿用前一區塊的 `nBits`。
4. **選擇時間戳記視窗。** 在主網邊界，Bitcoin Core 用前一個 2,016 區塊週期最後一區塊的時間戳記減去首區塊時間戳記。這兩個端點包含 2,016 個區塊，卻只有 2,015 個區塊間隔；名義目標跨度仍為 `2,016 × 600 = 1,209,600` 秒。
5. **限制實耗跨度。** 令 `t = clamp(t_actual, 302,400, 4,838,400)` 秒，即名義 14 天的四分之一至四倍。區塊標頭時間戳記是礦工提供、並受其他有效性約束的共識欄位，不是節點的精確接收時間。
6. **計算並編碼新目標值。** 依照目前主網規則，以整數算術計算 `T_new = min(powLimit, T_old × t / 1,209,600)`，再把結果緊湊編碼為 `nBits`。由於整數運算和緊湊格式取整，顯示比率可能與理想十進位計算略有不同。
7. **按機率解讀結果。** 近似有 `D_new / D_old = T_old / T_new`。應把調整結果與出塊時間分布和明確標為估算的算力一起比較，並與收入、累計鏈工作量、集中度及確認風險結論分開。
主網公式使用最後一區塊的目標值作為 `T_old`。Testnet4 有意採用不同規則：BIP 94 允許在時間戳記延遲足夠久後出現特殊最低難度區塊，但禁止週期首區塊使用該例外，並以首區塊的真實難度作為週期調整基準，避免暫時例外污染下一週期。Regtest 通常停用重新定標。未註明網路的規則描述是不完整的。
## 計算範例
### 1. 名義週期不發生變化
假設 `T_old = 10` 個任意目標單位，測得跨度恰為 `1,209,600` 秒。限幅不會改變它：
`T_new = 10 × 1,209,600 / 1,209,600 = 10`
難度比為 `10 / 10 = 1`，所以理想化難度不變。這不表示每個區塊都用了十分鐘；視窗內隨機出現的快慢間隔可能彼此抵銷。
### 2. 12 天的快速週期
假設端點時間戳記相隔 12 天。12 天位於限幅區間內，因此目標值比率為 `12 / 14 = 6/7`，新目標值約為舊目標值的 85.7143%，而：
`D_new / D_old ≈ 14 / 12 = 1.166667`
因此理想化難度上升約 16.67%，而非 14.29%。目標值的下降百分比與難度的上升百分比並不相等，因為兩者互為倒數。
### 3. 四倍限幅
如果端點時間戳記僅相隔 1.75 天，計算將採用 3.5 天的下限。目標值最多約降至舊值的四分之一，所以一次主網調整可使難度最多約升至四倍。
如果時間戳記跨越 70 天，計算則採用 56 天的上限。目標值最多約升至四倍，難度最多約降至四分之一，除非 `powLimit` 更早封頂。「四倍限制」必須說明所指的是目標值還是難度，以及變化方向。
### 4. 週期中點的算力衝擊
使用一個簡化期望：前 1,008 個區塊以符合十分鐘間隔的速率挖出，約用七天。隨後在目標值不變時有 30% 算力消失。剩餘 70% 算力的預期間隔為 `10 / 0.70 ≈ 14.286` 分鐘，因此後 1,008 個區塊約需十天，整個週期約 17 天。
忽略端點、隨機性和緊湊取整影響，目標值乘數為 `17/14 ≈ 1.214286`，難度乘數為 `14/17 ≈ 0.823529`，即下降約 17.65%。它不會完整下降 30%，因為衝擊只影響半個週期。若之後算力一直維持在 70%，此次部分調整後區塊預期仍慢於十分鐘，下一週期會繼續回饋。
## 風險與審查失誤
### 規則與算術錯誤
- 把難度稱作門檻本身，沒有區分目標值與其反向相對指標。
- 把公式方向寫反，導致快速週期提高目標值，或慢速週期提高難度。
- 把 2,016 個區塊當作 2,016 個被測時間戳記間隔；目前主網端點計算跨越 2,015 個間隔。
- 忘記 3.5 天與 56 天限幅、`powLimit`、整數除法或緊湊 `nBits` 取整。
- 把主網說法套用於 Testnet4、舊版測試網、signet、regtest 或其他工作量證明鏈。
- 把瀏覽器在邊界區塊出現前的預測當作共識輸入，而不是估算。
- 使用本地接收時間，而不是共識計算實際使用的區塊標頭時間戳記。
- 混淆目前區塊難度、單塊工作量、累計鏈工作量和分叉選擇結果。
### 測量與推論
- 把估算算力當作線上機器的直接清單，而不是根據工作量和隨機到達作出的推論。
- 從週期的一小部分外推調整值，此時一般出塊時間變異可能占主導。
- 把難度上升當作價格、礦工收入、能耗或去中心化程度上升的證明。
- 不檢查絕對工作量、集中度和持續時間，就把難度下降當作網路故障證明。
- 比較不同鏈的難度數字，卻不統一雜湊函數、參考目標值和調整規則。
- 把十分鐘描述為截止時間、服務等級保證或固定確認時間。
- 推斷礦工獲利能力時忽略區塊獎勵、手續費、上線率、礦池條款、避險、電力、融資和設備效率。
### 安全與維運
- 把重新定標當作週期內算力突然流失或湧入時的即時保護。
- 假設降低難度會增加區塊容量或立即清空交易積壓。
- 僅根據難度制定確認策略，忽略累計工作量、重組能力和交易價值。
- 評估調整機制時忽略時間戳記操縱誘因與協定特定的緩解措施。
- 在沒有跨實作測試向量和啟用計畫時改動共識算術、邊界索引或緊湊編碼。
## 常見誤解
- **每個 Bitcoin 區塊都耗時十分鐘。** 十分鐘是在算力匹配時的目標均值；單次到達時間仍然隨機。
- **礦工投票決定下一難度。** 驗證節點獨立計算允許的 `nBits`；宣告其他值的區塊無效。
- **目標值縮小 20% 就是難度提高 20%。** 難度成反比：目標值乘數 0.8 對應難度乘數 1/0.8 = 1.25，即提高 25%。
- **重新定標直接測量算力。** 它回應帶時間戳記的區塊產出；任何算力數字都是帶有抽樣與時間戳記假設的估算。
- **難度就是 Bitcoin 的貨幣政策。** 重新定標幫助穩定按高度發行的時間節奏；另有共識規則定義補貼值與減半。
## 相關主題
- [出塊時間](/zh-tw/crypto/block-time/)
- [分叉選擇規則](/zh-tw/crypto/fork-choice-rule/)
- [算力](/zh-tw/crypto/hashrate/)
- [挖礦](/zh-tw/crypto/mining/)
- [工作量證明](/zh-tw/crypto/proof-of-work/)
## 資料來源
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org（存取日期：2026-08-19）
- [Bitcoin Core: Proof-of-Work Calculations](https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp) - Bitcoin Core（存取日期：2026-08-19）
- [Bitcoin Core: Network Consensus Parameters](https://github.com/bitcoin/bitcoin/blob/master/src/kernel/chainparams.cpp) - Bitcoin Core（存取日期：2026-08-19）
- [Bitcoin Core: Consensus Parameter Definitions](https://github.com/bitcoin/bitcoin/blob/master/src/consensus/params.h) - Bitcoin Core（存取日期：2026-08-19）
- [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Project（存取日期：2026-08-19）
- [Bitcoin Developer Reference: Block Headers](https://developer.bitcoin.org/reference/block_chain.html) - Bitcoin Project（存取日期：2026-08-19）
- [BIP 94: Testnet 4](https://bips.dev/94/) - Bitcoin Improvement Proposals（存取日期：2026-08-19）
- [Bitcoin Core RPC: getblockheader](https://developer.bitcoin.org/reference/rpc/getblockheader.html) - Bitcoin Project（存取日期：2026-08-19）
Source: https://wiki.fcontext.com/zh-tw/crypto/difficulty-adjustment/index.mdx