Armadillo ECDSA-113

[sendersu]

Originally Posted by contextrax

You want to break 4 113 bit's ECC curves by solving ECDSA?
We used like 6 months last time so unless you have access to a lot of CPU's this will take forever.

What is more important in bruteforcing - CPU GHz speed or # of cores?

[ismail]

can u share the target?

[Apuromafo]

About the importance of privatevalue in the example before exposed:
generating a licence for apuromafo for x86+x64 (is the same cert shortv3 lv10)

->

tool:ATK 0.4
Ecdsa Public: 1570789295,4089747062247003654720736468506441,10111618751385367037406972360317044
(Curve SEED : 1570789295
Base Point x : 4089747062247003654720736468506441
Base Point y : 10111618751385367037406972360317044)
Private:1984557253727814641989266002264698
name:apuromafo
Sym:BDA4FA1C
press generate and see:

name:apuromafo
serial:000017-MC8PXU-6U3PC3-3V93J6-Y9MCJ5-7GF1E8-TRWK3F-JUGJV6-4QFZNC-TW0YVM


in advanced log

KeyBytes (Len: 6, 0x6):
1CC8BDA4FA1C
NextRandomRange Array (Seed=37577C32)
F40CE61ECC9B
Encrypted KeyBytes:
E8C45BBA3687
Cooked Name (Len: 9, 0x9):
APUROMAFO
Message (Len: 15, 0xF):
E8C45BBA3687415055524F4D41464F
Message Hash (Len: 16, 0x10):
F1AAF5EC593C2E208C91E2BFA9ED06F7
Random point:
x=747BC033ABFF5D62B6845ABE3139, y=11EE604E9C851EBF14BF56807DCD8,
prvt=CD79505FC0D0A18FD75A5F355CD8
Signature (Len: 28, 0x1C):
660C7B48E46F268C914F0785C8CE3931BE5A84B6625DFFAB33C07B74
Signed KeyBytes (Len: 34, 0x22):
E8C45BBA3687660C7B48E46F268C914F0785C8CE3931BE5A84B6625DFFAB33C07B74

in my pc, both armadillo was registred with my user+serial generated using atk0.4

BR, Apuromafo

[cjack]

Agent v1.3.3 released! Download updated from the same link or from here:

hxxxs://mega.nz/file/thxBWAIb#DkB8VygjaZEPQpU6Qsm6mZOdW5hizZuQZ3ejmms34q0

What's new:

Auto-reconnect: if the server goes down, the agent keeps computing and reconnects automatically when it's back — no more manual restarts or batch file loops
Faster heartbeats: reduced HTTP timeouts to prevent false "offline" status on the dashboard when multiple agents share the same network
Version tracking: your agent version now shows up in the dashboard

We'll briefly restart the server in a few minutes to deploy the matching update.

Agents running v1.3.3 will reconnect on their own. Older agents may need a manual restart.

Currently running 20x RTX 5090 in parallel — 70 G/s and climbing. ETA under 21 hours!

[cjack]

Server Update v1.4.0 — Auto-Keygen on Solution
* No Agent update needed *

https://ecdlp.protect.cx/

What's new in v1.4.0:

When the ECDLP is solved, the server now automatically forges a valid Armadillo serial using an integrated keygen (based on AKT v0.4 source by mrexodia & Sigma)
The dashboard displays the forged serial in a dedicated "FORGED SERIAL" banner — ready to copy & paste
BasePoint Init seed persisted per-project, so keygen works across server restarts
Fixed UTF-8 decode crash when agents send GPU names with non-ASCII characters

Currently running 24 Agents in parallel — 73 G/s and climbing. ETA 10h 9m

[WhoCares]

@cjack

There is sth. wrong with my agent.

1. The computing speed is toggling between 591 M/s and 1.4 G/s.
2. And the card name "5070 Ti" should be "4070".
3. My agent becomes #1 of leaderboard.

Maybe collide with another agent?

[cjack]

Originally Posted by WhoCares

@cjack

There is sth. wrong with my agent.

1. The computing speed is toggling between 591 M/s and 1.4 G/s.
2. And the card name "5070 Ti" should be "4070".
3. My agent becomes #1 of leaderboard.

Maybe collide with another agent?

Hey WhoCares, thanks for reporting the speed issue!

The toggling between 591 M/s and 1.4 G/s is actually expected behavior when using --gpu-limit — it's a duty-cycle mechanism (compute burst → sleep → compute burst). The reported speed alternates between instantaneous (high) and averaged (low). Nothing wrong there, that's by design.

However, while investigating this I stumbled onto something bigger: your agent was over-reporting iteration counts by roughly 50× compared to the actual Distinguished Points it produced. All 27 other agents had a perfectly normal DP/iteration ratio (around 100%), while yours was sitting at ~2%.

This caused the dashboard to show inflated progress (135% instead of the real ~91%). We've now corrected the totals and the ETA is accurate again.

Possible cause: are you by any chance running multiple instances of the solver with the same --worker-name? That would explain it — each instance reports its own iteration count to the server, but the DP production doesn't scale proportionally if they're all fighting for the same GPU.

Quick check:

Make sure you have only one solver_fast.exe running per GPU
If you want to use multiple GPUs, use --device N to assign each instance to a different GPU, with different worker names
I've also added a server-side guard (v1.4.2) that validates the DP/iteration ratio per agent, so this kind of inflation can't happen again regardless of the cause.

Thanks for being part of the battle! Your GPU is doing great work.

[WhoCares]

I confirmed there is only one process for solver_fast.exe.

My command is:
solver_fast.exe --server ecdlp.protect.cx --worker-name "WhoCares" --gpu-limit 100 --worker-notes "RTX 4070" --resume

And I have no 5070 Ti card. Only one NVIDIA card.

Shall I remove "--gpu-limit 100"?
I originally set it to 50, but later I got lazy and just changed it to 100 without removing that parameter.

Originally Posted by cjack

Quick check:

Make sure you have only one solver_fast.exe running per GPU
If you want to use multiple GPUs, use --device N to assign each instance to a different GPU, with different worker names
I've also added a server-side guard (v1.4.2) that validates the DP/iteration ratio per agent, so this kind of inflation can't happen again regardless of the cause.

[cjack]

Originally Posted by WhoCares

I confirmed there is only one process for solver_fast.exe.

My command is:
solver_fast.exe --server ecdlp.protect.cx --worker-name "WhoCares" --gpu-limit 100 --worker-notes "RTX 4070" --resume

And I have no 5070 Ti card. Only one NVIDIA card.

Shall I remove "--gpu-limit 100"?
I originally set it to 50, but later I got lazy and just changed it to 100 without removing that parameter.

Thanks for checking! Good news — the issue wasn't on your end at all. We tracked it down to a bug in the solver itself.

The problem: init_worms() used a deterministic hash based only on thread ID. This meant every time an agent reconnected (server restart, network hiccup, etc.), it replayed the exact same random walks from the exact same starting points — producing identical DPs. Since there were several server restarts yesterday, most iterations across ALL agents were duplicated work.

Your --gpu-limit 100 is fine, no need to remove it (100 = no throttling, same as not having the flag).

The fix is in agent v1.4.0 and above — worm initialization now uses a session-unique seed (time ^ PID), so every session and every agent gets different starting points.

Download the new agent directly from the server here:
https://ecdlp.protect.cx/download/ArmadilloSolver.zip

Just replace solver_fast.exe and restart. Your same command line works perfectly.

[cjack]

Agent v1.4.4 Available!

Hey everyone,

A new solver version v1.4.4 is available for download from the dashboard. If you're still running v1.4.2 or v1.4.3, please update ASAP.

https://ecdlp.protect.cx/download/ArmadilloSolver.zip

What's fixed:

v1.4.2 and v1.4.3 had a worm initialization bug that caused massive overlap between agents — up to 99.9% of your DPs were duplicates that the server already had. In other words, most of your GPU cycles were wasted computing points that other agents had already found.

v1.4.4 uses a chained pre-hash algorithm for worm seeding that guarantees unique starting points across all agents, regardless of launch timing or PID.

Results after deploying v1.4.4:

DP yield: 99.3% (verified across all 28 agents on the leaderboard)
Zero overlap between agents
Speed unchanged: ~3.5 G/s per RTX 5090
Fleet total: 89 G/s with 29 active agents
Progress so far: 3.6%, ETA ~5.5 days
How to update:

Just download the new ArmadilloSolver.zip from the dashboard page and replace your solver_fast.exe. No config changes needed — same command line as before.

The dashboard is live at the usual address if you want to check your agent's stats.

Every GPU counts — let's crack this code!

[cjack]

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.

[WhoCares]

How did the agents update automatically?

I didn't find any auto-update feature.

Originally Posted by cjack

Armadillo ECDLP Solver v1.4.5 — CRITICAL UPDATE: Cycle-Reset Diversity Fix

After deployment, unique DPs immediately resumed growing (155K → 161K within minutes). 26/29 agents already updated automatically.

[cjack]

Originally Posted by WhoCares

How did the agents update automatically?

I didn't find any auto-update feature.

They didn't — there's no auto-update feature right now, but something new is under beta testing.
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

[aliali]

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.

Originally Posted by cjack

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.

[cjack]

Originally Posted by aliali

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.

Sure! This is the package with source code, version 1.4.5:

hxxxs://mega.nz/file/4oow3IDK#lj_6FkkOBAXreljlH9tRhY08jZyCanIXfWco26_HPBg

Thanks for contributing to this "crazy" project! We'll find the collision point!