[Lightning-dev] Breach of contract?

Joseph Poon joseph at lightning.network
Wed Jul 29 19:50:06 UTC 2015


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.

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.

Fundamentally, the cause is derived from the fact that the HTLC timeout
and the OP_CSV revocation are inextricably linked.

Number 1 is more relevant to me (IMO), which is why I brought up the
reserve thing. I'm not so into the reserve balance concept, simply
because it severely limits the amount of transactional flow available at
once (it also limits the number of retries/multiplexing sends), which
matters more for liquidity providers (that model can reduce available
liquidity by 4x in best-case scenarios).

-- 
Joseph Poon


More information about the Lightning-dev mailing list