Bitcoin puzzle transaction ~32 BTC prize to who solves it

[adaseb]

I got a bunch of old GPUs that can't mine ETH or ZEC and for fun I am thinking of trying to solve the 50th bit with brute force.

However how can I get the oclvangen program to start at 1,125,899,906,842,620 instead of using random numbers and go in order.

With the GPUs I got it should take about 15 days or so...

 

[1714021155]

1714021155

[1714021155]

1714021155

[1714021155]

1714021155

[1714021155]

1714021155

[Xester]

I got a bunch of old GPUs that can't mine ETH or ZEC and for fun I am thinking of trying to solve the 50th bit with brute force.

However how can I get the oclvangen program to start at 1,125,899,906,842,620 instead of using random numbers and go in order.

With the GPUs I got it should take about 15 days or so...

 

If you have a hard time mining Ethereum using GPU then the best way and the most easy way is to register and download minergate. I am not advertising minergate but since it is the easiest way to mine ethereum I am sharing this to you. BUt with regards to ZEC I have no site to recommend to you. You can try my recommendation to find out if its a good option or not.

[BurtW]

I got a bunch of old GPUs that can't mine ETH or ZEC and for fun I am thinking of trying to solve the 50th bit with brute force.

However how can I get the oclvangen program to start at 1,125,899,906,842,620 instead of using random numbers and go in order.

With the GPUs I got it should take about 15 days or so...
 

You should read this thread and consider participating in the pooled search effort:

https://bitcointalk.org/index.php?topic=1573035.0

It looks like you can configure your system to search just the 2⁵¹ - 2⁵² private key address space (where then next payout will be):

https://bitcointalk.org/index.php?topic=1573035.msg16338052#msg16338052


This pooled effort is sequentially searching the key space.  They have already re-found almost all the puzzle transactions, see this page:

https://lbc.cryptoguru.org/trophies

I got a bunch of old GPUs that can't mine ETH or ZEC and for fun I am thinking of trying to solve the 50th bit with brute force.

However how can I get the oclvangen program to start at 1,125,899,906,842,620 instead of using random numbers and go in order.

With the GPUs I got it should take about 15 days or so...

 

If you have a hard time mining Ethereum using GPU then the best way and the most easy way is to register and download minergate. I am not advertising minergate but since it is the easiest way to mine ethereum I am sharing this to you. BUt with regards to ZEC I have no site to recommend to you. You can try my recommendation to find out if its a good option or not.

You should learn to read before you post.

[adaseb]

So I am trying to get the initial private key set to = 0; so I can do the search in sequential form, however its very difficult in oclvanitygen.

Basically I replaced

EC_KEY_generate_key(pkey);


with

char b1[] = "0";
BN_dec2bn(&res,b1);
EC_KEY_set_private_key(pkey, res)

However I keep getting the core segmentation fault error, probably something to do with the pointers.


Another issue is setting the rekey interval higher

const BN_ULONG rekey_max = 10000000;
   BN_ULONG npoints, rekey_at, nbatch;

Setting rekey_max to like 999999999999999 doesnt seem to work because every private key generated doesn't look sequential with the previous.

[jjrundy]

hey....you guys, the world of btc that unfolds before me everyday is still quite baffling, at least on the mining and coding side of it.
i've read most of this thread and am absolutely mesmerized by everyone's knowledge of the inner workings of things
i would love to be up to par with everyone on this. so who wants to tutor me and/or provide a link to something that explains
more in-depth?

[BurtW]

char b1[] = "0";

Did you try starting with one?

0 * G is a special case for the scalar multiply over the point group so try starting with one instead.

[adaseb]

char b1[] = "0";

Did you try starting with one?

0 * G is a special case for the scalar multiply over the point group so try starting with one instead.

Problem is I can't remove

EC_KEY_Generate_key(pkey)

Because I get segmentation fault

I need to leave that in there and just add

BN_init(&start);
     ctx = BN_CTX_new();

     res = &start;
BN_hex2bn(&res,"1");
EC_KEY_set_private_key(pkey, res);



But I keep getting delta errors on the GPU miner and with the CPU miner the pattern I search for doesn't equal to the result I get, but it actually starts with 1 private key.

I think the issue is that I also can't include

pkey = EC_KEY_new_by_curve_name(NID_secp256k1);

Because I get segmentation faults also.

[coinsocieties]

I have seen some of these before and I have to ask, how do you solve things like this.  Is there a method or general way to go about looking at this.  All this is to me is numbers and letters.  None of it makes sense to me, but I would like it to make sense.

[adaseb]

Finally got vanitygen AND oclvanitygen to start at a custom integer for the private key

I had some weird issue before with the POINT or the GROUP functions. That and I am really not good with Pointers.

Now just need to do some Optimizations to make it go faster.

Really hope to solve the 51st part of the puzzle.

[Jude Austin]

Finally got vanitygen AND oclvanitygen to start at a custom integer for the private key

I had some weird issue before with the POINT or the GROUP functions. That and I am really not good with Pointers.

Now just need to do some Optimizations to make it go faster.

Really hope to solve the 51st part of the puzzle.

I've got a 4 GPU rig sitting here doing nothing.

[adaseb]

Finally got vanitygen AND oclvanitygen to start at a custom integer for the private key

I had some weird issue before with the POINT or the GROUP functions. That and I am really not good with Pointers.

Now just need to do some Optimizations to make it go faster.

Really hope to solve the 51st part of the puzzle.

I've got a 4 GPU rig sitting here doing nothing.

Yeah I can't get it to work under windows for my GPUs. For some reason CYGWIN only seems the CPU.

So far scanning the 51st key

10 billion keys scanned and haven't hit it yet. Way too slow with CPU.


EDIT:

Scanned 42 Billion keys and not hit yet. I started with hex 6000000000000, which is 50% in the middle of the range.

Still working on getting the GPU miner to work however running into issues and rather not resort to Linux at the moment.


2nd EDIT:

I decided to abandon this project. Basically can't get Oclvanitygen to work in Windows with sequential search and the speeds seem very slow when using a 1x riser. It would take too long to find the 51st key and 52nd and 53rd would take months.

[Kangaderoo]

2nd EDIT:

I decided to abandon this project. Basically can't get Oclvanitygen to work in Windows with sequential search and the speeds seem very slow when using a 1x riser. It would take too long to find the 51st key and 52nd and 53rd would take months.

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.

[CyberKuro]

The transactions seem to originate from address 173ujrhEVGqaZvPHXLqwXiSmPVMo225cqT  which had a Total received amount of   56,457.80848111 BTC and a Final Balance of    312.04932734 BTC

Definitely a very big player of some kind.

Well spotted.

Also it looks active, there are daily transactions there.

Probably some exchange?

Well, now it's have total received 64,770.80848111 BTC   
 And Final Balance 4.72027689 BTC
Since, we mentioned so much about it. The owner move and divide his funds around, not interested to check all of them.
May not look like as exchange, probably just a trader. How lucky they are who had such big amount of bitcoin.

[adaseb]

2nd EDIT:

I decided to abandon this project. Basically can't get Oclvanitygen to work in Windows with sequential search and the speeds seem very slow when using a 1x riser. It would take too long to find the 51st key and 52nd and 53rd would take months.

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.

Im very bad at programming, all I did was add


const BN_ULONG rekey_max = 10000000000000000;
   BIGNUM *bnprivkey, *bnpubkey;      
   BIGNUM start;      
   BIGNUM *res;


   BN_init(&start);      
               
   int keylen = 32;      
         
   res = &start;      
   BN_hex2bn(&res,"6000000000000");      
         
         //   pkey = EC_KEY_new_by_curve_name(NID_secp256k1);      
         
   pgroup = EC_KEY_get0_group(pkey);      
         
   pgen = EC_POINT_new(pgroup);      
         
   EC_KEY_set_private_key(pkey,res);      
         
         
   if (!EC_POINT_mul(pgroup, pgen, res, NULL, NULL, vxcp->vxc_bnctx));      
      printf("ERROR AT EC POINT MUL");      
         
         
   EC_KEY_set_public_key(pkey, pgen);      
   rekey_at = 999999999999999;      

[Hydrogen]

I can't believe no one has cracked this yet (assuming its still even in play).

I saw this thread 2 years ago & assumed it would be cracked before I could get started on it.

Maybe I'll make an attempt at it later, if only for educational purposes & learning on my part.

[adaseb]

I can't believe no one has cracked this yet (assuming its still even in play).

I saw this thread 2 years ago & assumed it would be cracked before I could get started on it.

Maybe I'll make an attempt at it later, if only for educational purposes & learning on my part.

I think one reason why its not cracked is because you make like 10x more profit just mining ZEC, ETH, XMR, or other GPU coins than brute forcing the 51st bit. For the 52nd bit its 20x more profit, for 53rd bit its 40x more profit.

Another reason is that its hard to get the OCLVANITYGEN to run properly when starting at a custom integer instead of the random key. I asked in that main Vanitygen thread and seems most devs have moved on.

Another issue is speed. Since the program relies heavily on the CPU, if the GPU is inside a 1x slot, then it runs at 50% of its true speed. This is due to the poor lane speed in the 1x slot.

[erickkyut]

Hi guys,

In continuation to this thread: https://bitcointalk.org/index.php?topic=1305887.0

While playing around with my bot, I found out this mysterious transaction:

https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15

those 32.896 BTC were sent to multiple addresses, all the private keys of those addresses seem to be generated by some kind of formula.

For example:

Address 2:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S
1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
Biginteger PVK value: 3
Hex PVK value: 3

Address 3:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Biginteger PVK value: 7
Hex PVK value: 7

Address 4:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU77MfhviY5
1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e
Biginteger PVK value: 8
Hex PVK value: 8

Address 5:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Dq8Au4Pv
1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k
Biginteger PVK value: 21
Hex PVK value: 15

Address 6:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Tmu6qHxS
1PitScNLyp2HCygzadCh7FveTnfmpPbfp8
Biginteger PVK value: 49
Hex PVK value: 31

Address 7:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7hDgvu64y
1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC
Biginteger PVK value: 76
Hex PVK value: 4C

Address 8:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU8xvGK1zpm
1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK
Biginteger PVK value: 224
Hex PVK value: E0

Address 9:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUB3vfDKcxZ
1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV
Biginteger PVK value: 467
Hex PVK value: 1d3

Address 10:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUBTL67V6dE
1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe
Biginteger PVK value: 514
Hex PVK value: 202

Address 11:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUGxXgtm63M
1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu
Biginteger PVK value: 1155
Hex PVK value: 483

Address 12:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUW5RtS2JN1
1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot
Biginteger PVK value: 2683
Hex PVK value: a7b

Address 13:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUspniiQZds
1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1
Biginteger PVK value: 5216
Hex PVK value: 1460

Address 14:

KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVfZyiN5iEG
1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk
Biginteger PVK value: 10544
Hex PVK value: 2930

and so on...

until the addresses 50 (1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk) it was already cracked by someone.

Any ideas what's the formula behind the generation of these addresses?

Address 2, pvk decimal value: 3
Address 3, pvk decimal value: 7
Address 4, pvk decimal value: 8
Address 5, pvk decimal value: 21
Address 6, pvk decimal value: 49
Address 7, pvk decimal value: 76
Address 8, pvk decimal value: 224
Address 9, pvk decimal value: 467
Address 10, pvk decimal value: 514
Address 11, pvk decimal value: 1155
Address 12, pvk decimal value: 2683
Address 13, pvk decimal value: 5216
Address 14, pvk decimal value: 10544
Address 15 and after, pvk decimal value: ?

The prize would be ~32 BTC

EDIT: If you find the solution feel free to leave a tip 1DPUhjHvd2K4ZkycVHEJiN6wba79j5V1u3

I wan to try but I'm not a techy person. I have limited knowledge regarding computer programs and coding! But I want to keep track on this puzzle. I want to know who will be the genius that will solve this. 32 BTC is already a big reward for ansering a puzzle Good luck to everyone!

[BadGhost]

Cracking it is useless. Its interesting I fully agree, but from economical point of view, you gonna bleed money on every other address. What kept me interested in reading those posts is that this address with over 57K Btc I have found it aswell but on a completely different basis. I was searching for some bitcoins from the very beginning of bitcoin for my own purposes, but I have found this. There is much more wierd patters created by the owner/owners. Literally thousands of unspend 0.01 btc transactions. Clusters of 1 btc transactions, which end up in unspend amounts of 0.005 and so on. I believe the real question here is why would you do that? Someone must have wrote a bot to do that many transactions. Someone must have a file of thousands private keys to thousands addresses - that just does not make things safe.

So why would someone do it? And who is it?

[Kangaderoo]

Im very bad at programming, all I did was add

const BN_ULONG rekey_max = 10000000000000000;
   BIGNUM *bnprivkey, *bnpubkey;      
   BIGNUM start;      
   BIGNUM *res;


   BN_init(&start);      
               
   int keylen = 32;      
         
   res = &start;      
   BN_hex2bn(&res,"6000000000000");      
         
         //   pkey = EC_KEY_new_by_curve_name(NID_secp256k1);      
         
   pgroup = EC_KEY_get0_group(pkey);      
         
   pgen = EC_POINT_new(pgroup);      
         
   EC_KEY_set_private_key(pkey,res);      
         
         
   if (!EC_POINT_mul(pgroup, pgen, res, NULL, NULL, vxcp->vxc_bnctx));      
      printf("ERROR AT EC POINT MUL");      
         
         
   EC_KEY_set_public_key(pkey, pgen);      
   rekey_at = 999999999999999;      

my change in the cpu version:

Code:

const BN_ULONG rekey_max = 1000000000000000000;
// snip//
	while (!vcp->vc_halt) {
		if (++npoints >= rekey_at) {
			vg_exec_context_upgrade_lock(vxcp);
			/* Generate a new random private key */

// remove the random key generation
//			EC_KEY_generate_key(pkey); 
// add start point equal to 1 * generator
			BN_set_word(&vxcp->vxc_bntmp, 1);
			EC_KEY_set_private_key(pkey, &vxcp->vxc_bntmp);
			EC_KEY_set_public_key(pkey, pgen);

and the second change I made, just to prevent a EC_point add where EC_Point double is needed

Code:

			if (vcp->vc_pubkey_base){
				EC_POINT_add(pgroup,
						 ppnt[0],
						 ppnt[0],
						 vcp->vc_pubkey_base,
						 vxcp->vxc_bnctx);
				EC_POINT_add(pgroup,
							 ppnt[1],
							 ppnt[0],
							 pgen,
							 vxcp->vxc_bnctx);
			}
			else{
				EC_POINT_dbl(pgroup,
							 ppnt[1],
							 ppnt[0],
							 vxcp->vxc_bnctx);
			}
// point 0 and 1 in the array are predefined, start from point 2.

			for (nbatch = 2;
				 (nbatch < ptarraysize) && (npoints < rekey_at);
  				 nbatch++, npoints++) {

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.

[BurtW]

Cracking it is useless. Its interesting I fully agree, but from economical point of view, you gonna bleed money on every other address. What kept me interested in reading those posts is that this address with over 57K Btc I have found it aswell but on a completely different basis. I was searching for some bitcoins from the very beginning of bitcoin for my own purposes, but I have found this. There is much more wierd patters created by the owner/owners. Literally thousands of unspend 0.01 btc transactions. Clusters of 1 btc transactions, which end up in unspend amounts of 0.005 and so on. I believe the real question here is why would you do that? Someone must have wrote a bot to do that many transactions. Someone must have a file of thousands private keys to thousands addresses - that just does not make things safe.

So why would someone do it? And who is it?

Sounds like a Bitcoin mixer to me.