search

cryptonomex / graphene

MIT License
1.05k stars 337 forks source link

Block producing issue, possible security flaw #645

Closed abitmore closed 8 years ago

abitmore commented 8 years ago

According to the log, the system clock of one of active witnesses is 7 seconds ahead of correct time, when a block is produced by it, the timestamp is set to 9 seconds in the future. IMO this kind of blocks should be rejected by other witnesses. But now they got accepted, in addition next block is produced after 10 seconds. Other witnesses are missing blocks due to this. What if one witness set the clock to 1 minute or 2 minutes ahead?

2016-04-05T21:04:09 th_a:invoke handle_block         handle_block ] Got block: #5006631 time: 2016-04-05T21:04:09 latency: 393 ms from
: fox  irreversible: 5006606 (-25)                        application.cpp:521
2016-04-05T21:04:10 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
                witness.cpp:197
2016-04-05T21:04:10 th_a:invoke handle_block         handle_block ] Got block: #5006632 time: 2016-04-05T21:04:18 latency: -7235 ms from: mindphlux.witness  irreversible: 5006614 (-18)                        application.cpp:521
2016-04-05T21:04:11 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
                witness.cpp:197
2016-04-05T21:04:12 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
                witness.cpp:197
2016-04-05T21:04:13 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
                witness.cpp:197
2016-04-05T21:04:14 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
                witness.cpp:197
2016-04-05T21:04:15 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
                witness.cpp:197
2016-04-05T21:04:16 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
                witness.cpp:197
2016-04-05T21:04:17 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
                witness.cpp:197
2016-04-05T21:04:18 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
                witness.cpp:197
2016-04-05T21:04:19 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
                witness.cpp:197
2016-04-05T21:04:20 th_a:Witness Block Production block_production_loo ] Not producing block because slot has not yet arrived
                witness.cpp:197
2016-04-05T21:04:21 th_a:Witness Block Production block_production_loo ] Not producing block because it isn't my turn
        witness.cpp:194
2016-04-05T21:04:21 th_a:invoke handle_block         handle_block ] Got block: #5006633 time: 2016-04-05T21:04:21 latency: 366 ms from: wackou  irreversible: 5006615 (-18)                     application.cpp:521
abitmore commented 8 years ago

duplicate of #595

abitmore commented 8 years ago

If a witness produced a block with a timestamp 100 years in the future, will the network die?

abitmore commented 8 years ago

This issue has been fixed in Steem. Best if backport the fix.

abitmore commented 8 years ago

This issue happened on BitShares network a few hours ago. It happened on MUSE network a few days ago.

When the system clock of one active witness is off (at several minutes in the future), only that witness was producing one block in every round, network participation rate became very low. Once size of undo_db reached the limit, the network will freeze.

I pushed a quick and dirty patch.