Setup
How I set up the ECDSA.fail challenge on a fresh Ubuntu laptop, from an empty terminal to a validated score, with the reasoning at each step. The three system problems near the end were the most instructive part, so they get the most detail.
Step 1
Before adding anything I checked what the machine already had, so every later step started from a known state instead of a guess. Git and my GitHub SSH key were set up. Rust was not installed.
terminal
git --version
rustc --version
cargo --version
ssh -T git@github.comStep 2
Two reasons. Ubuntu's packaged Rust is years old. And the challenge repo pins an exact compiler version in a rust-toolchain file that only rustup respects. It downloads that version on the first build, so everyone in the competition compiles with the same one.
I downloaded the installer script to a file and read it before running it, instead of piping curl straight into a shell. Worth doing with any install script you find on the internet.
terminal
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs -o rustup-init.sh
less rustup-init.sh # read it first
sh rustup-init.shStep 3
I created an empty public repository: no README, no .gitignore, and no license template. That last one matters. The challenge code is other people's work, parts under CC BY 4.0 and attributed in a NOTICE file, the rest belonging to the maintainers. A license grants permission, and you can only grant permission for work you own. So I added no license and kept their NOTICE intact.
Step 4
I cloned the official challenge repo, renamed its remote to upstream, and added mine as origin. My work pushes to my repository, and their future improvements can still be pulled.
terminal
git clone https://github.com/Layr-Labs/ecdsafail-challenge.git
cd ecdsafail-challenge
git remote rename origin upstream
git remote add origin git@github.com:austinamissah/ecdsa-circuit-optimization.gitStep 5
My first push failed, because GitHub had auto-created an initial commit from a checkbox I missed. Before forcing anything I checked the remote held only that stub commit, then used --force-with-lease, which refuses to overwrite anything you have not seen. Never force-push a branch other people build on. This was my own one-day-old solo repo, so it was safe.
terminal
git fetch origin
git log origin/main --oneline # only GitHub's stub commit
git push --force-with-lease -u origin mainStep 6
Before running anything I read the NOTICE file (who owns what), the rust-toolchain file (the pinned compiler, 1.93.0), and all of benchmark.sh. That last one matters: it runs contestant code from unknown contributors inside a bubblewrap sandbox with a read-only filesystem, no network, an unprivileged user, and one throwaway writable folder. The repo openly accepts code from many people, so the sandbox is the designed safety model.
Step 7
Compiling everything without executing any contestant code keeps build errors and runtime problems separate, so when something fails you know which kind of failure you are looking at. The build finished with warnings, all dead-code, all normal for a shared research codebase.
terminal
cargo build --releaseStep 8
The run then failed three times, each for a different reason. I diagnosed each one from the actual error message before changing anything.
error
bwrap: loopback: Failed RTM_NEWADDR: Operation not permittedRecent Ubuntu releases restrict unprivileged sandboxes, so the script's preferred path is to launch bubblewrap through sudo, which then drops the contestant code to an unprivileged user anyway. The fix is just to authorize sudo before running:
fix
sudo -v && ./benchmark.sh ...error
sudo: a password is requiredThis appeared from inside the script even though I had just typed my password. Ubuntu caches sudo credentials per terminal, a setting called tty_tickets. The script launches the sandbox in a detached session with no terminal, so the cached ticket does not apply there and sudo cannot ask again. The fix is a one-line sudoers drop-in. I wrote it through sudo tee, locked its permissions down, and validated it with visudo before trusting it.
fix
echo 'Defaults !tty_tickets' | sudo tee /etc/sudoers.d/notty
sudo chmod 0440 /etc/sudoers.d/notty
sudo visudo -c # validate before trusting itThere is a tradeoff. My password still expires after about 15 minutes, but within that window any of my processes can use sudo. On a single-user laptop I find that acceptable.
error
bwrap: execvp .../build_circuit: Permission deniedThe sandbox runs contestant code as the user “nobody”, and modern Ubuntu creates home directories as mode 750, so other users cannot even pass through /home/<me> to reach the binary. I verified that with namei, then granted traverse-only access: others can pass through my home directory but still cannot list or read anything in it.
fix
namei -l target/release/build_circuit # confirm where traversal fails
chmod o+x "$HOME" # traverse only, no list, no readStep 9
With the three obstacles cleared, the harness ran end to end. It validated all 9,024 test points, confirmed every ancilla qubit returned to zero with no phase leakage, and scored the current community circuit at 1,320,763 average Toffoli gates × 1,152 qubits, about 1.52 × 10⁹, on my machine. That score is the community's accumulated optimization work, which I reproduced and validated; the profiling and analysis that followed are my own contribution.
Expect a different number. That was July; upstream has improved the circuit many times since, and by August the same command reported 1,288,101 × 1,154. The steps below do not change, only the score they print.
terminal
./benchmark.sh --note "first local run, unmodified clone"Step 10
The harness appends one row to results.tsv per run. I reviewed the diff, committed it under my own name, and pushed. Uncommitted work is invisible, so every session of mine ends with a clean git status.
terminal
git diff results.tsv
git add results.tsv
git commit -m "First local benchmark run: baseline reproduced and validated"
git pushWhere this leads
The environment now just works: build, run, score, commit, repeat. The next work is profiling where the Toffoli gates are spent, and that is where the project notes on the main page pick up.
Keep going
Keep reading