Vanity addresses are unsafe

[Lionel]

If i , with my humble PC, am able to generate a vanity address in reasonable time ...
then a team of hackers with a cluster of PCs can generate all the possible vanity addresses, and constantly monitor them for stealing the funds as soon as they receive a tx.

All the addresses that begin with any keyword like "GIFT" or any business name like "bitstamp" are a very infinitesimal fraction of all possible addresses, so this attack is feasible for a moderately equipped hacker team.

[1713893684]

1713893684

[RHavar]

Before trying to educate people on something, you should make sure you know the subject matter yourself. In this case, you're exactly wrong. Assuming the vanity-address generating software is written correctly, a vanity address is no easier to brute force than any other address.

At it's most fundamental level, vanity address generation is just generating addresses in a loop until you find one that looks pretty and you use that.

A worked example: this is the ultimate vanity address:

Code:

1BitcoinEaterAddressDontSendf59kuE

  tell me the private key, and I'll give you 13.24 BTC.

[o_e_l_e_o]

All the addresses that begin with any keyword like "GIFT" or any business name like "bitstamp" are a very infinitesimal fraction of all possible addresses, so this attack is feasible for a moderately equipped hacker team.

There is nothing inherently different between trying to brute force a vanity address and a regular address. The fact that the first few characters have a pattern that humans recognize is completely irrelevant at a code level.

All the addresses which begin with "HQ3G" or "LdRc" are a similarly small fraction of all possible addresses as those beginning "GIFT". Given those two addresses have a combined bounty of $1.5 billion, why are there not thousands of "moderately equipped hacker teams" creating competing transactions trying to clear them out by now?

Vanity addresses will be insecure if you generate them on an online computer or use an online service to generate them for you, but they are not insecure simply because they have a particular string of characters at the start.

[bitmover]

There is nothing inherently different between trying to brute force a vanity address and a regular address. The fact that the first few characters have a pattern that humans recognize is completely irrelevant at a code level.

Exactly.

A vanity address generator is not a magical tool. It does the same that a wallet does: generates a new address from a private key.
However, the vanity generator will be generating private keys / addresses  pairs until it finds one that matches the text you are looking for.

If you software is safe, in an offline environment, it is safe.



somehow offtopic:
It would be amazing if there was a third party software for ledger nano / trezor that could generate vanity addresses from the hardware wallet seed. That would be much safer.

[pooya87]

i think you are confused about how vanity generation works.
the reason why you are wrong is that you are forgetting about the starting point of searching for the address. it is a random number not a fixed one. and since the private key range is vast it doesn't matter how many keys you check before you get to the final result, it won't be reproduced as long as the initial key was selected randomly.

[ebliever]

On an unrelated note - I had a person recently tell me they were unable to donate bitcoin to a vanity address I had generated in early 2019, using software from probably a couple years earlier. They said their wallet or service (they never told me what they were using) said it was an invalid address. I pointed out the address has a couple test deposits in it and that Bitcoin devs are very careful to maintain backward compatibility during updates to the bitcoin code so that BTC does not become stranded, but does anyone know why a bitcoin wallet would be refusing a transaction to a vanity address?

[pooya87]

but does anyone know why a bitcoin wallet would be refusing a transaction to a vanity address?

possible reasons could be buggy implementation of:
- base58 encoding
- checksum computation
- SHA256 calculation
or it is possible the person copying the address simply copied less or more characters than the real address.

[RHavar]

but does anyone know why a bitcoin wallet would be refusing a transaction to a vanity address?

The bible quote in your signature reminded me of a fanatical Christian dude who maintained (maintains?) a patchset that blacklisted certain prefixes of bitcoin addresses. The blacklist worked by looking at the start of an address and rejecting vanity addresses corresponding to some gambling sites (e.g. satoshidice).

As I recall there was some drama at the time (2014?) when this ridicilious patchset was snuck into the default build in gentoo.

[o_e_l_e_o]

Was it a legacy or a bech32 vanity address? It could simply be that the person was using an old wallet/web wallet/exchange which still did not support SegWit addresses.

[bitmover]

Theoretically it's possible if you continue generate address from the seed until you find prefix that match your needs.

As a seed can generate billions of addresses ^[1], it would be as efficient as a normal vanity generator.

But you need to remember the index.

That is what the software would do
you could just save the derivation path/index with the seed to be safe.



^[1]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.

[RHavar]

As a seed can generate billions of addresses ^[1], it would be as efficient as a normal vanity generator.

That's not nearly the case. A normal vanity generation is something like:

Step 1: Pick a random private key `p`
Step 2: Compute  the elliptical operation `P=p*G`
Step 3: Let V = to_bitcoin_address(P)
Step 4: If V matches our vanity filter, we are done. And the private key is p.
Step 5: Compute p = p+1
Step 6: Compute the elliptical operation P = P + G
Step 7: GO TO step 3.


This is insanely more efficient than using an HD seed which every iteration requires a lot of pointless, slow and complex steps (hashes, EC multiplications) . And also you can resume the process easily by just substituting "Step 1" for using the last `p` you want to continue the process from. In short: Using an HD seed makes absolutely zero sense. I can't think of a single upside.

[Coding Enthusiast]

This is insanely more efficient than using an HD seed which every iteration requires a lot of pointless, slow and complex steps (hashes, EC multiplications) .

Using hardened children it's a single HMACSHA512 and a single modular addition (HMAC can also be optimized to only perform 2 block compressions instead of 4). But yeah it makes no sense to use this method.

[bitmover]

As a seed can generate billions of addresses ^[1], it would be as efficient as a normal vanity generator.

That's not nearly the case. A normal vanity generation is something like:

Step 1: Pick a random private key `p`
Step 2: Compute  the elliptical operation `P=p*G`
Step 3: Let V = to_bitcoin_address(P)
Step 4: If V matches our vanity filter, we are done. And the private key is p.
Step 5: Compute p = p+1
Step 6: Compute the elliptical operation P = P + G
Step 7: GO TO step 3.


This is insanely more efficient than using an HD seed which every iteration requires a lot of pointless, slow and complex steps (hashes, EC multiplications) . And also you can resume the process easily by just substituting "Step 1" for using the last `p` you want to continue the process from. In short: Using an HD seed makes absolutely zero sense. I can't think of a single upside.

thanks.
yeah, really there are many additional steps as you said...

But there is one upside. Security. You can then use your vanity address with the same security as a HW wallet. wouldn't it be worth? at least for small vanity addresses (such as 3-4 characters).

[o_e_l_e_o]

But there is one upside. Security. You can then use your vanity address with the same security as a HW wallet. wouldn't it be worth? at least for small vanity addresses (such as 3-4 characters).

You can create a vanity address on a permanently airgapped computer, and encrypt the wallet or even the entire disk when you are done. Keep the private key on that computer, and set up a watch only wallet with the address on an internet enabled device. Such a set up is more secure than a hardware wallet.

[RHavar]

But there is one upside. Security. You can then use your vanity address with the same security as a HW wallet. wouldn't it be worth? at least for small vanity addresses (such as 3-4 characters).

Well, if you wanted to do that -- you'd use the HD derived value for "Step 1" part. But you wouldn't actually use bip32 to try brute force a vanity address.


Actually if you wanted to make a "vanity hardware wallet" it's not too hard, and the cool thing is the hardware wallet can safely outsource the work to a computer without [realistically] compromising security. (In short: The hardware wallet keeps `p` a secret, but gives you `P` and then you keep track of how many times you need to add `G` to P to get a good vanity address.)


I don't think there's much demand for this sort of thing though, as it'd be pretty toxic for privacy

[bob123]

Such a set up is more secure than a hardware wallet.

But also less convenient.
Having a seed from which the private key of a vanity address is derived, definitely has its charm.

Obviously the time it would take to find a seed which has the vanity address in the first few derived keys, is much higher.
But it might be worth it under some specific circumstances (e.g. the prefix of the vanity address doesn't have to be too long and mobility is important).

[bitmover]

You can create a vanity address on a permanently airgapped computer, and encrypt the wallet or even the entire disk when you are done. Keep the private key on that computer, and set up a watch only wallet with the address on an internet enabled device. Such a set up is more secure than a hardware wallet.

Not convenient, and also costly. I don't have an airgapped computer, I don't have an spare computer computer also...

I don't think there's much demand for this sort of thing though, as it'd be pretty toxic for privacy

Why toxic for privacy? Just as toxic as any other vanity address, which is going to be obviously reused..

You can set your HW balance as unspendable or even create a new seed just for this vanity address.

[j2002ba2]

As a seed can generate billions of addresses ^[1], it would be as efficient as a normal vanity generator.

That's not nearly the case. A normal vanity generation is something like:

Step 1: Pick a random private key `p`
Step 2: Compute  the elliptical operation `P=p*G`
Step 3: Let V = to_bitcoin_address(P)
Step 4: If V matches our vanity filter, we are done. And the private key is p.
Step 5: Compute p = p+1
Step 6: Compute the elliptical operation P = P + G
Step 7: GO TO step 3.


This is insanely more efficient than using an HD seed which every iteration requires a lot of pointless, slow and complex steps (hashes, EC multiplications) . And also you can resume the process easily by just substituting "Step 1" for using the last `p` you want to continue the process from. In short: Using an HD seed makes absolutely zero sense. I can't think of a single upside.

With non-hardened keys it's almost the same:

Step 1: generate a seed s, derive (kpar, Kpar, Cpar) using know derivation path m/a'/b'/c'/0, set i32=0 (the index)
Step 2: P = Kpar + HMAC-SHA512(Cpar, Kpar || i32).L * G
Step 3: Let V = to_bitcoin_address(P)
Step 4: If V matches our vanity filter, we are done. And the private key is kpar + HMAC-SHA512(Cpar, Kpar || i32).L, with seed s, and path m/a'/b'/c'/0/i32
Step 5: Compute i32 = i32+1
Step 6: If i32 >= 2^31 GO TO step 1
Step 7: GO TO step 3.

The main slowdown is elliptic point multiplication in Step 2. HMAC-SHA512 is relatively fast.

My guess is that it's 100 times slower than normal vanity gen. Using some memory tradeoffs 30x or even 10x slowdown might be achieved.

[RHavar]

Why toxic for privacy? Just as toxic as any other vanity address, which is going to be obviously reused..

Because they (inherently) don't look like other addresses, which is information that heuristics can exploit.

[gmaxwell]

I think that while the OP is technically wrong, there is a kernel of truth in their claim.

Vanity addresses, generated correctly, aren't inherently weaker-- as people were quick to point out.

Attackers can generate lookalike addresses for any address, vanity or not-- but they can only look so alike due to exponential complexity.

It's unsafe to tell if a an address, ANY address, is the right one by comparing only a couple characters especially if an attacker can predict what characters you'll check.  Just like statistical methods in password guessing are surprisingly effective I imagine that a sufficiently smart attacker could make more successful lookalikes than you'd assume on first guess-- maybe because he uses fancy techniques to compute really fast, maybe because he is really good at predicting the visual similarity of addresses.

Why would do people use vanity addresses?  Mostly because they expect people to recognize the name as being associated with them.  They use them because they want people to be comparing those friendly human readable characters.

So essentially vanity addresses encourage an unsafe behaviour-- users validating an address by comparing a few easily predicted characters. Making a predictable and weak comparison is unsafe for any kind of address, but for a vanity address enabling a weak comparison is a lot of the point for people.

Is it possible to use vanity addresses safely?  Absolutely-- validate them by comparing parts other than the vanity part.   But do most users compare them safely? Probably not.

If users could be relied on to compare as much non-vanity part as they would on a non-vanity address, you could make an argument that they increase security by making it more expensive to generate vaguely similar addresses. But I think it's clear that this benefit is dwarfed by people-- even experts-- not being as diligent in comparing them.   While working on BIP173 I contemplated making it expensive to brute force similar addresses-- e.g. applying a expensive cryptographic permutation to the data before encoding it in an address.  But I felt I just couldn't justify making implementers life harder for a speculative benefit that only helps really sloppy users. Any operation expensive enough to really slow attackers would be painfully slow on hardware wallet devices which are uniformly very underpowered.  ... and I also expected that because that kind of strengthening would make vanity address generation much harder too I might have had to navigate opposition from users that didn't want vanity addresses to be much less available to them.

Another alternative I considered but didn't go for was requiring the underlying address data to have an all zeros suffix.  This would also make generation expensive-- but would have the additional benefit of allowing shorter addresses-- so at least the benefit wouldn't just be against sloppy users.   But it would really complicate hdwallet/taproot/multisig usage where generating a key is already complicated.

In any case, ... just because something exists doesn't mean it's a good idea. There is evidence in the wild that lookalike vanity addresses being used to rob people and lookalike onion domains in Tor, so the security concern isn't just a theory.

Given that, as mentioned, they're also pretty toxic for privacy (both due to encouraging reuse and being identifiable) they're probably better avoided.