Pierre [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-24 📝 Original message: Hi Mats, I am not sure I ...

📅 Original date posted:2015-09-24
📝 Original message:
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