With regards to combining keys there is nothing more to it then can be found on the website.
The Vanitygen c-code itself just makes use of library functions to work with the generated keys.
The calls are all based on EC (Eliptic Curve) mathematics, where bitcoin just uses the specs according to SECP256k1.
https:<slashslash>en.wikipedia.org/wiki/Elliptic_curve.

Transforming a public key to a bitcoin address can be found here:
https:<slashslash>en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses.

But I guess I probably do not understand your questions.
Are you looking for more information on how Vanitygen 'searches' for the BitcoinPrefix?

You can find the basics of the agorithm here:
http:<slashslash>gobittest.appspot.com/VanityAll

On this site your can combine both private and public key to generate new results.
It show you raw private/public keys as well as the generated bitcoin addresses.
It supports both addition and multiplication of the private keys.
Vanitygen only uses the additions methode because public keys can only be added.

The SSL library was updated, changing the way the BigNumber stuff works.
you could check this commit in my repo to see the changes I made to get it to work again.
https://github.com/kangaderoo/vanitygen/commit/312c32d13dde534f0968397f4dd5fd42ef4898fc

Over the years I've seen requests for P2SH multisignature vanity addresses.
The basic support of Vanitygen was a 1 signature out of 1 key P2SH address.
I thought it was time to add more multisignature support :-)

The code for the following proof can be found in my https://github.com/kangaderoo/vanitygen repository.

Generating two public keys for a 2 signature out of 3 keys P2SH redeem script:

Searching for the 2/3 P2SH address starting with 3P14159 (or ℼ):

./vanitygen.exe -M 2 -X 5 -j [\"02a3fdb80c5da1ceb4da75e56c900da9baf2dfde0a2d2efbf81387e5ab2e91e985\",\"03d2c632fa06281b97eba0475de8e6e4597bc19b1ce0edfb36ad889141137f7dc3\"] -v -i -F compressed 3P14159

-M <M>                          --> script address needing M signatures
-X <scriptaddresstype>       --> 5 is for bitcoin adresses starting with 3, other values could be used for alt-coins
-j [\"pubkey1\",\"pubkey2\",....,\"pubkey(N-1)\"]
                  --> list of keys, one key will be added by the vanitygen search to complete N keys
-v                  --> verbose
-i                  --> ignore case
-F                  --> public key type

Response:

Verify the generated Private Key using the keyconv utility:

./keyconv -M 2 -X 5 -C -j  [\"02a3fdb80c5da1ceb4da75e56c900da9baf2dfde0a2d2efbf81387e5ab2e91e985\",\"03d2c632fa06281b97eba0475de8e6e4597bc19b1ce0edfb36ad889141137f7dc3\",\"0279600e5939f4f7baace27acefcc6191f260d23d30da8c779bc557c50eaf01751\"]
or:
./keyconv -M 2 -X 5 -C -j  [\"02a3fdb80c5da1ceb4da75e56c900da9baf2dfde0a2d2efbf81387e5ab2e91e985\",\"03d2c632fa06281b97eba0475de8e6e4597bc19b1ce0edfb36ad889141137f7dc3\"] <PrivKey>

Response:

Verification in Bitcoin-qt:
Response:

As I'm a puzzle solver, not a software professional, my github repository has a fixed setup to my personal environment and does
not automatically configure to other development environments. My personal environment also does not support OpenCL, so this
part of the code is not updated.

Vanitygen is a address search application, it runs the calculations in address-batches to optimize the heavy EC_POINT calculations.
The search functionality will disregard remaining calculations in the batch when it finds a match.
If only a "1" is specified in the search, each calculation yields a valid result, so the first in the batch is a match, the rest is
disregarded. If you want to use vanitygen as an address generator, you need to change the code to search in smaller batches.

I don't know the specifics of oclvanitygen, but most software that runs on a GPU runs even larger (parallel) batches.
If the same match and throw away routine is used, oclvanitygen will be less productive then vanitygen on small searches.

I guess 'standard' vanitygen runs on your system.
I only have the CPU version, this one uses the SSL libaries to perform the ec-point calculations.

The way I made the change has a bug when starting from offset 0.
At each iteration an increment ec-point is added, this increment point is equal to the number hashes in one iteration.
If offset=0 the last entry in the field has a value equal to the increment value during the first iteration,
resulting in a EC-point-add with two equal numbers on the second iteration.
EC-point-add with two equal numbers results in a div#0 error, I'm not sure if the ocl code handles a div#0 like the SSL lib does.

run a tests using an offset.
example an offset of 0x1000 would be:
oclvanitygen.exe 1Test -P 04175E159F728B865A72F99CC6C6FC846DE0B93833FD2222ED73FCE5B551E5B739D3506E0D9E3C7 9EBA4EF97A51FF71F5EACB5955ADD24345C6EFA6FFEE9FED695

Assuming this offset is bigger than the increment value, you avoid the div#0.

my change in the cpu version:
and the second change I made, just to prevent a EC_point add where EC_Point double is needed

and this is the result

:~/workspace/32BTC-Challenge$ ./vanitygen 1CUNE  -F compressed -v -t 1
Pattern: 1CUNE                                                                 
Pubkey (hex): 04f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9388f7b0f632de 8140fe337e62a37f3566500a99934c2231b6cb9fd7584b8e672
Privkey (hex): 03
Address: 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
Privkey: KwDidCf1aesp7ibPmj64maKRXJoHJnKKtTvvuwAjME7BcDHW33X2

And using the -P <public_key> for the offset with the pubkey =  2*the generator pattern:

:~/workspace/32BTC-Challenge$ ./vanitygen 1CUNE  -F compressed -P 04C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE51AE168FEA63DC 339A3C58419466CEAEEF7F632653266D0E1236431A950CFE52A -v -t 1
Pattern: 1CUNE                                                                 
Pubkey (hex): 0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c 4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
Privkey (hex): 01
Address: 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
PrivkeyPart: KwDidCf1aesp7ibPmj64maKRXJoHJnKKtTvvuwAjME7Bb2yevh1x

I guess the same change should work in oclvanitygen.
The next point(s) generation code was already sequential and based on the generator point.

The only thing you need is the pub key of 2^51 or any other point you want to start (example: 2^51 + 2^33) for your start point of the search.

I had a look at the vanitygen code the last couple of day's to see how to make the sequential search.
I just needed a minor change to have the CPU code to run from EC_key=0x01.
Using the online generator at gobittest(dot)appspot(dot)com/VanityAll a key can be made to generate an offset or start code. (for the -P split-key function)
There are still two issue that need to be solved
1) when starting from 1, there are parts of the code that perform an EC_POINT_ADD on two equal value's, here a EC_POINT_DOUBLE is needed.
2) when running multiple threads the old code uses a random key generation to make sure the threads used unique values, currently all my threads run the same data.

1) Is no issue when an offset key is used
2) I just execute the code in single thread, and run the executable #cpu times with another offset start code.

Since I don't have a GPU system I don't know if the change in that code there is just as hard/easy.

I was kind of curious what code changes you made to get it to run.

Ok, that seems to be a lacking from the p2pool software.
I guess the password field could be used for the merged mining address, its just distribution that needs to be coded.
But what about merging the myriad p2pool networks?

Hi,

It seems there are more yescrypt P2Pool networks running on different ports.
I thought the strength was to join the networks.
Info on the other network is here: http://p2pool.unitus.online/home

I also do not understand why you have myriad(yescrypt) and unitus (yescrypt) running independent.
Unitus can be merged mined with myriad, increasing your Unitus hashrate.

Vanitygen uses the standard openssl libraries, the key's generated are secp256k1.
One of the secp257k1 constants it the mentioned key range, so yes it is using this range.

The percentage is not based on a linear algorithm.

The key's that you are processing are generated based on randomness.
So the progress indicator is following some statistical algorithms that involve normal distribution, 'bell-curves', probability etc.

In short; this indicator shows the chance that you would have found a hit by now.

Ignoring that it is no use to find a complete bitcoin adress. :-)

You can not put the whole bitcoin adress in vanitygen.
the adress is a base58 of a hash+checksum.
You will have unbase58; remove the checksum, then rebase58 and try and find that sequence.
When found, that checksum part will be regenerated by vanitygen when it presents the result.... in a couple of million years.


try:
vanitygen 1 -k -o test.log

As far as I know the flags cannot combined.

It depends a bit on what you would consider a 'save' state.
-f --> input file
The input file of the matches you want to find, if the -k is not used a found match would be scratched of the list.
Restarting would put it back on the list.
-o --> output file
output file, no change here with start/restart. all found matches will be appendend.
-s --> seed file for randomness.
This is a tricky one. The brute force search requires a high entropy source for the EC-Points generation to be truly random.
If you have a system that has a more psuedo random entropy source; i.e. a possiblity to repeat the randomness in a set time,
and you might end up generating the same sequence of addresses all the time.
Using a seed file to bring in more randomess could help here.

Most OS-systems use a combination of randomness like CPU temp, time, HDD temp, HDD head locations etc to generate something true random.
I don't know if this the same case when a GPU is used.
So in a restart, if you are using -s, I would advice to use a different file each time you restart.
 

I had the same issue, but posted the question in the xpool thread.
here is the link.
https://bitcointalk.org/index.php?topic=650952.msg12599281#msg12599281
Got it working now.

If tried to update my settings with a MBL address, but since my default settings are NXT based,
the sign message procedure to add this wallet to my account is not available.
The procedure mentions a NXT-QT client, that as far as I know is not available and in the
standard web-based client I cannot find a sign message function.

Please advice.

And the number of found coins is still 0.

I tried both settings Lyra2RE and Lyra2REv2, and only with the Lyra2RE setting blocks got accepted.
The protocol does not match the listed coins.

It's a pity there is no 'real' pool that rewards the common effort.
Most of the third party generation is a rat race where the first find is rewarded.

This could relative easy be setup in a three stage approach.

1 - Client delivers a public key and a wanted prefix to the pool.

2 - Pool adds or multiplies their own private key and generates a new public key.

3 - Workers are now hashing with this new pool public key, and results are send back to the pool.
(intermediate results to generate shares are needed here)

2 - Pool combines his private key with the found private key, provides proof of work to client and collects reward.

1 - Clients takes the combined private key, combines it with it's own private key.

All miners can now be payed by share ratio.

Short answer is no.
The ASIC based miners only support the SHA and or Scrypt algorithms.

But 80% of the processing time for vanitycoins is related to the ECSDA calculations,
and there is also a RIMD hashing involved. These last two protocols are not supported by the ASIC's.

You would need GPU hashing for this one, and looking at the length of your prefix.... a lot of time.
each char is roughly a multiple of 60;  in your case you might need to run the program for
60^14/hashingspeed seconds.
Even when hashing 10GH/s that would take 25 million years.... give or take...

I had to add
to the conf file for solo mining.

The default value for a minimum transaction (0.01 IFC) is lower than the block reward,
so the block reward did not show up in the wallet during mining.

Took me some time to find out, any idea what happens to the block rewards of the found
blocks that were blocked by this low threshold setting of the wallet?