monitor_pending_forwards: Vec<(PendingHTLCInfo, u64)>,
monitor_pending_failures: Vec<(HTLCSource, PaymentHash, HTLCFailReason)>,
- // pending_update_fee is filled when sending and receiving update_fee
- // For outbound channel, feerate_per_kw is updated with the value from
- // pending_update_fee when revoke_and_ack is received
+ // pending_update_fee is filled when sending and receiving update_fee.
//
- // For inbound channel, feerate_per_kw is updated when it receives
- // commitment_signed and revoke_and_ack is generated
- // The pending value is kept when another pair of update_fee and commitment_signed
- // is received during AwaitingRemoteRevoke and relieved when the expected
- // revoke_and_ack is received and new commitment_signed is generated to be
- // sent to the funder. Otherwise, the pending value is removed when receiving
- // commitment_signed.
+ // Because it follows the same commitment flow as HTLCs, `FeeUpdateState` is either `Outbound`
+ // or matches a subset of the `InboundHTLCOutput` variants. It is then updated/used when
+ // generating new commitment transactions with exactly the same criteria as inbound/outbound
+ // HTLCs with similar state.
pending_update_fee: Option<(u32, FeeUpdateState)>,
- // update_fee() during ChannelState::AwaitingRemoteRevoke is hold in
- // holdina_cell_update_fee then moved to pending_udpate_fee when revoke_and_ack
- // is received. holding_cell_update_fee is updated when there are additional
- // update_fee() during ChannelState::AwaitingRemoteRevoke.
+ // If a `send_update_fee()` call is made with ChannelState::AwaitingRemoteRevoke set, we place
+ // it here instead of `pending_update_fee` in the same way as we place outbound HTLC updates in
+ // `holding_cell_htlc_updates` instead of `pending_outbound_htlcs`. It is released into
+ // `pending_update_fee` with the same criteria as outbound HTLC updates but can be updated by
+ // further `send_update_fee` calls, dropping the previous holding cell update entirely.
holding_cell_update_fee: Option<u32>,
next_holder_htlc_id: u64,
next_counterparty_htlc_id: u64,
if feerate_per_kw < lower_limit {
return Err(ChannelError::Close(format!("Peer's feerate much too low. Actual: {}. Our expected lower limit: {}", feerate_per_kw, lower_limit)));
}
- let upper_limit = fee_estimator.get_est_sat_per_1000_weight(ConfirmationTarget::HighPriority) as u64 * 2;
+ // We only bound the fee updates on the upper side to prevent completely absurd feerates,
+ // always accepting up to 25 sat/vByte or 10x our fee estimator's "High Priority" fee.
+ // We generally don't care too much if they set the feerate to something very high, but it
+ // could result in the channel being useless due to everything being dust.
+ let upper_limit = cmp::max(250 * 25,
+ fee_estimator.get_est_sat_per_1000_weight(ConfirmationTarget::HighPriority) as u64 * 10);
if feerate_per_kw as u64 > upper_limit {
return Err(ChannelError::Close(format!("Peer's feerate much too high. Actual: {}. Our expected upper limit: {}", feerate_per_kw, upper_limit)));
}
return Err(ChannelError::Close("Peer sent update_fee when we needed a channel_reestablish".to_owned()));
}
Channel::<Signer>::check_remote_fee(fee_estimator, msg.feerate_per_kw)?;
+ let feerate_over_dust_buffer = msg.feerate_per_kw > self.get_dust_buffer_feerate();
+
self.pending_update_fee = Some((msg.feerate_per_kw, FeeUpdateState::RemoteAnnounced));
self.update_time_counter += 1;
+ // If the feerate has increased over the previous dust buffer (note that
+ // `get_dust_buffer_feerate` considers the `pending_update_fee` status), check that we
+ // won't be pushed over our dust exposure limit by the feerate increase.
+ if feerate_over_dust_buffer {
+ let inbound_stats = self.get_inbound_pending_htlc_stats();
+ let outbound_stats = self.get_outbound_pending_htlc_stats();
+ let holder_tx_dust_exposure = inbound_stats.on_holder_tx_dust_exposure_msat + outbound_stats.on_holder_tx_dust_exposure_msat;
+ let counterparty_tx_dust_exposure = inbound_stats.on_counterparty_tx_dust_exposure_msat + outbound_stats.on_counterparty_tx_dust_exposure_msat;
+ if holder_tx_dust_exposure > self.get_max_dust_htlc_exposure_msat() {
+ return Err(ChannelError::Close(format!("Peer sent update_fee with a feerate ({}) which may over-expose us to dust-in-flight on our own transactions (totaling {} msat)",
+ msg.feerate_per_kw, holder_tx_dust_exposure)));
+ }
+ if counterparty_tx_dust_exposure > self.get_max_dust_htlc_exposure_msat() {
+ return Err(ChannelError::Close(format!("Peer sent update_fee with a feerate ({}) which may over-expose us to dust-in-flight on our counterparty's transactions (totaling {} msat)",
+ msg.feerate_per_kw, counterparty_tx_dust_exposure)));
+ }
+ }
Ok(())
}
// whichever is higher. This ensures that we aren't suddenly exposed to significantly
// more dust balance if the feerate increases when we have several HTLCs pending
// which are near the dust limit.
- cmp::max(2530, self.feerate_per_kw * 1250 / 1000)
+ let mut feerate_per_kw = self.feerate_per_kw;
+ // If there's a pending update fee, use it to ensure we aren't under-estimating
+ // potential feerate updates coming soon.
+ if let Some((feerate, _)) = self.pending_update_fee {
+ feerate_per_kw = cmp::max(feerate_per_kw, feerate);
+ }
+ cmp::max(2530, feerate_per_kw * 1250 / 1000)
}
pub fn get_cur_holder_commitment_transaction_number(&self) -> u64 {
if self.is_outbound() {
self.pending_update_fee.map(|(a, _)| a).write(writer)?;
} else if let Some((feerate, FeeUpdateState::AwaitingRemoteRevokeToAnnounce)) = self.pending_update_fee {
- // As for inbound HTLCs, if the update was only announced and never committed, drop it.
Some(feerate).write(writer)?;
} else {
+ // As for inbound HTLCs, if the update was only announced and never committed in a
+ // commitment_signed, drop it.
None::<u32>.write(writer)?;
}
self.holding_cell_update_fee.write(writer)?;
projects / rust-lightning / blobdiff