From rusty at rustcorp.com.au Thu Mar 10 01:13:58 2016 From: rusty at rustcorp.com.au (Rusty Russell) Date: Thu, 10 Mar 2016 11:43:58 +1030 Subject: [Lightning-dev] terminology In-Reply-To: <20160309064850.GA26586@sapphire.erisian.com.au> References: <20160309064850.GA26586@sapphire.erisian.com.au> Message-ID: <87r3fjkucp.fsf@rustcorp.com.au> Anthony Towns writes: >>From IRC: > > 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 > HTLC? > "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... Cheers, Rusty.