Bitcoin Forum

Hello community,
as offered here (https://bitmit.net/de/trade/i/2447-bitcoin-custom-adresses/description) I have experienced it's possible to create custom bitcoin bitcoin addresses. I've contacted the seller but it seems he can't help me at the moment.

I want a bitcoin adress, after the starting 1-digit, with 7 certain case-sensitive digits. Whoever is able to create such addresses and tell me how to import them to my wallet, please contace me via PM, you can name your price for this service, I'll be generously.

https://bitcointalk.org/index.php?topic=25804.0

you will not be able to get 7 digits though.

Also you will not be able to get an address without a private key, therefore you're risking loosing everything on it "buying" this from a third party.

Thank you.
Isn't this a matter of time and key generating power?

Correct (but the difficulty dramatically increases per character).

You can generate an address with 5 leading characters (after the 1 of course) with just an average computer using vanitygen.

I did it using an average 2 year old laptop in about 4 days. :)

Well yes. It took me about 15 minutes to get to 5 digits, I imagine it would take quite a bit longer to get to 7. But I guess it can be done, eventually.
But as I said, I wouldn't trust anyone else with this, so do it yourself.

Wow - guess my laptop computer is rather slow then. :(

It ran on quite a decent GPU, so there really is no comparison :)

I played around with vanitygen, and from my experience it appears that the length of custom text you want isn't important, some addresses just took longer to generate than others, regardless of the number of vanity characters.

The algorithm is really "dumb", it just generates addresses and stops when it finds one that matches the pattern. Difficulty grows with length (imagine trying to find a certain address from first to last digit, chances of finding it are almost non-existent), but there's quite a bit of variance in this, it might take 1 second or it might take 1 hour to find the same pattern (just like block mining).

If it's done right, the party generating the address for you has no access to the private key, only the public key.

It works like this:

1) You generate a random 256-bit integer less than the SECP256k1 generator. You keep this secret. (Effectively, an ECDSA private key.)

2) You compute the corresponding EC point on the SECP256k1 curve. You share this with whoever is finding the vanity address for you. (This is the ECDSA public key that corresponds to the private key you generated in step one.)

3) The person working out the vanity address for you tries various 256-bit integers also less than the SECP256k1 generator. They compute the corresponding EC point and add it to the EC point you sent them (from step two). They then hash this and see if it produces the desired vanity address. They repeat this over and over until they find a 256-bit integer that works. They give this integer to you. (And the world, it need not be kept secret.)

4) You add the 256-bit integer they found to the 256-bit integer you generated in step 1 and reduce it modulo the SECP256k1 generator.

5) You now have the private key, and they don't. (And you can prove that they cannot generate the private key from just the information you gave them unless ECDSA is fundamentally broken.)

In ECDSA, you convert a private key to a public key by multiplying by the generator. Division is impossible.

The vanity address generation scheme above works because: (A+B)*G = AG + BG

You generate A and AG, but give them only AG.

They try various different B's, calculating the AG+BG for each one to find the right one for the vanity address.

They give you B. You can now compute A+B (the secret key corresponding to the public key AG+BG) but nobody else can since they do not know A.

Computing A from AG would mean breaking ECDSA fundamentally. All you gave them is AG, an ECDSA public key. If they could figure out the private key to your new account (A+B), they could also figure out A. So if they could figure out the private key to your vanity account, they could also figure out the private key you created in step 1. But all you gave them was the corresponding public key. So any compromise of the vanity account would mean they could compromise a private key given only its corresponding public key.

My name is 7 digits.
With my GPU, case-insensitive I found 1 TehzoMB in 24 hours.
When I didn't set the case-insensitive flag, the ETA for a 50% chance of finding a key was two years. You might want to rethink what you're asking for. <-- wrong info/name/prefix/aaah

Doesn't anyone have a farm optimized to run Vanitygen yet? They could sell their services. For optimizations, you just need to overclock and make sure your memory is clocked up as well. It should run very fast on a 7970.

I can probably find this for you, I've generated some and I have vanitygen installed.  I have up to 7.7 GH/s here and I'm sure I found find 7 digits (or at least try!)

What's the bounty on this? :)

i wouldn't trust anybody else generating private key for me, unless maybe if it's done how JoelKatz describes above

if you have good or decent GPU just use vanitygen software yourself and if 7 chars estimate is too long, try to come up with shorter alternatives

my 5800 GPU took couple of hours generating 6 char. vanity gen address without overclock settings, i generated 2 such addresses each taking roughly 2 hours to find, 4 and 5 chars were found extremely fast.
7 char could take much longer, up to few days i think with 5800 series card for instance

I got 7 characters no problem for my vanity addy using a single 5850 and vanitygen.

1GigavpsDjLBQJzHenH3zPq3EwkENL9tQS

There is an element of luck however the length of the custom text most certainly affects difficulty.  The average search time grows with each digit.

A case sensitive search will require 58^(length) attempts on average.

And... How can we add this address to our wallet?

You can import the private key. Each client has a different way of doing that.

quite simple, even on windows, assuming using official bitcoin client:

• shutdown Bitcoin-QT client
• start bitcoind.exe (leave this blank terminal bitcoind.exe screen open while doing next steps)
• in new Command Prompt window navigate to bitcoind.exe location, by default it's something like C:\Program Files (x86)\Bitcoin\daemon>
• type following in command prompt:
  
  C:\> bitcoind importprivkey <bitcoinprivkey>
  
  where <bitcoinprivkey> is your newly generated private key for the vanitygen address you just generated
  
  
• it's going to take few moments, after it's complete, you can shutdown bitcoind from windows task manager processes or just typing "bitcoind stop" in the command prompt
• start bitcoin client again, you should be able to see your vanitygen address in there

On my rather lame laptop this took much more than a few moments (I thought it had hung and killed the task after 10 minutes).

i was watching these "few moments" with windows task manager processes open after the task didn't complete instantaneously )) so i sow it was doing something by using 25% of the CPU, took about 10-20seconds to import the key on my system

Yes, it is going to need to do a full blockchain verification in order to pick up inputs (even though you just generated it - it doesn't know that of course), so that means reading about a gigabyte of data and doing a few hash operations. A fast disk would help.

where can i find detailed instructions on how to use vanitygen?

see this thread https://bitcointalk.org/index.php?topic=25804.0
to utilize GPU use oclvanitygen.exe from its distribution, much faster than generating with CPU

Thanks Serge, it worked in my linux system. :-)

Interesting... why does it take longer to find 1nimda than 1Nimda?

I'm the seller :D
To generate the address 1Nimda takes around 40/50 minutes at 270 Kkeys/s ( 2 CPU's).
Response for the creator of the topic, as I tell you my laptop is very slow to generate complex addresses, but your request its a bit difficult sorry but I can't help you.

And I need help please,
Im trying to figure out what JoelKatz write about secure generating, but I really don't understand what he say, can anyone explain more easily, because I wanted to improve the quality of my service.

The steps shouldn't be too hard. Implementation probably requires some coding though.

1) Have the buyer create a private key, and send you the public key. If vanitygen has an option for producing the public keys along with addresses from private keys, this would be ideal. Even if it doesn't, IIRC vanitygen is written in python, so it shouldn't be too hard to modify it to print the public key along with the private key and address.

2) Have a program that generates private keys and public keys. Have it add the buyer's public key (the one he sent you) to each of your public keys before hashing it to get an address. Again, adding this step in the vanitygen code shouldn't be too difficult... hard-code his public key if necessary.

3) When you find an address that matches what the buyer wants, send him the private key that matches YOUR public key (the one you added to his to get the address.)

4) The buyer then adds your private key to his, does a little bit of math (step #4 of JoelKatz's instructions), and now has a new private key, one that you don't have and can't get, and can use it to get the address you found. A few lines of code would be all that's required to do this math, but you may have to provide the program to buyers.

Actually... there's probably a few bitcents in donations to be made from someone packaging all this into one or two simple little programs or vanitygen mods (not sure the vanitygen code's license approves of that though.)

Why would it need to be less than the generator?


Again, why the constraint?  It shouldn't be necessary.


You mean modulo the order of the underlying field I think.

Other than that, neat scheme!

I got rid of this "few moments" delay by commenting out two lines in the source code that perform this lengthy rescan - I did this so I could batch-import lots of keys and not have any per-key delay.  The flip side is I must -rescan when I'm done.

I also modified the code driving the -rescan flag on my bitcoind so I could say -rescan=180000 and it would only scan blocks 180000 and beyond.  I'd do this if I knew I was picking up recent payments that couldn't possibly be in earlier blocks.  Big timesaver.

Me too:


I don't need to -rescan at all if I'm importing addresses I just made in vanitygen, since I know there aren't yet any transactions mentioning the imported keys.

Strictly speaking, it doesn't need to be. It will get reduced modulo the generatororder anyway.

In this case, it doesn't matter at all. But for every value greater than the generatororder, there's an equivalent one less than the generatororder. You just don't want to waste time testing both.

Yes. You are correct all around.

Pardon the lameness, but...


Any suggestions as to how does one do it in practice? OpenSSL? Gpg? Something else?

Does this make it clearer? https://github.com/ciyam/ciyam/blob/master/src/crypto_keys.cpp#L538 and https://github.com/ciyam/ciyam/blob/master/src/crypto_keys.cpp#L54

Basically a random 256 bit number will work but it has to fit within the curve range (it is very unlikely that it won't but the sanity check is necessary).

I am using OpenSSL for the random number (as does Bitcoin as I sourced that part from Bitcoin itself) but you could of course use "hex dice" or some other method if you don't trust OpenSSL.