[Beginner question] Vanity from Xpub

[Hispo]

I have got a question: Is it possible to get a vanity address from xpub?

I was planning to code a little program on python to do so (I am an also a beginner at it), but I would like to know whether it is possible or not first.

[jackg]

I don't think it's been done yet but I think it might be quite slow to function and that's why it hasn't been done and published at least.

[khaled0111]

As far as I know, you can derive only up to 2³¹-1 public addresses (non-hardened) from an xPub, so this might be the only limitation.
You will have to generate a new xPub and use it to derive a new set of addresses, so you have to keep track of that alongside the child index. You will need them to get the private key corresponding to the address (supposing you have the xPrv in first place).

You will probably get more help if you move this topic to Development & Technical Discussion

[Hispo]

I have got a question: Is it possible to get a vanity address from xpub?

No, neither can you get it from ypub or zpub.

To create vanity address, why do you not try the normal ways

[GUIDE] How To Create Vanity Address (Segwit)
[Guide] How to create your customized Bitcoin-Address (vanitygen) – step by step

I have already used the "normal way" to experiment..
I was holding up to the hope there was a more efficient way to generate them without force bruting a private key. Besides, handling a private key per vanityaddress is... not comfy.

But thanks for the straight forward reply.

[ranochigo]

You can theoretically have more than enough derivation path to find the desired vanity addresses without having to switch keys. The prefix or the pattern of the addresses are independent of the seed or any other factors, so you'd have to keep track of the derivation path as well as the index. It can be quite tedious but it would allow you to have all of the vanity addresses being derived from a seed, but with differing path and non-sequential indexes.

[o_e_l_e_o]

No, neither can you get it from ypub or zpub.

Sure you can. Just use the xpub to derive addresses until you find the prefix you want.

As far as I know, you can derive only up to 2³¹-1 public addresses (non-hardened) from an xPub, so this might be the only limitation.

You can only have 2³¹ - 1 unhardened indexes at each level in the derivation path, but your derivation path can have a total of 255 additional levels after your master key m. That gives you a total of (2³¹ - 1)²⁵⁵ possible derivation paths which do not use any hardened derivations, which is still far in excess of the total number of valid public keys.

[pooya87]

It simply makes no sense to use an extended key to derive a single vanity address. Extended keys by nature are designed to be used for many child keys not only a single one. If you want to create 1 vanity address you have to generate 1 key (hence using an initial seed).

You can always adapt the method in a weird way though. For example the extended pubkey can be used as the seed, eg. use the pubkey at m/0'/0 to start the search and increment that key millions of times to find the desired address then compute its private key by adding the number of times you incremented the pubkey to the private key at m/0'/0.

[Hispo]

Thanks everyone for the replies, I shall move the topic, so hopefully I will get even more help.

[odolvlobo]

Is there an advantage to generating a vanity address from an extended key? Note that it is also slower than the standard method.

[o_e_l_e_o]

Is there an advantage to generating a vanity address from an extended key? Note that it is also slower than the standard method.

The only advantage I can see is that you can back up a single seed phrase and one or more derivation paths, rather than individual private keys, although if your derivation paths are particularly long or complex then there is just as much risk as making a mistake with them as there would be with a private key (and probably harder to brute force a mistake than it is with individual private keys).

I suppose as well when spending from your vanity address you'll have a ready made supply of change addresses available to you, which you wouldn't have with individual private keys.

[pooya87]

I suppose as well when spending from your vanity address you'll have a ready made supply of change addresses available to you, which you wouldn't have with individual private keys.

Considering that a vanity address by nature is an address that is reused I don't think the ability to create more change addresses can be considered a benefit, the same address could be used for change as well.

[Hispo]

Is there an advantage to generating a vanity address from an extended key? Note that it is also slower than the standard method.

Is there an advantage to generating a vanity address from an extended key? Note that it is also slower than the standard method.

The only advantage I can see is that you can back up a single seed phrase and one or more derivation paths, rather than individual private keys, although if your derivation paths are particularly long or complex then there is just as much risk as making a mistake with them as there would be with a private key (and probably harder to brute force a mistake than it is with individual private keys).

I suppose as well when spending from your vanity address you'll have a ready made supply of change addresses available to you, which you wouldn't have with individual private keys.

I suppose as well when spending from your vanity address you'll have a ready made supply of change addresses available to you, which you wouldn't have with individual private keys.

Considering that a vanity address by nature is an address that is reused I don't think the ability to create more change addresses can be considered a benefit, the same address could be used for change as well.

I had something on my mind like a little program which would ask for the user to introduce their public key and then the prefix of choice, once that is done, the program would withdraw computing power from the computer to start looking for the desired address.

I thought this would be an advantage because if you are using a cold wallet, you could use vanity addresses without exposing the private keys.
Also, people who have several inputs/outputs may share customized addresses for differente purposes, how several people do already, but without managing several private keys.

[odolvlobo]

Is there an advantage to generating a vanity address from an extended key? Note that it is also slower than the standard method.

I thought this would be an advantage because if you are using a cold wallet, you could use vanity addresses without exposing the private keys.

Hey, that's not a bad idea.

[pooya87]

I had something on my mind like a little program which would ask for the user to introduce their public key and then the prefix of choice, once that is done, the program would withdraw computing power from the computer to start looking for the desired address.

That's the principle that the third party vanity creators, or vanity pools use. They get user's public key and then report back a number that was added to that pubkey.
The problem here would be storing the final result. The cold storage still has to be updated with the final private key or at least the difference (the number of times G was added to the pubkey) should be stored so that user doesn't have to perform the same long operation each time they want to access the funds.

[ranochigo]

I had something on my mind like a little program which would ask for the user to introduce their public key and then the prefix of choice, once that is done, the program would withdraw computing power from the computer to start looking for the desired address.

I thought this would be an advantage because if you are using a cold wallet, you could use vanity addresses without exposing the private keys.
Also, people who have several inputs/outputs may share customized addresses for differente purposes, how several people do already, but without managing several private keys.

Split-key vanity generation basically fulfills all that you're looking for, without additional complexity. By introducing complex derivation paths and indexes, you risk losing your funds if you don't know the exact path and index. In addition, because there is an extra step when converting your seed and an arbitrary derivation path and index during the generation, there is likely some additional resources needed in the process as well.

I can see a point if you're looking for multiple vanity addresses in succession within a seed. That would definitely be harder than just generating them individually.

[o_e_l_e_o]

I thought this would be an advantage because if you are using a cold wallet, you could use vanity addresses without exposing the private keys.

Hey, that's not a bad idea.

Am I missing something here? It is trivially easy to use vanity addresses in a cold wallet without exposing the private keys using the more traditional methods of generating them.

Run your vanity generator on an airgapped computer, collect the private keys from all the addresses you want you use and import them in to an airgapped wallet such as Electrum. Then just take your addresses over to an online computer and create a watch only wallet with them.

[pooya87]

Run your vanity generator on an airgapped computer,

Some people use old computers (an old second hand laptop for example) to use as a dedicated air-gap system to be used to store the offline wallet, sign,... Obviously such systems are slow and generating a vanity address within reasonable time is out of the question. Split key method could help in this case so that they can use their main system that may be stronger.

[Hispo]

I had something on my mind like a little program which would ask for the user to introduce their public key and then the prefix of choice, once that is done, the program would withdraw computing power from the computer to start looking for the desired address.

That's the principle that the third party vanity creators, or vanity pools use. They get user's public key and then report back a number that was added to that pubkey.
The problem here would be storing the final result. The cold storage still has to be updated with the final private key or at least the difference (the number of times G was added to the pubkey) should be stored so that user doesn't have to perform the same long operation each time they want to access the funds.

Do you know where could I find the program used by vanity creators?
Perhaps, knowing the path which leads to the desired address, one could manipulate Electrum (which would store the public keys of a Trezor or Ledger, in order to show de address)

I thought this would be an advantage because if you are using a cold wallet, you could use vanity addresses without exposing the private keys.

Hey, that's not a bad idea.

Am I missing something here? It is trivially easy to use vanity addresses in a cold wallet without exposing the private keys using the more traditional methods of generating them.

Run your vanity generator on an airgapped computer, collect the private keys from all the addresses you want you use and import them in to an airgapped wallet such as Electrum. Then just take your addresses over to an online computer and create a watch only wallet with them.

I was thinking like, managing all your vanity with your main seed and without exposing it to the internet or an internet connected computer.

Something like: Go to your Ledger/Trezor, copy-paste your xpub to a program to get a vanity, you get a vanity address.
You want another?
You do the same again, and again all without managing several xpriv's, the only seed would keep stored withit the Trezor/Ledger the whole time.

The only problem I see would the the computing power and the fact the xpubs being exposed are still a problem, not as severe as seeds being exposed, though.

I had something on my mind like a little program which would ask for the user to introduce their public key and then the prefix of choice, once that is done, the program would withdraw computing power from the computer to start looking for the desired address.

I thought this would be an advantage because if you are using a cold wallet, you could use vanity addresses without exposing the private keys.
Also, people who have several inputs/outputs may share customized addresses for differente purposes, how several people do already, but without managing several private keys.

By introducing complex derivation paths and indexes, you risk losing your funds if you don't know the exact path and index.

Even with Hierarchical Deterministic wallets?

[ranochigo]

Even with Hierarchical Deterministic wallets?

Yes. Your vanity addresses are going to be scattered around the different derivation paths, so if you need to use a specific address, you need to input quite a large and arbitrary number. If you don't remember the path, then you don't have access to your funds. It is obviously possible to bruteforce it but it would be too much effort and in certain cases not feasible. If you still have to take note of the derivation path and the index when using your wallet, then I reckon there is no benefits over a split key generation.

Vanitysearch is a common program used for individual vanity generation.

[o_e_l_e_o]

I was thinking like, managing all your vanity with your main seed and without exposing it to the internet or an internet connected computer.

If you want your vanity addresses' private keys to be stored on a hardware wallet, then yes, this is the only way to do it since hardware wallets will not allow you to import external private keys for obvious reasons. But a hardware wallet is not the only type of cold storage, and you can easily have airgapped vanity addresses using an airgapped computer.

Even with Hierarchical Deterministic wallets?

As ranochigo explained, if you lose your derivation path then you may never find it again, given the absolutely enormous number of possible derivation paths. Further, if you make a mistake it will be much harder to fix than with a private key.

With a WIF private key, we know the number of characters and it includes a checksum. If we miss out, add, swap, or substitute a character or two it is easy to brute force. With a derivation path we have no idea. If it is wrong you may have missed out an entire level, which could be any number, in any location, could be hardened or unhardened. You might have added a level, missed out or added hardening, etc. You could end up with a derivation path with 30, 50, 100 levels in it. Far easier to make a mistake when trying to write it down as back up.