<p>One hexadecimal digit represents 4 bits which is half of a byte (8 bits). Therefore, the raw byte length of a transaction is half of the length of its hexadecimal representation.</p>

<p>In your case, there are 384 hexadecimal digits, and the raw byte length of the transaction is 192 bytes. Depending on whether the fee rate is given in [satoshi/byte], [satoshi/kilobyte] or [BTC/kilobyte], you need to apply the corresponding unit conversions. Note that Bitcoin uses kilobyte here for 1,000 bytes.</p>

<p>There are two more pitfalls here:</p>

<ol>
<li><p>Since the activation of segwit, fees are paid per weight, not raw byte length. In practice this means that transactions with segwit inputs require less fees than what would correspond to their raw byte length. I've explored the topic further here: <a href="https://medium.com/@murchandamus/psa-wrong-fee-rates-on-block-explorers-48390cbfcc74" rel="nofollow noreferrer">Medium: PSA: Wrong fee rates on block explorers</a></p></li>
<li><p>Signatures in Bitcoin have a variable length. It is therefore common that your fee estimate is off by a byte or two, especially if your transaction has few inputs. You can get around that by either using a slightly conservative estimate (which is for example how this is addressed in Bitcoin Core), or by repeating the signature for the transaction until the size fits your estimate.</p></li>
</ol>

CC BY-SA 3.0
2018-02-16T19:12:46.127Z
2018-02-16T19:12:46.127Z
Murch
<p>generally yes. I got this here from the forum (lost the link): </p>

<blockquote>
  <p>fee = (n_inputs * 148 + n_outputs * 34 + 10) * price_per_byte</p>
</blockquote>

<p>SegWit slightly changes this, where instead of paying per byte, you pay per unit of weight: 1 byte of non witness data = 4 weight, 1 byte of witness data = 1 weight. </p>

CC BY-SA 3.0
2018-01-17T18:51:44.427Z
I understand that size (raw bytes) may be deterministic but I would rather prefer to calculate it using the len(raw bytes) * price_per byte than other complicated calc like you mentioned (n_inputs * 148 + n_outputs * 34 + 10)
Books
CC BY-SA 3.0
2018-01-17T19:55:32.153Z
when assembling the raw tx, it is only afterwards the signatures come in. The signatures can be of different length (72, 73 or 74 bytes - I think Pieter last recently mentioned, only the last two appear in the wild), due to R- or S-Value corrections. So before sig, the formula would be a good approach for P2SH or P2PKH tx (SegWit have slight changes). To be absolutly sure, I think one would need to sign the tx, calculate the length, and then adopt the tx fees. But how would one present this to a user interface? And what if many inputs/outputs? At least the values are fixed length.
pebwindkraft
CC BY-SA 3.0
2018-01-16T17:13:51.193Z
2018-01-16T17:13:51.193Z
pebwindkraft
<p>I know that the bitcoin fee is calculated based on the number of bytes in a transaction (i.e. satoshi per byte). But what bytes are calculated? The bytes of the encoded/serialized transaction or of the raw transaction? </p>

<p>For example, I have the transaction below. The size of the raw bytes is 192. The encoded(hex) is  384. I used a fee of "1" satoshi to generate it so that I can get a sample of what the size will be like. 
   Would be safe to multiple satoshi with the raw size to get the fee and then re-make the transaction? (e.g. 1000 satoshi * 192 = 192000 satoshi fee).</p>

<pre><code>0100000001433a94862b051af03d6ad033153c937d258f6d501edc35a57b61b855f0b691b022ddb2126b483045022100da9bd107a96990429498df53d963a6b5d26455b180f3742f87c2352805d1bd33022033071d16a9578b765b38d68b51d692c575b9b3ce48e9b93276784e33adfd5a1201210342b992de6ebd9f2d0d522f9559d3ff6388fcdb70095c0f0dfe75811c74437bd1ffffffff01ae130000000000001976a914fafb913a62cce4c017e986d07d9a1c25d30e2ace88ac00000000
</code></pre>

<transaction-fees>
What bytes are calculated on the transaction fee?
Books
# What bytes are calculated on the transaction fee?

(Asked by: username_0 on 2018-01-16)

I know that the bitcoin fee is calculated based on the number of bytes in a transaction (i.e. satoshi per byte). But what bytes are calculated? The bytes of the encoded/serialized transaction or of the raw transaction?

For example, I have the transaction below. The size of the raw bytes is 192. The encoded(hex) is 384. I used a fee of "1" satoshi to generate it so that I can get a sample of what the size will be like.
Would be safe to multiple satoshi with the raw size to get the fee and then re-make the transaction? (e.g. 1000 satoshi \* 192 = 192000 satoshi fee).

```
0100000001433a94862b051af03d6ad033153c937d258f6d501edc35a57b61b855f0b691b022ddb2126b483045022100da9bd107a96990429498df53d963a6b5d26455b180f3742f87c2352805d1bd33022033071d16a9578b765b38d68b51d692c575b9b3ce48e9b93276784e33adfd5a1201210342b992de6ebd9f2d0d522f9559d3ff6388fcdb70095c0f0dfe75811c74437bd1ffffffff01ae130000000000001976a914fafb913a62cce4c017e986d07d9a1c25d30e2ace88ac00000000

```

**Tags:** transaction-fees


---

## 2 answers

### Answer by username_1 on 2018-02-16. Score: 1

One hexadecimal digit represents 4 bits which is half of a byte (8 bits). Therefore, the raw byte length of a transaction is half of the length of its hexadecimal representation.

In your case, there are 384 hexadecimal digits, and the raw byte length of the transaction is 192 bytes. Depending on whether the fee rate is given in [satoshi/byte], [satoshi/kilobyte] or [BTC/kilobyte], you need to apply the corresponding unit conversions. Note that Bitcoin uses kilobyte here for 1,000 bytes.

There are two more pitfalls here:

1. Since the activation of segwit, fees are paid per weight, not raw byte length. In practice this means that transactions with segwit inputs require less fees than what would correspond to their raw byte length. I've explored the topic further here: [Medium: PSA: Wrong fee rates on block explorers](https://medium.com/@murchandamus/psa-wrong-fee-rates-on-block-explorers-48390cbfcc74)
2. Signatures in Bitcoin have a variable length. It is therefore common that your fee estimate is off by a byte or two, especially if your transaction has few inputs. You can get around that by either using a slightly conservative estimate (which is for example how this is addressed in Bitcoin Core), or by repeating the signature for the transaction until the size fits your estimate.


---

### Answer by username_2 on 2018-01-16. Score: 0

generally yes. I got this here from the forum (lost the link):

> fee = (n\_inputs \* 148 + n\_outputs \* 34 + 10) \* price\_per\_byte

SegWit slightly changes this, where instead of paying per byte, you pay per unit of weight: 1 byte of non witness data = 4 weight, 1 byte of witness data = 1 weight.

> **Comments:**
> **username_0**: I understand that size (raw bytes) may be deterministic but I would rather prefer to calculate it using the len(raw bytes) * price_per byte than other complicated calc like you mentioned (n_inputs * 148 + n_outputs * 34 + 10)  
> **username_2**: when assembling the raw tx, it is only afterwards the signatures come in. The signatures can be of different length (72, 73 or 74 bytes - I think Pieter last recently mentioned, only the last two appear in the wild), due to R- or S-Value corrections. So before sig, the formula would be a good approach for P2SH or P2PKH tx (SegWit have slight changes). To be absolutly sure, I think one would need to sign the tx, calculate the length, and then adopt the tx fees. But how would one present this to a user interface? And what if many inputs/outputs? At least the values are fixed length.  

---

