These commits introduce CWallet::CreateExactTransaction() function that works like CWallet::CreateTransaction(), but takes explicit list of prev_out transactions for sourcing the new transaction and fixed value of transaction fee.
Furthermore, new RPC call 'sendexact' is introduced; it works like 'sendmany', but takes explicit list of transactions to use as coin sources, and explicit value of transaction fee.
All outputs of the listed transactions that the account can claim are used to source coins; the output of the new transaction must be exactly the same amount, the user is responsible for dealing with any change. The user is also responsible for setting the transaction fee to such a value that other nodes will relay the transaction.
The point is to provide a low-level interface for making transactions without all the auto-guessing implicitly done by the client. My primary motivation is that I am a control freak and I want to have precise control over the addresses used as "sources" of my transactions.
There are other applications too - even if more specific interfaces might be more suited to them, this interface makes them possible at all as the lowest common denominator. E.g. people who wish to be sure no transaction fees will be paid for their transaction can use this interface. Or people wishing to try out different coin selection algorithms (or when coin selection makes sense at the moment of transaction setup, e.g. in case of anonymizers).
Q: Why use explicit transactions instead of addresses? A: In reality, you do not quite transfer money "from" an address. Address is just a token that proves you are authorized to claim a particular amount of bitcoins listed as one of outputs of some transaction. Specific use-cases might be simplified, but you would still be in hands of a fixed coin selection algorithm. You can use (somewhat laborously) listtransactions or external service to discover transactions that send money to a given address.
Q: Why use account instead of explicit addresses? A: First, it is more consistent with the other "send" interfaces and the wallet organization. Second, I believe account is the right abstraction - as mentioned, address is just a token for claiming some bitcoins, but different kind of claim proofs might be used (e.g. the now-deprecated "send to IP address", or it could be possible to also specify password-protected coins). In the future, you could associate further methods of authentication with accounts, but addresses are limited. If you require a specific set of addresses to be used, you can set up an ad-hoc account.
Q: What does that bit about "change" mean? A: If transaction input claims some output of a previous transaction, it must claim all the coins in the output. If you need to transfer smaller amount than that, you must specify what to do with the remaining amount (change). The built-in coin selection algorithm either sends them to a new address (for better anonymity) or returns them to the source address. Here, you are responsible for manually specifying the destiny of your remaining amount.
Q: Can I be finally sure I pay only the TX fee I specify? A: Yes, the TX fee you specify is final. However, please note that if the new transaction is large (i.e. has many inputs and outputs) or transfers too small amount and you do not offer any TX fee, it may not be accepted by any other nodes. Note that this is more serious than not being included in a block - you could just wait longer for a benevolent miner. In these circumstances, your transaction is not likely to even reach a mining node because the P2P network will not relay it.
(If you like the feature, you can send donations to 19VF444umGxX76DZwPuWVMHpv7i84DHM1D.)
