Empty blocks

[Lauda]

empty blocks result from bursts

No? They're the result of SPV mining. This means that the miners don't verify the block nor transactions within it but start immediately mining a new block (referencing only the header). They have to mine it without any transactions since they don't know what was included in the last block. A empty block will propagate faster through the network and a full block would most likely get orphaned (if both are solved in similar times). This is why some of the miners are doing this.

Yes, they've certainly gotten better about submitting empty blocks.

They need to completely stop doing this.

They want bigger block so they do empty block.

Miners can impose their own limits anyways.

[1714024178]

1714024178

[1714024178]

1714024178

[1714024178]

1714024178

[1714024178]

1714024178

[Mikestang]

empty blocks result from bursts

Uh, what is a "burst"?  Whatever it is, it's not why empty blocks happen.  Empty blocks come from bad/lazy coders looking for a shortcut.

A empty block will propagate faster through the network and a full block would most likely get orphaned (if both are solved in similar times).

Not true at all, kano.is has about the fastest network block propagation and never mines empty blocks.

[organofcorti]

empty blocks result from bursts

Uh, what is a "burst"?  Whatever it is, it's not why empty blocks happen.  Empty blocks come from bad/lazy coders looking for a shortcut.

A empty block will propagate faster through the network and a full block would most likely get orphaned (if both are solved in similar times).

Not true at all, kano.is has about the fastest network block propagation and never mines empty blocks.

Are you sure about that last part?

[Lauda]

Not true at all, kano.is has about the fastest network block propagation and never mines empty blocks.

If that were true, why would miners bother mining empty blocks in the first place? They lose out on fees by doing so.

[jonnybravo0311]

On AntPool miners don't get the fees anyway, the pool does.  Of course one wonders why anyone mines on that pool at all...

[Mikestang]

Are you sure about that last part?

Yes.

Not true at all, kano.is has about the fastest network block propagation and never mines empty blocks.

If that were true, why would miners bother mining empty blocks in the first place? They lose out on fees by doing so.

It's not "if" it were true because it is true.  Read Kano's posts about block changes, they do it faster than the guys who mine empty blocks.  The empty block miners do it because they are lazy coders who don't care about bitcoin or the network, all they see is $$$.

[organofcorti]

Are you sure about that last part?

Yes.

I think you meant block change response rather than block propagation.

Block propagation is different to a pool's response to block changes. Block propagation is related to how connected a pool is to the network, block change response seems to be a software issue.

I've read that Kano's response to block changes is very quick, but I haven't read that Kano's block propagation times are that much better than any one elses. If I'm wrong, please post a link.

[Mikestang]

Off the top of my head I could only come up with this post by ck:
https://bitcointalk.org/index.php?topic=789369.msg13822317#msg13822317

15 mins ago we got another block

  okay I see it on blocktrail but not blockchaininfo

The block explorers seem to really struggle around the time the orphans hit. Sometimes they may even need manual intervention to keep working it seems... blockchain is showing Eligius as having won that block yet if you click on their block it then says orphan. Regardless, it's our block as all nodes have synced up to ours and confirmed it numerous times since. Our extensive propagation network (and numerous ckpool improvements to distant nodes) may well have paid off on saving that one.

[Lauda]

It's not "if" it were true because it is true.  Read Kano's posts about block changes, they do it faster than the guys who mine empty blocks.  The empty block miners do it because they are lazy coders who don't care about bitcoin or the network, all they see is $$$.

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.

[jonnybravo0311]

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

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

[TracerX]

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

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

Interesting data, thanks.

[David Rabahy]

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

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

Please help me understand this data.

[Mikestang]

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.

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.

[jonnybravo0311]

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

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

Please help me understand this data.

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.

[Lauda]

I don't think a block being full or empty has anything to do with its propagation speed

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

i.e. I don't think there is any valid reason for producing empty blocks.

I do agree that they should not be doing this.

[jonnybravo0311]

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.

[Mikestang]

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.

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.

[achow101]

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.

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.

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.

[jonnybravo0311]

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).

[-ck]

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

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

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.