One flaw that I can see is, since you are doing n-1 iteration on the client side, the use of bcrypt/scrypt/PBKCDF doesn't make sense. As the use of these algorithms is to make cracking of passwords time consuming and computation intensive. In present scenario, an attacker will have the n-1 iteration hash readily available and further requiring only another 1 iteration to guess the password. Which would be trivial for any attacker and in my knowledge carried out on a simple desktop machine.
One possible solution to prevent DoS is, if somebody (malicious user) wants to log into the account, then after certain threshold number of attempts you can stop the user from logging in for certain time and keep increasing this time exponentially. For example, let the threshold attempts be 3. If a user with username 'user123' is logging in, (s)he enters 3 wrong passwords, after that you can block the account for 5 seconds. If again there is a wrong attempt after 5 seconds, you can block the accounts for 10 seconds and so on.
This way you ensure that one user is not hogging your resource and making any bruteforce attack time consuming and eventually unfeasible.
EDIT: Another issue with this approach is, you are sending the salt to the client side. Salt is used to make the brute-forcing of passwords hard. In the present scenario, the attacker will also have the salt corresponding to the username easily available.
Also, if client disables javascript, then he/she won't be able to log in to the website. But this may not be a major issue, as modern websites are heavily dependent on javascripts and require it to be enabled on the client.