Firstly the obvious: empty blocks are not necessary - as I explained above:
https://bitcointalksearch.org/topic/m.63821149
which is why my pool will never mine an empty block unless there are no transactions available at the time.
The amount of empty blocks found, simply depends on how long miners, on all the pools that make empty blocks, mine empty blocks.
(which almost all the pools mine empty blocks)
If all miners and all pools mined them for 1 second, then on average, 1 in 600 blocks would be empty.
If a pool is slow to send the non-empty forced work block update, then the miners must wait until that update, to switch from mining an empty block.
If the miner itself is ignoring the work flag to force switching work, then that would be the case on all pools on the network mining with antminers
- which happens to be a pretty big % of miners.
The only 2 ways it could be directly related to antpool are:
1) antpool doesn't send a forced stratum work update when they send the non-empty block work (i.e. their pool programmers are idiots)
OR
2) antpool and antminers have extra code to identify the mining on antpool and act differently
However, as already explained, none of this is necessary, so we shouldn't be seeing empty blocks anyway.
(my pool code logs when there are no transactions available and it is VERY rare)
Topic: How does Foundry USA pool avoid mining empty blocks? (Read 414 times)
The answer has possibly been found.
Antminer had some (likely intentional) code in their firmware that made their miners stay for longer times when mining an empty block, even when they were given new work. This likely solves the speculation. This was a trick by antminer to likely gain an edge on competition by hampering profits of others. Foundry obviously must have been running their own firmware or had a secret deal with antminer (if they even used ant miners). If they didn't use any antminer hardware at all then then they wouldn't need antminer firmware to have this problem.
https://x.com/GrassFedBitcoin/status/1796311998466003418
According to the above there was a fix even pushed by antminer while they were getting exposed so hopefully in the future we'll see much fewer empty blocks.
Antminer had some (likely intentional) code in their firmware that made their miners stay for longer times when mining an empty block, even when they were given new work. This likely solves the speculation. This was a trick by antminer to likely gain an edge on competition by hampering profits of others. Foundry obviously must have been running their own firmware or had a secret deal with antminer (if they even used ant miners). If they didn't use any antminer hardware at all then then they wouldn't need antminer firmware to have this problem.
https://x.com/GrassFedBitcoin/status/1796311998466003418
According to the above there was a fix even pushed by antminer while they were getting exposed so hopefully in the future we'll see much fewer empty blocks.
No pool does what is described above.
Since it is 'prediction' that means there is the chance of it being wrong.
Thus the pool would be mining an invalid block, until they corrected the mistake.
My bitcoin logs would show these invalid blocks coming from these large pools also.
Building a block beforehand doesn't save anything worth doing ...
The time to fully process a block on my pool is less than 100ms.
Thus any pool that can do a block change in 0ms (which isn't possible), will only gain one extra block, every 6000 blocks they find, vs my pool.
i.e. a 0.0167% gain. Though it will be lower again coz nothing takes zero time to do.
Orphans are not common any more, so discussions about large pools winning against small pools is pretty much pointless and irrelevant.
People keep quoting ridiculously large times to do block changes like 5-10 seconds.
The average time to do block changes will determine how often orphan races occur.
If it was 10s then there would be 10/600 % of blocks being orphan races i.e. 1.7% i.e. about 2.4 orphan races EVERY SINGLE DAY.
Clearly that is not the case. Yes some pools will do slow changes - a minority - crappy pools with badly written code and poor network connections.
Even if it was 3 seconds, the expected number of orphan races would be about 1 every 1.4 days - which is not the case either.
Since it is 'prediction' that means there is the chance of it being wrong.
Thus the pool would be mining an invalid block, until they corrected the mistake.
My bitcoin logs would show these invalid blocks coming from these large pools also.
Building a block beforehand doesn't save anything worth doing ...
The time to fully process a block on my pool is less than 100ms.
Thus any pool that can do a block change in 0ms (which isn't possible), will only gain one extra block, every 6000 blocks they find, vs my pool.
i.e. a 0.0167% gain. Though it will be lower again coz nothing takes zero time to do.
Orphans are not common any more, so discussions about large pools winning against small pools is pretty much pointless and irrelevant.
People keep quoting ridiculously large times to do block changes like 5-10 seconds.
The average time to do block changes will determine how often orphan races occur.
If it was 10s then there would be 10/600 % of blocks being orphan races i.e. 1.7% i.e. about 2.4 orphan races EVERY SINGLE DAY.
Clearly that is not the case. Yes some pools will do slow changes - a minority - crappy pools with badly written code and poor network connections.
Even if it was 3 seconds, the expected number of orphan races would be about 1 every 1.4 days - which is not the case either.
...
Jameson Lopp reviewed empty blocks a few years ago
https://blog.lopp.net/empty-bitcoin-blocks-full-mempool/
In that review, only ViaBTC was mining empty blocks, which implies all the other pools had implemented the next+2 mechanism
More recent observations indicate that other pools are now mining empty blocks
Clearly wrong since most large pools have mined empty blocks for a long time. Jameson Lopp reviewed empty blocks a few years ago
https://blog.lopp.net/empty-bitcoin-blocks-full-mempool/
In that review, only ViaBTC was mining empty blocks, which implies all the other pools had implemented the next+2 mechanism
More recent observations indicate that other pools are now mining empty blocks
Does Foundry construct block templates beyond the next block in case they mine two blocks consecutively?
I was once told, by someone who was involved in making this work, that most pools build 2 blocks in advance, by predicting which transactions are not going to be mined, and constantly update these predictive blocks
This mechanism was developed collaboratively in 2016, by several pools, and improved iteratively to reduce the incidence of invalid blocks
The issue with the delay at the start of mining a new block is not verification. It is ensuring that the candidate block does not contain any confirmed transactions. A pool can not build a candidate block from the mempool without removing the just-confirmed transactions from the mempool. But the pool can guess with a reasonably high certainty, by choosing lowest-fee-rate transactions for its initial candidate block
And then after 50 seconds or so, the pool replaces the initial block with a fee-optimized block
Jameson Lopp reviewed empty blocks a few years ago
https://blog.lopp.net/empty-bitcoin-blocks-full-mempool/
In that review, only ViaBTC was mining empty blocks, which implies all the other pools had implemented the next+2 mechanism
More recent observations indicate that other pools are now mining empty blocks
But there's a big IF here.
Does Foundry construct block templates beyond the next block in case they mine two blocks consecutively?
We can find the likely answer to this question by looking if they have mined two closely adjacent blocks.
I remember though, AntPool has mined empty blocks even when they were the ones to have also mined the previous one. So even if feasible, other big pools don't utilize such technique.
Does Foundry construct block templates beyond the next block in case they mine two blocks consecutively?
We can find the likely answer to this question by looking if they have mined two closely adjacent blocks.
I remember though, AntPool has mined empty blocks even when they were the ones to have also mined the previous one. So even if feasible, other big pools don't utilize such technique.
There is a risk of starting on the next block beforehand.
Which is You find a block, within a couple of seconds someone else finds the next block, a couple of seconds after that you find your next block which contains transactions that the other pool mined because you had already been working on it for 3 or 4 seconds. You now have an invalid block.
It's a very very very (add a few more very) small risk but still there. Someone with better math skills can probably come up with the % of hash you have to have to make that risk / reward amount work.
Keep in mind the people behind foundry have deep pockets. They probably do have some math guy sitting in a cube figuring out all kinds of things like this.
-Dave
There is another thing to consider for Foundry specifically, and you've already mentioned it - they are the biggest pool.
Since they are the biggest pool, they are finding the largest proportion of blocks. Every time they mine a block themselves, they don't need to go through the process of receiving the block over the network and verifying every transaction in it, because they already did all that when they constructed the candidate block in the first place. So every time they mine a block themselves, there is zero time before they can create a new candidate block filled with transactions (and indeed, they probably already have it constructed and waiting in reserve, just requiring to insert the hash of the previous block).
Interesting. Since they are the biggest pool, they are finding the largest proportion of blocks. Every time they mine a block themselves, they don't need to go through the process of receiving the block over the network and verifying every transaction in it, because they already did all that when they constructed the candidate block in the first place. So every time they mine a block themselves, there is zero time before they can create a new candidate block filled with transactions (and indeed, they probably already have it constructed and waiting in reserve, just requiring to insert the hash of the previous block).
Indeed this is a factor I didn't consider.
So if there's an x chance to find a block before the newest one has been received and fully verified, knowing what's in the block if it was mined by you could also mean that you can also construct the next block template safely.
So the risk factor is x minus your percentage of the network's total hash power.
But there's a big IF here.
Does Foundry construct block templates beyond the next block in case they mine two blocks consecutively?
We can find the likely answer to this question by looking if they have mined two closely adjacent blocks.
I remember though, AntPool has mined empty blocks even when they were the ones to have also mined the previous one. So even if feasible, other big pools don't utilize such technique.
There is another thing to consider for Foundry specifically, and you've already mentioned it - they are the biggest pool.
Since they are the biggest pool, they are finding the largest proportion of blocks. Every time they mine a block themselves, they don't need to go through the process of receiving the block over the network and verifying every transaction in it, because they already did all that when they constructed the candidate block in the first place. So every time they mine a block themselves, there is zero time before they can create a new candidate block filled with transactions (and indeed, they probably already have it constructed and waiting in reserve, just requiring to insert the hash of the previous block).
Since they are the biggest pool, they are finding the largest proportion of blocks. Every time they mine a block themselves, they don't need to go through the process of receiving the block over the network and verifying every transaction in it, because they already did all that when they constructed the candidate block in the first place. So every time they mine a block themselves, there is zero time before they can create a new candidate block filled with transactions (and indeed, they probably already have it constructed and waiting in reserve, just requiring to insert the hash of the previous block).
No, that's not the way mining works.
It's very simple to avoid mining empty blocks, you just have to take the risk of loosing a block to another miner.
I made this thread about Foundry in specific because to me it's logical that they being the biggest mining pool would not be willing to take this risk. It's very simple to avoid mining empty blocks, you just have to take the risk of loosing a block to another miner.
Naturally, the larger a pool becomes, the larger the opportunity cost of having certain chances of losing a block.
So, with network security measures as you mention, can that risk be minimized to an extent that it's negligible even for a pool that has ~1/3rd of the hashrate?
Because if not, they might be doing something else.
because we are entering a new era. ie rewards suck and fees are much more important then rewards.
Here is why, 48 blocks made in a day on a two-five second delay means no empty blocks ever.
so 48 sets of fees and we are at 1 btc or more in fees that is 48 coins and never get a zero fee.
They have weighed antpools short cut method and have worked and getting a slower hit .
This happened in 2023 and yeah antpool got 5 maybe ten empty blocks losing 1 or 2 or 3 coins in fees.
but with the delay move each would have had 1-3 coins in fees. that is a certain loss of 5 to 15 coins worth of fees.
and the 5 empty blocks via shortcut method does not mean they would not have gotten 1 or 2 of them anyway.
Now 2024 1/2 is coming and getting a fast block will only be 3.125 coins. and losing. 1 or 2 or 3 coins in fees is bigger
that is my take on this foundry is fully prepping for 2024 ½ ing.
See my reply in the Ocean thread regarding this
Summary: pools have prebuilt blocks cached to be used as soon as they get a New Block Found msg on the network. If the pool is the one that found the previous block after broadcasting the New Block found msg to the network they will immediately begin working on their cached new block.
Yes, it is *possible* that the new block work may be superseded if a different previous block gets more confirmations before the one used in the new work but that is the very reason why it is a very bad idea to view a tx as 'confirmed' before it gets at least 3 additional confirmations and why it takes 101 confirmations to be considered irrevocably confirmed. Competing blocks are AKA as Orphan races which are soon resolved as more pools hop onto one or the other competing blocks.
I'm sure that Kano who was a primary dev (but not lead - that was Con Klovias) for the ckpool software can explain the process better but the OP seems to take great umbrage when reading what Kano has to say about pool operations...
Summary: pools have prebuilt blocks cached to be used as soon as they get a New Block Found msg on the network. If the pool is the one that found the previous block after broadcasting the New Block found msg to the network they will immediately begin working on their cached new block.
Yes, it is *possible* that the new block work may be superseded if a different previous block gets more confirmations before the one used in the new work but that is the very reason why it is a very bad idea to view a tx as 'confirmed' before it gets at least 3 additional confirmations and why it takes 101 confirmations to be considered irrevocably confirmed. Competing blocks are AKA as Orphan races which are soon resolved as more pools hop onto one or the other competing blocks.
I'm sure that Kano who was a primary dev (but not lead - that was Con Klovias) for the ckpool software can explain the process better but the OP seems to take great umbrage when reading what Kano has to say about pool operations...
No, that's not the way mining works.
It's very simple to avoid mining empty blocks, you just have to take the risk of loosing a block to another miner.
I made this thread about Foundry in specific because to me it's logical that they being the biggest mining pool would not be willing to take this risk. It's very simple to avoid mining empty blocks, you just have to take the risk of loosing a block to another miner.
Naturally, the larger a pool becomes, the larger the opportunity cost of having certain chances of losing a block.
So, with network security measures as you mention, can that risk be minimized to an extent that it's negligible even for a pool that has ~1/3rd of the hashrate?
Because if not, they might be doing something else.
You are looking at it the wrong way:
With the assumption that they have the security measures in place they will probably have fewer (or no) empty blocks.
All the data is sifted and filtered before being passed back to their nodes. Because of that their nodes shuold have more time to think about the next block.
The downside is, that while they are scanning the data and cross checking that all their nodes agree some other pool found the next block and they have to start all over again.
Or by the time they do get all the data though and then they find a block they loose an orphan race because even though some other pool got the block *after* them by the time theirs made it out to the internet the block from the other pool had already been out and broadcast for a second or 2.
They are a large pool with a large staff. They are going to be more concerned about the risk of a hack / breach/ attack then some smaller pool run by just a couple of people. The potential cost of loosing a block or two a year is a lot less then the cost of a network intrusion.
-Dave
No, that's not the way mining works.
It's very simple to avoid mining empty blocks, you just have to take the risk of loosing a block to another miner.
I made this thread about Foundry in specific because to me it's logical that they being the biggest mining pool would not be willing to take this risk. It's very simple to avoid mining empty blocks, you just have to take the risk of loosing a block to another miner.
Naturally, the larger a pool becomes, the larger the opportunity cost of having certain chances of losing a block.
So, with network security measures as you mention, can that risk be minimized to an extent that it's negligible even for a pool that has ~1/3rd of the hashrate?
Because if not, they might be doing something else.
No, that's not the way mining works.
It's very simple to avoid mining empty blocks, you just have to take the risk of loosing a block to another miner.
Figuring it's about 3 to 10 seconds to get in the old block, verify it, and send it to a bunch of divergent nodes around the world to agree upon it and then you start mining a block with transactions.
During those few seconds you can either
1) mine an empty block
2) risk loosing a mined block because someone who did #1 found it before you.
The above is a VERY basic way of describing it. There are a lot more details and nuances involved.
See below for more.
-Dave
It's very simple to avoid mining empty blocks, you just have to take the risk of loosing a block to another miner.
Figuring it's about 3 to 10 seconds to get in the old block, verify it, and send it to a bunch of divergent nodes around the world to agree upon it and then you start mining a block with transactions.
During those few seconds you can either
1) mine an empty block
2) risk loosing a mined block because someone who did #1 found it before you.
The above is a VERY basic way of describing it. There are a lot more details and nuances involved.
See below for more.
-Dave
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 nodes 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 nodes 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 you were to monitor all empty blocks that have been miner by bitcoin tools, you'd come to the realization that Foundry, which is currently the biggest pool, has not in fact miner any emty blocks throughout its existence:
https://blockchair.com/bitcoin/blocks?q=time(2009-01-01%2000:00:00..2023-12-31%2023:59:59),transaction_count(1)#f=time,guessed_miner,transaction_count,size,id
This is an interesting metric if we consider that empty blocks are mined for a reason:
So how is Foundry able to avoid mining empty blocks?
An interesting theory I heard was that when a new block is mined, while it gets propagated to be verified by all other miners, Foundry is probably pointing their miners towards another pool, and then return them to their own.
This way effectively the pool doesn't appear to be mining any empty blocks themselves, but if the pool they pointed their hash to mines one, it'll be labeled under that different pool's name.
https://blockchair.com/bitcoin/blocks?q=time(2009-01-01%2000:00:00..2023-12-31%2023:59:59),transaction_count(1)#f=time,guessed_miner,transaction_count,size,id
This is an interesting metric if we consider that empty blocks are mined for a reason:
When a node receives a block from somewhere else, it has to spend a little bit of time verifying that block, checking every transaction in the block is correct and accurate, and then updating its set of unconfirmed outputs to remove all the outputs which have just been spent and add all the new outputs which have just been created. This doesn't take long - usually in the order of a few seconds depending on your hardware - but it isn't instant.
While this is happening, a miner cannot create a new block filled with transactions to work on, because it doesn't know which transactions it can and cannot include until it verifies which transactions have just been mined in the block it just received. So for these few seconds, the miner's options are either to have their mining equipment sit idle and do nothing, or attempt to mine an empty block until they have fully verified the last block. Since having their equipment sit idle would be a waste of money, most miners attempt to mine an empty block for a few seconds until they create a normal block filled with transactions and then switched to trying to mine that instead. Very occasionally a miner will be successful in these few seconds and will mine an empty block.
While this is happening, a miner cannot create a new block filled with transactions to work on, because it doesn't know which transactions it can and cannot include until it verifies which transactions have just been mined in the block it just received. So for these few seconds, the miner's options are either to have their mining equipment sit idle and do nothing, or attempt to mine an empty block until they have fully verified the last block. Since having their equipment sit idle would be a waste of money, most miners attempt to mine an empty block for a few seconds until they create a normal block filled with transactions and then switched to trying to mine that instead. Very occasionally a miner will be successful in these few seconds and will mine an empty block.
So how is Foundry able to avoid mining empty blocks?
An interesting theory I heard was that when a new block is mined, while it gets propagated to be verified by all other miners, Foundry is probably pointing their miners towards another pool, and then return them to their own.
This way effectively the pool doesn't appear to be mining any empty blocks themselves, but if the pool they pointed their hash to mines one, it'll be labeled under that different pool's name.
Jump to: