+/// The Proportion of the channel value to configure as counterparty's channel reserve,
+/// i.e., `their_channel_reserve_satoshis` for both outbound and inbound channels.
+///
+/// `their_channel_reserve_satoshis` is the minimum balance that the other node has to maintain
+/// on their side, at all times.
+/// This ensures that if our counterparty broadcasts a revoked state, we can punish them by
+/// claiming at least this value on chain.
+///
+/// Channel reserve values greater than 30% could be considered highly unreasonable, since that
+/// amount can never be used for payments.
+/// Also, if our selected channel reserve for counterparty and counterparty's selected
+/// channel reserve for us sum up to equal or greater than channel value, channel negotiations
+/// will fail.
+///
+/// Note: Versions of LDK earlier than v0.0.104 will fail to read channels with any channel reserve
+/// other than the default value.
+///
+/// Default value: 1% of channel value, i.e., configured as 10,000 millionths.
+/// Minimum value: If the calculated proportional value is less than 1000 sats, it will be treated
+/// as 1000 sats instead, which is a safe implementation-specific lower bound.
+/// Maximum value: 1,000,000, any values larger than 1 Million will be treated as 1 Million (or 100%)
+/// instead, although channel negotiations will fail in that case.
+#[no_mangle]
+pub extern "C" fn ChannelHandshakeConfig_get_their_channel_reserve_proportional_millionths(this_ptr: &ChannelHandshakeConfig) -> u32 {
+ let mut inner_val = &mut this_ptr.get_native_mut_ref().their_channel_reserve_proportional_millionths;
+ *inner_val
+}
+/// The Proportion of the channel value to configure as counterparty's channel reserve,
+/// i.e., `their_channel_reserve_satoshis` for both outbound and inbound channels.
+///
+/// `their_channel_reserve_satoshis` is the minimum balance that the other node has to maintain
+/// on their side, at all times.
+/// This ensures that if our counterparty broadcasts a revoked state, we can punish them by
+/// claiming at least this value on chain.
+///
+/// Channel reserve values greater than 30% could be considered highly unreasonable, since that
+/// amount can never be used for payments.
+/// Also, if our selected channel reserve for counterparty and counterparty's selected
+/// channel reserve for us sum up to equal or greater than channel value, channel negotiations
+/// will fail.
+///
+/// Note: Versions of LDK earlier than v0.0.104 will fail to read channels with any channel reserve
+/// other than the default value.
+///
+/// Default value: 1% of channel value, i.e., configured as 10,000 millionths.
+/// Minimum value: If the calculated proportional value is less than 1000 sats, it will be treated
+/// as 1000 sats instead, which is a safe implementation-specific lower bound.
+/// Maximum value: 1,000,000, any values larger than 1 Million will be treated as 1 Million (or 100%)
+/// instead, although channel negotiations will fail in that case.
+#[no_mangle]
+pub extern "C" fn ChannelHandshakeConfig_set_their_channel_reserve_proportional_millionths(this_ptr: &mut ChannelHandshakeConfig, mut val: u32) {
+ unsafe { &mut *ObjOps::untweak_ptr(this_ptr.inner) }.their_channel_reserve_proportional_millionths = val;
+}
+/// If set, we attempt to negotiate the `anchors_zero_fee_htlc_tx`option for all future
+/// channels. This feature requires having a reserve of onchain funds readily available to bump
+/// transactions in the event of a channel force close to avoid the possibility of losing funds.
+///
+/// Note that if you wish accept inbound channels with anchor outputs, you must enable
+/// [`UserConfig::manually_accept_inbound_channels`] and manually accept them with
+/// [`ChannelManager::accept_inbound_channel`]. This is done to give you the chance to check
+/// whether your reserve of onchain funds is enough to cover the fees for all existing and new
+/// channels featuring anchor outputs in the event of a force close.
+///
+/// If this option is set, channels may be created that will not be readable by LDK versions
+/// prior to 0.0.116, causing [`ChannelManager`]'s read method to return a
+/// [`DecodeError::InvalidValue`].
+///
+/// Note that setting this to true does *not* prevent us from opening channels with
+/// counterparties that do not support the `anchors_zero_fee_htlc_tx` option; we will simply
+/// fall back to a `static_remote_key` channel.
+///
+/// LDK will not support the legacy `option_anchors` commitment version due to a discovered
+/// vulnerability after its deployment. For more context, see the [`SIGHASH_SINGLE + update_fee
+/// Considered Harmful`] mailing list post.
+///
+/// Default value: false. This value is likely to change to true in the future.
+///
+/// [`ChannelManager`]: crate::ln::channelmanager::ChannelManager
+/// [`ChannelManager::accept_inbound_channel`]: crate::ln::channelmanager::ChannelManager::accept_inbound_channel
+/// [`DecodeError::InvalidValue`]: crate::ln::msgs::DecodeError::InvalidValue
+/// [`SIGHASH_SINGLE + update_fee Considered Harmful`]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html
+#[no_mangle]
+pub extern "C" fn ChannelHandshakeConfig_get_negotiate_anchors_zero_fee_htlc_tx(this_ptr: &ChannelHandshakeConfig) -> bool {
+ let mut inner_val = &mut this_ptr.get_native_mut_ref().negotiate_anchors_zero_fee_htlc_tx;
+ *inner_val
+}
+/// If set, we attempt to negotiate the `anchors_zero_fee_htlc_tx`option for all future
+/// channels. This feature requires having a reserve of onchain funds readily available to bump
+/// transactions in the event of a channel force close to avoid the possibility of losing funds.
+///
+/// Note that if you wish accept inbound channels with anchor outputs, you must enable
+/// [`UserConfig::manually_accept_inbound_channels`] and manually accept them with
+/// [`ChannelManager::accept_inbound_channel`]. This is done to give you the chance to check
+/// whether your reserve of onchain funds is enough to cover the fees for all existing and new
+/// channels featuring anchor outputs in the event of a force close.
+///
+/// If this option is set, channels may be created that will not be readable by LDK versions
+/// prior to 0.0.116, causing [`ChannelManager`]'s read method to return a
+/// [`DecodeError::InvalidValue`].
+///
+/// Note that setting this to true does *not* prevent us from opening channels with
+/// counterparties that do not support the `anchors_zero_fee_htlc_tx` option; we will simply
+/// fall back to a `static_remote_key` channel.
+///
+/// LDK will not support the legacy `option_anchors` commitment version due to a discovered
+/// vulnerability after its deployment. For more context, see the [`SIGHASH_SINGLE + update_fee
+/// Considered Harmful`] mailing list post.
+///
+/// Default value: false. This value is likely to change to true in the future.
+///
+/// [`ChannelManager`]: crate::ln::channelmanager::ChannelManager
+/// [`ChannelManager::accept_inbound_channel`]: crate::ln::channelmanager::ChannelManager::accept_inbound_channel
+/// [`DecodeError::InvalidValue`]: crate::ln::msgs::DecodeError::InvalidValue
+/// [`SIGHASH_SINGLE + update_fee Considered Harmful`]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html
+#[no_mangle]
+pub extern "C" fn ChannelHandshakeConfig_set_negotiate_anchors_zero_fee_htlc_tx(this_ptr: &mut ChannelHandshakeConfig, mut val: bool) {
+ unsafe { &mut *ObjOps::untweak_ptr(this_ptr.inner) }.negotiate_anchors_zero_fee_htlc_tx = val;
+}
+/// The maximum number of HTLCs in-flight from our counterparty towards us at the same time.
+///
+/// Increasing the value can help improve liquidity and stability in
+/// routing at the cost of higher long term disk / DB usage.
+///
+/// Note: Versions of LDK earlier than v0.0.115 will fail to read channels with a configuration
+/// other than the default value.
+///
+/// Default value: 50
+/// Maximum value: 483, any values larger will be treated as 483.
+/// This is the BOLT #2 spec limit on `max_accepted_htlcs`.
+#[no_mangle]
+pub extern "C" fn ChannelHandshakeConfig_get_our_max_accepted_htlcs(this_ptr: &ChannelHandshakeConfig) -> u16 {
+ let mut inner_val = &mut this_ptr.get_native_mut_ref().our_max_accepted_htlcs;
+ *inner_val
+}
+/// The maximum number of HTLCs in-flight from our counterparty towards us at the same time.
+///
+/// Increasing the value can help improve liquidity and stability in
+/// routing at the cost of higher long term disk / DB usage.
+///
+/// Note: Versions of LDK earlier than v0.0.115 will fail to read channels with a configuration
+/// other than the default value.
+///
+/// Default value: 50
+/// Maximum value: 483, any values larger will be treated as 483.
+/// This is the BOLT #2 spec limit on `max_accepted_htlcs`.
+#[no_mangle]
+pub extern "C" fn ChannelHandshakeConfig_set_our_max_accepted_htlcs(this_ptr: &mut ChannelHandshakeConfig, mut val: u16) {
+ unsafe { &mut *ObjOps::untweak_ptr(this_ptr.inner) }.our_max_accepted_htlcs = val;
+}