aguimaraes1986

This is the "lines of code per week" metric from the 90s, repackaged. "I'm doing more PRs" is not evidence that AI is working, it's evidence that you are merging more. Whether thats good depends entirely on what you are merging. I use AI every day too. But treating throughput of code going to production as a success metric, without any mention of quality, bugs, or maintenance burden is exactly the kind of thinking developers used to push back on when management proposed it.

Turns out we weren't opposed to bad metrics! We were just opposed to being measured! Given the chance to pick our own, we jumped straight to the same nonsense.

That's one of the best things I've read this week. Thank you.

I made a CLI tool to generate Bitcoin private keys offline on air-gapped machines. Its for cold storage, you run it, it prints the keypair, and thats it. No wallet, no network, no state.

The code is around 500 lines of Rust with 6 dependencies (secp256k1, bitcoin_hashes, bech32, getrandom, zeroize, clap). 60 tests including known vectors from Bitcoin wiki and BIP173.

I built this because I wanted a key generator where I can read every line of code myself. Everything else I found was either a full wallet with too much code to check, or a Python/JS tool that I cant compile into a static binary for an offline machine.

Its v0.0.1 and not audited. I'm posting here because I want people to break it. The codebase is small enough to read in one afternoon.

Things I want feedback on:

- Threat model and security assumptions (in the docs/ folder) - Is the entropy handling correct - I wrote Base58 inline (~30 lines) to avoid a dependency, should I not have done that - Anything that would be a problem for real cold storage use

Docs: https://github.com/aguimaraes/btc-keygen/tree/main/docs Repo: https://github.com/aguimaraes/btc-keygen Website: https://aguimaraes.github.io/btc-keygen