In a token burn tx, you end up having enough XEC from your dust inputs

TIL

Here's the tx in the test after this change

Here's the tx before this change. Note we add a nonSlpUtxo automatically to all txs before this refactor, which is overspending on some burn txs.

It would be better to check

needsAnotherUtxo = inputSatoshis < satoshisToSend + feeForThisTx

However, we need to build the tx to get feeForThisTx.

There is an available optimization to build the tx and get the fee using dummy (i.e. unsigned) inputs. However I am not totally sure how to do this (or if it is practical to do given the many different input types soon possible in Cashtab). I am also not sure on the performance trade-offs of calculating the fee every time with dummy inputs vs "getting it right" > ~95% of the time by using this check, then occasionally having to build the tx twice (as in the edge case tests added in this diff).

And, anyway, Cashtab is already behaving this way -- so this diff is still an improvement on existing behavior.

e.g. change the loop to one that tracks the index and if index = spendableUtxos.length && needsAnotherUtxo then throw exception here.

We get this result though without having to perform this check on every single utxo. imo not good practice to always "check if it's the last one" if you don't have to do this, just put the condition at the end.

tbh yes, it is still a bit messy. We should probably add utxo selection to ecash-lib, as it is a weird problem for app developers to deal with. But I don't think we need to do this before getting NFT trading into Cashtab.

satsPerKb in Cashtab is dynamic in this way -- but this is handled at the callsite. It's kept as a param in the function to support unit testing at different fee rates.

dustSats should be a param, yes, will handle this in a separate diff.