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
