<p>Have a look at <code>fundrawtransaction</code> (if you are okay using the internal wallet).
<code>fundrawtransaction</code> will give you back the used <code>fee</code> (next to the hex byte-array of the funded transaction) before signing or broadcasting the transaction.</p>
<h2>The ideal workflow is:</h2>
<ul>
<li><code>createrawtransaction '[]' '{&quot;&lt;addr&gt;&quot;: &lt;amount&gt;}' //set no inputs</code></li>
<li><code>fundrawtransaction &lt;hex&gt;</code></li>
<li>you'll get back <code>{&quot;hex&quot;:&lt;tx&gt;, &quot;fee&quot;: &lt;amount&gt;, &quot;changepos&quot;: &lt;pos of the change output&gt;}</code></li>
<li>Check the fee, maybe increase it (requires Bitcoin Core 0.14, use the <code>feeRate</code> of <code>fundrawtransaction</code>.</li>
<li><code>signrawtransaction &lt;hex&gt;</code></li>
<li><code>sendrawtransaction &lt;hex&gt;</code></li>
</ul>

CC BY-SA 3.0
2017-02-07T10:21:34.607Z
This is a great suggestion! But we want to spend from a particular address in the wallet which we retrieve from `listunspent` .. so it won't work for us as there is no way to do this filtering in `fundrawtransaction`
motatoes
CC BY-SA 3.0
2017-02-07T19:40:16.447Z
In that case you need to calculate the transaction size by yourself by assume 72byte per EC sig. But it depends what types of inputs you support (P2PKH, etc.).
Jonas Schnelli
CC BY-SA 3.0
2017-02-07T21:05:34.373Z
Well they are all multisig addresses .. So P2SH
motatoes
CC BY-SA 3.0
2017-02-07T08:43:57.727Z
2017-02-07T08:43:57.727Z
2020-06-16T11:10:03.350Z
Jonas Schnelli
<p>In our application we are generating a trasaction hex using the <code>createrawtransaction</code> call to "handcraft" a transaction. The problem we are facing is that we would like to estimate the mining fee for this transaction. I realize that we could call <code>estimatefee x</code> to estimate the mining fee per byte. But the problem is we are generating the transaction, so we don't know the size of the transaction yet! Chicken or egg?! I realize that we can generate a transaction and then account for the mining fee based on the hex, but this sounds like a hack to me. </p>

<p>So the question is: what's the best way to estimate the optimal mining fee while using <code>createrawtransaction</code> ? </p>

<bitcoind><mining-reward><createrawtransaction>
How to estimate mining fee for raw transaction?
motatoes
# How to estimate mining fee for raw transaction?

(Asked by: username_0 on 2017-02-07)

In our application we are generating a trasaction hex using the `createrawtransaction` call to "handcraft" a transaction. The problem we are facing is that we would like to estimate the mining fee for this transaction. I realize that we could call `estimatefee x` to estimate the mining fee per byte. But the problem is we are generating the transaction, so we don't know the size of the transaction yet! Chicken or egg?! I realize that we can generate a transaction and then account for the mining fee based on the hex, but this sounds like a hack to me.

So the question is: what's the best way to estimate the optimal mining fee while using `createrawtransaction` ?

**Tags:** bitcoind, mining-reward, createrawtransaction


---

## 1 answers

### Answer by username_1 on 2017-02-07. Score: 2 | Accepted answer

Have a look at `fundrawtransaction` (if you are okay using the internal wallet).
`fundrawtransaction` will give you back the used `fee` (next to the hex byte-array of the funded transaction) before signing or broadcasting the transaction.

## The ideal workflow is:

* `createrawtransaction '[]' '{"": }' //set no inputs`
* `fundrawtransaction`
* you'll get back `{"hex":, "fee": , "changepos": }`
* Check the fee, maybe increase it (requires Bitcoin Core 0.14, use the `feeRate` of `fundrawtransaction`.
* `signrawtransaction`
* `sendrawtransaction`

> **Comments:**
> **username_0**: This is a great suggestion! But we want to spend from a particular address in the wallet which we retrieve from `listunspent` .. so it won't work for us as there is no way to do this filtering in `fundrawtransaction`  
> **username_1**: In that case you need to calculate the transaction size by yourself by assume 72byte per EC sig. But it depends what types of inputs you support (P2PKH, etc.).  
> **username_0**: Well they are all multisig addresses .. So P2SH  

---

