[Lightning-dev] HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and revocation hashes.

Rusty Russell rusty at rustcorp.com.au
Fri Jul 24 00:54:05 UTC 2015


Anthony Towns <aj at erisian.com.au> writes:
> On 6 July 2015 at 16:41, Rusty Russell <rusty at rustcorp.com.au> 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.


More information about the Lightning-dev mailing list