📅 Original date posted:2021-05-03
📝 Original message:
On Mon, 3 May 2021 at 22:58, David A. Harding <dave at dtrt.org> wrote:
> On Mon, May 03, 2021 at 11:01:48AM +1000, Lloyd Fournier wrote:
> > 2. It is not easy to figure out whether it worked or not
>
> Good point.
>
> > 3. This is incompatible with covert recovery schemes like in [1] [...]
> > (3) is also a problem with just doing encrypted backups -- going around
> > looking for backups means you tell everyone that you are in recovery
> mode.
>
> Eh, I assume nodes using the backup commons would, each time they're
> restarted, go through the steps of downloading some number of backups
> even if they haven't lost any data. This tests that the backups are
> being stored faithfully (essential to any backup process) and provides
> cover for cases where a node does lose data.
>
Ok this is a fun idea and hadn't thought of it like that before. Here are
the thoughts that come to mind:
1. Each time you start up your node you backup you go around to different
nodes -- but the obvious question is *which* nodes do you go to? You could
try and do something like rendezvous hashing [1] to reduce the set (with
some secret data as input so it is not predictable to anyone but yourself) .
2. What do you backup? Full-channel state or just a channel list? Even if
you have mostly honest backup nodes you need to make sure you delete old
states from your remote backups before revoking them if you do full
backups. This slows down sending payments but it might be worth it for
users like myself. So perhaps it's still better to avoid full backups here.
[1] https://en.wikipedia.org/wiki/Rendezvous_hashing
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210504/dec95c85/attachment.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 13:02:25
in reply to nevent1q…xcpp
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 13:02:25Event JSON
{
"id": "3889126101f7e42426459207501654be6410e3c77bdba748c81d0012356d1328",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315745,
"kind": 1,
"tags": [
[
"e",
"cf0209e285b65597d953bb5b8d3ccbf432a41374faf3f29d2e3020153d4f9b3a",
"",
"root"
],
[
"e",
"567a77b509352f5a986ca7b3aa12e48d1ca30d1846d770a5c530516c5beed703",
"",
"reply"
],
[
"p",
"d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2"
]
],
"content": "📅 Original date posted:2021-05-03\n📝 Original message:\nOn Mon, 3 May 2021 at 22:58, David A. Harding \u003cdave at dtrt.org\u003e wrote:\n\n\u003e On Mon, May 03, 2021 at 11:01:48AM +1000, Lloyd Fournier wrote:\n\u003e \u003e 2. It is not easy to figure out whether it worked or not\n\u003e\n\u003e Good point.\n\u003e\n\u003e \u003e 3. This is incompatible with covert recovery schemes like in [1] [...]\n\u003e \u003e (3) is also a problem with just doing encrypted backups -- going around\n\u003e \u003e looking for backups means you tell everyone that you are in recovery\n\u003e mode.\n\u003e\n\u003e Eh, I assume nodes using the backup commons would, each time they're\n\u003e restarted, go through the steps of downloading some number of backups\n\u003e even if they haven't lost any data. This tests that the backups are\n\u003e being stored faithfully (essential to any backup process) and provides\n\u003e cover for cases where a node does lose data.\n\u003e\n\nOk this is a fun idea and hadn't thought of it like that before. Here are\nthe thoughts that come to mind:\n\n1. Each time you start up your node you backup you go around to different\nnodes -- but the obvious question is *which* nodes do you go to? You could\ntry and do something like rendezvous hashing [1] to reduce the set (with\nsome secret data as input so it is not predictable to anyone but yourself) .\n2. What do you backup? Full-channel state or just a channel list? Even if\nyou have mostly honest backup nodes you need to make sure you delete old\nstates from your remote backups before revoking them if you do full\nbackups. This slows down sending payments but it might be worth it for\nusers like myself. So perhaps it's still better to avoid full backups here.\n\n[1] https://en.wikipedia.org/wiki/Rendezvous_hashing\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210504/dec95c85/attachment.html\u003e",
"sig": "091bb024d1473bff9585c73b14a57c1a6fb6927f1fb358abf1f8282637a03e0985bd4c5b192ac7a25e448b543ed619b3a8622dd31a283124f6c5be331ed50892"
}