Vanity addresses are unsafe

[RHavar]

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.

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

[1714751822]

1714751822

[1714751822]

1714751822

[1714751822]

1714751822

[1714751822]

1714751822

[1714751822]

1714751822

[HCP]

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

It's not quite the same thing... but someone already created an "HD" vanitygen... https://bitcointalk.org/index.php?topic=5243577.0

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.

[Coding Enthusiast]

My idea is using existing seed, but generate as many address as possible until you find address that match you need.

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.