status-go/static/migrations/1540715431_add_version.down...

ALTER TABLE keys DROP COLUMN session_id;
ALTER TABLE sessions DROP COLUMN keys_count;
ALTER TABLE bundles DROP COLUMN version;
Change handling of skipped/deleted keys & add version (#1261) - Skipped keys The purpose of limiting the number of skipped keys generated is to avoid a dos attack whereby an attacker would send a large N, forcing the device to compute all the keys between currentN..N . Previously the logic for handling skipped keys was: - If in the current receiving chain there are more than maxSkip keys, throw an error This is problematic as in long-lived session dropped/unreceived messages starts piling up, eventually reaching the threshold (1000 dropped/unreceived messages). This logic has been changed to be more inline with signals spec, and now it is: - If N is > currentN + maxSkip, throw an error The purpose of limiting the number of skipped keys stored is to avoid a dos attack whereby an attacker would force us to store a large number of keys, filling up our storage. Previously the logic for handling old keys was: - Once you have maxKeep ratchet steps, delete any key from currentRatchet - maxKeep. This, in combination with the maxSkip implementation, capped the number of stored keys to maxSkip * maxKeep. The logic has been changed to: - Keep a maximum of MaxMessageKeysPerSession and additionally we delete any key that has a sequence number < currentSeqNum - maxKeep - Version We check now the version of the bundle so that when we get a bundle from the same installationID with a higher version, we mark the previous bundle as expired and use the new bundle the next time a message is sent 2018-11-05 19:00:04 +00:00			`ALTER TABLE keys DROP COLUMN session_id;`
			`ALTER TABLE sessions DROP COLUMN keys_count;`
			`ALTER TABLE bundles DROP COLUMN version;`