1. 引言
Hash Time-lock Contracts (HTLCs) 为任何闪电交易的核心。
闪电网络通道为比特币链上的一个2-of-2多签地址。
a HTLC为an unconfirmed交易的一个output，可对应为一个不同的“smart contract”地址，并具有如下属性：
- 1）通过提供某secret和有效的接收者签名，可花费该HTLC。
- 2）若超过设定时间，通过提供发送者的签名，可花费该HTLC。
具有以上1）、2）属性的HTLC可用于闪电网络之外。
当将HTLC用于在闪电通道内转账时，还需具有第三个属性：
- 3）若某人提供a revocation key，可立即花费该HTLC。
事实上，该uncommitted 交易不会提交到链上，当接收者提供了preimage：
- 通道内的balance将更新
- 创建新的commitment transaction
- 使前一commitment transaction失效
2. commitment transaction
正常通道内的commitment transaction看起来如上图，包含了一个input。
该input代表了该通道的channel point，或该channel的交易ID。该input对应的交易记录在链上，仅能由Bob和Alice双方签名的交易才能花费该input。
commitment transaction由Alice和Bob双方签名，根据其通道内的balance（此时为Alice 9BTC，Bob 1BTC）来花费该channel balance（10BTC）。
3. 创建a HTLC
当Alice支付一个1BTC 的invoice收款凭证时，Alice会创建一个新的commitment transaction，在该commitment transaction中，将Alice的balance降为8BTC，Bob的balance仍为1BTC，同时新创建一个1BTC的output。新创建的1BTC的output为HTLC，相应的脚本类似为：
IF <revocation pubkey>
ELSE IF <hash(preimage)>
<recover pubkey>
ELSE CHECKLOCKTIME
<sender pubkey>
取决于所选择的路由，Bob可能需转发该HTLC，此时Bob需要为其另一通道创建一个新的commitment transaction，从Bob的通道balance中减去1BTC，然后采用相同的preimage hash、将其中的recover pubkey替换为Bob节点的pubkey、将其中的sender pubkey替换为Bob的sender pubkey。
4. 在通道内固化a HTLC
一旦该1BTC payment的接收方看到具有1BTC HTLC的commitment transaction，接收方提供该preimage，然后该HTLC就固化回了channel balance中。此时，Bob将创建一个新的commitment transaction来移除该HTLC output，然后将该HTLC output的balance加到Bob的channel balance中。Alice，意识到Bob知道该preimage并可在链上claim 该HTLC，因此Alice也就有兴趣对Bob创建的新commitment transaction进行联合签名。整个支付环节完成。
若支付未完成（针对的场景为Bob不知道该preimage），该HTLC也可固化。比如Alice创建一个新的commitment transaction，将其balance改回为9BTC，此时，Bob可意识到其无法提供preimage来claim该HTLC，因此也有兴趣对Alice创建的新commitment transaction进行联合签名。从而维护该通道的活性。
5. HTLC在链上结算
某些特殊情况，HTLC需要在链上结算。因掉线等原因，当Alice不对Bob创建的新commitment transaction签名（即无法在通道内固化a HTLC）时，需要在链上对HTLC进行结算。
在链上对HTLC进行结算会对通道进行强制关闭，并锁定资金。若知道该HTLC的preimage，可立即赎回，否则需要等待一定时间。
若一方将某个old、revoked HTLC提交上链了，对方可使用revocation key获取通道内的所有资金。
6. Multi-hop payments
借助HTLC，可使payment以原子方式在不同通道内传输，要么都成功，要么都失败。中间的路由节点无法窃取资金。整个路由过程中构建的HTLC需采用统一secret preimage的同一hash值。
若某HTLC由最终接收方在链上结算，在该链上交易中公开了相应的preimage，其它中间节点可用该preimage来claim其HTLC。
7. HTLC约束
7.1 HTLC的非对称性
类似于commitment transaction，对HTLC也存在非对称性。取决于谁想向链上提交该HTLC，会使用不同的revocation key和waiting period。（如，若Alice提交了其交易，Bob可使用其key来contest）
7.2 HTLC的waiting period
每个通道可独立定义其各自的waiting period。通过设置lncli openchannel的--max_local_csv和--remote_csv_delay flag。
大的waiting period可makes it safer to recover from a failure, but will also lock up funds for longer if a channel closes unilaterally。
7.3 HTLC的CLTV delata
time lock delta（或CLTV expiry delta）为incoming HTLC和outgoing HTLC的expiration最小差。该差值可保证总是有足够的时间来settle an HTLC，即使前一HTLC在最后一分钟在链上结算。
可设置updatechanpolicy的--time_lock_delta flag，或者在配置文件中设置：
bitcoin.timelockdelta=40
7.4 HTLC size
可设置--min_htlc_msat来避免小额HTLC引起的通道关闭风险，或者由于低于dust limt无法在链上结算的情况。
7.5 最大在途值
设置--remote_max_value_in_flight_msat 来设置某通道内允许pending的最大金额，单位为sat。
7.6 多个HTLC
一个通道一次可处理数百个HTLC，当前默认设置最多为483。
default-remote-max-htlcs=483
应用示例为：
lncli updatechanpolicy --base_fee_msat 100 --fee_rate 0.00001 --time_lock_delta 50 --min_htlc_msat 1000 --chan_point 17ec2d0ac18d953b1dfe2cafa116b0c118020cab4d80c4063fe98debda6df469:1
lncli openchannel --node_key 021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d --connect 50.112.125.89:9735 --local_amt 210000000 --remote_max_value_in_flight_msat 105000000000 --max_local_csv 50
FAQ
- Can I receive payments while being offline?
To perform a Lightning Network transaction, both peers as well as all routing nodes in between need to be online. For mobile wallets, this often requires keeping the wallet running until the payment is settled, after which the application or device can be turned off. From a safety perspective it is not important to keep a Lightning wallet permanently connected to the internet.