Thanks for the answers, so I can't just collect all the bounties at vanitypool in one swoop, but I can search for multiple strings when generating for myself.

You can search for multiple bounties from the same person at once.  If someone wants multiple names, then they should submit them all at once to the site and use the same secret.

Also:
Are you guys creating compressed or uncompressed vanity adresses?
Uncompressed are the original format, but compressed seems to be the standard of the future..
Obviously, at some point all programs will (have to) understand both formats - which isn't the case now.

And then: A firstbit "wasted" on the wrong format can't be used/converted in the other.

Any thoughts on this, or am I seeing problems which aren't there?

Ente

Oh, good hint, I didn't even think of that yet!

I'll start "mining" compressed keys now.

/edit:
I see samr7s' vanitygen doesn't support compressed keys yet.
There seems to be at least two patched versions out there, gmaxwells' and salfters'.
Which one are you using, Dabs? Would you be so kind and share the windows bins of this? I have a remote box available for this with 7970 gpu, but no compiling stuff installed there.
Oh, is there any gpu vanitygen out there for compressed keys? In case I ever get that 7970 to run..

Thank you!

Ente

Thank you for the info!

Ente

The adress, which we see in our clients, are always the same length and look the same no matter if the underlying key is compressed or uncompressed. I can't go into more detail without writing more false than true statements ;-)
(ocl)vanitygen creates only uncompressed keys/adresses, unless you patch it or use a fork from other developers.

Ente

Compressed keys take up less space in the blockchain, so you don't contribute to the bloat. A compressed key is just a way of storing a public key in fewer bytes (33 instead of 65). There is no real reason to use uncompressed keys anymore except if your client can't use it. In which case, I strongly recommend that you switch to a client that does allow compressed keys, such as the bitcoind bitcoin-qt client.

Here is an example of an uncompressed key:
044f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa385b6b1b8ead8 09ca67454d9683fcf2ba03456d6fe2c4abe2b07f0fbdbb2f1c1

Here is an example of the same key in compressed format:
034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa

Notice the length.

A compressed private key is what you send from, so the warning is just telling you that you couldn't take that private key and use it to send funds with the current versions of the listed programs.  The only reason that would be concerning is if the Merchant API were the only way to send coins from whatever you imported to, but it isn't, because you can import the same private key into something else that does support it and use that to send.  IIRC, the funds go to the recipient using the address if it hasn't been seen on the network before and a public key if the address has been seen before.  I don't know if public keys can be compressed, but if they can, and there is a compressed public key on the network, it implies that the recipient can use that key.

The forum that this thread is in is "Development & Technical Discussion".

Thank you for the details!
I'll give it another try eventually.

Ente