閃電網絡中的替換循環攻擊

比特幣閃電網絡是比特幣的第二層擴展解決方案，旨在解決比特幣區塊鏈的可擴展性挑戰。它實現了即時且低成本的比特幣交易，使其對用戶來說更加高效和易於使用。與比特幣上的鏈上交易相比，閃電網絡上的交易是私密的，發生在鏈下，只有整體結果會被記錄。

閃電網絡的主要優勢之一是其速度和經濟性。它使用戶能夠以簡單且具成本效益的方式在比特幣網絡上進行小額支付。通過在用戶之間建立支付通道網絡，閃電網絡能夠實現交易而無需將每筆交易廣播到區塊鏈上。這減少了比特幣區塊鏈上的擁堵，並提高了交易的可擴展性。

然而，需要注意的是，閃電網絡仍在開發中，面臨著某些安全風險和中心化風險。今年十月，閃電網絡中新發現了一個名為"替換循環攻擊"的漏洞，涉及交易替換機制，可能導致閃電網絡中通道資金的損失。這種攻擊方法的出現引起了人們對閃電網絡安全性的擔憂，並促使進一步研究和改進其協議和實施。

閃電網絡機制

比特幣閃電網絡利用多重簽名機制來確保支付通道的安全性。參與者需要鎖定資金並建立支付通道。參與者可以在通道內進行快速、低成本的支付，而無需每次都將交易提交到比特幣區塊鏈上。支付通道只是參與者在比特幣區塊鏈之外的一種關係，通過在通道內簽署一系列交易來實現，這些交易僅在通道兩端之間傳播，而不涉及整個比特幣網絡的共識。

在具體過程中，當開設支付通道時，參與者需要創建一個多重簽名腳本，該腳本要求通道上的每一方提供他們的公鑰，同時指定所需的簽名數量，例如，定義一個包含多個公鑰和簽名驗證邏輯的腳本。在生成多重簽名地址時，這個腳本將被轉換為比特幣地址，形成支付通道的基礎設施。

例如，如圖1所示，Bob和Alice首先在區塊鏈上創建一個2-of-2多重簽名比特幣地址作為共同資金。在通道內，他們可以進行無限次的鏈下承諾交易來記錄資金分配的當前狀態。雙方可以協商並簽署新的承諾交易以更新通道狀態，而無需將這些更新廣播到整個比特幣網絡。當他們決定關閉通道時，最終的鏈上結算交易將根據最後協商的分配分配資金。這筆結算交易需要Bob和Alice的聯合簽名，確保資金按最終商定的方式分配。通過這種方式，閃電網絡提高了比特幣交易的效率，降低了成本，同時保留了其去中心化的特性。

圖1：狀態通道示意圖

來源：https://cypherpunks-core.github.io/bitcoinbook/images/mbc2_1204.png

HTLC機制

比特幣閃電網絡還採用了基於哈希時間鎖定合約（HTLCs）的支付通道來實現可路由的多跳支付通道系統。在實施中，HTLCs需要一個複雜的交易腳本，該腳本在腳本語言中定義，以滿足哈希條件和時間鎖定條件。這個腳本將在開啟支付通道時用於初始化，並在支付過程中被觸發。通過這種方式，比特幣閃電網絡實現了跨鏈支付的效率和安全性。

HTLC（雜湊時間鎖定合約）是一種雜湊時間鎖定合約，是在區塊鏈上實現跨鏈交易的重要組成部分之一。HTLC 有兩種常見應用：跨鏈原子交換和閃電網絡中的支付通道。HTLC 可以鎖定轉帳並設置解鎖條件，例如在指定時間內提供特定資訊。這確保了只有在滿足條件時，資金才能被接收方提取。

從技術上講，HTLC 是承諾交易中的一個額外輸出，具有獨特的輸出腳本。這是一個包含 OP_HASH160、OP_EQUALVERIFY 等操作的 Script 腳本，用於鎖定資金，使得只有提供原像值 R 才能解鎖。此腳本有兩條可能的路徑。第一條路徑（在 OP IF 中定義）在 Bob 能夠提供 R 的情況下將資金發送給 Bob。第二條路徑是使用支付交易中的 nLockTime 來強制執行時間鎖定，允許在鎖定期限過後將資金退還給 Alice。

OP_IF

OP_HASH160 <Hash160 (R)> OP_EQUALVERIFY

2 <Alice2> <Bob2> OP_CHECKMULTISIG

OP_ELSE

2 <Alice1> <Bob1> OP_CHECKMULTISIG

OP_ENDIF

路由示例

在閃電網絡中，Alice 想要向 Eric 支付 1 個比特幣，但 Alice 和 Eric 之間沒有直接的支付通道。因此，Alice 通過支付通道網絡中的中間節點（Bob、Carol、Diana）路由支付，構建一條安全的支付路徑，使她能夠間接向 Eric 支付 1 個比特幣。支付路由使用 HTLC——只有在特定時間窗口內提供正確的「秘密」才能解鎖資金，確保支付安全。

在這個例子中，在第 1 步，Eric 生成一個秘密 R（解決方案）並計算雜湊值 H（難題），然後將雜湊值 H 給予 Alice。

步驟2-5：Alice、Bob、Carol、Diana 和 Eric 各自成對構建 HTLC，要求在特定時間內提供 R（解決方案）以從上游方檢索鎖定的資金。

步驟6-9：Eric 向 Diana 提供 R（解決方案）以檢索 1 BTC。Diana 隨後用 R 從 Carol 處檢索 BTC，R 就這樣向後傳遞，直到 Alice 的 1.003 BTC（其中 0.003 BTC 為中間節點的服務費）被檢索。

在這個例子中，如果在步驟 6 中 Eric 未能在固定時間內提供 R（解決方案），時間到期後，步驟 2-5 中鎖定的資金將直接解鎖並返回。

圖 2：路由示例

來源：https://cypherpunks-core.github.io/bitcoinbook/images/mbc2_1210.png

替換循環攻擊

比特幣的交易替換機制指的是當一筆交易被標記為可替換時，在它被確認進入區塊之前，網絡中可以用另一筆手續費更高的交易來替換它。如果一筆交易支付了更高的絕對手續費和更高的費率，它就可以替換掉與之直接衝突的待定未確認交易。節點在收到替換交易後，會將原本費率較低的交易從 mempool 中移除，只保留替換交易。交易替換機制允許在交易被確認之前調整交易費用或其他參數。但這種機制也可能被用來實施交易拒絕服務攻擊，例如反覆替換某個關鍵交易，導致其無法得到確認。因此，交易替換機制為調整交易提供了便利，但也引入了被濫用的風險。

根據比特幣核心開發者 Antoine Riard 的電子郵件，替換循環攻擊主要涉及比特幣閃電網絡中的支付通道。攻擊者廣播一個具有更高絕對費用和費率的 HTLC-preimage 交易，以替換誠實節點的 HTLC-timeout 交易。在替換過程中，攻擊者可以添加額外的輸入或輸出，以確保替換交易被網絡成功接受。這種攻擊方法可能導致支付通道中資金的雙重支付，即在誠實節點廣播 HTLC-timeout 交易後，攻擊者通過替換成功取回資金。我們可以舉一個簡單的例子來說明，類似於之前的例子，假設路徑簡化為只有 Alice、Bob 和 Eric，而 Alice 和 Eric 串通以竊取 Bob 的比特幣。

步驟 1：Alice 打算通過 Bob 向 Eric 支付 1 個比特幣。Alice\Bob 和 Bob\Eric 各自建立一個 HTLC。Eric 需要在區塊 1020 之前（假設當前高度為 1000）向 Bob 提供 R（解決方案），否則 Bob 可以取回鎖定的 1 個比特幣；同樣，Bob 需要在區塊 1080 之前回應 Alice，否則 Alice 可以取回她的 1 個比特幣。

步驟 2：Eric 在區塊 1020 之前沒有向 Bob 提供 R（解決方案）。Bob 將廣播一個包含 HTLC-timeout 的交易。這筆交易中的資金將退還給 Bob。

步驟 3：Eric 監控 Bob 的 HTLC-timeout 交易，並用一個費率更高的 HTLC-preimage 交易替換它。然後 Eric 發起另一筆交易，將先前的 HTLC-preimage 從記憶池中驅逐出去。

步驟 4：Bob 的節點將重新廣播 HTLC-timeout 交易，直到區塊 1080。Eric 每次都可以發起替換。直到區塊 1080，另一個通道方 Alice 的交易得到確認，Alice 取回鎖定的比特幣。

步驟 5：Eric 的 HTLC-preimage 得到確認，因此 Bob 鎖定的 1 個比特幣被轉移給 Eric。

這樣，Bob 的 1 個比特幣被轉移給 Eric，而他也沒有收到應得的來自 Alice 的比特幣。

摘要

截至2023年11月，閃電網絡已有超過16,000個閃電節點和5,000個比特幣。儘管尚未確認實際的替換循環攻擊案例，但這凸顯了對閃電網絡持續進行安全研究和改進的必要性。Antoine Riard還建議了幾項避免或緩解替換循環攻擊的措施，如監控本地mempool和中繼交易、在礦工和閃電節點之間建立覆蓋網絡，以及主動重播HTLC超時交易以增加攻擊者成本。但同時，他宣佈停止參與閃電網絡及其實施工作，包括協調協議級安全漏洞的解決方案。

隨著閃電網絡規模的擴大，替換循環攻擊的潛在威脅可能成為其發展道路上的一個障礙，迫使社群更加關注安全研究和改進。然而，正是通過認真應對和改善安全問題，我們可能會見證閃電網絡在未來逐步解決潛在風險，實現更健康、更可靠的生態系統。

關於CoinEx

CoinEx成立於2017年，是一家致力於簡化交易的全球加密貨幣交易所。該平台為超過200多個國家和地區的500多萬用戶提供一系列服務，包括現貨和保證金交易、期貨、掉期、自動做市（AMM）和金融管理服務。自成立以來，CoinEx始終堅持"用戶至上"的服務理念。懷著培育公平、尊重和安全的加密交易環境的真摯意圖，CoinEx通過提供易於使用的產品和服務，使用戶能夠輕鬆進入加密貨幣世界。

參考資料

https://cypherpunks-core.github.io/bitcoinbook/

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022032.html

https://lightning.network/lightning-network-paper.pdf

https://github.com/ariard/mempool-research/blob/2023-10-replacement-paper/replacement-cycling.pdf