Does a big salt have the same memory effects as Bcrypt?
So in general, isn't this equivalent to what Bcrypt and PBKDF2 do in terms of password storage security?


PBKDF2, yes, pretty much. The only real difference is that salt/password are used the other way around, with the password mixed in at every step.

Bcrypt, however, is different.

In your case an attacker only needs a small amount of memory compared to computational resources. For example, you can imagine a long pipeline of hashing units, which each compute one block of the salt value and then pass the output onto the next unit.

In terms of tradeoffs, say you had memory to store a million hashes long (part of the) salt. Instead of using it all on the salt, you could store a 500k hash long part of it and 500k different password guesses. Then you can calculate a huge amount of work (500k squared) before you need the next part of the salt.

What bcrypt does is have a large part of memory it modifies. That means the memory cannot be shared among different password guesses. Also, the access pattern issue (which Thomas Pornin's comment raised) can play a part – if the access pattern is non-linear, tradeoffs are worse (halving the memory used can lead to a huge slowdown).



The salt storage issue Maarten Bodewes mentioned in comments is also important. A large number of large salts would be unwieldy to store. And you cannot just store some seed or you are in a way back to square one – a fast way to generate the "full" salt could be used to avoid storing it all.