[c-lightning] Replicated backups

[Christian Decker]

ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:

> 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.

I agree that a journal of actual DB queries is likely not the best
format for the backup, but it's what we currently have and what will be
stable for the foreseeable future. The information we store about the
channels is currently evolving rather more quickly than we can specify
a backup format on every change.

The reason I like the DB queries is that they are future-proof, and we
can be reasonably sure that they'll work in a years time. In th meantime
we can experiment with more concise and targeted backup formats in
plugins by just having the plugin re-apply the queries to an in-memory
DB and then extracting the necessary information from there. I think
this is far better than trying to come up with a format that may not
work in a month, but which we'll have to support for backwards
compatibility reason.

So while not the end-all-be-all solution, I think the `db_write` hook
allows us to experiment, and try to come up with a better solution,
without having to encumber `lightningd` itself while doing so. Once we
have a stable and minimal backup interface that we'd like to support
natively we can backport that into `lightningd`/

> 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).

I would argue that it's part of the plugin's duty to convert the raw
data we present it with to a format that a watchtower can use. If there
are specific extra datapoints we can provide to the plugin that's always
possible of course. Also notice that watchtowers and backups are pretty
much orthogonal, and are unlikely to have the same requirements :-)

> 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)

Good point, `db_upgrades` need to be applied as well, I'm not sure they
are currently.

As to the power of SQL queries, I agree that they aren't an optimal
interface, but at the moment it's all we have, and we should start
experimenting with more advanced scheme, in plugins.

Cheers,
Christian