From joseph at lightning.network Wed Jul 29 19:50:06 2015 From: joseph at lightning.network (Joseph Poon) Date: Wed, 29 Jul 2015 12:50:06 -0700 Subject: [Lightning-dev] Breach of contract? In-Reply-To: <874mkpoyde.fsf@rustcorp.com.au> References: <87k2tmpdvl.fsf@rustcorp.com.au> <20150727193714.GA16768@lightning.network> <874mkpoyde.fsf@rustcorp.com.au> Message-ID: <20150729195006.GA27670@lightning.network> 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