Topic: Empty blocks (Read 22955 times)

I think the accepted reason is that BITMAIN is using a covert version of the ASICBOOST system to boost their profits.  IIRC, the empty blocks are an effect of that.  I may not be up to speed, however--if someone has a differing opinion I would love to hear it.

hello,

as of today, the average fee per block is of 2 BTC so mining empty blocks is about 16% less profitable. but is still happens that some pools mine empty blocks.

can anyone explain this?

thanks

BURST is a coin and it is certainly not its fault for empty blocks 

Unfortunately money is the only motivator to the spv mining pools.  I hope that it becomes financially necessary for them to stop mining empty blocks, it will be a great thing for the network once they do, and it would give a more accurate portrayal of how the network is able to handle tons of transactions (and hopefully put an end to the excessive delays waiting for tx to go through).

Let us hope so, philipma, since money is a big motivator!

One good thing about the 1/2 ing is block to fee ratio may change by 2x.

Ie a 25.5 block with fees now will be 12.5 block with fees in July after the 1/2 ing.

So pools like f2pool and antpool may want to end spv mining.

Also if we do not change from 1mb blocks to 2mb blocks. The new norm may be 12.9 or 13.1 or even 13.5

This will place a lot of pressure on spv pools to stop that method of mining.

It is possible that empty block. Mining will become a bad financial play for current spv miners.

Thanks for the clarification to my statement -ck.  I realize now re-reading it after your reply that I should have stated it shows how fast pools get new work out to miners, and not how fast the pool propagates the blocks it receives.  Also, as you correctly point out - it's just how fast that particular server receives the updates from the pools to which it is connected.

So, take the information provided with a grain of salt.  I do, however, find it an interesting look into things - seeing the vast discrepancies between the top and bottom.  For example, if we ditch the SPV pools, taking a look at the list shows that (for the last 100 blocks anyway) the pools getting work to their miners the fastest are slush (his node in China), ck.solo, kano, bravo with a difference of less than 0.8 seconds between them.

That's not propagating blocks. It's just the stratum work templates which amounts to no more than the headers going to one VPS in the west coast of the USA. It's a marker of how quickly the pools' miners get block changes and has nothing to do with how quickly blocks propagate across the network, but is the combined sum of how quickly the pool itself sees the block changes and sends out stratum templates to miners. Also the code on that page is buggy and occasionally starts producing wrong values (like showing blocks appear from some pools up to 30 seconds before the block even exists) so use it as a guideline but don't place too much value on it when things look extreme. SPV pools don't verify headers when they send out their stratum templates so although their work templates are more often sent out slightly faster than other pools, they can't guarantee that they're not working on a nonsense fork since only real node pools verify block changes completely. A pool using that site as its reference may be tempted to start SPV mining to make its values look better but ultimately that then means they've moved to unverified headers for block changes and header only work also cannot contain any transactions so they'll be guaranteed to be empty blocks.

You just stated the quintessential difference between SPV mining and fully verified block mining.  In SPV mining, the pool starts work on a new block based upon only the block header of the previous one.  It has no knowledge the the previous block's transactions when it does so and is why it starts work on an empty block.  Eventually when it does in fact verify the full block, only then can it include transactions into the new block it's already mining.  Without verification, there is no guarantee the new block they are building is even valid... and it's why the chain forked last year.  Because without actually validating the block, they built upon a version that should have been rejected and submitted a new block on top of it.

So, without validating, the SPV mining pool can (and does quite frequently) find a solution to the bogus empty block they created initially, and it gets added to the chain.

The real difference that needs to be evaluated is how long it takes to actually verify the block before creating a new one on which to work.  If I remember correctly, kano's shown that difference to be a few hundred milliseconds.

Given that information, a pool like AntPool will start work on a new block faster than a pool like kano's (by a few hundred milliseconds) and if it finds a solution the block it produces will propagate across the network faster than a full block from kano.  That, more than anything else, is why the big pools refuse to change, no matter how much damage they are doing in the process (huge transaction backlogs and potential forking of the blockchain).

It doesn't matter when the block is time-stamped by the node, only after it is added to its databases which only happens after it had fully verified the block and thus has had to receive it in full.

I don't think it's that obvious.  When does a node "timestamp" the block it's receiving, when it first starts seeing data, or when the data is 100% received?  I think it's when it first sees data coming in, therefore rendering the size of the block a moot point with respect to propagation rate.  We're not comparing 10k to 10,000,000k, we're comparing 200k to 800k and with today's technology those values are essentially the same.

If we agree that all pools are equally well connected to the network, then obviously broadcasting an empty block (~200 bytes) vs a full block (~1,000,000 bytes) will be faster.

So propagating a 10kB block and a 1 GB block will take the same amount of time? This doesn't make sense.

I do agree that they should not be doing this.

I didn't write it, so I can only provide insight based on my own observation and running my own pool.

I presume the owner of that site has a number of cgminer processes running, each connecting to a pool (i.e. f2pool, Ant, kano, bravo, etc).  As and when each cgminer instance reports a block notification from the pool it is connected to, he writes the information to a data store.  He then correlates the data and presents it as you see on the web page.

The summary at the top shows over the past 100 blocks how each pool he's connected to fared.  The first column is the pool, the second is the average time difference between when that pool notified the block was found vs the first pool to provide notification.  The third column is the average of how the pool did subtracting out the best (i.e. how it compared to the number 1 pool).

The data below shows the values for each individual block.

I don't think a block being full or empty has anything to do with its propagation speed, i.e. I don't think there is any valid reason for producing empty blocks.

Please help me understand this data.

Interesting data, thanks.

Take a look here: https://poolbench.antminer.link

That site gives a good breakdown of how the pools propagate blocks.

Okay exclude Kano then. Take Antpool and F2Pool for example. Wouldn't e.g. Antpool's empty block propagate faster than F2Pool's full block? After all, Antpool has the highest percentage of empty blocks.

Off the top of my head I could only come up with this post by ck:
https://bitcointalksearch.org/topic/m.13822317