BOLT 2: clarify HTLC handling, esp w/ on-chain.

1. We say you can't fail an HTLC until it's removed outgoing; make it clear that this could also be on-chain. 2. Insist that you fail an expired HTLC (we never actually said this!) 3. You MUST fulfill an incoming HTLC for which the output was fulfilled (otherwise you'll lose money), and of course, even if fulfilled on-chain. Add an explanation paragraph to BOLT 5 as well, where it discusses on-chain HTLC output cases (though the requirements about what to do about incoming HTLCs is actually in BOLT 2). [ Extra wording clarification thanks to roasbeef ] Signed-off-by: Rusty Russell <[email protected]>
luke-jr · Aug 22, 2017 · 4bcf9dd · 4bcf9dd
1 parent b3b7a96
commit 4bcf9dd
Show file tree

Hide file tree

Showing 2 changed files with 13 additions and 3 deletions.
diff --git a/02-peer-protocol.md b/02-peer-protocol.md
@@ -506,10 +506,12 @@ A node MUST NOT offer an HTLC (`update_add_htlc`) in response to an incoming HTL
 the incoming HTLC has been irrevocably committed.
 
 A node MUST NOT fail an incoming HTLC (`update_fail_htlc`) for which it has committed 
-to an outgoing HTLC, until the removal of the outgoing HTLC is irrevocably committed.
+to an outgoing HTLC, until the removal of the outgoing HTLC is irrevocably committed, or the outgoing on-chain HTLC output has been spent via the HTLC-timeout transaction with sufficient depth.
+
+A node MUST fail an incoming HTLC (`update_fail_htlc`) once its `cltv_expiry` has been reached.
 
-A node SHOULD fulfill an incoming HTLC for which it has committed to an outgoing HTLC, 
-as soon as it receives `update_fulfill_htlc` for the outgoing HTLC.
+A node MUST fulfill an incoming HTLC for which it has committed to an outgoing HTLC,
+as soon as it receives `update_fulfill_htlc` for the outgoing HTLC, or has discovered the `payment_preimage` from an on-chain HTLC spend.
 
 #### Rationale
 

diff --git a/05-onchain.md b/05-onchain.md
@@ -262,6 +262,14 @@ the commitment transaction is ours, we need to use the HTLC-timeout
 transaction.
 
 
+The fulfillment of an on-chain HTLC delivers the `payment_preimage`
+required to fulfill the incoming HTLC (if it, too, is on-chain) or use
+in the `update_fulfill_htlc` message for the incoming HTLC.
+Otherwise, it needs to send the `update_fail_htlc` (presumably with
+reason `permanent_channel_failure`) as detailed in [BOLT
+02](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#forwarding-htlcs).
+
+
 # On-chain HTLC Output Handling: Their Offers