ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-05 📝 Original message: Good Morning Fabrice, ...
📅 Original date posted:2018-10-05
📝 Original message:
Good Morning Fabrice,
Without objecting to the rest of your email (which I have not read and thought about extensively):
>And it is not
> really a set reconciliation problem (like syncing channel
> announcements for example): we’re not missing items, we’re missing
> updates for existing items.
It may be reduced to a set reconciliation problem if we consider the timestamp and enable/disable state of channel updates as part of an item, i.e. a channel update of 111:1:1 at 2018-10-04 state=enabled is not the same as a channel update of 111:1:1 at 2018-10-05 state=disabled.
Then both sides can use standard set reconciliation algorithms, and for channel updates of the same short channel ID, we simply drop all items except the one with latest timestamp.
The above idea might be less efficient than your proposed extension.
Regards,
ZmnSCPxj
📝 Original message:
Good Morning Fabrice,
Without objecting to the rest of your email (which I have not read and thought about extensively):
>And it is not
> really a set reconciliation problem (like syncing channel
> announcements for example): we’re not missing items, we’re missing
> updates for existing items.
It may be reduced to a set reconciliation problem if we consider the timestamp and enable/disable state of channel updates as part of an item, i.e. a channel update of 111:1:1 at 2018-10-04 state=enabled is not the same as a channel update of 111:1:1 at 2018-10-05 state=disabled.
Then both sides can use standard set reconciliation algorithms, and for channel updates of the same short channel ID, we simply drop all items except the one with latest timestamp.
The above idea might be less efficient than your proposed extension.
Regards,
ZmnSCPxj