Allow specifying a fee rate for channel-open funding transactions

[kaloudis]

Motivation

Wallet UIs commonly collect a sat/vB fee rate in their channel-open flow, but LDK Node offers no way to apply it: the funding transaction is always built at the internal estimator's ChannelFunding rate. #176 added exactly this kind of override for the on-chain send APIs; this PR extends the same pattern to channel opens.

Surveying ldk-node integrators: Zeus collects an open-channel fee rate in its UI and had to carry this as a downstream fork patch (ZeusLN#6, adapted here to current main), and Alby Hub and Bitkit currently have no way to offer the option at all through ldk-node's API.

Changes

All Node::open_channel variants (open_channel, open_announced_channel, the _with_all and _0reserve variants) gain a trailing Option<FeeRate> (FeeRate? in bindings):

• open_channel_inner stashes the rate in a new pending_funding_fee_rates: Mutex<HashMap<u128, FeeRate>> keyed by user_channel_id once create_channel succeeds
• the FundingGenerationReady handler removes the entry and passes it to Wallet::create_funding_transaction, which now takes Option<FeeRate> and falls back to the estimator when None (same shape as send_to_address)
• for FundingAmount::Max the override also feeds get_max_funding_amount, so the maximum amount is computed at the rate the funding transaction will actually pay
• ChannelClosed clears any still-pending entry, so state stashed for a channel that is rejected or dies before funding does not leak

When the parameter is unset, behavior is byte-for-byte unchanged.

This is a breaking signature change on the six open methods; a Feature and API updates CHANGELOG entry is included, and all internal call sites (tests, doctest) are updated.

Testing

• cargo check, cargo check --features uniffi, and cargo check --tests pass
• cargo test --lib (196 tests) and cargo test --doc pass
• cargo fmt --all -- --check clean

An earlier version of this change (against the 0.7 API) is what Zeus ships; it has unit coverage on the wallet side and device testing pending there.

Disclosure

This change was developed with the assistance of an AI coding tool (Claude Code), per the repository's contribution guidelines.

[ldk-reviews-bot]

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tnull]

Hmm, I'm honestly not convinced we should do this as it kind of introduces additional footguns that might be more easily to hit in comparison to the onchain send cases.

Do you really expose manual fee rate setting to the user? Can you explain why a user wants to set a specific manual fee rate override? Would having more general fee estimator profiles would make more sense (allowing to specify 'economical' vs. 'fast confirmation' or similar)?

[kaloudis]

Hmm, I'm honestly not convinced we should do this as it kind of introduces additional footguns that might be more easily to hit in comparison to the onchain send cases.

Do you really expose manual fee rate setting to the user? Can you explain why a user wants to set a specific manual fee rate override? Would having more general fee estimator profiles would make more sense (allowing to specify 'economical' vs. 'fast confirmation' or similar)?

Yes, we've supported manual fee rates for on-chain sends and channel operations since the early days of ZEUS. We've defaulted to using recommendations from our Mempool.space/Esplora instances but some users want more granular controls, especially in higher fee rate environments.

[tnull]

Yes, we've supported manual fee rates for on-chain sends and channel operations since the early days of ZEUS. We've defaulted to using recommendations from our Mempool.space/Esplora instances but some users want more granular controls, especially in higher fee rate environments.

Alright, honestly don't quite buy the argument for mobile (or rather think that if it just were for mobile we could find a better API than raw fee rates), but I do buy it for LDK Server users. So fine by me to move forward with this.

CI is currently failing though, could you also adjus the Python/Kotlin tests for the new API?