Failure to reject `option_scid_alias` on an announced channel

[NishantBansal2003]

BOLT 2 forbids the sender of open_channel from setting the option_scid_alias bit in channel_type when announce_channel is true:

The sending node:

• if it includes open_channel_tlvs:
  • MUST set channel_type:
    • if announce_channel is true (not 0):
      • MUST NOT send channel_type with the option_scid_alias bit set.

CLN never generates this combination as opener, but it does not reject it on receipt: channel_type_accept() never sees channel_flags, so the fundee happily replies with accept_channel echoing back option_scid_alias on a channel it will then announce. The spec does not specify rules for the acceptor in this case, so accepting it is not itself a violation, but the resulting channel is internally inconsistent.

Impact

Both openingd and dualopend are affected. The effect is that both can exchange announcement_signatures and publicly announce the channel using its real short_channel_id. However, per BOLT, when the agreed channel type has option_scid_alias set, a node MUST NOT allow incoming HTLCs to that channel using the real short_channel_id. So if the peer returns its signatures, CLN ends up announcing a channel to the whole network and then refusing every HTLC (addressed to that short_channel_id) it is asked to forward to the peer, which only affects the peer.

Only forwards towards the peer are affected, inbound HTLCs still work. For CLN, this means gaining some bad reputation for unnecessarily failing HTLCs. Other than that, this is purely a spec-compliance issue.

Discovery

This bug was found while fuzzing the v1 funding protocol with smite.