[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