Matt Corallo

This seems like a very misguided feature. Normalizing identities tied to lightning nodes is incredibly problematic and may lead more to the idea that they are counterparties instead of just...

I don't really understand why this is a (material) concern. If A is gonna send a new closing_signed, A should handle this. If you don't want to handle it, disconnect...

Its optional primarily for backwards compatibility reasons - warnings were not merged when the new closing stuff was merged. I think we could just switch it to MUST (which, actually,...

Yes, lightning implementations need to specifically check if the funding transaction is a coinbase, and in that case need to delay channel_ready until 100 blocks have passed.

> the receiving peer knows that they shouldn't wait for a corresponding channel_announcement to be validated against the blockchain What does this mean? You should never "wait" for a channel_announcement...

> Sorry, this was poorly phrased. We validate channel_announcements asynchronously (since this requires calls to bitcoind), so we can receive a valid channel_update while the channel_announcement is being validated, in...

> Granted, this is something we can live without. It's not so much about the optimization of one call to a lookup table, but rather the ability of strongly typing...

> Lnd uses a range of [16_000_000, 16_250_000] and if we receive a value in that range, we know it's an alias so it serves the same purpose as this...

> It's true, it isn't perfect, but it's already better than nothing, because it lets you immediately identify channel_updates for which you'll never need to validate a channel_announcement No? If...

> Do you mean that we should add the following message flags to make this more useful? Yes, that's my alternative proposal here.