From rusty at rustcorp.com.au  Tue Jan  8 23:44:06 2019
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Wed, 09 Jan 2019 10:14:06 +1030
Subject: [Lightning-dev] Quick analysis of channel_update data
In-Reply-To: <CAL3Hpbd_Po7pBrTtnbC+Nq87Vf+Nppt2be9a-u7qexnnHOM9RQ@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>
	<875zuzg1tt.fsf@rustcorp.com.au> <871s5nfafb.fsf@gmail.com>
	<CAL3Hpbd_Po7pBrTtnbC+Nq87Vf+Nppt2be9a-u7qexnnHOM9RQ@mail.gmail.com>
Message-ID: <878szuemux.fsf@rustcorp.com.au>

Fabrice Drouin <fabrice.drouin at acinq.fr> writes:
> I think there may even be a simpler case where not replacing updates
> will result in nodes not knowing that a channel has been re-enabled:
> suppose you got 3 updates U1, U2, U3 for the same channel, U2 disables
> it, U3 enables it again and is the same as U1. If you discard it and
> just keep U1, and your peer has U2, how will you tell them that the
> channel has been enabled again ? Unless "discard" here means keep the
> update but don't broadcast it ?

This can only happen if you happen to lose connection to the peer(s)
which sent U2 before it sends U3.

Again, this corner case penalizes flapping channels.  If we also
ratelimit our own enables to 1 per 120 seconds, you won't hit this case?

> But then there's a risk that nodes would discard channels as stale
> because they don't get new updates when they reconnect.

You need to accept redundant updates after 1 week, I think.

Cheers,
Rusty.