Right now we pass in a change policy when creating the metric type:
#[derive(Clone, Copy)]
pub struct LowestFee {
/// The target parameters for the resultant selection.
pub target: Target,
/// The estimated feerate needed to spend our change output later.
pub long_term_feerate: FeeRate,
/// Policy to determine the change output (if any) of a given selection.
pub change_policy: ChangePolicy,
}
But what if we pass in a really wacky change_policy that doesn't try and lower your fees? This means a whole lot of complicated logic is needed within the bound function of the metric to try and still get the correct bound with a ChangePolicy that is working against the metric!
This would allow us to remove this entire if/else statement:
Right now we pass in a change policy when creating the metric type:
But what if we pass in a really wacky
change_policy
that doesn't try and lower your fees? This means a whole lot of complicated logic is needed within the bound function of the metric to try and still get the correct bound with aChangePolicy
that is working against the metric!This would allow us to remove this entire if/else statement:
https://github.com/bitcoindevkit/coin-select/blob/0f7cc313b792c4b4a9b58ece8396f02f71191d77/src/metrics/lowest_fee.rs#L56-L108
Can anyone think of a reason you'd want a change policy that is not inline with the metric you are trying to optimize for?