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

but it still pure luck - as you are not paid by shares or work contributed - first who found takes all prize?

If it not possible to generate it without public key being used. Otherwise you are compromising the security of the private key by knowing it. As far as I remember, you can use vanityminer and specify the public key in it even if you are generating offline. Best look at samr7's vanitygen thread for instructions.


A lot of the time Vanity Pool doesn't have very profitable work. However, new work comes in a few times a week that has better payout. If you automate your vanity miner to fetch work from the pool automatically you should be on that work quickly.

Given the usual vanities being requested - the current one being selected being 1AntjeDahm - yeah, probably not entirely unexpected.  My test machine would take a decade and then some, on average

Trying vanityminer on pool:
Is it normal to have 1.2y 50% prob on 50mkey/sec?

oh ok.
missed split-key somehow...
is there opportunity to use list of prefixes with list of Public Keys with oclvanityminer?

also is there opportunity to generate priv key without pubkey and than combine somehow?

Or it is only possible with oclvanitygen to generate 1 address at a time with split-key requirements?

thank you!

Addresses are case sensitive. Also keep in mind to use split-key vanity address generators in case you haven't been.

hi got the solution for

Pattern: 1BitSnitch
Address: 1BiTSniTCH....
Privkey: Kx19...........



when submitting - getting error:
Solution does not match the pattern

using bitcoin address utility by Casascius to convert key to hex.
Please advise.

It's a bit technical, but let's distill it down to the basics...

ECDSA keys are comprised of X and Y coordinate information.  A compressed key is simply a shorter representation of the public key by discarding the Y coordinate and instead adding a small bit of information about the coordinates that allows a bit of code to work out the Y coordinate based on the X coordinate.
This is desirable because it keeps the size of the blockchain down a fair bit at the expense of a teensy bit more computation for any piece of software that has to actually deal with these calculations.
However, because Bitcoin addresses are based on the public key representation - rather than the public key information - such a compressed key yields a different address than a non-compressed key.
( For those wondering - yes, that means that for every address out there, there's another matching address.  That's why private keys represented in a WIF format will have a bit of information for clients on whether the public key is uncompressed (WIF starts with a '5') or compressed (WIF starts with 'K' or 'L'), while for raw or incorrect imports you'll have to help the client along a bit by specifying it specifically. )

The additive and multiplicative bits are even more technical, you really would have to read up on the finer details, but suffice it to say that both yield the same results due to the way elliptic curve cryptography work with the exception that when using additive you can combine two public keys and get the desired address, while with multiplicative you can't.  This doesn't really affect the end-result other than having to choose which combination to use to actually get the correct address - i.e. if it is multiplicative and you choose additive instead, you still get a valid Bitcoin address.. just not the one with the vanity.

Can't help you with the other one other than that I believe the steps are exactly as you mention with the modification that the base point is added as that still yields valid results and is faster than re-generating a new key for each test.

The website has been updated to include a message from the admin:

Which is confusing me. I thought the system went like this:

• 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 address public key
• Use RipeMD160 and Base58 to check the address. Repeat.

I'm not really on top of ECDSA and this is really confusing. Any help is appreciated.

There are others, but Vanity Pool is the only particularly active one.
The others:
Vanity Address Market Place (VAMP) - in alpha, may be broken right now.  I contacted the proprietor, but didn't get a response.
Vanity Address Request (VAR) - should work, doesn't see many 'miners' though, and as a result not many requests.

You may want to set up some automated system to check for new work at Vanity Pool and see if it's profitable enough for you to mine, as most of the existing work is much too complex for the given rewards.

Is there any other vanity pools? (I couldn't find any other) Or this is only one? If there are multiple ones, which one would be most profitable? ie. with most rewards and easiest addresses.

------------

I think just one

I see. Thanks!

If it's not case sensitive, it should take less than a day.

Oh, so seven characters would take maybe about a few days with 4 r920s?

winter is six characters, so it's easy even you use your cpu power, you can get it in less than an hour.

It's been a while, but I think it was a vanitypool request because I didn't want to bother with figuring drivers out.

How long did it take for you to get your vanity address?

I don't know how fast r290s can get for vanity addresses, but should give you an estimate when you start up oclvanitygen.

right, so what about guys? Suppose I have 4 r920s, how long would I take?

Since you're quoting TH/s, I assume you're referring to an ASIC device. You can't use bitcoin mining devices to create vanity addresses. Bitcoin ASICs only do one specific thing, and that thing is bitcoin mining, not address calculations. You will need to use a CPU/GPU.