Closed jonasnick closed 9 years ago
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).
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
Yes, t2 SHOULD include the block latency again.
Days like today I wonder if I'm getting senile in my old age.....
(fix pushed)
Seems all right now. Thank you!
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
and recorded the t argument of the ConsiderChain method:
Therefore, if the peer latencies are the same and there is no jitter, they will be scheduled at the same time.