Disables automatically adding "minimum" fees for JSON-RPC methods-- instead, it returns an error or, iff the user sets the new second parameter "force" to the 'settxfee' JSON-RPC call, sends the transaction with the user-specified fee. This second parameter to 'settxfee' is only enabled if bitcoind is started with the undocumented -nosafefees option.
Currently 4/6 support this change: https://bitcointalk.org/index.php?topic=46925
No consensus on this-- and it removes a feature that I think most web services want ("just send whatever fee is likely to get the damn transactions into blocks, I'll eat the costs because they're so small anyway" -- anyway, that was what I wanted for ClearCoin).
With this part, automatic fees up to "maxtxfee" (default 0.01 BTC) will be accepted for sends without further JSON-RPC interaction.
ACK on the -maxtxfee idea; I'll check the code soon.
About -nosafefees - yes, but only after some way of reverting transactions that do not get accepted by the network is present.
Seriously, the upgrading transactions stuff was already coded, all you have to do is implement it and do it well...
Disagree with "accept any transaction...from myself" because that is a useful safety net.
No opinion on the other stuff. Probably should admin-close and let this issue/code sit until fees are straightened out.
Re "accept any transaction...from myself": By the time they're being rejected, it's already too late to undo them.
I think this is a mess we don't want to merge... NAK from me at least.
If and when fees get redone, this code will change anyway. Until that time, it is debatable that these will be used by >1 users.
Someone else is maintaining a complete fork just for this, and it seems to have a >1 userbase: https://bitcointalk.org/index.php?topic=22434.0
I'm quite sure some people are interested in this, especially the the ability to prevent transaction from taking a unexpected fee without interaction. There are alternatives though, like an RPC to prepare a transaction, and allow inspection before submitting it.
The nosafefees part... sure, one day, but we definitely need saner behaviour when non-accepting / conflicting transactions exist in a wallet.
I think so. Just because one can implement the same behaviour by implementing their own Bitcoin transaction maker externally, doesn't mean the simpler use-cases shouldn't be supported for software that just wants to deal with the financial aspects.
No consensus, it mixes in fee behavior which is actively debated, and this pull request has become "all over the place"
Closing, but you are welcome to re-open smaller, more fine-grained changes as separate pull requests that might be more easily ACK'd or NAK'd.