Is it safe to generate ECDSA keys from the hash of the previous, over and over again? I have memorized a very long and secure passphrase, that when hashed with sha256, I can use the result as an ECDSA private key, and use it as a brain-address for Bitcoin.

Now I need more bitcoin addresses, and instead of memorizing a new long and secure passphrase, I am thinking about just hashing the previous hash, over and over again to create new keys.

So I can build a simple software to which I type the passphrase and I tell him I want the key of the address number 58, so it just has to sha256 the passphrase 58 times to get that key.

If the greatest hacker ever had for example the first 500 bitcoin addresses that were generated with my passphrase, and if that hacker knew how those private keys where generated, would he have any chance to hack this system?

I am pretty sure he wouldn't but I want to make sure, because this is for a project at my job.
This approach will work, but there's another approach I want you to suggest.

As for why it's secure (or better the ways to attack):


Break the elliptic curve discrete logarithm problem. If you can do this you can just grab the first address out of your addresses, solve for the private key and derive all subsequent ones. This is generally considered infeasible.
Brute-force your passphrase. This is impossible as you describe it as "very long and secure".


Now for the alternative approach:

Don't use iterated hashing on your password for the ECDSA key derival. Use HKDF-extract on your password and then derive each indexed key using HKDF-expand which will allow you to supply context-information. You could simply use "1", "2","3",... as context info here. Use the derived values as ECDSA private keys.

The advantages are:


Independent keys. Compromise of one private key doesn't imply compromise of all subsequent private keys, because they are all independent.
Higher speed. If you only want to access your account number 500, you'd have to iterate your hash function 500 times (which may take a moment). With HKDF you get this at a few HMAC calls independently of the index.
More security. If you use HKDF you don't need to store / buffer 499 intermediate private keys on your machine, whereas with iterated hashing you'd have to (although you still have to store the master password).