Bitcoin puzzle transaction ~32 BTC prize to who solves it

[adaseb]

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.

Thanks I will try this with the oclvanitygen, however do you know how to make it detect AMD gpus when compiled with cygwin ?

I installed the OpenCL deps, added the amd.icd to \cygwin\etc\OpenCL\, copied the headers and libraries like so
cp -R '/cygdrive/c/Program Files (x86)/AMD APP SDK'/*/include/CL /usr/include
    $ cp '/cygdrive/c/Program Files (x86)/AMD APP SDK'/*/lib/x86/*.a /usr/lib

However it only detects the POCL

[1713575894]

1713575894

[1713575894]

1713575894

[1713575894]

1713575894

[1713575894]

1713575894

[1713575894]

1713575894

[shamzblueworld]

Why don't you ask Robert Langdon, I heard he is quite good at this sort of thing
Well the sequence doesn't make much sense to me as of yet but will try with it a little more later. But in any case, I don't think someone will give out 32 BTC just to solve some puzzle... there must be something else that we don't know or can't see.
Sherlock to rescue maybe?

[Jude Austin]

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.

Thanks I will try this with the oclvanitygen, however do you know how to make it detect AMD gpus when compiled with cygwin ?

I installed the OpenCL deps, added the amd.icd to \cygwin\etc\OpenCL\, copied the headers and libraries like so
cp -R '/cygdrive/c/Program Files (x86)/AMD APP SDK'/*/include/CL /usr/include
    $ cp '/cygdrive/c/Program Files (x86)/AMD APP SDK'/*/lib/x86/*.a /usr/lib

However it only detects the POCL

Howdy,

I am able to get oclvanitygen to compile with out error but when I run it I get this:

Code:

C:\cygwin\home\Jude Austin\vanitygen-master>oclvanitygen 1Test
Difficulty: 264104224
      0 [main] oclvanitygen 7672 cygwin_exception::open_stackdumpfile: Dumping stack trace to oclvanitygen.exe.stackdump

The stackdump:

Code:

[tt]Exception: STATUS_ACCESS_VIOLATION at eip=20042B00
eax=00000000 ebx=200428D0 ecx=2004293C edx=00000000 esi=6107CE80 edi=00000000
ebp=0065CC48 esp=0065C8B8 program=C:\cygwin\home\Jude Austin\vanitygen-master\oclvanitygen.exe, pid 10408, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame     Function  Args
0065CC48  20042B00 (00000002, 0065CC6C, 200280F0, 61007A6A)
0065CD18  61007ACF (00000000, 0065CD74, 61006B00, 00000000)
End of stack trace[/tt]

When I run oclvanitygen.exe 1Test I can hear my video card fan fire up and then I get the exception.

According to Dependency Walker I am using c:\windows\system32\OPENCL.DLL

Anyone have any ideas?

[canhchuacaro1]

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

Great!!!!
This is wonderful, a number too large
I feel sorry to not be involved
Congratulations to those who have joined
I really want to participate in that program
where can I participate in ?

[Kangaderoo]

// snip //
When I run oclvanitygen.exe 1Test I can hear my video card fan fire up and then I get the exception.

According to Dependency Walker I am using c:\windows\system32\OPENCL.DLL

Anyone have any ideas?

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.

[adaseb]

I tried what you guys suggested and now I am getting hundreds of errors like

undefined reference to 'clRleaseContent' etc

No clue how to get the GPU to work under Windows. Even if it doesn't get these errors, it doesn't find the AMD GPUs.

[sabbybibi]

This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density.

If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two?

[rico666]

LBC has found #50 yesterday. See also

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

Next stop: 51 - with funds (so far).

Rico

[Kizaki]

So hard to solve for this even a genius may take time reviewing this

[rico666]

This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density.

You're saying the right thing (about entropy), but you do not think it through to the end.
The 161-256 are already (as collisions) in the 1-160 search space. So for the puzzle creator there's no need to do anything. :-)


Rico

[rico666]

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

LBC Pool front set to 2^50 - the hunt for #51 of the puzzle transaction has begun! 0.051 BTC bounty awaits in 0-41 days. Start your engines!

Rico

[BurtW]

This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density.

You're saying the right thing (about entropy), but you do not think it through to the end.
The 161-256 are already (as collisions) in the 1-160 search space. So for the puzzle creator there's no need to do anything. :-)


Rico

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

LBC Pool front set to 2^50 - the hunt for #51 of the puzzle transaction has begun! 0.051 BTC bounty awaits in 0-41 days. Start your engines!

Rico

What we can say with respect to these two posts:

Between 2⁰ and 2⁵⁰ there were 50 - 0 = 50 bounties found.

Somewhere between 2⁵⁰ and 2⁵¹ there is at least one bounty.
Somewhere between 2⁵¹ and 2⁵² there is at least one bounty.
Etc.

If every single private key between 2⁰ and 2⁵⁰ was not tried then there is a (small) possibility that you might have missed another bounty.

Assuming no bounties were missed due to leaving holes in the search space between 2⁰ and 2⁵⁰ then between 2⁵⁰ and 2¹⁶⁰, instead of only 160 - 50 = 110 bounties there are 256 - 50 = 206 bounties.

So, once you find one bounty in a search space (2⁵⁰ ... 2⁵¹ for example) you really should search the entire remaining space to see if there is a second (aliased) larger bounty!

You will be able to very easily see if you find an "extra" bounty in a range before the expected bounty because the bounty will be much larger than expected. 

However if you happen to find the expected bounty and then skip to the next range there is a chance you will miss a larger bounty in the remainder of the range.

[rico666]

What we can say with respect to these two posts:

Between 2⁰ and 2⁵⁰ there were 50 - 0 = 50 bounties found.

We call them trophies. There were these https://lbc.cryptoguru.org/trophies found.

Somewhere between 2⁵⁰ and 2⁵¹ there is at least one bounty.
Somewhere between 2⁵¹ and 2⁵² there is at least one bounty.
Etc.

Where the probability of having more than one bounty doubles with each of these spaces.

If every single private key between 2⁰ and 2⁵⁰ was not tried then there is a (small) possibility that you might have missed another bounty.

We will try every single key. Every single key between 0 and 2^49.35 was tried. We will now try every single key from 2⁵⁰ on and after #51 is found, then finish the work 2^49.35 to 2⁵⁰. If it's there, we will miss nothing.

So, once you find one bounty in a search space (2⁵⁰ ... 2⁵¹ for example) you really should search the entire remaining space to see if there is a second (aliased) larger bounty!

Sure. That's the normal mode of operation. That's how we found e.g. f6cc30532dba44efe592733887f4f74c589c9602
In general, we seem to find uncompressed addresses with funds that pre-date the pool inception.

However if you happen to find the expected bounty and then skip to the next range there is a chance you will miss a larger bounty in the remainder of the range.

We know. We perform an exhaustive search. It's just for this specific #51 we skipped around 370 tn keys, because it has funds and it would be nice if the LBC finds it before someone else does. Then we return to our normal mode of operation.



Rico

[rico666]

All of this story tell us something.

We now know that someone out there is able to crack aprox. 2^50 private keys in about 1 year.

(in a worst case scenario, also assuming that the one who cracked the 50 addresses brute forced all the possible addresses sequential)

As time goes by this capability will increase, it may take decades and decades or centuries but eventually it will be possible to crack 2^256 pvks.

The transaction referenced in this thread is a good reference to test how far the mankind cracking capabilities are.

...

2^50   1125899906842620   <- This is aprox. the number of bitcoins private keys someone is able to crack in about 1 year
...
2^160   1461501637330900000000000000000000000000000000000   
...
2^256   115792089237316000000000000000000000000000000000000000000000000000000000000000   <- And this is how safe bitcoin is.

Nope. Nope and nope.

a) 1125899906842620 is the number of private keys LBC is able to crack within 15 days (at current speed - see https://lbc.cryptoguru.org/stats)
b) Your calculator seems to have trouble with big numbers
2¹⁶⁰ = 1461501637330902918203684832716283019655932542976 <---- also, this is how safe bitcoin is

so

c) Bitcoin is not 256bit safe



Rico

[rico666]

I repeat: LBC found #51 tonight!   


Rico

[amaclin]

I repeat: LBC found #51 tonight!   

What is the reason to sweep to the same address?
https://blockchain.info/tx/70ee9ab241829a6f49ebf9f109e97f6e466d938e558bade1c5fe341310bc356e
proof of knowing private key?

[rico666]

I repeat: LBC found #51 tonight!   

What is the reason to sweep to the same address?
https://blockchain.info/tx/70ee9ab241829a6f49ebf9f109e97f6e466d938e558bade1c5fe341310bc356e
proof of knowing private key?

I think the same reason as for sweeping #1 - #50: These are bounties - right?

Rico

[NeuroticFish]

I repeat: LBC found #51 tonight!   

What is the reason to sweep to the same address?
https://blockchain.info/tx/70ee9ab241829a6f49ebf9f109e97f6e466d938e558bade1c5fe341310bc356e
proof of knowing private key?

I think the same reason as for sweeping #1 - #50: These are bounties - right?

Rico

Amaclin is right. You didn't read (or translate) the question correctly.
The source and the target address in the transaction are the same.

I guess that the reason is to prove they know the private key. I guess that it was found by the large collider thing, since, from what I know, they ask only for a % of the money after "cracking" the private key of a wallet.

[amaclin]

I guess that the reason is to prove they know the private key. I guess that it was found by the large collider
thing, since, from what I know, they ask only for a % of the money after "cracking" the private key of a wallet.

As far as I know the "author" of this puzzle-transaction is unknown.
Whom are you asking?

[NeuroticFish]

I guess that the reason is to prove they know the private key. I guess that it was found by the large collider
thing, since, from what I know, they ask only for a % of the money after "cracking" the private key of a wallet.

As far as I know the "author" of this puzzle-transaction is unknown.
Whom are you asking?

I know.
I just tried to give some sort of reasoning behind what could mean that self-sending of those funds.
Anyone with a better idea is most welcome to share it