đ
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
Pierre [ARCHIVE] /
npub1yzâŚy4pdt
2023-06-09 12:44:39
in reply to nevent1qâŚg40t
Author Public Key
npub1yz88535e0ydqye9q9x8l5cz9d3g6ervfjgyk5xm88zvktmxvstlsuy4pdtPublished at
2023-06-09 12:44:39Event JSON
{
"id": "909eab2bfba2289f3995bf9506aa437842cb1cd419e67bbe7c9c2548f06bf262",
"pubkey": "208e7a4699791a0264a0298ffa60456c51ac8d8992096a1b67389965eccc82ff",
"created_at": 1686314679,
"kind": 1,
"tags": [
[
"e",
"b5b57978740a799524f789c978ceee5f2bde61143922af5930a7f8658ef6ef76",
"",
"root"
],
[
"e",
"6fb5371a1c42b55725aca017adb7c0f0c1e39a4458ef84e25e198eb240e68984",
"",
"reply"
],
[
"p",
"ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211"
]
],
"content": "đ
Original date posted:2015-09-24\nđ Original message:\nHi Mats,\n\nI am not sure I understand what you meant, so forgive me if my answer\nis a bit off topic.\n\nLet's consider A-\u003eB-\u003eC-\u003eD-\u003eE.\n\nThe way lightning works is that A does *not* pay B, instead it locks\nthe corresponding funds in a contract that can end up two ways :\n1) B provides a secret R which means E got the funds, and the contract\nis fulfilled.\n2) a timeout occurs in which case the contract is voided. So there is\nno refund because the payment never actually took place.\n\nBut what you might have meant is that you are aware how this works,\nbut you still want a way for A to cancel the contract before the\ntimeout, in case A and E cooperate and C is unresponsive.\n\nI would say this is a bit contradictory because when A signed the\ninitial contract, it basically acknowledged the fact that it is\nwilling to take the risk to have its funds locked for at most $timeout\nif things go bad, right ? This is the essence of lightning after all.\n\nThat been said, I see two ways for A to reduce the timeout :\n- either find a shorter path (maybe even A-\u003eE)\n- or convince B/C/D to use small timeouts, maybe just a few blocks\nbetween each node. That would reduce A's timeout to a few hours, and I\ndon't see why that wouldn't work. This might be the real answer to\nyour problem, but I am certainly missing something!\n\nNow that I think of it, I actually don't know why the default timeout\nis 1 day on the original lightning presentation, that seems really\nhigh.\n\nCheers,\n\nPierre",
"sig": "a5a2e652c087999c56f22fc70e54e2a7d813b00bbca36a74a6c90c4c23ca784ae455c015a3c23013ffbbab9c5d5252146a1ae4af9ce8811c4ced4bfabe9f628b"
}