From rusty at rustcorp.com.au Thu Jul 30 02:33:21 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Thu, 30 Jul 2015 12:03:21 +0930 Subject: [Lightning-dev] Breach of contract? In-Reply-To: <20150729195006.GA27670@lightning.network> References: <87k2tmpdvl.fsf@rustcorp.com.au> <20150727193714.GA16768@lightning.network> <874mkpoyde.fsf@rustcorp.com.au> <20150729195006.GA27670@lightning.network> Message-ID: <87pp3anzm6.fsf@rustcorp.com.au> Joseph Poon 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 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 + ", because if A broadcasts its commitment tx, the HTLC stays redeemable until A spends it (which it can't do until after ). 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.