For my project it's *imperative to use specific outputs when sending coins.
* You may whine, bitch, complain, argue, stomp, stamp and even tantrum that this is some how wrong/bad/undesirable/ect... Though it won't change project design goals and the problem would still remain.
I'll assume you are talking about the Bitcoin Core wallet?
All transactions have "specific outputs" when sending the transaction. A transaction wouldn't make sense if it didn't. Most people just let the wallet handle the transaction fee and change output for them, but if you prefer to have individual control over that, you can do so either with the coin control features (which can be turned on in the "Wallet" section of the "Preferences" menu), or with the createrawtransaction API call. I wouldn't expect anybody to "whine, bitch, complain, argue, stomp, stamp and even tantrum that this is some how wrong/bad/undesirable/etc".
I'm working with the raw transaction JSON interface, my question is about the application(subtract) of fee to a change address. At the time of having a list of outputs, a selection of new outputs one being flexible(change address) in value, a total value of all inputs, and the value of the non-change outputs. How can the size of the transaction be calculated?
The size of the transaction can't be computed until after you've already sent it if you're using the "sendtoaddress", "sendfrom", or the "sendmany" API calls.
If you use the "createrawtransaction" then you will need to know more than the "total value of all inputs", you will need to know exactly which unspent outputs you are going to use as inputs. Once you know that, you'll need to know if the inputs were received at compressed key addresses, or at uncompressed key addresses. Using all of the above information, you can calculate the maximum likely transaction size as follows:
- 10 bytes of required data for every transaction
- 34 bytes for each output (including all change outputs)
- Between 179 and 181 bytes inclusive for each input that was received at an uncompressed key address (exact size can't be computed until after the transaction is signed)
- Between 147 and 149 bytes inclusive for each input that was received at an uncompressed key address (exact size can't be computed until after the transaction is signed)
One thought I had was to issue this to createrawtransaction with a bogus(1Satoshi?) value for change and compute the size from the returned hex, device by 2.
It's not enough to jsut "createrawtransaction". You won't know the exact size until you "signrawtransaction". If you then modify the change output, the size (in bytes) of the transaction might become different by up to 2X the number of inputs when you re-sign the transaction. As such, depending on your particular use case, it might be easiest to just always assume that the inputs will contribute their largest size (149 bytes for compressed key and 181 bytes for uncompressed key).
Though I was hoping for a simpler method, say each input is X bytes and each output is Y add these together with the constant header size of Q.
Unfortunately, each input must be signed, and the size of the signature isn't known until after you've actually calculated the signature. The signature consists of two 32 byte values, but if the first byte of either of those values is greater than or equal to 0x80 then an additional 0x00 byte is prepended to the value.
