On Thu, Feb 20, 2020 at 03:42:39AM +0000, ZmnSCPxj wrote: > A thought that arises here is, what happens if I have forwarded a payment, > then the outgoing channel is dropped onchain and that peer disconnects from > me? > > Since the onchain HTLC might have a timelock of, say, a few hundred blocks > from now, the outgoing peer can claim it up until the timelock. > If the peer does not claim it, I cannot claim it in my incoming as well. > I also cannot safely fail my incoming, as the outgoing peer can still claim > it until the timelock expires.
Suppose the channel state looks like: Bob's balance: $150 Carol's balance: $500 Bob to Carol: $50, hash X, timelock +2016 blocks The pre-signed close transaction will have already deducted maybe $1 in fees, say 50c from each balance. At 5% pa, that's $50*0.05*2/52, so about 10 cents worth of "holding" fees, so that seems like it's worth just committing to up-front, ie: Bob's balance: $149.60 (-.50+.10) Carol's balance: $499.40 (-.50-.10) Bob to Carol: $50, hash X, timelock +2016 blocks Fees: $1 And that seems necessary anyway: if the channel does drop to the chain, then the HTLC can't be cancelled, so if it never confirms, Bob will have had to pay, say, 9.5c to Alice waiting for the timeout, and can then immediately cancel the HTLC with Alice allowing it to finish unwinding. So I think the idea would be not to accept a (rate, amount, timelock) tuple for an incoming HTLC unless the rate*amount*timelock product is substantially less than what you're putting towards the blockchain fees anyway, as otherwise you've got bad incentives for the other guy to drop to the chain. Note the rate increases with number of hops, so if it's 1% pa per hop, the 11th peer will be emitting 10% pa. I think that's probably okay, because BTC's deflationary nature probably means you don't need to earn much interest on it, and you can naturally choose the rate dynamically based on how many HTLCs you currently have open and how much of your channel funds are being used up by the HTLC? Also, you'd presumably update your channel state every hundred blocks, reducing the 10c by half a cent or so each time, so you could have your risk reduce. Maybe there could be some way of bumping the timelock across a HTLC path so that the risk is capped, but if the HTLC is still being paid for it doesn't have to be cancelled? Cheers, aj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
