ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-02-20 📝 Original message: Good morning Rusty, ...

📅 Original date posted:2018-02-20
📝 Original message:
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