It’s somewhat more complicated than that.
By only knowing the Ethereum address, you cannot get at the public key, because the public key goes through a SHA3 hash to get to the address.
However, you can recover the public key by observing a valid eth transaction to that address. To verify the signature, the public key must be revealed.
So unless the address was never used, you essentially always have the matching public key.
Now. The list of addresses is generated via BIP-32. All addresses start with a private secret derived from your seed, and then you descend down a tree consisting of hardened and unhardened steps.
The default derivation path for Ethereum is m/44'/60'/0'/0/x
, where x
goes from 0 to 1 million. The steps denoted with '
are hardened and we don’t care about those, because you always need a private key to do that step.
But the last two steps are unhardened, meaning that if you somehow got a hold of the (extended) public key at m/44'/60'/0'
, you can compute the remaining /0/x
yourself and get a public key of any address this way.
And it turns out that the public key at m/44'/60'/0'
is commonly called an “xpub” and people work with it regularly. In particular, MetaMask will ask Trezor for your xpub and only then show the list of your addresses. AFAIK the xpub is not stored, but technically it can be.
This was designed with Bitcoin in mind, where an account consists of many addresses and you need a convenient way to collect all of them. Ethereum stupidly adopted the same structure, despite it making very little sense, but then six years of development happened and now we’re pretty much stuck with it.
In conclusion: if you just have an address, then you can’t calculate the other addresses. If you have an xpub, you can calculate all the addresses below that xpub.