We are keying the hash (HMAC), keyed by a value derived from the data pool. Please don't take the 4 line pseudo-code too literally.
The value stored in the database (Hash2) can only be used to verify a password if you can also complete the blind hash which is blinded by the data pool.
I can say, this approach has been vetted by both well known cryptographers (Solar Designer, Scoob) as Passwords^15 as well as industry crypto wonks at MITRE and elsewhere. It's certainly not snake oil.
The salt kept on the site's server means that the site must be breached in order for a successful attack to be mounted. It's why we call this a fully additive layer of security. You need the Salt from the site, and the entire data pool from us, to mount an offline attack.
2) Why would you say that? It's absolutely not the case that you can login with Hash1 and Salt2.
If you intercept Hash1 and Salt2 then you may know Hash2 but you still cannot login, and you cannot try to crack it without Salt1. Again, this is all assuming TLS is broken in which case you can just inject your own JavaScript onto the page and steal passwords in clear text.
By direct peering I mean programs such as AWS DirectConnect which gives us 10Gbps on their network and private IP access to our peers. Nothing to get too excited about.
I'll be back online in about an hour if this still doesn't answer the basic questions around the security of the construct.
EDIT: I do not mean to say solardiz or sc00bz have personally endorsed our product. Only that we have all worked on and published write ups on the same general approach (using large data pools with bounded network links) to solve the password security problem.