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 
Topic: Empty blocks - page 8. (Read 22955 times)
Should have been clearer about that. It's the next four that caught my attention 
...
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 Examples:
ckpool/Kano: Block 360242 / https://www.blocktrail.com/BTC/tx/f8f596c2ef4fe49c2ebe0727ceefa017a43bd2081b0571cfd52229e746afe189
...
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
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:
http://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.http://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
You'll probably find most of the pools with more than 0.5% empty have done that or simply use Eloipool as it is.
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). 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. 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). 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.
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).
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).
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:
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
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
The DateTime in the block header is not when the block was found.
It's close, but, far from exact. It's within about 1.5 hours.
Some pools used to push this number a long way ahead - close to 1/1.5 hours.
There's still some pretty egregious differences between the time in the block and what's probably the actual time. The actual actual time can't be determined, but for my graph above I ended up using the time that blocktrail saw the block announced. Much smaller deviations there.It's close, but, far from exact. It's within about 1.5 hours.
Some pools used to push this number a long way ahead - close to 1/1.5 hours.
...
If the pool is putting out work close to the actual actual time, then the case for putting out empty blocks would depend on, over a large sample, showing what that delay is: making a full block vs an empty block.
That delay should be very small - and thus invalidate doing it.
If it's not, then that's a software problem.
Next there is the issue of how do you decide to put out an empty block early?
If you decide based on the arrival of the block before it has been validated, then that means that the block you are switching to may not be valid.
However, there's something that no doubt no one has bothered to look at (I do mean Eligius clearly has never bothered to look at) and that is to verify something else to prove their theory about why they say it's OK to send out empty blocks.
If their pool is putting out empty blocks AFTER other pools are putting out full blocks, then they have no argument at all for doing it.
I've checked this. They do put out most of their block change information slower.
(Yeah that really does mean no one should be mining at Eligius)
The DateTime in the block header is not when the block was found.
It's close, but, far from exact. It's within about 1.5 hours.
Some pools used to push this number a long way ahead - close to 1/1.5 hours.
There's still some pretty egregious differences between the time in the block and what's probably the actual time. The actual actual time can't be determined, but for my graph above I ended up using the time that blocktrail saw the block announced. Much smaller deviations there.It's close, but, far from exact. It's within about 1.5 hours.
Some pools used to push this number a long way ahead - close to 1/1.5 hours.
Just a cursory glance at the file reveals some pretty big "empty block" offenders... AntPool and f2pool are the leaders in that metric.
Still fairly small, percentage-wise. I think it was around 2% of all blocks in that last ~10,000 blocks. 2% more than I'd like to see, but not entirely horrible, Heh, now for another of those things you might not have known about bitcoin 
The DateTime in the block header is not when the block was found.
It's close, but, far from exact. It's within about 1.5 hours.
Some pools used to push this number a long way ahead - close to 1/1.5 hours.
So you will find blocks in the blockchain with DateTime out of order.
That's sometimes referred to as roll-n-time in pool/mining software.
Actually that one I did know. Unfortunately I don't have actual block times so I had to make due with what info was available in the block header The DateTime in the block header is not when the block was found.
It's close, but, far from exact. It's within about 1.5 hours.
Some pools used to push this number a long way ahead - close to 1/1.5 hours.
So you will find blocks in the blockchain with DateTime out of order.
That's sometimes referred to as roll-n-time in pool/mining software.
Just a cursory glance at the file reveals some pretty big "empty block" offenders... AntPool and f2pool are the leaders in that metric.
Heh, now for another of those things you might not have known about bitcoin
The DateTime in the block header is not when the block was found.
It's close, but, far from exact. It's within about 1.5 hours.
Some pools used to push this number a long way ahead - close to 1/1.5 hours.
So you will find blocks in the blockchain with DateTime out of order.
That's sometimes referred to as roll-n-time in pool/mining software.
The DateTime in the block header is not when the block was found.
It's close, but, far from exact. It's within about 1.5 hours.
Some pools used to push this number a long way ahead - close to 1/1.5 hours.
So you will find blocks in the blockchain with DateTime out of order.
That's sometimes referred to as roll-n-time in pool/mining software.
So I tweaked things a bit. Now the file will contain every block, how many transactions were in the block, when the block was found and who found it (if I could discern that, otherwise it shows the payout address from the coinbase transaction). It's currently executing and I'll upload the file when it's done.
EDIT:
It's done and uploaded. 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.
EDIT:
It's done and uploaded. 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.
Probably what needs to be added would be a running avg of txn per block to show when there were basically no blocks early on.
I didn't track every block, just the empty ones. However tracking them all and including number of transactions per block is pretty easily accomplished.
Probably what needs to be added would be a running avg of txn per block to show when there were basically no blocks txns early on.
Edit: fixed typo
Edit: fixed typo
OK... I rebuilt everything and ran it again. For any blocks that I couldn't identify the pool, I listed the payout address.
As of block 360520, there are a total of 85307 empty blocks. The raw data is here: https://www.dropbox.com/s/tisp9mj6a369dds/empty_blocks.csv?dl=0
As of block 360520, there are a total of 85307 empty blocks. The raw data is here: https://www.dropbox.com/s/tisp9mj6a369dds/empty_blocks.csv?dl=0
Gotcha. I've got a ticket open with Blocktrail, so hopefully I can just re-run that with their API later.
They found the bug on their end and fixed it earlier today, so here's an updated table:
For the three biggest 'offenders', I did an additional check for block time deltas. A very short time between blocks can mean that A. there were no transactions in the mempool to include, B. there were no attractive transactions to include, C. they included no transactions for other reasons.
The 245 second one for F2Pool was an outlier. Still, given the great number of transactions existing in the mempool and being added all the time, 20-30 seconds for a coinbase-only block seems unnecessary.
Here's some other semi-relevant graphs...
AntPool and BTC China adjusting their max block size after the recent (and on-going) debate:
See also: http://www.reddit.com/r/Bitcoin/comments/39f59k/aftermath_of_may_29_stress_test_btc_china_antpool/
Discus Fish / F2Pool's possible strategy on 'empty blocks + fill with transactions later' (note 100KB lines):
...
Now for a stupid question... and I only say it's stupid because I've been mining on p2pool for well over a year and don't know the answer myself... is p2pool the only pool to use "/P2SH/" in the coinbase? I swear I saw that in the coinbase of another... maybe I'm wrong and that really is the p2pool identifier. Guess I'll find out when I run my code and do some checks.
I used to identify it last, due to it having so many coinbase addresses, and the 'other' pool that sometimes had many was already identified by name.Now for a stupid question... and I only say it's stupid because I've been mining on p2pool for well over a year and don't know the answer myself
... is p2pool the only pool to use "/P2SH/" in the coinbase? I swear I saw that in the coinbase of another... maybe I'm wrong and that really is the p2pool identifier. Guess I'll find out when I run my code and do some checks.I'm pretty sure the last address in the p2pool coinbase that shows up as invalid on blockchain is also a way to identify p2pool.
Looks like I'll have to use something other than /P2SH/ since block 360476 has /P2SH/ in the coinbase and it's not a p2pool block. Guess I'll do more checks in p2pool's case.
...
Now for a stupid question... and I only say it's stupid because I've been mining on p2pool for well over a year and don't know the answer myself... is p2pool the only pool to use "/P2SH/" in the coinbase? I swear I saw that in the coinbase of another... maybe I'm wrong and that really is the p2pool identifier. Guess I'll find out when I run my code and do some checks.
I used to identify it last, due to it having so many coinbase addresses, and the 'other' pool that sometimes had many was already identified by name.Now for a stupid question... and I only say it's stupid because I've been mining on p2pool for well over a year and don't know the answer myself
... is p2pool the only pool to use "/P2SH/" in the coinbase? I swear I saw that in the coinbase of another... maybe I'm wrong and that really is the p2pool identifier. Guess I'll find out when I run my code and do some checks.I'm pretty sure the last address in the p2pool coinbase that shows up as invalid on blockchain is also a way to identify p2pool.
Jump to: