<p>Mining pools occasionally mine &quot;empty blocks&quot; when they find a sufficiently low hash in the brief time-frame between hearing about a new block, verifying the new block, and pushing out new block templates to build on top of it to the miners. These blocks will often be &quot;empty&quot; in the sense that they will only contain the mandatory coinbase transaction.  Since the coinbase transaction only has to have a witness commitment if the block includes any transactions with witness data (see <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Commitment_structure" rel="nofollow noreferrer">BIP141</a>), we can't tell for empty blocks whether they were mined by segwit or non-segwit miners. So given that the coinbase transaction doesn't necessarily contain any segwit data, I would not count these empty blocks as bonafide &quot;non-segwit&quot; blocks.</p>
<p>I would therefore interpret your question as asking for the last block that included more transactions than just the coinbase transaction, but did not include any transactions with witness data. This is what I found, when I searched for blocks fulfilling those criteria:</p>
<p><a href="https://i.sstatic.net/ayMWo.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ayMWo.png" alt="Screenshot from blockchair.com showing the latest blocks with no witness data and more than 1 transaction" /></a></p>
<p>The latest such block was mined on 2020-04-18 at height 626,507. This block had three transactions, two non-segwit transactions, and a coinbase transaction. I've verified that the coinbase transaction of block 626,507 does not have a witness commitment, so it's a bonafide non-segwit block.</p>
<p>Now you might say: &quot;But wait, only two additional transactions? That were probably just new transactions the mining pool sent, so they were sure that nobody else could have included them yet, and it's really basically an empty block&quot;.</p>
<p>In that case, the last non-segwit block was 616,561 which had 2,992 transactions, but not a single transaction among them has any witness data. Neither does the coinbase transaction have a witness commitment.</p>
<p>Given that both these blocks are almost and more than two years old, I think it's safe to say that <strong>the network today has no non-segwit hashrate</strong> (or it is only mining empty blocks).</p>

CC BY-SA 4.0
2024-04-20T16:48:58.947Z
A URL for this query: [https://blockchair.com/](https://blockchair.com/bitcoin/blocks?s=witness_count(asc)&q=transaction_count(2..),witness_count(0)#f=id,hash,time,guessed_miner,output_total,output_total_usd,fee_total,fee_total_usd,size,witness_count,transaction_count)
Lee
CC BY-SA 4.0
2022-02-16T19:48:34.807Z
2022-02-16T19:48:34.807Z
Murch
<p>There is an important distinction here: just because a block has no segwit spends, does not mean the miner that created it is a 'non-segwit miner'. Such blocks may be formed incidentally, by miners that otherwise are aware of and follow the segwit rules.</p>
<p>Saying a miner is a 'non-segwit miner' implies that they would not follow the segwit consensus rules when crafting blocks. This means that they would allow transactions that spend segwit outputs, without providing segwit signatures. Such blocks would be considered invalid by the majority of the network (ie, all nodes that are aware of the segwit consensus rules), and thus would be ignored by all of those nodes.</p>
<p>So really, we should expect there to be <strong>no</strong> 'non-segwit miners' since the segwit soft-fork activated (<a href="https://bitcoin.stackexchange.com/questions/61482/what-was-the-number-of-the-block-in-which-segwit-got-activated-and-first-transa">block 481,824</a> was the first to include segwit-rule-following transactions), as any such miner would be constantly at risk of creating blocks which would be seen as invalid by most of the network. Creating such blocks would mean that miner was just wasting resources, with basically no chance of gaining any reward.</p>

CC BY-SA 4.0
2022-02-15T04:34:06.103Z
Note that Bitcoin Core releases from the few years before 0.13.1 (the version that had segwit mainnet support) would not include segwit transactions in their mined blocks due to policy rules, and thus be able to participate without being forked off.
Pieter Wuille
CC BY-SA 4.0
2022-02-15T10:55:47.947Z
A non segwit miner can still mine a block that contains 0 segwit tx and still be valid or I am missing a point ?
SadPepo
CC BY-SA 4.0
2022-02-15T12:47:48.447Z
Yes, exactly. Non-segwit miners can produce valid blocks. Of course, they could be tricked into building on top of a segwit-invalid block too, since they cannot validate that.
Pieter Wuille
CC BY-SA 4.0
2022-02-15T04:31:41.277Z
2022-02-15T04:31:41.277Z
chytrik
<p>I wanted to know what the last non-segwit block mined is, and if there are still some non-segwit miners?</p>

CC BY-SA 4.0
2022-02-15T10:52:29.170Z
Thanks ! Any easy way to check all blocks with 0 segwit tx ?
SadPepo
CC BY-SA 4.0
2022-02-16T19:52:09.280Z
@Prayank: Well, but it's also an empty block. Even a segwit miner wouldn't need to include a witness commitment in an empty block.
Murch
<bitcoin-core><segregated-witness><miner-configuration>
What is the last non-segwit block mined?
SadPepo
# What is the last non-segwit block mined?

(Asked by: username_0 on 2022-02-15)

I wanted to know what the last non-segwit block mined is, and if there are still some non-segwit miners?

**Tags:** bitcoin-core, segregated-witness, miner-configuration

> **Comments:**
> **username_0**: Thanks ! Any easy way to check all blocks with 0 segwit tx ?  
> **username_1**: @Prayank: Well, but it's also an empty block. Even a segwit miner wouldn't need to include a witness commitment in an empty block.  

---

## 2 answers

### Answer by username_1 on 2022-02-16. Score: 2

Mining pools occasionally mine "empty blocks" when they find a sufficiently low hash in the brief time-frame between hearing about a new block, verifying the new block, and pushing out new block templates to build on top of it to the miners. These blocks will often be "empty" in the sense that they will only contain the mandatory coinbase transaction. Since the coinbase transaction only has to have a witness commitment if the block includes any transactions with witness data (see [BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Commitment_structure)), we can't tell for empty blocks whether they were mined by segwit or non-segwit miners. So given that the coinbase transaction doesn't necessarily contain any segwit data, I would not count these empty blocks as bonafide "non-segwit" blocks.

I would therefore interpret your question as asking for the last block that included more transactions than just the coinbase transaction, but did not include any transactions with witness data. This is what I found, when I searched for blocks fulfilling those criteria:

[![Screenshot from blockchair.com showing the latest blocks with no witness data and more than 1 transaction](https://i.sstatic.net/ayMWo.png)](https://i.sstatic.net/ayMWo.png)

The latest such block was mined on 2020-04-18 at height 626,507. This block had three transactions, two non-segwit transactions, and a coinbase transaction. I've verified that the coinbase transaction of block 626,507 does not have a witness commitment, so it's a bonafide non-segwit block.

Now you might say: "But wait, only two additional transactions? That were probably just new transactions the mining pool sent, so they were sure that nobody else could have included them yet, and it's really basically an empty block".

In that case, the last non-segwit block was 616,561 which had 2,992 transactions, but not a single transaction among them has any witness data. Neither does the coinbase transaction have a witness commitment.

Given that both these blocks are almost and more than two years old, I think it's safe to say that **the network today has no non-segwit hashrate** (or it is only mining empty blocks).

> **Comments:**
> **username_2**: A URL for this query: [https://blockchair.com/](https://blockchair.com/bitcoin/blocks?s=witness_count(asc)&q=transaction_count(2..),witness_count(0)#f=id,hash,time,guessed_miner,output_total,output_total_usd,fee_total,fee_total_usd,size,witness_count,transaction_count)  

---

### Answer by username_3 on 2022-02-15. Score: 1

There is an important distinction here: just because a block has no segwit spends, does not mean the miner that created it is a 'non-segwit miner'. Such blocks may be formed incidentally, by miners that otherwise are aware of and follow the segwit rules.

Saying a miner is a 'non-segwit miner' implies that they would not follow the segwit consensus rules when crafting blocks. This means that they would allow transactions that spend segwit outputs, without providing segwit signatures. Such blocks would be considered invalid by the majority of the network (ie, all nodes that are aware of the segwit consensus rules), and thus would be ignored by all of those nodes.

So really, we should expect there to be **no** 'non-segwit miners' since the segwit soft-fork activated ([block 481,824](https://bitcoin.stackexchange.com/questions/61482/what-was-the-number-of-the-block-in-which-segwit-got-activated-and-first-transa) was the first to include segwit-rule-following transactions), as any such miner would be constantly at risk of creating blocks which would be seen as invalid by most of the network. Creating such blocks would mean that miner was just wasting resources, with basically no chance of gaining any reward.

> **Comments:**
> **username_4**: Note that Bitcoin Core releases from the few years before 0.13.1 (the version that had segwit mainnet support) would not include segwit transactions in their mined blocks due to policy rules, and thus be able to participate without being forked off.  
> **username_0**: A non segwit miner can still mine a block that contains 0 segwit tx and still be valid or I am missing a point ?  
> **username_4**: Yes, exactly. Non-segwit miners can produce valid blocks. Of course, they could be tricked into building on top of a segwit-invalid block too, since they cannot validate that.  

---

