|
|
#91
03-06-2026, 13:05
|
||||
|
||||
|
Armadillo ECDLP Solver v1.4.5 — CRITICAL UPDATE: Cycle-Reset Diversity Fix
Immediate release of v1.4.5 — critical fix for a bug that caused Distinguished Points to stall after ~3.7 hours of computation. The problem: When worms reach the cycle limit (8 × 2^25 steps ≈ 268M steps), they need to restart from a new point. v1.4.4 selected only 2 walk table entries (5+5 = 10 bits), producing just 992 unique starting points for 174,080 worms. Result: ~175 worms per point, all replaying the same walk → 97% duplicate DPs. Unique DPs stalled at ~154K overnight. The fix: 32-bit bitmask to select a subset of all 32 walk table entries → up to 2^32 unique starting points (~4.3 billion) Per-worm resets counter to guarantee diversity on every subsequent reset splitmix64 device-side hash for robust seed mixing Zero performance impact: same 96 registers on sm_120, 0 spills, same speed Verification: After deployment, unique DPs immediately resumed growing (155K → 161K within minutes). 26/29 agents already updated automatically. Download the new version from the dashboard: https://ecdlp.protect.cx/download/ArmadilloSolver.zip Replace solver_fast.exe and restart your agent. Command line arguments remain unchanged. Note: Checkpoint format has changed (new worm_t struct). Old checkpoints are incompatible — agents will restart from scratch, but all DPs already collected on the server are valid and preserved. 
|
|
#92
03-06-2026, 15:24
|
||||
|
||||
|
How did the agents update automatically?
I didn't find any auto-update feature. Quote:
__________________
AKA Solomon/blowfish.
|
|
#93
03-06-2026, 15:29
|
||||
|
||||
|
Quote:
The users of those 26 agents simply downloaded the new build from the server's /download endpoint and restarted their agents manually. Poor wording on my part, sorry for the confusion! To update: download as usual the latest ArmadilloSolver.zip from the server, replace your solver_fast.exe, and restart. Live Stats (as of now): 29 active agents — 25x RTX 5090, 2x RTX 4070 Ti, 1x RTX 3060, 1x RTX 5070 Ti 90.73 G/s combined throughput 254,011 unique DPs collected (440K total submitted) 4.89 × 10¹⁵ iterations computed so far 36.3% progress toward expected collision 0 collisions yet ETA: ~12 hours to median collision point Last edited by cjack; 03-06-2026 at 16:57.
|
|
#95
03-07-2026, 05:19
|
||||
|
||||
|
Quote:
Think of it like flipping a coin — just because you "should" get heads by flip #10 doesn't mean it can't take 15 or 20 flips. The ETA shows "--" because we're past the median estimate, but the math is solid and all 30 agents are grinding at 92 G/s. The collision can hit any moment now. TL;DR: Perfectly normal statistical variance. We keep running.
|
| The Following User Says Thank You to cjack For This Useful Post: | ||
niculaita (03-07-2026) | ||
|
#96
03-07-2026, 06:34
|
|||
|
|||
|
Hi cjack,
I'm contributing on this ECDLP Solver, can you kindly include the source code with v1.4.5 version published on the dashboard website. Quote:
|
|
#97
03-07-2026, 06:41
|
||||
|
||||
|
Quote:
hxxxs://mega.nz/file/4oow3IDK#lj_6FkkOBAXreljlH9tRhY08jZyCanIXfWco26_HPBg Thanks for contributing to this "crazy" project! We'll find the collision point!
|
| The Following User Gave Reputation+1 to cjack For This Useful Post: | ||
niculaita (03-07-2026) | ||
|
#98
03-07-2026, 14:50
|
||||
|
||||
|
Status Update:
Progress: 156% of expected mean (85% cumulative probability) Unique DPs collected: 1,093,619 Active agents: 29 (24× RTX 5090, 1× RTX 5070 Ti, 1× RTX 4070 Ti Super, 1× RTX 3090, 1× RTX 4070, 1× RTX 3060 Ti) Fleet speed: 90.76 G/s Efficiency: 78% Collisions: 0 (still waiting) Uptime: ~38 hours continuous Why no collision yet? Pollard's Rho is probabilistic — the "expected" iteration count is a median, not a guarantee. Being at 156% means we're in the statistical tail, but this is perfectly normal. The CDF is P(x) = 1 − e^(−π/4 · x²), so at x=1.56 there's still a ~15% chance of not having found it yet. Nothing is wrong — all agents are healthy and producing DPs at the correct rate. ETA from current position: 90th percentile: ~7 hours 95th percentile: ~21 hours 99th percentile: ~52 hours The 5090 fleet is available for another ~33 hours, which covers us up to the 95th percentile. Statistically, the collision is very likely to happen within the next day. Stay tuned and join the battle!
|
|
#99
03-08-2026, 03:55
|
||||
|
||||
|
Critical Bug Found & Fixed (v1.5.0)
Hey all, Wanted to share a hard lesson learned with the THUNDERSTRIKE distributed Pollard's Rho solver targeting Armadillo ECDSA-113 (binary Koblitz curve over GF(2^113)). The Problem We've been running ~30 agents (mostly RTX 5090s) at a combined ~92 G/s for a while now. Reached 233% of the expected median iteration count with absolutely zero collisions. The probability of that happening with a correctly functioning Rho walk is roughly 1.4% — suspicious enough to warrant a deep investigation. Root Cause The walk partition function p = X.hi & 31 was using the projective X coordinate instead of the affine x coordinate. In Lopez-Dahab projective coordinates, X_proj = x_affine × Z. After the very first ld_madd step, Z diverges from 1. So two walks arriving at the same affine point but carrying different Z values would compute different partition indices, select different walk table entries, and diverge. Walks never merge. Pollard's Rho degenerates into pure random distinguished point sampling — you'd need ~10^12 DPs for a birthday collision among them. We had collected ~1.8 million. At that rate: roughly 223 years. Not ideal. The bug was subtle because every individual component (EC arithmetic, DP detection, server collection) was working correctly in isolation. The partition function just happened to operate on the wrong representation of the point. The Fix (v1.5.0) We switched to per-step affine normalization using Itoh-Tsujii inversion, ensuring Z = 1 at every step. This means the partition function now sees the true affine x coordinate and walks sharing the same point will always take the same step — as Pollard intended. With Z guaranteed to be 1 on input, we wrote an optimized ld_madd_z1 routine (5M+3S vs the previous 8M+5S). The compiled kernel hits 96 registers, 0 spills. Throughput on a single RTX 5090 is ~975 M/s — about 3.5x slower per step than before, but the algorithm now actually converges. Verification We wrote formal proofs for the partition invariant and ran a 5-test verification suite — all passing, confirming both that the old code was broken and that the new code preserves walk mergeability. Test runs show hash table duplicates growing at the expected rate, which is exactly what you want to see. What's Next Operations are temporarily suspended while we do final verification across the fleet. Once we restart with v1.5.0, the estimated time to solve one certificate is in the range of 32-50 hours with the full agent fleet at reduced per-step throughput. A very different story from "223 years." Sometimes the most dangerous bugs are the ones where everything looks like it's working perfectly. 92 G/s of beautifully fast, completely useless computation.
|
|
#100
03-08-2026, 06:07
|
|||
|
|||
|
I can not connect to the server, waiting the new fix (v1.5.0) to be released with its source code.
Quote:
|
|
#101
03-08-2026, 07:00
|
||||
|
||||
|
Hey aliali,
v1.5.0 is now live on the server — full source code included in the download package. Download the new package from https://ecdlp.protect.cx/download/ArmadilloSolver.zip Old agents (< v1.5.0) are automatically rejected by the server The fleet is already running with 26 workers at ~21 G/s on the new target. ETA ~3 days. We also switched to a new certificate target (codename ENDGAME). Your agent will pick up the new parameters automatically from the server when it connects — no manual config needed.
|
| The Following User Says Thank You to cjack For This Useful Post: | ||
wx69wx2023 (03-10-2026) | ||
|
#102
03-08-2026, 10:05
|
||||
|
||||
|
@cjack
There is a small bug for printf. The console output is mixed with printf from if and else branches: [ENDGAME][ 315s] 129.85 M iter/s | 4.090e+10 iters | DP sent:1 NE - retrying... There should be a '\n' for if(hb_failed) branch. And I don't know why the heartbeat failed so frequently, my network connection is quite stable. Code:
if (hb_failed)
printf("\r[%s][%7.0fs] %.2f %s | %.3e iters | SERVER OFFLINE - retrying... ",
job_codename ? job_codename : "?",
elapsed, dspeed, unit, (double)agent_iters);
else
printf("\r[%s][%7.0fs] %.2f %s | %.3e iters | DP sent:%u ",
job_codename ? job_codename : "?",
elapsed, dspeed, unit, (double)agent_iters, dp_found);
Quote:
__________________
AKA Solomon/blowfish. Last edited by WhoCares; 03-08-2026 at 11:55.
|
| The Following User Gave Reputation+1 to WhoCares For This Useful Post: | ||
Jupiter (03-11-2026) | ||
|
#103
03-08-2026, 14:04
|
||||
|
||||
|
Hi WhoCares!
Thank you so much for the detailed bug report! Both issues were spot-on. v1.5.1 is now available from the dashboard download link with the following fixes: 1) Printf mixing (agent): The hb_failed status line was using \r without a terminating \n, causing it to overwrite normal output. Fixed — now uses \n delimiters so the "SERVER OFFLINE" message prints cleanly on its own line. 2) Heartbeat timeouts every ~300s (server): This was the more critical one. save_state() was holding the global lock during the entire disk write — serializing millions of DPs with struct.pack in a loop while every API endpoint waited. As the DP table grows, save time grows, and at ~15M+ DPs it was blocking long enough to trigger agent heartbeat timeouts. Fix: new save_state_background() takes a fast snapshot of all data structures under lock (milliseconds), then releases the lock and writes to disk outside it. Agents no longer see any interruption during auto-save. Fleet is currently at 28 workers / ~21 G/s, 9.3% progress, efficiency 99.9%. No more periodic disconnections. Thanks again for catching these — the heartbeat timeout one in particular would have become worse as the DP table keeps growing toward collision.
|
| The Following User Says Thank You to cjack For This Useful Post: | ||
Jupiter (03-11-2026) | ||
|
#105
03-11-2026, 20:07
|
||||
|
||||
|
Hi WhoCares! Thanks for the report and sorry about the disruption at 3 AM.
Here's what happened: we switched the attack target from Cert #11 to Cert #6 (the correct eval certificate — we discovered the old target had a wrong base point). The server was restarted with a fresh project, and then we upgraded the entire fleet to agent v1.6.0. Sorry for the inconvenience — this is very much a work-in-progress experiment and things like these can happen. We really appreciate everyone who's contributing despite the bumps along the road. Your help means a lot! Everything is stable now — 39 workers running at 34+ G/s, server healthy with 14.5M+ unique DPs and growing. Important: Please download the latest agent (v1.6.0) from the dashboard at ecdlp.protect.cx. This version has the async DP sender pipeline which eliminates idle time between GPU kernel launches — you should see a nice speed boost (up to 25% faster). Your current v1.5.1 still works but it's leaving performance on the table. Thanks for contributing to the attack!
|
 |
| Tags |
| bolero, ecdlp |
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Replacing ECDSA in Target (arma) | Mynotos | General Discussion | 3 | 11-22-2019 00:49 |
Linear Mode
