[bug]: Failure to reject `open_channel` with zero `feerate_per_kw`

[NishantBansal2003]

BOLT 2 requires the receiver of open_channel to reject a feerate that is too low:

The receiving node MUST fail the channel if:

• channel_type does not include zero_fee_commitments and:
  • it considers feerate_per_kw too small for timely processing or unreasonably large.

LND does not enforce the lower bound (nor does it enforce the upper bound, see #11149, which is already open). As a result, LND accepts feerate_per_kw = 0.

Impact

A peer can open a channel to an LND node with feerate_per_kw = 0. LND accepts it, resulting in a commitment transaction with zero fee.

• The LND cannot force-close. bitcoind rejects the commitment transaction with min relay fee not met, leaving the LND's funds locked.

• The channel cannot be used. LND already enforces FeePerKwFloor (253 sat/kw) when validating commitment updates in validateCommitmentSanity, rejecting operations (including update_fee(f) where f < 253) below this feerate. As a result, no HTLCs can be added or routed over the channel.

With push_msat = 0, the LND has no balance at risk. With a non-zero push_msat, the LND's funds are locked and cannot be recovered unilaterally. The opener's funds are also locked, so the main issue is that the LND needs the other party's cooperation to close the channel and recover their funds.

Suggested Fix

Reject open_channel when feerate_per_kw < chainfee.FeePerKwFloor. Other implementations already enforce a 253 sat/kw floor when accepting open_channel:

• LDK defines FEERATE_FLOOR_SATS_PER_KW = 253, which is applied when accepting open_channel in new_for_inbound_channel.
• CLN defines FEERATE_FLOOR 253, which is applied when accepting open_channel in fundee_channel.
• Eclair defines MinimumFeeratePerKw = 253 sat, which is applied when accepting open_channel in validateParamsSingleFundedFundee.

Discovery

Found while fuzzing the v1 funding protocol with smite.

[GeorgeTsagk]

Thanks for the report, confirmed. The fundee path builds the initial commitment straight from the peer's feerate_per_kw and the 253 sat/kw floor is only checked in the state update path, so the channel opens and then every update fails locally. Since we don't do package relay the anchor CPFP doesn't help either, the zero fee commitment never enters the mempool.

Impact is bounded to push_msat and the channel slot, none of the acceptor's own funds enter the channel, so treating this as a griefing bug rather than a fund loss one. Fix is a check in fundeeProcessOpenChannel against chainfee.FeePerKwFloor, skipped for the zero fee commitments channel type. Makes sense to land it alongside #11151 which covers the upper bound.

[TayfurYldz]

I can take the lower-bound side of this. I’ll first add a focused fundee regression for a below-floor inbound open, keep the zero-fee-commitments exemption explicit, and avoid overlapping #11151’s upper-bound work.

[Roasbeef]

With push_msat = 0, the LND has no balance at risk. With a non-zero push_msat, the LND's funds are locked and cannot be recovered unilaterally. The opener's funds are also locked, so the main issue is that the LND needs the other party's cooperation to close the channel and recover their funds.

Yeah so in single funder, if a party actually does broadcast something that isn't mineable, it's their issue. Even with push amount, a channel isn't real until its confirmed. The inputs might not even exist (single funder doesn't verify that and just waits on a confirmation).

[morehouse]

Yeah so in single funder, if a party actually does broadcast something that isn't mineable, it's their issue. Even with push amount, a channel isn't real until its confirmed. The inputs might not even exist (single funder doesn't verify that and just waits on a confirmation).

I think you're confusing the funding and commitment transactions. feerate_per_kw gives the feerate for the initial commitment transaction. So the channel opens successfully (funding tx confirms on chain) but then can't be force closed unless the opener later sends update_fee to increase the commitment feerate.