The hard coded AllowFree threshold is not suitable for determining whether a free transaction will be confirmed in a reasonable time.
If estimatePriority returns -1 it either means there isn't yet enough data to estimate or there is no priority that is high enough to be confirmed by the desired target, in either case it's better to not send a zero fee transaction.
The hard coded AllowFree threshold is not suitable for determining whether a free transaction will be confirmed in a reasonable time.
The GUI option at least is called "Send without fee if possible", it explicitly warns that the transaction may not confirm soon. I may be misunderstanding what this change does, but if not, I'm not sure it needs additional protection.
Well, its inconsistent now. It uses the result of estimatePriority to determine if it can send free, unless estimatePriority doesn't give you an answer, in which case it'll use AllowFree. This can cause the odd behavior of being more likely to send a low priority transaction for free if you're asking to be confirmed in 1 block (for which no priority is big enough) than if you're asking to be confirmed in 10 blocks (for which your priority isn't big enough). It should either use AllowFree for everything, which would be the literal interpretation of "if possible" or it should use estimatePriority and interpret -1 as an indication that you can not send for free. The latter would be more useful and is what this pull does. Sorry for the delayed response.
ut ACK. Makes the gui code consistent with the other free check in the wallet code.
concept ACK ut code ACK
Probably needs a slightly longer comment to explain what dPriorityNeeded < 0 means.