Bitcoin Forum
October 29, 2026, 09:19:45 AM *
News: Latest Bitcoin Core release: 31.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 [700] 701 »
  Print  
Author Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it  (Read 415795 times)
demonarcher360
Newbie
*
Offline

Activity: 3
Merit: 0


View Profile
October 17, 2026, 12:56:44 AM
 #13981

What are the best public puzzle pools for scanning puzzle 71?

Does anyone have the link to work on it?

thank you
cicada 3301
Newbie
*
Offline

Activity: 26
Merit: 0


View Profile
October 22, 2026, 06:52:43 PM
Last edit: October 22, 2026, 09:06:17 PM by Mr. Big
 #13982

So, Satoshi, Nakomoto. Damn genius, he created, a seed generator to manage all wallets, divided everything into different baskets, he used, extremely advanced mathematics, BIP39 dictionary. and a lot of linguistic and dictionary jokes, and also used, time, for encryption. 256 wallets, that here they are not the main goal now mine, my goal is to break the bank, all Satoshi wallets are Nakomoto, 1.1 million BTC. The first 7 words I have already discovered, but in the generator there is more of them assumption 30-36 and maybe 18 I don't know I'm at the refining stage. And yes, I know who Satoshi Nakamoto is. A hint for all RING. The second joke, he created a BIP 39 dictionary in ancient Hebrew. Only for himself. So this is additional protection. Strangely, not a single Satoshi Nakamoto wallet was ever hacked.



secp256k1 can't be hacked, since it's just a projection of a more complex equation. So I'm telling you bluntly that Satoshi Nakamoto was behind the creation of secp256k1. He's a genius of mathematics. No doubt, sensei.
fecell
Jr. Member
*
Offline

Activity: 197
Merit: 2


View Profile
October 23, 2026, 12:43:58 PM
 #13983

secp256k1 can't be hacked
Don't be so sure.
There are many tricks involving this curve. At some point, a combination of them - or perhaps a new property - will bring an end to it. This is both obvious and predictable.
detechs
Jr. Member
*
Offline

Activity: 92
Merit: 1


View Profile WWW
October 23, 2026, 06:15:10 PM
 #13984

So, Satoshi, Nakomoto. Damn genius, he created, a seed generator to manage all wallets, divided everything into different baskets, he used, extremely advanced mathematics, BIP39 dictionary. and a lot of linguistic and dictionary jokes, and also used, time, for encryption. 256 wallets, that here they are not the main goal now mine, my goal is to break the bank, all Satoshi wallets are Nakomoto, 1.1 million BTC. The first 7 words I have already discovered, but in the generator there is more of them assumption 30-36 and maybe 18 I don't know I'm at the refining stage. And yes, I know who Satoshi Nakamoto is. A hint for all RING. The second joke, he created a BIP 39 dictionary in ancient Hebrew. Only for himself. So this is additional protection. Strangely, not a single Satoshi Nakamoto wallet was ever hacked.



secp256k1 can't be hacked, since it's just a projection of a more complex equation. So I'm telling you bluntly that Satoshi Nakamoto was behind the creation of secp256k1. He's a genius of mathematics. No doubt, sensei.

A lot of assumptions there, you sure it's bip39? And not something like bip42? Why don't you just ring up saatoshi and ask them for the generator? Wouldn't that be easier since you say you know who it is?

Bitcoin Puzzle Solvers Discord https://discord.gg/3TVn3PGYtu
cicada 3301
Newbie
*
Offline

Activity: 26
Merit: 0


View Profile
October 24, 2026, 02:44:02 AM
 #13985

So, Satoshi, Nakomoto. Damn genius, he created, a seed generator to manage all wallets, divided everything into different baskets, he used, extremely advanced mathematics, BIP39 dictionary. and a lot of linguistic and dictionary jokes, and also used, time, for encryption. 256 wallets, that here they are not the main goal now mine, my goal is to break the bank, all Satoshi wallets are Nakomoto, 1.1 million BTC. The first 7 words I have already discovered, but in the generator there is more of them assumption 30-36 and maybe 18 I don't know I'm at the refining stage. And yes, I know who Satoshi Nakamoto is. A hint for all RING. The second joke, he created a BIP 39 dictionary in ancient Hebrew. Only for himself. So this is additional protection. Strangely, not a single Satoshi Nakamoto wallet was ever hacked.



secp256k1 can't be hacked, since it's just a projection of a more complex equation. So I'm telling you bluntly that Satoshi Nakamoto was behind the creation of secp256k1. He's a genius of mathematics. No doubt, sensei.

A lot of assumptions there, you sure it's bip39? And not something like bip42? Why don't you just ring up saatoshi and ask them for the generator? Wouldn't that be easier since you say you know who it is?


Let's do it differently, when the puzzle was created, the second when it was created, bip 42, and the third Rings. And it turned out to be not 18, 24, 36, but 54 words in the cryptographic generator. I've already restored them all, again secp256k1 can't be hacked. But Bitcoin Puzzle is the thread that gives access to a legal exit to how Satoshi thinks. And it's obvious that I'm the new Satoshi. I also have the original client, 0.1.0 BTC. I remade the yoke for Linux, all that remains is to assemble. And punch through, and it's already the 13th week of my Bitcon Puzzle marathon, and I'll answer right away, I'll take 71-74 wallets to try the pen, I won't touch the rest. 76-160. satoshi, used odd-numbered public keys when creating wallets.
brainless
Member
**
Offline

Activity: 506
Merit: 46


View Profile
October 24, 2026, 04:12:41 AM
 #13986

So, Satoshi, Nakomoto. Damn genius, he created, a seed generator to manage all wallets, divided everything into different baskets, he used, extremely advanced mathematics, BIP39 dictionary. and a lot of linguistic and dictionary jokes, and also used, time, for encryption. 256 wallets, that here they are not the main goal now mine, my goal is to break the bank, all Satoshi wallets are Nakomoto, 1.1 million BTC. The first 7 words I have already discovered, but in the generator there is more of them assumption 30-36 and maybe 18 I don't know I'm at the refining stage. And yes, I know who Satoshi Nakamoto is. A hint for all RING. The second joke, he created a BIP 39 dictionary in ancient Hebrew. Only for himself. So this is additional protection. Strangely, not a single Satoshi Nakamoto wallet was ever hacked.



secp256k1 can't be hacked, since it's just a projection of a more complex equation. So I'm telling you bluntly that Satoshi Nakamoto was behind the creation of secp256k1. He's a genius of mathematics. No doubt, sensei.

A lot of assumptions there, you sure it's bip39? And not something like bip42? Why don't you just ring up saatoshi and ask them for the generator? Wouldn't that be easier since you say you know who it is?


Let's do it differently, when the puzzle was created, the second when it was created, bip 42, and the third Rings. And it turned out to be not 18, 24, 36, but 54 words in the cryptographic generator. I've already restored them all, again secp256k1 can't be hacked. But Bitcoin Puzzle is the thread that gives access to a legal exit to how Satoshi thinks. And it's obvious that I'm the new Satoshi. I also have the original client, 0.1.0 BTC. I remade the yoke for Linux, all that remains is to assemble. And punch through, and it's already the 13th week of my Bitcon Puzzle marathon, and I'll answer right away, I'll take 71-74 wallets to try the pen, I won't touch the rest. 76-160. satoshi, used odd-numbered public keys when creating wallets.
Have you study Bitcoin ver 1 client and minner at cpu,, only one static connection to 1 node, IP is Brazil university, and who were doing PhD in mathematics in 1998, who were working on secp256k1, ecc,  who were traveling to Japan in 2007,
Hope you will study more in deep

13sXkWqtivcMtNGQpskD78iqsgVy9hcHLF
klaxis
Newbie
*
Offline

Activity: 4
Merit: 0


View Profile
October 24, 2026, 03:03:37 PM
 #13987

Bitcrack KMS Pool is open for Bitcoin Puzzle 71 workers.

We’re combining NVIDIA GPU work to search separate portions of Puzzle 71’s public key range. The pool assigns work units, tracks each worker’s completed search, and reassigns unfinished work when a worker disconnects.

Target: 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU
Search range: 0x400000000000000000–0x7fffffffffffffffff (inclusive)
Live dashboard: http://99.8.222.129:3001/
Agent download: https://github.com/klaxis/KMC-Miner-Pool/releases/latest

Reward policy
If the puzzle is solved, the pool fee is 15% of the recovered reward. The remaining 85% goes to participating miners, divided pro rata by the number of keys each miner searched, as recorded by the pool. There is no payout unless the puzzle is solved.

How to join
Download the Windows agent ZIP for your NVIDIA GPU from the release page and extract it. In PowerShell, run this from the extracted folder:

Code:
.\kmc-agent.exe --address YOUR_BTC_ADDRESS --worker Rig01 --pool 99.8.222.129:3333

Use your own Bitcoin address for worker accounting, not the puzzle target address. Give each rig a distinct worker name. The dashboard uses port 3001; the agent connects on port 3333.

Before contributing GPU time
This is a keyspace search, not Bitcoin block mining. Finding the key is uncertain, and running an agent does not guarantee a reward. If an agent finds a matching private key, it sends that key to the pool operator; the agent does not keep a local copy. The current agent connection uses plain TCP without built-in TLS.

Questions and feedback are welcome here.
cicada 3301
Newbie
*
Offline

Activity: 26
Merit: 0


View Profile
October 24, 2026, 06:34:58 PM
 #13988

Bitcrack KMS Pool is open for Bitcoin Puzzle 71 workers.

We’re combining NVIDIA GPU work to search separate portions of Puzzle 71’s public key range. The pool assigns work units, tracks each worker’s completed search, and reassigns unfinished work when a worker disconnects.

Target: 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU
Search range: 0x400000000000000000–0x7fffffffffffffffff (inclusive)
Live dashboard: http://99.8.222.129:3001/
Agent download: https://github.com/klaxis/KMC-Miner-Pool/releases/latest

Reward policy
If the puzzle is solved, the pool fee is 15% of the recovered reward. The remaining 85% goes to participating miners, divided pro rata by the number of keys each miner searched, as recorded by the pool. There is no payout unless the puzzle is solved.

How to join
Download the Windows agent ZIP for your NVIDIA GPU from the release page and extract it. In PowerShell, run this from the extracted folder:

Code:
.\kmc-agent.exe --address YOUR_BTC_ADDRESS --worker Rig01 --pool 99.8.222.129:3333

Use your own Bitcoin address for worker accounting, not the puzzle target address. Give each rig a distinct worker name. The dashboard uses port 3001; the agent connects on port 3333.

Before contributing GPU time
This is a keyspace search, not Bitcoin block mining. Finding the key is uncertain, and running an agent does not guarantee a reward. If an agent finds a matching private key, it sends that key to the pool operator; the agent does not keep a local copy. The current agent connection uses plain TCP without built-in TLS.

Questions and feedback are welcome here.


and how does this differ from simple bitcoin mining, if the mining efficiency is higher than mining a private key.  and in the github code? download the trash archive, it's not even clear what language it's written in. in short, an ordinary bot farm created for idiots. who are chasing gold "fool's gold"  | `--address ADDR` | Valid Bitcoin address used for accounting; required for mining | — |
| `--worker NAME` | Worker identifier; required for mining | — |
| `--pool HOST:PORT` | KMC Pool TCP endpoint | `127.0.0.1:3333` |
| `-d`, `--device ID` | CUDA device ID | `0` |
| `-b`, `--blocks N` | CUDA grid blocks | `32` |
| `-t`, `--threads N` | CUDA threads per block | `256` |
| `-p`, `--points N` | CUDA points per thread | `32` |
| `-f`, `--follow` | Print each progress update on a new line | Off |
| `--list-devices` | List CUDA devices and exit; no address or worker needed | — |
| `-v`, `--version` | Print version and exit | — |
| `-h`, `--help` | Print built-in help and exit | — | In short, you're suggesting installing a bitcoin miner on your PC. I think I'll decline.
vadimkotvickij190
Newbie
*
Offline

Activity: 1
Merit: 0


View Profile
October 24, 2026, 07:07:24 PM
 #13989

Wow, so much time has passed! I remember being in university when people were talking about this puzzle, but back then, there weren't any PCs with powerful enough graphics cards to solve it quickly. Looking at it now, technology has advanced significantly.
klaxis
Newbie
*
Offline

Activity: 4
Merit: 0


View Profile
October 24, 2026, 09:03:31 PM
 #13990

Bitcrack KMS Pool is open for Bitcoin Puzzle 71 workers.

We’re combining NVIDIA GPU work to search separate portions of Puzzle 71’s public key range. The pool assigns work units, tracks each worker’s completed search, and reassigns unfinished work when a worker disconnects.

Target: 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU
Search range: 0x400000000000000000–0x7fffffffffffffffff (inclusive)
Live dashboard: http://99.8.222.129:3001/
Agent download: https://github.com/klaxis/KMC-Miner-Pool/releases/latest

Reward policy
If the puzzle is solved, the pool fee is 15% of the recovered reward. The remaining 85% goes to participating miners, divided pro rata by the number of keys each miner searched, as recorded by the pool. There is no payout unless the puzzle is solved.

How to join
Download the Windows agent ZIP for your NVIDIA GPU from the release page and extract it. In PowerShell, run this from the extracted folder:

Code:
.\kmc-agent.exe --address YOUR_BTC_ADDRESS --worker Rig01 --pool 99.8.222.129:3333

Use your own Bitcoin address for worker accounting, not the puzzle target address. Give each rig a distinct worker name. The dashboard uses port 3001; the agent connects on port 3333.

Before contributing GPU time
This is a keyspace search, not Bitcoin block mining. Finding the key is uncertain, and running an agent does not guarantee a reward. If an agent finds a matching private key, it sends that key to the pool operator; the agent does not keep a local copy. The current agent connection uses plain TCP without built-in TLS.

Questions and feedback are welcome here.


and how does this differ from simple bitcoin mining, if the mining efficiency is higher than mining a private key.  and in the github code? download the trash archive, it's not even clear what language it's written in. in short, an ordinary bot farm created for idiots. who are chasing gold "fool's gold"  | `--address ADDR` | Valid Bitcoin address used for accounting; required for mining | — |
| `--worker NAME` | Worker identifier; required for mining | — |
| `--pool HOST:PORT` | KMC Pool TCP endpoint | `127.0.0.1:3333` |
| `-d`, `--device ID` | CUDA device ID | `0` |
| `-b`, `--blocks N` | CUDA grid blocks | `32` |
| `-t`, `--threads N` | CUDA threads per block | `256` |
| `-p`, `--points N` | CUDA points per thread | `32` |
| `-f`, `--follow` | Print each progress update on a new line | Off |
| `--list-devices` | List CUDA devices and exit; no address or worker needed | — |
| `-v`, `--version` | Print version and exit | — |
| `-h`, `--help` | Print built-in help and exit | — | In short, you're suggesting installing a bitcoin miner on your PC. I think I'll decline.



KMC Agent was built after BitCrack to run the key search on newer NVIDIA GPUs. It uses CUDA 13.4, and RTX 30, 40, and 50 series builds are already released. The pool assigns a target address and a bounded key range; the agent searches that range, reports progress, and requests another. This is different from Bitcoin block mining, so keys per second and mining hash rates are not comparable.
Your concern about the download is fair. The released agent is closed source, and a found key is sent to the pool owner. The --address option currently identifies a miner for accounting; it does not trigger an automatic payout. Work is underway on an Electrum-based payment processor intended to send rewards promptly to miners if a key is found, but that feature is not live yet. I understand why you would decline to run the agent in its current form.
decruptor
Newbie
*
Offline

Activity: 2
Merit: 0


View Profile
October 24, 2026, 09:12:07 PM
 #13991

First classical solve on the "Brace for impact" ECDLP ladder: rung 80

The ladder from arXiv:2508.14011 ("Brace for impact: ECDLP challenges for quantum cryptanalysis") publishes 20 secpKKk1-style instances meant to demonstrate quantum advantage. Rung 80 is now solved classically.

Verification (secp80k1, p = 2^80 − 8259, n = 1208925819612459780337609):

P = 030D08430A6C00FAE05651
Q = 02CF45D656507F3699875E
kappa = 0x27f35e126a10e6e7d3d4

Check: P = [kappa]Q. Ten lines of Python on any laptop; no trust required.

Notes for anyone reproducing:
- The kappa is full-range (kappa in [1, n-1]) — these cards are NOT interval-restricted like the 2019 puzzle transaction, so the right tool is parallel Pollard rho with distinguished points, not a kangaroo.
- Hardware: one consumer-class GPU. Wall time: ~31 minutes at ~0.88 billion group operations/s (expected cost = 1.25*sqrt(n) = 1.4e12 ops; this run drew 1.19x).
- The GPU result was validated bit-for-bit against an independent CPU reference build before trusting any counters — worth doing after we hit a silent compiler miscompile on the new architecture that corrupted walk states while looking perfectly healthy at the PTX level.

Higher rungs are in progress. Kappa verification files will be published as the ladder falls.

https://github.com/decruptor/ecdlp-ladder  (verification file: result_80.json)

— Decruptor
cicada 3301
Newbie
*
Offline

Activity: 26
Merit: 0


View Profile
October 25, 2026, 02:33:04 AM
Last edit: October 25, 2026, 10:17:41 AM by Mr. Big
 #13992

First classical solve on the "Brace for impact" ECDLP ladder: rung 80

The ladder from arXiv:2508.14011 ("Brace for impact: ECDLP challenges for quantum cryptanalysis") publishes 20 secpKKk1-style instances meant to demonstrate quantum advantage. Rung 80 is now solved classically.

Verification (secp80k1, p = 2^80 − 8259, n = 1208925819612459780337609):

P = 030D08430A6C00FAE05651
Q = 02CF45D656507F3699875E
kappa = 0x27f35e126a10e6e7d3d4

Check: P = [kappa]Q. Ten lines of Python on any laptop; no trust required.

Notes for anyone reproducing:
- The kappa is full-range (kappa in [1, n-1]) — these cards are NOT interval-restricted like the 2019 puzzle transaction, so the right tool is parallel Pollard rho with distinguished points, not a kangaroo.
- Hardware: one consumer-class GPU. Wall time: ~31 minutes at ~0.88 billion group operations/s (expected cost = 1.25*sqrt(n) = 1.4e12 ops; this run drew 1.19x).
- The GPU result was validated bit-for-bit against an independent CPU reference build before trusting any counters — worth doing after we hit a silent compiler miscompile on the new architecture that corrupted walk states while looking perfectly healthy at the PTX level.

Higher rungs are in progress. Kappa verification files will be published as the ladder falls.

https://github.com/decruptor/ecdlp-ladder  (verification file: result_80.json)

— Decruptor

article, garbage. literally. What should I crack, a projection?  You're really assholes. arXiv in order to find a single piece of music that has been sucked out of your finger.  literally, there is nothing interesting there, for me, as a source of knowledge, it is garbage, "compression of the curve to 2^80", those who wrote this article just made a reformulation.  ""The Bitcoin curve is y^2=x ^3+ 7 modulo p with a gradual decrease in the main field from 256 to 6 bits.""



All challenges are generated by a deterministic, reproducible procedure, and no private challenge scalar is chosen in advance. We calibrate classical cost against Pollard's rho records and quantum cost against resource estimation results for Shor's algorithm.

Pierre-Luc Dallaire-Demers, William Doyle, Timothy Foo These are not scientists, they are plagiarists.

and without Shor's algorithm, are you capable of anything? in general, the method of blind brute force, on a compressed curve. literally a pack of rabid dogs.  



So, Satoshi, Nakomoto. Damn genius, he created, a seed generator to manage all wallets, divided everything into different baskets, he used, extremely advanced mathematics, BIP39 dictionary. and a lot of linguistic and dictionary jokes, and also used, time, for encryption. 256 wallets, that here they are not the main goal now mine, my goal is to break the bank, all Satoshi wallets are Nakomoto, 1.1 million BTC. The first 7 words I have already discovered, but in the generator there is more of them assumption 30-36 and maybe 18 I don't know I'm at the refining stage. And yes, I know who Satoshi Nakamoto is. A hint for all RING. The second joke, he created a BIP 39 dictionary in ancient Hebrew. Only for himself. So this is additional protection. Strangely, not a single Satoshi Nakamoto wallet was ever hacked.



secp256k1 can't be hacked, since it's just a projection of a more complex equation. So I'm telling you bluntly that Satoshi Nakamoto was behind the creation of secp256k1. He's a genius of mathematics. No doubt, sensei.

A lot of assumptions there, you sure it's bip39? And not something like bip42? Why don't you just ring up saatoshi and ask them for the generator? Wouldn't that be easier since you say you know who it is?


Let's do it differently, when the puzzle was created, the second when it was created, bip 42, and the third Rings. And it turned out to be not 18, 24, 36, but 54 words in the cryptographic generator. I've already restored them all, again secp256k1 can't be hacked. But Bitcoin Puzzle is the thread that gives access to a legal exit to how Satoshi thinks. And it's obvious that I'm the new Satoshi. I also have the original client, 0.1.0 BTC. I remade the yoke for Linux, all that remains is to assemble. And punch through, and it's already the 13th week of my Bitcon Puzzle marathon, and I'll answer right away, I'll take 71-74 wallets to try the pen, I won't touch the rest. 76-160. satoshi, used odd-numbered public keys when creating wallets.
Have you study Bitcoin ver 1 client and minner at cpu,, only one static connection to 1 node, IP is Brazil university, and who were doing PhD in mathematics in 1998, who were working on secp256k1, ecc,  who were traveling to Japan in 2007,
Hope you will study more in deep



brainless
Member
**


Activity: 506
Merit: 46 There’s nothing to comment on here; you’re really brainless.
decruptor
Newbie
*
Offline

Activity: 2
Merit: 0


View Profile
October 26, 2026, 05:02:05 PM
 #13993

Rung 96 of the "Brace for impact" ECDLP ladder (arXiv:2508.14011) is solved classically — our largest published card to date, following rung 80.

Verification (secp96k1, p = 2^96 − 7245, n = 79228162514264890447722092359):

P = 029E1F276C17BCE3D8DF9D22BB
Q = 03CCF37E1E144A24433C0582A6
kappa = 0xd80a4bdb34ee0494d6543463

Check: P = [kappa]Q. Ten lines of Python on any laptop; no trust required.

Notes for anyone reproducing:
- Full range again (kappa in [1, n-1]) — these cards are NOT interval-restricted, so the right tool is parallel Pollard rho with distinguished points, same solver family as rung 80.
- Hardware: one RTX 4090 (rented cloud instance) — one of 12 independent workers run in parallel with different seeds. Wall time: ≈ 3.7 h at 3.56 G group operations/s (expected cost = 1.25*sqrt(n) = 3.518·10^14 ops; this run drew 0.13×).
- Verified twice independently: the solver's own collision algebra (verify_kappa) and a from-scratch pure-Python EC replay with no shared code.

The verification file (result_96.json) is in the repo next to result_48/64/80. The full write-up — solutions, the ladder's classical cost curve, and a silent nvcc miscompile case study — is being prepared for ePrint.

https://github.com/decruptor/ecdlp-ladder  (verification file: result_96.json)

— Decruptor
Efim_Wr
Newbie
*
Offline

Activity: 6
Merit: 0


View Profile
October 26, 2026, 06:02:11 PM
 #13994

I wrote a small browser-based utility to help with understanding elliptic curves; perhaps someone will find it useful.
Download the file secp256k1Visual.html and open it in your browser.
https://drive.google.com/file/d/1R3gJtvnZYdTuCiKeNnKAYSufardzG0mm/view?usp=sharing
btc11235
Jr. Member
*
Offline

Activity: 40
Merit: 1


View Profile
October 27, 2026, 10:54:39 PM
Last edit: October 28, 2026, 02:57:39 AM by btc11235
 #13995

Ok, I could really use some help here...

I'm trying to learn Keyhunt's xpoint mode, and the `tests/substracted40.txt` file has these two lines that I've been using for testing my own code:

Code:
03a2efa402fd5268400c77c20e574ba86409ededee7c4020e4b9f0edbee53de0d4 # target
029626454cd0d154c91e174fc9b0967adf6749e5f94ed8ed462f13709120716be7 # + 3214927

I've confirmed that the 'target' key is indeed Puzzle 40's compressed public key, so that's right.

The problem is when I try to generate the other key myself... I'm getting different results from all three methods I've tried...

I have the code below in C# using the NBitcoin library, and the Secp256k1.Net library (both available on Nuget), and in Python using the ICE library, and here are the results I'm getting:

Code:
From Keyhunt:   029626454cd0d154c91e174fc9b0967adf6749e5f94ed8ed462f13709120716be7
From NBitcoin:  039626454cd0d154c91e174fc9b0967adf6749e5f94ed8ed462f13709120716be7
From Secp256k1: 02badda947ee2165bfa66ddcbea05deb1385fa551dd7673d48aa9bfddaaa1201a1
From Ice:       02badda947ee2165bfa66ddcbea05deb1385fa551dd7673d48aa9bfddaaa1201a1

You can see that the NBitcoin result is the same as Keyhunt's, but with an '03' prefix instead of '02'. And the Secp256k1.Net library and Ice both give the same completely different result.

So either:

A) Keyhunt's example is right, which means I'm close with my NBitcoin code, but somehow wildly off with the other two, and in exactly the same way for both.

B) Keyhunt's example is actually wrong, but if that's the case then I have no way to know if the two results from Secp256k1.Net and Ice actually are the correct ones, or how I got nearly the same wrong result with my NBitcoin code.

I'm now pretty far out of my depth here, so any help would be greatly appreciated!

-----
Edit: Had a burst of inspiration after walking away from my computer for a bit: I'd completely forgotten that the Ice library seems to only want to work with full, uncompressed public keys (or, at least, that was the only way I could make it work)... So I grabbed that key (after converting the compressed, x-only key with `ice.pub2upub()`) and fed that into both NBitcoin (as an `ECPubKey` object, instead of the `ECXOnlyPubKey` object) and into Secp256k1.Net, and here's what I got:

Ice: Only deals with the uncompressed pubkey, returns the "02badda..." result
NBitcoin: Now returns the same "02badda..." result, when given the uncompressed key
Secp256k1.Net: Returns the "02badda..." result no matter if I pass it the compressed or uncompressed pubkey (so I'm assuming it converts the compressed into the uncompressed behind the scenes)

So, when I do the point-addition maths (or point-multiplication? I'm still not certain which I'm doing, or are they two terms that both mean the same thing?) on the x-only key, I get the same result as in the Keyhunt example (though I'm still not sure why I get a '03' prefix instead of '02')... but when I do it on the uncompressed key, I get the "02badda..." result...

So, which is right? Are they both technically right, but Keyhunt only expects the maths to be done on the x-only key? So, if I were writing my own code (and not actually feeding these keys to Keyhunt), could I use either one, just so long as I'm consistent?

To be clear, I'm trying to essentially emulate Keyhunt's xpoint mode, so in the end I need to be able to go from the known pubkey, to a modified pubkey (+/- some amount on the x coord), and then if I get a hit, I have to be able to reverse the +/- maths on the private key... So I guess the real question is: Can I reverse either method? Or does the reversing only work when modifying the compressed x-only key, not the full uncompressed key? Or, thinking about it more, what I now fear is that modifying the uncompressed key is modifying both the x and y coords; and in that case I'd never even get a hit, right?

I'll try to work-out a way to test this tomorrow, but if anyone can provide any insights in the meantime, I'd really appreciate it.
-----

Code:
// NBitcoin in C#

var target = "03a2efa402fd5268400c77c20e574ba86409ededee7c4020e4b9f0edbee53de0d4";
uint num = 3214927;

// Parse the x-only compressed public key
var nbPubKeyX = NBitcoin.Secp256k1.ECXOnlyPubKey.Create(Convert.FromHexString(target.Substring(2)));

// Convert the uint to 32 bytes (big-endian)
Span<byte> tweakBytes = stackalloc byte[32];
BitConverter.GetBytes(num).Reverse().ToArray().AsSpan().CopyTo(tweakBytes.Slice(28));

// AddTweak computes: publicKey + (G × tweak)
var tweakedPubKey = nbPubKeyX.AddTweak(tweakBytes);

// Convert back to x-only bytes and format as hex
var resultHex = Convert.ToHexStringLower(tweakedPubKey.ToXOnlyPubKey().ToBytes());

Code:
// Secp256k1.Net in C#

var target = "03a2efa402fd5268400c77c20e574ba86409ededee7c4020e4b9f0edbee53de0d4";
uint num = 3214927;

// Parse the x-only compressed public key
var nbPubKeyX = NBitcoin.Secp256k1.ECXOnlyPubKey.Create(Convert.FromHexString(target.Substring(2)));

// Convert the uint to 32 bytes (big-endian)
Span<byte> tweakBytes = stackalloc byte[32];
BitConverter.GetBytes(num).Reverse().ToArray().AsSpan().CopyTo(tweakBytes.Slice(28));

// AddTweak computes: publicKey + (G × tweak)
// Compute G × tweak using precomputed tables (fast!)
var tweak = new NBitcoin.Secp256k1.Scalar(tweakBytes, out var overflow);
var ctx = NBitcoin.Secp256k1.Context.Instance;
var tweakG = ctx.EcMultContext.Mult(NBitcoin.Secp256k1.GEJ.Infinity, NBitcoin.Secp256k1.Scalar.Zero, tweak);

// Add public key to (G × tweak)
var pkJacobian = nbPubKeyX.Q.ToGroupElementJacobian();
var resultJacobian = pkJacobian.AddVariable(tweakG, out _);

// Extract x-coordinate
var result = resultJacobian.ToGroupElement();
Span<byte> xBytes = stackalloc byte[32];
result.x.WriteToSpan(xBytes);

// Convert back to x-only bytes and format as hex
var resultHex = Convert.ToHexStringLower(xBytes);

Code:
// Ice in Python

import secp256k1 as ice

target_hex = "03a2efa402fd5268400c77c20e574ba86409ededee7c4020e4b9f0edbee53de0d4"
scalar = 3214927

# Convert compressed pubkey to uncompressed point (65 bytes)
target_point = ice.pub2upub(target_hex)

# Calculate G * scalar
g_times_scalar = ice.scalar_multiplication(scalar)

# Add the two points: target + (G * scalar)
result_point = ice.point_addition(target_point, g_times_scalar)

# Convert back to compressed format
result_hex = ice.point_to_cpub(result_point)
Niekko
Member
**
Offline

Activity: 180
Merit: 71


View Profile
October 28, 2026, 04:58:03 AM
 #13996

The problem is when I try to generate the other key myself... I'm getting different results from all three methods I've tried...


Look the albertobsd's keysubtracter

https://github.com/albertobsd/keysubtracter



And24r
Newbie
*
Offline

Activity: 38
Merit: 0


View Profile
October 28, 2026, 04:10:49 PM
 #13997

secp256k1 can't be hacked
Don't be so sure.
There are many tricks involving this curve. At some point, a combination of them - or perhaps a new property - will bring an end to it. This is both obvious and predictable.
I’ve been reading this forum for a long time. Why are there so few mathematical ideas on the forum? After all, everything is built on the formulas for adding points on a curve. For example, for the curve y^2=x^3, the point number is easy to find.

Also, there is a formula that shows where a point is located on the curve y^2=x^3+7: it is (y/x)^2-x = A.

There is also a formula that introduces a correction for point doubling: you double the point and get an answer with a correction; this answer will already correspond to a point on the curve y^2=x^3, and you can find the point’s number. But this works only for doubling. There is no such formula yet for the point addition formula.

Please share your ideas with formulas. It is in mathematics that the curve has the greatest vulnerability.
napros
Newbie
*
Offline

Activity: 33
Merit: 0


View Profile
October 28, 2026, 04:24:32 PM
 #13998

secp256k1 can't be hacked
Don't be so sure.
There are many tricks involving this curve. At some point, a combination of them - or perhaps a new property - will bring an end to it. This is both obvious and predictable.
I’ve been reading this forum for a long time. Why are there so few mathematical ideas on the forum? After all, everything is built on the formulas for adding points on a curve. For example, for the curve y^2=x^3, the point number is easy to find.

Also, there is a formula that shows where a point is located on the curve y^2=x^3+7: it is (y/x)^2-x = A.

There is also a formula that introduces a correction for point doubling: you double the point and get an answer with a correction; this answer will already correspond to a point on the curve y^2=x^3, and you can find the point’s number. But this works only for doubling. There is no such formula yet for the point addition formula.

Please share your ideas with formulas. It is in mathematics that the curve has the greatest vulnerability.

Because unless you’ve got a maths degree, any idea you post gets shot down as stupid. The only way to learn is to ask, but ask it the “wrong” way and you cop the same thing. Too many here don’t actually listen. They’ve already decided they know best, and that’s backwards. The whole point of a forum is to hear people out, especially the ones still learning.

I’ve been shot down plenty of times just for asking or replying.

So to the know-it-alls: show some respect. Treat people who ask the way you’d want to be treated yourself.
demonarcher360
Newbie
*
Offline

Activity: 3
Merit: 0


View Profile
October 28, 2026, 04:53:23 PM
Last edit: Today at 08:23:30 AM by Mitchell
 #13999

secp256k1 can't be hacked
Don't be so sure.
There are many tricks involving this curve. At some point, a combination of them - or perhaps a new property - will bring an end to it. This is both obvious and predictable.
I’ve been reading this forum for a long time. Why are there so few mathematical ideas on the forum? After all, everything is built on the formulas for adding points on a curve. For example, for the curve y^2=x^3, the point number is easy to find.

Also, there is a formula that shows where a point is located on the curve y^2=x^3+7: it is (y/x)^2-x = A.

There is also a formula that introduces a correction for point doubling: you double the point and get an answer with a correction; this answer will already correspond to a point on the curve y^2=x^3, and you can find the point’s number. But this works only for doubling. There is no such formula yet for the point addition formula.

Please share your ideas with formulas. It is in mathematics that the curve has the greatest vulnerability.

Because unless you’ve got a maths degree, any idea you post gets shot down as stupid. The only way to learn is to ask, but ask it the “wrong” way and you cop the same thing. Too many here don’t actually listen. They’ve already decided they know best, and that’s backwards. The whole point of a forum is to hear people out, especially the ones still learning.

I’ve been shot down plenty of times just for asking or replying.

So to the know-it-alls: show some respect. Treat people who ask the way you’d want to be treated yourself.

That makes perfect sense.



At the moment, my local private pool has already scanned 500 quadrillion keys, and I’m not even close to finding the key for Puzzle 71. I’m picking up another GPU—just for fun, really—because actually finding it would require a tremendous, truly immense amount of luck.  Cheesy Smiley Roll Eyes Grin
btc11235
Jr. Member
*
Offline

Activity: 40
Merit: 1


View Profile
October 28, 2026, 05:49:40 PM
 #14000

The problem is when I try to generate the other key myself... I'm getting different results from all three methods I've tried...

Look the albertobsd's keysubtracter

https://github.com/albertobsd/keysubtracter

oh, well, lol 😝

I'd feel worse about not knowing this existed, except I just double-checked and there's absolutely nothing about it in Keyhunt's documentation 🙃

Thanks for pointing me to it!
Pages: « 1 ... 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 [700] 701 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!