From ZmnSCPxj at protonmail.com  Tue Feb 20 06:26:16 2018
From: ZmnSCPxj at protonmail.com (ZmnSCPxj)
Date: Tue, 20 Feb 2018 01:26:16 -0500
Subject: [Lightning-dev] Improving the initial gossip sync
In-Reply-To: <87606so4bd.fsf@rustcorp.com.au>
References: <874lmvy4gh.fsf@gmail.com> <87tvurym13.fsf@rustcorp.com.au>
	<87shaawft5.fsf@gmail.com> <878tbzugj0.fsf@rustcorp.com.au>
	<CAL3Hpbdr6LM-T9XcN6Bz-t74Zo6gDGbdt0k7fzieLfDBDH=tMA@mail.gmail.com>
	<87mv0cto38.fsf@rustcorp.com.au>
	<CAL3HpbcipCnJCtBPedLCchAHj4DnPJaVGqUNVdV=CJ=sRU4dOg@mail.gmail.com>
	<CAL3HpbcesFdkAJV_GDBe3UuwPyZYW2_1TC9asybPZnE+NtgRNg@mail.gmail.com>
	<87606so4bd.fsf@rustcorp.com.au>
Message-ID: <KIcyvA2KnBnurC_uV-L01Neucb158QdltqMXJ-mHyuCbsV0nBHlBqAouFDlQ3S9dpEkxsiOgPzMV9EuP-McbUH8Q87PE1G9DiVRNrqKqsAE=@protonmail.com>

Good morning Rusty,

?>4. query_short_channel_id
> =========================
>
>
>5. type: 260 (query_short_channel_id)
>
>6. data: 
> - [32:chain_hash]
>
> - [8:short_channel_id]
>
> This is general mechanism which lets you query for a
> channel_announcement and channel_updates for a specific 8-byte shortid.
> The receiver should respond with a channel_announce and the latest
> channel_update for each end, not batched in the normal 60-second gossip
> cycle.
>
> A node MAY send this if it receives a channel_update for a channel it
> has no channel_announcement, but SHOULD NOT if the channel referred to
> is not an unspent output (ie. check that it's not closed before sending
> this query!).

Is the SHOULD NOT something the sender can assure?  In the case that the sender is a lightweight Bitcoin node, and does not keep track of a mempool, and only notices closes if they have been confirmed onchain, it may be possible that the sender thinks the channel is still possibly open, while the receiver is a full Bitcoin node and has seen the closing transaction of the channel on the mempool.  There are also race conditions where the sender has not received a new block yet, then sends the message, and the receiver receives/processes the message after it has received a new block containing the closing transaction.

Perhaps there should also be a possible reply to this message which indicates "short_channel_id so-and-so was closed by txid so-and-so".

Or maybe receivers should not rely on this "SHOULD NOT" and will have to silently ignore `query_short_channel_id` that it thinks is closed; this also implies that the sender cannot rely on getting information on the specified channel from anyone, either.

Regards,
ZmnSCPxj