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, where as vanitygen only uses one methode, addition I believe.

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.

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

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.

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?

I was looking for an update like this for weeks on your facebook and twitter pages.
It would have been nice if you also used these channels to update your loyal players.

It's a pity you've decided to stop.
Please keep you players updated until all accounts are settled.

So the fact that I'm a newbie make me unfit to have an opinion that differs from yours...?

I've played the game! Where possible I verified the find of others so to checked their conclusions.
I've backtracked often enough to check the current leads and the trail we were following was logical
with regards to the solved puzzles and hints and the way forward.

The only conclusion I can make (as newbie... so it doesn't count) is that this puzzle was not self sustaining, and needed too many
hint from the OP to keep the momentum going, but the solution as provided by gatekeeper has more merit than
the alternative solution you keep promoting. That one has more holes than Swiss cheese.... and less pony's....

I guess you are correct, I should not be playing the games. :-(
The image with the marked area used in the solution you are promoting has actually being made by me..... and its wrong.
https://bitcointalk.org/index.php?topic=661781.msg7669775#msg7669775
I did mention the line-up is not exact.....

There have been updates of this image where this overlay content was scaled correctly, no line is going down the Declination column there.....
I have to agree with you that this overlay has not been explained, there as also never been a hint that it was part of the puzzle either...
80% of the Dungeons of Daggorath source code has not been used, you need an explanation for that as well?

There has never been a real hint from the OP that the solution had to be a darkwallet. Sure with the picture as starting point it could have been an option.
That is what makes it a puzzle; pursue possibilities and eliminate impossibilities.
The title of this topic has been changing during the game but it always stated that we were searching for a private key, here it never mentioned a darkwallet seed.

This was no hint from OP, it actually is the solution of the crop circle puzzle.


Yeah, this makes much more sense then seeing it as a description of a base 62 alphabet translation.
The 'real' solution you keep referring to is just as fragile in it assumptions and leaps.

It could have been a valid path, but I have to believe the real path to the correct solution is the one defined by the makers or the puzzle itself.
Sure the road was bumpy and bouncy and at times we were led by the hand, but it does not make their defined road wrong, just different that
the one you are promoting.

Since I mostly enjoyed the puzzle as was laid out by the OP, I welcome a new version, and take any mistakes for granted.

I suggest to watch the movie "A beautiful mind"
If you really look for something hidden and believe its there, you will always find something.

Concerning the game, there were some slip-ups making the puzzle not self sustaining.
I know I 'broke' the rule of not looking behind the curtain by (trying to?) expose xavier46930.
The problem being that when the first bit(.)ly/mindthecraft was found, I just used the link with a plus(+) to see the stats of this link.
At the time I did this the name xavier46930 was listed as owner of the link.
A couple of hours later this was set to someone, making it impossible for anyone else to follow the same path.
Hints should be able to be found by anyone, not just by a lucky few at specific times (OP updates..... ?)
The curtain should not be moving constantly if you want participants not to look!
After this I just followed the puzzle instead of participating fully.

An ARG follows the rules as set by the puppetmaster. If you don't like the rules... well I was not forced to play......

And yes, I would have liked the answer to be in the same start image.

If at the end someone with 1500 BTC wins the price... I'm just glad the winner was someone who actually posted a lot on the forum and was a player
from the beginning. He spend just as much time puzzling as anyone else.

See you all at the next treasurehunt.

It's just brute-forcing 62^8 (218340105584896) combinations....
@ 1MHash/sec about 252 days of work....

Congrats to the winner.....

I learned a lot and slept little.....