<p><strong>No, in the past year, there were only 15 non-empty-non-segwit blocks mined which account for less than 0.03% of all blocks.</strong></p>

<h2>Non-empty blocks without segwit transactions</h2>

<p><a href="https://i.sstatic.net/8601X.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/8601X.png" alt="Last twenty blocks that confirm transactions but don&#39;t include any segwit transactions"></a></p>

<p>I've looked up the last twenty blocks that confirmed transactions but did not include any segwit data. The newest of these was mined on 2018-12-18, more than four months ago. The 21st-newest block in that series was mined on 2018-03-13 at height 513,267. </p>

<p><a href="https://i.sstatic.net/RaKtx.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/RaKtx.png" alt="20th and 21st newest block"></a></p>

<p>Given that we're currently at height 573,220, there were only 20 non-empty blocks that did not include segwit transactions among the last 59,953 blocks. Or put differently, over a period of time exceeding the past year, there were fewer than 0.034% non-empty-non-segwit blocks mined.</p>

<p>The two known miners that created such blocks without segwit transactions appear not to be doing that now:</p>

<p>Bitcoin Russia's last ten blocks were segwit blocks.</p>

<p><a href="https://i.sstatic.net/knHZu.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/knHZu.png" alt="Bitcoin Russia&#39;s last ten blocks"></a></p>

<p>Bitcoin.com's last ten blocks were segwit blocks.</p>

<p><a href="https://i.sstatic.net/GnJbL.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/GnJbL.png" alt="Bitcoin.com&#39;s last ten blocks"></a></p>

<h2>Empty Blocks</h2>

<p>I did not count empty blocks (blocks that contain only a coinbase transaction) as the coinbase transaction has no inputs and therefore cannot be a segwit transaction. However, BIP141 specifies that the Witness Commitment is optional if there is no segwit transaction included. Therefore, there is no reliable way to determine whether or not an empty block is segwit or non-segwit.</p>

<hr>

<p><sup>Images via blockchair.com</sup></p>

CC BY-SA 4.0
2019-04-25T21:20:51.540Z
2019-04-26T16:06:07.837Z
2019-04-26T16:06:07.837Z
Murch
<p>It was well known that initially while SegWit got more than 50% of hashrate after activation that a part of the mining pools refused to implement it.</p>

<p>But are there still blocks being mined by miners which refuse to implement SegWit more than 2 years later ?<br>
For example, is <a href="https://medium.com/@ViaBTC/why-we-dont-support-segwit-91d44475cc18" rel="nofollow noreferrer">this article</a> or <a href="https://newconomy.media/news/reddit-bitmain-controlled-mining-pools-reject-all-segwit-transactions/" rel="nofollow noreferrer">this article</a> still true ?</p>

CC BY-SA 4.0
2019-04-22T15:30:41.107Z
Hey ! Why the downvote ? The question is only about those who do it.
user2284570
CC BY-SA 4.0
2019-04-22T15:41:27.947Z
Don't know why someone downvoted, but here's my question: SegWit2x required 80% of the hashrate signaling readiness to activate and it is reasonable to assume that generally all software that signaled readiness for SegWit2x (e.g. Bitcoin Core or btc1) was actually segwit-capable. IIRC, at activation more than 95% of the blocks were signaling segwit support. So, I'm wondering what you mean when you say "It’s well known that initially while SegWit got more than 50% of hashrate after activation that a large part of the mining pools refused to implement it.".
Murch
CC BY-SA 4.0
2019-04-22T15:58:46.390Z
@Murch ok sorry. Removed the large word. I thought to have read in the news that 30% or 40% of miners in terms of Hashrrate refused the SegWit implementation at activation time but it was still a success.
user2284570
CC BY-SA 4.0
2019-04-22T16:05:48.943Z
You could look at the coinbase transactions of the last blocks to get some data: segwit enabled blocks commit to the witness txids by adding an op_return output in the coinbase transaction. (I think they always add that, but it might only be there if there is at least one segwit transaction, i.e. not present on empty blocks).
Murch
CC BY-SA 4.0
2019-04-22T16:45:41.890Z
@Murch `You could look at the coinbase transactions of the last blocks` the problem is I don’t know how to do this too.
user2284570
CC BY-SA 4.0
2019-04-22T16:54:47.820Z
If it's well known then there is no reason to ask a question about it.
G. Maxwell
CC BY-SA 4.0
2019-04-22T16:59:05.597Z
@G.Maxwell sorry. But thank you, my point is rather “it was”.
user2284570
CC BY-SA 4.0
2019-04-22T17:08:07.830Z
I don't know about any refusal to implement after it was activated.  The only thing like that I know of was bitmain's himming and hawing at first and F2Pool being stuck on a seriously outdated version of Bitcoin because they were on a seriously outdated OS that couldn't handle C++11. Both of those were before activation.
G. Maxwell
CC BY-SA 4.0
2019-04-22T17:18:19.973Z
@G.Maxwell As far I’m aware the Bitmain’s Antpool Saga started after a full year of SegWit activation. But we’re in 2019 now, I’m wondering if it’s still the case.
user2284570
CC BY-SA 4.0
2019-04-22T20:05:00.837Z
I don't think it was the case even shortly after activation either. Its important to distinguish enforcing SW rules from including the txn... the latter required a bunch of updates to mining infrastructure but isn't relevant to consensus. No one has produced a SW invalid block that I'm aware of which is really the only strong test of enforcing the rules.  But all notable miners include transactions using segwit now (they're be missing a lot of fee income if they weren't).
G. Maxwell
CC BY-SA 4.0
2019-04-22T22:55:28.717Z
@G.Maxwell no they wouldn’t be missing fees. If they don’t, they would just process the transactions as anyone can spend. But this isn’t a proof no miners are still refusing SegWit as nodes don’t relay those type of pre‑SegWit transactions anymore.
user2284570
CC BY-SA 4.0
2019-04-22T22:57:50.187Z
They can't because that would be a SW invalid block.
Murch
CC BY-SA 4.0
2019-04-22T22:59:18.707Z
@Murch no. And as far I’m aware SegWit is both backward and upward compatible in terms of block generation. The protection is mostly from nodes not relaying transactions to miners.
user2284570
CC BY-SA 4.0
2019-04-22T23:08:43.007Z
Segwit transactions are backwards compatible in that they can be stripped off the witness and then appear valid to non-segwit full nodes. However, stripped transactions are incomplete in that they're invalid according to the rules of segwit. Including a stripped segwit transaction would be a breach of the consensus rules. Every segwit enabled full node would recognize that block as invalid and reject it.
Murch
CC BY-SA 4.0
2019-04-22T23:29:13.797Z
@Murch if it was true, then it would means if a miner who refuses to implement SegWit treats a SegWit address as anyone can spend as sender they're would be a hard fork. As far I understand SegWit was designed so that they would be no hard fork either from the side implementing SegWit and the side refusing to do it.
user2284570
CC BY-SA 4.0
2019-04-23T08:13:01.717Z
Segwit transactions appear non-standard to non-segwit nodes. They do not propagate them and do not include them into blocks. If a miner did indeed include a stripped Segwit transaction, it would simply cost them the block reward because they mined an invalid block.
Murch
CC BY-SA 4.0
2019-04-23T08:46:34.900Z
@Murch `If a miner did indeed include a stripped Segwit transaction, it would simply cost them the block reward because they mined an invalid block.` Yes and other miners which don’t implement SegWit would treat the block as valid instead of rejecting it, hence a hard fork (hypothetical as we agree nodes wouldn’t relay such transactions).
user2284570
CC BY-SA 4.0
2019-04-23T09:11:22.820Z
Undoing soft fork is always(*) a hard fork.  They'd simply be ignored by everyone else.  Murch's descriptions are (as usual) spot on.   (*undoing doesn't include things like a rule that expires on its own as part of the rule itself).
G. Maxwell
CC BY-SA 4.0
2019-04-23T09:13:35.950Z
@G.Maxwell And as far I’m aware, the plan with SegWit was to not have a possible hard fork as result of the change.
user2284570
CC BY-SA 4.0
2019-04-23T09:18:56.210Z
That doesn't even make logical sense: No consensus rule change can have the properties you're expecting.   Segwit-- like other softforks-- was designed to not split the consensus and it didn't.  That is accomplished by two main properties: It is a strict increase in restrictiveness (making it backwards compatible-- not a hardfork) and it was triggered by forward compatible encoding (cleanstack rule in segwit's case) making it so that old nodes won't accidentally relay or mine invalid transactions.
G. Maxwell
CC BY-SA 4.0
2019-04-23T14:37:29.757Z
Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/92788/discussion-on-question-by-user2284570-are-there-still-miners-or-mining-pool-whic).
Ava Chow
<mining-pools><segregated-witness><hashpower>
Are there still miners or mining pool which refuse to implement SegWit?
user2284570
# Are there still miners or mining pool which refuse to implement SegWit?

(Asked by: username_0 on 2019-04-22)

It was well known that initially while SegWit got more than 50% of hashrate after activation that a part of the mining pools refused to implement it.

But are there still blocks being mined by miners which refuse to implement SegWit more than 2 years later ?  
For example, is [this article](https://medium.com/@ViaBTC/why-we-dont-support-segwit-91d44475cc18) or [this article](https://newconomy.media/news/reddit-bitmain-controlled-mining-pools-reject-all-segwit-transactions/) still true ?

**Tags:** mining-pools, segregated-witness, hashpower

> **Comments:**
> **username_0**: Hey ! Why the downvote ? The question is only about those who do it.  
> **username_1**: Don't know why someone downvoted, but here's my question: SegWit2x required 80% of the hashrate signaling readiness to activate and it is reasonable to assume that generally all software that signaled readiness for SegWit2x (e.g. Bitcoin Core or btc1) was actually segwit-capable. IIRC, at activation more than 95% of the blocks were signaling segwit support. So, I'm wondering what you mean when you say "It’s well known that initially while SegWit got more than 50% of hashrate after activation that a large part of the mining pools refused to implement it.".  
> **username_0**: @username_1 ok sorry. Removed the large word. I thought to have read in the news that 30% or 40% of miners in terms of Hashrrate refused the SegWit implementation at activation time but it was still a success.  
> **username_1**: You could look at the coinbase transactions of the last blocks to get some data: segwit enabled blocks commit to the witness txids by adding an op_return output in the coinbase transaction. (I think they always add that, but it might only be there if there is at least one segwit transaction, i.e. not present on empty blocks).  
> **username_0**: @username_1 `You could look at the coinbase transactions of the last blocks` the problem is I don’t know how to do this too.  
> **username_2**: If it's well known then there is no reason to ask a question about it.  
> **username_0**: @G.username_2 sorry. But thank you, my point is rather “it was”.  
> **username_2**: I don't know about any refusal to implement after it was activated.  The only thing like that I know of was bitmain's himming and hawing at first and F2Pool being stuck on a seriously outdated version of Bitcoin because they were on a seriously outdated OS that couldn't handle C++11. Both of those were before activation.  
> **username_0**: @G.username_2 As far I’m aware the Bitmain’s Antpool Saga started after a full year of SegWit activation. But we’re in 2019 now, I’m wondering if it’s still the case.  
> **username_2**: I don't think it was the case even shortly after activation either. Its important to distinguish enforcing SW rules from including the txn... the latter required a bunch of updates to mining infrastructure but isn't relevant to consensus. No one has produced a SW invalid block that I'm aware of which is really the only strong test of enforcing the rules.  But all notable miners include transactions using segwit now (they're be missing a lot of fee income if they weren't).  
> **username_0**: @G.username_2 no they wouldn’t be missing fees. If they don’t, they would just process the transactions as anyone can spend. But this isn’t a proof no miners are still refusing SegWit as nodes don’t relay those type of pre‑SegWit transactions anymore.  
> **username_1**: They can't because that would be a SW invalid block.  
> **username_0**: @username_1 no. And as far I’m aware SegWit is both backward and upward compatible in terms of block generation. The protection is mostly from nodes not relaying transactions to miners.  
> **username_1**: Segwit transactions are backwards compatible in that they can be stripped off the witness and then appear valid to non-segwit full nodes. However, stripped transactions are incomplete in that they're invalid according to the rules of segwit. Including a stripped segwit transaction would be a breach of the consensus rules. Every segwit enabled full node would recognize that block as invalid and reject it.  
> **username_0**: @username_1 if it was true, then it would means if a miner who refuses to implement SegWit treats a SegWit address as anyone can spend as sender they're would be a hard fork. As far I understand SegWit was designed so that they would be no hard fork either from the side implementing SegWit and the side refusing to do it.  
> **username_1**: Segwit transactions appear non-standard to non-segwit nodes. They do not propagate them and do not include them into blocks. If a miner did indeed include a stripped Segwit transaction, it would simply cost them the block reward because they mined an invalid block.  
> **username_0**: @username_1 `If a miner did indeed include a stripped Segwit transaction, it would simply cost them the block reward because they mined an invalid block.` Yes and other miners which don’t implement SegWit would treat the block as valid instead of rejecting it, hence a hard fork (hypothetical as we agree nodes wouldn’t relay such transactions).  
> **username_2**: Undoing soft fork is always(*) a hard fork.  They'd simply be ignored by everyone else.  username_1's descriptions are (as usual) spot on.   (*undoing doesn't include things like a rule that expires on its own as part of the rule itself).  
> **username_0**: @G.username_2 And as far I’m aware, the plan with SegWit was to not have a possible hard fork as result of the change.  
> **username_2**: That doesn't even make logical sense: No consensus rule change can have the properties you're expecting.   Segwit-- like other softforks-- was designed to not split the consensus and it didn't.  That is accomplished by two main properties: It is a strict increase in restrictiveness (making it backwards compatible-- not a hardfork) and it was triggered by forward compatible encoding (cleanstack rule in segwit's case) making it so that old nodes won't accidentally relay or mine invalid transactions.  
> **username_3**: Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/92788/discussion-on-question-by-username_0-are-there-still-miners-or-mining-pool-whic).  

---

## 1 answers

### Answer by username_1 on 2019-04-25. Score: 5 | Accepted answer

**No, in the past year, there were only 15 non-empty-non-segwit blocks mined which account for less than 0.03% of all blocks.**

## Non-empty blocks without segwit transactions

[![Last twenty blocks that confirm transactions but don't include any segwit transactions](https://i.sstatic.net/8601X.png)](https://i.sstatic.net/8601X.png)

I've looked up the last twenty blocks that confirmed transactions but did not include any segwit data. The newest of these was mined on 2018-12-18, more than four months ago. The 21st-newest block in that series was mined on 2018-03-13 at height 513,267.

[![20th and 21st newest block](https://i.sstatic.net/RaKtx.png)](https://i.sstatic.net/RaKtx.png)

Given that we're currently at height 573,220, there were only 20 non-empty blocks that did not include segwit transactions among the last 59,953 blocks. Or put differently, over a period of time exceeding the past year, there were fewer than 0.034% non-empty-non-segwit blocks mined.

The two known miners that created such blocks without segwit transactions appear not to be doing that now:

Bitcoin Russia's last ten blocks were segwit blocks.

[![Bitcoin Russia's last ten blocks](https://i.sstatic.net/knHZu.png)](https://i.sstatic.net/knHZu.png)

Bitcoin.com's last ten blocks were segwit blocks.

[![Bitcoin.com's last ten blocks](https://i.sstatic.net/GnJbL.png)](https://i.sstatic.net/GnJbL.png)

## Empty Blocks

I did not count empty blocks (blocks that contain only a coinbase transaction) as the coinbase transaction has no inputs and therefore cannot be a segwit transaction. However, BIP141 specifies that the Witness Commitment is optional if there is no segwit transaction included. Therefore, there is no reliable way to determine whether or not an empty block is segwit or non-segwit.

---

Images via blockchair.com


---

