HTLC 成功/超時事務中輸出的見證腳本是：

OP_IF
   # Penalty transaction
   <revocationpubkey>
OP_ELSE
   `to_self_delay`
   OP_CHECKSEQUENCEVERIFY
   OP_DROP
   <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

其中已經存在懲罰交易。在提供的 HTLC 和在承諾交易中收到的 HTLC 輸出中，我們有，

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
...

為什麼我們不只將撤銷放在 HTLC-Timeout/Success 輸出中？

HTLC 的超時 ( cltv_expiry) 與我們用於懲罰事務的正常超時 ( to_self_delay) 不同。這就是為什麼我們使用單獨的交易階段（HTLC 成功/HTLC 超時）來讓我們的交易對手有足夠的時間行使他們的權利來獲得通道的全部餘額，以防我們廣播通道的先前狀態。

進一步說明，當您的交易對手告訴您添加 HTLC 時，您的承諾交易版本將有 3 個輸出：

1. 立即向您的交易對手付款
2. 支付給自己，由撤銷密鑰守衛to_self_delay時間
3. 收到如下所示的 HTLC 輸出

# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
   OP_CHECKSIG
OP_ELSE
   <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
   OP_IF
       # To local node via HTLC-success transaction.
       OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
       2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
   OP_ELSE
       # To remote node after timeout.
       OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
       OP_CHECKSIG
   OP_ENDIF
OP_ENDIF

當您向您的交易對手提供 HTLC 前映像時，交易就會得到解決。然而，即使在與您的交易對手成功解決 HTLC 之後，假設您決定通過強制關閉包含 HTLC 的承諾交易的早期狀態來欺騙他們。一旦您發布此承諾交易，您就會發布OP_IF消耗OP_ELSE. 由於 HTLC 成功交易正在消耗未鎖定的輸出，因此您沒有為您的交易對手提供足夠的時間來使用其在收到的 HTLC 輸出中的撤銷密鑰的權利。這就是第二階段的原因，您從提供的 HTLC 輸出到您自己的支出被鎖定，直到to_self_delay這允許您的交易對手使用撤銷密碼。

現在您可能想知道，如果在 HTLC 成功/超時事務中提供了送出事務接收到的 HTLC 輸出，為什麼會存在撤銷。讓我們以上面的案例來解釋一下。您添加了 HTLC 並簽署了承諾交易。該 HTLC 是通過您向您的交易對手提供原像來結算的，並且包含該 HTLC 的承諾交易已被撤銷。儘管如此，假設您嘗試廣播包含 HTLC 的先前承諾交易並避免發布 HTLC 成功交易。如果承諾交易中不存在撤銷，則交易對手可能無法取回資金，直到cltv_expiry如果有許多躍點，這可能會擴展到數百個塊（幾天）。這很麻煩，因為 HTLC 已經結算（尤其是如果有多個先前滿足的 HTLC），並且在承諾交易中提供撤銷允許交易對手立即結算它們。

撤銷部分的設計使您的交易對手永遠不會因為您決定採取欺騙他們的行動而遭受損失。承諾交易中存在的撤銷和 HTLC 成功/HTLC 超時交易有助於保護閃電網路參與者免受其同行的欺詐行為。

TL; 博士

因為它會在 CSV 延遲或降低 HTLC 的安全性上創建 CLTV 增量的令人討厭的依賴性。

在第二階段交易中擁有撤銷路徑可以使 HTLC 超時（即，您的對等方不能再通過原像贖回它），同時仍然保持撤銷期 (CSV) 完整，以便您在作弊時受到懲罰。

兩級 HTLC

閃電網路協議使用兩階段 HTLC。

為什麼：允許使用比用於基本安全模型（懲罰）的相對時間鎖增量更短的絕對時間鎖增量，而不會降低 HTLC 輸出的安全模型。

如何：（基本上）使 HTLC 輸出支付給撤銷路徑、僅在 block 之後可廣播的 [timeout/success] 事務B或具有原像的接收器。僅在撤銷期完全到期後才使 [超時/成功] 交易支付（這裡不再有原像路徑，如果接收者沒有作弊，他們將獲得報酬）。

有關此答案中的兩個階段 HTLC 的更多資訊。

為什麼要把撤銷路徑放在兩個階段？

因為第一階段在絕對時間鎖定期結束時到期，很可能小於撤銷期。

如果第二個事務中不存在撤銷路徑（這實際上是使用兩個階段的目的），那麼您要麼大幅減少 HTLC 輸出的撤銷期，要麼需要使用非常高的 CLTV 增量。

一個例子

我和你有一個頻道，我們同意一個to_self_delay144 個區塊（1 天懲罰撤銷狀態的廣播）和一個（魯莽）cltv_expiry_delta6 個區塊。

我只是試圖通過我們的渠道付款。我們將提供的 HTLC 輸出附加到我的承諾交易中，並將收到的 HTLC 輸出附加到您的承諾交易中。

比方說，有人覺得有趣的是不接受其微不足道的費用，而是堅持 HTLC 來惹我們。在 4 個區塊之後，我們使 HTLC 失敗，簽署了一對新的承諾交易並繼續操作——我後來才知道，你實際上是在收集原像後卡住了 HTLC。

我們不會為我們的頻道創建新狀態，當晚我遇到停電，我的節點離線，直到我醒來（5 小時後）我才注意到它。

在我下線的那一刻，你做出了一個絕對不合理的決定來廣播你的古老承諾交易，你仍然有一個簽名的接收到的 HTLC 輸出。

您的交易得到確認，並通過了 6 個區塊（距離我醒來還有 4 小時），您可以使用您的 HTLC 成功交易索取輸出。

4 小時後，我醒來，將我連續備份的節點重新上線並註意到漏洞。

在我還沒來得及感到幻滅、失望和沮喪到對一個隨機的網際網路彩色別名發誓之前，我的節點從你的承諾交易的輸出中偷走了你的硬幣to_self，索取了我的to_remote輸出並花費了你的 HTLC 成功交易。

如果沒有第二階段的撤銷路徑，我的硬幣就會失去。

引用自：https://bitcoin.stackexchange.com/questions/91344