Block Propagation

[jonasnick]

Hi, I ran into an issue with the block propagation code. Consider for example the network A <-> B <-> C. It appears that when A finds a block then B and C's ConsiderChain method will be scheduled at the same time (if the peer latencies are the same). Shouldn't the time when a the block arrives be the path length times the block's latency plus each edge's latency?

I tested this with the following config

miner=0.90 standard 
miner=0.06 standard
miner=0.04 standard

biconnect=0 1 0.01
biconnect=1 2 0.01

and recorded the t argument of the ConsiderChain method:

 ./mining_simulator --blocks 1 --config mining_debug.cfg --rng_seed 0 --latency 2 --runs 1 
Simulating 1 blocks, default latency 2secs, with 3 miners over 1 runs
Configuration: just a test
miner 0.06 considers chain at  479.525
miner 0.04 considers chain at  479.525

Therefore, if the peer latencies are the same and there is no jitter, they will be scheduled at the same time.

[gavinandresen]

You're absolutely right, multi-hop simulation was very broken.

I just pushed a fix.

This doesn't change the results I published last week at http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners (because I was not testing what happens for miners that are more than one hop away from other miners).

[jonasnick]

Now if A finds a block at time t0 then B learns about the block at t1 = t0 + block_latency + peer_latency1 and C at time t2 = t1 + peer_latency2. But shouldn't t2 include the block latency again?

See

./mining_simulator --blocks 1 --config mining_debug.cfg --rng_seed 1 --latency 10 --runs 1
Miner 0.9 found block at simulation time 764.475
Miner 0.06 considering chain at simulation time 774.485
Miner 0.04 considering chain at simulation time 774.495
Miner 0.06 considering chain at simulation time 774.505

[gavinandresen]

Yes, t2 SHOULD include the block latency again.

Days like today I wonder if I'm getting senile in my old age.....

[gavinandresen]

(fix pushed)

[jonasnick]

Seems all right now. Thank you!