At least 1 other pool has never mined an empty block - KanoPool.
Various excuses are used by some to justify mining empty blocks with the most common being that 'it takes significant time' to verify the last block and verify new tx's so it can be faster to just send out empty work. Long ago Luke Jr's eligus pool did it claiming it took up to 10sec or more to verify - maybe his crappy pool software or the fact that even back then he was examining tx's and censoring those he did not like was the reason for the excessive time?
Fact is, for the past decade or so verification takes less than 100ms so there is really no excuse for empty blocks.
Depends on how much other security you are doing.
Quoting myself from last year:
Taking it a bit past what was said above.
IF they are doing it properly and that is a big IF a large pool is running several nodes all over the world, when a block comes in they all should start validating it. Once a certain percentage of them agree then and only then do they start building the new block for the pool.
Loosing the fees even now is better then building a invalid block that gets rejected.
AND not broadcasting an empty block as soon as possible risks loosing it too.
It just comes down to routing. It takes about 1/2 a second to send 1 packet of data around the world without doing any kind of firewall / security inspection in an ideal setting.
Allowing for the nodes to verify what is in the block, and sending it back out is another couple of seconds and then start building a new block. If all is ideal you should have a new block ready to go in 10 seconds or so.
BUT, if you are waiting for minimum of 3 of 5 to do their thing you might add a few seconds on top of that.
Add in a bloated memory pool and some DPI From firewalls and you add a few seconds again.
All of a sudden you are looking at more time to build a block.
Even now there are 2 schools of thought with what happened with what happened with foundry the other day.
Some people including Kano are saying that they tried to orphan a couple of blocks.
Others are saying that they saw foundrys blocks 1st.
It has always been the way it works.
And part of the problem is that even if you understand
BTC perfectly, unless you understand the true issues of internet routing and the true delays that proper DPI can put into network performance then it's never going to seem logical as to what happened.
Dave's pool can put it's nodes out there in public.
A corporation with all kinds of security requirements probably has 3 layers of security devices looking at all data coming in before it even hits the node to be processed. Dave's node has seen, and processed the block before it has even gotten through the security devices of some places. On the flip side, it's a lot harder to take out big corps node(s) by flooding them with bad data since it never even makes it into the network.
-Dave
* DPI = deep packet inspection.
https://www.fortinet.com/resources/cyberglossary/dpi-deep-packet-inspectionAnd it's still true today. My LN node that is sitting out on a public IP running on an RPi has seen and just about finished processing a block BEFORE my node running on a 9th gen i7 has even seen the block because in front of the i7 are 2 separate security appliances sitting in series that take a look at the data before passing it back. So sometimes it bad programming, and sometimes it's a deliberate decision.
Side note, if you look in the Ocean thread you can see I have no love for them. So I am not defending them here. Just pointing out that it's not as simple as 'bad node setup' it can be that simple but you don't know.
-Dave