The current algorithm used in all rivine (wallet) implementations does the following:
order all outputs from biggest to smallest
start selecting until the amount is reached
if after all outputs are used it still doesn't work,
continue for all unconfirmed
if after all confirmed still not possible, funding fails
This works, but has several flaws:
(a) it can make the transaction fail by funding a Tx with too many coin inputs
(b) it creates pretty much always a coin output for change
(c) it doesn't spend smaller outputs for wallets that have big enough outputs to consume from,
meaning that smaller coin outputs created because of (b) as change will not be spend, and accumulate instead
(d) there are no fallbacks, if the single try cycle does not work, it doesn't continue
Eventually combining all these flaws, a wallet could get in a position where the algorithm will always fail for big enough amounts to be sent.
The current algorithm used in all rivine (wallet) implementations does the following:
order all outputs from biggest to smallest start selecting until the amount is reached if after all outputs are used it still doesn't work, continue for all unconfirmed if after all confirmed still not possible, funding fails This works, but has several flaws:
(a) it can make the transaction fail by funding a Tx with too many coin inputs (b) it creates pretty much always a coin output for change (c) it doesn't spend smaller outputs for wallets that have big enough outputs to consume from, meaning that smaller coin outputs created because of (b) as change will not be spend, and accumulate instead (d) there are no fallbacks, if the single try cycle does not work, it doesn't continue Eventually combining all these flaws, a wallet could get in a position where the algorithm will always fail for big enough amounts to be sent.
The reference implementation should be implemented like described in https://github.com/threefoldtech/rivine/blob/master/specs/outputselection.md after which this file can be moved to the documentation