Pages:
Author

Topic: Vanity Pool - vanity address generator pool - page 26. (Read 148120 times)

hero member
Activity: 759
Merit: 502
I just calculated expected daily profitability for my card (HD 5870):
27 MKey/s * 3600 * 24 = 2332 GKey/day
Total value for current work: 0.000018 BTC/Gkey

So 2332*0.000018 = 0.04199 BTC / day in average. Is it really less worth than bitcoin mining or I have any mistake in my calc?

Your calculation is correct, you can check

http://fizzisist.com/mining-value/

to get quick info if it is worth to turn vanity miner on
legendary
Activity: 1386
Merit: 1097
I just calculated expected daily profitability for my card (HD 5870):
27 MKey/s * 3600 * 24 = 2332 GKey/day
Total value for current work: 0.000018 BTC/Gkey

So 2332*0.000018 = 0.04199 BTC / day in average. Is it really less worth than bitcoin mining or I have any mistake in my calc?
sr. member
Activity: 444
Merit: 313
The fix is live and it appears to be working. It also addresses a part of the issue with the lower case characters being used for public key making it harder to submit work. Now new works' public keys will be converted to upper case, as it is the same case used by oclvanityminer.
legendary
Activity: 952
Merit: 1000
Then I realized that with ASICs and the reward drop around the corner, my GPUs will likely only be good for vanity mining soon enough.
+1
hero member
Activity: 742
Merit: 500
[...]
I'm hoping to be watching near the moment the work switches over to "available" because I'm testing out a new feature for oclvanityminer that allows you to set a minimum value to mine for, otherwise put oclvanityminer in a sleeping state. This could make it possible to automatically switch to mining vanity addresses whenever it is more valuable than bitcoin mining (right now it isn't)...

If anyone wants to try it out, feel free to try my fork: https://github.com/fizzisist/vanitygen
I'm on your fork. Works great.

Switching from vanity to bitcoin mining and back is a good idea. I'm actually already doing it with a custom Ruby script which is monitoring your API and the Bitcoin difficulty. It's not reusable (it builds upon my own existing setup with a central monitoring server which already knows how to reconfigure each of my rigs which all use cgminer).

I don't see exactly how oclvanityminer simply sleeping when rewards are not high enough will allow dynamic switching. There needs to be a trigger when oclvanityminer detects a switch from Bitcoin to Vanity or vice versa is adequate that handles all the work needed to properly switch. Here are the things my script does on all rigs when it detects a change from Bitcoin to Vanity is appropriate:
  • stop the GPU in cgminer and change the memory speed (vanity mining sweet spot is around 650MHz for my 5870 and 5970 GPUs) through its API and leave it running to manage the fan speeds
  • launch oclvanityminer
in the other case (Vanity -> Bitcoin) oclvanityminer is killed and cgminer restarted to reapply optimized settings for Bitcoin mining.
I've started writing a python script to do something very similar.  Then I realized that with ASICs and the reward drop around the corner, my GPUs will likely only be good for vanity mining soon enough.

I didn't think about changing memory values to improve speeds.  I'll try it out with my 5970s.
hero member
Activity: 896
Merit: 1000
[...]
I'm hoping to be watching near the moment the work switches over to "available" because I'm testing out a new feature for oclvanityminer that allows you to set a minimum value to mine for, otherwise put oclvanityminer in a sleeping state. This could make it possible to automatically switch to mining vanity addresses whenever it is more valuable than bitcoin mining (right now it isn't)...

If anyone wants to try it out, feel free to try my fork: https://github.com/fizzisist/vanitygen
I'm on your fork. Works great.

Switching from vanity to bitcoin mining and back is a good idea. I'm actually already doing it with a custom Ruby script which is monitoring your API and the Bitcoin difficulty. It's not reusable (it builds upon my own existing setup with a central monitoring server which already knows how to reconfigure each of my rigs which all use cgminer).

I don't see exactly how oclvanityminer simply sleeping when rewards are not high enough will allow dynamic switching. There needs to be a trigger when oclvanityminer detects a switch from Bitcoin to Vanity or vice versa is adequate that handles all the work needed to properly switch. Here are the things my script does on all rigs when it detects a change from Bitcoin to Vanity is appropriate:
  • stop the GPU in cgminer and change the memory speed (vanity mining sweet spot is around 650MHz for my 5870 and 5970 GPUs) through its API and leave it running to manage the fan speeds
  • launch oclvanityminer
in the other case (Vanity -> Bitcoin) oclvanityminer is killed and cgminer restarted to reapply optimized settings for Bitcoin mining.
sr. member
Activity: 444
Merit: 313
How many confirmations do you require before a new pattern is available? I submitted this one and the bounty payment has 8 confirmations, but the work is still "awaiting payment."

Hmm, I think I might've put in a strict inequality (<) in the work updating tool, while I should've used a non-strict inequality (<=). So for the time being paying exactly 0.1 can cause the work not to update.

I will change that today.

[...]I'm testing out a new feature for oclvanityminer that allows you to set a minimum value to mine for, otherwise put oclvanityminer in a sleeping state. This could make it possible to automatically switch to mining vanity addresses whenever it is more valuable than bitcoin mining (right now it isn't)...

This probably would be a welcome feature for a lot of miners.
hero member
Activity: 720
Merit: 528
Please tell us when it's fixed. I've disabled vanitypool in my configurations: in the current state I lose money on it (0.16BTC for ~6GH/s worth of rigs in 24h...).

The fix is live. I hope it will work as intended.

How many confirmations do you require before a new pattern is available? I submitted this one and the bounty payment has 8 confirmations, but the work is still "awaiting payment."

I'm hoping to be watching near the moment the work switches over to "available" because I'm testing out a new feature for oclvanityminer that allows you to set a minimum value to mine for, otherwise put oclvanityminer in a sleeping state. This could make it possible to automatically switch to mining vanity addresses whenever it is more valuable than bitcoin mining (right now it isn't)...

If anyone wants to try it out, feel free to try my fork: https://github.com/fizzisist/vanitygen

13 confirmations now... Looks like something went wrong with that fix.

Definitely something wrong, the work still isn't available.
hero member
Activity: 896
Merit: 1000
Sorry, I updated the url to just api/vanitypool-value after samr7's explanation yesterday. I forgot to set up a redirect for that one, and the old url just points to the old data (which is no longer being updated). Sorry about that!
Works with the new URL, thanks.
hero member
Activity: 720
Merit: 528
fizzizsst: I use your API (http://fizzisist.com/mining-value/api/vanitypool-value-mult) to trigger vanity mining but it seems it doesn't work anymore (returns the same value oclvanityminer used to give me yesterday).

Sorry, I updated the url to just api/vanitypool-value after samr7's explanation yesterday. I forgot to set up a redirect for that one, and the old url just points to the old data (which is no longer being updated). Sorry about that!
hero member
Activity: 896
Merit: 1000
fizzizsst: I use your API (http://fizzisist.com/mining-value/api/vanitypool-value-mult) to trigger vanity mining but it seems it doesn't work anymore (returns the same value oclvanityminer used to give me yesterday).
hero member
Activity: 720
Merit: 528
Please tell us when it's fixed. I've disabled vanitypool in my configurations: in the current state I lose money on it (0.16BTC for ~6GH/s worth of rigs in 24h...).

The fix is live. I hope it will work as intended.

How many confirmations do you require before a new pattern is available? I submitted this one and the bounty payment has 8 confirmations, but the work is still "awaiting payment."

I'm hoping to be watching near the moment the work switches over to "available" because I'm testing out a new feature for oclvanityminer that allows you to set a minimum value to mine for, otherwise put oclvanityminer in a sleeping state. This could make it possible to automatically switch to mining vanity addresses whenever it is more valuable than bitcoin mining (right now it isn't)...

If anyone wants to try it out, feel free to try my fork: https://github.com/fizzisist/vanitygen

13 confirmations now... Looks like something went wrong with that fix.
hero member
Activity: 720
Merit: 528
Please tell us when it's fixed. I've disabled vanitypool in my configurations: in the current state I lose money on it (0.16BTC for ~6GH/s worth of rigs in 24h...).

The fix is live. I hope it will work as intended.

How many confirmations do you require before a new pattern is available? I submitted this one and the bounty payment has 8 confirmations, but the work is still "awaiting payment."

I'm hoping to be watching near the moment the work switches over to "available" because I'm testing out a new feature for oclvanityminer that allows you to set a minimum value to mine for, otherwise put oclvanityminer in a sleeping state. This could make it possible to automatically switch to mining vanity addresses whenever it is more valuable than bitcoin mining (right now it isn't)...

If anyone wants to try it out, feel free to try my fork: https://github.com/fizzisist/vanitygen
sr. member
Activity: 444
Merit: 313
Please tell us when it's fixed. I've disabled vanitypool in my configurations: in the current state I lose money on it (0.16BTC for ~6GH/s worth of rigs in 24h...).

The fix is live. I hope it will work as intended.
hero member
Activity: 896
Merit: 1000
The searched pattern "1Rotsor" already solved (https://vanitypool.appspot.com/check?key=1Rotsor:049d749ebb0fb11d2adc00508708ab514c5070185ae374cb1aacc6b420e05974a93d05acc27c195 d6b28a191fa8e05a00bb2d45ce454666bef1a4721fc5c9ca5ad), but remains in the available works list with the highest lavishness, and oclvanityminer's always get this work from pool  Sad

Sorry about that. The system is running on the cloud, meaning that sometimes data synchronisation can be a bother. At the moment there were two instances running, one was displaying correctly, the second one didn't notice the update. I'm already testing a fix for that issue, it should be up on the main version of the Pool in a couple hours. For now, I just had to resort to kicking the system manually so it would behave Tongue.
Please tell us when it's fixed. I've disabled vanitypool in my configurations: in the current state I lose money on it (0.16BTC for ~6GH/s worth of rigs in 24h...).
sr. member
Activity: 444
Merit: 313
The searched pattern "1Rotsor" already solved (https://vanitypool.appspot.com/check?key=1Rotsor:049d749ebb0fb11d2adc00508708ab514c5070185ae374cb1aacc6b420e05974a93d05acc27c195 d6b28a191fa8e05a00bb2d45ce454666bef1a4721fc5c9ca5ad), but remains in the available works list with the highest lavishness, and oclvanityminer's always get this work from pool  Sad

Sorry about that. The system is running on the cloud, meaning that sometimes data synchronisation can be a bother. At the moment there were two instances running, one was displaying correctly, the second one didn't notice the update. I'm already testing a fix for that issue, it should be up on the main version of the Pool in a couple hours. For now, I just had to resort to kicking the system manually so it would behave Tongue.
newbie
Activity: 16
Merit: 0
The searched pattern "1Rotsor" already solved (https://vanitypool.appspot.com/check?key=1Rotsor:049d749ebb0fb11d2adc00508708ab514c5070185ae374cb1aacc6b420e05974a93d05acc27c195 d6b28a191fa8e05a00bb2d45ce454666bef1a4721fc5c9ca5ad), but remains in the available works list with the highest lavishness, and oclvanityminer's always get this work from pool  Sad


legendary
Activity: 980
Merit: 1008
I'm 100% sure oclvanityminer is searching for patterns belonging to only a single public key at once, and this implies the multiplicative method (if I understand correctly). Still, I don't know if it is actually using that method.

There have been a lot of questions lately about additive vs. multiplicative, and how they work in oclvanitygen/oclvanityminer.  I'll try to answer them.

Oclvanityminer uses the additive method:

  • Generate a random partial private key
  • Calculate the associated partial public key
  • Add the base public key to the partial public key to get the test public key
  • Generate a large batch (~1M) of sequential addresses by successively adding the generator point to the test public key, and converting the points to addresses
  • If a match is found, report the partial private key plus the number of times the test public key was incremented.  Otherwise, repeat the previous step

Sequential public keys in this scheme are generated by successively adding the generator point to the test public key.  In the multiplicative method, we would skip adding the base public key to the test key at the start, and use the base public key as the increment instead of the generator point.

If anyone really wants to use the multiplicative method instead, it's possible to modify oclvanityminer to do this by changing maybe 5-10 lines of code.  The performance difference would be negligible.
As far as I can gather, your method is much faster than the method proposed by BurtW. You only do EC point addition (and hashing) in the CL kernel, right? BurtW's proposal looks like it includes public key generation in the kernel/loop, which would involve point multiplication (this is slow).

Could you elaborate on what you mean by "successively adding the generator point to the test public key" (step 4)? If "test public key" refers to the key generated in step 3, then repeatedly adding this key to the generator point of the curve would just yield the same point (and address). I assume "test public key" refers to one of the keys in the large batch of sequential public addresses (points)?

How do you create the sequential addresses? So you just use the secp256k1 curve equation to isolate y, and then add 1, 2, 3, 4, etc. to the "test public key"'s x coordinate, and calculate y from this equation (using the secp256k1 parameters)?



And increment x once for each time you want a new sequential point?

Quote
You are correct that oclvanityminer will search for addresses belonging to a single public key at a time.  I'm not sure how additive vs. multiplicative makes a difference in the ability to concurrently search for patterns using different base public keys.  For that matter, I'm not quite sure how to efficiently search for multiple patterns with different base public keys in the first place.
It doesn't make a difference. To the best of this forums knowledge - as far as I can see - this requires non-trivial changes to the protocol, one being that the clients who want a vanity address calculated in the same batch as other client's addresses would need to submit their private key to the vanity miner upon request.

hero member
Activity: 720
Merit: 528
I'm 100% sure oclvanityminer is searching for patterns belonging to only a single public key at once, and this implies the multiplicative method (if I understand correctly). Still, I don't know if it is actually using that method.

There have been a lot of questions lately about additive vs. multiplicative, and how they work in oclvanitygen/oclvanityminer.  I'll try to answer them.

Oclvanityminer uses the additive method:

  • Generate a random partial private key
  • Calculate the associated partial public key
  • Add the base public key to the partial public key to get the test public key
  • Generate a large batch (~1M) of sequential addresses by successively adding the generator point to the test public key, and converting the points to addresses
  • If a match is found, report the partial private key plus the number of times the test public key was incremented.  Otherwise, repeat the previous step

Sequential public keys in this scheme are generated by successively adding the generator point to the test public key.  In the multiplicative method, we would skip adding the base public key to the test key at the start, and use the base public key as the increment instead of the generator point.

If anyone really wants to use the multiplicative method instead, it's possible to modify oclvanityminer to do this by changing maybe 5-10 lines of code.  The performance difference would be negligible.

You are correct that oclvanityminer will search for addresses belonging to a single public key at a time.  I'm not sure how additive vs. multiplicative makes a difference in the ability to concurrently search for patterns using different base public keys.  For that matter, I'm not quite sure how to efficiently search for multiple patterns with different base public keys in the first place.

Thank you for the explanation! I updated the wording on my site so hopefully it is all correct now.
Pages:
Jump to: