From rusty at rustcorp.com.au Fri Jul 24 00:54:05 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Fri, 24 Jul 2015 10:24:05 +0930 Subject: [Lightning-dev] HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes. In-Reply-To: References: <87fv51eqjl.fsf@rustcorp.com.au> Message-ID: <87bnf2qssy.fsf@rustcorp.com.au> Anthony Towns writes: > On 6 July 2015 at 16:41, Rusty Russell wrote: > >> To recap: each side maintains a commitment transaction with two >> outputs: one paying to self (with some delay), and the second paying to >> the other side. >> To generate hash time-locked contracts (required for lightning >> to be a network), both commitment transactions get an additional output. >> > > ?That is, an additional output per HTLC, no?? Yep. > This output is spendable under four conditions: > > 1) Recipient knows the R value (funds go to recipient), OR >> 2) The HTLC has timed out (funds return to initiator), OR >> 3) The HTLC has been revoked (funds to go "non-cheating" side), OR >> 4) The Commit transaction has been revoked (funds to go "non-cheating" >> side) >> > > >> The last two failure modes are separate from each other, because HTLCs >> have different lifetimes from commit transactions. >> > > ?I'm not sure that makes sense? It seems to me there's two options: Yes, the paper removed the unneceesary HTLC revocation. It was a leftover from before HTLCs were reduced to a single output. See: https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf (Still haven't written the code, so these scripts are untested. I'm hoping to finish the dual-anchor code soon though, then HTLCs are next). Cheers, Rusty.