Is it possible to generate every address from one seed

[apoorvlathey]

Just came to know that a wallet is capable to generate a lot more address than 20 or 30.
I would like to know is there a limit to how many bitcoin public keys be generated using one seed phrase. Is it unlimited? If it's not limited then this would mean that wallets with different seeds would cause a clash of their addresses. Am I right?

[1714838668]

1714838668

[1714838668]

1714838668

[1714838668]

1714838668

[AB de Royse777]

I would like to know is there a limit to how many bitcoin public keys be generated using one seed phrase. Is it unlimited?

It is unlimited

If it's not limited then this would mean that wallets with different seeds would cause a clash of their addresses. Am I right?

You really gave a good point however I think there must have an explanation. I will wait for others answer.

[pooya87]

I would like to know is there a limit to how many bitcoin public keys be generated using one seed phrase. Is it unlimited?

It is unlimited

If it's not limited then this would mean that wallets with different seeds would cause a clash of their addresses. Am I right?

You really gave a good point however I think there must have an explanation. I will wait for others answer.

it is not unlimited, nothing in bitcoin is.
you are still generating a private key in a finite space (from 1 to n which is a little smaller than 2²⁵⁶) so it is limited by that number.

as for the second part it is talking about collision. or in other words a collision in the truncated HMAC-SHA512 digest which is not going to happen in our lifetime. it is the same argument about "can two person generate the same random private key".

[bitmover]

I would like to know is there a limit to how many bitcoin public keys be generated using one seed phrase. Is it unlimited?

It is unlimited

If it's not limited then this would mean that wallets with different seeds would cause a clash of their addresses. Am I right?

You really gave a good point however I think there must have an explanation. I will wait for others answer.

As pooya said it is limited to 2^256 (in practical terms only 255)

However this is a very big number.

Every seed can create billions of addresses in each derivation path. That means billions of addresses in change addresses, in legacy, segwit, native segwit, etc etc

A collision , which is what you are talking about is impossible in practical terms. Billions of addresses randomly generated is hard for our minds to understand.


From antonopoulos mastering bitcoin:

https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc#navigating-the-hd-wallet-tree-structure

The HD wallet tree structure offers tremendous flexibility. Each parent extended key can have 4 billion children: 2 billion normal children and 2 billion hardened children. Each of those children can have another 4 billion children, and so on. The tree can be as deep as you want, with an infinite number of generations.

[MrFreeDragon]

In order to understand, how many address could be generated from one seed we should go to the process of address generation in HD wallets.
As bitmover said, there are 4 billion children possible:

From antonopoulos mastering bitcoin:

https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc#navigating-the-hd-wallet-tree-structure
The HD wallet tree structure offers tremendous flexibility. Each parent extended key can have 4 billion children: 2 billion normal children and 2 billion hardened children. Each of those children can have another 4 billion children, and so on. The tree can be as deep as you want, with an infinite number of generations.

To be exact, the 4 billions means 2^32 - 1 = 4 294 967 295 (this was a limit designed in HD wallets).

The path format of HD wallets is m / purpose' / coin_type' / account' / change / address_index, where account, change and address_index are dependnecies for address creation based on master private key (SHA of the seed).
Let's say for bitcoin it is m/44' /0 / account' / change / address_index

account and address_index could be in the range from 0 to 2^32-1 (2^32 total combinations), change could be 0 or 1 (change address or not), so 2 total combinations.

Hence, the total number of possible combinatins is 2^32 * 2^32 * 2*1 = 2^(32+32+1) = 2^65 which is 2^191 less than the total possible private keys and 2^95 less than the total possible addresses (cinsidering hash160 function) for every address type (legacy, segwit, bech32)

So, considering the HD wallet limitation (2^32 for child and address index), we need at leat 2^95 different seeds in order to generate all possible addresses (withount collisions).

[mpufatzis]

Is it possible to calculate (theoretically) , how many common addresses could derive from the seeds?

If there are 2048^12 different seed combinations (in 12-word BIP39) and each has  2^256 keys then we have 6.3X10^116 different addresses.
We have altogether in Bitcoin 2^160=1,46x10^48 different addresses, which is a smaller number than the first one.

How many of them are common?

I would like to know is there a limit to how many bitcoin public keys be generated using one seed phrase. Is it unlimited?

It is unlimited

If it's not limited then this would mean that wallets with different seeds would cause a clash of their addresses. Am I right?

You really gave a good point however I think there must have an explanation. I will wait for others answer.

As pooya said it is limited to 2^256 (in practical terms only 255)

However this is a very big number.

Every seed can create billions of addresses in each derivation path. That means billions of addresses in change addresses, in legacy, segwit, native segwit, etc etc

A collision , which is what you are talking about is impossible in practical terms. Billions of addresses randomly generated is hard for our minds to understand.


From antonopoulos mastering bitcoin:

https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc#navigating-the-hd-wallet-tree-structure

The HD wallet tree structure offers tremendous flexibility. Each parent extended key can have 4 billion children: 2 billion normal children and 2 billion hardened children. Each of those children can have another 4 billion children, and so on. The tree can be as deep as you want, with an infinite number of generations.

[odolvlobo]

Is it possible to calculate (theoretically) , how many common addresses could derive from the seeds?

If there are 2048^12 different seed combinations (in 12-word BIP39) and each has  2^256 keys then we have 6.3X10^116 different addresses.
We have altogether in Bitcoin 2^160=1,46x10^48 different addresses, which is a smaller number than the first one.

How many of them are common?

A BIP-39 12-word phrase can represent 2¹²⁸ seeds (it contains a checksum). As noted above, an HD wallet can normally generate 2⁶⁵ private keys from a seed. Thus, the 12-word phrase can generate 2¹⁹³ private keys, which is 2³³ times the 2¹⁶⁰ possible addresses.

[d.kevin29]

In order to understand, how many address could be generated from one seed we should go to the process of address generation in HD wallets.
As bitmover said, there are 4 billion children possible:

Might've got it wrong, but I'd like to ask the following just to make sure I understand: does this mean 2^65 is the max number of addresses your seed can create? I know the number is HUGE (36,893,488,147,419,103,232), but what happens if somebody somehow created the last possible address in their seed? Does it start over from the first address?

[MrFreeDragon]

In order to understand, how many address could be generated from one seed we should go to the process of address generation in HD wallets.
As bitmover said, there are 4 billion children possible:

Might've got it wrong, but I'd like to ask the following just to make sure I understand: does this mean 2^65 is the max number of addresses your seed can create? I know the number is HUGE (36,893,488,147,419,103,232), but what happens if somebody somehow created the last possible address in their seed? Does it start over from the first address?

There is a  very easy answer on your question: It depends!

I'm sure that you are not happy with this answer. So, here are more details.
First of all you should understand how Bitcoin public and private keys are connected and also understand the scalar addition of ECDSA points.

If k - the private key, then Public Point is k*G, where G is the basic point, and the X-coordinate of that public key will represent the public key --> the bitcoin address. All these operations are made under mod p (which is 2^256-2^32-2^2^8-2^7-2^6-2^4-1 - determined in bitcoin ECDSA)
So, if you now want to receieve the address from the subsequent private key (k+1), the public point for that key will be (k+1) * G which is exactly k*G + G. The public point for key (k+m) will be k*G + m*G which is the addition of the Public Point for k and the Public Point for m.

This particulariyu is used in HD wallets. So you can easily calculate the subsequent address knowing the master public key, and you do no actually need to know the master private key, as the subsequent address could be calculated based on Public Point.

Why did I say in the beginning that it depends? Because, if you are facing with HD wallet there the subsequent address is only the increase of the private key by 1, so actually you do not need the limitation of 2^32  for the index, you can calculate the next address just increasing the private key by 1.  So, using some seed you will start at some point (let's say the master private key is mpk = 2^100), the every next address is mpk = mpk +1 up to the order (which is close to 2^256). When mpk exceeds the order, it starts from 1 and will increase up to initial private key 2^100. So, you will have all possible private keys generating the subsequent address 2^256 times.

BUT, in reality HD wallets are not so easy. In reality HD wallets use special chain to generate the "neighbour" addresses index, i.e. the difference in neighbour private keys of HD wallet will be not 1 (as in the easy example above), but it will be one way hash of address index and a special chain code. Thats why HD wallets uses not just private and public keys, but master private key and master public key. That master keys contain also the "chain code" which is the same as in master private key, so in master public key. Knowing this chain code it is possible to generate ANY index address of the HD wallet (with the master public key) and ANY index private key (with the master private key).

So, returning to the initial question, in practice, the key out of 2^65 range in HD wallet wil not repeat the 1st key. Because of the random entropy (for chain code and master private key) and one way sha256 (for subsequent address generation) used in HD wallets.

You can also find more details about how HD wallets works here: https://bitcoin.org/en/wallets-guide#hierarchical-deterministic-key-creation

PS. Regardless of HD wallets, how many private keys (addresses) could be generated from the starting private key 6a4669bc5d8959ab24a60e15da09275c950539edf45cfc138ab527eeb4f136d8 (which is sha256('d.kevin29') - sha256 from your forum nick) making the next private key privkey n+1 as sha256(privkey n)? Is it the whole 100% available range from 1 to 2^256 or only 10% of this range? Inspite of easier calculations in this example (compared to HD wallets), there is no answer.

[Dabs]

I'm not sure what the point is, but, let's attack this from a different angle. Why don't we start with the smallest private key and work up from there. When we get to the last possible private key, then we have generated all possible private keys.

Of course, that's not really a seed, and while it can be a naive form of deterministic wallet (increment private key by 1), this process will get all possible private keys, and public keys and addresses. It's also going to take forever, however you define that word, it's still forever. (Don't tell me the age of the universe is not forever.)

[MrFreeDragon]

I'm not sure what the point is, but, let's attack this from a different angle. Why don't we start with the smallest private key and work up from there. When we get to the last possible private key, then we have generated all possible private keys.

The initial question was not to generate all possible keys. TC asked is it possible to generate all possible addresses from one seed. So, some seed should be a starting point.
The most common practicals ways to use the seed as a key to the wallet are: (1) to use HD wallets, (2) to make sha256 from the seed

[Dabs]

If you have ten thousand monkeys typing on keyboards, they'll eventually type the complete works of Shakespeare. But it will most likely happen after the universe is dead. (So they say, I'd argue it just won't happen, not in the next hundred generations.)

From a practical point of view, it's not possible to prove that one can generate all possible addresses from one seed. You can't know, because to find out, you'd have to try them all.

Just like other pseudo random number generators that start from a certain state, you can't possibly tell what was, from what's next (or the other way around) without knowing the state. Those things can have very long periods, like the Mersenne Twister.

The reason we picked such large numbers for usage in bitcoin (2^160, 2^256) is so that the odds of any two different processes coming up with the exact same private key or address is negligible or practically non-existent.

Yes, there is a chance. There's also a chance you'll win the mega millions powerball lottery or get struck by lightning several times in a row. Not just one in a million, or one in a billion. It's one in a quadrillion (or other large number, googol, age of the sun, that type of thing.)

[igor72]

The path format of HD wallets is m / purpose' / coin_type' / account' / change / address_index, where account, change and address_index are dependnecies for address creation based on master private key (SHA of the seed).
Let's say for bitcoin it is m/44' /0 / account' / change / address_index

account and address_index could be in the range from 0 to 2^32-1 (2^32 total combinations), change could be 0 or 1 (change address or not), so 2 total combinations.

Hence, the total number of possible combinatins is 2^32 * 2^32 * 2*1 = 2^(32+32+1) = 2^65 which is 2^191 less than the total possible private keys and 2^95 less than the total possible addresses (cinsidering hash160 function) for every address type (legacy, segwit, bech32)

So, considering the HD wallet limitation (2^32 for child and address index), we need at leat 2^95 different seeds in order to generate all possible addresses (withount collisions).

Why did you limit your calculations to the BIP44 format? What prevents me from using the derivation path like m/0'/0'/0'/0'/0'/0'/0'/0'/0'/0'?

To the question in the topic I would answer: Yes, it is possible to generate every address from one seed.

[igor72]

But can you mathematically prove that?

In my example, the number of possible keys will be equal 2³²*2³²*2³²*2³²*2³²*2³²*2³²*2³²*2³²*2³² = 2³²⁰. That is on average in this example 2^320-256 = 2⁶⁴ of keys will be repeated. But you can add a branching even deeper if this number is not enough to generate all possible keys.

[igor72]

No, it is generated from a single seed. Only the derivation path is changing.

[MrFreeDragon]

Why did you limit your calculations to the BIP44 format? What prevents me from using the derivation path like m/0'/0'/0'/0'/0'/0'/0'/0'/0'/0'?

Yes, its under BIP44 convention. If you do not want to follow it you can make the non-standard deriviation path for your wallet.
The path in your example is supported for example by Electrum wallet, but it will not be supported by other wallets as it is not standard. You also need to remember the derivation path in addition to the secret seed.
HD wallets were designed for user comfort. User should write down just the seed words, and thats it. It is like brain wallet, but very very secure.

Due to different standards, there is also a warning in HD wallets: "HD wallet programs are not expected to be fully compatible, so users must only use the same HD wallet program with the same HD-related settings for a particular root seed"

To the question in the topic I would answer: Yes, it is possible to generate every address from one seed.

It depends.
Obviously, in order to generate every address with minimal operations, the function should be very simple (like private key = private key + 1). But for HD wallets, you should undertand the process of the sebsequent address creation. Even if you try to create all the addresses in your 8-deep childs HD wallet (2^32*8 = 2*256), you can not be sure that you will create them ALL, because there is no evidence that all the generated addresses will be unique. Some addresses could repeat in your complex wallet. And it is also possible that "some" addresses will NOT be created at all.

In simple wallets, there we increment a private key by 1, we can (only theoretically) generate all the addresses for 2^256 operations. But in HD wallet with complex generation process (where sha used for step calculation for every sunsequent key), you can not prove to generate every address from one seed even theoretically.

From a practical point of view, it's not possible to prove that one can generate all possible addresses from one seed. You can't know, because to find out, you'd have to try them all.

Yes, it's not possible to prove that one can generate all possible addresses from one seed

[Dabs]

There is a practical limit though, assuming the wallet is running on a typical desktop or even a mobile device (phone or tablet). That limit is based on RAM and maybe storage, and it would be somewhere around maybe 1 million addresses.

Actually, beyond ten thousand addresses, some wallets begin to show problems processing them. Exchanges and online wallet providers use custom software to parse info from addresses and show you your balance.

Maybe it's not the addresses too, but the number of transactions. One of my altcoin wallets is several megabytes already, like 300mb and doing rescans takes awhile.

My original bitcoin core wallet.dat is a lot smaller, and that includes a bunch of on-chain (and of course, only on-chain) dice transactions with the old satoshidice.


Aside from big businesses dealing with 10 million customers, who, or what individual needs more than 1 million addresses? Your desktop wallet works fine with up to ten thousand or  hundreds of thousands addresses per wallet; tried it on both Bitcoin Core Qt and Electrum for Desktop.

Have not honestly tried any other wallet; and mobile wallets on phone I don't have more than a few hundred addresses on them anyway.

[igor72]

Why did you limit your calculations to the BIP44 format? What prevents me from using the derivation path like m/0'/0'/0'/0'/0'/0'/0'/0'/0'/0'?

Yes, its under BIP44 convention. If you do not want to follow it you can make the non-standard deriviation path for your wallet.
The path in your example is supported for example by Electrum wallet, but it will not be supported by other wallets as it is not standard.

It is standard by BIP32 and it is supported by other wallets, not only by Electrum.

To the question in the topic I would answer: Yes, it is possible to generate every address from one seed.

It depends.
Obviously, in order to generate every address with minimal operations, the function should be very simple (like private key = private key + 1). But for HD wallets, you should undertand the process of the sebsequent address creation. Even if you try to create all the addresses in your 8-deep childs HD wallet (2^32*8 = 2*256), you can not be sure that you will create them ALL, because there is no evidence that all the generated addresses will be unique. Some addresses could repeat in your complex wallet. And it is also possible that "some" addresses will NOT be created at all.

In simple wallets, there we increment a private key by 1, we can (only theoretically) generate all the addresses for 2^256 operations. But in HD wallet with complex generation process (where sha used for step calculation for every sunsequent key), you can not prove to generate every address from one seed even theoretically.

Ok, I agree. However you can not prove to generate every address from all possible seeds too. And you can not prove that the coin will go to tails at least once in 1000 attempts  .

[MrFreeDragon]

It is standard by BIP32 and it is supported by other wallets, not only by Electrum.

Ok, i do not argue. Agree. Actually I like your comment very much as you raised here a good security point.

While you import your secret seed to HD wallet, it uses the standard deriviation path: it scans the first 20 (default gap) addresses for the 1st account. If there are transactions on these accounts, it scans the subsequent addresses and so on. By default the wallet will never scan the address with index 1,000,000 if it will found the transactions only on the first 5 addresses --> AGeneration of addresses and scanning will stop on the first 20 addresses.

So, making complex derivation paths or just manual settings for account and address indexes in BIP44 could help you to "hide" the addresses within the same secret seed. Example: "Generate a wallet, write down the seed and put it to a secret place. Make some operations with the wallet, for every new transaction the new address will be generated. Let's say we use only 100 first addresses in this way. Then manually generate at home the address for account 2055120551 and index 2055120551 (any numbers could be here within 2^32 range; i used for example postal index of Federal Reserve System 20551 concatenated twice)). These indexes are easy to remember. So, even somebody will found your secret seed, he will not found your hidden bitcoins with the path m/44/0/2055120551/0/2055120551, because he will see only the first 100 addresses where you made the transactions".

PS. BIP32 is old format. Now HD wallets use BIP44 for legacy addresses, BIP49 for segwit p2sh and BIP84 for native segwit

[igor72]

PS. BIP32 is old format. Now HD wallets use BIP44 for legacy addresses, BIP49 for segwit p2sh and BIP84 for native segwit

BIP32 is old but not outdated. The BIPs you listed are based on it and do not contain any new mathematics.