Why Nostr? What is Njump?
2023-06-09 12:43:46
in reply to

Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-27 📝 Original message: Joseph Poon <joseph at ...

📅 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.
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx