Quote from: gmaxwell on September 26, 2014, 04:38:13 PM

As far as the idea goes perhaps. Though I'd recommend adjusting your business plans such that the average of the fees in total is what you worry about; rather than the fees on any particular transaction. Otherwise you're just going to get jammed up and unable to transact when someone has sent you a number of dust inputs and the only way to eliminate them is to pay a somewhat high fee... all your low value transactions will end up failing until you up that limit.

I'm not entirely sure what good worrying about the average of fees in total is when I have zero control over it using send* apis. In fact I am here making a proposal because I do worry about it.

The case of small amounts may actually be where this is most useful because the fees can presently eat up 50% or even 100+% of the send amount. But its hard to KNOW that until you actually try to send. And then you get the surprise fee amount like an unwanted toy out of a cracker jack box. So it is often preferable to wait until those inputs have aged sufficiently and/or enough other larger inputs have come in that the overall fee percentage goes down to something like 1%. Or maybe just wait till btc price rises and those dust are worth something. whatever.... it should be my application (or its user's) choice, not some algo within bitcoind.

In the case you mention where many dust inputs are received and it jams things up, it is still useful for the app to be able to make informed decisions. Maybe the decision is to call lock_unspent for some utxo, or log a warning or email the site administrator. Or maybe it is just to send again with a higher fee limit or no fee limit at all.

Right now the app developer's options are to either blindly call sendto* and take the fee it arbitrarily comes up with or else write your own coin selection and fee calculation routines and generate a raw transaction. I've been down that route.... it is painful and error-prone, and only a few people will get it right.

I'm not saying the proposed API change is perfect... actually perfection to me would be if I could write app code something like:

Quote

// business application pseudo-code

while( num_tries++ < max_tries ) {

fee = rpc.calcsendfee( address, amount )

if( not fee_is_ok( fee ) )
break;

code = rpc.sendtoaddress( address, amount, .., fee )

if( code != insufficient_fee ) {
break;
}
}

There would be a corresponding calcsendmanyfee also. sendtoaddress might (rarely) return insufficient_fee error code if conditions have changed since calcsendfee() returned. In that case, the application should retry, possibly multiple times.

I'm guessing this approach is a bit more involved to implement than my first proposal, but maybe not too bad since it is already calc'ing the fee internally anyway.

thoughts?