How IOTA addresses are generated from seeds.

A seed and an address are both 81 trytes long. That means that in the best case every seed can map to a single unique address. Now factor in the fact that a single seed is used to generate any number of addresses and you can see that there must be an overlap taking place. However, the number of possible values for a seed/address is so ridiculously high (27⁸¹) that the chances of accidentally overlapping addresses are vanishingly small when using random seeds.

And this is where the special case comes in: the algorithm used in creating the series of addresses. It is not random. To be able to deterministically generate the series of addresses from the seed we need to have a function that uses the seed plus the index of the address to generate a starting point for generating a subseed that can be used to map 1 to 1 to a private key and address. This function is very simple: you add the index to the seed as if it was a number stored with the least significant bytes first.

It works like this: let’s assume our seed is BLABLABLABLA…

For address 0 we add 0 to the seed, resulting in BLABLABLABLA…
For address 1 we add 0 to the seed, resulting in CLABLABLABLA…
For address 2 we add 0 to the seed, resulting in DLABLABLABLA…
For address 3 we add 0 to the seed, resulting in ELABLABLABLA…

You get the sequence? And once a tryte overflows the next tryte is also incremented, etcetera.

Now see what happens when we start with seed CLABLABLABLA…

For address 0 we add 0 to the seed, resulting in CLABLABLABLA…
For address 1 we add 0 to the seed, resulting in DLABLABLABLA…
For address 2 we add 0 to the seed, resulting in ELABLABLABLA…
For address 3 we add 0 to the seed, resulting in FLABLABLABLA…

Do you see the overlap with the previous series?

This is why seeds that only differ in the first few characters can have overlapping ranges of addresses. But because most people generate a random seed the chances of them only differing in the first few characters are vanishingly small.

Now, just to be complete, here is how the sub-seed, private key, and address are generated from the original seed once the index has been added like we did above:

First, the resulting (seed+index) is hashed into a sub-seed. Due to the hashing nature this means that the resulting sub-seeds are so different that it is impossible to recreate the original (seed+index) it came from. They no longer form a sequential series but instead are distributed randomly over the address space.

Now, this sub-seed is in turn hashed into a private key which length is determined by the desired security level of the address. The private key length will be double for security level 2 and triple for security level 3 (the light wallet uses a default security level of 2).
Note how these private keys can always easily be re-generated from the (seed+index), so there is no necessity to store the private keys anywhere.

Next, the private key is hashed into 27 key fragments that are each hashed 26 times. These key fragments will play an essential part in the Winternitz signing process when funds from an address get spent.

And finally, the hashed key fragments are hashed together into a public key. This public key is the address.

I hope this has shed some light into the entire process.