mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 10:00:04 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 5: requirement to fail HTLCs which don't have outputs in the commit tx.

Browse Source 
BOLT 5 only talks in terms out HTLC outputs, but not all HTLCs have outputs.

HTLCs which are dust for both sides are easy, but others require the
commit tx to be buried before we can consider the HTLC failed.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2017-08-31 11:02:25 +09:30
parent 36c099e0d4
commit 149cf020d6
1 changed files with 20 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
05-onchain.md
View File

@ -208,6 +208,9 @@ B's *commitment transaction*, hence the requirement to handle both.
Each HTLC output can only be spent by us after it's timed out, Each HTLC output can only be spent by us after it's timed out,
or them if they have the payment preimage. or them if they have the payment preimage.
There can be HTLCs which are not represented by an output: either
because they were trimmed as dust, or in the case where B has two
valid commitment transactions, and the HTLCs differ in each.
The HTLC has *timed out* once the depth of the latest block is equal The HTLC has *timed out* once the depth of the latest block is equal
or greater than the HTLC `cltv_expiry`. or greater than the HTLC `cltv_expiry`.
@ -232,6 +235,13 @@ Transaction Handling". Otherwise it MUST resolve the
output by spending it to a convenient address. output by spending it to a convenient address.
For any committed HTLC which does not have an output in this
commitment transaction, the node MUST fail the corresponding incoming
HTLC (if any) once the commitment transaction has reached reasonable
depth, and MAY fail it sooner if no valid commitment transaction
contains an output corresponding to the HTLC.
## Rationale ## Rationale
@ -270,6 +280,16 @@ reason `permanent_channel_failure`) as detailed in [BOLT
02](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#forwarding-htlcs). 02](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#forwarding-htlcs).
If an HTLC is too small to appear in *any* commitment transaction, it
can be safely failed immediately and `update_fail_htlc` returned to
the incoming HTLC (if any: it might be locally-generated). Otherwise,
if a HTLC isn't in the commitment transaction we need to make sure
that a blockchain reorganization or race does not switch to a
commitment transaction which does contain it, before we fail it, hence
the wait. The requirement that we fail the incoming HTLC before its
own timeout still applies as an upper bound.
# On-chain HTLC Output Handling: Their Offers # On-chain HTLC Output Handling: Their Offers