📅 Original date posted:2015-07-27
📝 Original message:
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.