Author

Topic: Vanity Address Web site - Would you use? (Read 1501 times)

hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
September 23, 2012, 02:15:00 AM
#18
My aVanityGen for Android is mobile and simple to use(at least I believe it to be). But it does have bugs I've identified but am reluctant to fix due to other projects taking priority.
I can't imagine finding addresses very quickly on a phone (if that's what you're doing). But I could see an Android front end using the API that would allow finding prefixs quickly being a good idea.
OpenSSL 1.0.1c does pretty good on the phone, I mean I have not timed it correctly but it does a few thousand per second, around 30? But my original algorithm to count the keys is broken so it instead shows some low number like less than 150 or so.
With that speed I could see some users wanting to use my site api. What takes one second on my site (well 5-15 seconds due to polling overhead) would take 8 minutes on the phone. For a prefix longer than 4 chars it would be even more attractive.

eg.
1Lover taking 25 seconds @10 MH/s, would take 140 minutes on the phone.

At the moment my backend code only runs 1 GPU / job but later I plan to have it use more GPUs at once on longer jobs.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
September 22, 2012, 08:20:57 PM
#17
My aVanityGen for Android is mobile and simple to use(at least I believe it to be). But it does have bugs I've identified but am reluctant to fix due to other projects taking priority.
I can't imagine finding addresses very quickly on a phone (if that's what you're doing). But I could see an Android front end using the API that would allow finding prefixs quickly being a good idea.
OpenSSL 1.0.1c does pretty good on the phone, I mean I have not timed it correctly but it does a few thousand per second, around 30? But my original algorithm to count the keys is broken so it instead shows some low number like less than 150 or so.
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
September 22, 2012, 08:04:06 PM
#16
My aVanityGen for Android is mobile and simple to use(at least I believe it to be). But it does have bugs I've identified but am reluctant to fix due to other projects taking priority.
I can't imagine finding addresses very quickly on a phone (if that's what you're doing). But I could see an Android front end using the API that would allow finding prefixs quickly being a good idea.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
September 22, 2012, 07:34:55 PM
#15
My aVanityGen for Android is mobile and simple to use(at least I believe it to be). But it does have bugs I've identified but am reluctant to fix due to other projects taking priority.
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
September 22, 2012, 12:41:56 AM
#14
Sounds very promising - I will be wanting 10,000 addresses where each address has a specific 5 character (after the 1) prefix. Do you have a rough estimate how much this would cost?
It actually depends on the specific chars. The site has a quote engine that prices it before submitting a request. I took the vanitygen probability estimator and wrapped it as a Python module for my web app.

Currently I've set a max qty of 1000 to limit long runs that could potentially get stuck or have some problem and not be detected.

As an example I ran "1Lover" thru the estimator and it spits out the following prices,

100 qty = 0.012 btc, 62 minutes
1000 qty = 0.124 btc, 618 minutes (yes, about 10 hours)
(ie. roughly 0.1 us cents each)

This isn't definitive yet as I may tweak the pricing. It's based on probability but once a price is quoted and job submitted the price holds even if it takes longer than expected, barring some calculation error. I base the rate on a multiplier to current mining rates.

Some letters take longer, eg. 1Queen @ 100 qty, estimates at 61 hours.

Also, long jobs may take a bit longer in real time. I'm working on job prioritizing code so long jobs may get paused to handle higher paying short jobs.
legendary
Activity: 1890
Merit: 1072
Ian Knowles - CIYAM Lead Developer
September 22, 2012, 12:23:15 AM
#13
I just checked the keyconv code again. It doesn't need boost. It's roughly a dozen lines of code that mostly use openssl fucntions,

EC_KEY_get0_private_key
EC_GROUP_get_order
BN_mod_add

and a few init/free type openssl calls.

So it should be straightforward. Once I've got further, assuming I actually go live with this, and have some time, I can write up a function and test it out. Curl should work fine for actually accessing the api. Would you be getting generating keys single or in batches? Batches is far more efficient unless the prefix is long (6-7+ chars).

Sounds very promising - I will be wanting 10,000 addresses where each address has a specific 5 character (after the 1) prefix. Do you have a rough estimate how much this would cost?
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
September 22, 2012, 12:15:42 AM
#12
But it would be fairly easy for me to create a C++ function you integrate at your end to add the keys. The code is readable in the vanitygen keyconv utility and was what I based my own JS client code on. At the C++ end it would require linking to the openssl library and only a few lines to add the keys. openssl provides the BigNum functions for addition. I'd have to look into.

Great - I am already using OpenSSL so that should be easy (am not using boost though so hopefully the code won't need it also).

I just checked the keyconv code again. It doesn't need boost. It's roughly a dozen lines of code that mostly use openssl fucntions,

EC_KEY_get0_private_key
EC_GROUP_get_order
BN_mod_add

and a few init/free type openssl calls.

So it should be straightforward. Once I've got further, assuming I actually go live with this, and have some time, I can write up a function and test it out. Curl should work fine for actually accessing the api. Would you be getting generating keys single or in batches? Batches is far more efficient unless the prefix is long (6-7+ chars).

What happens if I have a vanity address and your site goes down?
Once you have the vanity address (and key) my site wouldn't matter at all. They are normal addresses just as if you generated one yourself. Requesting addresses in a batch would make sense as you wouldn't depend on the site to create an address on demand. The api would allow you to request a batch and then call back later to retrieve the results. For short prefixes this can be quite fast. 100 x 4 chars ones in a minute or so is reasonable. A single short prefix address would take a 5-15 seconds due to overhead and polling time on the GPU backend.
newbie
Activity: 57
Merit: 0
September 22, 2012, 12:05:53 AM
#11
What happens if I have a vanity address and your site goes down?
legendary
Activity: 1890
Merit: 1072
Ian Knowles - CIYAM Lead Developer
September 21, 2012, 11:48:19 PM
#10
But it would be fairly easy for me to create a C++ function you integrate at your end to add the keys. The code is readable in the vanitygen keyconv utility and was what I based my own JS client code on. At the C++ end it would require linking to the openssl library and only a few lines to add the keys. openssl provides the BigNum functions for addition. I'd have to look into.

Great - I am already using OpenSSL so that should be easy (am not using boost though so hopefully the code won't need it also).
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
September 21, 2012, 11:35:34 PM
#9
I haven't added an end user api yet but the client JS does already access an Ajax JSON interface. It would require at your end a fairly small function to do the final key addition. I'd have to create a few samples in php, python etc.

Unlike most other web systems my back end is 100% C++ so I would be hoping for something simpler (such as just using "curl" to get back CSV).

Smiley

Due to how it combines keys at the client end a simple csv api call wouldn't work as that would mean I know your keys.

But it would be fairly easy for me to create a C++ function you integrate at your end to add the keys. The code is readable in the vanitygen keyconv utility and was what I based my own JS client code on. At the C++ end it would require linking to the openssl library and only a few lines to add the keys. openssl provides the BigNum functions for addition. I'd have to look into.

My api would provide the partial keys as a list (could be csv or json or whatever) but then those partial keys need a bit of openssl magic to make the final keys. You wouldn't need to create the private key as that can be done on bitaddress.org or even on my site since it has a backup button that copy the key for backup. I use BitcoinJS to do this in the browser.

edit: it also may be feasible that a subprocess call to openssl cmd line tool could work. I have not explored that yet at all.
legendary
Activity: 1890
Merit: 1072
Ian Knowles - CIYAM Lead Developer
September 21, 2012, 11:22:06 PM
#8
I haven't added an end user api yet but the client JS does already access an Ajax JSON interface. It would require at your end a fairly small function to do the final key addition. I'd have to create a few samples in php, python etc.

Unlike most other web systems my back end is 100% C++ so I would be hoping for something simpler (such as just using "curl" to get back CSV).

Smiley
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
September 21, 2012, 11:06:20 PM
#7
Do you have a link to an explanation about how the third-party partial key implementation of vanitygen is working?

Provided I am satisfied with the safety of the system I think I would be interested to use this (although an API approach might be preferable to a standard website).

I describe it briefly on my "How It Works" page but since that's currently the main page I didn't want to get technical. I could add a more detailed "Under the Hood" page to more fully explain how it functions. I'd have to read up more on Elliptic Curve math to be able to explain it adequately as I pretty much trust vanitygen that it is safe as stated.

The math is out there. Basically vanitygen uses your login public key to generate vanity keys and due to EC math those keys will function when combined with the unknown private key once back in the browser. This login private key is "added" to the partial key generated by vanitygen to create the final vanity private key.

I did test the partial key created by vanitygen on bitaddress.org to see if it is a valid key and was told it isn't valid. Only when it is added to the original private key does bitaddress.org then recognize it as a valid key.

I haven't added an end user api yet but the client JS does already access an Ajax JSON interface. It would require at your end a fairly small function to do the final key addition. I'd have to create a few samples in php, python etc.
legendary
Activity: 1890
Merit: 1072
Ian Knowles - CIYAM Lead Developer
September 21, 2012, 10:56:17 PM
#6
Do you have a link to an explanation about how the third-party partial key implementation of vanitygen is working?

Provided I am satisfied with the safety of the system I think I would be interested to use this (although an API approach might be preferable to a standard website).
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
September 21, 2012, 10:54:04 PM
#5
Why would I when I can get vanity with vanitygen?
Obviously if you have vanitygen you could do this yourself. My use case was for situations or users where running vanitygen wouldn't be easy. Users who just want to do a few clicks and get addresses or who are mobile and use their phone.

I was watching posts a while back here where people had many issues getting vanitygen up and going  or they don't want to deal with cmd line stuff. Having a no-brainer web interface may be  useful for many users. I totally agree that for people knowledgeable and comofrtable with the cmd line and installing special tools and having their own GPUs it makes little sense.

Someone who doesn't want to run vanitygen on their laptop for a long name requiring a 24 hour, 100% cpu, search may also be inclined to get it in a minute (with GPU) using a web service like this.

Anyway, this is what I'm trying to gauge here. I did most of the interesting work to set it up but since I'll have to pay for another dedicated IP for SSL (on EC2) I'm wondering if I should bother going live.

Even under best circumstances I wouldn't expect to make much with it but I'd prefer it cover the cost of adding an IP  Shocked
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
September 21, 2012, 10:45:58 PM
#4
That's not me and it doesn't (yet) support third-party partial keys which means they have knowledge of your private key. Mine already uses bitcoinjs to do in browser key building to make sure I never could know your private key.

It's also way more expensive than I planned. 4 char prefix @ 0.25 btc? and something like 3btc/hour for longer ones? Yikes.

I was planning on offering eg. 1Love, 100 qty 4 char for something like 0.005 btc.

Not that I expect to make much from this at all but I want to have a small fee to prevent abuse as my mining rig auto switches to handle pending requests. Anything over the current mining rate is a bonus.

Current mining rate is about 0.004 btc/hour. for one of my GPUs. 100 qty 4 char prefix takes about 60 seconds, so even at this rate I'm way ahead of mining.
vip
Activity: 1302
Merit: 1042
👻
September 21, 2012, 10:35:04 PM
#3
Why would I when I can get vanity with vanitygen?
legendary
Activity: 1022
Merit: 1000
hero member
Activity: 784
Merit: 1009
firstbits:1MinerQ
September 21, 2012, 09:16:46 PM
#1
I've developed 90% of a Vanity Address web site using the third-party partial-key support in VanityGen. Would you use it?

I have it working here for test purposes and I'm trying to make final determinations about how to go live or even if it's worth going live. Is there demand?

I've designed it to be as safe as possible for users wanting vanity addresses instantly without hassle for a trivially small fee. Typically you can get dozens or hundreds of matching addresses for a few milliBTC (ie. few US$ cents). Longer matches taking more time cost a bit more, based on processing time.

It works like this:
- you login with a user id and passphrase which is used to generate a "login key pair" in browser.
- your login creates a payment address you can use to maintain a small balance
- you enter in a match pattern and qty and are quoted a price instantly.
- you click to submit the request
 
In most cases your addresses are generated immediately (depends on how many requests are pending) and the results are available with a single click in several formats (html, csv, sql, json).

The public key from the login key pair is used as a unique token on the server and is the only identifying info stored. It is also what is used to generate the addresses. When you click the results item in your request log the addresses are received and combined in browser with your login private key and displayed in a list of vanity addresses/keys.

My server makes use of two backends - for normal prefix matches requests are passed off to a GPU mining rig for processing. For regex matches requests are based on a per hour fee and an Amazon EC2 instance is started to do the search. Both are transparent to end users. You just see the status go from waiting funds >> pending >> processing >> completed.

You can also save a backup of your login key (also as word list like Electrum) in case you forget your login details. This uniquely identifies each user.

Now why am I explaining all this? Well, I'm wondering if people would even use such a service.
If I've done my coding correctly it should be just as secure as blockchain.info or any other online wallet that handles keys. But maybe people would be afraid to use a key gen web site.

Feedback?

(btw I could offer an api for this such that other sites/services could request vanity addresses and use them in their offerings to users easily without doing their own backend coding / mgmt)

(also btw any small balance kept by users is 100% in offline addresses. Any refunds would be by request and processed manually in a batch. In most cases users would never have more than a few bitcents on balance anyway)

Jump to: