Topic: Vanity Pool - vanity address generator pool - page 22. (Read 147800 times)

I guess something is wrong with my bitcoind server, I will need to check its status when I will be home. Thanks for the info.

Thanks.  Now I'm getting:

when trying to request a new vanity address.

I guess I should add this to the FAQ:

https://gobittest.appspot.com/Address

So, I want to request a vanity address to be solved for me, but I don't know how to generate a private key/public key in the proper format for my side?  I tried looking at the FAQ, but it only tells me to go here: https://gobittest.appspot.com/Vanity which seems completely unrelated.

I did find this:  https://gobittest.appspot.com/PrivateKey which seems to generate private keys, but doesn't seem to generate the public key I would also need to submit to the vanity mining site?

Okay, the unsolvable work has been deleted from the system and the reward will be returned to the person that requested it. The system should clear out any traces of the work soon and everything will be normal again.

I still have to create some safeguard against submitting unsolvable work, as well as replace Lavishness with Value. For now I'm busy with other projects, so I'm not planning on doing those fixes this week.

Thank you all for bringing the unsolvable work issue to my attention and explaining why it is unsolvable.

Hmm, I guess I will have to look into fixing the pool for that. I would probably need to develop some more general algorithm though, instead of handling things just for Bitcoin and Namecoin.

Got it: so the allowable namecoin addresses start with:
N1, N2, N3, N4, N5, N6, N7, N8, N9, NA, NB, NC, ND, NE, NF, NG, NH, NJ, NK, Mv, Mw, Mx, My, Mz

Maybe VanityPool can have some logic in there to prevent someone from requesting an invalid address.

Maybe the person requesting NPhaux would be willing to get N1Phaux.
./vanitygen -N N1Phaux
Difficulty: 15318045009

Correct, namecoin addresses have a network byte of 52, just as bitcoin addresses have a network byte of 0, that was just a demonstration that it's not that vanitygen won't give that prefix, just that it isn't possible with that network byte.

Sorry for taking so long to get back about this.

I understand what you're going for, but I think you're adding unnecessary confusion. You are correct that bitcoin difficulty itself is a sort of arbitrary number since it has to be multiplied by 2^32 to be meaningful. This is because the difficulty convention was established long ago to express difficulty as a multiple of the minimum difficulty (which is 2^32 - 1). The true difficulty is currently 3438908.9601591383 * (2^32 - 1) (the average number of hashes needed to find one under the target). In my opinion, this is an unfortunate convention, but we can't do anything about it now.

Unfortunately, you just created another arbitrary number (lavishness) by introducing this factor of 2^32 unnecessarily. It's not too late to fix it, though, since this is all new! If we wait too long though, this convention will be established and we'll all be stuck with it. Vanitygen tells you the difficulty of a pattern as the average number of keys required to find a match. This is the true difficulty, since it tells you how much work needs to be done before you will complete the goal.

Based on that, value is always a meaningful number, since it is reward / difficulty. In the case of block mining, we need to multiply the "difficulty" by 2^32 to get the real difficulty, but for address mining we don't need to do anything special. The user can simply look at the number of keys generated per second by their hardware and know exactly how much they expect to earn. If you introduce "lavishness," they need to divide by 2^32.

To sum it up, here's what I would suggest for the terms:

Bitcoin mining:
Reward: 25 | units: BTC
"Difficulty": 3438908.9601591383 | units: hashes / (2^32 - 1)
Difficulty (actual): 14770001514365957 | units: hashes
Value: Reward / Difficulty | units: BTC / hash

Address mining:
Reward: bounty for pattern | units: BTC
Difficulty: Pattern difficulty as reported by vanitygen | units: keys
Value: Reward / Difficulty | units: BTC / key

It's unfortunate that the 2^32 is stuck in the bitcoin difficulty, but it would only make it worse to stick a new one in the value calculation for address mining, as you propose:

Vanitypool address mining (current definitions):
Bounty: bounty for pattern | units: BTC
Complexity: Pattern difficulty as reported by vanitygen | units: keys
Lavishness: 2^32 * Bounty / Complexity | units: BTC / key * 2^32

At the very least, I ask that you put that 2^32 in the same place as in bitcoin mining, so that they remain analogous to each other (although I would prefer skipping it entirely).

Apparently that isn't an actual, valid namecoin address:


I'm guessing you're only allowed to use 52 as a leading byte. ThePiachu should probably cancel that work and refund the bounty.

According to my work checker NPhaux is only a valid prefix with a network byte of 53, and it does seem to solve that way:


Looks like a bug in the input verification for the pool server.

This seems to be the case. I checked the Namecoin block explorer and couldn't find any addresses started with the combinations above, NP doesn't seem to be a valid start to a namecoin address.

ThePiachu, can you remove it from available work?

Update from the vanitygen posts:


Perhaps the NPhaux currently listed as available work on vanitypool website is not a valid namecoin address?

sorry ThePiachu - i quoted the wrong text so my comment made no sense! I'm submitting an issue to samr7, just wanted to tell sangaman that it is a bug in vanitygen, not in vanitypool.

Well, Vanitygen is a software created by samr7 - https://bitcointalksearch.org/topic/vanitygen-vanity-bitcoin-address-generatorminer-v022-25804 .

Something might be wrong in vanitygen, the following combinations don't work:
Na, Nb, Nc, Nd, Ne, Nf, Ng, Nh, Ni, Nj, Nk, Nm, Nn, No, Np, Nq, Nr, Ns, Nt, Nu, Nv, Nw, Nx, Ny, Nz, NL, NM, NN, NP, NQ, NR, NS, NT, NU, NV, NW, NX, NY, NZ

but the rest do - this is probably a bug in vanitygen, i'll report it

I'm working at 19 - 20 Mkey/sec

I will look into incorporating that metric in when I will switch over from simple http requests to JSON RPC. For now, I know that there are miners constantly checking for work, but I am not able to determine the speed.

Any contribution to the pool is meaningful. If you are mining at a profit to yourself and that profit is higher than mining for blocks, everyone is benefiting.

Is there any way to know how much effort is being exerted by the pooled vanity-address-miners (in Mkey/sec) in total? For example, is there any way to know if the current target (JohnGALT) will get solved sooner or later, or if my efforts are contributing in any meaningful way compared to the whole?

I would love to see a little bit of text on the mining pool page saying "

• miners connected for [y] Mkey/s", so I could know (out of curiosity) if I'm the only one working on the pool at the moment, or if there are hundreds of folks.

Cheers

Yes, it's a part of my Vanity Pool webapp. I consulted with samr7 on the subjct of how the initial character (after net byte) affects the final result (See here http://bitcoin.stackexchange.com/a/3858/323).

Hmm, I suppose lavishness if useful when determining the mining ratio. From my FAQ page:

MR = L * (d/r) * (k/m) = 2^32 * (b/c) * (d/r) * (k/m)

(b/c) is as you said, value of the address. If you want to compare that to how much you would earn by mining blocks, you would have to multiply that by 2^32 * (d/r) * (k/m), which can be quite complex. Value would be a really small number, 2^32 is a really large number, and the other two are somewhere in between. If, however, you would take Lavishness, it would give most parts of the equation values that can be understood by people.

I suppose I should start using the Value once GPU mining stops becoming a thing and nobody will be comparing the two.

As for the complexity and bounty instead of difficulty and reward - I mainly use it to distinguish between key mining and block mining. I use "bounty", because people are setting their bounties for solving their work. Complexity I use because it is a bit of a different thing. Difficulty is an arbitrary construct in itself - a ratio of the maximum Target (2^32) to the current Target. So when talking about creating blocks we should be using Target at all times, but we don't, as the values are really big. To get the number of hashes required to solve a block of given Difficulty (well, at 50% chance), you need to multiply it by 2^32. Alternatively, we could be using Difficulty and shares per second as the mining speed, but shares are also a construct brought about by the pools and are arbitrary (not all of them need to be ~~Difficulty 1). In Complexity, it's the actual number of keys you need to generate in order to have a 50% chance of solving the work.