6 digits spaced apart throughout the key would work better - first 6 hex digits means if your vanity key had the mleku in the beginning, any impersonator generating npub1mleku would get your mleku AND your colors
anyone who uses next.nostrudel.ninja would be seeing a change that nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr made to use the first 6 hex digits of pubkeys as a colour outline to help reduce impersonations... i thought it was his idea... he thought it was my idea... lol! maybe i was not in my normal mind also at the time haha
Discussion
(Making it 8 or 10 digits would also make it exponentially harder to crack)
takes about 4 days to make 5 characters like my npub
each additional character is probably 100x as long, for example you can mine a 3 character string in about 5 minutes maybe, 4 character in a few hours
the thing is that the pubkey is a hella amount of calculation to check for a pattern on top of the secret... i'm not sure if there is some way to fragment them, like, to use the EC group but make it a dual key split out of two keys, and then how do you compute a signature from that? is it going to use the root key raw bytes with the secondary key raw bytes?
i have not looked into how one can do this, the general idea would be that based on a master pubkey, anyone can compute a valid child subkey, and so on, this would make it possible for someone to send you a message to a key you have the secret for without it having ever been used before and without needing an interactive protocol to generate it
if i remember correctly, the secp256k1 group has an interesting property that if i have a secret somewhere in a chain of HD keys, it is much cheaper for me to reverse the derivation of at least the first upstream key, and then once you have that you can eventually get the root
so even if it is theoretically possible, non-interactive derivative key generation could have some serious security pitfalls on the path