You post things that you claim
Please post information you can at least substantiate.

You are ignoring facts and the most obvious of those is the fact that my pool has found 2429 blocks so far.
No empty blocks in there.

In fact, my code reports ANY work generated that is ever empty, of the work generated once every 30 seconds over the years.
Over the life of my pool, that would amount to less than you can count on one hand.
You obviously do not understand how work is generated by a pool and how a block can be empty, without the pool purposely producing an empty block like most of the large pools still do.

You like to ignore the facts when posted, since it doesn't suit your argument, so I'll post it here:


As I have also stated to you before, I make my bitcoin debug.log report the transaction information for each work it generates, and I can also see in the bitcoin debug.log what is available in the first work after any block change.

Please stop posting like you're an expert, and research what you claim, before you decide to post incorrect information to promote your argument.

There is a lot more to the issue of orphans, again that you clearly do not know or understand, or have ignored

P.S. I'm probably older than you

Edit: the above is of course actually related to this thread.
The reason being that the OP of that other pool is ignoring this information (and the information about orphans that I will reply to him later) and thus increasing the risk to his miners.

Well that's if you are simply doing first grade math, counting and comparing block counts to the large pools with many more blocks.
Also a common mistake made by many bitcoin novices about mining pools.

I also understand the statistics of bitcoin and mining more than most people on the forum.
My pool provides more statistical analysis of it's results than any other pool.
I also do more statistical analysis of the pools results to check miners, that would appear to be beyond the understanding of any of the other pools, and many who've argued about pool statistics with me

The total number of bitcoin blocks ever found is (at this point) 631862.
That's 25913% more, for the entire network over all time
No pool has even close to a third of that.
Yaw out by possibly up to 2 orders of magnitude
Even as a guess, that's pretty far off ...
When you go on about your mathematical prowess because you are using one of poisson's formulas that has nothing to do with your argument, I guess it's not odd you'd be ok at throwing out a random, highly inaccurate, uneducated guess, that you suggest is conservative, but is a massive over estimate, in the same post

Incorrect.
Empty blocks have to do with the time between the last work generation sent to the miner that found the block, before finding a block, and the next work generation once your pool found a block.
The transactions that appear on the network during that time (or unused in the block) decide it ... as I have already stated ... and you clearly ignored or could not understand.

You used it incorrectly, it's not relevant.

The "maybe" statement is correct and also a pretty accurate value, it's just that I've not looked for a while at how many there have been, since it's been so long since I've even seen one.

It doesn't matter how big or how small my pool is, my pool is part of the bitcoin network and sees the same transactions as every other well connected pool on the network - though mine is most likely the most well connected of all pools
(the other pool OP is also misunderstanding what needs to be done to handle this correctly)

When a block change occurs, my pool will ALWAYS see every transaction that was in the block, that's how bitcoin works.
It will also see what transactions were left over and available to use mining for the next block in the new work it will send out to the pool's miners.
This is the time gap/number of available transactions that decides if pools MUST generate an empty block with the new work they send to their miners.
This number is the "maybe" less than half a dozen in the past many years.
Until you understand what that means, please refrain from posting incorrect information about it.

Please research before you post.

What the other pools do, to purposefully produce empty blocks, is to not use a template with transactions generated by bitcoind, but simply generate work based on the hash of the block just found on the network, and nothing more - they cannot include transactions in the work when they do this, since they don't already know which network transactions have already been included in the block they don't want to get the transaction details of.
i.e. they aren't seeing the full block before producing a new block work template for their miners.

This was the cause of the failed/incorrect fork by Bitmain and F2Pool in 2015 - they lost all their 5 or 6 blocks on that bad fork since they built new blocks, on a fork of the network based on an invalid block, produced by another pool that ignored the network rule changes.

You could probably force most of the current large pools onto an invalid fork by mining a block with an invalid transaction in it

Yet again, ignoring what I have posted here already that is the correct information.

The guy in the video is incorrect from the start.
He starts off on a false premise:
00:16 "It takes 15-20 seconds at least to validate a block"
False - it takes less than 200ms, often a lot less
Ask any of the bitcoin core developers and they will agree that it does not take anywhere near 15-20 seconds.
I'll give info further below that shows this also.

He is using the 15-20 second (false) claim, that the miners would be working on old stale work for an extended period of time before they could provide them with new work, if they waited for the block to be processed.
This ridiculously large time is false.
The whole first five minutes of his explanation is based on this premise which is wrong.
I gave up watching at that point.

Again, it takes less than 200ms from receiving a block in bitcoind, until it can produce a full new block template with transactions.
I have a message in debug.log when the block arrives with a timestamp to microseconds, another when it has been processed, and another when the pool has been sent the new work - yeah that's an extra step also - but the full time delay.

The largest block in the last 8 hours was 631950 it was 1783877 bytes.
bitcoind debug.log shows (as I mentioned)

Also of interest in this case, it had to extend some disk space for the block.

Total time from when it arrived until the pool got new work 19:07:54.174358 - 19:07:53.985131 = 189227 microseconds 189 milliseconds

As for empty blocks, the one I see in the last 8 hours is 631926 by ViaBTC
I'll include the block before as well for more information:
In this case firstly, you can see the block before it was 20 seconds before it.
Secondly, in this case the work kano.is generated included 1933 transactions and fees: 0.18324281 BTC
However as can be seen from the next block on the block chain, it was only 315 bytes  ... instead of our "block weight: 3964991"
i.e. our work that miners were working on was a full block, but ViaBTC miners were working on an empty block when they found it.

It took 196639 microseconds to process i.e. 197 milliseconds

Seriously, there's no point finding random online videos or random belief in some person (myself as well if you don't want to) about how bitcoin works.

Go run a bitcoind yourself and you can see this information - though you'll have to patch it and recompile it to display the extra information

I've been around in bitcoin since 2011 working on code related to it.
Working on mining code, pool code, and even simple patches to bitcoin itself.

Edit: corrected the 2nd block information - I showed the wrong block

Edit2: and of course it didn't take 197 milliseconds longer than ViaBTC - they didn't process it in 0ms