You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a block is mined, enclave does not release it until some short time based on the lucky number. The idea is that luckier block candidates should be sent out sooner than less lucky, so that potentially less lucky do not have to be sent at all. In this way we optimize network traffic.
But currently it seems that we have to rely on this also for security properties, and not just for network performance.
One way to test this is to make afterSleepsetTimeout to use 0 timeout (and disable validation inside the enclave). If you have a network of two parties, and one sets it to 0, then currently more or less that one always wins. The reason for that is that when chain is prolonged, miners switch to mine on this longer chain, even if their block might otherwise win in previous chain.
One check we currently have is that after a block is mined, the enclave releases immediately the lucky number, but not the block itself. So the check can then see if we receive a block A with less lucky number than our own B, which should come after our own block B, so something strange is happening. And we currently ignore such blocks which come to soon. And when we then release our own block B (at expected time), the network switches to it. Also, because everyone else probably started mining on that other block A, that work is not lost, because both A and B share the same parent, which serves as round block.
The issue is that this works only after a block has been mined (and node can compare its lucky number with incoming block). Currently, should wait at least one second before releasing their block, to allow for everyone to mine their block before that, but we are not yet checking for that.
Another issue is that occasionally it seems that current code trigger "Received new luckier latest block out of order, ignoring" error even for well behaving nodes.
But main issue is that even if we ignore block A, the malicious miner will win the next block after that, because they could start mining on a followup block C immediately. And even if A does not win and B wins, C will be ready before everyone else even start mining (before 10 seconds, because everyone else slept at least one second more), and because A and B share the same parent, C will be seen as a valid continuation. We should somehow penalize a malicious user so that they cannot win the next block.
In general anyone who is able to mine a block every 10 seconds, and not 13 (on average, because they are not sleeping) will through time have an advantage and more chances of winning with their blocks.
The text was updated successfully, but these errors were encountered:
When a block is mined, enclave does not release it until some short time based on the lucky number. The idea is that luckier block candidates should be sent out sooner than less lucky, so that potentially less lucky do not have to be sent at all. In this way we optimize network traffic.
But currently it seems that we have to rely on this also for security properties, and not just for network performance.
One way to test this is to make
afterSleep
setTimeout
to use 0 timeout (and disable validation inside the enclave). If you have a network of two parties, and one sets it to 0, then currently more or less that one always wins. The reason for that is that when chain is prolonged, miners switch to mine on this longer chain, even if their block might otherwise win in previous chain.One check we currently have is that after a block is mined, the enclave releases immediately the lucky number, but not the block itself. So the check can then see if we receive a block A with less lucky number than our own B, which should come after our own block B, so something strange is happening. And we currently ignore such blocks which come to soon. And when we then release our own block B (at expected time), the network switches to it. Also, because everyone else probably started mining on that other block A, that work is not lost, because both A and B share the same parent, which serves as round block.
The issue is that this works only after a block has been mined (and node can compare its lucky number with incoming block). Currently, should wait at least one second before releasing their block, to allow for everyone to mine their block before that, but we are not yet checking for that.
Another issue is that occasionally it seems that current code trigger "Received new luckier latest block out of order, ignoring" error even for well behaving nodes.
But main issue is that even if we ignore block A, the malicious miner will win the next block after that, because they could start mining on a followup block C immediately. And even if A does not win and B wins, C will be ready before everyone else even start mining (before 10 seconds, because everyone else slept at least one second more), and because A and B share the same parent, C will be seen as a valid continuation. We should somehow penalize a malicious user so that they cannot win the next block.
In general anyone who is able to mine a block every 10 seconds, and not 13 (on average, because they are not sleeping) will through time have an advantage and more chances of winning with their blocks.
The text was updated successfully, but these errors were encountered: