Mats Jerratsch [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-24 📝 Original message: Hey Pierre, I was mainly ...

📅 Original date posted:2015-09-24
📝 Original message:
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 <pm+lists at acinq.fr>:
> 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