Append ChannelEvent on Channel Backup Subscriptions in LND's gRPC API

[bluebycode]

The implementation of the SubscribeChannelBackups API in LND's gRPC service provides valuable real-time updates on channel backups. However, it lacks granularity in specifying the type of event that triggered the backup change. As per the official documentation, the API sends a new set of channel backups whenever a channel is opened or closed. This is useful but needs to be more sufficient for particular use cases.

For instance, when a channel is opened or closed, two consecutive events are received with different byte representations of the backup but with the same list of channel points. This behavior can be detected in the codebase and debugging LND locally, specifically in the channel_notifier.go file. The "issue" or this particularity arises when distinguishing between these two events, as the byte representation is encrypted, and the list of channel points remains the same for both.

To address this, it would be beneficial to include an additional enumerator field in the ChanBackupSnapshot object returned by the subscription. This enumeration state could specify the type of event that triggered the backup change, such as 'PendingOpen,' 'Open', 'PendingClose', or 'Close'. By doing so, consumers of this API would have a clearer understanding of the channel state transitions, enabling more robust and informed decision-making processes.

Enhancing the API to include this additional information can provide a more comprehensive and user-friendly experience for developers interacting with LND's gRPC services.

Do you think this enhancement can be valuable ? Or as in most cases of use, persisting the backup object, getting the latest one, and then not looking backward...

[guggero]

I don't think that addition is needed. Since the information for a particular channel doesn't change during the lifetime of that channel (with the sole exception being if the peer announces a different public IP address), you can basically just run a diff on the channel points themselves. If the list of channel points doesn't change, then the content won't have changed either.
Maybe just do a full update once a day (even if channel points don't change) to account for the IP updates of peers.

[bluebycode]

Thanks for the reply. It makes sense, but I disagree with the differentiation of the channel points. Two events are received during the opening of a channel: a pending_open and open (we don't receive this state, but I figure out how they arrive consecutively). In both cases, the list of channel points is always the same, so running diff on them is unhelpful, but the representation in bytes differs; this is inconsistent, IMHO. That's why my concert here. In any case, we should stick with the latest update, but it would be consistent to know information about the event or status.

[guggero]

but the representation in bytes differs

What exactly do you mean by that? Can you show me an example of a diff (after decrypting of course, since the encryption adds a salt and therefore always produces different output even for the exact same input)?

[bluebycode]

..since the encryption adds a salt and therefore always produces different output even for the exact same input

Aham that's interesting, I can't confirm you as I did not try to decipher the bytes representation, but it sounds totally sense now to me. It could be explain a lot. However, Let' me sample it!