Topic: Vanity addresses are unsafe (Read 465 times)

I know that software, but it's quite different since you generate many seed with few address generated from it until you find address that match you need.
My idea is using existing seed, but generate as many address as possible until you find address that match you need.

Either way, it's not practical and more expensive in terms of computational power (which already mentioned in detail by another members).

BIP-85 seems more suitable here.
User can deterministically generate the starting key (step 1 outlined here) at a predefined standard path (m/83696968'/app_no'/index') and finds the vanity address that way.
This avoids any overhead of having any extra steps while adds the possibility of recovering the key from the seed backup by taking the same (time consuming) steps.

It's not quite the same thing... but someone already created an "HD" vanitygen... https://bitcointalksearch.org/topic/vanitygen-hd-a-vanity-hdhdm-wallet-generator-5243577

Theoretically, one could run this on an airgapped machine, then restore the discovered seed mnemonic to a hardware wallet... et voila... "vanity HW"™

Of course, it's fairly obvious that the "security" implications of doing something like this are fairly horrendous.

It'd really suck balls to not be able to convert an arbitrary public key into a bitcoin address. But I guess you could make it opt-in by using a prefix like "bcN" which means the first N bytes are implied to be zero.  But hard to imagine the complexity is worth it and not to mention it'd create yet another heuristic (grinders vs non-grinders) attackers could use for analysis

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.

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

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.

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


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.

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).

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

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.

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).

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.

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.

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


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

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.

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.

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.

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?

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.