From matsjj at gmail.com Thu Sep 24 13:24:58 2015 From: matsjj at gmail.com (Mats Jerratsch) Date: Thu, 24 Sep 2015 14:24:58 +0100 Subject: [Lightning-dev] Payment and Refund Stuck In-Reply-To: References: Message-ID: Hey Pierre, I was mainly talking about the case where one node in the chain does not relay the payment to the next node. So this is mainly about recovering, such that we can finish the payment without waiting for the timeout (which would piss off users so much). And this is possible in general. I feel I was either very unclear or you should reread my post again, as you just talk about timeouts (which is more of a layer-0 variable than a layer-1 mitigating technique). I have discussed in http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-September/000182.html that the revocation time and timeout time must be identical. I'm still not sure if I am missing something, but it does seem logical. It is the one drawback we have from having all outputs directly to the parties, instead of spending them to another set of multisig addresses. Indeed, one day payment timeout is a lot, but one day revocation time is quite low, as it means all parties has to check the blockchain at least once a day, every day... Cheers, Mats 2015-09-24 13:13 GMT+01:00 Pierre : > Hi Mats, > > I am not sure I understand what you meant, so forgive me if my answer > is a bit off topic. > > Let's consider A->B->C->D->E. > > The way lightning works is that A does *not* pay B, instead it locks > the corresponding funds in a contract that can end up two ways : > 1) B provides a secret R which means E got the funds, and the contract > is fulfilled. > 2) a timeout occurs in which case the contract is voided. So there is > no refund because the payment never actually took place. > > But what you might have meant is that you are aware how this works, > but you still want a way for A to cancel the contract before the > timeout, in case A and E cooperate and C is unresponsive. > > I would say this is a bit contradictory because when A signed the > initial contract, it basically acknowledged the fact that it is > willing to take the risk to have its funds locked for at most $timeout > if things go bad, right ? This is the essence of lightning after all. > > That been said, I see two ways for A to reduce the timeout : > - either find a shorter path (maybe even A->E) > - or convince B/C/D to use small timeouts, maybe just a few blocks > between each node. That would reduce A's timeout to a few hours, and I > don't see why that wouldn't work. This might be the real answer to > your problem, but I am certainly missing something! > > Now that I think of it, I actually don't know why the default timeout > is 1 day on the original lightning presentation, that seems really > high. > > Cheers, > > Pierre