On Mon, 3 May 2021 at 22:58, David A. Harding <d...@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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
