<p>It's a trick that increases the block size without breaking backwards compatibility with non-Segwit nodes. I found this <a href="https://medium.com/@jimmysong/understanding-segwit-block-size-fd901b87c9d4" rel="nofollow noreferrer">article</a> by Jimmy Song to be more helpful than trying to understand the BIP.</p>
<blockquote>
<p>The Segwit blocks are restricted by something called Block Weight. Block Weight is a new concept introduced in Segwit, and it’s calculated on a per-transaction basis. Each transaction has a “weight” which is defined this way:</p>
<p>(tx size with witness data stripped) * 3 + (tx size)</p>
<p>Non-Segwit transactions have zero witness data, so the weight for a non-Segwit transaction is exactly 4 times the size. Segwit transactions have some witness data so the weight is going to be less than 4 times the size. Note Segwit transactions are transmitted to Legacy nodes without witness data, so this formula will always result in blocks communicated to Legacy Nodes that are less than or equal to 1,000,000 bytes.</p>
</blockquote>
<p>If you fill a block with non-Segwit transactions (0 bytes of witness data), the number of weight units (WU) will be calculated as</p>
<pre><code>(1,000,000 B - 0 B) * 3 + 1,000,000 B = 4,000,000 WU
</code></pre>
<p>But the size of the block is still 1,000,000 bytes. This also means that you can fill a block with Segwit transactions, as long as their size, excluding the witness data, totals to 1,000,000 bytes or less. The reason this works is that non-Segwit nodes don't see the witness data for Segwit transactions, therefore they don't count it towards the block size.</p>
<p>As of 2018-01-21, there have been several blocks, such as <a href="https://blockstream.info/block/0000000000000000006aa2f22d95f468611794325617b61c29b6abf998e2b912" rel="nofollow noreferrer">this one</a>, mined that are greater than 1MB.</p>

CC BY-SA 4.0
2018-01-21T18:18:07.790Z
2020-10-31T14:19:57.027Z
2020-10-31T14:19:57.027Z
Sam Jones
<p>Block weight is defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Block_size" rel="nofollow noreferrer">BIP 141</a> itself:</p>

<blockquote>
  <p>Block weight is defined as Base size * 3 + Total size. (rationale[3])</p>
  
  <p>Base size is the block size in bytes with the original transaction
  serialization without any witness-related data, as seen by a
  non-upgraded node.</p>
  
  <p>Total size is the block size in bytes with transactions serialized as
  described in BIP144, including base data and witness data.</p>
</blockquote>

<p>The given rationale is:</p>

<blockquote>
  <p>Rationale of using a single composite constraint, instead of two separate limits such as 1MB base data and 3MB witness data: Using two separate limits would make mining and fee estimation nearly impossible. Miners would need to solve a complex non-linear optimization problem to find the set of transactions that maximize fees given both constraints, and wallets would not be able to know what to pay as it depends on which of the two conditions is most constrained by the time miners try to produce blocks with their transactions in. Another problem with such an approach is freeloading. Once a set of transactions hit the base data 1MB constraint, up to 3MB extra data could be added to the witness by just minimally increasing the fee. The marginal cost for extra witness space effectively becomes zero in that case.</p>
</blockquote>

CC BY-SA 3.0
2017-06-20T19:46:06.023Z
so this is a notion defined by the BIP141 not related to the bitcoin core
Sig Touri
CC BY-SA 3.0
2017-06-20T20:26:36.653Z
Yes, that's what it looks like.
Nate Eldredge
CC BY-SA 3.0
2017-06-20T19:14:47.243Z
2017-06-20T19:14:47.243Z
Nate Eldredge
<p>While reading about BIP141, I have encountered the following options:</p>

<pre><code>Block creation options:
-blockmaxweight=&lt;n&gt; Set maximum BIP141 block weight (default: 3000000)
-blockmaxsize=&lt;n&gt;   Set maximum block size in bytes (default: 750000)
</code></pre>

<p>What is a block weight? Is it a integer representation of the size?</p>

CC BY-SA 3.0
2017-06-26T00:52:48.487Z
related: [Why does BIP141 define both virtual transaction size and weight?](https://bitcoin.stackexchange.com/q/53623/5406)
Murch
<segregated-witness><blocksize><block-weight>
What is block weight and how is it different from block size?
Sig Touri
# What is block weight and how is it different from block size?

(Asked by: username_0 on 2017-06-20)

While reading about BIP141, I have encountered the following options:

```
Block creation options:
-blockmaxweight=<n> Set maximum BIP141 block weight (default: 3000000)
-blockmaxsize=<n>   Set maximum block size in bytes (default: 750000)

```

What is a block weight? Is it a integer representation of the size?

**Tags:** segregated-witness, blocksize, block-weight

> **Comments:**
> **username_1**: related: [Why does BIP141 define both virtual transaction size and weight?](https://bitcoin.stackexchange.com/q/53623/5406)  

---

## 2 answers

### Answer by username_3 on 2017-06-20. Score: 4 | Accepted answer

Block weight is defined in [BIP 141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Block_size) itself:

> Block weight is defined as Base size \* 3 + Total size. (rationale[3])
>
> Base size is the block size in bytes with the original transaction
> serialization without any witness-related data, as seen by a
> non-upgraded node.
>
> Total size is the block size in bytes with transactions serialized as
> described in BIP144, including base data and witness data.

The given rationale is:

> Rationale of using a single composite constraint, instead of two separate limits such as 1MB base data and 3MB witness data: Using two separate limits would make mining and fee estimation nearly impossible. Miners would need to solve a complex non-linear optimization problem to find the set of transactions that maximize fees given both constraints, and wallets would not be able to know what to pay as it depends on which of the two conditions is most constrained by the time miners try to produce blocks with their transactions in. Another problem with such an approach is freeloading. Once a set of transactions hit the base data 1MB constraint, up to 3MB extra data could be added to the witness by just minimally increasing the fee. The marginal cost for extra witness space effectively becomes zero in that case.

> **Comments:**
> **username_0**: so this is a notion defined by the BIP141 not related to the bitcoin core  
> **username_3**: Yes, that's what it looks like.  

---

### Answer by username_2 on 2018-01-21. Score: 2

It's a trick that increases the block size without breaking backwards compatibility with non-Segwit nodes. I found this [article](https://medium.com/@jimmysong/understanding-segwit-block-size-fd901b87c9d4) by Jimmy Song to be more helpful than trying to understand the BIP.

> The Segwit blocks are restricted by something called Block Weight. Block Weight is a new concept introduced in Segwit, and it’s calculated on a per-transaction basis. Each transaction has a “weight” which is defined this way:
>
> (tx size with witness data stripped) \* 3 + (tx size)
>
> Non-Segwit transactions have zero witness data, so the weight for a non-Segwit transaction is exactly 4 times the size. Segwit transactions have some witness data so the weight is going to be less than 4 times the size. Note Segwit transactions are transmitted to Legacy nodes without witness data, so this formula will always result in blocks communicated to Legacy Nodes that are less than or equal to 1,000,000 bytes.

If you fill a block with non-Segwit transactions (0 bytes of witness data), the number of weight units (WU) will be calculated as

```
(1,000,000 B - 0 B) * 3 + 1,000,000 B = 4,000,000 WU

```

But the size of the block is still 1,000,000 bytes. This also means that you can fill a block with Segwit transactions, as long as their size, excluding the witness data, totals to 1,000,000 bytes or less. The reason this works is that non-Segwit nodes don't see the witness data for Segwit transactions, therefore they don't count it towards the block size.

As of 2018-01-21, there have been several blocks, such as [this one](https://blockstream.info/block/0000000000000000006aa2f22d95f468611794325617b61c29b6abf998e2b912), mined that are greater than 1MB.


---

