Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Cricktor]

...

I don't have high hopes that you'll find here someone left besides all the lunatics in this thread and I'm pretty sure @RetiredCoder doesn't waste its time wading through all the noise'n'nonsense. I would be very surprised to see him discuss your questions here as he already expressed his disgust about the situation of this mega-thread.

Unfortunately he has locked his thread Solving ECDLP with Kangaroos: Part 1 + 2 + RCKangaroo which would likely be a more appropriate spot to talk about your findings.

He likely has also blocked newbies to contact him via PM.

You can wait if someone with enough working brain cells like @mcdouglasx or @kTimesG chimes in here. Or you open your own topic in Development & Technical Discussion board.

I don't do active programming and research to optimize search strategies and methods. I'm mostly curious about actually working methods to tackle arbitrarily lowered entropy keys. I also don't believe in wishful ideas to break Bitcoin security. It hasn't been done since 2009 as long as good randomness and entropy were used.

As all the noisers here haven't achieved anything close to any solution of a single puzzle, well, I think it's reasonable to assume it's a waste of time and energy to listen to them. I mean, noisers and loud-mouths, do your thing, at least it's a document in time to prove Bitcoin's and BIP-39's determinism security are fine so far.

[detechs]

...

I don't have high hopes that you'll find here someone left besides all the lunatics in this thread and I'm pretty sure @RetiredCoder doesn't waste its time wading through all the noise'n'nonsense. I would be very surprised to see him discuss your questions here as he already expressed his disgust about the situation of this mega-thread.

Unfortunately he has locked his thread Solving ECDLP with Kangaroos: Part 1 + 2 + RCKangaroo which would likely be a more appropriate spot to talk about your findings.

He likely has also blocked newbies to contact him via PM.

You can wait if someone with enough working brain cells like @mcdouglasx or @kTimesG chimes in here. Or you open your own topic in Development & Technical Discussion board.

I don't do active programming and research to optimize search strategies and methods. I'm mostly curious about actually working methods to tackle arbitrarily lowered entropy keys. I also don't believe in wishful ideas to break Bitcoin security. It hasn't been done since 2009 as long as good randomness and entropy were used.

As all the noisers here haven't achieved anything close to any solution of a single puzzle, well, I think it's reasonable to assume it's a waste of time and energy to listen to them. I mean, noisers and loud-mouths, do your thing, at least it's a document in time to prove Bitcoin's and BIP-39's determinism security are fine so far.

You don't have to post here, you can leave the people trying to solve the puzzles and scroll past. What's wrong with anyone trying to solve puzzles and have fun? It's kind of weird that you posted at all. Just to be negative. If you took the time to test my methods you can verify it all yourself. I'm giving the info freely so anyone can. And I'm going to give more. Wether on this thread or by releasing open source software, it's going to happen. Personally I've only been working on Bitcoin and the puzzles for a little over a month. Imagine how much I'll have learned by the 13th. There is a clear set of people here not happy with other people progressing and it's clear. You can't hide what you found forever. I already know.

[eggsylacer]

...

I don't have high hopes that you'll find here someone left besides all the lunatics in this thread and I'm pretty sure @RetiredCoder doesn't waste its time wading through all the noise'n'nonsense. I would be very surprised to see him discuss your questions here as he already expressed his disgust about the situation of this mega-thread.

Unfortunately he has locked his thread Solving ECDLP with Kangaroos: Part 1 + 2 + RCKangaroo which would likely be a more appropriate spot to talk about your findings.

He likely has also blocked newbies to contact him via PM.

You can wait if someone with enough working brain cells like @mcdouglasx or @kTimesG chimes in here. Or you open your own topic in Development & Technical Discussion board.

I don't do active programming and research to optimize search strategies and methods. I'm mostly curious about actually working methods to tackle arbitrarily lowered entropy keys. I also don't believe in wishful ideas to break Bitcoin security. It hasn't been done since 2009 as long as good randomness and entropy were used.

As all the noisers here haven't achieved anything close to any solution of a single puzzle, well, I think it's reasonable to assume it's a waste of time and energy to listen to them. I mean, noisers and loud-mouths, do your thing, at least it's a document in time to prove Bitcoin's and BIP-39's determinism security are fine so far.

You don't have to post here, you can leave the people trying to solve the puzzles and scroll past. What's wrong with anyone trying to solve puzzles and have fun? It's kind of weird that you posted at all. Just to be negative. If you took the time to test my methods you can verify it all yourself. I'm giving the info freely so anyone can. And I'm going to give more. Wether on this thread or by releasing open source software, it's going to happen. Personally I've only been working on Bitcoin and the puzzles for a little over a month. Imagine how much I'll have learned by the 13th. There is a clear set of people here not happy with other people progressing and it's clear. You can't hide what you found forever. I already know.

I would prefer to call it regression or degradation (because they/you are getting into a topic that you don't have any understanding of.). And please stop getting into this topic and writing all sorts of garbage (especially generated by AI) and show a little respect for other people.

As the person wrote above, create your own topic.

[detechs]

...

I don't have high hopes that you'll find here someone left besides all the lunatics in this thread and I'm pretty sure @RetiredCoder doesn't waste its time wading through all the noise'n'nonsense. I would be very surprised to see him discuss your questions here as he already expressed his disgust about the situation of this mega-thread.

Unfortunately he has locked his thread Solving ECDLP with Kangaroos: Part 1 + 2 + RCKangaroo which would likely be a more appropriate spot to talk about your findings.

He likely has also blocked newbies to contact him via PM.

You can wait if someone with enough working brain cells like @mcdouglasx or @kTimesG chimes in here. Or you open your own topic in Development & Technical Discussion board.

I don't do active programming and research to optimize search strategies and methods. I'm mostly curious about actually working methods to tackle arbitrarily lowered entropy keys. I also don't believe in wishful ideas to break Bitcoin security. It hasn't been done since 2009 as long as good randomness and entropy were used.

As all the noisers here haven't achieved anything close to any solution of a single puzzle, well, I think it's reasonable to assume it's a waste of time and energy to listen to them. I mean, noisers and loud-mouths, do your thing, at least it's a document in time to prove Bitcoin's and BIP-39's determinism security are fine so far.

You don't have to post here, you can leave the people trying to solve the puzzles and scroll past. What's wrong with anyone trying to solve puzzles and have fun? It's kind of weird that you posted at all. Just to be negative. If you took the time to test my methods you can verify it all yourself. I'm giving the info freely so anyone can. And I'm going to give more. Wether on this thread or by releasing open source software, it's going to happen. Personally I've only been working on Bitcoin and the puzzles for a little over a month. Imagine how much I'll have learned by the 13th. There is a clear set of people here not happy with other people progressing and it's clear. You can't hide what you found forever. I already know.

I would prefer to call it regression or degradation (because they/you are getting into a topic that you don't have any understanding of.). And please stop getting into this topic and writing all sorts of garbage (especially generated by AI) and show a little respect for other people.

As the person wrote above, create your own topic.

I'm here talking about BTC puzzles, you other people are the ones regressing.. I'm here helping. You're only here trying to suppress information. This is my topic to be in, I only post about BTC puzzles, where in the rules says I m not allowed and you are? Please stop derailing the btc puzzle topic with your nonsense. Either post facts or rebuttals with proof,  or share information. If you want to hide go somewhere else.  Every negative person never replied with proof I wonder why...

Here's a free seed phrase for everyone so my reply isn't just nonsense as well. I derived it from studying the bitcoin genesis block in binary. Maybe knowing it will help you also, ill send funds to it if I ever get rich so you can try sweep some

dust clay favorite cage absurd level best pride absurd cage beef master donate pool bacon pool agree captain bamboo math doctor captain avoid satoshi

[puzzle_72_worker]

As i see people are trying to send "dust" or how do you call it to BTC address of puzzles in hope that who get's the money will send back to those addresses....Serious???
Difference between hackers that steal and this guys is zero...both categories are hungry for money using cheating and easy methods...
Instead of using brain, some people prefer to get rich by stealing...shame on you people...
BTC puzxles are to use your brain and create/develop, not to steal...

[Ahmedx007]

 Yo, I have been trying my luck on python to solve puzzle  don't judge me as I am Salesforce developer
 I am working on prefix incrementing that I think for it to work i should be extremely lucky does anyone know to increase speed or something  :-


import hashlib
import base58
import ecdsa
addr=['12VVRNPi4SJqUTsp6FmqDqY5sGosDtysn4','1JTK7s9YVYywfm5XUH7RNhHJH1LshCaRFR','1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU']

import random
def decimal_to_compressed_btc_ecdsa(private_key_int):
    """Fastest using ecdsa's C-optimized SECP256k1 implementation"""
    # Convert to bytes
    private_key_bytes = private_key_int.to_bytes(32, 'big')
   
    # Generate compressed public key (C-optimized)
    sk = ecdsa.SigningKey.from_string(private_key_bytes, curve=ecdsa.SECP256k1)
    vk = sk.get_verifying_key()
    compressed_pubkey = b'\x02' + vk.pubkey.point.x().to_bytes(32, 'big') if vk.pubkey.point.y() & 1 == 0 else b'\x03' + vk.pubkey.point.x().to_bytes(32, 'big')
   
    # Hash and encode
    sha256_hash = hashlib.sha256(compressed_pubkey).digest()
    ripemd160 = hashlib.new('ripemd160')
    ripemd160.update(sha256_hash)
    pubkey_hash = ripemd160.digest()
   
    payload = b'\x00' + pubkey_hash
    checksum = hashlib.sha256(hashlib.sha256(payload).digest()).digest()[:4]
   
    return base58.b58encode(payload + checksum).decode()
min=1180591620717411303424
#min=1180591620757415303424
start=1180
#start=2000
end=4722
end=9999
cc=0
k=random.randint(min,min*3)
while True:
   cc=cc+1
   if start>=end:
      start=1180
   
   #   print(jcc)
      k=9999999999999999999999-random.randint(100000000000000000,1000000000000000000)

       
   

   k_str = str(k)   
      
   rest = k_str[4:]  # Get last 6 digits
   k = int(str(start) + rest)  # Replace first 4 digits with start
   if True:

   #      k=k-1
         start = start+1
   
   k=k
   


      
   d=decimal_to_compressed_btc_ecdsa(k)
   print(k,len(str(k)),d)
   if d in addr:
      print('yes')
      
      print(k,d)
      break

[puzzle_72_worker]

@detechs i reduced the space  to 2^64 only. 100% verificable information.

The real problem that my formula cannot go over 5M/s...i need to improve this days.
I've reached searching on 2^40 and i will let over night to see.

If this will be the key, for puzzle 72 will be 2^63.

[kTimesG]

I've been reproducing the SOTA method constants on CPU before committing any GPU budget to #140. Posting the numbers here because I could not find them measured anywhere at this sample size.

Ported RC's Kang-1 to a Linux CLI, ~46k verified solves (R=40, dp=5, 512 kangs):

   Classic   2.066            (published 2.10)
   3-way     1.632            (published 1.60)
   SOTAv1    1.173            (published 1.15)
   SOTAv2    1.141 +/- 0.011  (published 1.15)
   SOTA+     0.997            (published 0.99)

The DP-overhead formula in RCKangaroo, K = 1.15 + (0.07 + 0.76/sqrt(x)) / (1 + 0.30x), matches simulation to under 1.4% across 10 values of x.

The loop statistics in the RCGpuCore.cu comments also check out:
   measured L1S2 = 9.71e-4 vs 1/(2*JMP_CNT) = 9.766e-4 at JMP_CNT=512
   measured L1S4 = 1.0e-6  vs L1S2/1024 = 9.5e-7

One result I did not expect, and I think it is worth stating clearly: K's real dependence is on kangaroo count, not on range.

40-bit is toddler range, that is, it's more like something to experiment over in Python then C/CUDA. At machine/GPU speeds, 40-bits is noise and likely the setup itself is more expensive then the actual solve.

Once you go big you start realizing some facts:

1. If you plan to solve something that has an unclaimed reward using other people's code, think one hundred times.
2. RC's code assumes things about the GPU. 12 or 24 group size optimizes for L2 cache sizes of 4090 and 5090 relative to how memory and thread scheduling are used in his kernels; nothing to do with the algorithm, and definitely not the "this is the best that can ever be achieved because some guy did it like this". As you saw, SOTA+ is clearly better, however RC dumped it because of other reasons, but that doesn't mean the issues he couldn't get past are unresolvable, for a better k without sacrificing the speed.
3. That DP overhead does indeed depend on the number of kangaroos, not on the number of GPUs or on the overall throughput. Sometimes (e.g. without actually thinking through) the DP overhead is larger than the entire "k".
4. That there's around a dozen tradeoffs to be careful about before investing a single penny in computing. GPU models and cost, algorithm to use, probabilities of each strategy, relative throughputs, number of total kangaroos, expected total speed, DP storage throughput, and most importantly, knowing what the freaking code you're actually uploading to production DOES, not blindly running `make` out of some git repo and then wondering why you wasted eight million dollars and nothing was yet found. It's all about the actual ROI at the end of the day.

NB this thread's getting worse and worse by each day. It's impossible to do any meaningful real discussions here, when it's full of delusional bullshit.

[eggsylacer]

...

I don't have high hopes that you'll find here someone left besides all the lunatics in this thread and I'm pretty sure @RetiredCoder doesn't waste its time wading through all the noise'n'nonsense. I would be very surprised to see him discuss your questions here as he already expressed his disgust about the situation of this mega-thread.

Unfortunately he has locked his thread Solving ECDLP with Kangaroos: Part 1 + 2 + RCKangaroo which would likely be a more appropriate spot to talk about your findings.

He likely has also blocked newbies to contact him via PM.

You can wait if someone with enough working brain cells like @mcdouglasx or @kTimesG chimes in here. Or you open your own topic in Development & Technical Discussion board.

I don't do active programming and research to optimize search strategies and methods. I'm mostly curious about actually working methods to tackle arbitrarily lowered entropy keys. I also don't believe in wishful ideas to break Bitcoin security. It hasn't been done since 2009 as long as good randomness and entropy were used.

As all the noisers here haven't achieved anything close to any solution of a single puzzle, well, I think it's reasonable to assume it's a waste of time and energy to listen to them. I mean, noisers and loud-mouths, do your thing, at least it's a document in time to prove Bitcoin's and BIP-39's determinism security are fine so far.

You don't have to post here, you can leave the people trying to solve the puzzles and scroll past. What's wrong with anyone trying to solve puzzles and have fun? It's kind of weird that you posted at all. Just to be negative. If you took the time to test my methods you can verify it all yourself. I'm giving the info freely so anyone can. And I'm going to give more. Wether on this thread or by releasing open source software, it's going to happen. Personally I've only been working on Bitcoin and the puzzles for a little over a month. Imagine how much I'll have learned by the 13th. There is a clear set of people here not happy with other people progressing and it's clear. You can't hide what you found forever. I already know.

I would prefer to call it regression or degradation (because they/you are getting into a topic that you don't have any understanding of.). And please stop getting into this topic and writing all sorts of garbage (especially generated by AI) and show a little respect for other people.

As the person wrote above, create your own topic.

I'm here talking about BTC puzzles, you other people are the ones regressing.. I'm here helping. You're only here trying to suppress information. This is my topic to be in, I only post about BTC puzzles, where in the rules says I m not allowed and you are? Please stop derailing the btc puzzle topic with your nonsense. Either post facts or rebuttals with proof,  or share information. If you want to hide go somewhere else.  Every negative person never replied with proof I wonder why...

Here's a free seed phrase for everyone so my reply isn't just nonsense as well. I derived it from studying the bitcoin genesis block in binary. Maybe knowing it will help you also, ill send funds to it if I ever get rich so you can try sweep some

dust clay favorite cage absurd level best pride absurd cage beef master donate pool bacon pool agree captain bamboo math doctor captain avoid satoshi

Evidence or refutation of what? As the users said above, you're talking outright nonsense. Besides, you don't undertanding what you're talking about at all. If you want to speak the language of fact, then it is your responsibility to provide evidence/facts of what you are saying. But since you're talking nonsense, I dare say there won't be any evidence (The burden of proof is on the approver)

"A map is not a territory" - there is no independent evidence, it is only a hypothesis. Besides, your hypothesis breaks down on the words of the alleged "creator" himself.

[detechs]

@detechs i reduced the space  to 2^64 only. 100% verificable information.

The real problem that my formula cannot go over 5M/s...i need to improve this days.
I've reached searching on 2^40 and i will let over night to see.

If this will be the key, for puzzle 72 will be 2^63.

I'm already at 10m/s on one core of my i5 6600k. If you want my optimisations? I made them specially for my own hardware albut csn port them.

Also since this a btc puzzle thread and the creator did not set any rules for it like some people are claiming.. then I'm going to continue spreading my information I discovered.

Bitcoin whitepaper hash key
Twin SHA-256 of bitcoin.pdf (Satoshi's whitepaper)
Published Oct 31 2008, the declaration of intent
Oddly enough someone has already used these wallets in the past, so twin sha256 is known by other people

Hex key for VisualBTC: 316a938a719b5200d53d3099870bcc8f02365a2d5b27a8ce29468f4a79ba75ac

0x316a938a719b5200d53d3099870bcc8f02365a2d5b27a8ce29468f4a79ba75ac

Address:
12ftye63b2hhJLZXknaw8f4NN3NPZUvGCU (compressed)

Dusted March to April 2026 (1000 sats sent, then swept)


Bonus addresses I found with old transactions that I now have the private keys for:

1MJp4z3ig498hNATfgHBAnLFhwoZpvw118
164qRoL9B3oxAZCn2RS6kAFejJQyAEcjaw

[puzzle_72_worker]

@detechs i repaired my code and now i have 1600M/s for 3080RTX, so is enough. I played with MN_BATCH and now all computations are in GPU.
Just for everybody info I have extra formula that jumps over the unused addresses and hex keys, so there is extra computation in the GPU before doing the HEX to BTC. The hex keys are not going from 1 to 1, and is going from a step that is doing automatic adjust based on address that i search.

And now K timesG will say: SF and reinventing the wheel...nothing smart and nothing theoretical....i am renting some power GPU;s to test the theory and come back...

@detechs i think is better not to share to anyone...a lot of sharks will come to you just to give them formula and get the old wallets with money...


And coming back to tell you the speed:
-using 6 GPU 3060 i have 6874.98 MK/s]
-in 10 minutes i scanned [Total 2^44.33]
-i found [Found 28] 1PWo3JeB

So my scanning per second is 391.128.153.264 addresses.

This is proved by scanning using vanity search by Paul on same range of 44 bits. So i reduced the time of scanning using a formula that is auto adjusting based on what i search.
So to be clear, the searching is not 1 by 1, is 1 by N , auto adjusting based on my formula. All computations are made in GPU. Can word on any architecture RTX 3000,4000,5000,6000 or datacenter cards.
is tested on multiple ranges of 44 bits, so the findings are the same, but the time is lower. The GPU's are not killed, so they have same temp always. Maybe i can improve the speed a little more, but for what is doing the software is perfect.

Maybe is something that i built...maybe not....

[satashi_nokamato]

mcdouglasx

Problem with this kind of challenge is that it doesn't care if you have ideas, it only cares if you have enough resources to search and find the keys.
It would have been much better if it could reward ideas rather than equipment,  but that's the habit of the author,  proof of work by letting the cpu/gpu (asics)  do the work. 

Since the method introduced by mcdouglasx works, not sending him one of the puzzles as his reward would just make him care less about brainstorming for more new ideas.

That's why,  you could be a genius developing and releasing something like BTC, but when it comes to supporting  others with potentials, you'd sit silently  without knowing what to do.

[NUCLEAR7.1]

MARA Opens Slipstream to the Public as Coldcard Victims Race to Escape..  

You now have access to MARA Slipstream.

We've made the service available as a permissionless public good for anyone who needs it, with no client code required.

Additionally, and for the foreseeable future, MARA is not charging any fees on top of the regular network fees for this service. You are responsible only for the appropriate Bitcoin network transaction fee, so please be careful and conservative with your fee selection to make sure your transaction goes through - if competitive rates spike, an underpriced transaction can get stuck in the Slipstream mempool.

Terms and conditions apply to every submission. Please read them in full at slipstream.mara.com before submitting.

Access Slipstream: https://slipstream.mara.com

The MARA Slipstream Team

[detechs]

Yo, I have been trying my luck on python to solve puzzle  don't judge me as I am Salesforce developer
 I am working on prefix incrementing that I think for it to work i should be extremely lucky does anyone know to increase speed or something  :-


import hashlib
import base58
import ecdsa
addr=['12VVRNPi4SJqUTsp6FmqDqY5sGosDtysn4','1JTK7s9YVYywfm5XUH7RNhHJH1LshCaRFR','1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU']

import random
def decimal_to_compressed_btc_ecdsa(private_key_int):
    """Fastest using ecdsa's C-optimized SECP256k1 implementation"""
    # Convert to bytes
    private_key_bytes = private_key_int.to_bytes(32, 'big')
   
    # Generate compressed public key (C-optimized)
    sk = ecdsa.SigningKey.from_string(private_key_bytes, curve=ecdsa.SECP256k1)
    vk = sk.get_verifying_key()
    compressed_pubkey = b'\x02' + vk.pubkey.point.x().to_bytes(32, 'big') if vk.pubkey.point.y() & 1 == 0 else b'\x03' + vk.pubkey.point.x().to_bytes(32, 'big')
   
    # Hash and encode
    sha256_hash = hashlib.sha256(compressed_pubkey).digest()
    ripemd160 = hashlib.new('ripemd160')
    ripemd160.update(sha256_hash)
    pubkey_hash = ripemd160.digest()
   
    payload = b'\x00' + pubkey_hash
    checksum = hashlib.sha256(hashlib.sha256(payload).digest()).digest()[:4]
   
    return base58.b58encode(payload + checksum).decode()
min=1180591620717411303424
#min=1180591620757415303424
start=1180
#start=2000
end=4722
end=9999
cc=0
k=random.randint(min,min*3)
while True:
   cc=cc+1
   if start>=end:
      start=1180
   
   #   print(jcc)
      k=9999999999999999999999-random.randint(100000000000000000,1000000000000000000)

       
   

   k_str = str(k)   
      
   rest = k_str[4:]  # Get last 6 digits
   k = int(str(start) + rest)  # Replace first 4 digits with start
   if True:

   #      k=k-1
         start = start+1
   
   k=k
   


      
   d=decimal_to_compressed_btc_ecdsa(k)
   print(k,len(str(k)),d)
   if d in addr:
      print('yes')
      
      print(k,d)
      break

bugs

- `k_str[4:]` gets everything after first 4 chars, not last 6 digits. use `k_str[-6:]` if you want last 6
- tail set once per cycle, never changes. 8820 keys per random tail, not 8820 × random
- `end=9999` searches prefixes 2362-9999 which are above 2^71. valid prefixes: 1180 to 2361. 75% wasted
- `k = k` on line 59 does nothing
- wrap-around randint gives 9-heavy tails (subtracting from all-9s). all keys look like `1180999...`
- no checkpoint - crash = lose all progress
- `cc` counter incremented but never printed or used


speed

- pure python ecdsa: ~100 keys/s. need millions/s minimum
- string conversion every iteration (`str(k)`, `str(start)`) is slow
- base58 encode on every key is the bottleneck. check hash160 first, only base58 on match
- new SigningKey object every iteration - reuse or use coincurve
- single-threaded. use multiprocessing or a compiled scanner
- 2^70 keys at 100/s = 374 billion years. current CPU python cannot solve p71 with brute force unless you get lucky


replacements

- `ecdsa` → `coincurve` (50,000 keys/s vs 100)
- `base58` → inline only for matches, check hash160 first
- `random.randint` → `secrets.randbits(71)` for direct 71-bit generation
- string concat prefix method → just generate keys in [2^70, 2^71) directly


what actually works for 71-bit

- **KeyHunt** (albert0bsd) - CUDA address mode, range search
- **VanitySearch** (JeanLucPons) - CUDA, prefix matching, billions/sec
- **BitCrack** - OpenCL, AMD support

python CPU search will not finish. 71 bits needs GPU or a direct calculation of the key

[puzzle_72_worker]

I do not want to discurage you, but using quantum simulation for keys, is not doing anything...the best thing is to work on last 4 bits and find a formula as i found.
Of couse everybody is free to test any ideea, but take in count all aspects, all gaps and mathematical limits
.

[bill32767]

If a user is asking for a simple information, why you give more that he asked? At least if you give the private key, give also the address...he needs now to scan again and again wasting power and money....sometimes is a joke for everyone...

There is only 2 addresses with form 1PWo3JeB9jrG for puzzle 71. If the first one is on 4, the second one should be on 60-68.

1PWo3JeB9jrGMLiH83vD775NRqHZMR2hHB
1PWo3JeB9jrGLDTmsp45h1pDXXtb7zisQH
1PWo3JeB9jrGFsveoYdzAukjcwp645X7Zx

SRG02289, please don't feint the comunity.

There are only 2 addresses betweeen puzzle 71's gap 0x400..0x7fff. One of the is solution and another one is 0x4da0aa7f285f61b1c5 = 1PWo3JeB9jrGMLiH83vD775NRqHZMR2hHB.

Other 2 addresses(1PWo3JeB9jrGLDTmsp45h1pDXXtb7zisQH - 1PWo3JeB9jrGFsveoYdzAukjcwp645X7Zx) aren't between the gap 0x400..0x7fff.

How do you like the disclosure of one address in the 7xxxx range?
I can throw dust on another address in the 7xxxx range that hasn't yet been published in this thread.
Three addresses with the prefix 1PWo3JeB9jrG have already been found in the 6xxxx range...
One address in the 5xxxx range...

I feel better SRG02289. Thank a lot!
Could you please share other prefixed addresses and private keys?

1PWo3JeB9jrGWfHDnpdGk54CRaRcbvZeYp in 6xxxx
1PWo3JeB9jrGwPQrSTUVWxyZAARjU29VG2   in 7xxxx

So, they seems like that?

4da0aa7f285f61b1c5 = 1PWo3JeB9jrGMLiH83vD775NRqHZMR2hHB
5xxxxxxxxxxxxxxxxx = 1PWo3JeB9jrGLDTmsp45h1pDXXtb7zisQH
6xxxxxxxxxxxxxxxxx = 1PWo3JeB9jrGWfHDnpdGk54CRaRcbvZeYp
75dfb41bc502e1cf50 = 1PWo3JeB9jrGFsveoYdzAukjcwp645X7Zx
7xxxxxxxxxxxxxxxxx = 1PWo3JeB9jrGwPQrSTUVWxyZAARjU29VG2
?                              = 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU

NO!
1PWo3JeB9jrGLDTmsp45h1pDXXtb7zisQH  79B5402CAD2BBA4D17

1PWo3JeB9jrGAPqRCdeFghiJkMmigGBGmV 5A.... - 5FFF....

1PWo3JeB9jrpyPqE6SjTbwjLYKxKYUoJp5    7f92587dd9bd019205

[jedi12345]

What is the key rate on 5090 these days, have not been on in a year and figured would check back in. Any updates in last 12 months?

[puzzle_72_worker]

5090 without optimisation will get 8500-9000.
If you built your own version you can get 12000-13000.

[IntervalWalker]

As you saw, SOTA+ is clearly better, however RC dumped it because of other reasons, but that doesn't mean the issues he couldn't get past are unresolvable, for a better k without sacrificing the speed.

Fair point on 40 bits. The constant is dimensionless and DPs/kang and NK were pinned precisely so that neither range nor fleet size could leak into it; the range sweep ran to 2^62 and stayed flat (+0.0014/bit). The number that transfers to production is not the 40-bit K, it is the NK saturation curve.

On SOTA+ I cannot make "clearly better" and my own op count agree, so one of them is wrong and I would rather know which.

Measured: SOTAv2 1.141 +/- 0.011 -> SOTA+ 0.997, i.e. -12.6% in K.

Counted against the v4.0 core: a jump is ~5 MUL + 1 SQR, and the cheap point add is +1 MUL + 1 SQR, so roughly +33% per step for -13.9% ops. That is net negative, which is RC's stated conclusion, not yours.

Your phrasing - "for a better k without sacrificing the speed" - implies the +33% is not mandatory. That is the part I cannot reconstruct from the source. Is the cheap add amortised into the batched inversion in a way the naive count misses, or is it a different construction than the one described in the v3.x notes?

Happy to publish the CLI harness and the 331k-sample dataset if anyone wants to re-run it.

[puzzle_72_worker]

Guys, if you get the source code from RC or from paul and you put CHAT GPT to change the code and to give a ideea of implementation, this do not means that is correct.
You did analysis of the code using AI, you got a point of view and a ideea how the AI is seeing the problem and you come here to this forum to present to everybody how smart you are....
Are you selling flowers to the gardner?
If you want to improve something, get a new method  of encoding or apply all the math formulas .... learn the architecture of a GPU and see how you can improve the speed....