<blockquote>
  <p>How is this computed?</p>
</blockquote>

<p>Bitcoin Core offers something called fee estimation, where you can gauge the amount of fee that is probably necessary to get a transaction into the next block. It returns the fee per kilobyte to get into one of the next <code>n</code> blocks, assuming the miners making them have similar transaction acceptance rules as prior ones.</p>

<pre><code>1 confirmation 0.00026816 BTC
2 confirmation 0.00011483 BTC
3 confirmation 0.00002048 BTC
4 confirmation 0.00001255 BTC
5 confirmation 0.00001255 BTC
6 confirmation 0.00001255 BTC
</code></pre>

<p>Emulating this without running a fully validating node that can evaluate its memory pool over a long period of time is probably not particularly doable at present. Centralized wallets like Mycelium make HTTP calls to their own endpoint which returns this information on their behalf, there will probably be more endpoints for this in the future given the difficulty of estimating fees for non fully validating wallets.</p>

<blockquote>
  <p>would the unusually large number of inputs for the new transaction justify a larger transaction fee? If so, how much larger?</p>
</blockquote>

<p>The transaction fee is per kilobyte. Adding additional inputs requires both the public key for the address and a signature, and some miscellaneous overhead to be included. It will often be about one hundred bytes per vin, but this varies if the input is P2SH or not and if the keys used were compressed or not. Generally if the input is below 0.00005 BTC it is probably going to add more in cost in fee than the value of it to include. </p>

<p><a href="http://webbtc.com/tx/d68584905c27bb0441c38c241728be86b2fe96aa3126d46a9aceca8fa54fb056" rel="nofollow">This transaction on mainnet is similar</a> in size to the one you describe, it has 16 vin, 2 vout, for a total size of 2291 bytes. The key for 1FkiXxeKektpHVjvfknVvC6eQmjM9DEu9D is compressed (begins with 02 and is only 33 bytes long) which contributed to the small size of the transaction. </p>

CC BY-SA 3.0
2015-08-19T00:37:12.340Z
2015-08-19T00:37:12.340Z
Claris
<p>When I send Bitcoins through Electrum, I just pay whatever transaction fee the software recommends. Now I'm writing a program that will have to determine the size of the transaction fee on the fly. </p>

<p>How is this computed? It looks like Electrum is consistently recommending .0002 BTC for each transaction but I read elsewhere that resolving the fee amount depends upon the size of the transaction. In an extreme example, if I wanted to redeem 15 tiny unspent outputs and send them to 2 destinations (the receiver + my change address), would the unusually large number of inputs for the new transaction justify a larger transaction fee? If so, how much larger?</p>

<transaction-fees>
How do I determine my transaction fee in an automated way?
Festus Martingale
# How do I determine my transaction fee in an automated way?

(Asked by: username_0 on 2015-08-18)

When I send Bitcoins through Electrum, I just pay whatever transaction fee the software recommends. Now I'm writing a program that will have to determine the size of the transaction fee on the fly.

How is this computed? It looks like Electrum is consistently recommending .0002 BTC for each transaction but I read elsewhere that resolving the fee amount depends upon the size of the transaction. In an extreme example, if I wanted to redeem 15 tiny unspent outputs and send them to 2 destinations (the receiver + my change address), would the unusually large number of inputs for the new transaction justify a larger transaction fee? If so, how much larger?

**Tags:** transaction-fees


---

## 1 answers

### Answer by username_1 on 2015-08-19. Score: 2 | Accepted answer

> How is this computed?

Bitcoin Core offers something called fee estimation, where you can gauge the amount of fee that is probably necessary to get a transaction into the next block. It returns the fee per kilobyte to get into one of the next `n` blocks, assuming the miners making them have similar transaction acceptance rules as prior ones.

```
1 confirmation 0.00026816 BTC
2 confirmation 0.00011483 BTC
3 confirmation 0.00002048 BTC
4 confirmation 0.00001255 BTC
5 confirmation 0.00001255 BTC
6 confirmation 0.00001255 BTC

```

Emulating this without running a fully validating node that can evaluate its memory pool over a long period of time is probably not particularly doable at present. Centralized wallets like Mycelium make HTTP calls to their own endpoint which returns this information on their behalf, there will probably be more endpoints for this in the future given the difficulty of estimating fees for non fully validating wallets.

> would the unusually large number of inputs for the new transaction justify a larger transaction fee? If so, how much larger?

The transaction fee is per kilobyte. Adding additional inputs requires both the public key for the address and a signature, and some miscellaneous overhead to be included. It will often be about one hundred bytes per vin, but this varies if the input is P2SH or not and if the keys used were compressed or not. Generally if the input is below 0.00005 BTC it is probably going to add more in cost in fee than the value of it to include.

[This transaction on mainnet is similar](http://webbtc.com/tx/d68584905c27bb0441c38c241728be86b2fe96aa3126d46a9aceca8fa54fb056) in size to the one you describe, it has 16 vin, 2 vout, for a total size of 2291 bytes. The key for 1FkiXxeKektpHVjvfknVvC6eQmjM9DEu9D is compressed (begins with 02 and is only 33 bytes long) which contributed to the small size of the transaction.


---

