Armadillo ECDSA-113 - Page 8

WhoCares · #**106** 03-12-2026, 09:06

@cjack

Performance optimizations suggested by the AI agent (Claude Opus 4.6 Thinking):

Core conclusion: The two highest-priority optimizations together can provide roughly a 3–4× speedup:

Montgomery batch inversion (P0) — A prototype already exists in pollard_rho.cuh, but it uses an old data structure. It needs to be ported to the fe_t architecture used in solver_fast.cu. This can reduce the per-step cost from 15M + 120S to approximately 6M + 6S.

CUDA Stream double buffering + pinned memory (P0) — The current workflow (kernel → sync → D2H → CPU processing) is strictly serial. Using dual streams with a ping-pong buffer allows GPU computation to fully overlap with CPU/network processing. ��

And I ask AI to code a Python script to run and upgrade "slover_fast.exe" automatically:
https://github.com/z16166/PySolverLauncher/

cjack · #**107** 03-12-2026, 16:13

Quote:

Originally Posted by WhoCares

@cjack

Performance optimizations suggested by the AI agent (Claude Opus 4.6 Thinking):

Core conclusion: The two highest-priority optimizations together can provide roughly a 3–4× speedup:

Montgomery batch inversion (P0) — A prototype already exists in pollard_rho.cuh, but it uses an old data structure. It needs to be ported to the fe_t architecture used in solver_fast.cu. This can reduce the per-step cost from 15M + 120S to approximately 6M + 6S.

CUDA Stream double buffering + pinned memory (P0) — The current workflow (kernel → sync → D2H → CPU processing) is strictly serial. Using dual streams with a ping-pong buffer allows GPU computation to fully overlap with CPU/network processing. ��

And I ask AI to code a Python script to run and upgrade "slover_fast.exe" automatically:
https://github.com/z16166/PySolverLauncher/

@WhoCares

Thanks for the deep analysis and the PySolverLauncher — really appreciate you putting time into this!

Let me give some context on the current state, since the AI reviewed v1.3.0 but we're now on v1.6.0 with several things already addressed:

CUDA Streams / GPU overlap — Already solved in v1.6.0. We implemented an async DP sender pipeline (background thread handles all HTTP while the main thread immediately relaunches the kernel). Measured GPU utilization: 100%, power draw 502W/575W on the RTX 5090. The double-buffering approach from the analysis would add <0.5% on top of what we already have.

Montgomery batch inversion — This is the one genuinely interesting suggestion. The per-step Itoh-Tsujii inversion IS the main cost (8M+116S out of 15M+120S per step). Batch inversion could amortize it across 128 threads. However, it requires 14x __syncthreads() per step (currently we have ZERO sync across 2048 steps), plus shared memory for the product tree, plus extra registers. Our realistic estimate is 1.5-2x speedup, not 3x. Worth exploring after the current run.

Comb w=5/6 for fe_mul — We actually tested this. Wider comb = more registers = less occupancy. Our history: comb table fe_mul gave 198 registers (16.7% occupancy), while the current table-free approach uses 80 registers (50% occupancy) and was 2.4x faster in practice. Occupancy wins over per-operation speed on GPU.

Important note about per-step normalization: the analysis calls it "the biggest bottleneck" — true, but it's mathematically required. Without it, walks never merge (we learned this the hard way — our old 3.5 G/s benchmark was invalid because of this). It can only be amortized (batch inversion), not removed.

Your PySolverLauncher: we've bundled it into the official ArmadilloSolver.zip on the dashboard! The /api/download-info endpoint was already there, so it works out of the box. Credit in the changelog. Thanks for the contribution!

Current status: 42 G/s fleet, 101M DPs, 22% probability, all verified end-to-end. Just waiting for the birthday paradox to do its thing!

WhoCares · #**108** 03-12-2026, 16:52

@cjack

The AI's analysis is based on the 1.6.0 code. It's just that each time I extract the latest version of the exe and the source code into the same directory whose name contains 1.3.0, overwriting the old version.

You forgot to update the zip sha1 from download api interface, latest is B5A021ADE2C88548EB511120C17470F0D00FBB5C, not 0306102b37f2a102d4d8376c3dc806ce059c9597.
This sha1 is used as version number by Python script. The real version number "v1.6.0" is hardcoded in exe. It's not easy to extract it.

cjack · #**109** 03-12-2026, 17:36

Quote:

Originally Posted by WhoCares

@cjack

The AI's analysis is based on the 1.6.0 code. It's just that each time I extract the latest version of the exe and the source code into the same directory whose name contains 1.3.0, overwriting the old version.

You forgot to update the zip sha1 from download api interface, latest is B5A021ADE2C88548EB511120C17470F0D00FBB5C, not 0306102b37f2a102d4d8376c3dc806ce059c9597.
This sha1 is used as version number by Python script. The real version number "v1.6.0" is hardcoded in exe. It's not easy to extract it.

@WhoCares

Good catch on the stale SHA1! It was cached at server startup and never refreshed after we updated the ZIP (we added your launcher script + updated changelog).

Fixed. The API now returns the correct hash. I also implemented automatic mtime-based detection: whenever the ZIP file changes on disk, /api/download-info recomputes SHA1 and size on the fly. No more stale hashes, no server restart needed.

The API response now also includes a version field:

{
"available": true,
"sha1": "c7c267adca36c7e2ddac0f4b3bf37100f88ef033",
"size": 1018086,
"filename": "ArmadilloSolver.zip",
"version": "1.6.0"
}

This is fully backward compatible — your existing launcher works without any changes. The version field is just extra info you can optionally use if you want to display a human-readable version instead of the SHA1.

We also added VERSION.txt and a README.txt with quick start instructions inside the ZIP, so anyone extracting it knows exactly which version they have.

Thanks for keeping an eye on things — your feedback makes the project better!

Flash status update:

42 active workers, fleet speed 41.7 G/s
104M distinguished points collected
Current probability: 23.4%
Median ETA: ~17 hours (Mar 13, ~03:00 UTC+1)
0 collisions so far — the hunt continues!

WhoCares · #**110** 03-13-2026, 10:44

cjack · #**111** 03-13-2026, 17:49

Quote:

Originally Posted by WhoCares

Hey WhoCares, thanks for reporting the connection problems you experienced.

The "SERVER OFFLINE" errors you're seeing are caused by our network setup — we use a VPN as a reverse proxy to route traffic to the server. This intermediate hop occasionally drops connections or times out, resulting in those 502 errors. The agent handles this gracefully by retrying automatically, so no work is ever lost.

We've recently applied a server-side optimization that significantly reduced the issue (server response time went from ~2000ms down to ~2ms), but the VPN layer can still cause sporadic hiccups. We're looking into improving this path further.

Important: these brief connection blips have zero impact on computational performance. The solver keeps running on the GPU continuously — it only needs the server to submit Distinguished Points, which happens asynchronously. Even if a submission fails, it simply retries on the next cycle. Your GPU speed and contribution are not affected at all.

Thanks for your patience and for contributing to the project!

WhoCares · #**112** 03-13-2026, 21:27

@cjack

Not sure if this is expected behavior, but I noticed a couple of things:

1. The local console reports about 197 M/s, while the web dashboard shows around 192 M/s.
2. The speed reported by the console gradually decreases over time. It started at around 200 M/s and has slowly dropped to ~197 M/s so far.

My machine isn’t running any other CPU- or GPU-intensive workloads.

Just wondering if this difference is expected, or if I might be missing something.

cjack · #**113** 03-13-2026, 23:30

Quote:

Originally Posted by WhoCares

@cjack

Not sure if this is expected behavior, but I noticed a couple of things:

1. The local console reports about 197 M/s, while the web dashboard shows around 192 M/s.
2. The speed reported by the console gradually decreases over time. It started at around 200 M/s and has slowly dropped to ~197 M/s so far.

My machine isn’t running any other CPU- or GPU-intensive workloads.

Just wondering if this difference is expected, or if I might be missing something.

@WhoCares

Both are totally expected, no worries!

1. Console vs Dashboard difference (~197 vs ~192 M/s):
The local console shows a cumulative average (total iterations ÷ total time since start). The dashboard uses a server-side EMA (exponential moving average) computed from DP arrival deltas every ~10 seconds. The server measurement includes a tiny network latency overhead on each heartbeat interval, which consistently makes it read ~2-3% lower. The dashboard number is actually a more accurate picture of your current sustained throughput, while the console number is slightly inflated by the faster early-session burst.

2. Gradual speed decrease (200 → 197 M/s):
Classic GPU thermal behavior. When you first start, the GPU runs at max boost clocks while it's cool. After a few minutes it reaches thermal equilibrium and settles to sustained clocks — slightly lower. Since the console uses a cumulative average from time zero, it takes a while for the displayed number to drift down from that early burst. It'll eventually stabilize around ~195-197 and stay there. Completely normal.

Your setup is running perfectly. Thanks for contributing!

WhoCares · #**114** 03-15-2026, 00:46

@cjack

Please confirm whether the issues described in the attachment are real bugs. Thanks.

cjack · #**115** 03-15-2026, 01:06

Hey WhoCares,

I owe you a correction — and a big one.

In my previous reply, I said your point #3 (walk partition not Frobenius-invariant) was "a legitimate optimization opportunity, not a correctness bug." I was wrong, and I want to be upfront about it.

After a deeper analysis, we realized this is actually the root cause of why our collision is taking so long. Here's what we found:

The walk function uses p = x.lo & 31 (actual affine x bits) for the partition. Since τ(x,y) = (x², y²) produces completely different low bits, walks through P and τ(P) diverge immediately. There's no walk merging between orbit members, which means the 226× Frobenius speedup we assumed in our probability formula was never active.

The numbers speak for themselves:

What we thought: P = 94.5%, past the median, "just unlucky"
Reality: P = 1.28%, only 14% of the way to the median
Search space: We were walking in ORDER (5.19×10³³), not ORDER/226 (2.30×10³¹)
The canonicalization at DP time is mathematically correct (the server handles all Frobenius cases perfectly, as I described before), but it only helps with DP-space birthday collisions — which are negligible at our DP count (expected: 2.6×10⁻¹⁵). The dominant mechanism is walk merging, and that requires Frobenius-invariant iteration.

We're already working on the fix. The plan is to implement canonical lifting at every walk step:

Canonicalize the current point each step (112 squarings in GF(2¹¹³) — cheap in binary fields)
Use canonical x bits for the walk partition
Adjust (a,b) coefficients by λ^i at each canonicalization
Walk from the canonical representative
Cost: ~25-35% overhead per step. Gain: 226× from walk invariance. Net: ~178× speedup.

With this fix, the post-fleet timeline goes from years to weeks — completely changes the game.

You nailed the critical issue. Your analysis was more right than our initial review gave it credit for, and I should have dug deeper before replying. This is exactly why external reviews matter — thank you for pushing on this.

We'll keep you posted on the implementation progress.

cjack · #**116** 03-15-2026, 03:05

Hey everyone,

Quick update on the Armadillo ECDSA-113 solver project. We just released v2.0.0 of both server and solver, fixing a critical bug discovered by WhoCares — huge thanks to him for the sharp eye.

What was wrong:

The walk partition function was using raw affine x-coordinate bits to determine the walk step (p = wX.hi & 31). Since the Frobenius endomorphism τ(x,y) = (x², y²) completely changes the bit pattern of x, two points in the same Frobenius orbit would take different walk paths. This means the 226× speedup from Frobenius equivalence classes was completely inactive — the solver was effectively brute-forcing the full 112-bit space instead of the reduced ~104-bit quotient space.

With 344M distinguished points collected under v1.x, the true collision probability was around 1.3%, not the 94.5% displayed on the dashboard. The old DPs were essentially useless for finding collisions through Frobenius orbits.

What v2.0 fixes:

The solver now implements canonical lifting — at every walk step, it finds the lexicographically smallest x-coordinate across all 113 Frobenius conjugates (x, x², x⁴, ..., x^(2¹¹²)), lifts the point to that canonical representative via repeated squaring, and scales the linear combination coefficients by the appropriate power of λ (the Frobenius eigenvalue). The partition function now operates on the canonical x, making the walk Frobenius-invariant.

Key changes:

ec_canon_x(): iterates 112 squarings to find lex-min x in the orbit
λ^i power table (113 entries) precomputed in __constant__ memory
Coefficient scaling via sc_mul128(a, lambda_pow[ci]) at each step
Server collision resolution updated for all 5 Frobenius cases (d=0, ±τ^d, ±τ^d')
Version gating: server rejects all agents < v2.0.0 to prevent mixing old/new DPs
Performance: ~377 M iter/s per RTX 5090 (down from ~1050 M/s due to canonicalization overhead), but each iteration now searches an effective space 226× smaller. Net theoretical speedup: ~81×.

Current status:

Server v2.0.0 and solver v2.0.0 are up and running, all workers active and submitting canonical DPs. Fresh start from zero — all old DPs discarded.

@WhoCares: Would you be willing to do another independent verification of the v2 solver+server? I've prepared a review package (source code + test suite + review instructions) — I can send it to you or you can grab it from the dashboard download. Specifically interested in confirming:

The canonical lifting logic is mathematically sound
Coefficient scaling with λ^i is correct
Walk partition is truly Frobenius-invariant
Server collision resolution handles all Frobenius rotation cases
No regression in DP generation/submission pipeline
Your previous analysis was spot-on and saved us from burning through the entire fleet budget on broken walks. Want to make absolutely sure v2 is solid before we spend the next few days waiting for a collision.

Source code and full changelog available on the dashboard. ZIP includes complete sources, build scripts, and test suite.

WhoCares · #**117** 03-15-2026, 10:34

@cjack

To be honest, I didn't catch this manually. It was actually flagged by Gemini within Google Antigravity. I simply audited the code referenced in the report to verify it wasn't a false positive. I ran out of tokens for Gemini Pro, so I was using Gemini Flash yesterday—even the free tier provided surprisingly solid analysis. My takeaway is that it’s definitely worth running project code through different AI agents for peer reviews.

I've already gone through the v2.1.0 client implementation and no more issue found（except for some perf optimizations like Warp-level Montgomery Batch Inversion, early-exit or bit-filtering to eliminate candidates before full squaring in ec_canon_x()). If you'd like me to take a look at the server-side logic, you can reach me at "bugtraq at 163 dot com". Alternatively, you might want to perform a local audit using an AI agent for a quick sanity check.

Thanks.

cjack · #**118** 03-15-2026, 15:17

Quote:

Originally Posted by WhoCares

@cjack

To be honest, I didn't catch this manually. It was actually flagged by Gemini within Google Antigravity. I simply audited the code referenced in the report to verify it wasn't a false positive. I ran out of tokens for Gemini Pro, so I was using Gemini Flash yesterday—even the free tier provided surprisingly solid analysis. My takeaway is that it’s definitely worth running project code through different AI agents for peer reviews.

I've already gone through the v2.1.0 client implementation and no more issue found（except for some perf optimizations like Warp-level Montgomery Batch Inversion, early-exit or bit-filtering to eliminate candidates before full squaring in ec_canon_x()). If you'd like me to take a look at the server-side logic, you can reach me at "bugtraq at 163 dot com". Alternatively, you might want to perform a local audit using an AI agent for a quick sanity check.

Thanks.

@WhoCares That's a great approach — using multiple AI agents as independent reviewers is something we've fully embraced in this project, after the latest critical bug. The Frobenius invariance bug you flagged was the single most impactful finding: it saved us from burning weeks of GPU time on completely useless DPs. We rebuilt everything from scratch after that (v2.0.0), and then the independent audits caught another subtle bug in the collision resolution logic (missing negation case for d=0). None of these would have been easy to spot manually.
Honestly, we should have started doing independent reviews much earlier in the project — lesson learned. From now on it's standard procedure: every significant change gets reviewed by at least one external AI agent before deployment.
Regarding the perf optimizations you mentioned — we evaluated warp-level batch inversion but decided the risk/complexity wasn't worth it for the marginal gain. The early-exit in ec_canon_x() is interesting but the current 112-squaring loop is already branch-free and register-friendly on sm_120, so we kept it simple. We did implement two other optimizations in v2.1.0 (reusing canon_x from canonicalization + hardware-accelerated scalar multiply with Barrett reduction) which brought us from 377 to 535 M/s per GPU — a clean 1.42x speedup with zero register increase.
Fleet is currently running at 32.5 G/s with 58 workers, ETA ~2 days for the collision. Fingers crossed.
I've sent you the server-side sources via PM — looking forward to your analysis. When this is over, everything goes open source on GitHub.

JMP-JECXZ · #**119** 03-15-2026, 17:05

Is that project full vibe coded ? feel like each time a bug is found wasting days of computing.
cant you add a test mode using this post maybe https://forum.exetools.com/showpost.php?p=111962&postcount=54 to see if the solver actually can reproduce the result of a know broken cert

cjack · #**120** 03-15-2026, 17:21

@JMP-JECXZ Fair question, and I understand the concern — finding bugs after days of computing is painful (and expensive).

To be honest, you're touching on a real lesson we learned the hard way. The independent review process was introduced only AFTER WhoCares flagged the Frobenius invariance bug that invalidated all our v1.x DPs. Before that, we were too confident in our own code — that was our mistake, plain and simple. Presumption.
Since then, we've put the entire codebase through 4 independent reviews, with 175/175 mathematical tests passing, 100/100 production DPs verified via independent EC scalar multiplication, and all 6 collision resolution formulas tested with synthetic collisions. So only NOW do we have mathematical certainty that the calculations are correct. We should have done this from day one.
Regarding testing with a known key: we already do exactly that. The solver has a --v964 test mode using the Armadillo v9.64 known secret:

k = 1984557253727814641989266002264698

This was used extensively to verify the entire pipeline end-to-end: GPU walk → DP emission → server collection → collision detection → key recovery → serial generation.
The current system is in code freeze — no changes until the collision is found. The fleet is running at 32.5 G/s with 99.1% efficiency and 58 workers. At this point, it's pure math.
Thanks for your input — it's great to see the community engaged on this!

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Replacing ECDSA in Target (arma)	Mynotos	General Discussion	3	11-22-2019 00:49

The Following User Says Thank You to cjack For This Useful Post:
WhoCares (03-13-2026)

The Following 2 Users Say Thank You to cjack For This Useful Post:
Jupiter (03-15-2026), WhoCares (03-13-2026)

The Following User Gave Reputation+1 to WhoCares For This Useful Post:
Jupiter (03-16-2026)

The Following 2 Users Say Thank You to cjack For This Useful Post:
Abaddon (03-19-2026), Jupiter (03-16-2026)

The Following 3 Users Say Thank You to cjack For This Useful Post:
Abaddon (03-19-2026), WhoCares (03-15-2026), wx69wx2023 (03-15-2026)

The Following User Says Thank You to JMP-JECXZ For This Useful Post:
deepzero (03-15-2026)

The Following User Says Thank You to cjack For This Useful Post:
niculaita (03-16-2026)