I just wanted the list in an easily downloadable format so I can check offline

(easily downloadable == not the rapidshare of russia, something you could wget)

But I submitted the hash of my password and it's there so...

I have a torrent up of the database so you can check locally,

here: http://www.seedpeer.me/download/linkedin_hashes/ad1e93a1aee2...

www.mediafire.com/?n307hutksjstow3

Click download, copy the URL from your browser into wget/axel/download manager. I get a solid 1mb/s from media fire.

Interesting implementation, but won't this eat up a lot of bandwidth and cause a high S3 bill?

I cut the hash database into 256 pieces based on the last two digits of hash so chunk is smaller than 1MB. To check one password it only downloads one piece. So hopefully it won't be that bad.

Assuming the split is computer-generated based on a parameter, why not use the last three digits and cut it into 4096 pieces, where each chunk is under 64KB? If your bandwidth bill is small it won't matter (ie: not worth the time involved) but if you get a bunch of traffic your cost is 1/16th of what it would have been. Also, to the user the site will be way more responsive as the download will happen quicker.

Bloom filter?

Probably a noob question but... How does this account for any salt that may have been used?

LinkedIn didn't use a salt. Hence the easier-than-it-should-have-been password crackfest.

(However, could everyone please stop making random websites encouraging people to type in their passwords from third party sites!)

I suspected that was the answer but this blog post http://blog.linkedin.com/2012/06/06/linkedin-member-password... mentions that they are salting the passwords.

It doesn't, LinkedIn didn't salt the passwords.