Topic: Vanity Pool - vanity address generator pool - page 27. (Read 148044 times)

Just saving https://www.bitaddress.org ("save page as") and opening that local file in browser seems to work fine for me.

don't worry, thanks for great service

Hmm, that's odd. I think I'll have to fix that after work. Sorry about the inconvenience.

heyja, cool pool!

I'm mining and I also inserted a job (for '1MoLeCuLaR'). I payed BTC 0.15 to address 193qKiLHKQK3LADCzNea9z26DZnd22rPRC as instructed, tx_id: 71c2b2da04087b03813b79e41f663c9a44f999d04b533aa9f98c0f34add7a2bf

page still says "Status: Work is awaiting payment" (19 confirmations).

what up?

Yes it was.

@fizzisist many thanks for the 1Private solution link

Thanks for the clarification samr7.

I edited the wiki accordingly.

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.

The solution is waiting for you here then:
https://vanitypool.appspot.com/checkSolved?key=1Private:04C13D9CF2B0E382A4AF29C5E2B97F85C6DD9445F7DCE82CD7207E6FC4716511981B0012C10B39E F152257A8407A2965F92F075379D311D5786D9421795B82D01C

Yep, that work has been solved, but it is still listed (I submitted this pattern, in fact). Something is definitely wrong.

An interesting clue in the add/mult question: that page lists it as an additive solution. Was that solved with oclvanityminer? Am I just totally misunderstanding the method? Could oclvanityminer be using the additive method but still not searching the entire set of available work? Does the method even limit the number of patterns it could be searching for at the same time? We need someone who understands the method more clearly to come explain this. Unfortunately, I probably need to dig into the math...

That's one of my bounties & hasn't been sent to me as solved as yet.

Transaction 9ac1cabecb652a8d74569a8ba2413e7b75b3083a1c9ac90c39dc6d83eb57cd45 just paid for the 1vanity bounty (seeing it accepted in the HTML on the miner's output right now). But 1vanity from 1CXUwsY6pcMAV3iqwovq4Vesh24bBeecTp is still listed as available for 0.0796 BTC on vanitypool and http://fizzisist.com/mining-value/api/vanitypool-value-mult seems to see it too as the expected value matches what my miners are reporting.

I'm not sure either, I don't understand the code. I see references to both EC_POINT_add, BN_mul, and EC_POINT_mul, and I can't quite figure which is used for what.

The method that is described in the first post of this thread is addition, at least. I just assumed that BurtW's post later in the thread was a suggestion on how to speed up the generation. Here he suggests multiplication of the private keys as a speedup.

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.

Ok, looking forward to it!

A side note: I think you should avoid the terms complexity and lavishness and instead stick with difficulty and value. These terms have already been established by vanitygen and users are accustomed to them at this point. I don't think it would be worth it to try to redefine them. Furthermore, in my opinion, difficulty and value are perfectly descriptive of the quantities they represent, and complexity and lavishness are less descriptive.

I do plan to lower it once the Pool has a proper bounty system proportional to the complexity and some traffic. For now I'm still operating at a loss.



I guess I might be wrong, but as far as I remember the oclvanityminer was using the multiplicative method. Guess I'll have to look into that.

I've added my 5770 to the wiki page.

Shouldn't all our key-speeds be in the "Additive" column though? As far as I've understood (public key point) addition is what's in use now, and (private key) multiplication hasn't been implemented (but should be faster):

I updated the calculator to take into account the 0.1 BTC minimum and the 20% fee. The Piachu, I'm surprised to see these so high. Any plans to lower them? I would also suggest saying something about the fee on the "request a vanity address" page.

The difficulty is calculated with the same algorithm oclvanityminer uses. I first used a simple command line tool I built that just calls the vg_prefix_get_difficulty() function from vanitygen. Then, BkkCoins released a nice python wrapper for the function, so I switched over to that.

I believe the discrepancy here has to do with the intricacies of bitcoin's funky base58 encoding. I haven't looked into it closely, but whatever the reason, the number of valid keys that must be searched in either case is different. I'm tempted to look into it, but I really should be working on other things.   

Ok, thank you. I didn't know that the pool kept 20% of the bounty. That certainly needs to be included in the bounty calculator. Any plans to lower the bounty? This would be especially good in light of the discussion about multiple patterns for a single public key.

Speaking of, I don't think this statement is correct:


The "value" of the work being done is still the sum of the values of all work being simultaneously searched for. The difficulty of the work is reduced when you add additional acceptable patterns. Imagine a dice game where the house will pay if you roll a specific number. Put in terms of the vanity address search, here is a possible "piece of work:"

Goal: roll a 5
Difficulty: 6
Reward: 1 BTC
Value: 1/6 = 0.1667 BTC/roll

Now, imagine they offer two rewards:

Goal A: roll a 5
Difficulty A: 6
Reward A: 0.8 BTC
Value A: 0.8/6 = 0.1333 BTC/roll

Goal B: roll a 2
Difficulty B: 6
Reward B: 0.2 BTC
Value B: 0.2/6 = 0.0333 BTC/roll

The total value of rolling the die at any time is equal to Value A + Value B = 0.1337 BTC/roll. You can calculate it another way, if you don't believe that:

Goal: roll a 2 or a 5
Difficulty: 3
Reward: 0.8/2 + 0.2/2 (50% chance you'll get either one of the rewards in 3 rolls) = 0.5 BTC
Value: 0.5/3 = 0.1667 BTC/roll

In fact, you could add a third goal with zero reward and it would still be worth your time to roll the die! In reality, though, adding that third goal adds slightly more difficulty to the problem, because you need to add that to the list of patterns to be checked, and submitting the solution isn't free. For this reason I would impose some minimum bounty for a new pattern, albeit much less than 0.1 BTC.

In summary, adding an additional pattern lowers the total difficulty of the work. The miner does not need to keep hashing to get the full reward: they found the reward earlier since the difficulty was lower.