不論是隔離見證區塊激活，或者最新提出的延展區塊擴容方案被激活，都將使閃電網絡變的完整。而閃電網絡的普及將意味着人類進入全新的社會結構，對人類命運的改變將是前無古人的，這次人類命運的改變將要比第一次工業革命對人新的影響還要大。可以一點也不誇張的說，比特幣的閃電網絡發明就像瓦特發明的蒸汽機一樣，會引領人類進入新的全自動化社會生產，爲進一步的高智力人工智能自動化工業生態奠定基礎。
比特幣閃電網絡即將正式發佈，閃電網絡將帶來極致的交易處理能力和近乎瞬時的交易確認，遠超目前的VISA系統。以太坊上的類似項目雷電網絡也預計將在幾個月後發佈。本文剖析了它們背後的原理和技術細節，並據此對R3 Corda 的原理作出一番揣測。
朱立
上交所技術有限責任公司
1. 閃電網絡（LIGHTNING NETWORK）
1.1 閃電網絡概述
比特幣自誕生起一直存在若干技術問題：論處理能力，目前全網只有7筆每秒；論時延，是大致10分鐘出一個塊；論交易最終性，一般建議將等待6個塊的確認視作交易最終化，大額交易則建議等待更多；論容量，目前已生成40多萬個區塊，約60GB數據量，且眼見的未來中只見增加不見減少。
在閃電網絡出現前，雖然比特幣社區也試圖通過區塊擴容、隔離見證等技術在一定程度上增加交易處理能力，但這些方式並不能導致交易處理能力出現數量級的改善。至於前面提及的其他技術難題，現存的PoW機制是萬萬動不得的，需要等待多個區塊的確認也是不能觸碰的底線，更麻煩的是：交易處理能力和區塊鏈數據容量似乎是一對無可調和的矛盾。
思路決定出路，常規方法找不到出路，就逼得社區換一個思路考慮這個問題。代碼性能調優的經驗提示我們：優化編譯、改進算法、調整數據結構等方式雖然很重要也很管用，但怎麼能比得上“根本不執行”的強悍？既然在比特幣區塊鏈中優化性能如此艱難，爲何不儘可能將交易放到鏈外執行？
倚天一出，誰與爭鋒。以比特幣區塊鏈爲後盾，在鏈下實現真正的點對點微支付交易，區塊鏈處理能力的瓶頸被徹底打破，時延、最終性、容量甚至隱私問題也迎刃而解，這就是比特幣“閃電網絡”（Lightning Network）的思路。因爲這個原因，社區甚至認爲：“閃電網絡”的論文（The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments）對比特幣的重要性僅在中本聰的創世論文之下，排名第二。
閃電網絡提供了一個可擴展的微支付通道網絡。交易雙方若在區塊鏈上預先設有支付通道，就可以多次、高頻、雙向地通過軋差方式實現瞬間確認的微支付；雙方若無直接的點對點支付通道，只要網絡中存在一條連通雙方的、由多個支付通道構成的支付路徑，閃電網絡也可以利用這條支付路徑實現資金在雙方之間的可靠轉移。
閃電網絡並不試圖解決單次支付的銀貨對付問題，其假設是單次支付的金額足夠小，即使一方違約另一方的損失也非常小，風險可以承受。因此使用時必須注意“微支付”這個前提。多少資金算“微”，顯然應該根據業務而定。
1.2 閃電網絡技術本質
閃電網絡的關鍵技術有三，後後依賴於前前，依次是：RSMC，HTLC和閃電網絡。技術實現雖然複雜，但本質卻很簡單。
1.2.1 RSMC
閃電網絡的基礎是交易雙方之間的雙向微支付通道，RSMC（Recoverable Sequence Maturity Contract）定義了該雙向微支付通道的最基本工作方式。
微支付通道中沉澱了一部分資金，通道也記錄有雙方對資金的分配方案。通道剛設立時，初值可能是{Alice: 0.4, Bob: 0.6}，意味着打入通道的資金共有1.0 BTC，其中Alice擁有0.4 BTC，Bob擁有0.6 BTC。通道的設立會記錄在比特幣區塊鏈上。
假設稍後Bob決定向Alice支付0.1 BTC。雙方在鏈下對最新餘額分配方案{Alice:0.5, Bob:0.5} 簽字認可，並簽字同意作廢前一版本的餘額分配方案{Alice:0.4, Bob:0.6}，Alice就實際獲得了0.5 BTC的控制權。
如果Alice暫時不需要將通道中現在屬於她的0.5 BTC用作支付，她可以無需及時更新區塊鏈上記錄的通道餘額分配方案，因爲很可能一分鐘後Alice又需要反過來向Bob支付0.1 BTC，此時他們仍然只需在鏈下對新的餘額分配方案達成一致，並設法作廢前一版本的餘額分配方案就行了。
如果Alice打算終止通道並動用她的那份資金，她可以向區塊鏈出示雙方簽字的餘額分配方案。如果一段時間之內Bob不提出異議，區塊鏈會終止通道並將資金按協議轉入各自預先設立的提現地址。如果Bob能在這段時間內提交證據證明Alice企圖使用的是一個雙方已同意作廢的餘額分配方案，則Alice的資金將被罰沒並給到Bob。
實際上，前面所說的“作廢前一版本的餘額分配”，正是通過構建適當的“舉證”證據並結合罰沒機制實現的。
爲了鼓勵雙方儘可能久地利用通道進行交易，RSMC對主動終止通道方給予了一定的懲罰：主動提出方其資金到賬將比對方晚，因此誰發起誰吃虧。這個設計雖然增加了技術複雜度，但應該說是合理的。
通道餘額分配方案的本質是結算準備金。在此安排下，因爲要完全控制資金交收風險，每筆交易都不能突破當前結算準備金所施限制。
1.2.2 HTLC
RSMC只支持最簡單的無條件資金支付，HTLC（Hashed Timelock Contract）進一步實現了有條件的資金支付，通道餘額的分配方式也因此變得更爲複雜。
通過HTLC，Alice和Bob可以達成這樣一個協議：協議將鎖定Alice的0.1 BTC，在時刻T到來之前（T以未來的某個區塊鏈高度表述），如果Bob能夠向Alice出示一個適當的R（稱爲祕密），使得R的哈希值等於事先約定的值H(R)，Bob就能獲得這0.1 BTC；如果直到時刻T過去Bob仍然未能提供一個正確的R，這0.1 BTC將自動解凍並歸還Alice。
由於到期時間T、提款條件H(R)、支付金額、支付方向的不同，同一個通道上可以同時存在多個活動的HTLC合約，加上唯一的通過RSMC協議商定的無條件資金餘額，餘額分配方式會變得相當複雜。假設雙方初始各存入0.5 BTC，一段時間後餘額分配可能這樣：
餘額分配方案是一種快照，只能整體刷新。接上表，如果Alice下一刻決定無條件向Bob支付0.1 BTC，或者Alice在T1前向Bob出示了符合H(R1)的祕密，雙方將在鏈下交換並共同簽字認定新的快照，然後構建適當的“舉證”證據，結合罰沒機制作廢前一版本的快照。這些動作完全不出現在區塊鏈上。
引入HTLC後，任何一方仍然能通過在區塊鏈上公開最終餘額快照的方式終止通道。
1.2.3 閃電網絡
基於HTLC可以實現終極目標“閃電網絡”。
如上圖所示，Alice想給Dave發送0.05 BTC，但Alice和Dave之間並沒有微支付通道。但這沒關係，Alice找到了一條經過Bob、Carol到達Dave的支付路徑，該路徑由Alice/Bob, Bob/Carol和Carol/Dave這樣三個微支付通道串接而成。
Dave生成一個祕密R並將Hash(R)發送給Alice，Alice不需要知道R。R和Hash(R)的作用就像是古代調兵用的一對虎符。
Alice和Bob商定一個HTLC合約：只要Bob能在3天內向Alice出示哈希正確的R，Alice會支付Bob 0.052 BTC；如果Bob做不到這點，這筆錢3天后自動退還Alice。
同樣地，Bob和Carol商定一個HTLC合約：只要Carol能在2天內向Bob出示哈希正確的R，Bob會支付Carol 0.051 BTC；如果Carol做不到這點，這筆錢到期自動退還Bob。
最後，Carol和Dave商定一個HTLC合約：只要Dave能在1天內向Carol出示哈希正確的R，Carol會支付Dave 0.05 BTC；如果Dave做不到這點，這筆錢到期自動退還Carol。
一切就緒後，Dave及時向Carol披露R並拿到0.05 BTC；現在Carol知道了R，她可以向Bob出示密碼R並拿到0.051 BTC（差額部分的0.001 BTC成了Carol的佣金）；Bob知道R後當然會向Alice出示並拿到他的那份0.052 BTC，差額部分的0.001 BTC成了Bob的佣金。
圖2 閃電網絡逐級提款
整個過程很容易理解。最終效果是Alice支付了0.052 BTC，Dave安全地拿到0.05 BTC，整個閃電支付網絡爲此收取的佣金成本是0.002 BTC。上述過程中的全部動作都發生在比特幣區塊鏈之外。
儘管閃電網絡本身可以基於任何合適的傳統技術構建，閃電網絡的支付通道也可能逐漸向少數大型中介集中，變成若干大型中介彼此互聯、普通用戶直連大型中介的形式，但這種方案仍然具有傳統中心化方案不可比擬的優勢，因爲用戶現在並不需要信任中介，不需要在中介處存錢才能轉移支付，資金安全受到比特幣區塊鏈的充分保護。
比特幣閃電網絡的實現方式非常複雜，不擬在此展開講解，有興趣的讀者可以在附錄一中找到詳細的技術剖析。
2. 雷電網絡（RAIDEN NETWORK）
必須承認，雖然在區塊鏈技術蓬勃發展的今天，比特幣顯得臃腫和老舊，但比特幣社區仍然爲區塊鏈技術貢獻着重要的思想。基於閃電網絡的思路，以太坊社區也提出了自己的鏈下微支付通道解決方案：雷電網絡（Raiden Network）。
Raiden項目源碼託管在https://github.com/raiden-network/raiden，開發語言Python，目前尚未完成，其實施原理則是基於“Universal Payment Channels”一文。當我們將以太坊作爲一個側鏈導入其他加密貨幣之後，很容易依託以太坊智能合約爲各類加密貨幣開發微支付通道。
Raiden項目的思路直接繼承自比特幣閃電網絡，但也有所發展。因爲以太坊智能合約對報文格式沒有特別的字段限制，使得Raiden得以爲通道餘額快照引入一個單增序號，極爲輕鬆自然地解決了舊版本快照的識別和作廢問題。
首先要在以太坊上建有一個智能合約，由此智能合約處理下文提到的OpenTransaction、UpdateTransaction等指令。
圖3 Raiden:建立交易通道
和閃電網絡一樣，雙方需要在以太坊區塊鏈上開設通道並各自鎖定以太。這步動作可通過向Raiden智能合約發送一條雙方簽名認可的報文來實現。報文中的關鍵信息包括：雙方公鑰、雙方鎖定資產數量、雙方簽名。
此後的任何支付動作都可以發生在以太坊區塊鏈外，參與雙方只需要私下傳遞一系列報文，其中最重要的報文是UpdateTransaction，其形式如下。
圖4 Raiden:更新交易通道
此報文的內容幾乎就是閃電網絡的通道餘額分配方案的翻版，只有幾處細微的差別：
一是增加了Sequence Number字段和Hold Period字段以便識別作廢的報文。A如果向區塊鏈上合約提交一個雙方簽字的UpdateTransaction報文，合約將等待Hold Period時間。期間如果對手方B能夠提交一個Sequence Number更高的UpdateTransaction報文，合約將沒收A質押在通道中的全部資產並轉移給B。如果直至等待超時B也沒有異議，合約將按照報文內容在區塊鏈上完成轉移支付並關閉通道。
二是通過Net Transfer Amount隱含餘額分配的方式和閃電網絡略有不同，這裏的方式是從建立通道時申明的Amount 1中扣減Net Transfer Amount，再將之加到Amount 2上。和直接申明餘額比只是形式上的差別。
三是雷電中引入了較HTLC更爲通用的“Smart Condition”。Smart Condition表現爲一個可在區塊鏈上執行的函數Function(argument)，可接受任何格式的報文爲參數，執行後返回一個[0, 1]之間的數。將其返回值乘以配套的Condition Transfer Amount，再加到Net Transfer Amount上去，就完成了條件支付引發的餘額調整。閃電網絡中的所謂hash lock，現在成了Smart Condition的一個特例。Smart Condition能夠提供遠較哈希校驗豐富的功能，比如可以根據某類ORACLE提供的道瓊斯指數值完成衍生品合約的自動執行。
當發生爭議時，只需向區塊鏈上智能合約出示最新版本的UpdateTransaction報文，並請求智能合約對報文中的Smart Condition予以處理，就可以強制執行合約。如果沒有爭議，以上這一切都不會出現在以太坊區塊鏈上，增強了隱私，又提升了性能。
其他設計思路，如通過多跳打通微支付通道、接收方提交適當的argument作爲提款憑證等都和閃電網絡類似。
Vitalik Buterin最近提及的State Channel技術，本質上也和這裏一樣，欲將區塊鏈作爲爭議仲裁及強制執行的最後手段，平時則盡力避免信息在鏈上公開。
3. 帶給CORDA的啓發
R3 CEV的首席技術官Richard Brown之前在博客中披露了Corda的主要特點：
沒有多餘的全局數據共享：只有有合法需求的參與方可以按照協議獲取數據；
Corda編寫和配置在企業間流轉，無中心控制者；
Corda在企業間單個交易水平達成共識，而不是在系統水平上；
系統設計直接支持監管觀察員節點；
交易直接由交易雙方驗證，而不是由一大羣不相干的驗證者進行；
支持多種共識機制；
記錄了智能合約代碼和人類語言法律文件的清晰聯繫；
用行業標準工具創建；
沒有原始加密貨幣。
特徵1、3、5相當值得注意。如果相關參與方只有2到3個，根據計算機科學的已知結論，他們要通過遠程通信達成拜占庭容錯的共識是不可能的，這也是爲何目前的智能合約需要向足夠數量的驗證者公開的重要原因。那麼Corda是怎麼做到這點的？
Corda當然有可能在其核心只做了特徵7，也即通過類XBRL的語言制訂了一種電子化的法律文件模板，然後雙方對此電子簽名後就結束了。但這裏的“雙方電子簽名”就是個兩軍問題。如果一方擁有了雙方簽名的電子合同後就不再繼續，讓另一方空有一份只有一方簽名的電子合同怎麼辦？
這些疑惑的產生都很自然，但當我們見到閃電網絡後，Corda的這些特徵從何而來也許就不再令人費解了。
4. 總結
將交易和智能合約的執行放在鏈下執行，僅在必要的時候纔將其在鏈上公開並執行，這就是閃電網絡帶給我們的絕佳思路。對於合適的業務場景，這種方法可以在吞吐量、確認時延、隱私保護等方面帶來質的提升。
附錄一 比特幣閃電網絡技術剖析
1. 重要說明
相比以太坊而言，爲比特幣增加特性受到的限制要多得多。對於以太坊開發者是小菜一碟的事情，放在比特幣上很可能會成就一篇學術論文。閃電網絡的技術本質並不難理解，但要將之付諸實踐則相當複雜。
閃電網絡的實施建立在若干BIP得以實施的基礎上，比如隔離見證等等。隨着社區開發工作的持續進行，障礙已被陸續掃清，閃電網絡軟件目前已接近正式發佈狀態。
閃電網絡的原始論文非常難懂，很大一部分困難可能來自作者使用的圖例的形式不夠直觀，且缺乏明確的說明。筆者將嘗試使用一套新的圖例，希望能夠極大降低理解難度。
本文將詳細剖析閃電網絡所用交易結構，但不能完全代替原始論文。
圖1 比特幣交易圖例
圖1展示了一個擁有2個輸入、3個輸出、保存在鏈下的比特幣交易記錄，以下逐一說明其中要素。
圓角矩形代表“交易”，用不同的底色區分交易持有者，本文一律用玫紅色表示Alice，淺藍色表示Bob。圓角矩形的邊框用細實線勾勒，表示該筆交易並未公佈在區塊鏈上。
論文中每筆交易都有一個名稱，雖然比特幣交易結構並沒有這樣一個字段。我們選擇將交易名稱寫在圓角矩形上半部，上圖中“txnName”就是這個名稱。
閃電網絡需要在比特幣交易結構中的sequence字段和locktime字段填入適當的值，將其寫在圓角矩形的下半部，如上圖中的“seq = 1000”。
“0.55、0.35、0.3、0.4、0.2”都是交易輸出金額。雖然“0.55和0.35”邊上的箭頭代表交易輸入，但交易輸入一定是另一交易的輸出，所以這樣表達仍然合理。
“0.3、0.4、0.2”邊上的箭頭代表交易輸出。“#0, #1, #2”代表輸出序號。
金額爲0.3的交易輸出旁邊寫有“（B）”，表示該筆交易輸出需用B的私鑰解鎖。
金額爲0.55的交易輸入旁邊寫有“（C）”，意思一樣，表示需動用C的私鑰解鎖對應交易輸出。在“（C）”的右上方打有一鉤（√），表示對應解鎖條件已就緒。此鉤顏色是綠色，表示此解鎖腳本在交易擁有者拿到手時就已就緒。
“（A, B, H(R)）”代表一個特殊的解鎖條件，需要同時提供A和B的私鑰簽名，並且需要提供一個合適的R，令其哈希值等於預設的H(R)值，才能解鎖交易輸出。圖中A、B右上角都打有綠色的鉤，表明對應解鎖條件已就緒。H(R)右上角沒有任何鉤，表明合適的R尚未出現。
接下來我們爲這筆交易提供正確的R值，並將就緒後的交易在區塊鏈上公佈，對應圖例就變成這樣：
注意H(R)右上方出現了紅色的鉤，表明對應解鎖條件變爲就緒。圓角矩形框的邊框變成寬實線，表明這筆交易已公佈在區塊鏈上。
圖3 互斥的交易
閃電網絡允許在鏈下並存多個消費同一交易輸出的不同交易。如果將這些交易都發布到區塊鏈上，顯然只有其中一個交易能夠生效，其他交易都因爲不能雙花被拒絕了。上圖用一個帶“X”的圓圈表達了C1a、C1b的互斥關係。
HTLC中會使用IF…ELSE…ENDIF結構的加鎖腳本，就長這樣子：
圖4 IF…ELSE…ENDIF腳本
其中一個分支通過提供Alice2、Bob2的簽名和R解鎖，另一個分支只需提供Alice1、Bob2的簽名就可以解鎖。爲特別表明此處用到了IF結構，在圖例中我們會在表達互斥的帶“X”圓圈旁邊加註“if”，就像下圖一樣：
圖5 if語句帶來的互斥交易
2. RSMC剖析
2.1 通道建立
圖6 通道建立
通道建立只需要雙方在鏈下準備一套類似上圖的交易結構，完成後僅將funding交易發佈到區塊鏈上（注意粗實線的邊框）。上圖中的A代表Alice,B代表Bob。
雖然本例中雙方都向通道注資0.5 BTC，但其實各自注入多少都是可以的，不強求相等或大於0。
之所以要完全準備就緒這套交易結構後才能發佈funding交易，是爲了避免先發布funding交易後一方拒絕配合完成其餘交易的準備活動。由於funding交易唯一的輸出要求同時使用A/B雙方的私鑰簽字才能提取，一方拒絕配合簽名將導致這部分資金永久無法支取。所以合理的順序是先準備就緒全套交易，再發布funding交易。
上圖中，交易C1a雖然爲Alice持有（玫紅底色），但其輸入解鎖腳本中B已就緒，因此這條交易記錄實際上是Bob準備好後給到Alice的，因爲除了Bob沒人能夠做到這一點。C1b的輸入解鎖腳本中A也已就緒，說明交易記錄C1b是Alice準備好後給到Bob的。
圖中，交易RD1a和RD1b上都標註了“seq=1000”，這是比特幣交易結構的一個最新特性，sequence字段如此設置後，交易RD1a只能在包含其父交易C1a的區塊得到1000個確認後才能被收錄。
2.2 單方面終止通道
通道建立後，Alice或Bob隨時可以選擇單方面終止通道並取回資金，發起方將受到延遲提款的懲罰。
Alice單方面終止通道的方式如下：Alice爲C1a和RD1a的輸入解鎖腳本用自己的私鑰簽名，並在區塊鏈上發佈交易C1a。由於RD1a的seq = 1000，他必須等待C1a被收錄並得到1000個確認後才能發佈交易RD1a，因此他需要等上10,000分鐘（約7天）才能通過RD1a取回自己的款。對Bob來說，他只需要在區塊鏈上看到C1a發佈，隨時可以用自己的私鑰動用C1a的0號輸出的資金。最終雙方都得到0.5 BTC，funding交易的輸出被提取一空，通道終止。
圖中用粗黑有向線條表達了區塊鏈上實際的資金流向。
2.3 微支付及舊版本廢止
在雙方各佔0.5 BTC的基礎上，Alice向Bob支付0.1 BTC，雙方餘額應該調整爲Alice 0.4 BTC，Bob 0.6 BTC。
爲此需要創建餘額的新版本，然後廢止餘額的舊版本。由於比特幣的交易由一個個離散的utxo構成，也沒有多餘的字段存放“版本號”，所以是迂迴地通過經濟手段來達到實際廢止的效果。
圖8 微支付：創建新版本餘額
創建餘額的新版本很簡單，雙方完全不動區塊鏈上的funding交易，在鏈下按上圖另外創建一套反映新餘額的交易。很清楚，現在Alice實際控制0.4 BTC而Bob實際控制0.6 BTC，等價於Alice支付Bob 0.1 BTC。注意爲便於區分，交易名稱都改變了。
作廢舊版本的餘額非常有技巧，方法是在舊版本交易的基礎上增加幾個作惡懲戒交易，效果上類似發誓：“我要是拿這個舊版本去區塊鏈上提款，你就把我的那份拿走！”，只不過這個誓言是決定可以生效的。
圖9 微支付：作廢舊版本餘額
C1a, C1b, RD1a, RD1b都是舊版本餘額用到的交易。作廢這堆交易的方式是構造一對新的交易BR1a和BR1b，並準備就緒其輸入解鎖腳本所需全部簽名。上圖中，紅色虛線框中的兩筆交易是在原來基礎上新增構建的。
在圖9的基礎上，如果Alice希望通過在區塊鏈上通過發佈舊版本餘額對應的交易來逆轉剛纔支付給Bob的0.1 BTC，她將受到懲罰，原理見上圖。
Alice爲C1a的輸入解鎖腳本補上自己的簽名，發佈到區塊鏈上。因爲交易RD1a有seq=1000的屬性設定，所以Alice暫時還不能發佈RD1a。但Bob將看到承諾作廢的C1a被放出，爲保護自身利益，Bob可以立刻在區塊鏈上發佈交易BR1a，因爲BR1a的父交易已被放出，且BR1a的輸入解鎖腳本早已就緒，所以BR1a可以馬上生效，於是Bob一共可以拿走1.0 BTC，企圖作惡的Alice偷雞不成。
正常情況下，Alice只要不在區塊鏈上發佈C1a，雖然Bob擁有輸入解鎖腳本完全就緒的BR1a，因爲其父交易C1a並未發佈，Bob也無法發佈BR1a。這說明只要一方安分守己，就無需擔心懲罰措施。
3. HTLC剖析
3.1 初始化HTLC
圖11給出的是一個簡單的HTLC示例，其所反映的通道餘額劃分是：有0.9 BTC以無條件餘額劃分的形式在Alice和Bob之間分割，Alice佔0.4 BTC，Bob佔0.5 BTC。Alice向Bob有條件支付0.1 BTC，如果Bob能於3天內（實際是以區塊鏈高度代表的未來某時）之前提供合適的R，Bob就能得到這筆錢，反之這筆錢仍然回到Alice賬上。
這裏的“> 3 days”是利用locktime字段的最新擴展實現的。和“seq=1000”的區別在於：locktime指定的是一個高度絕對值，而sequence指定的是相對父交易所在區塊高度的相對值。
由於要在一個通道上同時反映無條件餘額劃分和有條件支付，所以交易結構變得相當複雜。圖10中，C2a, RD2a, D2a, C2b, RD2b, D2b通過RSMC實現無條件餘額劃分，最下方的6筆交易專門用於HTLC支付。
3.2 條件支付的兩種結果
如果Bob能夠在3天內及時提交R，他可以如圖11所示，準備好一系列交易的輸入解鎖腳本（注意圖中紅色的“√”）後將C2b、RD2b、HE1b及HERD1b交易發佈到區塊鏈上，拿走0.5+0.1 BTC。Alice此時只能跟着發佈交易D2b拿走自己的0.4 BTC，通道終止。
也可以不終止通道，關鍵在於只要Bob離線告知Alice他擁有適當的R，且雙方願意達成新版本的餘額劃分，那麼只需要新建一個Alice 0.4 BTC、Bob 0.6 BTC的新版本餘額並廢止舊版本，效果上就等於這0.1 BTC的條件支付已經達成。
圖13 HTLC: 超時退款
如果直到超時Bob仍不能提供正確的R值，Alice可以如圖12所示，通過用自己的私鑰準備各交易的輸入解鎖腳本併發布交易到區塊鏈上，最終取回這0.1 BTC（注意圖中紅色的“√”），。在此方式下，最終Alice拿到0.5 BTC，Bob拿到0.5 BTC。和圖11完全類似，也可以採用新建版本餘額的方式，無需終止通道。
2.3 作廢舊版本與違約懲罰
建立新版本餘額快照後，就應該作廢舊版本。和之前作廢舊版本的思路類似，在通道中還包含HTLC合約的情況下，依然靠新增若干作惡懲戒交易的方式作廢舊版本。
圖14中用紅色虛線框出的部分就是新增的“作惡懲戒交易”。
在圖15中，假設HT1a交易已經超時，但以C2a爲根的全部交易都已通過懲戒交易予以作廢。如果此時Alice想作惡，她將C2a、RD2a、HT1a及HTRD1a的輸入解鎖腳本用自己的私鑰準備就緒後（注意圖中紅“√”），將交易C2a和交易HT1a在區塊鏈上公開。由於seq字段的限制，她不能立刻公開交易RD2a和HTRD1a，這樣就使得Bob有機會發現Alice企圖作惡並能夠通過公佈BR2a和HTBR1a交易的方式予以懲戒。發出這對交易後，通道中的全部資金將都歸Bob所有。
圖15中雖然沒有用上懲戒交易HBR1a，但該交易並不多餘。理由是：如果Alice在區塊鏈上公佈了交易C2a但故意不公佈交易HT1a，倘若Bob手頭沒有HBR1a，也不知道祕密R，Bob將無法獲得這0.1 BTC。有了懲戒交易HBR1a之後，即使Alice不公佈交易HT1a，只要C2a公佈，Bob也可以通過HBR1a順利提取這0.1 BTC。
只提供HBR1a、不提供HTBR1a也是不行的。因爲萬一Alice選擇的是解鎖並公佈交易HT1a，並且搶在Bob之前消費了C2a的#2輸出，Bob擁有的HBR1a交易就無法生效了，而此時雖然HTRD1a交易要等上1000個確認才能公佈，Bob也沒有任何手段來利用這1000個塊的確認時間來阻止Alice提取這0.1 BTC。