目錄

• 你可能想知道的事
• 主要議題
• 關鍵見解表
• 後續...

你可能想知道的事

1. 比特幣交易如何意外地把整筆輸入金額轉成礦工手續費？

2. 有哪些保護措施（如果有）可以回收錯誤當作手續費支付給礦池的資金？

主要議題

在 8 月 12 日（區塊高度 962,142），單一比特幣區塊確認了 4,700 筆交易。其中有四筆來自同一地址的交易，實際上把它們整筆輸入金額都轉成了礦工手續費，合計為 177,153,578 satoshis (1.7715 BTC)。以確認時的 BTC 價格（約每 BTC $64,180）計算，這約等於 $113,700 作為手續費消失。僅這四筆交易就占了該區塊總手續費收入（1.8189 BTC）的 97.4%，剩下的 4,695 筆交易僅分到大約 2.6% 的手續費。

該區塊由 SpiderPool 挖出，該池為該區塊共獲得 4.9439 BTC 的獎勵，包含區塊補貼與交易手續費。因此這四筆異常交易為該礦池在此單一區塊帶來了不成比例的收益。

檢視這四筆交易的結構可以看出資金為何被燒掉。每筆交易都只有一個輸入和一個輸出。唯一的輸出是一個零值的 OP_RETURN 輸出。在比特幣中，手續費並非在單獨欄位指定；手續費就是輸入總和與輸出總和之間的差額。當唯一的輸出為零值 OP_RETURN（且沒有將剩餘資金作為找零輸出回到發送者）時，整筆輸入就成為手續費。因為錢包軟體通常不會把這種情況視為明確錯誤，構造此類交易的腳本或自動化流程可能不會觸發明顯警告，該錯誤交易就會像正常交易一樣被廣播並被打包確認。

鏈上分析顯示，這四筆交易在 UTXO 序列上相互依賴，且被燒掉的金額依序增加。被花費的 UTXO 序列顯示以下燒掉數額（sat，括號內為確認時的約略美元）：174,592 sat（約 $112）、1,799,921 sat（約 $1,155）、14,835,180 sat（約 $9,520），然後是大額的 160,343,885 sat（約 $102,900）。在這些燒掉之前，早先有一筆合併交易把 12 個小 UTXO 合併成單一 1.6034 BTC 的 UTXO，並支付了正常偏低的手續費（858 sat，約 $0.55）。那一步的合併本身是普通的，但隨後自動化的步驟花費該合併後的 UTXO 時產生了零值的 OP_RETURN 輸出，導致大部分餘額被轉為手續費。

產業報導與鏈上跡象指向一個濫用 RBF（以費率替換，Replace-By-Fee）行為的自動化錢包腳本作為直接原因。四筆有問題的交易其 nSequence 設為 0xfffffffd，根據常見的 Bitcoin Core 預設這表示它們可被 RBF 取代。然而，僅僅標記為 RBF 並非根本原因。核心問題在於交易輸出結構：當沒有找零輸出，且唯一非塵埃輸出為零值 OP_RETURN 時，手續費即等同於整筆輸入。組裝交易的錢包與腳本必須確保在適當情況下存在找零輸出，否則就有可能把整筆輸入送給礦工作為手續費。

這類錯誤並非首次發生。2025 年 4 月曾有事件報導顯示因第二次 RBF 嘗試消耗大型 UTXO 並未送回找零而損失 0.75 BTC。2024 年 6 月一個集中式錢包的自動化合併錯誤據報毀損了 254.28 BTC 作為手續費。這些事件顯示當自動化、合併腳本與 RBF 語意在沒有健全防護的情況下結合時，會形成反覆出現的操作風險。

從礦工或礦池角度來看，該事件是財務上的利好。SpiderPool 在區塊 962,142 得到的區塊獎勵加手續費總值相當於約 $317,000，其中超過三分之一來自有效上繳給礦工的交易。礦工沒有義務退回錯誤支付的手續費；退款完全是自願且歷來罕見。雖然曾有少數例子顯示礦池公開請受害者自我識別並進行退款，但此類行為屬於良意而非強制補救。

為何錢包軟體不防止這種情況？比特幣的費率模型意味著手續費是隱含的。錢包通常會計算所需的輸入與輸出，包含一個回發給發送者的找零輸出，並設定適當的手續費。然而，當腳本以程式化方式構建交易——尤其是使用 OP_RETURN 輸出來放置元資料或標記時——很容易因為疏失而遺漏找零輸出或構造出零值輸出。自動化腳本可能不會顯示出"結果手續費等於整筆輸入"的警告，因此交易就會像任何其他交易一樣被送出並被確認。

緩解措施包括在錢包軟體與腳本中增加更嚴格的驗證以偵測帶有大額輸入的零值交易、明確檢查找零輸出是否存在，以及當構造出的交易會把整個 UTXO 當作手續費時提示使用者。開發者的最佳實踐包括對合併腳本進行單元與整合測試、分階段的乾跑（dry run），以及加入每筆交易的合理性檢查以比較預期手續費與合理門檻。對於託管或大規模錢包系統的營運者，對大額合併操作實施多步驟確認與人工審查可避免災難性損失。

簡言之，8 月 12 日事件提醒我們鏈上自動化的操作風險。合併或費率替換腳本中的一個小錯誤或遺漏，就可能把數萬或數十萬美元變成礦工手續費且無法在鏈上追回。責任落在錢包開發者、服務營運者與腳本作者身上，他們應建立防護措施以防止高嚴重性錯誤進入生產環境。

關鍵見解表

後續...

此事件強化了對自動化與合併腳本周圍進行全面防護的必要性。組織與開發者應實施明確檢查以偵測異常大的隱含手續費，對任何會燒掉大量輸入的交易要求確認，並避免在非刻意情況下構造唯一非塵埃輸出為 OP_RETURN 的交易。在政策與工具面向，錢包函式庫與使用者介面客戶端可以做更多以警告使用者並預設封鎖可疑交易。

最後，雖然礦工有時會以善意退還錯誤支付的資金，但沒有鏈上機制可以強制退款。實務上的教訓是：操作紀律、錢包軟體更強的預設值，以及對自動化進行仔細測試，是避免把資金意外變成手續費的可靠防線。