發生什麼：一次安全修補，讓誠實的資產付款也可能結不了帳
Lightning Labs 在 2026 年 10 月 22 日 19:18（UTC）發布 Taproot Assets（tapd）v0.8.8，發布說明只有一句重點：修補 v0.8.6 引入、可能讓資產發票（asset invoice）無法結算的回歸問題。Taproot Assets 是在比特幣上發行資產、並讓這些資產經閃電網路通道支付的協議，目前社群實際拿來跑的主要是美元穩定幣類資產。
對照提交紀錄，v0.8.8 相較 v0.8.7 只改了發票處理模組 tapchannel/aux_invoice_manager.go 與其測試，以及版本號。關鍵提交 15df287 的說明是：v0.8.6 為了「精確入帳」，把原本的捨入容差一併移除；結果在付款方與收款方各自向下取整後，付款金額可能比發票少一點點，這些付款會停在「部分付款」狀態，直到多路徑付款（MPP）逾時被取消。
受影響範圍是 v0.8.6 與 v0.8.7。v0.8.6 於 10/16 發布，是一次安全版本；v0.8.7 於 10/22 02:55（UTC）發布，只是以 Go 1.27.3 重新編譯以處理 CVE-2026-111943，發票邏輯沒有變。tapd 的發布說明沒有提到實際卡單的事故數量，本文也沒有找到公開的受害回報。
原始證據：雙重取整與被移除的容差
資產發票的金額以聰（精確到毫聰，msat）表示，但通道裡實際移動的是資產單位。付款方先用報價把 msat 換成資產單位並向下取整，收款方的 tapd 再把收到的資產單位換回 msat，又向下取整一次。v0.8.8 原始碼註解把這稱為「double floor problem」：即使付款方完全誠實，最後算出的入帳金額也可能比發票少。
這不是新問題。2025 年 7 月合併的 PR #1639 已經處理過：原本發票接受邏輯就允許每個 HTLC 分片差 1 個資產單位，PR #1639 又補上每分片 1 msat，因為換算容差本身也會差 1 msat。
10/16 的 v0.8.6 安全刷新（提交 734ce74）則把方向反過來。發布說明寫明：資產發票 HTLC 只按該 HTLC 內的資產價值入帳，已取消的分片不再計入，而且「捨入容差不能用來填補資產短缺」；同時以發票路由提示中的報價為入帳匯率上限。這些修補擋住的是重播已取消分片灌大入帳、或用更有利報價多入帳之類的問題，但副作用是把誠實付款的捨入誤差也一起擋掉。
v0.8.8 的做法是恢復舊容差：已接受的分片加上當前 HTLC，若比發票少不超過「每分片 1 個資產單位加 1 msat」，就把當前 HTLC 補足差額。其餘修補保留：只計算處於 accepted 狀態的 HTLC、以短缺額而非餘額計算補足以避免數值回繞，金額為零的發票不套用調整。程式註解也坦白寫出取捨：這個容差同時就是付款方能「故意少付」的最大值，當初正因此被移除，恢復它是有意識的權衡。
對讀者的影響：用 litd 的節點目前仍停在受影響版本
許多人不是單獨跑 tapd，而是用把 lnd、tapd 等打包在一起的 Lightning Terminal（litd）。litd v0.17.7 於 10/17 發布，說明寫明內附 Taproot Assets v0.8.6，並要求跑資產通道的用戶「必須」更新；10/22 01:38（UTC）的 litd v0.17.8 組件表仍列 Taproot Assets v0.8.6「unchanged」。也就是說，截至台北時間 10/24 上午，litd 最新正式版仍不含 v0.8.8 的修補。
這和實際使用情境直接相關。10/7 一名開發者在 Stacker News 自述，他以 litd 整合模式、自設價格預言機，透過 Amboss 開的資產通道，支付 2.14 USDTL 買了一罐可樂；邊緣節點在最後一跳把聰換成資產。這類「一般閃電錢包付聰、收款端收穩定幣」的流程，正好每次都經過兩次換算。
升級時要注意 v0.8.6 的操作指南仍然適用：從 v0.8.6 之前版本升級者，需先讓預言機拒絕新報價、在 lnd 設 rejecthtlc 停止接收新 HTLC，等待結 HTLC 處理完再換執行檔。預設 RFQ 報價有效期 10 分鐘，資產發票預設 5 分鐘到期。
AI 觀點分析與推論
AI 觀點：資產閃電付款的難處，在換匯而不是路由
我傾向認為，這次回歸比 CVE 重編更值得資產通道營運者注意。安全修補把「多入帳」的路堵死，卻讓「少一點點就不收」成為新的失敗模式；對收款方來說，付款卡在部分付款再逾時取消，表現上就像網路不穩，很難第一時間聯想到捨入規則。
受益的是一般付款人和商家：v0.8.8 讓小額、多分片付款恢復可結算。承擔風險的是收款方：每分片最多可被少付 1 個資產單位加 1 msat。若資產單位切得很細，這只是極小金額；但若某資產的單位粒度很粗，或付款被拆成大量分片，容差的經濟意義就會放大，這是我認為營運者應依自己收的資產自行檢查的地方。
反面情境是，有人發現能透過大量拆分分片把這個容差累積成有意義的少付。若後續出現這類揭露，或 Lightning Labs 改採「發票預留緩衝、付款方多付」之類設計，我會調整判斷。下一個可觀察訊號是 litd 何時收入 tapd v0.8.8，以及 main 分支後續版本是否以同樣方式處理容差。
