|
1 |
| -{-# LANGUAGE RankNTypes #-} |
| 1 | +{-# LANGUAGE RankNTypes #-} |
| 2 | +{-# LANGUAGE ViewPatterns #-} |
2 | 3 | {-# OPTIONS_GHC -fno-warn-orphans #-}
|
3 | 4 |
|
4 | 5 | module Cardano.Wallet.Kernel.CoinSelection.FromGeneric (
|
@@ -211,7 +212,23 @@ runCoinSelT :: forall m. Monad m
|
211 | 212 | => NonEmpty (Output (Dom utxo))
|
212 | 213 | -> CoinSelT utxo CoinSelHardErr m [CoinSelResult (Dom utxo)])
|
213 | 214 | -> CoinSelPolicy Core.Utxo m CoinSelFinalResult
|
214 |
| -runCoinSelT opts pickUtxo policy request utxo = do |
| 215 | +runCoinSelT opts pickUtxo policy (NE.sortBy (flip (comparing outVal)) -> request) utxo = do |
| 216 | + -- NOTE: we sort the payees by output value, to maximise our chances of succees. |
| 217 | + -- In particular, let's consider a scenario where: |
| 218 | + -- |
| 219 | + -- 1. We have a payment request with two outputs, one smaller and one |
| 220 | + -- larger (but both relatively large) |
| 221 | + -- 2. Random selection tries to cover the smaller one first, fail because |
| 222 | + -- it exceeds the maximum number of inputs, fall back on largest first, |
| 223 | + -- which will pick the n largest outputs, and then traverse from from |
| 224 | + -- small to large to cover the payment. |
| 225 | + -- 3. It then tries to deal with the larger output, and fail because in |
| 226 | + -- step (2) we picked an output we needed due to only consider the n |
| 227 | + -- largest outputs (rather than sorting the entire UTxO, |
| 228 | + -- which would be much too expensive). |
| 229 | + -- |
| 230 | + -- Therefore, just always considering them in order from large to small |
| 231 | + -- is probably a good idea. |
215 | 232 | mSelection <- unwrapCoinSelT policy' utxo
|
216 | 233 | case mSelection of
|
217 | 234 | Left err -> return (Left err)
|
|
0 commit comments