From rusty at rustcorp.com.au  Tue Jul 28 01:38:05 2015
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Tue, 28 Jul 2015 11:08:05 +0930
Subject: [Lightning-dev] Breach of contract?
In-Reply-To: <20150727193714.GA16768@lightning.network>
References: <trinity-74561245-d7a6-480d-81af-a87e7a2d3fce-1437857956212@3capp-mailcom-bs04>
	<87k2tmpdvl.fsf@rustcorp.com.au>
	<20150727193714.GA16768@lightning.network>
Message-ID: <874mkpoyde.fsf@rustcorp.com.au>

Joseph Poon <joseph at lightning.network> writes:
> On Mon, Jul 27, 2015 at 11:20:54AM +0930, Rusty Russell wrote:
>> Yes, I assume that the HTLC gets eliminated by a commitment transaction
>> update at (or before) that time.
>> 
>> We could add an additional delay for this case, but it seems like
>> overengineering?
>
> To ensure that the older version of the transaction does not get
> broadcast through a credible threat, there needs to be some contestation
> period for one's own HTLC when one is redeeming funds.

The rule, AFAICT, is: if it's A's commitment transaction, all outputs
which are redeemable by A must be delayed.

For HTLCs, this means:
1) Timeout returns for HTLCs A initiates must be OP_CSV delayed.
2) Payments for HTLCs A receives must be delayed.

I just noticed the scripts in the 0.1 draft are a bit messed up; in
particular they're missing a delay.  Here's the (fixed!) A offers HTLC
to B case:

(See https://github.com/ElementsProject/lightning/blob/master/doc/ )

HTLC Sender Redeemscript (A):

OP_HASH160 OP_DUP        Replace top element with two copies of its hash
<R-HASH> OP_EQUAL        Test if they supplied the HTLC R value
OP_SWAP <COMMIT-REVOCATION-HASH> OP_EQUAL OP_ADD
                         Or the commitment revocation hash

OP_IF                    If any hash matched.
        <KEY-B>          Pay to B.
OP_ELSE                  Must be A, after HTLC has timed out.

        <HTLC-TIMEOUT> OP_CHECKLOCKTIMEVERIFY OP_DROP
                         Ensure (absolute) time has passed.
        <DELAY> OP_CHECKSEQUENCEVERIFY OP_DROP
                         Delay gives B enough time to use revocation if it has it.
        <KEY-A>          Pay to A.
OP_ENDIF
OP_CHECKSIG              Verify A or B's signature is correct.

HTLC Receiver Redeemscript (B):

OP_HASH160 OP_DUP        Replace top element with two copies of its hash
<R-HASH> OP_EQUAL        B redeeming the contract, using R preimage?
OP_IF
        OP_DROP          Remove extra hash
        <DELAY> OP_CHECKSEQUENCEVERIFY OP_DROP
                         Delay gives A enough time to use revocation if it has it.

        <KEY-B>          Pay to B
OP_ELSE
        <COMMIT-REVOCATION-HASH> OP_EQUAL
                         If the commit has been revoked.
        OP_NOTIF
                         If not, you need to wait for timeout.
                <HTLC-TIMEOUT> OP_CHECKLOCKTIMEVERIFY OP_DROP
                         Ensure (absolute) time has passed.
        OP_ENDIF

        <KEY-A>          Pay to A
OP_ENDIF
OP_CHECKSIG              Verify A or B's signature is correct.

> Current/unexpired HTLCs will have the same payout and enforcement, but
> there is a risk of broadcasting older Commitments and stealing the HTLC
> payout, e.g. transactions that are believed to be timed out but whose
> preimages are known after-the-fact.

I see that?

If A broadcast an older commitment, B can steal the HTLC payout, but
that's as designed.

Cheers,
Rusty.