channel_update delayed on 0conf

[TheBlueMatt]

T-hast said this about eclair 0conf compat tests:

Thanks, that was easy enough. My cross-compat tests worked, we can ship this ;)
I've found one issue on the LDK side though: when LDK opens a 0-conf channel, it doesn't send its channel_update so the other side cannot create routing hints to actually benefit from the 0-conf. It looks like lnd has the same issue, I reported it to them as well.

[tnull]

Not sure, but couldn't this be fixed by extending the special case of sending ChannelUpdates for unannounced channels upon receipt of the counterparty's ChannelReady to include cases where we already sent our ChannelReady, i.e., simply setting the condition in this line to chan.get().is_usable() || chan.get().is_our_channel_ready()?

[TheBlueMatt]

Hmmmmm, is_usable should be true after we receive our counterparty's channel_ready for a 0conf, so I think looking at the code that we don't have an issue if the counterparty sends their channel_ready after us (which should always be the case for 0conf?) It may be that we need to extend send_channel_ready!() to also send the channel_update, but I'm actually a bit confused by this. Do you have log fragments from the LDK side @t-bast?

[tnull]

Hmmmmm, is_usable should be true after we receive our counterparty's channel_ready for a 0conf, so I think looking at the code that we don't have an issue if the counterparty sends their channel_ready after us

Yes, that's what I'm seeing, too.

(which should always be the case for 0conf?)

Could you elaborate why we can trust on this being the case? Wouldn't we still only send our channel_ready first, if we opened the channel?

[t-bast]

Sorry guys, I just tested again, and the issue was on my side, I had a patched eclair to downgrade to option_static_remotekey instead of anchor_outputs to test against LDK, and it was missing part of the 0-conf invoice generation code...

I do see a valid channel_update being sent by LDK after we exchange channel_ready, so we're all good!