Topic: Um okay... Block 683273 has just one transaction... (Read 276 times)

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.
You're right. I was thinking of something else.
Validation time depends on the hardware: https://bitcointalksearch.org/topic/m.56181206.

Since the block doesn't necessarily have to be validated fully before being relayed, it becomes more or less a non-factor.
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://bitcointalksearch.org/topic/why-not-to-mine-on-pools-mining-empty-blocks-and-why-do-pools-mine-empty-blocks-5251592.

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

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.

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.

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. 

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


Block 683399

---

---

Coinbase this time around.

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.

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://bitcointalksearch.org/topic/empty-blocks-1085800
and: https://www.google.com/search?q=bitcointalk.org+empty+blocks

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.

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.

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


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.

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.

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.

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.

 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.

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.

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.

Five more blocks found in as many minutes:





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

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.

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?