Vanity Address

A vanity address is a Bitcoin address whose prefix has been chosen for vanity reasons rather than left to chance. The generation method is brute force: derive keypair after keypair and check if the resulting address starts with the desired pattern. The search cost grows exponentially with the prefix length.

Not every pattern is possible: the bech32 alphabet has no 1, b, i or o, so bc1qlearnbtc can never exist. Legacy 1... prefixes are case-sensitive, and the way Base58 packs the bytes makes 1R... through 1z... about 58 times rarer than 12... through 1Q....

Rough orders of magnitude for bech32 (bc1q...) addresses:

• 4 custom characters: ~1 million tries (seconds on a laptop)
• 6 custom characters: ~1 billion tries (minutes to an hour on a laptop)
• 8 custom characters: ~1 trillion tries (multiple GPU-hours)
• 10+ custom characters: realistically requires GPU clusters and days of compute

Taproot (bc1p...) prefixes need the same number of tries, but with standard BIP 86 keys each candidate needs a fresh Taproot tweak instead of one point addition, so the same search runs slower.

A genuine example is the 3BMEX... deposit addresses BitMEX used to issue. The famous 1BitcoinEater... address is the opposite construction: hand-written text with only the last six characters worked out so the checksum passes. No key search produced it and nobody holds a key for it, which is exactly what makes it a burn address.

The security trap is letting someone else do the work. If a vanity service generates the key and hands you the private key, they have it too (and so does anyone who breaks into their database). Best practice is one of:

• Local generation with an open-source tool on hardware you control. VanitySearch (CPU or GPU) does 1..., 3... and bc1q... prefixes and vanitygen++ adds bc1p...; the original vanitygen is Base58-only, so it cannot produce the bech32 addresses in the table above. The private key never leaves your machine.
• Split-key vanity generation. You pick a secret a and publish only the point A = aG. The searcher brute-forces offsets b until the address of A + bG matches and sends you b. The private key is a + b (mod n); only you can compute it, because the searcher never learns a. Check that (a + b)G really produces the advertised address before you fund it. Useful when you want to outsource the compute without trusting the compute provider.

Vanity addresses are a privacy mistake by default. Reusing one address for vanity-branding purposes destroys the wallet's transactional privacy by aggregating activity onto one identifier. If you really want a vanity address, generate one and use it as a vanity receive address that you then sweep into normal HD-wallet addresses for actual custody.

What two real searches took

The table gives averages. In October 2026 we ran two searches ourselves with VanitySearch 1.19 on twelve CPU threads of a laptop (an Apple M3 Max, no GPU, about 74 million keys a second once the machine was free). Both patterns choose eight characters. The legacy search asked for 1LearnBTC in any letter case and found 1LeArNBtcECPZj7Bd5oeNcUJnhpVddy81U after 46 minutes and 2^37.6 tries (about 203 billion), half the average for that pattern. The bech32 search asked for bc1qlearn8tc exactly (the 8 stands in for the b the alphabet lacks) and found bc1qlearn8tcerg966qrqtwaelyt06fq2ze7zrsg9t after 6 hours 1 minute and 2^40.2 tries (about 1.24 trillion), 12 percent past its average. Folding case gives most letters two chances out of 58, which is why the bech32 job averaged 2.7 times the work; luck stretched that into six times the tries and eight times the wait. Both keys are demo material with no custody behind them, so never send anything to either address.