Lloyd Fournier

eak concept NACK. If my understanding is up to date we currently use `max_satisfaction_weight()` to figure out weight for coin selection which will not use the grinded value. So fixing...

I am writing about this for the blog post which should drop this week but here's my current vision on how this would work with `bdk_core`: 1. I'll introduce something...

+1. Thanks for bringing this up. Before depreciating BIP69 I think we should make it possible to set the rng for shuffling so you still have a deterministic sorting option....

> > ... Before depreciating BIP69 I think we should make it possible to set the rng for shuffling so you still have a deterministic sorting option. I'd like this...

> Agreed that we can deprecate it to show a warning that it should not be used, but I'm not sure I would remove it completely anytime soon. The way...

@Eunoia1729 Go for it! Probably the best approach right now is to do what @afilini suggested and allowing a custom comparison function. So I guess this means adding a `Custom`...

@FadedCoder do we actually need those derives for anything? I wouldn't have thought so. Try removing them. If we need `Clone` for some reason just make it an `Arc` rather...

> Is it worth supporting FnMut against the extra complexity? Ok I see your point. If it does need to be an `Arc` because of the clone thing then yeah...

I suppose we always "see" a transaction at a certain point and can record it so I think this is doable. I'll keep this in mind for `bdk_core`.

The difficulty with the approach is that now you have to have two impls -- one using `tokio::sync::Mutex` and one using `RefCell` to account for no_std/WASM. I don't see how...