打開任何一個比特幣區塊瀏覽器，你會同時看到三個核心數字：交易大小（Size）、虛擬大小（Virtual Size，vsize）以及費率（sat/vB）。許多初學者常直接將「交易大小」乘上費率來估算成本，結果發現錢包扣除的金額遠低於計算值。要掌握真實成本，核心在於理解比特幣底層的虛擬位元組vBytes換算與交易重量架構。
區塊容量改用重量計算之後，字節數不再等於成本
2017 年 8 月隔離見證（SegWit，BIP141）在主網正式啟用，比特幣網絡的計量標準迎來重大升級。早期規則十分直觀：單個區塊上限為 1 MB，交易序列化後的原始字節數即等於佔用的區塊空間，費率單位以 sat/B（每位元組多少聰）計量。隔離見證將簽名與見證資料（Witness）自交易基礎資料中剝離，改由重量單位（Weight Units，WU）作為全網共識標準。
這項改動使交易具備兩種不同維度的尺寸：一個是在節點網絡間傳輸時實際消耗頻寬的原始大小（Raw Size），另一個則是經由折扣規則折算後的區塊配額。礦工打包交易收取手續費時，僅依據後者計費。在各類錢包中設定的「12 sat/vB」，分母即為虛擬位元組（vBytes，簡寫為 vB），與未折算的原始大小並不相等。
透徹掌握此項機制，有助於精確控制轉賬支出、預估確認時間，並在鏈上壅塞需要加速排隊時，精準算出最經濟的補貼金額。
交易重量與虛擬大小的換算公式
比特幣主網限制每個區塊的重量上限為 4,000,000 WU，折算為虛擬空間即為常見的 1,000,000 vB 額度。交易總重量由基礎部分與見證部分相加得出：
weight = 基礎大小 × 4 + 見證大小 × 1
vsize = ceil(weight ÷ 4)
基礎大小（Base Size / Stripped Size）指剔除見證資料後的核心交易體積；marker 與 flag 兩個位元組計入見證側，共佔 2 WU。
見證資料在計算中享受四分之一的重量折扣。交易中的簽名比例越高，折算後的 vB 相對原始體積就越精簡。需特別注意的是，公式中的 ceil() 為無條件進位函數。若一筆交易的重量為 562 WU，562 ÷ 4 = 140.5，最終的 vsize 必須進位判定為 141 vB。如果省略進位直接按浮點數計算，在大批量交易中會產生累積誤差。
四種容量指標定義
| 計量名稱 | 涵蓋範疇 | 實際用途 |
|---|---|---|
| 原始大小（Raw Size） | 完整字節串列，包含見證簽名 | P2P 節點傳播與頻寬計算 |
| 基礎大小（Base Size） | 去除見證簽名後的結構資料 | 重量權重的主要乘數（× 4） |
| 重量（Weight，WU） | Base × 4 + Witness × 1 | 比特幣區塊上限的法定標準（4M WU） |
| 虛擬位元組（vBytes / vsize） | ceil(Weight ÷ 4) | 手續費率計價的核心分母 |
常見地址類型的輸入與輸出成本
交易的最終 vsize 是由「基礎固定開銷 + 各輸入花費成本 + 各輸出構造成本」加總後計算得出。選用的腳本類型會顯著影響體積分佈：
| 地址格式名稱 | 地址特徵 | 單個輸入體積 | 單個輸出體積 |
|---|---|---|---|
| 傳統地址（P2PKH） | 以 1 開頭 | 約 148 vB | 約 34 vB |
| 嵌套隔離見證（P2SH-P2WPKH） | 以 3 開頭 | 約 91 vB | 約 32 vB |
| 原生隔離見證（P2WPKH） | 以 bc1q 開頭 | 約 68 vB | 約 31 vB |
| Taproot 密鑰路徑（P2TR） | 以 bc1p 開頭 | 約 57.5 vB | 約 43 vB |
很多人認為 Taproot（P2TR）在任何維度都是最省的，其實不然。P2TR 的輸出體積為 43 vB，高於 P2WPKH 的 31 vB；但在花費該資金時，P2TR 的密鑰路徑輸入僅需約 57.5 vB，大幅低於舊格式。此外，Schnorr 簽名在預設使用 SIGHASH_DEFAULT 時固定為 64 位元組，若帶有顯式 sighash 旗標則為 65 位元組，波動幅度遠小於 DER 編碼的 ECDSA 簽名（71 至 72 位元組）。整筆交易是否划算，需結合收付雙方的輸入與輸出數量綜合評估。
交易固定結構開銷
- 版本號（Version）：4 位元組
- 輸入計數器（Input Counter）：1 至 3 位元組（通常為 1 位元組，超過 252 個輸入時擴增）
- 輸出計數器（Output Counter）：1 至 3 位元組
- 鎖定時間（Locktime）：4 位元組
- 隔離見證旗標（Marker & Flag）：見證交易專用，貢獻 2 WU（折算名義值約 0.5 vB）
傳統交易的基本固定開銷為 10 位元組（40 WU）。隔離見證交易在折算後基礎開銷約 10.5 vB，這是一個在參與進位前的折算名義值，必須與所有輸入輸出的總重量相加後統一向上取整。
實戰換算：兩組真實交易推導演練
案例一：標準 1 輸入、2 輸出（P2WPKH）
情境設定為使用一個原生隔離見證 UTXO 付款，產生一個收款地址與一個找零地址：
- 基礎資料結構：版本號 4 位元組 + 輸入計數 1 位元組 + 輸入主體 41 位元組（TXID 32 + VOUT 4 + 空 scriptSig 1 + Sequence 4）+ 輸出計數 1 位元組 + 兩組 P2WPKH 輸出 62 位元組（各 31 位元組）+ Locktime 4 位元組 = 113 位元組。基礎重量為 113 × 4 = 452 WU。
- 見證資料結構：Marker & Flag 佔 2 WU；見證棧內容包含項目數、簽名長度、DER 簽名、公鑰長度及壓縮公鑰，合計 108 WU。見證總重量為 2 + 108 = 110 WU。
- 總重量與 vsize：總重量 = 452 + 110 = 562 WU。虛擬大小 = ceil(562 ÷ 4) = 140.5，進位取整為 141 vB。
若設定費率為 12 sat/vB，總手續費為 141 × 12 = 1,692 聰（Sats）。此交易序列化後的原始體積（Raw Size）為 113 + 110 = 223 位元組。若誤將原始體積直接乘上 12，會得出 2,676 聰，估算值偏高達 58%。
案例二：3 輸入、2 輸出的格式成本對比
若因資金零碎，需要花費 3 個 UTXO 來完成一筆 2 輸出的轉賬：
方案 A（全 P2WPKH）：基礎大小為 4 + 1 + (41 × 3) + 1 + (31 × 2) + 4 = 195 位元組（780 WU）；見證大小為 2 + (108 × 3) = 326 WU。總重量為 1,106 WU。vsize = ceil(1106 ÷ 4) = 276.5，進位為 277 vB。在 12 sat/vB 下手續費為 3,324 聰。
方案 B（全傳統 P2PKH）：基礎大小為 4 + 1 + (148 × 3) + 1 + (34 × 2) + 4 = 522 位元組。由於無見證資料，重量為 522 × 4 = 2,088 WU。vsize 即為其原始大小 522 vB。相同費率下成本跳升至 6,264 聰，成本增加近 88%。
常見費率單位換算指南
開發者介面與區塊瀏覽器呈現費率的口徑各不相同。Bitcoin Core RPC 介面常用 BTC/kvB，瀏覽器通常顯示 sat/vB，混淆單位極易導致手續費高付或轉賬停滯。
| 計費單位 | 完整含義 | 換算關係 |
|---|---|---|
| sat/vB | 每虛擬位元組多少聰 | 基準計價單位 |
| sat/kvB | 每千虛擬位元組多少聰 | = sat/vB × 1,000 |
| BTC/kvB | 每千虛擬位元組多少比特幣 | = (sat/vB × 1,000) ÷ 100,000,000 |
若節點返回 0.00015 BTC/kvB，換算過程為：0.00015 × 100,000,000 ÷ 1,000 = 15 sat/vB。手動計算時，務必將各部分重量完整匯總後再行除以 4 取整，切勿逐項取整累加，以避免產生人為進位誤差。
粉塵閾值與找零處置邏輯
構建交易時，若收款後剩餘的金額極小，是否應生成找零輸出需要謹慎權衡。新增一個輸出會增加約 31 vB（P2WPKH）至 43 vB（P2TR）的體積，而該輸出本身的金額若低於節點的「粉塵門檻（Dust Limit）」，整個交易將被節點拒絕廣播。
在預設的 3 sat/vB 粉塵中繼費率下，各類型輸出的標準防粉塵下限為：
- P2PKH 輸出：546 聰
- P2WPKH 輸出：294 聰
- P2TR 輸出：330 聰
建立找零輸出的邊際成本由「輸出 vB × 當前費率 + 粉塵下限」共同決定。在 50 sat/vB 的高費率環境下，建立一個 P2WPKH 找零的最低損益平衡點為 31 × 50 + 294 = 1,844 聰。若找零金額低於該數值，將該找零直接讓利充當手續費，反而能省去日後高額花費該 UTXO 的開銷。
交易受阻時的 vBytes 重新推算
鏈上費率飆升導致交易滯留在內存池（Mempool）時，主要透過費用替換（RBF）或以子貴父（CPFP）進行加速處理，兩者均深度依賴精確的虛擬大小重算。
費用替換（RBF）
自 Bitcoin Core 28.0 起，內存池預設啟用完全費用替換（Full RBF），不再嚴格依賴原交易是否包含 BIP125 信號。替換原則要求新交易支付更高的總費額，且增加的費用必須滿足最低增量中繼費率的要求。若原交易為 141 vB、支付了 1,692 聰（12 sat/vB），若欲提升至 30 sat/vB，只需廣播相同結構的新交易並支付 141 × 30 = 4,230 聰即可。
以子貴父（CPFP）
當無法發起 RBF 時，可花費未確認父交易的輸出建立子交易。礦工會將兩筆交易視為一個整體套件（Package）來評估平均費率：
有效組合費率 =（父交易手續費 + 子交易手續費）÷（父交易 vsize + 子交易 vsize）
若父交易為 141 vB、已付 1,692 聰，新建的 1 輸入 1 輸出 P2WPKH 子交易體積為 110 vB，二者合併 vsize 為 251 vB。若目標套件費率為 30 sat/vB，總費用需達 251 × 30 = 7,530 聰。扣除父交易已付部分，子交易必須單獨負擔 5,838 聰，其自身名義費率高達 5,838 ÷ 110 ≈ 53.1 sat/vB。
手算速查基準常數表
進行日常快速估算時，可運用下列經驗常數先行累加，最後統一向上取整：
| 元件類別 | P2PKH (1) | P2SH-P2WPKH (3) | P2WPKH (bc1q) | P2TR (bc1p Key-path) |
|---|---|---|---|---|
| 單個輸入（Input） | ~148 vB | ~91 vB | ~68 vB | ~57.5 vB |
| 單個輸出（Output） | ~34 vB | ~32 vB | ~31 vB | ~43 vB |
| 固定開銷基準 | 見證交易折算名義開銷約 10.5 vB（非見證交易約 10 vB） | |||
例如：2 個 P2WPKH 輸入、1 個 P2TR 輸出、1 個 P2WPKH 找零輸出，總體積估算為：10.5 + (68 × 2) + 43 + 31 = 220.5 vB，向上取整為 221 vB。若輸入超過 252 個或使用複雜腳本花費（Script-path），因計數器擴增及腳本證明體積上升，則應回歸原始重量公式逐項求和。
常見問題解答（FAQ）
Q1：為什麼同一筆交易在區塊瀏覽器中看到的 Size 和 Virtual Size 不一樣？
Size 代表序列化後的原始位元組數（Raw Size），直接反映傳輸頻寬需求；Virtual Size（vsize）則是引入隔離見證折扣後的名義計費大小。因見證數據享有 75% 的重量折扣，所有包含見證資料的現代交易，其 vsize 均會明顯小於原始 Size。
Q2：將地址全面升級為 Taproot（bc1p）是否一定能節省更多手續費？
不一定。Taproot 的主要優勢在於輸入端（約 57.5 vB），但其輸出體積（約 43 vB）高於原生隔離見證 P2WPKH（約 31 vB）。若轉賬場景為 1 輸入多輸出，使用 P2WPKH 反而更具成本優勢；只有在輸入數量較多或使用複雜多簽腳本時，Taproot 才能發揮最大的費率節省效益。
Q3：手動計算 vsize 時，為什麼必須在最後一步才進行向上取整？
比特幣共識規則是以全交易的總重量（WU）為單位進行校驗，公式為 ceil(weight ÷ 4)。若在計算各個輸入與輸出的過程中提早進位，會人為虛增 1 到 2 vB；在高頻或批量轉賬業務中，此類累積誤差會直接轉化為不必要的成本支出。
Q4：為什麼設定了足額費率，交易依然可能在內存池中長時間擱置？
內存池的競爭是即時變動的。若廣播後全網突發大批高費率交易，礦工會優先打包費率更高的交易。此外，若錢包在估算時少算了實際簽名輸入數量，會導致最終廣播的交易體積超出預期，進而稀釋了實際生效的 sat/vB 費率。
