📅 Original date posted:2021-05-24
📝 Original message:
Hey Z,
Thanks for your analysis. I agree with your conclusion. I think the most
practical approach is the "ask first" 3 round protocol.
Another option is to have `remote_penaltyclaimpubkey` owned by the node
instead of the hardware device.
This allows funds to accrue in the fast forward state which can be swept
into the commit tx at the merchants discretion.
If a fast forward state needs to be asserted on-chain it can then be done
automatically without the hardware device.
Of course, the funds in the FF state are more vulnerable than the main
channel balance during that time because their keys are not in a secure
device but this seems ok.
The obvious analogy is to having cash in the till (less secure) that you
send to your bank (more secure™) at the end of the day or week.
> We ***need*** privkeys to be periodically online more often than
`to_self_delay` anyway, ***in case of theft attempts***.
> So this is not an ***additional*** requirement at least.
This is a really important point. I guess you have to actually do this
periodically, only when there is an actual attempt at theft. Quite annoying
to UX to require this.
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210524/98ec9903/attachment.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 13:02:29
in reply to nevent1q…st3q
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 13:02:29Event JSON
{
"id": "c0e66ed6262cb5816a85dbea7bc07580bf275972ddf53b40413270d507fc4c97",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315749,
"kind": 1,
"tags": [
[
"e",
"06e34eda5a8a0c7de05c6d7fb765c1b1b6244f4127232ba197792f82a60b593c",
"",
"root"
],
[
"e",
"70c9b3571c0ded08721c84a0d8e744afb36d42667109863cf97235a7d254432b",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2021-05-24\n📝 Original message:\nHey Z,\n\nThanks for your analysis. I agree with your conclusion. I think the most\npractical approach is the \"ask first\" 3 round protocol.\n\nAnother option is to have `remote_penaltyclaimpubkey` owned by the node\ninstead of the hardware device.\nThis allows funds to accrue in the fast forward state which can be swept\ninto the commit tx at the merchants discretion.\nIf a fast forward state needs to be asserted on-chain it can then be done\nautomatically without the hardware device.\nOf course, the funds in the FF state are more vulnerable than the main\nchannel balance during that time because their keys are not in a secure\ndevice but this seems ok.\nThe obvious analogy is to having cash in the till (less secure) that you\nsend to your bank (more secure™) at the end of the day or week.\n\n\u003e We ***need*** privkeys to be periodically online more often than\n`to_self_delay` anyway, ***in case of theft attempts***.\n\u003e So this is not an ***additional*** requirement at least.\n\nThis is a really important point. I guess you have to actually do this\nperiodically, only when there is an actual attempt at theft. Quite annoying\nto UX to require this.\n\nCheers,\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210524/98ec9903/attachment.html\u003e",
"sig": "b26c4777757533d39abef686e435fccb76431bafcf19eabf3fe980083b39e5d9aa63f4ece0be87903eb5d97551553053ce6dc0d5f815d687099fac6bcee6035c"
}