Ethereum cryptography from a Go dev's view

I built an Ethereum wallet CLI in Go because I wanted to understand what a wallet actually does. Not just: generate a key create an address sign a transaction done That was my mental model at the beginning. After implementing the pieces myself, I realized a wallet is less like a key container and more like a collection of cryptographic decisions, where small implementation details can break compatibility, correctness, or security. This post is about what I learned while building mini-wallet , and the cryptography details that surprised me. The project is built for learning, not production key management. Why I built a wallet CLI instead of just reading about crypto Reading about cryptography is useful. Implementing it is different. Before this project, my view of wallets was much simpler: I thought they were mostly responsible for transferring assets. Once I started implementing the pieces myself, I started seeing the hidden complexity: How random data becomes a human-readable recovery phrase. How one seed generates thousands of keys. How signatures can recover public keys. Why different tools sometimes represent the same value differently. Why compatibility tests matter as much as the algorithms themselves. I chose to build a CLI wallet because you understand a system differently when you are responsible for making every part work. A library can hide complexity; building the library exposes it. Entropy → mnemonic (BIP39) Most wallets start with entropy. For a 12-word mnemonic, BIP39 starts with 128 bits of random entropy, then calculates SHA-256 of that entropy and takes the first 4 bits as the checksum: 128 bits entropy + 4 bits checksum = 132 bits Those 132 bits are split into groups of 11 bits. Each 11-bit number is an index between 0 and 2047, and BIP39 has a word list with exactly 2048 words, so each index maps to one word. The result is the 12-word mnemonic. The interesting part for me was the checksum. The wallet does not store an extra "checksum field" — th