As explained by others before and above (DaveF's one the easiest to understand), if you're a miner, it's all about balancing your books. If a few seconds matter, and the higher likelihood of a block reward outweighs the fees, even I'd go for it.
I've wondered myself in the past if "overpaying" fees is a way of tipping, to convince miners back then when empty blocks were more common, to include these high-fee txs.
Topic: Why can't other pools do the same as solo.ckpool to not mine empty blocks? (Read 209 times)
June 19, 2024, 10:50:46 AM
June 19, 2024, 08:20:59 AM
some things to note:
most empty blocks occur due to the fact that when a previous block is solved. its takes time for nodes to properly switch transactions out of a nodes mempool of spent transactions now confirmed and then collate new transactions. many pools wait until their peers have also confirmed the block to update their blockheight to come to an agreement between connected peers that they all agree the newest block just broadcast passed all the tests..
this delay is where by pool managers did send out a blockheader with no normal transactions bar the coinbase tx. and then when all tests pass and enough peers agree they then send out a blockheader to their miners with a merkle hash containing transactions that are still unspent(unconfirmed)
so when you look at all the empty blocks and see the previous block is solved not so long ago(seconds to at most a couple mins) its more to do with the process of quantifying if the last block passed the tests network wide before working on new transactions.. and not a case of wanting to ignore transactions for the sake of ignoring transactions
as for things CKpool does that other pools dont
smaller pools never solve blocks in quick succession to some other pools block due to lack of hashpower. so smaller pools wont solve a block in seconds to have a empty block, so the lack of empty block is more due to the session time of validating a block and solving it being different to other pools who can solve blocks faster
most empty blocks occur due to the fact that when a previous block is solved. its takes time for nodes to properly switch transactions out of a nodes mempool of spent transactions now confirmed and then collate new transactions. many pools wait until their peers have also confirmed the block to update their blockheight to come to an agreement between connected peers that they all agree the newest block just broadcast passed all the tests..
this delay is where by pool managers did send out a blockheader with no normal transactions bar the coinbase tx. and then when all tests pass and enough peers agree they then send out a blockheader to their miners with a merkle hash containing transactions that are still unspent(unconfirmed)
so when you look at all the empty blocks and see the previous block is solved not so long ago(seconds to at most a couple mins) its more to do with the process of quantifying if the last block passed the tests network wide before working on new transactions.. and not a case of wanting to ignore transactions for the sake of ignoring transactions
as for things CKpool does that other pools dont
smaller pools never solve blocks in quick succession to some other pools block due to lack of hashpower. so smaller pools wont solve a block in seconds to have a empty block, so the lack of empty block is more due to the session time of validating a block and solving it being different to other pools who can solve blocks faster
I would say enough geographically dispersed peers agree.
Most larger pools do not just have stratum servers all over the world but they also have nodes all over the world too.
Having US East and US West and EU agree is great but if an bunch of Asian nodes are seeing something different then it's worth mining an empty block vs one that may be rejected.
-Dave
June 18, 2024, 01:40:08 PM
some things to note:
most empty blocks occur due to the fact that when a previous block is solved. its takes time for nodes to properly switch transactions out of a nodes mempool of spent transactions now confirmed and then collate new transactions. many pools wait until their peers have also confirmed the block to update their blockheight to come to an agreement between connected peers that they all agree the newest block just broadcast passed all the tests..
this delay is where by pool managers did send out a blockheader with no normal transactions bar the coinbase tx. and then when all tests pass and enough peers agree they then send out a blockheader to their miners with a merkle hash containing transactions that are still unspent(unconfirmed)
so when you look at all the empty blocks and see the previous block is solved not so long ago(seconds to at most a couple mins) its more to do with the process of quantifying if the last block passed the tests network wide before working on new transactions.. and not a case of wanting to ignore transactions for the sake of ignoring transactions
as for things CKpool does that other pools dont
smaller pools never solve blocks in quick succession to some other pools block due to lack of hashpower. so smaller pools wont solve a block in seconds to have a empty block, so the lack of empty block is more due to the session time of validating a block and solving it being different to other pools who can solve blocks faster
most empty blocks occur due to the fact that when a previous block is solved. its takes time for nodes to properly switch transactions out of a nodes mempool of spent transactions now confirmed and then collate new transactions. many pools wait until their peers have also confirmed the block to update their blockheight to come to an agreement between connected peers that they all agree the newest block just broadcast passed all the tests..
this delay is where by pool managers did send out a blockheader with no normal transactions bar the coinbase tx. and then when all tests pass and enough peers agree they then send out a blockheader to their miners with a merkle hash containing transactions that are still unspent(unconfirmed)
so when you look at all the empty blocks and see the previous block is solved not so long ago(seconds to at most a couple mins) its more to do with the process of quantifying if the last block passed the tests network wide before working on new transactions.. and not a case of wanting to ignore transactions for the sake of ignoring transactions
as for things CKpool does that other pools dont
smaller pools never solve blocks in quick succession to some other pools block due to lack of hashpower. so smaller pools wont solve a block in seconds to have a empty block, so the lack of empty block is more due to the session time of validating a block and solving it being different to other pools who can solve blocks faster
June 17, 2024, 03:51:53 PM
As OP said: It's not a lack of blocks. Since 2014 KanoPool has mined 2437 blocks and Kano has said a few times that the pool has mined only 2 empty blocks over that time. Those were only because mempool was empty - no tx's waiting to be processed.
Any decent high-end server is more than fast enough to produce new work with all tx's validated. As an aside, Kano's main server runs dual XEON CPU's with 96 cores/256GB memory so it should be a safe bet that the major pools have at least that or more horsepower running.
Any decent high-end server is more than fast enough to produce new work with all tx's validated. As an aside, Kano's main server runs dual XEON CPU's with 96 cores/256GB memory so it should be a safe bet that the major pools have at least that or more horsepower running.
June 17, 2024, 07:42:34 AM
~snip~
Also, it could be just lack of blocks.
In the last 7 months (since they started) Ocean has found 43 blocks.
In the last 7 months Kano has found 3 blocks. 2 of them solo and 1 of them PPLNS
If we want to get back to 43 blocks for kano you are looking at 5 1/2 years.
Look at it this way. If every block ocean has mined was empty and as a miner you switched from kano to ocean as soon as they came alive you are still making a lot more mining @ ocean then mining at kano.
-Dave
Also, it could be just lack of blocks.
In the last 7 months (since they started) Ocean has found 43 blocks.
In the last 7 months Kano has found 3 blocks. 2 of them solo and 1 of them PPLNS
If we want to get back to 43 blocks for kano you are looking at 5 1/2 years.
Look at it this way. If every block ocean has mined was empty and as a miner you switched from kano to ocean as soon as they came alive you are still making a lot more mining @ ocean then mining at kano.
-Dave
I don't think it is lack of blocks. If you look at Ocean, 2 of their last 15 blocks have been empty mined. Here is their list: https://ocean.xyz/dashboard and here are the two empty ones:
https://mempool.space/block/844208
https://mempool.space/block/842828
That's quite a high rate of empty blocks.
And actually I quite like Ocean, specially their ability to pay with lightning.
But the point still stands, empty blocks are a waste of time for people making transactions, they shouldn't really be happening. Also the miners get less fees.
June 17, 2024, 07:23:45 AM
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.
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.
So, again, a small pool operator, just one person, kano, coding it and it ends up with no empty blocks.
In comparison, all these mega companies with massive amounts of resources, and they don't manage to write a proper pool that doesn't mine empty blocks?
How is that possible?
I mean, even solo ckpool code is open source. The code is just there.
There must be some kind of reason, but I don't know why. Mining an empty block makes no sense at all, I see that as a bug really.
Also, it could be just lack of blocks.
In the last 7 months (since they started) Ocean has found 43 blocks.
In the last 7 months Kano has found 3 blocks. 2 of them solo and 1 of them PPLNS
If we want to get back to 43 blocks for kano you are looking at 5 1/2 years.
Look at it this way. If every block ocean has mined was empty and as a miner you switched from kano to ocean as soon as they came alive you are still making a lot more mining @ ocean then mining at kano.
-Dave
June 17, 2024, 07:22:01 AM
~snip~
It's faster to mine an empty block. If a miner wants to mine a block with transactions, it has to verify the recent block. It takes some seconds but during these seconds, miner can mine an empty block before it fully verifies the last block. When they are lucky, they mine an empty block during these seconds. Mining an empty block vs full block is like risking 3.125 block reward for additional 0.15-0.30 bitcoins (at the moment this is the average fee that one block collects from transactions).
It's faster to mine an empty block. If a miner wants to mine a block with transactions, it has to verify the recent block. It takes some seconds but during these seconds, miner can mine an empty block before it fully verifies the last block. When they are lucky, they mine an empty block during these seconds. Mining an empty block vs full block is like risking 3.125 block reward for additional 0.15-0.30 bitcoins (at the moment this is the average fee that one block collects from transactions).
solo ckpool states that they verify the last block in parallel, so it greatly minimizes the chances of mining an empty block (I guess you can always get two blocks in a row, so in that case even if you do the verification in parallel it won't be fast enough)
~snip~
I don't understand the math of mining an empty block is faster than mining a block with is not empty but includes many transactions.
The computational quiz for miners to solve and find a new block does not depend on whether that block is empty or not empty. Transactions are other things to be add to the block, after miners from that mining pool finds that block.
So is mining empty block is faster than not empty block, are you sure about this?
I don't understand the math of mining an empty block is faster than mining a block with is not empty but includes many transactions.
The computational quiz for miners to solve and find a new block does not depend on whether that block is empty or not empty. Transactions are other things to be add to the block, after miners from that mining pool finds that block.
So is mining empty block is faster than not empty block, are you sure about this?
Solving the block is done independent of the transactions. So, it takes the same amount of time.
The difference is if the pool first verifies the previous block to create the transactions of the next block, and while doing that, other pool simply mines an empty block because they didn't bother "wasting" time verifying the previous block to create the transactions of the new block.
Mining an empty block is silly because lots of people want to put their transactions there, and that opportunity to charge those fees in that block is gone forever. But I guess many pools simply do constant hashing, without always validating the previous block.
June 17, 2024, 06:22:45 AM
It's faster to mine an empty block. If a miner wants to mine a block with transactions, it has to verify the recent block. It takes some seconds but during these seconds, miner can mine an empty block before it fully verifies the last block. When they are lucky, they mine an empty block during these seconds. Mining an empty block vs full block is like risking 3.125 block reward for additional 0.15-0.30 bitcoins (at the moment this is the average fee that one block collects from transactions).
I don't understand the math of mining an empty block is faster than mining a block with is not empty but includes many transactions.The computational quiz for miners to solve and find a new block does not depend on whether that block is empty or not empty. Transactions are other things to be add to the block, after miners from that mining pool finds that block.
So is mining empty block is faster than not empty block, are you sure about this?
June 17, 2024, 05:38:05 AM
There are many questions besides why other pools don't do the same. My question usually is, why miners join pools like AntPool that don't share reward collected via transaction fees?
It's faster to mine an empty block. If a miner wants to mine a block with transactions, it has to verify the recent block. It takes some seconds but during these seconds, miner can mine an empty block before it fully verifies the last block. When they are lucky, they mine an empty block during these seconds. Mining an empty block vs full block is like risking 3.125 block reward for additional 0.15-0.30 bitcoins (at the moment this is the average fee that one block collects from transactions).
It's faster to mine an empty block. If a miner wants to mine a block with transactions, it has to verify the recent block. It takes some seconds but during these seconds, miner can mine an empty block before it fully verifies the last block. When they are lucky, they mine an empty block during these seconds. Mining an empty block vs full block is like risking 3.125 block reward for additional 0.15-0.30 bitcoins (at the moment this is the average fee that one block collects from transactions).
June 17, 2024, 04:31:30 AM
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?
If he claimed that before SegWit activation, his claim might be true due to quadratic verification time. See https://bitcoin.stackexchange.com/a/54552.
Fact is, for the past decade or so verification takes less than 100ms so there is really no excuse for empty blocks.
But these days some mining pool include TX which never propagated (usually non-standard and their own TX), which is valid excuse for empty blocks.
June 17, 2024, 04:29:53 AM
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.
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.
So, again, a small pool operator, just one person, kano, coding it and it ends up with no empty blocks.
In comparison, all these mega companies with massive amounts of resources, and they don't manage to write a proper pool that doesn't mine empty blocks?
How is that possible?
I mean, even solo ckpool code is open source. The code is just there.
There must be some kind of reason, but I don't know why. Mining an empty block makes no sense at all, I see that as a bug really.
June 16, 2024, 10:17:21 PM
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.
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-inspection
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-inspection
And 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
June 16, 2024, 09:22:45 PM
At least 1 other pool has never mined an empty block (without good reason) - 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.
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.
June 16, 2024, 09:35:43 AM
Miners always prefer a filled block to an empty one because the reward is bigger on filled blocks, but an empty block is better than nothing.
The Empty blocks shouldn't exist, if there are transactions to confirm then the empty blocks are useless for the blockchain, the miners don't get that extra reward from fees, and the users need to wait for the next blocks to get that confirmation. But as you mention, it keeps happening, maybe in the future we will see an update in the blockchain to avoid this kind of blocks.
The Empty blocks shouldn't exist, if there are transactions to confirm then the empty blocks are useless for the blockchain, the miners don't get that extra reward from fees, and the users need to wait for the next blocks to get that confirmation. But as you mention, it keeps happening, maybe in the future we will see an update in the blockchain to avoid this kind of blocks.
June 16, 2024, 09:09:33 AM
Is there something fundamentally different in how solo ckpool is run that cannot be replicated in these other pools?
The big mining pools really cares about the money (bitcoin). If you mine an empty block, you will not get the transaction fees reward but you will get the mining reward which is now 3.125 BTC. So those big pools and most other pools will prefer to mine an empty block and earn 3.125 BTC than not to mine a block at all when they supposed to mine a block.
June 16, 2024, 08:36:43 AM
While checking out solo mining on Ocean XYZ, I noticed they mined empty blocks from time to time, like this one: https://mempool.space/block/842828
I then checked for other blocks and realized that this seems to happen to pretty much all the pools, as you can see by ordering the latest blocks by transaction number. All these are empty blocks, mined by different pools: "https://blockchair.com/bitcoin/blocks?s=transaction_count(asc)"
When you go to the solo ckpool website, it states:
And it seems that in fact ckpool hasn't mined empty blocks.
My question is, how is it possible that this small pool run by one person, Con Kolivas, can manage to write code so that the miners never get an empty block but massive companies like Binance and others still produce empty blocks?
Is there something fundamentally different in how solo ckpool is run that cannot be replicated in these other pools?
I then checked for other blocks and realized that this seems to happen to pretty much all the pools, as you can see by ordering the latest blocks by transaction number. All these are empty blocks, mined by different pools: "https://blockchair.com/bitcoin/blocks?s=transaction_count(asc)"
When you go to the solo ckpool website, it states:
Quote from: https://solo.ckpool.org/
Unlike regular pools, ckpool never mines transaction-free blocks due to its ultra-scalable code which has miners on both new blocks and transactions concurrently.
And it seems that in fact ckpool hasn't mined empty blocks.
My question is, how is it possible that this small pool run by one person, Con Kolivas, can manage to write code so that the miners never get an empty block but massive companies like Binance and others still produce empty blocks?
Is there something fundamentally different in how solo ckpool is run that cannot be replicated in these other pools?
Jump to: