Greetingz...
One of the things I've read, having to do with the no-transaction-fee branch, and some of the other comments about how unpredictable fees can be sometimes, and my own experience sending out transactions made of small inputs, let me to a feature I would like to have available.
Being able to have some control over a transaction being sent, or not sent, due to the fee, is something I can see the end user as well as a commercial user needing to have, when using 'bitcoind'.
As it is right now, you can sendtoaddress, and as long as you have the balance to cover the fee it chooses to add onto it, it just goes, with no query approving the fee being added on. We need some control over that.
I would suggest allowing in the <amount> field, a format such as "##.###[+#.##][-#.##]"
+#.## would be the maximum fee the command is allowed to add, and if it exceeds that, then it fails.
-#.## would be the minimum fee to add, if someone wants their transaction to have a higher priority and wishes to force the fee on it.
Used together, a command such as "bitcoind.exe sendtoaddress 1blahblah 1.2+0.001-0.0002" would be interpreted as
I want to send 1.2 btc, but if the fee is going to be above 0.001, then don't send it through, and if the fee is going to be less than 0.0002, send it with a 0.0002 fee anyways.
The exact method can be changed around to something more easily parsed, but as long as we can at the very least, specify a cap on the upper range of the fee to be allowed, then that would give us some measure of control over what we're going to be charged as a fee, and then we could more easily predict a fee expense, say, for a business purpose.
I would carry this over to the other send coin methods as well.
I think this would address some of the concerns I've seen other posters have had, including how the inputs are selected randomly, since you're stating the max/min fee permitted, in the same command, it could be part of the same transaction check.
If the transaction fails, include what the calculated fee would have been in the error/failure message.
Then we would have the option, of increasing the allowed limit on our next attempt, or just wait until later to try again if we suspect our inputs need to mature more.
Any automatic expenditure that we don't explicitly approve of, should have some measure of our approval before it is just tacked onto the coin we intend to send. How much or how little it is, really isn't all that relevant, the principle of the matter remains.
Somehow, even by making a pre-approval in this manner, we have to have the ability to say yes or no to a transaction.
Thank you for your time.
-- Smoov
ps: no, I can't code it myself, I'm way way way too rusty
