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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to