Um okay... Block 683273 has just one transaction...

[Timelord2067]

This just happened a few minutes ago - four blocks found in under half an hour.  The latest block 683273 apparently contains just one transaction (and that one transaction is literally itself being created) even though there are thousands of transactions waiting to be processed.

https://mempool.space/

Anyone know what gives?

[ranochigo]

The block before that (683272) was propagated right before this block was propagated. My best guess would be SPV mining where the pool intentionally constructs a block without any transactions while they validate the previous block. Doing so would eliminate the risk of the block being invalid as it has yet to validate the entire block and thus wouldn't know the transactions that were already included in that block. -- Including a transaction that has already been included in a prior block within the same chain makes the entire block invalid, even if it has a valid POW.

Validation time for a proper pool has proven to be quite short. Not all of the pool practices this and thus there can be blocks that are mined within a few seconds of each other yet the transactions are still included.

[Timelord2067]

Five more blocks found in as many minutes:





I guess that's one way to clear the backlog of transactions...

[NotATether]

It's called an empty block and happens occasionally, because some pools like creating them when their verification is not finished as ranochigo explained above.

Some pools like Kano.is intentionally avoid mining empty blocks.

[BrewMaster]

Some pools like Kano.is intentionally avoid mining empty blocks.

when they are doing what they are supposed to do you can't call that intentionally avoiding empty blocks. the other mining pools that are not validating blocks are in the wrong and are intentionally mining empty blocks.

[InvestFi]

 Even though the POW is correct, using a transaction that has already been used in a previous block within the same chain invalidates the whole block. There might be blocks mined within a few seconds of one another, but the transactions are always used.

[Quickseller]

The block before that (683272) was propagated right before this block was propagated. My best guess would be SPV mining where the pool intentionally constructs a block without any transactions while they validate the previous block. Doing so would eliminate the risk of the block being invalid as it has yet to validate the entire block and thus wouldn't know the transactions that were already included in that block. -- Including a transaction that has already been included in a prior block within the same chain makes the entire block invalid, even if it has a valid POW.

Validation time for a proper pool has proven to be quite short. Not all of the pool practices this and thus there can be blocks that are mined within a few seconds of each other yet the transactions are still included.

The timestamps between 683273 and 683272 are 40 seconds apart. I would think this would be enough time to receive and validate a block. The timestamps between 683278 and 683277 are only 4 seconds apart and 683278 has transactions (it is a full block). Granted, it is possible the timestamps are not 100% accurate.

This may be a case of SPV mining, but I would not say this is a blanket guarantee for anytime something like this happens.

[NotATether]

Some pools like Kano.is intentionally avoid mining empty blocks.

when they are doing what they are supposed to do you can't call that intentionally avoiding empty blocks. the other mining pools that are not validating blocks are in the wrong and are intentionally mining empty blocks.

I'm not sure I understand what you're trying to say. In the worst case we have miners who by finding a block, run out of time for validation. It doesn't make economic sense for someone to mine only empty blocks as they'll miss out on transaction fee rewards, which is what incentivizes them to validate in the first place.

[Quickseller]

Some pools like Kano.is intentionally avoid mining empty blocks.

when they are doing what they are supposed to do you can't call that intentionally avoiding empty blocks. the other mining pools that are not validating blocks are in the wrong and are intentionally mining empty blocks.

I'm not sure I understand what you're trying to say. In the worst case we have miners who by finding a block, run out of time for validation. It doesn't make economic sense for someone to mine only empty blocks as they'll miss out on transaction fee rewards, which is what incentivizes them to validate in the first place.

If a miner is SPV mining, it is not that they "run out of time" to validate the previous block, it is that they mine on top of a block from another miner before have validated the block. When a miner is checking if a hash is valid, the has will be based on what is in the block (transactions), which means the proposed transactions need to be in the block prior to checking if the has is valid.

[ranochigo]

The timestamps between 683273 and 683272 are 40 seconds apart. I would think this would be enough time to receive and validate a block. The timestamps between 683278 and 683277 are only 4 seconds apart and 683278 has transactions (it is a full block). Granted, it is possible the timestamps are not 100% accurate.

This may be a case of SPV mining, but I would not say this is a blanket guarantee for anytime something like this happens.

For what it's worth, here's the timestamp I've pulled from my node:

Code:

2021-05-12T12:54:19Z UpdateTip: new best=000000000000000000037c05d54e63858ddcd16c02f1a4fecfe4a1c15fe4814a height=683272 version=0x20002000 log2_work=92.873115 tx=641610681 date='2021-05-12T12:53:55Z' progress=1.000000 cache=154.6MiB(1148889txo)
2021-05-12T12:54:23Z UpdateTip: new best=0000000000000000000cc09df69592553f00431741a9e49e540a3be66da541f2 height=683273 version=0x3fff0004 log2_work=92.873129 tx=641610682 date='2021-05-12T12:54:35Z' progress=1.000000 cache=154.6MiB(1148893txo)

It's not uncommon for the block timestamps to have quite a significant deviation. Taking the relayed time of a well connected node would be far better for this.

[Quickseller]

The timestamps between 683273 and 683272 are 40 seconds apart. I would think this would be enough time to receive and validate a block. The timestamps between 683278 and 683277 are only 4 seconds apart and 683278 has transactions (it is a full block). Granted, it is possible the timestamps are not 100% accurate.

This may be a case of SPV mining, but I would not say this is a blanket guarantee for anytime something like this happens.

For what it's worth, here's the timestamp I've pulled from my node:

Code:

2021-05-12T12:54:19Z UpdateTip: new best=000000000000000000037c05d54e63858ddcd16c02f1a4fecfe4a1c15fe4814a height=683272 version=0x20002000 log2_work=92.873115 tx=641610681 date='2021-05-12T12:53:55Z' progress=1.000000 cache=154.6MiB(1148889txo)
2021-05-12T12:54:23Z UpdateTip: new best=0000000000000000000cc09df69592553f00431741a9e49e540a3be66da541f2 height=683273 version=0x3fff0004 log2_work=92.873129 tx=641610682 date='2021-05-12T12:54:35Z' progress=1.000000 cache=154.6MiB(1148893txo)

It's not uncommon for the block timestamps to have quite a significant deviation. Taking the relayed time of a well connected node would be far better for this.

When a node receives a block, it will not send the block to any of its peers until it has verified the block as being valid. If there are 4 nodes between a node that initially broadcasts a block, and your node, and it takes 4 seconds to verify a block as being valid, it  would take 16 seconds for your node to even be aware of a new block. This stackexchange answer by Pieter Wuille says that it can take up to ~4 seconds between validation and latency for a block to go from one node to another. In theory, when two blocks are quickly found back to back, the second block could be broadcast before your node is aware of the first block.

In order to get the most accurate timestamp of a block, you really need to be directly connected to the node broadcasting the block initially.

According to what you posted, block x73 probably has a timestamp some amount of seconds in the future, as the block has a timestamp of x54:35, while your node reflects x54:23, so 12 seconds, plus the time it takes to get from poolin's node to your node.

[ranochigo]

When a node receives a block, it will not send the block to any of its peers until it has verified the block as being valid. If there are 4 nodes between a node that initially broadcasts a block, and your node, and it takes 4 seconds to verify a block as being valid, it  would take 16 seconds for your node to even be aware of a new block. This stackexchange answer by Pieter Wuille says that it can take up to ~4 seconds between validation and latency for a block to go from one node to another. In theory, when two blocks are quickly found back to back, the second block could be broadcast before your node is aware of the first block.

In order to get the most accurate timestamp of a block, you really need to be directly connected to the node broadcasting the block initially.

Yes. Compact block does basic validations (block headers) which is much faster than a full validation of it before relaying to the peers under high bandwidth mode. Bitcoin Core has compact block support which lowers the relay time quite significantly. Given that my node connects to over 125 peers, it would probably mean that the time that the block takes to reach my block is far lower than most. Since the post was from 2016 and given the optimizations for block propagation/validation, I'll consider the actual time taken to be a lot smaller.

From my previous experience, the deviation between two of my nodes which are considered fairly far in terms of geographical distance was about 1 second. I'd say that the time that it takes for it to have a good propagation is far less than 40 seconds.

I suppose there could be a small amount of delay within the mining pool themselves as well. After constructing the empty block header, it has to be sent to the miner, the ASIC returns the golden nonce, it gets sent back to the server, the server validates and the server starts to propagate. There is no telling of how much delay (if any) that is present within the mining pool. I'll think that pools like Poolin would probably try to avoid mining empty blocks as that'll mean potential loss in revenue for their miners. SPV mining is a different case.

[HCP]

Anyone know what gives?

The same thing that has been happening for years... miners have been mining "empty" blocks since "ages ago"™. This is neither new, nor unexpected behaviour...

refer: https://bitcointalk.org/index.php?topic=1085800.0
and: https://www.google.com/search?q=bitcointalk.org+empty+blocks

[pooya87]

I suppose there could be a small amount of delay within the mining pool themselves as well. After constructing the empty block header, it has to be sent to the miner, the ASIC returns the golden nonce, it gets sent back to the server, the server validates and the server starts to propagate. There is no telling of how much delay (if any) that is present within the mining pool.

There are of course delays but we are talking about very small ones. The data communicated between the pool and its miners is tiny since the header size is just 80 bytes. The validation of the returned successful value is also not time consuming since hashing the header takes a micro second if not less on any CPU.

[Timelord2067]

Looks like it's a more common occurrence than I originally realised

Block 683399


Coinbase this time around.

[Quickseller]

When a node receives a block, it will not send the block to any of its peers until it has verified the block as being valid. If there are 4 nodes between a node that initially broadcasts a block, and your node, and it takes 4 seconds to verify a block as being valid, it  would take 16 seconds for your node to even be aware of a new block. This stackexchange answer by Pieter Wuille says that it can take up to ~4 seconds between validation and latency for a block to go from one node to another. In theory, when two blocks are quickly found back to back, the second block could be broadcast before your node is aware of the first block.

In order to get the most accurate timestamp of a block, you really need to be directly connected to the node broadcasting the block initially.

Yes. Compact block does basic validations (block headers) which is much faster than a full validation of it before relaying to the peers under high bandwidth mode. Bitcoin Core has compact block support which lowers the relay time quite significantly. Given that my node connects to over 125 peers, it would probably mean that the time that the block takes to reach my block is far lower than most. Since the post was from 2016 and given the optimizations for block propagation/validation, I'll consider the actual time taken to be a lot smaller.

From my previous experience, the deviation between two of my nodes which are considered fairly far in terms of geographical distance was about 1 second. I'd say that the time that it takes for it to have a good propagation is far less than 40 seconds.

I suppose there could be a small amount of delay within the mining pool themselves as well. After constructing the empty block header, it has to be sent to the miner, the ASIC returns the golden nonce, it gets sent back to the server, the server validates and the server starts to propagate. There is no telling of how much delay (if any) that is present within the mining pool. I'll think that pools like Poolin would probably try to avoid mining empty blocks as that'll mean potential loss in revenue for their miners. SPV mining is a different case.

Most nodes will connect to far fewer than 125 other nodes, and you don’t know how well connected the nodes you are connected to are. Nodes by default try to connect to a diverse set of nodes, so your two nodes being geographically far from each other doesn’t necessarily mean anything.

The verification time may be less than the 4 seconds I quoted. This can be tested by running a node that connects to a single note, yours, and to track the time difference between found block times each node is reporting.  

Once a pool validates a block, it will need to update its UTXO set, and it’s database for valid transactions waiting for confirmation. There will be some time between when a block is validated and when a pool will start including transactions in its proposed block if it is SPV mining. 

[NotATether]

Most nodes will connect to far fewer than 125 other nodes, and you don’t know how well connected the nodes you are connected to are. Nodes by default try to connect to a diverse set of nodes, so your two nodes being geographically far from each other doesn’t necessarily mean anything.

Here's the thing about being well-connected. Merely having connections to a lot of nodes will cause you to get a much larger number of timestamps, and there's going to be even more of them that are different from each other because the more nodes you connect to, the higher the chance they are going to receive a block propagated by yet another miner.

For profiling, you'll want to find which nodes belong to the big mining pools (the top 10 are sufficient), maybe by looking at their DNS seeds, and just connect to those. Then you will know that the most accurate timestamp is the lowest one, from the node that submitted the block to you first.

[o_e_l_e_o]

Timestamps are not accurate for knowing when a block was broadcast, especially when some miners are using the timestamp as additional entropy to the nonce field when attempting to calculate an appropriate hash. Take a look at the timestamps of the following blocks:

145044 - 15:46
145045 - 16:05
145046 - 16:00
145047 - 15:53
145048 - 16:04
145049 - 16:08

The lower limit for the timestamp of any given block is the average time of the last 11 blocks plus 1 second. The upper limit is the current network time plus 2 hours. Assuming a 10 minute average block time, then the timestamp can vary by about 3 hours.

[ranochigo]

Most nodes will connect to far fewer than 125 other nodes, and you don’t know how well connected the nodes you are connected to are.

Having a connection to/from more nodes will give you a far higher chance of the block propagated to you with the least hops. Granted this doesn't mean you'll have a direct connection but it does lower your margin of error.

Nodes by default try to connect to a diverse set of nodes, so your two nodes being geographically far from each other doesn’t necessarily mean anything.

You're right. I was thinking of something else.

The verification time may be less than the 4 seconds I quoted. This can be tested by running a node that connects to a single note, yours, and to track the time difference between found block times each node is reporting.  

Validation time depends on the hardware: https://bitcointalk.org/index.php?topic=5312030.msg56181206#msg56181206.

Since the block doesn't necessarily have to be validated fully before being relayed, it becomes more or less a non-factor.

Once a pool validates a block, it will need to update its UTXO set, and it’s database for valid transactions waiting for confirmation. There will be some time between when a block is validated and when a pool will start including transactions in its proposed block if it is SPV mining.  

The time that it takes for validation is quite fast actually. This topic has been discussed numerous times but the most noteworthy one is this: https://bitcointalk.org/index.php?topic=5251592.0.

Here's the thing about being well-connected. Merely having connections to a lot of nodes will cause you to get a much larger number of timestamps, and there's going to be even more of them that are different from each other because the more nodes you connect to, the higher the chance they are going to receive a block propagated by yet another miner.

We're interested in being the fastest to find out when the block gets propagated. Having multiple nodes sending the block to us won't matter because we're only concerned about when we first see the block and thus getting a more accurate timestamp. Getting another block at the same height doesn't really matter.

For profiling, you'll want to find which nodes belong to the big mining pools (the top 10 are sufficient), maybe by looking at their DNS seeds, and just connect to those. Then you will know that the most accurate timestamp is the lowest one, from the node that submitted the block to you first.

Just run a zombie on their pool. You'll definitely be the first to see if a block gets mined. I wouldn't do this though, you're just wasting their resources and would probably get kicked. But that was how they were SPV mining in the past.