I and others have spent a lot of time trying to come up with a way to do vanity address mining in such a way that you can look for all the outstanding vanity addresse requests (all requests from all customers) with a single loop. There are ways to do this but they all have issues. Here is one thread to read:
https://bitcointalksearch.org/topic/outsourcing-vanity-address-generation-56839
Especially this summary posting:
https://bitcointalksearch.org/topic/m.679537
Note that generating vanity addresses that start with 3 like "3vanity" will be much easier and faster than generating vanity addresses that start with 1 (like "1vanity").
I will get you a couple more threads when I get a chance.
Topic: Vanity Pool - vanity address generator pool - page 35. (Read 148044 times)
Hmm, interesting, I'll have to look into that further. I guess the addition version might allow one to look for more addresses at the same time, but it probably won't be enough to compensate for the added complexity.
Adding the functionality to the site will probably be easy, I'll look into it once I have a bit of free time on my hands.
Thank you for the information!
Adding the functionality to the site will probably be easy, I'll look into it once I have a bit of free time on my hands.
Thank you for the information!
There are two ways to do this but one takes less steps inside the time critical loop so would take less time to compute each trial:
Public key addition (described above) steps
1) Generate new key pair
2) Add the generated public key to the provided public key
3) Hash and test
4) If not the vanity address match go to step 1)
Private key multiplication (described elsewhere) steps
0) Set the starting point of all key generation to the provided public key (instead of the normal point G)
1) Generate new key pair
2) Hash and test
3) If not the vanity address match go to step 1)
See how method 1) requires a larger modification to the vanity generation loop and adds a large computational step, point (public key) addition defined over the eliptical curve, into the time critical loop?
I believe that method 2) would run much faster.
After the vanity address is found the only difference between the two methods is that in method 1) the final private key is the modulo sum of the two private keys where as in method 2) is is the modulo product of the two private keys.
Public key addition (described above) steps
1) Generate new key pair
2) Add the generated public key to the provided public key
3) Hash and test
4) If not the vanity address match go to step 1)
Private key multiplication (described elsewhere) steps
0) Set the starting point of all key generation to the provided public key (instead of the normal point G)
1) Generate new key pair
2) Hash and test
3) If not the vanity address match go to step 1)
See how method 1) requires a larger modification to the vanity generation loop and adds a large computational step, point (public key) addition defined over the eliptical curve, into the time critical loop?
I believe that method 2) would run much faster.
After the vanity address is found the only difference between the two methods is that in method 1) the final private key is the modulo sum of the two private keys where as in method 2) is is the modulo product of the two private keys.
It is somewhat close to that algorithm, but not exact.
I'm glad you find the idea interesting. If you want to write a library to perform offline key mearging, or split-vanity-key mining, I'll put up a link to it on the website and the orIginal post. I'll have to look into writing some C++ code for that at some point...
I'm glad you find the idea interesting. If you want to write a library to perform offline key mearging, or split-vanity-key mining, I'll put up a link to it on the website and the orIginal post. I'll have to look into writing some C++ code for that at some point...
Sorry I haven't read the whole thread but that is basically Diffie-Hellman, right?
Anyway it sounds to me like a pretty good idea and a possibility for an additionnal business for miners.
An offline tool will be easy to write. My Perl bitcoin library almost aready does the job.
Anyway it sounds to me like a pretty good idea and a possibility for an additionnal business for miners.
An offline tool will be easy to write. My Perl bitcoin library almost aready does the job.
I generated a 1freenode address (9 characters because the 1 counts as well) and it toook a day or 2 on a single 5870. The time estimate from oclvanitygen was significantly higher than that, so I may have gotten lucky. During that run I actually found 2 matching keys, and one of them happened to be all lowercase too.
we all live in a yellow submarine, a yellow submarine...
I imagine a vanity address of 'polymorphic..." would be difficult [time consuming] in the extreme to generate.
I imagine a vanity address of 'polymorphic..." would be difficult [time consuming] in the extreme to generate.
My estimation is, that the cost would be in the order of 1-2 million Bitcoins. When you go over 8 characters, the keys get quite expensive really fast. But then again, I don't really have much data on the cross performance of many graphic cards doing vanity generation.
we all live in a yellow submarine, a yellow submarine...
I imagine a vanity address of 'polymorphic..." would be difficult [time consuming] in the extreme to generate.
I imagine a vanity address of 'polymorphic..." would be difficult [time consuming] in the extreme to generate.
I've created a simple split vanity miner software in Google Go (if you're wondering why I used this weird language - I've been developing Bitcoin-related apps in it for a year for my master thesis). The source code and a Mac executable is available here:
https://github.com/ThePiachu/Split-Vanity-Miner-Golang
It is quite slow, checking a couple hundred addresses on my old Macbook Pro, but it can solve some reasonably short patterns. The software is streamlined for the vanity pool, you only need to change the given testnet Bitcoin address to yours and it will do most of the work. It fetches work only during the start, so keep that in mind if you want to run it for longer.
https://github.com/ThePiachu/Split-Vanity-Miner-Golang
It is quite slow, checking a couple hundred addresses on my old Macbook Pro, but it can solve some reasonably short patterns. The software is streamlined for the vanity pool, you only need to change the given testnet Bitcoin address to yours and it will do most of the work. It fetches work only during the start, so keep that in mind if you want to run it for longer.
Code:
Work accepted!
Your work has been prepared!
Please send a reward you want to pay for it to this address: mh4ymyUejEA7VNuA9VKEqw3wsVquoN7BPx
Is that address correct? Starting by m?
It's a testnet address:
https://en.bitcoin.it/wiki/Testnet
Means you can play with fake-Bitcoins, just in case something goes wrong with the system.
You can get some testnet bitcoins here:
http://testnet.freebitcoins.appspot.com/
They are free.
Code:
Work accepted!
Your work has been prepared!
Please send a reward you want to pay for it to this address: mh4ymyUejEA7VNuA9VKEqw3wsVquoN7BPx
Is that address correct? Starting by m?
Is there some way to charge based on how long the key took to find? Like what if you set the price equal to whatever you would made mining BTC?
For now the service doesn't charge based on key length. It can be implemented if there is a need for it. I'd have to benchmark some split-vanity-mining software on some various hardware first in order to determine how much should one be charging. I've done it for normal vanity mining (details will be available in my master thesis that I'll probably post on the forum eventually).
Personally, I'd have to first check whether looking for multiple keys at the same time will slow the process down considerably, or will it not be too noticeable.
Generally I'd like to leave a lot of freedom to the miners to discriminate themselves which tasks pay enough for them to undertake them (this is why the bounty is listed along with the task).
Something I have thought about doing for a long time. Subscribe.
I still think an address namespace in namecoin (or something similar) is a better long term solution than vanity addresses, but they are fun for now.
Is there some way to charge based on how long the key took to find? Like what if you set the price equal to whatever you would made mining BTC?
Something I have thought about doing for a long time. Subscribe.
and say we want to find a pattern "166". One of the solutions takes a form of a private key
B18427B169E86DE681A1A62588E1D02AE4A7E83C1B413849989A76282A7B562F
mapping to public key:
049C95E0949E397FACCECF0FE8EAD247E6FD082717E4A4A876049FB34A9ADED110DFEA2EF691CC4 A1410498F4C312F3A94318CD5B6F0E8E92051064876751C8404
B18427B169E86DE681A1A62588E1D02AE4A7E83C1B413849989A76282A7B562F
mapping to public key:
049C95E0949E397FACCECF0FE8EAD247E6FD082717E4A4A876049FB34A9ADED110DFEA2EF691CC4 A1410498F4C312F3A94318CD5B6F0E8E92051064876751C8404
Sorry for my terrible math, but how is that private key a solution to the pattern "166"? That private key makes the address 12gFLYWpfnDTQ3JB5w5VDPpF5JQZnA1g1c it doesn't have 166 in it. The math doesn't lie and if you add the two private keys together you do get an address with "166" in it, but where did this one come from? How would one do this with vanitygen?
Check out this page:
http://gobittest.appspot.com/Vanity
When you add
18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725
and
B18427B169E86DE681A1A62588E1D02AE4A7E83C1B413849989A76282A7B562F
their sum becomes
CA65722CD418ED28EC369E36CFE3B7F3CC1CD035BFBF6469CE759FCA30AD6D54
which maps to 166ev9JXn2rFqiPSQAwM7qJYpNL1JrNf3h
Currently you can't do these operations with vanitygen, but I'll look into making a tool for the generation soon.
Basically, one would need to make a modified vanitygen that would add a predefined public key to a generated keypair before proceeding with calculating the Bitcoin address. It's a fairly simple modification, but I'm not fluent enough in vanitygen's source code to make it.
and say we want to find a pattern "166". One of the solutions takes a form of a private key
B18427B169E86DE681A1A62588E1D02AE4A7E83C1B413849989A76282A7B562F
mapping to public key:
049C95E0949E397FACCECF0FE8EAD247E6FD082717E4A4A876049FB34A9ADED110DFEA2EF691CC4 A1410498F4C312F3A94318CD5B6F0E8E92051064876751C8404
B18427B169E86DE681A1A62588E1D02AE4A7E83C1B413849989A76282A7B562F
mapping to public key:
049C95E0949E397FACCECF0FE8EAD247E6FD082717E4A4A876049FB34A9ADED110DFEA2EF691CC4 A1410498F4C312F3A94318CD5B6F0E8E92051064876751C8404
Sorry for my terrible math, but how is that private key a solution to the pattern "166"? That private key makes the address 12gFLYWpfnDTQ3JB5w5VDPpF5JQZnA1g1c it doesn't have 166 in it. The math doesn't lie and if you add the two private keys together you do get an address with "166" in it, but where did this one come from? How would one do this with vanitygen?
Cool! I added a link to this in the OP of my thread.
This is cool, now all we need is oclvanitygen to support this so that we can use all the video cards that will soon be obsolete now that ASICs are coming along. 
Well, this might be viable if suddenly a lot of people would want really fancy addresses and they were willing to pay up for them. It probably won't happen, but it might encourage a few people to go for a vanity address that normally wouldn't.
This is cool, now all we need is oclvanitygen to support this so that we can use all the video cards that will soon be obsolete now that ASICs are coming along.
One way or another this will end up as a FLOSS platform so there's not much monetization potential.
There's more to it than software. The key to success for a business venture like this will be the backend hardware that allows for mass production and fulfilment.Jump to: