Support `option_anchors_zero_fee_htlc_tx` feature 22/23

[JssDWt]

Issue and Steps to Reproduce

There is an incompatibility between LND and CLN currently. LND is unable to open a zero conf anchor channel to a CLN node, because LND sets the required feature option_anchors_zero_fee_htlc_tx, which CLN does not support.

Steps to reproduce:

• Spin up an LND node with --protocol.zero-conf and --protocol.option-scid-alias
• Spin up a CLN node with a zero conf accepting plugin
• Open a channel from LND to CLN with commitmenttype anchors and zero conf
• Feature negotation will fail, because CLN does not support option_anchors_zero_fee_htlc_tx

Since this is an interoperability issue, here's the issue in the LND repository: https://github.com/lightningnetwork/lnd/issues/7230

[chrisguida]

Closed by #6334 i think. I'm a bit confused though, what do zero conf channels have to do with option_anchors_zero_fee_htlc_tx?

[JssDWt]

I'm a bit confused though, what do zero conf channels have to do with option_anchors_zero_fee_htlc_tx?

Nothing from CLN's perspective. LND only allows opening zero conf channels with anchors. And anchors in LND have zero fee htlc tx. So it was not possible to open zero conf channels from LND to CLN. #6334 should fix this issue, yes.

[chrisguida]

Gotcha, thanks!

Maybe give it a test and then we can call this complete?

[JssDWt]

Maybe give it a test and then we can call this complete?

Currently getting You gave bad parameters: Did not support channel_type 12,22,50 when opening a zero conf channel from LND to CLN.

I guess the combination zero fee htlc tx + zero conf could be missing?

[chrisguida]

Did you enable experimental-anchors in your config?

[JssDWt]

Did you enable experimental-anchors in your config?

Yes

[chrisguida]

Hmm ok. I got nothing then, maybe you were right about this:

I guess the combination zero fee htlc tx + zero conf could be missing?

[JssDWt]

Hmm ok. I got nothing then, maybe you were right about this:

Yeah I think so. @cdecker said "It's likely just an entry in the default channel type table missing."

[chrisguida]

Is "You gave bad parameters: Did not support channel_type 12,22,50" an LND error or a CLN error?

Have you decoded your features hex string using ./devtools/features <hex>?

[cdecker]

So my initial comment seems to not apply, the table is not written out completely, rather we consider variants of the default types: https://github.com/ElementsProject/lightning/blob/c67f1f92a845dd067be310899eb99ca23a369989/common/channel_type.c#L165-L168

This code accepts the channel_type by blanking optional features and then checking for equality to one of our default variants.

The error originates from CLN:

https://github.com/ElementsProject/lightning/blob/c67f1f92a845dd067be310899eb99ca23a369989/openingd/openingd.c#L138

https://github.com/ElementsProject/lightning/blob/c67f1f92a845dd067be310899eb99ca23a369989/openingd/dualopend.c#L414

wrapping the inner error at

https://github.com/ElementsProject/lightning/blob/c67f1f92a845dd067be310899eb99ca23a369989/openingd/openingd.c#L976

https://github.com/ElementsProject/lightning/blob/c67f1f92a845dd067be310899eb99ca23a369989/openingd/dualopend.c#L2266

I wonder if we could build a repro test between CLN and CLN with this combination, because that should be the zeroconf variant we get when turning both of them on, right?

[cdecker]

Assigning myself as well in order to hunt down the zeroconf + zeroanchor failure.

[cdecker]

So it looks like we are setting channel_type=12,22, i.e., option_static_remotekey and option_anchors_zero_fee_htlc_tx, but not 50 (option_zeroconf) and also no 46 (option_scid_alias). These are rather pointless to signal anyway, since they can be trivially inferred from the behavior (we send an alias if we support it, and we send channel_ready as soon as we believe it is safe). The problem seems to be that lnd does signal 50, which we seem to not blank when comparing with our own type.

[JssDWt]

Closing this issue as completed. LND is now able to open zero conf channels with CLN.