“HTLC 不適用於小額支付”？
我最近讀了 Tadge Dryja 的這條推文。他到底是什麼意思？這是一個問題嗎？如果是這樣，這個問題可以解決嗎？
從用於路由支付的閃電網路 (LN) 散列時間鎖定合約 (HTLC) 輸出中花費大約 200 vbytes。在 10 nBTC/vbyte 的預設最低費用率下，嘗試申請低於約 2,000 nBTC（0.008 美元，4,000 美元/BTC）的路由小額支付是不經濟的。隨著費用的上漲，越來越大的小額支付變得不經濟。
更糟糕的是，預設的比特幣核心記憶體池策略試圖通過拒絕中繼或探勘任何包含以 30 nBTC/vbyte 的費率花費不經濟的輸出的交易來防止 UTXO 設置的膨脹攻擊。這稱為粉塵限制。 為了遵守這一限制，LN 節點不得在 LN 鏈下交易中包含用於非常小額小額支付的 HTLC——否則，如果有必要，這些交易無法在鏈上得到確認，並且通道中的其他價值可能會被交易對手竊取。
目前，當要求 LN 節點將支付路由至低於灰塵限制時，他們 會通過將其通道的潛在交易費用增加小額支付金額而不是添加 HTLC 來削減這些 HTLC。只有當通道在包含此費用的狀態下關閉時，該費用才會實際支付給礦工——通過通道交易對手之間的相互協議，可以在以後的狀態下取消該費用。這會產生三種可能的結果：
- 由於雙方都同意小額支付成功完成，因此費用在稍後的狀態中被取消，因此該金額被轉移到不受灰塵限制的正常大小的輸出中。
- 由於雙方都同意小額支付失敗（要麼被拒絕，要麼超時），費用在以後的狀態中被取消。恢復了早期將資金存放在較大產出中的狀態。
- 兩個對等方就付款產生分歧並關閉通道。在這種情況下，資金實際上被轉移給了礦工，並且失去了在技術上對最終支付狀態正確的任何渠道方。
Peter Rizun 認為，再加上不斷上漲的比特幣交易費用，這可能導致“即使是 50 美元的付款也不是‘不可信’的問題。” 如果 50 美元低於灰塵門檻值 […]，則 HTLC 不能用於保護 50 美元的付款。客戶可能會因為自己的過錯而損失 50 美元的付款。”
看起來他可能是正確的，儘管我們可以對目前的網路行為做出一些規避：
- 目前涉及的金額很小（約 0.02 美元，4,000 美元/比特幣）。
- 想要消除風險的節點運營商可以簡單地拒絕將小額支付路由到灰塵限制以下。
- 那些願意接受有限風險的人可以限制他們的最大風險敞口（例如，在最大風險為 0.20 美元的情況下，最多只能發送 10 次低於 0.02 美元的付款）。
然而，我們真正想要的是從根本上解決這種風險——一種讓小額支付無需信任的方法。令人高興的是，問題中引用的人——Thaddeus Dryja（最初的 LN 建築師之一）——之前 描述 瞭如何實現這一點。
從無法表達的價值觀中消除信任
上面我們描述了低於灰塵限制的小額支付，這是一種中繼和挖礦策略（意味著它可以在不需要全球共識的情況下進行更改）。但是，LN 還允許小額支付低至 10 pBTC，這是共識強制執行的鏈上比特幣 10 nBTC 最大精度的 1/1,000。
當通道包含一些無法在鏈上表示的值時，剩餘的值將在數據庫中進行跟踪，並使用四捨五入進行 LN 承諾。例如，如果 6 nBTC 從 Alice 的通道側支付給 Bob 的通道側，她實際上可能會在鏈下交易中向他發送 10 nBTC，並且在數據庫中跟踪額外的 4 nBTC 以記入後續付款。如果此時通道關閉，Alice 接受她將失去這 4 個 nBTC（0.00002 美元，4,000 美元/BTC）。
鑑於所涉及的金額很小，這似乎是一個非常令人滿意的解決方案——Bob 不太可能僅僅為了從 Alice 那裡偷走 4 nBTC 就支付 4,000 nBTC 的鏈上交易費用。但是，在早期的 LN 展示中，Dryja 提出了一種基於比特幣協議開發人員偶爾討論的替代技術：機率支付。
機率支付是僅在指定時間百分比內成功的支付。例如，Alice 想向 Bob 支付 1 nBTC，但這比比特幣允許的要小。相反，她以十分之一的賠率向他提供 10 nBTC（允許的最小比特幣）的機率支付。十有八九，鮑勃一無所獲；十分之一，他得到 10 nBTC。如果這是通過可證明公平的協議完成的，並且分配金額與賠率對稱（即沒有賭場優勢），那麼有理由相信在 1/10 的時間內收到 10 個 nBTC 相當於每次收到 1 個 nBTC。
Dryja 描述的確切機制很複雜，我不知道它的安全性審查情況如何。所有關於比特幣機率支付的想法都面臨的一個大問題是，它們很難或不可能在比特幣非常有限的腳本語言中實現。基於 ElementsProject.org 的側鏈，例如 Blockstream Liquid，已經重新啟用了一些來自比特幣的禁用數學操作碼，並添加了一個
OP_DETERMINISTICRANDOM操作碼，使機率支付更容易在那裡實現（儘管我不知道在特定協議上的任何具體工作） . 也許有一天，如果社區有需求，這些操作碼或其他類似功能將在比特幣上可用。規避粉塵限制的機率支付
在上一節中，我們看到了用於不信任地繞過 10 nBTC 的最小共識精度的機率支付。我們可以使用相同的機制來不信任地繞過灰塵限制。如果花費價值低於 10,000 nBTC 的 HTLC 輸出是不經濟的，那麼我們只需要對低於該值的任何金額進行機率支付。
例如，Alice 想要通過 Bob 發送 1,000 nBTC 付款。Bob 要求她創建一個 HTLC，以十分之一的成功機會向他支付 10,000 nBTC。然後處理 LN。如果 Alice 和 Bob 都同意它失敗了，他們就會丟棄 HTLC。如果他們都同意它成功了，Alice 只需將 1,000 nBTC 添加到 Bob 的更大輸出中，從而繞過灰塵限制。如果他們不同意並且交易需要在鏈上進行，則進行機率支付，並且十分之九，Bob 沒有收到任何東西（Alice 拿回了她的 10,000 nBTC）。十分之一，Bob 收到 10,000 nBTC。這可以完全無需信任，可證明是公平的，並且不需要任何第三方。
如上所述，機率支付目前是在比特幣上實施的大量工作，有效使用它們可能依賴於現在只是想法的軟分叉。此外，雖然交易費用很低，比特幣的估值仍然使塵埃大小的產出只值幾美分，但實際上沒有必要為人們可能會損失幾美分的問題尋找複雜的解決方案——那些不想承擔風險的人可以簡單地禁用低於約 0.02 美元的路由付款。但如果這成為一個真正的問題，我認為我們可以合理地期望以完全無需信任的方式解決這個問題。
附錄：繞過灰塵限制的一種更簡單、更不聰明的方法
在發布上述描述幾個小時後，我突然想到，有一種更簡單的方法可以創建低於灰塵限制的無信任支付，它不依賴於未經測試的機率支付。如果 Alice 想通過 Bob 發送 1,000 nBTC 付款，但最低經濟的鏈上 HTLC 是 10,000 nBTC，她和 Bob 只需同時創建兩個鏈下輸出：一個 Alice 向 Bob 支付 11,000 nBTC，另一個是 Bob 向 Alice 支付 10,000 nBTC。兩個 HTLC 使用相同的 hashlock 和 timelock，因此它們可以同時成功或超時。如果鏈下支付需要在鏈上結算，淨效果是向 Alice 支付 1,000 nBTC，加上他們定期就結果達成一致並合作更新他們的主要餘額的能力。
缺點包括這需要 Alice 和 Bob 在他們的渠道中保持更多的平衡，而不是為了處理小額支付，並且總體上會花費他們更多的費用。這種額外的負擔可以通過他們對低於經濟鏈上費率的路由支付收取更高的費用來補償。這種方法還以完全無需信任的方式解決了這個問題，它不需要大量研究來實施，儘管它可能仍然是一個過早的優化，而目前的風險是以便士來衡量的。
（機率支付仍然是我所知道的處理低於 10 nBTC 的最小鏈上精度的支付的唯一方法，但這不是這裡的問題。）