1

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 or this article still true ?

  • 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.". – Murch Apr 22 at 15:41
  • 3
    They can't because that would be a SW invalid block. – Murch Apr 22 at 22:57
  • 2
    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 Apr 22 at 23:08
  • 3
    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 Apr 23 at 9:11
  • 3
    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 Apr 23 at 9:18
5

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

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

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

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

Bitcoin.com's last ten blocks

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.