📅 Original date posted:2015-11-24
📝 Original message:
While working on the payment layer and messing around with timeouts /
timeframes for CSV and CLTV, I noticed a few things...
(1)
It is indeed not possible for HTLCs to have a long revocation time and
a short refund time. And it makes sense the way we designed the
scripts and the commit transaction. As it's a single output, we either
can prevent the other side from doing ANYTHING for the revocation
timeout T1, or the other party is able to claim the complete output
without any encumbering... In long chains of multiple hops, I might
need R to settle the payment normally, while you still wait out the
revocation timeout before you can reveal R...
I described that some time ago, but was unsure if I was right
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-September/000182.html
(2)
As revocation-time and refund time are equal, we have some problematic
race conditions, where both parties can technically claim the payment,
depending on propagation time of the transaction. Further, if you
claim the payment that I was actually entitled to per refund, I may be
out of luck getting my money back on the next hop...
(3)
As the absolute CLTV timeout has to increase with each hop, it can
give us insight about our position within the route, even with onion
routing. It is possible to have the sender add some delay, but this
just increases the (already long) total refund time.
I played with the numbers back and forth, but I don't really see any
way out of this problem. Anything below one day might be dangerous
already for DDoS attacks, with 20 hops we might end up with 30-40 days
for a refund though...
If we go back to the original design, we are able to separate
'claiming-a-payment-using-R' and 'revoke-an-output' into two layers
and such, we can enforce revealing R within a separate timeframe than
the revocation timeframe. To do this, we need either SIGHASH_NOINPUT
or SW, as we can't construct the transaction on top of the 'reveal-R'
transaction without knowing R currently. Short refund timeouts would
also mitigate the problems of (3)
I would really love to stick with the current design, as not having to
keep another set of signatures makes everything easier ...
Cheers
Mats
Mats Jerratsch [ARCHIVE] /
npub1hz…q5x8w
2023-06-09 12:45:13
in reply to nevent1q…acdj
Author Public Key
npub1hz386xq4qszumlx5fsxa3kuxpaf8qvfrqqjg8zdl2l892hrcg55q6q5x8wPublished at
2023-06-09 12:45:13Event JSON
{
"id": "f3373ecaaa8e6c61e727e846667a581274a56e0784839788f077704b0ace8b90",
"pubkey": "b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528",
"created_at": 1686314713,
"kind": 1,
"tags": [
[
"e",
"736dfb86ab78326fcc1e394bf47470bcf73f1ab13d3a1b7b50e205d771436d9e",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2015-11-24\n📝 Original message:\nWhile working on the payment layer and messing around with timeouts /\ntimeframes for CSV and CLTV, I noticed a few things...\n\n(1)\nIt is indeed not possible for HTLCs to have a long revocation time and\na short refund time. And it makes sense the way we designed the\nscripts and the commit transaction. As it's a single output, we either\ncan prevent the other side from doing ANYTHING for the revocation\ntimeout T1, or the other party is able to claim the complete output\nwithout any encumbering... In long chains of multiple hops, I might\nneed R to settle the payment normally, while you still wait out the\nrevocation timeout before you can reveal R...\n\nI described that some time ago, but was unsure if I was right\nhttp://lists.linuxfoundation.org/pipermail/lightning-dev/2015-September/000182.html\n\n(2)\nAs revocation-time and refund time are equal, we have some problematic\nrace conditions, where both parties can technically claim the payment,\ndepending on propagation time of the transaction. Further, if you\nclaim the payment that I was actually entitled to per refund, I may be\nout of luck getting my money back on the next hop...\n\n(3)\nAs the absolute CLTV timeout has to increase with each hop, it can\ngive us insight about our position within the route, even with onion\nrouting. It is possible to have the sender add some delay, but this\njust increases the (already long) total refund time.\n\nI played with the numbers back and forth, but I don't really see any\nway out of this problem. Anything below one day might be dangerous\nalready for DDoS attacks, with 20 hops we might end up with 30-40 days\nfor a refund though...\n\nIf we go back to the original design, we are able to separate\n'claiming-a-payment-using-R' and 'revoke-an-output' into two layers\nand such, we can enforce revealing R within a separate timeframe than\nthe revocation timeframe. To do this, we need either SIGHASH_NOINPUT\nor SW, as we can't construct the transaction on top of the 'reveal-R'\ntransaction without knowing R currently. Short refund timeouts would\nalso mitigate the problems of (3)\n\nI would really love to stick with the current design, as not having to\nkeep another set of signatures makes everything easier ...\n\nCheers\nMats",
"sig": "42b16cb67a5b1daf843d6447a7edca02eaf9a5a5e9e317dc630aff0611a67705efe4de53ab8de93120ded22b0378f10db40bae66eda39a5d708e1d9fc14c7bd2"
}