Empty blocks

[jonnybravo0311]

Well, technically, the worst offender in your list is 'unknown'  Earlier you said that where you couldn't determine the pool, you used the coinbase address (presumably if only one found) instead.  Have you tried separating those out? That's how I got the 1KTNE and 1Ar2gR ones in my table.. blocktrail doesn't separate those out (with a few exceptions).

I just got lazy there, to be honest.  Any time I couldn't figure out what the pool was, I just lumped it into "unknown" for the stats.  I could certainly break it down to show every address, but figured it was overkill.  I also just figured out why I didn't identify some of the ckpool solo blocks.  The first blocks coinbase script was simply "ckpool/".  I was looking for "/solo.ckpool.org/".  Doesn't matter though since the ckpool code doesn't allow for empty blocks.

Steve, if you want, I'll tweak things again to pump out all of the addresses.  The vast majority of the empty blocks by "unknown" were from the beginning of the blockchain.  Pretty much every block up to 50,000 is empty.  As a matter of fact, I think the first block I saw with more than 1 transaction was 49,076 (but that was just quickly scrolling through the data and I might have missed an earlier block or two).  It's not until the mid 60k range that we really start to see blocks with more than the coinbase transaction start to outweigh the ones with only the coinbase.

Also, there were a number of blocks found where the coinbase was paid to multiple addresses, but the first address in the list couldn't be decoded.  For example, check out block 157606.

[1715031795]

1715031795

[-ck]

There's a bit of inaccuracy in it, since I know that -ck has recorded 67 blocks found in his solo pool, but I only detected 54... not sure if the coinbase wasn't always signed as it is today, or what the root cause of the discrepancy is.

A private entity had a unique solo instance that was signed avahuobi (but still said ckpool).

[kano]

Tweaked the code a bit more to run some stats.  Ran it again today.  The vast majority of the empty blocks are from the beginning, which is to be expected.  Here's the data broken down by pool:
https://i.imgur.com/QkD1UeJ.png
There's a bit of inaccuracy in it, since I know that -ck has recorded 67 blocks found in his solo pool, but I only detected 54... not sure if the coinbase wasn't always signed as it is today, or what the root cause of the discrepancy is.

Anyway, from the data and ignoring the unknowns, AntPool is by far the worst offender with 4.62% empty blocks.  Next up is KnC with 2.91% and they are virtually tied with discus fish at 2.9%.  That's what I've got.  Not sure how useful it is, but I had fun putting it together

As far as I know, AntPool based their code off Eloipool code.
You'll probably find most of the pools with more than 0.5% empty have done that or simply use Eloipool as it is.

[TheRealSteve]

I could certainly break it down to show every address, but figured it was overkill.

I think if you kept every single one - certainly since the beginning - that would be quite a few  Was just wondering if you had that information already and just chose to lump them together under 'Unknown' after the fact.

Also, there were a number of blocks found where the coinbase was paid to multiple addresses, but the first address in the list couldn't be decoded.  For example, check out block 157606.

Odd - then again, early blocks.. who knows if something was broken there.

A private entity had a unique solo instance that was signed avahuobi (but still said ckpool).

I think I saw a few that had 'ckpool' in the scriptSig, without it being detected as kano on blocktrail, or solo via the scriptSig.  I ended up lumping those together under CKPool/other.

Examples:
ckpool/Kano: Block 360242 / https://www.blocktrail.com/BTC/tx/f8f596c2ef4fe49c2ebe0727ceefa017a43bd2081b0571cfd52229e746afe189
ckpool/solo.ckpool.org: Block 360687 / https://www.blocktrail.com/BTC/tx/c618ff74a23b343e84c0185d24695045358495c49cd030c6e974e99c19632a69
ckpool/mined by devastra/: Block 360419 / https://www.blocktrail.com/BTC/tx/b78ba888133ac4c496759490b14199903678eed2a0746f929232e7b6eb7555f4
ckpool/NiceHashSolo: Block 360224 / https://www.blocktrail.com/BTC/tx/778724d38cfec7dc8782621cd8d0d9f09e4a7c1a1f82a66ddbdda698ef3b9433
ckpool: Block 353625 / https://www.blocktrail.com/BTC/tx/c9b538f11484781f7b40b59c026e8a2763d878bbac25396dc413d782feb4d35b
ckpool: Block 352116 / https://www.blocktrail.com/BTC/tx/13f836bcbc1c6dc952bef00dea5de38096bb85a3f148faff6f62c285d7441d1d

[jonnybravo0311]

I could certainly break it down to show every address, but figured it was overkill.

I think if you kept every single one - certainly since the beginning - that would be quite a few  Was just wondering if you had that information already and just chose to lump them together under 'Unknown' after the fact.

Also, there were a number of blocks found where the coinbase was paid to multiple addresses, but the first address in the list couldn't be decoded.  For example, check out block 157606.

Odd - then again, early blocks.. who knows if something was broken there.

A private entity had a unique solo instance that was signed avahuobi (but still said ckpool).

I think I saw a few that had 'ckpool' in the scriptSig, without it being detected as kano on blocktrail, or solo via the scriptSig.  I ended up lumping those together under CKPool/other.

Examples:
ckpool/Kano: Block 360242 / https://www.blocktrail.com/BTC/tx/f8f596c2ef4fe49c2ebe0727ceefa017a43bd2081b0571cfd52229e746afe189
ckpool/solo.ckpool.org: Block 360687 / https://www.blocktrail.com/BTC/tx/c618ff74a23b343e84c0185d24695045358495c49cd030c6e974e99c19632a69
ckpool/mined by devastra/: Block 360419 / https://www.blocktrail.com/BTC/tx/b78ba888133ac4c496759490b14199903678eed2a0746f929232e7b6eb7555f4
ckpool/NiceHashSolo: Block 360224 / https://www.blocktrail.com/BTC/tx/778724d38cfec7dc8782621cd8d0d9f09e4a7c1a1f82a66ddbdda698ef3b9433
ckpool: Block 353625 / https://www.blocktrail.com/BTC/tx/c9b538f11484781f7b40b59c026e8a2763d878bbac25396dc413d782feb4d35b
ckpool: Block 352116 / https://www.blocktrail.com/BTC/tx/13f836bcbc1c6dc952bef00dea5de38096bb85a3f148faff6f62c285d7441d1d

I've got the data for every block... I got lazy with lumping things together

[kano]

...
Examples:
ckpool/Kano: Block 360242 / https://www.blocktrail.com/BTC/tx/f8f596c2ef4fe49c2ebe0727ceefa017a43bd2081b0571cfd52229e746afe189
...

Well that was my pool's last block found ... and it says /Kano in the coinbase

[TheRealSteve]

Well that was my pool's last block found ... and it says /Kano in the coinbase

Yeah, that - and the solo one - were two examples that did get recognized  Should have been clearer about that.  It's the next four that caught my attention

[kano]

Well running ckpool on it's own (without ckdb) is as easy as, for almost anyone without too much expertise to do.
Of course there are other issues - but they are the same for anyone running any pool.
There are a few pools that have used it and probably then changed the line of code that says ckpool after finding 1 or more blocks.
I know of at least 4 - even BW.com has used it for quite a few blocks - but not sure if they now only use ckpool or what else they use.

[TheRealSteve]

default string leftovers?  reasonable assumption

[kano]

Why the Eligius empty block excuse is a scam:
https://bitcointalk.org/index.php?topic=789369.msg11638137#msg11638137

[Lauda]

I don't think that this discussion went in the right way. In general I believe that people don't know if empty blocks are good or bad (neither do I). Instead of discussing the total amount of empty blocks someone should try to explain this in a single post that we can relate to in the future.
I'm not really interested in the exact number, however looking at the picture we can clearly see that AntPool has the highest percentage.

Empty blocks aren't useless as they confirm previous transactions and secure them further against attacks. Though, they are much less useful than normal blocks. I am assuming the 23% number is skewed by 2009 and 2010 blocks which were mosly empty due to not having actual transactions rather than being empty on purpose by miners. 25 out of 1000 last which makes 2.5% seem much more right to work on.
I think miners shouldn't mine empty blocks because they would lose tx fee and make people await more time for their tx to be included in the chain. Why do some pools do that? Is there an advantage?

Can someone confirm this or elaborate the usefulness of empty blocks?

[jonnybravo0311]

I don't think that this discussion went in the right way. In general I believe that people don't know if empty blocks are good or bad (neither do I). Instead of discussing the total amount of empty blocks someone should try to explain this in a single post that we can relate to in the future.
I'm not really interested in the exact number, however looking at the picture we can clearly see that AntPool has the highest percentage.

Empty blocks aren't useless as they confirm previous transactions and secure them further against attacks. Though, they are much less useful than normal blocks. I am assuming the 23% number is skewed by 2009 and 2010 blocks which were mosly empty due to not having actual transactions rather than being empty on purpose by miners. 25 out of 1000 last which makes 2.5% seem much more right to work on.
I think miners shouldn't mine empty blocks because they would lose tx fee and make people await more time for their tx to be included in the chain. Why do some pools do that? Is there an advantage?

Can someone confirm this or elaborate the usefulness of empty blocks?

It's a debate that has supporters on both sides of the argument.  I am pretty firmly entrenched on the side that believes empty blocks are a waste if they are added simply to add a block to the chain.  Now, if there really are no transactions to be included - which was the case quite a bit at the beginning of the block chain - then, by all means if you find a valid solution add the block, because as chalkboard17 points out, even an empty block provides value in securing the blockchain.

Some pools are coded in such a way as to provide empty blocks to their miners until the pool can properly provide transactions.  Whether this is a limitation of the language in which the pool is written, the inability of the pool's coder(s) to properly include transaction, or some other factor, it's wrong.  Kano has provided very clear evidence that the claims of "we do it this way because it's faster" that the empty block guys stand on is indeed patently false.

Since there are almost always plenty of transactions to be included in a block, then I believe it is up to the pool to properly include those transactions in any work it provides to miners.  Creating a block just for the sake of creating a block because your pool can't push work out quickly enough is an excuse for poorly coded software and not a valid reason.  Why should all those transactions have to wait another ~10 minutes to be included on the blockchain?

[kano]

So I've continue this Eligius vs my pool https://kano.is/ comparison
... and I'll repeat: feel free to try this yourself, point 2 cgminers: one at kano.is and the other at eligius to see the block change notifications

I am of course still getting faster block change information from kano.is than from Eligius - well OVER 90%
No wonder the eligius pool luck is so bad.
The block change information from kano.is is a block of transactions that are available after the block change.
The block change information you get from Eligius is an empty block ... but still slower.

I've got over 5.5 days non-stop of stats and I will add, that for 12 hours on my pool a few days ago the stats went crap again for my pool - regularly 10-15s slower than eligius for around 12 hours (that's why I say over 90% and not over 98% as it usually is)
When I've seen a few blocks more than a few seconds slower than Eligius I KNOW something is wrong and do something about it,
since I also know eligius sux slow at block changes and if my pool is slower that means something must be wrong.
That particular 12 hours was a side effect of me not seeing a particular problem ... that I wont miss seeing again

There was an interesting 1.5 hours today (6 hours ago), where Eligius sent no block changes ... mining was still running along fine ... on the old block for 1 hour after it changed (it was a slow network block of about 0.5 hrs - plus 1 hr of mining on it stale from eligius)

Maybe the fact that they don't have someone full time looking after the pool means things go to crap and no one cares

Now there's yet another issue about all this.
Any pool mining using the standard bitcoin uses an RPC function called getblocktemplate()
Here's the actual commit:
https://github.com/bitcoin/bitcoin/commit/3390014fd0d91b0148425e794ac01c10b646a682
Yeah not much of a code change, but of course which name is on it?
Luke-Jr
The same guy who bypasses using it on block changes coz he says it's too slow
Gotta love the ignorant lack of change control on that one
I will also add that the code could be written to provide a block of transactions faster on a block change ... but that is clearly beyond his mcdonalds burger flipping skills where he used to work.

--

Edit: sigh - and on Eligius today they say how they've finished changing stuff and no one should have noticed anything.
Of course no one noticed anything, coz they hid the fact that part of that was an hour of mining stale blocks i.e. the whole pool was mining rubbish for an hour (as stated above) that could only find orphans

Update of my stats for the last 150 blocks:
mining on Eligius has been 1,345 seconds (more than 22 minutes) of stale mining when compared to kano.is
with still >90% of eligius block changes slower than kano.is (making up that 22 minutes)

[kano]

Another update

Last 326 blocks:
95% of Eligius block changes were slower than https://kano.is/
( only 5 of the 326 block changes were slower on https://kano.is/ )

So, if you were mining at Eligius, almost half an hour of mining on stale work in the last 326 blocks.

Clearly their empty blocks are not relevant to the argument they hide behind.

[TheRealSteve]

or at the very least has negligible impact considering other delays

For something slightly more generic on the topic: https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-6-data-propagation

[kano]

... actually
If I get time to, some time soon, I may start up a thread about that.
Specifically comparing pool block change times.

Even big pools like AntPool use Eloipool and also merge mine.
I'd not be surprised if they have crap average block change times also.
I doubt any pools in the past have even bothered to look into this - or if they have, may have got bad results they didn't want to report about their pools.

An expectation of >1% orphans seems quite high ... when the block average is expected to be 600s per block (or less when diff is rising)

I would not be surprised at all if my pool was one of the fastest, on average, to send out block changes.
Will be interesting to see how quickly other pools - not using eloipool - handle block changes - eloipool is slow so it may be a bit pointless comparing it running on other pools.

Although it's only been 254 blocks, the number of orphans at https://kano.is/ is only 0.8% (2) - and my ckdb reports ALL block shares submitted to the pool before it knows about a block change, no matter what bitcoin says about them - there are no 'hidden orphans'.
We've only had 2 so far, one back when the pool started, and one since then that was an example of what other pools may not show, where the block was late for the network, but not late for the pool - yes sometimes network blocks can take a few seconds to get to the pool

ckpool work handling by -ck is fast, but I also monitor the information relevant to block changes and act on it
(yeah my pool even wakes me up in one of the rare cases that causes block delays)

[Mikestang]

I doubt any pools in the past have even bothered to look into this - or if they have, may have got bad results they didn't want to report about their pools.

This would be a very interesting study to compare block change times across several pools, the information could be very useful.  Not only might it help people decide where to send their hash (one reason anyway), but it might also motivate other devs to improve their pool code.

[el kaka22]

Today, there is a stress test on bitcoin, and lots of transactions have been made (>7k unconfirmed as of the time of writing), however there are still empty block: https://blockchain.info/block/0000000000000000088390da860e3624e9c6f3162dcce3f2f166bb371e018de7 (height=363266). So I don't think empty blocks should exist as they make people waiting for confirmations wait even longer!

[Peter R]

360629 blocks, 85311 are empty.  I zipped it up because with every block the file was about 22MB.  If anyone wants to check it out, you can find it here: https://www.dropbox.com/s/gduh8oafyqzi57t/empty_blocks.csv.zip?dl=0

The format is:
Height,NumTx,DateTime,WhoMined

Enjoy.

Great work!

I'd love to do some statistical hypothesis testing on the data in this file, but the link seems to be broken.  Any chance you could repost the raw data?  

[jonnybravo0311]

360629 blocks, 85311 are empty.  I zipped it up because with every block the file was about 22MB.  If anyone wants to check it out, you can find it here: https://www.dropbox.com/s/gduh8oafyqzi57t/empty_blocks.csv.zip?dl=0

The format is:
Height,NumTx,DateTime,WhoMined

Enjoy.

Great work!

I'd love to do some statistical hypothesis testing on the data in this file, but the link seems to be broken.  Any chance you could repost the raw data?  

I took the file down a while ago... let me run it again and get you the most up-to-date data.  I'll post a link as soon as it's done.