https://blog.lisk.io/further-details-regarding-june-2-network-interruption-7c8f4abdc4feFurther Details Regarding June 2 Network Interruption
On Saturday, June 2, the Lisk network experienced a temporary halt. Despite the fact that the issue was identified and resolved within several hours, we believe the situation warrants a more thorough explanation of precisely what happened to the Lisk network.
Lisk Core uses PostgreSQL, a relational database. Blocks are stored as rows in a `blocks` table. This table has a foreign key constraint requiring that each block contain the ID of the previous block the constraint here being that the previous block must already exist in the database. Insert operations which do not conform to the constraint will fail and not be saved. Similar to that, transactions are stored as rows in a `transactions` table, with the different parameters of a transaction, like a timestamp, sender, recipient, and amount, being saved in columns.
In the early hours of last Saturday morning, an anonymous individual broadcasted a transaction to the Lisk network with a timestamp of -3704634000, which comes out to be 18981231 13:00:00 CEST. This requires a manually created and signed transaction, which is how we know it was intentional. The timestamp column in the `transactions` table will only accept a 32-bit integer value (a value between -2,147,483,648 and 2,147,483,647) the timestamp used exceeded this range. Therefore, the transaction can be described as malformed and malicious; this resulted in the transaction not being inserted into the database. When a block is saved to the database, the block and its corresponding transactions are written as one atomic database operation; if a transaction-insert operation failed, the entire block-insert operation will fail as well. Thus, the whole block with the malformed transaction did not get inserted into the database. All subsequent attempts at block-insertions referenced the block ID of this nonexistent block and failed to insert due to the previous block foreign key constraint. This, in turn, halted all transaction and block-insertions into the database. That is the described security measure we reported on Saturday.
