Vanity Pool - vanity address generator pool

[ThePiachu]

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

Well, Vanitygen is a software created by samr7 - https://bitcointalk.org/index.php?topic=25804 .

[1713504782]

1713504782

[1713504782]

1713504782

[1713504782]

1713504782

[1713504782]

1713504782

[maqifrnswa]

Well, Vanitygen is a software created by samr7 - https://bitcointalk.org/index.php?topic=25804 .

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.

[maqifrnswa]

Update from the vanitygen posts:

Something might be wrong in vanitygen, the following (namecoin) 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

Is there any update on this bug? Vanitygen won't generate addresses that start with the combinations listed above.

I don't know that it's a bug, more likely that there are no possible values of raw binary Namecoin addresses that will convert into a Base58 address that starts with these characters. The underlying data of a Namecoin address must start with a network ID of 00110100 (binary) + hash. This means that the range of inputs to the Base58 converter can only go from 0011010000000000... to 0011010011111111...

You can search or explore the namecoin block explorer and likely see that there are no examples of these "nonworking" addresses, a less lazy person than me could actually do the math and describe the possible Base58 address ranges.

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

[sangaman]

Update from the vanitygen posts:

Something might be wrong in vanitygen, the following (namecoin) 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

Is there any update on this bug? Vanitygen won't generate addresses that start with the combinations listed above.

I don't know that it's a bug, more likely that there are no possible values of raw binary Namecoin addresses that will convert into a Base58 address that starts with these characters. The underlying data of a Namecoin address must start with a network ID of 00110100 (binary) + hash. This means that the range of inputs to the Base58 converter can only go from 0011010000000000... to 0011010011111111...

You can search or explore the namecoin block explorer and likely see that there are no examples of these "nonworking" addresses, a less lazy person than me could actually do the math and describe the possible Base58 address ranges.

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

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?

[mskwik]

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

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?

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:

Code:

mskwik@mskwik ~/script/bitcoin/vanitygen $ ./oclvanitygen -X 53 -p 0 -P 0435518A6E54753DF8397AD915EBB5449026EE170481C65FB515D8D2015DC80EC9EF401771BAE9F6278A474C03F23978BCB0A54E5211612029115277C5B5549781 NPhaux
Pattern: NPhaux
Address: NPhauxDmxGJfKSAJmAnZBLH9mhrKY5BALv
Privkey: 75y4T2rk3nbUipwcMzmeUcwwEzy3fhgdhvWVf6DhRM6CR9jWnSp

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

[fizzisist]

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

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?

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:

Code:

mskwik@mskwik ~/script/bitcoin/vanitygen $ ./oclvanitygen -X 53 -p 0 -P 0435518A6E54753DF8397AD915EBB5449026EE170481C65FB515D8D2015DC80EC9EF401771BAE9F6278A474C03F23978BCB0A54E5211612029115277C5B5549781 NPhaux
Pattern: NPhaux
Address: NPhauxDmxGJfKSAJmAnZBLH9mhrKY5BALv
Privkey: 75y4T2rk3nbUipwcMzmeUcwwEzy3fhgdhvWVf6DhRM6CR9jWnSp

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

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

Code:

$ namecoind validateaddress NPhauxDmxGJfKSAJmAnZBLH9mhrKY5BALv
{
    "isvalid" : false
}

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

[fizzisist]

On another note, why oh why do you multiply the value by 2^32 to get "lavishness?" As I tried to plead before, the terms "difficulty" and "value" are perfectly applicable here, and are an established convention in vanitygen. Furthermore, value, as defined in vanitygen, is a meaningful quantity: reward / key. A user can take this number and multiply it by their key/s rate and figure out their expected reward. Multiplying by 2^32 just makes it that much harder for the user. Creating some new, arbitrary units when there are perfectly good ones already is almost a sin in the scientific community. Of course, if you can justify the creation of some new units, fine, but I don't see the justification for these ones.

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.

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).

[mskwik]

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

Code:

$ namecoind validateaddress NPhauxDmxGJfKSAJmAnZBLH9mhrKY5BALv
{
    "isvalid" : false
}

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

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.

[maqifrnswa]

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.

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

[ThePiachu]

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.

[ThePiachu]

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.

[SgtSpike]

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?

[ThePiachu]

I guess I should add this to the FAQ:

https://gobittest.appspot.com/Address

[SgtSpike]

I guess I should add this to the FAQ:

https://gobittest.appspot.com/Address

Thanks.  Now I'm getting:

An error has occurred...

Error communicating with Bitcoin, please try again later

when trying to request a new vanity address.

[ThePiachu]

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.

[fizzisist]

... as well as replace Lavishness with Value.

Wait, my crazy ramblings about units convinced you? Awesome! I hope other people agree with me, too. I did spend a lot of time thinking about that when I set up the stuff on fizzisist.com. Might not be the best way of looking at it, of course. But, we should at least be having the debate now before the number of people interested in this stuff goes up by a factor of 10 or 100, when the difficulty spikes after ASICs appear.

I'm completely open to criticism about my proposed conventions, if anyone has other ideas.

[ThePiachu]

Hmm, my Amazon EC2 micro instance appears to be blasting at a 100% load. Gave it a restart, updated Bitcoin, and hopefully that will help. So far I don't see much of an improvement. I suppose it's that time of year when everyone needs their server time and so forth. I will try looking into what I can do about the situation over the next couple weeks and so forth. I hope either the 0.8 version will decrease the CPU load, I will be able to host my wallet someplace else, or the Amazon load will go back to normal.

[ThePiachu]

Okay, the server appears to be back to the usual load for now.

[Ente]

I try to connect via samr7's oclvanityminer on windows. I use
https://github.com/downloads/samr7/vanitygen/vanitygen-0.22-win.zip for this.

I get this verbose error:

* About to connect() to vanitypool.appspot.com port 443 (#0)
*   Trying 74.125.132.141...
* connected
* Connected to vanitypool.appspot.com (74.125.132.141) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: cacert.pem
  CApath: none
* SSL certificate problem: certificate has expired
* Closing connection #0
* Peer certificate cannot be authenticated with given CA certificates
Get work request failed: Peer certificate cannot be authenticated with given CA certificates

Any help?

Seems like I am the only one trying to run on (my friend's) windows. Could any of you upload his [linux] cacert.pem for me?

Thank you!

Ente

[ThePiachu]

Hmm, that is strange, does this mean my certificate would expire? This would be kind of hard, since my website is hosted through Google and their certificate.

I'm afraid I can't really help you there, I don't know much about the problem you are experiencing.