Web3智网 / 知識讀本 · 比特幣 · 2 分鐘閱讀
收到交易識別碼、在記憶池看見交易，以及交易已有多次確認，是三個不同階段。確認數應配合支付金額、交付方式與可承受的重組風險解讀。
運作原理
交易廣播後，節點會先檢查是否符合規則，再可能放入自己的記憶池。記憶池不是全網唯一的公共佇列，各節點看見的內容可以不同。出現在某個網站上，只代表該服務曾接收到交易，並不保證礦工將它放進下一個區塊。
當交易被收錄在目前有效鏈的一個區塊中，通常稱為一次確認；後續區塊在其上延伸，確認數便增加。比特幣依累積工作量選擇有效鏈，短暫分叉可能令最近的區塊退出主鏈。因此確認增加是在提高改寫歷史的成本，不是產生一張絕對不可逆的保證書。
假設案例：把數字放回流程
假設一家商店出售可立即交付的數位序號，買家提供一筆零確認交易。若商店立刻交貨，而之後另一筆花費相同輸出的交易被收錄，原付款就可能無法成為有效收款。若商店改為等待兩次確認，流程較慢，但已排除純粹未收錄的狀態。兩次只是本例的假設政策，並不適用所有金額或攻擊條件。
判讀與實務
等待時間不能只用確認數乘上一個固定分鐘數。出塊帶有隨機性，交易也可能因費率過低而延遲收錄。客服應分開說明「尚待首次收錄」與「已收錄、等待更多確認」，讓收款人知道目前卡在哪一個階段。
對商戶而言，確認政策本質上是交付風險管理。可撤回的低額服務、不能收回的實體商品與大額結算，適合不同的等待門檻。最好事先寫下例外處理方式，包含重組、付款不足、費率過低及逾時付款，避免每次遇到異常才臨時決定。
判讀時還要注意瀏覽器使用哪個區塊高度，以及錢包節點是否已同步。如果兩個服務顯示不同確認數，先比對它們的最新區塊雜湊與同步狀態。數字差一不一定是付款失敗，但長時間分歧值得進一步查證。
若收款服務另有內部風控等待，應把它與鏈上確認要求分開公告，避免讓使用者誤以為網路仍未完成收錄。
操作前檢查清單
- 先確認交易已收錄，勿只檢查交易識別碼是否存在。
- 依交付可逆性及金額訂定等待政策，並公開例外規則。
- 保留交易識別碼、區塊雜湊與觀測時間，方便重組後複核。
常見問題
零確認交易一定不安全嗎？
風險並非相同，但它尚未獲得區塊工作量的保護。是否接受應取決於商戶的風險模型，而非把「看得到」當成「已結算」。
已有確認又變少，資金消失了嗎？
可能是區塊重組或資料來源落後。應先確認交易是否回到記憶池、在新鏈重新收錄，或已被衝突交易取代。