mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-01-19 05:33:37 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 3: Explicit description of implicitly enforced timelocks on HTLC outputs (#601)

Browse Source 
* Added descriptions of how a 2-of-2 multisignature verification is used for enforcing timelocks when timing out on-chain offered HTLCs as well as spending on-chain received HTLCs in the success case.
This commit is contained in:
Nadav Kohen 2019-08-19 16:52:09 -05:00 committed by Bastien Teinturier
parent 6729755f0c
commit 8555709811
2 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
02-peer-protocol.md
View File

@ -991,6 +991,8 @@ offline until after sending `commitment_signed`. Once
those HTLCs, and cannot fail the related incoming HTLCs until the
output HTLCs are fully resolved.
Note that the `htlc_signature` implicitly enforces the time-lock mechanism in the case of offered HTLCs being timed out or received HTLCs being spent. This is done to reduce fees by creating smaller scripts compared to explicitly stating time-locks on HTLC outputs.
### Completing the Transition to the Updated State: `revoke_and_ack`
Once the recipient of `commitment_signed` checks the signature and knows

4
03-transactions.md
View File

@ -147,7 +147,7 @@ If a revoked commitment transaction is published, the remote node can spend this
<revocation_sig> <revocationpubkey>
The sending node can use the HTLC-timeout transaction to timeout the HTLC once the HTLC is expired, as shown below.
The sending node can use the HTLC-timeout transaction to timeout the HTLC once the HTLC is expired, as shown below. This is the only way that the local node can timeout the HTLC, and this branch requires `<remotehtlcsig>`, which ensures that the local node cannot prematurely timeout the HTLC since the HTLC-timeout transaction has `cltv_expiry` as its specified `locktime`. The local node must also wait `to_self_delay` before accessing these funds, allowing for the remote node to claim these funds if the transaction has been revoked.
#### Received HTLC Outputs
@ -178,7 +178,7 @@ If a revoked commitment transaction is published, the remote node can spend this
<revocation_sig> <revocationpubkey>
To redeem the HTLC, the HTLC-success transaction is used as detailed below.
To redeem the HTLC, the HTLC-success transaction is used as detailed below. This is the only way that the local node can spend the HTLC, since this branch requires `<remotehtlcsig>`, which ensures that the local node must wait `to_self_delay` before accessing these funds allowing for the remote node to claim these funds if the transaction has been revoked.
### Trimmed Outputs