<ul>
<li>Legacy input size: 148 bytes (compressed)</li>
<li><p>Legacy output size: 34 bytes (compressed)</p></li>
<li><p>Segwit input size: 104 bytes </p></li>
<li>Segwit output size: 32 bytes</li>
</ul>

<p>so if your transaction has two inputs and one output total size is ~ 246 Bytes, Don't forget about some more additional bytes for transaction header.</p>

CC BY-SA 3.0
2018-03-28T02:50:31.493Z
2018-03-28T02:50:31.493Z
Tailer
<blockquote>
  <p>Say, my raw transaction is 500 bytes,100 bytes of which are witness data. Thus, 400 bytes are now competing for the place in 1 Mb block.</p>
</blockquote>

<p>That's not correct.</p>

<p>SegWit replaces the concept of size and maximum block size with <strong>weight</strong>. The weight of a transaction is defined as 3 times the stripped_size in bytes (excluding the witness) plus the total_size in bytes (including the witness). The maximum weight of all transactions in a block is 4000000. This is the only limit that matters. Due to the way the weight formula is constructed, it implies that the old rule (stripped_size &lt;= 1000000) is always satisfied. Miners try to get as much fees out of the weight limit they have available, and as a result optimize for <em>fee per weight</em>.</p>

<p>So, transaction sizes don't matter anymore. What matters is their weight. Unfortunately, there is a factor 4 scaling between the two, so you can't easily convert feerates from before SegWit to after. For this reason, the concept of <strong>vsize</strong> (virtual size) was introduced. It's equal to weight/4. For non-SegWit transactions, their size and vsize are identical. The easiest way to express fees is now to see them as BTC per vbyte (vsize byte).</p>

<blockquote>
  <p>How accurate is it to say that current transaction fee is 1000 / 400 = 2.5 s/b?</p>
</blockquote>

<p>In your example, the weight of your transaction is 3*400 + 500 = 1700. This means its vsize is 425 vbytes. As a result, its feerate is 1000 / 425 = 2.35 sat/vbyte, and it would compete with other transactions at that level.</p>

CC BY-SA 3.0
2018-01-06T11:37:08.857Z
As clear as it gets. Thx
Average Joe
CC BY-SA 3.0
2018-01-09T04:12:21.397Z
@pieter-wuille Does Segwit embedded inside P2SH get the benefit of the new concept of size? The following question mentioned that using nested in a legacy P2SH has benefit (although less efficient). I want to understand the meaning.
https://bitcoin.stackexchange.com/questions/62053/how-do-transaction-costs-compare-between-bech32-addresses-and-legacy-bitcoin-add
zono
CC BY-SA 3.0
2018-01-09T08:04:24.313Z
Yes, it does, though to a lesser extent. I'll try to write an answer to that question.
Pieter Wuille
CC BY-SA 3.0
2018-01-06T11:28:41.297Z
2018-01-06T11:28:41.297Z
Pieter Wuille
<p>For transaction not spending SegWit outputs it's straightforward: if I have <code>1000</code> Satoshi fee set for <code>500</code> byte raw transaction, I end up with <code>2</code> s/b fee.</p>

<p>How about transaction containing witness data? </p>

<p>Say, my raw transaction is <code>500</code> bytes,<code>100</code> bytes of which are witness data. Thus, <code>400</code> bytes are now competing for the place in 1 Mb block.</p>

<p>How accurate is it to say that current transaction fee is <code>1000 / 400 = 2.5</code> s/b?</p>

<transaction-fees><segregated-witness>
SegWit transaction fee/byte
Average Joe
# SegWit transaction fee/byte

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

For transaction not spending SegWit outputs it's straightforward: if I have `1000` Satoshi fee set for `500` byte raw transaction, I end up with `2` s/b fee.

How about transaction containing witness data?

Say, my raw transaction is `500` bytes,`100` bytes of which are witness data. Thus, `400` bytes are now competing for the place in 1 Mb block.

How accurate is it to say that current transaction fee is `1000 / 400 = 2.5` s/b?

**Tags:** transaction-fees, segregated-witness


---

## 2 answers

### Answer by username_2 on 2018-01-06. Score: 12 | Accepted answer

> Say, my raw transaction is 500 bytes,100 bytes of which are witness data. Thus, 400 bytes are now competing for the place in 1 Mb block.

That's not correct.

SegWit replaces the concept of size and maximum block size with **weight**. The weight of a transaction is defined as 3 times the stripped\_size in bytes (excluding the witness) plus the total\_size in bytes (including the witness). The maximum weight of all transactions in a block is 4000000. This is the only limit that matters. Due to the way the weight formula is constructed, it implies that the old rule (stripped\_size <= 1000000) is always satisfied. Miners try to get as much fees out of the weight limit they have available, and as a result optimize for *fee per weight*.

So, transaction sizes don't matter anymore. What matters is their weight. Unfortunately, there is a factor 4 scaling between the two, so you can't easily convert feerates from before SegWit to after. For this reason, the concept of **vsize** (virtual size) was introduced. It's equal to weight/4. For non-SegWit transactions, their size and vsize are identical. The easiest way to express fees is now to see them as BTC per vbyte (vsize byte).

> How accurate is it to say that current transaction fee is 1000 / 400 = 2.5 s/b?

In your example, the weight of your transaction is 3\*400 + 500 = 1700. This means its vsize is 425 vbytes. As a result, its feerate is 1000 / 425 = 2.35 sat/vbyte, and it would compete with other transactions at that level.

> **Comments:**
> **username_0**: As clear as it gets. Thx  
> **username_3**: @username_2-username_2 Does Segwit embedded inside P2SH get the benefit of the new concept of size? The following question mentioned that using nested in a legacy P2SH has benefit (although less efficient). I want to understand the meaning. https://bitcoin.stackexchange.com/questions/62053/how-do-transaction-costs-compare-between-bech32-addresses-and-legacy-bitcoin-add  
> **username_2**: Yes, it does, though to a lesser extent. I'll try to write an answer to that question.  

---

### Answer by username_1 on 2018-03-28. Score: 2

* Legacy input size: 148 bytes (compressed)
* Legacy output size: 34 bytes (compressed)
* Segwit input size: 104 bytes
* Segwit output size: 32 bytes

so if your transaction has two inputs and one output total size is ~ 246 Bytes, Don't forget about some more additional bytes for transaction header.


---

