Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Evillo]

Doing some testing on 76 bit...

Code:

KangaBGStrider v1.01
Range Start :0 (0 bit)
Range End   :FFFFFFFFFFFFFFFFFFF (76 bit)
Public Key(s) :1
Creating Stride Table...
CPU thread(s) : 8
Stride Table Complete: Max Stride: 2^36
Stride Avg Distance: 2^34.09
Number of Striders: 2^13.00
Suggested DP: 22
Expected operations: 2^41.39
Simulated DP size: 32 [0x00000000FFFFFFFF]
[31.88 MS/s][GPU 0.00 MS/s][Total Collision Checks 2^32.97][05:04 (Avg 1.0d)]
Key# 0 [1S]Pub:  0x02BF6E9A6F10A15DC828E968FC96CF9BC80A98F42227CCBE2AC4947B637B3E8FB1
       Priv: 0x865CE114686A1301A4C

Done: Total time 05:05

This code be revolutionary if stretched all the way up to say 128 bits. Might get speed that no one managed to reach before. Congrats WP, another great build.

[1714643463]

1714643463

[1714643463]

1714643463

[WanderingPhilospher]

I found a way to speed up the brute force attack method, drop the hash160 conversion to address, because that conversion requires a SHA-256D, that is equal as mining bitcoin, now if we skip that part, what percentage can we gain in speed increase?

True. It's how Brainflayer and keyhunt in RMD160 mode work. Much much faster and results in the same output eventually. I wish bitcrack would update to rmd mode. Might double speed.

Are y'all talking about loading/searching for hash160 versus address? I ask because this comment kind of confused me, "drop the hash160 conversion to address".

Yes

Then you are correct. This has been known and Vanity, KeyhuntCuda, do in fact already do this. I’m not sure about bitcrack; I’d have to look at the code.

[Evillo]

I found a way to speed up the brute force attack method, drop the hash160 conversion to address, because that conversion requires a SHA-256D, that is equal as mining bitcoin, now if we skip that part, what percentage can we gain in speed increase?

True. It's how Brainflayer and keyhunt in RMD160 mode work. Much much faster and results in the same output eventually. I wish bitcrack would update to rmd mode. Might double speed.

Are y'all talking about loading/searching for hash160 versus address? I ask because this comment kind of confused me, "drop the hash160 conversion to address".

Yes

Then you are correct. This has been known and Vanity, KeyhuntCuda, do in fact already do this. I’m not sure about bitcrack; I’d have to look at the code.

Yeah Bitcrack is a classic try-the-privatekey-and-convert-to-full-address-then-compare-to-input-address thingy. It's fast and works on all GPU types, although it failed test on all RX 500 series 8GB GPUs for some reason. There is a random search version of it that generates millions of random sub-ranges and start searching through them sequentially. Good stuff. Not fast enough compared to Vanbitcracken. If we can drop the convert-all-the-way-to-address process, this can save a lot of time by generating output faster. Keyhuntcuda is a great example for this.

And even better, what if we can apply the prefix concept on hash160 too. Instead of looking for address prefix, we look for hash160 prefix. Even more speed. In fact, this would be the fastest way ever.

[digaran]

And even better, what if we can apply the prefix concept on hash160 too. Instead of looking for address prefix, we look for hash160 prefix. Even more speed. In fact, this would be the fastest way ever.

Won't work, rmd160 has 40 characters and by searching for their prefix, should we stop hashing half way? Meaning converting sha256 hash of public key into rmd160 but only looking for a specific prefix, either we generate the whole hash and compare with our target or we can't generate just a prefix to compare because it would break the function and we wouldn't know the result.

About brute force tools, bitcrack, vanity etc they all convert rmd160 to address, otherwise why would they accept an address as an input to check against?

[WanderingPhilospher]

And even better, what if we can apply the prefix concept on hash160 too. Instead of looking for address prefix, we look for hash160 prefix. Even more speed. In fact, this would be the fastest way ever.

Won't work, rmd160 has 40 characters and by searching for their prefix, should we stop hashing half way? Meaning converting sha256 hash of public key into rmd160 but only looking for a specific prefix, either we generate the whole hash and compare with our target or we can't generate just a prefix to compare because it would break the function and we wouldn't know the result.

About brute force tools, bitcrack, vanity etc they all convert rmd160 to address, otherwise why would they accept an address as an input to check against?

Say huh?! You have it backwards. Or at least saying it backwards. Vanity takes addresses and converts to 160.
I also believe it converts the partial strings to 160 as well; I’d have to recheck on that but I’m pretty sure it does.

[digaran]

And even better, what if we can apply the prefix concept on hash160 too. Instead of looking for address prefix, we look for hash160 prefix. Even more speed. In fact, this would be the fastest way ever.

Won't work, rmd160 has 40 characters and by searching for their prefix, should we stop hashing half way? Meaning converting sha256 hash of public key into rmd160 but only looking for a specific prefix, either we generate the whole hash and compare with our target or we can't generate just a prefix to compare because it would break the function and we wouldn't know the result.

About brute force tools, bitcrack, vanity etc they all convert rmd160 to address, otherwise why would they accept an address as an input to check against?

Say huh?! You have it backwards. Or at least saying it backwards. Vanity takes addresses and converts to 160.
I also believe it converts the partial strings to 160 as well; I’d have to recheck on that but I’m pretty sure it does.

If that's the case then there is another way to speed up the process but this would work for addresses with known public key. Searching only for the public key, saves us a sha256 and rmd160 to skip.

[WanderingPhilospher]

And even better, what if we can apply the prefix concept on hash160 too. Instead of looking for address prefix, we look for hash160 prefix. Even more speed. In fact, this would be the fastest way ever.

Won't work, rmd160 has 40 characters and by searching for their prefix, should we stop hashing half way? Meaning converting sha256 hash of public key into rmd160 but only looking for a specific prefix, either we generate the whole hash and compare with our target or we can't generate just a prefix to compare because it would break the function and we wouldn't know the result.

About brute force tools, bitcrack, vanity etc they all convert rmd160 to address, otherwise why would they accept an address as an input to check against?

Say huh?! You have it backwards. Or at least saying it backwards. Vanity takes addresses and converts to 160.
I also believe it converts the partial strings to 160 as well; I’d have to recheck on that but I’m pretty sure it does.

If that's the case then there is another way to speed up the process but this would work for addresses with known public key. Searching only for the public key, saves us a sha256 and rmd160 to skip.

Yeah that’s already a thing…for at least 2 years now.

[digaran]

Yeah that’s already a thing…for at least 2 years now.

So bitcrack and vanity can search for public key alone?

[WanderingPhilospher]

Yeah that’s already a thing…for at least 2 years now.

So bitcrack and vanity can search for public key alone?

No, but both Keyhunters can and in short nutshell, that is what Kangaroo does; think of all the points saved as an auto, continually growing, x point input file.

[Evillo]

Yeah that’s already a thing…for at least 2 years now.

So bitcrack and vanity can search for public key alone?

Although there are tools for that, we are limited by the fact that you would have to know the public key of your target addresses. I have 250,000 pulic keys of the richest addresses, updated every month, but the problem is i would have to be searching for those in the 253-256 bit to ever dream of finding the private key. Since this is almost ALMOST impossible to achieve, pub key cracking should only be used on puzzle addresses and even those are in the high bit range i.e 125-160 bits . That's why i was originally talking about searching through pure private key cracking. Which gets me to the previous point of hash160 prefix. You're right, prefixing h160 would break the function. Looks like we're gonna stick to conventional ways.

[Lolo54]

Doing some testing on 76 bit...

Code:

KangaBGStrider v1.01
Range Start :0 (0 bit)
Range End   :FFFFFFFFFFFFFFFFFFF (76 bit)
Public Key(s) :1
Creating Stride Table...
CPU thread(s) : 8
Stride Table Complete: Max Stride: 2^36
Stride Avg Distance: 2^34.09
Number of Striders: 2^13.00
Suggested DP: 22
Expected operations: 2^41.39
Simulated DP size: 32 [0x00000000FFFFFFFF]
[31.88 MS/s][GPU 0.00 MS/s][Total Collision Checks 2^32.97][05:04 (Avg 1.0d)]
Key# 0 [1S]Pub:  0x02BF6E9A6F10A15DC828E968FC96CF9BC80A98F42227CCBE2AC4947B637B3E8FB1
       Priv: 0x865CE114686A1301A4C

Done: Total time 05:05

Superb result WanderingPhilospher especially only on CPU you get the result 4 times faster than with BSGSCuda and Kangaroo from JLP on my RTX 2070. I noticed that kangaroo was a little faster than BSGS on your 76 bit 18 min VS 20 min for 02BF6E9A6F10A15DC828E968FC96CF9BC80A98F42227CCBE2AC4947B637B3E8FB1
Out of curiosity I did a test with a key taken at random from the 80 bit range to compare BSGS again with kANGAROO then then if you want to test this same pubkey to display your result which should be 4 times faster so surely on the 20 MIN approximately just with CPU VS 1H20 on GPU with kangaroo and 5 Days for BSGSCuda
Kangaroo result 1h20 for this 80 bit 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc
BSGSCuda result stopped (in 47 min 4410978597433994379265 key traveled) i.e. a little over 5 days on my RTX 2070 to get the key
On the large range Kangaroo remains for the moment still the fastest and most efficient in my opinion
Adapting KangaBGstrider V 1.01 on GPU could give the same result for this 80 bit in less than 1min or around 20 min on CPU, of course then everything also depends on the hardware used as well as the number deployed.
But I think that on a single GPU type RTX 2070 or 2080 the result could be given in 45s
Could you do a test on this pubkey 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc to display your result when it is possible and if you want of course :-)


My results on the 76 bit with BSGS then Kangaroo

Code:

C:\Users\Laurent>C:\Users\Laurent\Documents\Bitcoin\BSGSgpu.exe -t 512 -b 72 -p 256 -pk 8000000000000000000 -pke fffffffffffffffffff -w 30 -htsz 28 -pb 02BF6E9A6F10A15DC828E968FC96CF9BC80A98F42227CCBE2AC4947B637B3E8FB1
Number of GPU threads set to #512
Number of GPU blocks set to #72
Number of pparam set to #256
Range begin: 0x8000000000000000000
Range end: 0xfffffffffffffffffff
Items number set to 2^30
HT size number set to 2^28
Pubkey set to 02bf6e9a6f10a15dc828e968fc96cf9bc80a98f42227ccbe2ac4947b637b3e8fb1
APP VERSION: 1.7.3
Found 1 Cuda device.
Cuda device:NVIDIA GeForce RTX 2070 (7173.000/8191MB)
Device have: MP:36 Cores+2304
Try -t 512 -b 72 -p 304 -w 30 -htsz 28 [7170.000 MB] Gen RAM[28672 MB]
---------------
Current config hash[d4b0aa674cd6f609feedc322743bf9fdb571f06c]
GiantSUBvalue:0000000000000000000000000000000000000000000000000000000080000000
GiantSUBpubkey: 025318f9b1a2697010c5ac235e9af475a8c7e5419f33d47b18d33feeb329eb99a4
*******************************
Total GPU Memory Need: 7008.000Mb
*******************************
Both HT files exist
Load BIN file:79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798_1073741824_268435456_htGPU.BIN
[0] chunk:1073741824b
[1] chunk:1073741824b
[2] chunk:1073741824b
[3] chunk:1073741824b
[4] chunk:1073741824b
[5] chunk:1073741824b
Generate Giants Buffer: 9437184 items
Load BIN file:512_72_256_1073741824_g2.BIN
[0] chunk:603979776b
Done in 00:00:01s
GPU count #1
GPU #0 launched
GPU #0 Free memory: 7171Mb
GPU #0 Total memory: 8191Mb
GPU #0 TotalBuff: 7008.000Mb
Load BIN file:79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798_1073741824_268435456_htCPU.BIN
[0] chunk:1073741824b
[1] chunk:1073741824b
[2] chunk:1073741824b
[3] chunk:1073741824b
[4] chunk:1073741824b
[5] chunk:1073741824b
[6] chunk:1073741824b
[7] chunk:1073741824b
[8] chunk:1073741824b
[9] chunk:1073741824b
START RANGE= 0000000000000000000000000000000000000000000008000000000000000000
  END RANGE= 000000000000000000000000000000000000000000000fffffffffffffffffff
WIDTH RANGE= 0000000000000000000000000000000000000000000007ffffffffffffffffff
SUBpoint= (107460520eec5c741683329a716622b0b81c03200807de973686f8800b188cbb, 541a2b3f65dea673cacd9464630ab5eedbd1f28b7231c259fe2849c8e0d8db0b)
Save work every 180 seconds

FINDpubkey: 02bf6e9a6f10a15dc828e968fc96cf9bc80a98f42227ccbe2ac4947b637b3e8fb1
Cnt:658ec0000000000001 [1][ 722 ] = 722 MKeys/s x2^31=2^60.50 t:00:20:01
KEY[1]: 0x000000000000000000000000000000000000000000000865ce114686a1301a4c
   Pub: 02bf6e9a6f10a15dc828e968fc96cf9bc80a98f42227ccbe2ac4947b637b3e8fb1
Working time 00:20:03s
Total time 00:21:47s
GPU#0 job finished
GPU#0 thread finished
cuda finished ok

Code:

C:\Users\Laurent>C:\Users\Laurent\Documents\Bitcoin\Kangaroo2.2.exe -t 6 -gpu -d 14 -o resultkang76.txt -ws Kang76.txt
Kangaroo v2.2
Start:8000000000000000000
Stop :FFFFFFFFFFFFFFFFFFF
Keys :1
Number of CPU thread: 6
Range width: 2^75
Jump Avg distance: 2^37.02
Number of kangaroos: 2^20.18
Suggested DP: 14
Expected operations: 2^38.60
Expected RAM: 982.1MB
DP size: 14 [0xFFFC000000000000]
SolveKeyCPU Thread 1: 1024 kangaroos
SolveKeyCPU Thread 2: 1024 kangaroos
SolveKeyCPU Thread 5: 1024 kangaroos
SolveKeyCPU Thread 4: 1024 kangaroos
SolveKeyCPU Thread 3: 1024 kangaroos
SolveKeyCPU Thread 0: 1024 kangaroos
GPU: GPU #0 NVIDIA GeForce RTX 2070 (36x64 cores) Grid(72x128) (97.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^20.17 kangaroos [4.6s]
[660.58 MK/s][GPU 619.62 MK/s][Count 2^39.09][Dead 1][17:50 (Avg 10:30)][1.1/1.3GB]  MB]
Done: Total time 18:07

 80 bit pubkey 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc

Code:

C:\Users\Laurent>C:\Users\Laurent\Documents\Bitcoin\Kangaroo2.2.exe -t 6 -gpu -d 16 -o resultkang80.txt -ws Kang80.txt
Kangaroo v2.2
Start:80000000000000000000
Stop :FFFFFFFFFFFFFFFFFFFF
Keys :1
Number of CPU thread: 6
Range width: 2^79
Jump Avg distance: 2^38.96
Number of kangaroos: 2^20.18
Suggested DP: 16
Expected operations: 2^40.60
Expected RAM: 982.1MB
DP size: 16 [0xFFFF000000000000]
SolveKeyCPU Thread 4: 1024 kangaroos
SolveKeyCPU Thread 5: 1024 kangaroos
SolveKeyCPU Thread 1: 1024 kangaroos
SolveKeyCPU Thread 3: 1024 kangaroos
SolveKeyCPU Thread 2: 1024 kangaroos
SolveKeyCPU Thread 0: 1024 kangaroos
GPU: GPU #0 NVIDIA GeForce RTX 2070 (36x64 cores) Grid(72x128) (97.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^20.17 kangaroos [5.0s]
[648.05 MK/s][GPU 603.01 MK/s][Count 2^41.31][Dead 2][01:19:35 (Avg 42:51)][1.2/1.6GB]
Done: Total time 01:19:58

Code:

C:\Users\Laurent>C:\Users\Laurent\Documents\Bitcoin\BSGSgpu.exe -t 512 -b 72 -p 256 -pk 80000000000000000000 -pke ffffffffffffffffffff -w 30 -htsz 28 -pb 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc
Number of GPU threads set to #512
Number of GPU blocks set to #72
Number of pparam set to #256
Range begin: 0x80000000000000000000
Range end: 0xffffffffffffffffffff
Items number set to 2^30
HT size number set to 2^28
Pubkey set to 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc
APP VERSION: 1.7.3
Found 1 Cuda device.
Cuda device:NVIDIA GeForce RTX 2070 (7173.000/8191MB)
Device have: MP:36 Cores+2304
Try -t 512 -b 72 -p 304 -w 30 -htsz 28 [7170.000 MB] Gen RAM[28672 MB]
---------------
Current config hash[1e744f24cca3231323c65c9831191e62c175fcc5]
GiantSUBvalue:0000000000000000000000000000000000000000000000000000000080000000
GiantSUBpubkey: 025318f9b1a2697010c5ac235e9af475a8c7e5419f33d47b18d33feeb329eb99a4
*******************************
Total GPU Memory Need: 7008.000Mb
*******************************
Both HT files exist
Load BIN file:79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798_1073741824_268435456_htGPU.BIN
[0] chunk:1073741824b
[1] chunk:1073741824b
[2] chunk:1073741824b
[3] chunk:1073741824b
[4] chunk:1073741824b
[5] chunk:1073741824b
Generate Giants Buffer: 9437184 items
Load BIN file:512_72_256_1073741824_g2.BIN
[0] chunk:603979776b
Done in 00:00:01s
GPU count #1
GPU #0 launched
GPU #0 Free memory: 7171Mb
GPU #0 Total memory: 8191Mb
GPU #0 TotalBuff: 7008.000Mb
Load BIN file:79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798_1073741824_268435456_htCPU.BIN
[0] chunk:1073741824b
[1] chunk:1073741824b
[2] chunk:1073741824b
[3] chunk:1073741824b
[4] chunk:1073741824b
[5] chunk:1073741824b
[6] chunk:1073741824b
[7] chunk:1073741824b
[8] chunk:1073741824b
[9] chunk:1073741824b
START RANGE= 0000000000000000000000000000000000000000000080000000000000000000
  END RANGE= 00000000000000000000000000000000000000000000ffffffffffffffffffff
WIDTH RANGE= 000000000000000000000000000000000000000000007fffffffffffffffffff
SUBpoint= (769bc75842bff58edc8366ecd78f8950ee4ab2e81359d90f9921fa3d2c4561be, b407e8c9d0187c4537231b3108c0a2b8be5e888984878c522a6df3ff4f2693d0)
Save work every 180 seconds

FINDpubkey: 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc
Cnt:ef1ea0000000000001 [1][ 699 ] = 699 MKeys/s x2^31=2^60.45 t:00:46:58

[WanderingPhilospher]

    Could you do a test on this pubkey 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc to display your result when it is possible and if you want of course :-)

Yeah, 76 bit is about the max for a decent time run on a CPU; because of the limits on cores/threads.

I did try implementing a stride function on GPU but can’t figure out what it’s doing wrong.

So then I ran bitcrack with stride function but there are so many limitations. It’s a lot slower than other key cracking software, the code is all over the place, you can only run 1 GPU at a time, no networking feature to share key range, etc.

But I did manage to scan and find keys in a 56 bit range in 11 seconds (nothing great for such a small range) and 60 bit test yielded results between 1 min and 3 mins; depending on where the key lied in relation to the closest thread.

[unclevito]

I wrote a python39 program to analyze patterns and trends and maybe an educated guess . no trends or patterns for 66  but likely output I will post the code on my github "unclevito2017" but here is the prediction for 66.
Next hexadecimal string: 2596c43425ad3bdfa
No pattern detected in input file


import re

def detect_pattern(nums):
    pattern = None
    trend = None
    count = 0
    diff_sum = 0
    for i in range(1, len(nums)):
        diff = int(nums, 16) - int(nums[i-1], 16)
        if pattern is None and i < len(nums) - 1 and nums[i+1:] and nums in nums[i+1:]:
            pattern = nums
        elif pattern is None and i < len(nums) - 2 and nums[i+1:] and nums + nums[i+1] in nums[i+2:]:
            pattern = nums + nums[i+1]
        elif trend is None and diff != 0:
            trend = diff
        elif diff == trend:
            count += 1
            diff_sum += diff
            if count >= 3:
                trend = diff_sum // count
                break
        else:
            trend = None
            count = 0
    return pattern, trend

def predict_next(nums, pattern, trend):
    if pattern is not None:
        if pattern in nums:
            index = nums.index(pattern)
            next_num = nums[index + 1]
            is_pattern = True
        else:
            next_num = pattern
            is_pattern = False
    elif trend is not None:
        next_num = hex(int(nums[-1], 16) + trend)[2:]
        is_pattern = False
    else:
        next_num = max(nums, key=lambda x: nums.count(x))
        is_pattern = False
    return next_num, is_pattern

# read input file
with open('input.txt', 'r') as f:
    nums = re.findall('[0-9a-fA-F]+', f.read())

# detect pattern and trend
pattern, trend = detect_pattern(nums)

# predict next number
next_num, is_pattern = predict_next(nums, pattern, trend)

# write output to files
with open('output.txt', 'w') as f:
    if is_pattern:
        f.write(f"Next hexadecimal string in pattern: {next_num}\n")
    else:
        f.write(f"Next likely hexadecimal string: {next_num}\n")
with open('next.txt', 'w') as f:
    f.write(f"Next hexadecimal string: {next_num}\n")
    if is_pattern:
        f.write("Pattern detected in input file\n")
    else:
        f.write("No pattern detected in input file\n")

[unclevito]

if anyone wants to try it make a input.text file
I filled it with
e9ae4933d6
153869acc5b
2a221c58d8f
6bd3b27c591
e02b35a358f
122fca143c05
2ec18388d544
6cd610b53cba
ade6d7ce3b9b
174176b015f4d
22bd43c2e9354
75070a1a009d4
efae164cb9e3c
180788e47e326c
236fb6d5ad1f43
6abe1f9b67e114
9d18b63ac4ffdf
1eb25c90795d61c
2c675b852189a21
7496cbb87cab44f
fc07a1825367bbe
13c96a3742f64906
363d541eb611abee
7cce5efdaccf6808
f7051f27b09112d4
1a838b13505b26867

[unclevito]

Its probably as good as anyone else's guess lol

[WanderingPhilospher]

Its probably as good as anyone else's guess lol

I can agree with that LOL!

[unclevito]

unique though and the output will vary depending the number of inputs

[Evillo]

Its probably as good as anyone else's guess lol

There's a prediction model based on statistics of previous puzzle keys. It is made by HomelessPhD and kinda sophisticated  The repository is on github if you wanna take a look.

[algorithm32]

Hello
I found this "puzzle" by a student who wondered if it is possible for the keys to be sequential, the answer to this is that it could be possible that a mathematical formula was used for this.

but it is also possible that he only did this:

n=1,256
r(2^n-1))

and then manually modify the values "randomly", It is most likely that he did so.

In short, I would have to investigate with more time, honestly I do not have the computational power to use brute force, but I can give you some statistical advice on this.

1- brute force with large numbers is always better randomly.
I will use the Monty Hall paradox as an example.

Suppose you're on a game show, and you're given the choice of three doors: Behind one door is a car; behind the others, goats. You pick a door, say No. 1, and the host, who knows what's behind the doors, opens another door, say No. 3, which has a goat. He then says to you, "Do you want to pick door No. 2?" Is it to your advantage to switch your choice?



At first the contestant has 1/3 chances, then when the host opens a door and gives you the option to change at first glance it seems that if you would have the same probability but no.

The car has a 1/3 chance of being behind the door chosen by the player. The other door have a probability of 2/3 and not 50%.

This is the reason why at this point in the "puzzle" a random search is always better than staying in a large range.

2- Is human randomness really random?

playing with some statistical algorithms I made calculations that are close to the range where there is a greater probability that the private keys are found.

Pn-                 range                                  found
65-     30580000000000000000         30568377312064202855
66-     61230000000000000000
67-     137500000000000000000
68-     266900000000000000000     
68-     459400000000000000000
69-     520700000000000000000
70-     978700000000000000000        970436974005023690481

Given that the range of the puzzles 65 and 70 of the formula that I use are close to reality, by statistics the ranges 66, 67, 68 and 69 exist the probability of being close to the real result.

if the puzzle creator made manual changes pretending randomness or disassociating from 2^n-1 , he fail because humans are bad at it.
we always tend to repeat sequences unconsciously by association.

exercise:

If I ask you to read 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 and quickly I ask you to say a color without meditating or thinking.
The most likely thing is that you chose the color: "answer at the end of the comment" (don't cheat, just say the numbers and say the first color you think of quickly).

my opinion

I don't know what is the reason for this, it's my first approach to bitcoin, but if the creator is rich enough to do it because I don't just take addresses like mine ( 1HUGxcudaxCdufCaYHRoNadeCa73i3hB2r) randomly and send money?
Does he try to test if bitcoin can be hacked? Does he want to encourage the creation of brute force tools?

Personally, I think it would be more likely to find a back door to the elliptic curve used by satoshi than to brute force 256.

In any case, if I were to do this, I wouldn't do it because my resources are basic.

I would use random numbers in a range


I would search for known public keys to maximize the performance of the code by skipping various processes that slow down the search.


I don't know if I'm wrong because this is a new world for me, if I am, please correct me.

sorry for my English.


answer: RED.

[nc50lc]

I found this "puzzle" by a student who wondered if it is possible for the keys to be sequential, the answer to this is that it could be possible that a mathematical formula was used for this.
-snip-

That's an interesting theory and probably useful with the current bruteforcing tools.
However, the creator of the puzzle already disclosed that there's no solution to the "puzzle" nor made the PrvKeys sequentially.

For reference, here's his only post in the forum (confirmed by most users): https://bitcointalk.org/index.php?topic=1306983.msg18765941#msg18765941
Here's my take on what he meant by "masked with zeroes": https://bitcointalk.org/index.php?topic=1306983.msg61997068#msg61997068

answer: RED.

I answered Green  :D