How to calculate and add FEE

[scalaz]

Hello!

I have created RAW transaction like this

createrawtransaction [{"txid":"cb6b3604efd24...","vout":0}]
{"3GW....":1.0,"39dj9....":206.0}

Calculated change and added address for the change.
How to calculate tx fee and add feeto the transaction ?

Thanks

[DannyHamilton]

Hello!

I have created RAW transaction like this

createrawtransaction [{"txid":"cb6b3604efd24...","vout":0}]
{"3GW....":1.0,"39dj9....":206.0}

Calculated change and added address for the change.
How to calculate tx fee and add feeto the transaction ?

Thanks

You can choose any fee you like.

Generally, I prefer to pay 0.0001 BTC per kilobyte (or remaining fraction of a kilobyte) at the moment (and I adjust this amount over time as the exchange rate changes).

So, to "calculate tx fee" you would figure out how many kilobytes the transaction will (remembering to add in the remaining fraction of a kilobyte) be and multiply by 0.0001 BTC.  If my transaction is 2.21 kilobytes I pay a 0.0003 BTC fee.

As for how to "add" the fee...
The fee is the difference between the inputs and the outputs.  Therefore, if you reduce the amount of your change output by 0.0001 BTC then the transaction will have a 0.0001 BTC fee.

Once you decide how much fee you want to pay, make sure that your change is at least that much (if it is not, then you'll need to include larger or additional inputs) and then reduce the change by the amount of fee you want the transaction to have.

[creepland]

Nice thanks...
I prepare 10k satoshis fee. But sometimes if need fast send then put 20k

[scalaz]

How to calculate size. found


in*180 + out*34 + 10 plus or minus 'in'
For example, this transaction has 40 inputs and 16 outputs. That gives us a transaction size of

40*180 + 16*34 + 10 +- 40
i.e. 7754 +- 40 bytes. The actual size is 7761 bytes.

Could you please clarify about  +- 40

BR!

[DannyHamilton]

Could you please clarify about  +- 40

The size of the transaction will depend on the specifics of the inputs and outputs.

The calculation that you found was based on an assumption that each input was previously received at a P2PKH address that used an uncompressed key address, and that each new output would be a P2PKH address.

If the addresses that the inputs were previously received at were compressed key addresses then each input will be 148 bytes plus or minus 1 bytes instead of 180 bytes plus or minus 1 byte.

If the outputs that you are creating are not P2PKH addresses, or if the inputs were not received at P2PKH addresses, then you'll need to figure out how big each one is.

As for the reasoning behind the "plus or minus 1 byte"...

This is because there's no way of knowing in advance how big the signatures are going to be.

From what I've read:

- snip -
In particular, for uncompressed public keys, there is:

• a 25% chance each input is 179 bytes or smaller,
• a 50% chance each input is 180 bytes,
• a 25% chance each input is 181 bytes.

- snip -