<div>Dear Peter,<br></div><div><br></div><div>Thanks for the kind words. Your suggestions is quite interesting but I think it would have some issues:<br></div><div><br></div><div>1. It assumes a universal clock i.e. synchronization in the network. Because everyone has to wait a fixed amount of time to receive h(x_i) and then again for a fixed amount of time to receive x_i. <br></div><div><br></div><div>2. It is possible some nodes, with poor connectivity,  may not receive one of the above or both of the above in the specified period. As a result, their computation of the winner would be incorrect. And they will not accept the block that the majority nodes accept as valid. In other words, a complete consensus might not be achieved. This problem would probably worsen exponentially  with the number of nodes in the network as you anticipated.<br></div><div><br></div><div>3. There is another, perhaps more serious problem. When a new node joins and is presented with a blockchain with multiple forks. It would not know which history to trust because nothing distinguishes one history from the other. This is because the winner does not get a permanent and universally verifiable proof of her winning which she could attach to her block (I don't know if such a proof exists in this protocol.).<br></div><div><br></div><div>The protocol presented in the paper does not need synchronization and the winner has a universally verifiable proof (the lottery ticket). When a new node joins the network, the longest valid chain will invariably be the agreed upon chain.<br></div><div><br></div><div class="protonmail_signature_block"><div class="protonmail_signature_block-user"><div>Regards,<br></div><div>Vincent<br></div></div><div><br></div></div><div><br></div><div><br></div>