Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2021-05-03 📝 Original message: On Mon, 3 May 2021 at ...
📅 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>;
📝 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>;