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 ?
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.
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.
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.com's last ten blocks were segwit 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
Hey ! Why the downvote ? The question is only about those who do it. – user2284570 – 2019-04-22T15:30:41.107
1Don'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 – 2019-04-22T15:41:27.947
@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 – 2019-04-22T15:58:46.390
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 – 2019-04-22T16:05:48.943
@Murch
You could look at the coinbase transactions of the last blocksthe problem is I don’t know how to do this too. – user2284570 – 2019-04-22T16:45:41.890If it's well known then there is no reason to ask a question about it. – G. Maxwell – 2019-04-22T16:54:47.820
@G.Maxwell sorry. But thank you, my point is rather “it was”. – user2284570 – 2019-04-22T16:59:05.597
1I 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 – 2019-04-22T17:08:07.830
@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 – 2019-04-22T17:18:19.973
1I 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 – 2019-04-22T20:05:00.837
@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 – 2019-04-22T22:55:28.717
3They can't because that would be a SW invalid block. – Murch – 2019-04-22T22:57:50.187
@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 – 2019-04-22T22:59:18.707
2Segwit 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 – 2019-04-22T23:08:43.007
@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 – 2019-04-22T23:29:13.797
1Segwit 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 – 2019-04-23T08:13:01.717
@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 – 2019-04-23T08:46:34.9003Undoing 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 – 2019-04-23T09:11:22.820
@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 – 2019-04-23T09:13:35.950
3That 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 – 2019-04-23T09:18:56.210
Comments are not for extended discussion; this conversation has been moved to chat.
– Andrew Chow – 2019-04-23T14:37:29.757