[Lightning-dev] Breach of contract?

[Rusty Russell]

Joseph Poon <joseph at lightning.network> writes:
> On Tue, Jul 28, 2015 at 11:08:05AM +0930, Rusty Russell wrote:
>> 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:
>
> Ah ok, cool!
>
>> [scripts]
>
> After thinking about this for a bit, there's two implications for this
> script:
>
> 1. De-facto requires constantly watching the blockchain for a very low
> interval. If Alice and Bob establish a channel, make a couple payments,
> and now the balance of the channel is now 0 to Alice and 1 BTC to Bob,
> if Bob doesn't constantly watch the chain, he can lose money. If the
> HTLC-TIMEOUT is defined as 1 day, Alice can broadcast an old Commitment
> and then hope Bob isn't paying attention and steal some money. In
> effect, the maximum time between watching the chain will be the minimum
> HTLC-TIMEOUT throughout the life of the channel when the channel balance
> is currently tiled heavily in one direction.

HTLC-TIMEOUT is an absolute time/block, not relative.  Thus
OP_CHECKLOCKTIMEVERIFY is a noop for old HTLCs.

So, if A broadcasts, they need to wait <DELAY> to spend.  I don't think
I added anything new here?

> 2. Probably at the minimum doubles the HTLC timelock on LN payments. If
> there is a minimum amount of time to wait to redeem funds (or receive a
> refund), then the HTLC timeout must give you sufficient amount of time
> to redeem as well. I suspect the amount of time necessary is about the
> same since they're both dependent upon the estimated amount of time to
> enter into the blockchain. If that's the case, doubling the HTLC
> timeouts has some implications since it'll result in higher fees as a
> downside, but might bias towards less graph centralization as well.

Yes, the effective minimum HTLC-TIMEOUT is "current-time + <DELAY>",
because if A broadcasts its commitment tx, the HTLC stays redeemable
until A spends it (which it can't do until after <DELAY>).

But it's not clear that this "htlc timeout doubling" applies to every
step on the route, it seems to just add one?

Or am I missing something else?

Cheers,
Rusty.