Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not rely on sleeping after mining for security properties #4

Open
mitar opened this issue Mar 10, 2017 · 0 comments
Open

Do not rely on sleeping after mining for security properties #4

mitar opened this issue Mar 10, 2017 · 0 comments

Comments

@mitar
Copy link
Member

mitar commented Mar 10, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant