# Deterministic wallet and address generation

I have a ledger nano hd wallet and I actively used the Google Chrome plugin to receive some transactions. After that I linked the HD wallet to my mycelium tablet app.

If I receive more transactions using the tablet app how can the chrome plugin stay in sinc and create a new public address from the correct starting point?

How can multiple instances of deterministic wallets referring to the same wallet know where to start to create new addresses?

I guess they don't sinc up and address reuse seems inevitable

Im assuming the HD ledger nano uses a deterministic wallet

The Ledger uses BIP 32, 39, 44 technology as do many other similar harware wallet devices, e.g. Trezor, Keepkey. You should be free to use your hardware wallet across multiple genetically independent software implementations on the same computer or across multiple computers with USB interfaces.

It works simply because each wallet application can rebuild itself each time it is instantiated as process or thread. Using a HD wallet seed (typically 12, 15, or 24 BIP 39 words), a HD wallet application effectively confers with a full node (exist locally, or remotely when SPV technology is used) and sequentially cycles across an integer set BIP 44 indices until it see no more algorithmically related transaction postings on a blockchain or related pending transactions in the blockchain's transaction pool can be detected. Some stateless HD web wallets (e.g., can be accomplished by mytrezor.com) will tend to do this and boot up more slowly, while other stateful HD wallet (e.g., Electrum) applications will save state locally and boot up quicker.

Well, it's a deterministic wallet. There is a function f which for every n∈ℕ returns the nth address that will be produced.

An address is basically a hash of a public key (we can neglect the rest it's comprised of but it's deterministic as well).

You can get a public key from a private key deterministically.

Every 256 bit number is a private key.

So your wallet just needs to make 256 bit numbers deterministically and do calculations to get to addresses deterministically.

This can easily be done by picking a hash function which outputs 256 bit – let's choose sha256 – and a salt λ. A salt is just something that's added to the input of a hash function.

If your wallet knows λ, it can generate a practically arbitrary amount of bitcoin addresses.

g(n) for every n∈ℕ can be defined as g(n) := sha256sum(λ.n) where `.` is the concatenation operator. g(n) is the nth private key.

If you use a Linux computer, just open the terminal and type in:

``````echo "aR3Ba9raAi1" | sha256sum
echo "aR3Ba9raAi2" | sha256sum
echo "aR3Ba9raAi3" | sha256sum
echo "aR3Ba9raAi4" | sha256sum
echo "aR3Ba9raAi5" | sha256sum
echo "aR3Ba9raAi6" | sha256sum
.
.
.
``````

`aR3Ba9raAi` is λ. The last digit of the parameter `echo` gets is n but of course it can be more than 1 digit.

Via the output you get:

``````g(1) = 49fc13b53bf8cbc8607c121066a974f5c803aee04629e11696946f93b16825a6
g(2) = 9462e18f435684eb8bf5008f8e7c717729fbfa505554ef4b3325a3eccc807519
g(3) = d7bde9e8c19959b0abaa5c476a3fc7a4eacf713fe78c9e2a66ac202419ddbf6f
g(4) = d08ddf753bb37b853407f1451334bb042d93ee2179c01244a019229a32fe9c03
g(5) = 4291513728b1a0d96b72df35bafa1f78db1ceaf135d874a3d8e5353aa9408893
g(6) = e04aba61558daaa532d252397e5d5467c8dd64552f987e54245ab759dd0517cb
.
.
.
``````

Those would be the private keys. They are the same on every machine as long as λ stays the same. No between your machines is necessary after they all know λ. g(n) is deterministic and so is everything else afterwards on the way of generating an address. So f(n) can be calculated from g(n).

Of course that's only an example to show you the basic principle behind deterministic address generation. It's strongly simplified and major steps for generating addresses are omitted. This answer should only show you that something can be calculated the same way on different machines without the need of them being able to communicate with each other.

This is also great because everything you need to recover an HD wallet is a seed. You don't need the entire history of what's been generated from the seed because it can be generated the exact same way again.

• So if, like the OP mentioned, he uses a hardware wallet. How does the wallet software know how to generate these addresses if it no longer has access to the private key? Another way to ask: If you never plugged the hardware wallet back into the computer, would the wallet software still be able to make new addresses? Aug 20, 2016 at 13:30
• "if it no longer has access to the private key" What do you mean by that? A HD wallet creates a practically arbitrary amount of private keys. Those are the return values of the function g in my answer. The different wallets only need the same λ. "If you never plugged the hardware wallet back into the computer, would the wallet software still be able to make new addresses?" Yes. And they would be able to make the exact same addresses as the instance of the HD wallet on @Gianluca's table on a different computer. The HD wallet produces more addresses until it finds some which haven't been used. Aug 20, 2016 at 14:22
• If this answers your question, please click the check on the left side to show that this question has been answered. Aug 20, 2016 at 17:13
• Actually not. Probably it's my broken English. I have two apps linked on the same hd wallet. I create a new receiving address on the first one.if now I go on the second app and ask for a new receiving address I get the previous one , isn't it?so basically I'm reusing the same address Aug 20, 2016 at 17:22
• That's the case if the wallets don't look on the blockchain or ask a sever whether a certain address has already been used. Then they have an internal counter which saves their current n. The address the wallet will give you is f(n+1) and it'll increment its n by one. The other wallet, however, doesn't know that. It produces the same address for its n which has not been incremented so the same address is produced twice. There are wallets which fix this, for example Electrum. Electrum asks a server whether an address has been used and increments its n until an unused one has been found. Aug 20, 2016 at 17:36