DEV Community: Mohsen

What I learned from reading Go's chan.go

Mohsen — Thu, 24 Sep 2026 07:11:04 +0000

Before reading chan.go, my mental model of a channel was one sentence: a safe way for goroutines to send values to each other. That sentence was true, but it was not enough. I could not answer simple follow-up questions: where does a blocked goroutine actually wait? Is an unbuffered channel secretly a buffer of size one? Why does select pick a random case?

So I spent a week reading src/runtime/chan.go (and later select.go) from Go 1.26. This post is what I found, written as the questions I had.

1. What is a channel, really?

Every make(chan T, n) gives you a pointer to an hchan. Here it is, lightly trimmed:

type hchan struct {
    qcount   uint           // values currently in the buffer
    dataqsiz uint           // buffer capacity (the n in make)
    buf      unsafe.Pointer // the ring buffer itself
    elemsize uint16
    closed   uint32
    elemtype *_type
    sendx    uint  // next slot to write
    recvx    uint  // next slot to read
    recvq    waitq // goroutines blocked on receive
    sendq    waitq // goroutines blocked on send
    lock     mutex
}

Three groups of fields: a ring buffer (buf, sendx, recvx, qcount), two wait queues (recvq, sendq), and one lock that protects all of it.

The lock is runtime.mutex, not sync.Mutex. At first I thought that was just "the runtime likes its own tools". The real reason is circularity: sync.Mutex parks goroutines through the scheduler, and the scheduler is exactly the code that uses hchan. The runtime cannot build its foundation on top of something that is built on top of it.

2. Is an unbuffered channel a buffer of size one?

No. When dataqsiz == 0, buf holds nothing. A send and a receive have to meet.

If a receiver is already waiting, the sender copies its value directly into the receiver's variable, which lives on the receiver's stack. The source has a comment about this that surprised me:

Sends and receives on unbuffered or empty-buffered channels are the only operations where one running goroutine writes to the stack of another running goroutine.

That is why an unbuffered channel is a synchronization point and not just a pipe: there is no place for the value to sit, so both sides must be there.

3. How many ways can a send end?

Reading chansend top to bottom, I counted these paths (for a normal, blocking send):

nil channel: the goroutine parks forever. There is no one to wake it.
closed channel: panic("send on closed channel"). It does not return quietly.
a receiver is waiting in recvq: dequeue it and hand the value over directly, even if the channel is buffered. The buffer is skipped.
buffer has space: copy into buf[sendx], advance sendx, done.
otherwise: wrap this goroutine in a sudog, put it on sendq, and gopark.

Path 3 was the most surprising one for me. If a receiver is already waiting, the value never touches the buffer. The source even writes this as an invariant: in a buffered channel, qcount > 0 implies recvq is empty. You never have data in the buffer and a waiting receiver at the same time.

4. Full buffer and a waiting sender: who gets what?

Say the buffer is full and a sender is parked on sendq. Now a receiver arrives. The naive idea is "give the receiver the sender's value". That would break FIFO order, because older values are still in the buffer.

What recv actually does:

// Queue is full. Take the item at the head of the queue.
// Make the sender enqueue its item at the tail of the queue.
// Since the queue is full, those are both the same slot.
qp := chanbuf(c, c.recvx)
typedmemmove(c.elemtype, ep, qp)                // oldest value -> receiver
typedmemmove(c.elemtype, qp, sg.elem.get())     // sender's value -> freed slot
c.recvx++
if c.recvx == c.dataqsiz {
    c.recvx = 0
}
c.sendx = c.recvx

The receiver takes the oldest value, and the waiting sender's value drops into the slot that just became free. Because the buffer is full, the head and the tail are the same slot. One read, one write, order preserved. I think this is the nicest piece of code in the file.

5. What is a `sudog`, and why not just queue the goroutine?

A sudog is "a goroutine waiting on one thing". It holds a pointer to the goroutine (g), a pointer to the value being sent or received (elem), and links for the wait queue.

Why a separate struct instead of putting the goroutine itself in recvq? Because one goroutine can wait on many channels at once. That is exactly what select does. Each case gets its own sudog, all pointing to the same goroutine. When one of them fires, the runtime has to remove the others. So the relation is one goroutine to many sudogs, and the queue holds sudogs.

6. How does `select` use all of this?

select.go builds on the same pieces. selectgo works in three passes:

Poll: look at every case in a random order (pollorder). If one is ready, do it and return. Random order is for fairness: a busy channel written first in your code should not starve the others.
Enqueue and park: nothing ready and no default? Put a sudog on the queue of every channel in the select, then gopark once.
Wake up and clean up: whoever woke us set gp.param to the winning sudog. Dequeue all the other sudogs from their channels.

Before touching the channels, select locks them all. The lock order is not the order in your code. It is sorted by the address of each hchan (lockorder). If two goroutines run selects over the same channels in opposite order, a code-order lock could deadlock. A single global order (addresses) makes that impossible.

One practical trick falls out of this: a nil channel case is never ready. The runtime just leaves it out. So inside a loop you can set ch = nil to turn a case off without restructuring the select.

Honest note: I read selectgo carefully, wrote notes, and five days later I could only explain half of it (I scored myself 5/10). Things I only read faded. Things I built stayed. That is the reason for the next section.

7. I built one myself

To check whether I understood hchan, I wrote a bounded channel with a sync.Mutex and two sync.Conds (notFull, notEmpty).

My first version stored items in a slice and received with buf = buf[1:]. It worked in small tests. The problem: re-slicing moves the start forward, and the space at the beginning is never reused. After enough sends and receives, the buffer looked full even when it had free space. The fix was the same idea as hchan: a fixed array with a read index and a write index that wrap around.

func (c *BoundedChannelTest[T]) Send(v T) {
    c.mu.Lock()
    defer c.mu.Unlock()

    if c.closed {
        panic("send on closed channel")
    }
    for c.count == len(c.buf) {
        c.notFull.Wait() // releases mu while waiting
        if c.closed {
            panic("send on closed channel")
        }
    }

    c.buf[c.sendx] = v
    c.sendx = (c.sendx + 1) % len(c.buf)
    c.count++
    c.notEmpty.Signal()
}

I even named the indexes sendx and recvx, like hchan.

A week later I closed it and rewrote it from memory, without notes or AI. It passed with go test -race (5 producers, 5 consumers, 1000 items each). That rebuild is what convinced me I understood it.

What my version does not have, compared to the real one: direct handoff to a waiting receiver (path 3), sudogs, or any way to take part in a select. sync.Cond wakes someone up. hchan knows exactly who is waiting and gives them the value.

8. What I take away

A Go channel is not just a queue. It is a ring buffer, two wait queues, and a lock, plus a scheduler that can park and wake goroutines and copy values straight between their stacks.

After chan.go, the rest of the sync package read differently. sync.Once is a mutex plus an atomic flag, and the detail I missed when I rebuilt it was that the standard library marks it done with a defer, so even a panicking f counts as "done". sync.Pool mostly avoids locks by giving each P (the scheduler's processor) its own local pool. Same questions every time: where does the data live, who waits, and who wakes them?

If you are learning Go concurrency, my advice is: read chan.go once, then close it and build a small version yourself. The reading gives you the words. The building makes them stay.

Source: Go 1.26, src/runtime/chan.go and src/runtime/select.go. Exercises: github.com/mohsenm4/go-fundamentals.

Ethereum cryptography from a Go dev's view

Mohsen — Sun, 13 Sep 2026 06:20:02 +0000

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" — the checksum is embedded in the words themselves. In my implementation it is calculated directly from the entropy:

checksumBits := bits / 32

hash := sha256.Sum256(entropy)
firstByteBits := fmt.Sprintf("%08b", hash[0])
checksum := firstByteBits[:checksumBits]

bitstring := ""
for _, b := range entropy {
    bitstring += fmt.Sprintf("%08b", b)
}

bitstring += checksum

The resulting bit string is then split into 11-bit chunks and mapped to the BIP39 word list:

entropy
   |
SHA-256
   |
checksum bits
   |
entropy + checksum
   |
11-bit groups
   |
BIP39 words

When recovering the wallet, the process runs in reverse: the words are converted back into bits, the entropy is separated from the claimed checksum, SHA-256 is calculated again, and the two checksums are compared. A handful of bits is enough to catch most human input mistakes.

Seed → keys (BIP32/BIP44)

The mnemonic is not the private key. It is used to generate a seed, and that seed becomes the root of a hierarchical deterministic (HD) wallet:

mnemonic
   |
   v
seed
   |
   v
master key
   |
   +---- account
   |       |
   |       +---- address
   |       +---- address
   |
   +---- account
           |
           +---- address

BIP32 lets us derive a whole tree of keys from one master key. The most important detail here is the difference between hardened and non-hardened derivation.

Hardened derivation

With hardened derivation, creating a child key requires the parent private key — an xpub alone is not enough. In the path parser, I mark hardened indices by adding HardenedOffset:

hardened := strings.HasSuffix(seg, "'")
if hardened {
    seg = seg[:len(seg)-1]
}

n, err := strconv.ParseUint(seg, 10, 32)
if err != nil {
    return nil, fmt.Errorf("invalid path segment %q: %w", seg, err)
}

index := uint32(n)

if !hardened && index >= HardenedOffset {
    return nil, fmt.Errorf("non-hardened index %d exceeds 2^31", index)
}

if hardened {
    index += HardenedOffset
}

So:

44'  -> 44 + 0x80000000
60'  -> 60 + 0x80000000
0    -> 0
0    -> 0
5    -> 5

Non-hardened derivation

With non-hardened derivation, someone with only an xpub can derive child public keys. That is useful for watch-only wallets, but it has a dangerous edge case. If an attacker has:

the parent xpub
one child private key

they can compute the parent private key — and once that is compromised, the whole subtree below it is compromised too. This is the well-known xpub + child-private-key attack, and it is why the first three levels of the path are hardened.

Ethereum uses the BIP44 path:

m/44'/60'/0'/0/n

Meaning:

m → master key
44' → BIP44 purpose
60' → Ethereum
0' → account index
0 → change
n → address index

The default path is also what my CLI uses when deriving Ethereum addresses.

secp256k1 signing and recovery

Ethereum uses the secp256k1 elliptic curve. A signature is usually written as:

(r, s, v)

The interesting part is v. Many cryptographic systems send the public key together with the signature. Ethereum does something different: the signature carries enough information to recover the public key.

signature
    |
    v
recover public key
    |
    v
derive Ethereum address

This matters because an Ethereum transaction has no from field. The sender is recovered from the signature, which saves 64 bytes of public key per transaction.

It is also where compatibility problems start showing up, because different tools represent v differently:

go-ethereum's SigToPub expects a recovery ID of 0/1
wallet tooling can provide 27/28

They carry the same recovery information, but they are not interchangeable byte-for-byte. I ran into exactly this problem. Instead of teaching the CLI about every wallet's signature format, I moved the compatibility logic into the signer layer:

if v := sig[64]; v == 27 || v == 28 {
    normalised = make([]byte, 65)
    copy(normalised, sig)
    normalised[64] = v - 27
}

hash := hashPersonalMessage(message)
pubKey, err := crypto.SigToPub(hash.Bytes(), normalised)
if err != nil {
    return common.Address{}, err
}

return crypto.PubkeyToAddress(*pubKey), nil

Now RecoverPersonal accepts either representation. A small detail — but exactly the kind that makes two otherwise-correct implementations incompatible.

There is a third use of v that is easy to confuse with these. For transactions, EIP-155 uses v for replay protection:

v = chainId * 2 + 35/36

That is different from the 0/1 recovery ID of the signing primitive and from the 27/28 convention of personal-message signing. Same field, three conventions.

Keystore V3: encryption is more than encrypt/decrypt

Ethereum keystore files protect private keys with three pieces:

scrypt

scrypt is the key derivation function: it turns the user's password into a 32-byte derived key. That key is split in two:

derivedKey, err := deriveKey(password, salt)
if err != nil {
    return KeystoreV3{}, err
}

encKey := derivedKey[:16]
macKey := derivedKey[16:32]

The first 16 bytes become the AES key; the remaining 16 bytes are used for the MAC.

AES-128-CTR

The private key is encrypted using AES-128 in CTR mode:

block, err := aes.NewCipher(encKey)
if err != nil {
    return KeystoreV3{}, err
}

stream := cipher.NewCTR(block, iv)
ciphertext := make([]byte, len(secret))
stream.XORKeyStream(ciphertext, secret)

CTR turns AES into a stream cipher, so the ciphertext is exactly as long as the private key and no padding is involved.

MAC

The MAC protects the ciphertext against modification:

keccak256(derivedKey[16:32] ‖ ciphertext)

In code:

h := sha3.NewLegacyKeccak256()
h.Write(macKey)
h.Write(ciphertext)
mac := h.Sum(nil)

So the overall flow looks like:

password
   |
   v
  scrypt
   |
   v
derived key
   |
   +---- first 16 bytes ----> AES-128-CTR key
   |
   +---- last 16 bytes -----> MAC key
                                |
ciphertext <--------------------+
   |
   v
keccak256(macKey || ciphertext)
   |
   v
MAC

At first, a simple round-trip test looks like enough:

encrypt
   |
decrypt
   |
same private key

But this can hide bugs: if encryption and decryption share the same mistake, the test still passes. That is why reference vectors matter — they test compatibility with the actual format, not with your own implementation.

One of the bugs I hit was hard-coded scrypt parameters. The reference vector intentionally used:

p = 8
r = 1

while my decryption path had the parameters hard-coded instead of reading them from the keystore JSON. My own round-trip tests passed, because both sides shared the same assumption. The reference vector did not. That was a much more useful failure.

Messages, not hashes

A signature alone does not explain what was signed — a hash is just 32 bytes. The same signing primitive could be used for:

a transaction
a login message
a smart contract interaction
structured application data

This is why Ethereum has standards such as EIP-191 and EIP-712.

EIP-191

For personal messages, the message is not hashed directly. Ethereum adds a prefix that includes the message length:

"\x19Ethereum Signed Message:\n" + len(message) + message

My implementation does exactly that:

func hashPersonalMessage(message []byte) common.Hash {
    prefix := fmt.Sprintf("\x19Ethereum Signed Message:\n%d", len(message))

    data := append([]byte(prefix), message...)
    return crypto.Keccak256Hash(data)
}

The \x19 byte is not a valid start of an RLP-encoded transaction, so a signed message can never be replayed as a transaction. The signature is tied to the personal-message format instead of being a raw signature over arbitrary bytes.

EIP-712

For structured data, EIP-712 goes further. Instead of an opaque blob, it defines typed data with a schema, a domain separator, and a structured hashing process. The final digest is:

keccak256(
    "\x19\x01" ||
    domainSeparator ||
    hashStruct(message)
)

The last step of my implementation:

data := append([]byte("\x19\x01"), domainHash...)
data = append(data, messageHash...)

return crypto.Sign(crypto.Keccak256(data), priv)

The domain separator binds the signature to context such as:

application
version
chain ID
verifying contract

In my tests, a signature made with chainId = 1 recovers to a different address when checked against chainId = 999 — that is the domain separator doing its job.

Three bugs my tests caught

This was the most valuable part of the project. The biggest lessons did not come from implementing algorithms; they came from failing tests.

Bug 1: `v` format mismatch

I took signatures with v = 27/28 from wallet tooling and passed them straight into SigToPub, which expects 0/1. Recovery returned the wrong address.

My first fix was inside the CLI command. Then I realized the conversion belonged in the signer layer: RecoverPersonal should accept both formats and normalize before recovery.

The lesson:

Compatibility logic should live where the concept belongs.

Bug 2: hard-coded scrypt parameters

My keystore tests passed — because encryption and decryption made the same assumption. The reference vector intentionally used p=8, r=1, while my decryption path ignored the parameters in the keystore JSON. The implementation was consistently wrong, and only the external vector exposed it.

The lesson:

Passing your own tests does not always mean you implemented the standard correctly.

Reference vectors are not optional polish for cryptographic code. They are part of the implementation.

Bug 3: unsafe type assertion in `HashStruct`

The third bug was in EIP-712 HashStruct. When processing a nested typed-data field, I assumed the value was always a map[string]any:

nested := value.(map[string]any)

A bare type assertion panics when the input has the wrong shape. The fix:

nested, ok := value.(map[string]any)
if !ok {
    return nil, fmt.Errorf(
        "field %s must be a nested struct (map[string]any), got %T",
        field.Name,
        value,
    )
}

Now malformed typed data produces an error instead of crashing the process.

The lesson:

Crypto security is not only about cryptographic algorithms.

Parsing, validation, and handling unexpected input are part of security too.

What's next

The next milestone is smaller than I originally thought. v0.1.0 is the MVP tag:

EIP-712 in the CLI
tag v0.1.0
call the MVP done

After that, transaction lifecycle work moves to a separate project, blockchain-insight:

transaction creation
signing
broadcasting
tracking transaction status

Separating those concerns is another thing this project taught me: a wallet does not need to become an entire blockchain application just because it can sign messages.

Final thoughts

The biggest thing I learned is that cryptography is not just mathematics — it is also engineering. The algorithms are one part of the problem. The other part is everything around them:

standards
byte formats
compatibility
serialization
validation
reference vectors
error handling
API boundaries

A 27 instead of a 0. A hard-coded KDF parameter. A type assertion without ok. Each one looks like a tiny detail, and each one is the difference between "works on my machine" and an implementation that actually interoperates with the Ethereum ecosystem.

Building this wallet changed how I look at Ethereum. I no longer see a wallet as a key container; I see it as a system where every small decision matters. That is probably the most useful thing I got from building it myself.

Code: github.com/mohsenm4/mini-wallet. Built for learning — not for production key management.

DEV Community: Mohsen

What I learned from reading Go's chan.go

1. What is a channel, really?

2. Is an unbuffered channel a buffer of size one?

3. How many ways can a send end?

4. Full buffer and a waiting sender: who gets what?

5. What is a sudog, and why not just queue the goroutine?

6. How does select use all of this?

7. I built one myself

8. What I take away

Ethereum cryptography from a Go dev's view

Why I built a wallet CLI instead of just reading about crypto

Entropy → mnemonic (BIP39)

Seed → keys (BIP32/BIP44)

Hardened derivation

Non-hardened derivation

secp256k1 signing and recovery

Keystore V3: encryption is more than encrypt/decrypt

scrypt

AES-128-CTR

MAC

Messages, not hashes

EIP-191

EIP-712

Three bugs my tests caught

Bug 1: v format mismatch

Bug 2: hard-coded scrypt parameters

Bug 3: unsafe type assertion in HashStruct

What's next

Final thoughts

5. What is a `sudog`, and why not just queue the goroutine?

6. How does `select` use all of this?

Bug 1: `v` format mismatch

Bug 3: unsafe type assertion in `HashStruct`