From ZmnSCPxj at protonmail.com  Fri Jan  4 03:43:14 2019
From: ZmnSCPxj at protonmail.com (ZmnSCPxj)
Date: Fri, 04 Jan 2019 03:43:14 +0000
Subject: [Lightning-dev] Quick analysis of channel_update data
In-Reply-To: <CAL3Hpbcw-1-UEpKi36Cs1-V+b+oZn6+QRfo2EHUYZMZGC1wb8A@mail.gmail.com>
References: <CAL3HpbeYjJtXaj4RXdyqdNZMQLniayocuSiP67F5sFGe6WPR0Q@mail.gmail.com>
	<87ef9veztc.fsf@gmail.com>
	<CAL3Hpbdp9c2qF3Z40jU0peTm1h_SqaU7HOYUaGzypXRjT3AzzA@mail.gmail.com>
	<CAL3Hpbcw-1-UEpKi36Cs1-V+b+oZn6+QRfo2EHUYZMZGC1wb8A@mail.gmail.com>
Message-ID: <Kjbzsn5nWZ9OwQ9l7OrffcoK3l_uxqkFlugw15sTV_qcl0Mtdw2-BRz9nbkXtQA549MG5rZoggYtHqEhy4SaNpR2074iEQ0FYuXOf_c3Q34=@protonmail.com>

Good morning,

> -   in set reconciliation schemes: we could reconcile [channel id |
>     timestamp | checksum] first

Perhaps I misunderstand how set reconciliation works, but --- if timestamp is changed while checksum is not, then it would still be seen as a set difference and still require further communication rounds to discover that the channel parameters have not actually changed.

Perhaps it is better to reconcile [channel_id | checksum] instead, and if there is a different set of channel parameters, share the set difference and sort out which timestamp is later at that point.

Regards,
ZmnSCPxj