rusty at rustcorp.com.au
Thu Mar 10 01:13:58 UTC 2016
Anthony Towns <aj at erisian.com.au> writes:
> <rusty> Hmm, what term should I use in documentation for the
> failure mode where a node uses too tight a timeout and ends up
> paying out an outgoing HTLC but unable to redeem the incoming
> <rusty> "one-sided redemption" is what I came up with, but it's not very
> punchy for "you screwed up and lost money"
> That's too loose a timeout, isn't it? You choose the timeout for your
> outgoing payment, so if the incoming timeout runs out, your outgoing
> timeout was too long.
> I'd just call it "avoiding timeout on incoming HTLC when forwarding"
> or similar?
Here's what I've got in my current draft, which spells out the exact
requirements in detail:
## Risks With HTLC Timeouts ##
HTLCs tend to be chained across the network. For example, a node A
might offer node B an HTLC with a timeout of 3 days, and node B might
offer node C the same HTLC with a timeout of 2 days.
This difference in timeouts is important: after 2 days B can try to
remove the offer to C even if C is unresponsive, by broadcasting the
commitment transaction it has with C and spending the HTLC output.
Even though C might race to try to use its R preimage at that point to
also spend the HTLC, it should be resolved well before the 3 day
deadline so B can either redeem the HTLC off A or close it.
If the timing is too close, there is a risk of "one-sided redemption",
where the R preimage received from an offered HTLC is too late to be
used for an incoming HTLC, leaving the node with unexpected liability.
However, there is an additional relative delay which needs to be
considered; if the connection fails, the node is forced to broadcast
the latest commitment transaction to the blockchain. It will not be
able to reclaim timed-out HTLC funds until `delay` (as specified by
the other node's `open_message`) has passed. Thus the actual timeout
of the HTLC is the greater of `expiry`, and the current time plus
`delay`. In addition, there will be some additional delay for the
transaction which redeems the HTLC output to be irreversibly committed
to the blockchain.
Thus a node MUST estimate the deadline for successful redemption for
each HTLC it offers. A node MUST NOT offer a HTLC after this
deadline, and MUST fail the connection if an HTLC which it offered is
in either node's current commitment transaction past this deadline.
> On Wed, Mar 09, 2016 at 11:13:36AM +1030, Rusty Russell wrote:
>> Confusingly, we also use "revocation preimage" as the term method to
>> invalidate old transactions, a private matter between pairs of nodes,
>> but try to avoid abbreviating it to R.
> Yeah, the lack of an obvious abbreviation for the revocation preimage
> has bugged me a couple of times. What about saying we "void" the old
> commitment, and use "V" as the symbol for the hash/signature/whatever?
Invalidate, hence I? I find void confusing as it's a noun and verb...
More information about the Lightning-dev