手續費

手續費（Transaction Fee）是發送比特幣交易時支付給礦工的費用。與傳統金融不同，比特幣手續費不是按交易金額的百分比計算，而是按交易的資料大小計算。這意味著發送 0.001 BTC 和發送 1000 BTC 的手續費可能完全相同。

手續費的本質

為什麼需要手續費？

手續費的作用：

1. 激勵礦工
   - 礦工消耗資源打包交易
   - 手續費是他們的收入來源之一
   - 區塊獎勵減半後越來越重要

2. 防止垃圾交易
   - 無成本 = 可無限發送
   - 手續費是「使用費」
   - 抑制濫用和攻擊

3. 分配稀缺資源
   - 區塊空間有限
   - 手續費是競價機制
   - 最願意付費的交易優先

4. 網路可持續性
   - 未來區塊獎勵趨近於零
   - 手續費將成為唯一獎勵

手續費計算公式

基本公式：

手續費 = 輸入總額 - 輸出總額

範例：
輸入：1.00000000 BTC
輸出1（收款方）：0.50000000 BTC
輸出2（找零）：0.49990000 BTC
手續費：1.00000000 - 0.50000000 - 0.49990000 = 0.00010000 BTC

注意：
- 差額自動成為手續費
- 沒有「找零」= 高額手續費
- 錢包會自動計算合適的找零

費率單位

sat/vB（最常用）

satoshi per virtual byte

1 sat/vB = 每虛擬位元組 1 聰

計算：
費率 = 總手續費(sat) / 交易虛擬大小(vB)

範例：
手續費：10,000 sat
交易大小：200 vB
費率：10,000 / 200 = 50 sat/vB

換算：
1 BTC = 100,000,000 sat
1 sat/vB = 0.00000001 BTC/vB

其他單位

單位	說明	換算
sat/vB	每虛擬位元組的聰	1
sat/WU	每權重單位的聰	1 sat/vB = 4 sat/WU
BTC/kvB	每千虛擬位元組的 BTC	1 sat/vB = 0.00001 BTC/kvB
sat/B	每位元組的聰（舊式）	≈ sat/vB（SegWit 前）

虛擬位元組 vs 實際位元組

SegWit 引入了權重和虛擬位元組：

交易權重(WU) = 基本資料 × 4 + 見證資料 × 1
虛擬大小(vB) = 權重 / 4

範例（P2WPKH 交易）：
基本資料：68 bytes × 4 = 272 WU
見證資料：107 bytes × 1 = 107 WU
總權重：379 WU
虛擬大小：379 / 4 = 94.75 vB

為什麼這樣設計？
- 向後兼容舊節點
- 激勵使用 SegWit
- SegWit 交易有「見證折扣」

交易大小因素

影響大小的因素

輸入數量（最大影響）：
- 每個 P2PKH 輸入：~148 bytes
- 每個 P2WPKH 輸入：~68 vB
- 每個 P2TR 輸入：~58 vB

輸出數量：
- 每個 P2PKH 輸出：~34 bytes
- 每個 P2WPKH 輸出：~31 bytes
- 每個 P2TR 輸出：~43 bytes

固定開銷：
- 交易版本：4 bytes
- 輸入計數：1-3 bytes
- 輸出計數：1-3 bytes
- 鎖定時間：4 bytes
- SegWit 標記：2 bytes（如適用）

典型交易大小

類型	輸入	輸出	大小 (vB)
簡單 P2WPKH	1	2	~141
整合 UTXO	5	1	~350
批量支付	1	10	~350
多簽 2-of-3	1	2	~200
Taproot	1	2	~111

地址類型對費用的影響

從最省錢到最貴（花費時）：

1. P2TR (bc1p...)
   - 最新、最高效
   - 輸入：~58 vB

2. P2WPKH (bc1q...)
   - 原生 SegWit
   - 輸入：~68 vB

3. P2SH-P2WPKH (3...)
   - 兼容 SegWit
   - 輸入：~91 vB

4. P2PKH (1...)
   - Legacy 地址
   - 輸入：~148 vB

建議：使用 bc1p 或 bc1q 地址省手續費

費率估算

即時費率

費率變化因素：

1. 記憶池擁堵程度
   - 待確認交易多 → 費率高
   - 記憶池清空 → 費率低

2. 時間因素
   - 週末通常較低
   - 亞洲/歐洲工作時間較高
   - 重大事件時飆升

3. 區塊空間需求
   - 牛市交易量大
   - Ordinals/Runes 活躍時
   - 鏈上活動增加時

確認時間對照

典型費率與確認時間（會變動）：

| 費率 (sat/vB) | 預期確認 | 適用場景 |
|--------------|---------|---------|
| 100+ | 下一區塊 | 緊急交易 |
| 50-100 | 1-2 區塊 | 重要交易 |
| 20-50 | 3-6 區塊 | 一般交易 |
| 10-20 | 1 小時+ | 不急 |
| 5-10 | 數小時 | 可等待 |
| 1-5 | 不確定 | 可能永不確認 |

注意：實際情況隨擁堵程度變化

費率查詢

推薦工具：

1. mempool.space
   - 即時費率建議
   - 區塊視覺化
   - 歷史數據

2. bitcoinfees.earn.com
   - 費率估算
   - 延遲預測

3. Bitcoin Core RPC
   bitcoin-cli estimatesmartfee 6
   # 估算 6 區塊內確認的費率

省錢技巧

整合 UTXO

問題：
大量小額 UTXO → 大交易 → 高手續費

解決方案：低費率時整合

範例：
有 50 個 0.001 BTC 的 UTXO
高峰期花費：50 個輸入 × 68 vB = 3400 vB
費率 50 sat/vB → 170,000 sat = 0.0017 BTC 手續費

低谷期整合：
費率 5 sat/vB → 17,000 sat = 0.00017 BTC
省了 0.00153 BTC！

之後花費整合後的 1 個 UTXO：
只需 ~141 vB × 50 sat/vB = 7,050 sat

批量交易

單獨發送 vs 批量發送：

單獨發送 10 筆：
10 × 141 vB = 1,410 vB
費率 50 sat/vB → 70,500 sat

批量發送（1 輸入，10 輸出）：
~350 vB
費率 50 sat/vB → 17,500 sat

節省：75%！

適用場景：
- 交易所提款
- 薪資發放
- 定期支付

使用 SegWit/Taproot

地址類型比較（花費 1 輸入 2 輸出）：

P2PKH (1...)：~226 vB → 11,300 sat @50sat/vB
P2WPKH (bc1q...)：~141 vB → 7,050 sat @50sat/vB
P2TR (bc1p...)：~111 vB → 5,550 sat @50sat/vB

節省：
bc1q vs 1...：節省 38%
bc1p vs 1...：節省 51%

建議：
✓ 使用支援 bc1p 的錢包
✓ 遷移舊地址餘額
✓ 接收時提供現代地址

選擇時機

費率波動規律：

較低時段：
- 週末（尤其週日）
- 美國夜間（UTC 5-10）
- 市場平靜期

較高時段：
- 週中工作日
- 亞洲/歐洲工作時間
- 市場波動時
- 重大事件前後

策略：
- 不急的交易等低谷
- 使用費率追蹤器設定提醒
- 利用 RBF 靈活調整

RBF（費用追加）

什麼是 RBF？

Replace-by-Fee：
用更高費率的新交易替換舊交易

使用場景：
1. 交易卡住 → 提高費率
2. 費率估錯 → 重新調整
3. 市場變化 → 加速確認

前提條件：
- 原交易必須啟用 RBF
- nSequence < 0xfffffffe
- 大多數現代錢包預設啟用

RBF 規則

替換交易必須滿足：

1. 更高總費用
   新費用 > 舊費用 + 額外中繼費

2. 額外費用要求
   增加 ≥ 最低中繼費率 × 新交易大小
   （通常 1 sat/vB × 新 vB）

3. 相同輸入
   必須花費原交易的所有輸入
   不能添加新的未確認輸入

4. 不增加後代
   替換交易的後代不能比原交易多

範例：
原交易：1000 sat，200 vB
新交易：必須 > 1000 + 200 = 1200 sat

RBF 操作

// 概念性程式碼
const originalTx = {
  inputs: [...],
  outputs: [...],
  fee: 1000,  // sat
  size: 200   // vB
};

const replacementTx = {
  inputs: originalTx.inputs,  // 相同輸入
  outputs: [
    { address: recipient, value: 0.099 },  // 減少輸出
    { address: change, value: 0.8998 }     // 調整找零
  ],
  fee: 2000,  // 更高費用
  rbf: true
};

// 新費用 2000 > 1000 + 200 = 1200 ✓

CPFP（子付父款）

什麼是 CPFP？

Child Pays for Parent：
創建高費率子交易「拉動」低費率父交易

原理：
礦工想要打包子交易
必須先打包父交易
所以會一起打包

適用場景：
1. 收到低費率交易
2. 等不及確認
3. 自己控制找零輸出

CPFP 計算

目標：整體達到期望費率

公式：
子交易費用 = (期望費率 × 總大小) - 父交易費用

範例：
父交易：大小 200 vB，費用 400 sat (2 sat/vB)
子交易：大小 141 vB
期望費率：50 sat/vB

計算：
總大小：200 + 141 = 341 vB
需要總費用：50 × 341 = 17,050 sat
子交易費用：17,050 - 400 = 16,650 sat

子交易費率：16,650 / 141 ≈ 118 sat/vB
整體費率：17,050 / 341 ≈ 50 sat/vB ✓

特殊情況

最低費率

記憶池最低中繼費率：

預設：1 sat/vB
- 低於此費率的交易會被拒絕
- 在擁堵時可能動態提高

粉塵限制：
- 輸出價值太小會被拒絕
- P2WPKH 粉塵閾值：~294 sat
- 防止產生不經濟的 UTXO

高費交易事故

歷史上的高費事故：

2023 年 11 月：
- 交易費：83.65 BTC（~$300 萬）
- 原因：軟體錯誤
- 礦池 Antpool 退還

教訓：
- 始終檢查費用
- 使用成熟錢包軟體
- 大額交易前測試

零費率交易

是否可能？

理論上可以，但：
1. 不會被中繼（低於最低費率）
2. 不會被打包（礦工沒激勵）
3. 會永遠卡住

例外情況：
- 礦工打包自己的交易
- 特殊礦池服務
- 私下提交給礦工

開發者資源

費用估算

def estimate_fee(inputs, outputs, fee_rate):
    """估算交易費用"""
    # P2WPKH 交易大小估算
    base_size = 10  # 版本、鎖定時間等
    input_size = len(inputs) * 68  # P2WPKH 輸入
    output_size = len(outputs) * 31  # P2WPKH 輸出

    vsize = base_size + input_size + output_size
    fee = vsize * fee_rate

    return {
        'vsize': vsize,
        'fee_rate': fee_rate,
        'fee_sat': fee,
        'fee_btc': fee / 100_000_000
    }

# 範例
result = estimate_fee(
    inputs=[{'value': 100000}],
    outputs=[{'value': 50000}, {'value': 49000}],
    fee_rate=50
)
print(f"估算費用: {result['fee_sat']} sat ({result['fee_btc']} BTC)")

Bitcoin Core RPC

# 估算費率
bitcoin-cli estimatesmartfee 6  # 6 區塊內確認

# 設置錢包費率
bitcoin-cli settxfee 0.0001  # BTC/kB

# 查看交易費用
bitcoin-cli gettransaction <txid>

# 分析原始交易
bitcoin-cli decoderawtransaction <hex>

# 計算 UTXO 花費成本
# (手動計算輸入大小 × 費率)

常見問題

手續費付給誰？

手續費流向：

1. 礦工收取
   - 打包進區塊的礦工獲得
   - 成為區塊獎勵的一部分

2. 礦池分配
   - 礦池收集所有手續費
   - 按貢獻分配給礦工

3. 沒有「比特幣基金會」
   - 完全去中心化
   - 無中間商

手續費可以退還嗎？

已確認交易：不可能
- 區塊鏈不可逆
- 費用已被礦工收取

未確認交易：
- 使用 RBF 調整
- 等待超時（14天）

高費事故：
- 取決於礦工/礦池意願
- 有些礦池會退還明顯錯誤
- 無強制機制

為什麼費用和金額無關？

設計原理：

區塊空間是稀缺資源：
- 1 BTC 和 1000 BTC 佔用相同空間
- 費用應該反映資源消耗
- 而非交易價值

對比傳統金融：
銀行轉帳：按金額百分比
比特幣：按資料大小

好處：
- 大額交易更便宜（相對）
- 小額交易成本可能較高（相對）
- 公平的資源定價