Mats Jerratsch [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-03 📝 Original message: I just messed around, ...
📅 Original date posted:2015-09-03
📝 Original message:
I just messed around, thinking about reasonable timeframes for
payments and revocation. I ended up thinking that 7 days would be
okayish as the revocation timeframe for most usecases, as we also have
to think about the everyday users that are not online (or don't even
have access to their computer) for a couple of days..
I further think 1 day is plenty of time to reveal R. We really don't
want to give the receiver too much time to accept and clear the
payment. (It locks up funds for everyone else in the route..)
Considering these values with the HTLC Receiver Redeemscript
HTLC Receiver
OP_HASH160 OP_DUP
<R-HASH> OP_EQUAL
OP_IF
<7 DAYS> OP_CSV
OP_2DROP
<KEY-B>
OP_ELSE
<REVOKE-HASH> OP_EQUAL
OP_NOTIF
<8 DAYS> OP_CLTV OP_DROP
OP_ENDIF
<KEY-A>
OP_ENDIF
OP_CHECKSIG
So if A has REVOKE-PREIMAGE he can claim the payment anytime.
If B has R he has to wait 7 days until he can claim the output (and
reveal R doing so..)
Furthermore, if he has R and wants to clear the payment, he has to act
within one day. He has to either settle the payment with the other
party or broadcast the channel within this time.
If he broadcasts the channel within one day, B can claim the output,
but A has to wait for full 7 days until he learns R. However, A might
not be the original sender, but just one of the nodes on the route,
and if A does not provide R to the node before him within 2 days (we
have 1 day per hop), he cannot pull the funds, although B can pull
his. This means all nodes along the route has to broadcast their
channel in order to not lose money.
In conclusion the payment-timeout and the revoke-time must be the same
in this channel design (which is inconvenient I think..). While the
payment-timeout should be as short as possible, a long revoke-time is
healthy in many instances.. 1 or maybe 2 days will probably be the
optimal trade-off then, although this can also be dangerously short in
case of full blocks..
Any thoughts?
Published at
2023-06-09 12:44:22Event JSON
{
"id": "be7f429b6e4b75dc38f5862f6dfc669861f0eb79c1faa8f9021e19afe1013847",
"pubkey": "b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528",
"created_at": 1686314662,
"kind": 1,
"tags": [
[
"e",
"cee1342295cb9701818c4f17dcc73ef0fa5b106b713ea49fc4bc08455e4ad084",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2015-09-03\n📝 Original message:\nI just messed around, thinking about reasonable timeframes for\npayments and revocation. I ended up thinking that 7 days would be\nokayish as the revocation timeframe for most usecases, as we also have\nto think about the everyday users that are not online (or don't even\nhave access to their computer) for a couple of days..\n\nI further think 1 day is plenty of time to reveal R. We really don't\nwant to give the receiver too much time to accept and clear the\npayment. (It locks up funds for everyone else in the route..)\n\nConsidering these values with the HTLC Receiver Redeemscript\n\nHTLC Receiver\nOP_HASH160 OP_DUP\n\u003cR-HASH\u003e OP_EQUAL\nOP_IF\n \u003c7 DAYS\u003e OP_CSV\n OP_2DROP\n \u003cKEY-B\u003e\nOP_ELSE\n \u003cREVOKE-HASH\u003e OP_EQUAL\n OP_NOTIF\n \u003c8 DAYS\u003e OP_CLTV OP_DROP\n OP_ENDIF\n \u003cKEY-A\u003e\nOP_ENDIF\nOP_CHECKSIG\n\nSo if A has REVOKE-PREIMAGE he can claim the payment anytime.\nIf B has R he has to wait 7 days until he can claim the output (and\nreveal R doing so..)\nFurthermore, if he has R and wants to clear the payment, he has to act\nwithin one day. He has to either settle the payment with the other\nparty or broadcast the channel within this time.\n\nIf he broadcasts the channel within one day, B can claim the output,\nbut A has to wait for full 7 days until he learns R. However, A might\nnot be the original sender, but just one of the nodes on the route,\nand if A does not provide R to the node before him within 2 days (we\nhave 1 day per hop), he cannot pull the funds, although B can pull\nhis. This means all nodes along the route has to broadcast their\nchannel in order to not lose money.\n\nIn conclusion the payment-timeout and the revoke-time must be the same\nin this channel design (which is inconvenient I think..). While the\npayment-timeout should be as short as possible, a long revoke-time is\nhealthy in many instances.. 1 or maybe 2 days will probably be the\noptimal trade-off then, although this can also be dangerously short in\ncase of full blocks..\n\nAny thoughts?",
"sig": "8ae667209abf416947ab48dc328f9734639476145fa7385ca19f2b9a884cc417eda0ecfe710c79f5dfc3c0902bf2f92e802a2a35470974aaa307eb246105344e"
}