在上一篇文章中，Alice 和Bob 建立了一個雙向的支付通道。但現在，Alice 想要給一個第三方Carol 支付 1 btc。一般來說，Alice 和 Carol 需要在彼此之間開設一個支付通道。但實際上並不需要。因為Bob 和Carol 之間已經有了一個通道，所以Alice 可以通過Bob 給Carol 支付，這樣就可以在不用負擔額外成本的情況下完成交易了。
（前情提要：乾貨 | 閃電網路深入解讀（上）：支付通道）
（事件背景：Arcane 報告：比特幣閃電網路支付的使用用戶數達 8,000 萬人！一年增長 800 倍
具
體來說，Alice 可以給Bob 支付 1 btc，而 Bob 再支付1 btc 給Carol。但是，Alice 實際上並不信任Bob，或者 Carol 並不信任Bob。她擔心把錢給 Bob 之後，Bob 不會給 Carol；又或者，他把錢給了Carol，但 Carol 謊稱自己壓根沒見到錢，而 Alice 也不知道該找哪個來追責。
因此，Alice 希望能保證，僅當 Bob 給了Carol 1 btc，自己才需要給 Bob 支付1 btc。
當Alice 要給Carol 支付1 btc 時，她讓Carol 先生成一個 Secret Key，並把對應的哈希值發給她。Alice 也告訴Carol 可以用這個 Secret Key 跟 Bob 交換1 btc。
與此同時，Alice 把從 Carol 處得到的哈希值發給 Bob，並告訴 Bob 如果他能提供對應於這個哈希值的 Secret Key，她就會給 Bob 1 btc（ 這個 Secret Key當然只有Carol 擁有 ）。
所以 Bob 找到 Carol，用1 btc 換來了Carol 的 Secret Key。
然後，Bob 找回 Alice，提供這個Secret Key。Alice 因此知道了 Bob 一定給過錢了，也就是 Carol 肯定已經收到了1 btc，於是就把錢給了Bob。
皆大歡喜，啊，幾乎是皆大歡喜。
在這種「 過家家」的情形下，中間人 Bob 還是需要信任 Alice 和 Carol。Bob 必須相信 Carol 給他的是一個真正有用的值（不然錢都給了就拿不回來了），而且要相信 Alice 真的會給他1 btc，假如他能提供對應於哈希值的Secret Key 的話。
這時候，我們就需要哈希時間鎖合約（HTLC）啦！
延伸閱讀：Block（前 Square) 宣布 Cash App 整合閃電網路， 比特幣付款數秒完成無須手續費
延伸閱讀：關鍵截圖曝光！工程師 : Twitter內建「比特幣小費支付」已好！使用閃電網路
延伸閱讀：【動區專題】閃電網路是比特幣的未來？——解決方案全攻略
哈希時間鎖合約
要解決上述的信任問題就必須做到兩點:
假設 Alice 需要付給 Carol 1 個 BTC，收款方 Carol 會創建一個 Value ( 鑰匙 ) 和對應的哈希值 ( 鎖頭 )，然後把哈希值交給 Alice。
這時候，如果 Bob 能給出 Value ( 鑰匙 )，就代表 Carol 確實收到了 1 個 BTC（ Carol 也同樣跟 Bob 簽訂一個合約，只要 Carol 提供哈希值對應的 Value ( 鑰匙 )，就必須給 Carel 1 BTC ）
在這個前提下，Alice 和 Bob 提出一份合約，如果 Bob 在 14 天內（Lock time = 3 day），提供哈希值對應的 Value，Alice 就給 Bob 1 BTC，超過 14 天，BTC 原路返回給 Alice。
最後要強調的一點是，Bob 必須在有效期內從 Carol 那裡拿到 Value ( 鑰匙 )，否則 Alice 就有可能取回多簽地址上的1 btc。如果等 Alice 取回1 btc 之後 Bob 才從 Carol 那裡拿到了Value ( 鑰匙 )，Bob 就會被卡在中間進退兩難。
因此，Bob 和 Carol 的哈希時間鎖合約必須比 Alice 和 Bob 的先到期（ 例如，前者的時限可以設成10 天，而非兩週 ）這就是為什麼哈希時間鎖合約需要 CheckLockTimeVerify（ 絕對時間鎖 ）而非 CheckSequenceVerify（相對時間鎖）。
