[c-lightning] Replicated backups

[ZmnSCPxj]

Good morning Christian,

> > > Edit: If you really want to continue here, I would suggest
> > > rather the creation of a `channel_state_update` hook that focuses on
> > > the only important DB update: revocation of old channel states. This
> > > removes a lot of the risk and complexity of using the DB
> > > statements. Then add a `restorechannel` command that requires the
> > > same information as `channel_state_update` provides, with some checks
> > > to ensure that we do not restore to a known-old channel state.
> >
> > Possibly you might also want a `getchannelstate` command that gives
> > the same information as `channel_state_update` hook -- for example,
> > after your plugin restarts, you might want to `getchannelstate` all
> > live channels. Attempting `restorechannel` on all channels we
> > currently hold would also be doable at startup of plugin. This may be
> > more useful than a remote backup of the entire database.
> > Of course, loss of invoice data is bad but presumably your shopping
> > cart software should also have a copy of any invoice it has issued
> > too.
>
> I'd really prefer the blacklisting approach here, since backing up more
> information than necessary is never a security issue, but missing some
> information that we didn't consider "important" is devastating.

I would argue that the issue is that database queries are too general and powerful, whereas a more focused approach gives us better analyzability.
One might compare database queries in this case to JavaScript, while more focused channelstates as akin to proper HTML.

For instance, if we want to eventually hook to a watchtower, I would strongly suspect that a `channel_update_hook` would be something we can use so that a plugin can connect and update channel state to watchtowers simply.
Certainly it would also be doable with SQL queries, but now you need to parse the SQL queries and you are now probably strongly coupled to the database format (which can impede us if we desire to change the database table schema in the future).

While I respect your desire to not lose any data, I also bring forward the issue that SQL queries are too powerful and we may need to focus on more specialized interfaces than simply the SQL queries without any proper structuring.
(I imagine also that any `db_upgrades` would have to be recorded by the plugin)

Regards,
ZmnSCPxj