i just lost 3 hours worth of interest on a 250k utxo because i voted in the casual poll, when the wallet could've picked another much smaller one instead. it should pick the smallest utxo first, same as it does with regular transactions.
that's no good
I would also like to request that change is sent back to the same address rather than a new change address, for the sake of backups. This same behavior should be applied to beacon transactions as well.
It ends up using SelectCoins to do the contract sends on the network with using minimumbalance call which should just like with beacon i'll look at it more. and could u define the smallest utxos u had?
perhaps you should make an issue @personthingman2 about allowing a config option when set to send change back to the same address. it's possible thou this would be global and all change goes back to originating address. Concept of using change is to keep funds moving making the address less vulnerable to cracking the private key which is hard enough as is.
I really like the idea of a global config option of sending the change back to the originating address rather than generating new ones. Unless you are worried about anonymity, the risk of loss of coin due to hardware failure and failed backups is much higher than theft of coin by cracking the private key. Constraining the key space to known keys already backed up makes old backups more likely to be able to recover all of someone's coins with a simple rescan.
alright will see what i can do while respect coin control ofcourse
At least with voting, the point of anonymity is moot because the vote TX already contains all the UTXOs and corresponding signatures you're voting with...
yes im looking into this issue and the option of also change as a configuration. :) rest assured i will get it done over next couple days
It appears that Select coins will pull all coins that are below or equal to the transaction amount needed. we then shuffle the inputs then use what it takes to meet the target. the change idea to same address could also be a bit of a challenge with this since it puts the data into a set which is ordered. if it was not ordered then the last input in the transaction would be the one with remaining change. so will think of ways to contend with both ideas mentioned in here. may have to modify the coins with minimum balance method of choosing the coins in the end but feesable