HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
chjj
mako
C2021–2024
chjj / mako

mako

Bitcoin node written in C

4Distinct people
6Mentions
0Explicit recommenders
596GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Bitcoin node written in C

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year6 dated mentions

Observed mentions: 2021-11-15 17:40:47 UTC to 2024-07-02 08:03:13 UTC.

0123452021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC514
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

What Hacker News says

6 sources
Call me old school, but I like looking at the number of lines of code to get a feel for how big of a project something is. Mako[1] is 265,618 lines of code. The most widely accepted Bitcoin implementation[2] is 639,074 lines of code -- that's 2.5x bigger and written in a slew of languages. Mako looks like a super-impressive amount of work (and by a single person no less). [1] https://github.com/chjj/mako [2] https://github.com/bitcoin/bitcoin [3] How I calculated: find <source-directory> -type f | sed 's/.*/"&"/' | xargs wc -l EDIT: Also of interest is this "from-scratch tour of Bitcoin in Python" that was discussed here on HN a few months ago: https://news.ycombinator.com/item?id=27593772
In Show HN: Mako – a full Bitcoin implementation in C
> Likewise, size_t tells you that this is a size, no need for the "n". How do you differentiate the two input lengths? If I were to rename `xp` to `x` and `xn` to `n`, what should `yn` be renamed to? At the very least, there's going to need to be a `yn` somewhere. It's very common for code to include the type when there are two inputs to a function (even when written more verbosely): e.g. `thing_len`, and `other_thing_len`. The `p`-suffix convention can also save you in a situation like this: int x = 1; int *xp = &x; int y = 1; int *yp = &y; It avoids naming collisions, and further down in the function, you'll be able to differentiate the pointer and the value. I find it very useful. If you write multi-precision integer code in C[1] without this convention, you will end up with an unreadable mess. I certainly wish Torbjör
Read the rest
n Granlund were here to testify to this. [1] https://github.com/chjj/mako/blob/master/src/mpi.c
In Show HN: Mako – a full Bitcoin implementation in C
I wasn't originally going to look at it but this claim got me intrigued. I'd say compared to a lot of C code I've seen, yeah, you aren't lying, the average cleanliness is so clean it's sick ;) Well done! Perhaps the GP means the general crypto nature of the project lends to opaqueness. For example, I randomly clicked into https://github.com/chjj/mako/blob/master/src/crypto/chacha20... and one could ask where the magic numbers on lines 41-44 come from. Maybe it's explained in the references, or just specified without explanation as part of the protocol. I looked at the reference implementation at https://cr.yp.to/streamciphers/timings/estreambench/submissi... which has the equivalent line at L66. After finding the implementation of U8TO32_LITTLE which does some bitwise-or'ing and shifting of the first 4 items ("expa" for either sigma or ta
Read the rest
u), in Lisp I quickly verified: (format nil "0x~x" (logior (char-code #\e) (ash (char-code #\x) 8) (ash (char-code #\p) 16) (ash (char-code #\a) 24))) ;-> "0x61707865" So perhaps an argument could be made that your implementation could be slightly cleaner by using those sigma/tau constants instead of the magic numbers for the first four entries in the initial state, which would show how they're related, but that doesn't really take away the magic-ness of them, just moves the question elsewhere to why those magic strings. And it wouldn't surprise me if the answer is just the strings were arbitrarily chosen; the sigma/tau naming in the reference suggests a common domain convention to me (I'm not a crypto guy though so I don't know). Still overall this is a minor point, it looks like a clean piece of code (especially given what I'm used to seeing from browsing other bits of crypto code here and there) and random sampling of other parts of the program are at least as nice and nicer, especially when they're not doing anything complicated, which I've seen plenty of C code make a mess of. While it might not always be clear why something is done, it's at least clear what's going on and where to jump for more context, what the interfaces are, and things are well-named such that I could probably go find references for some of the whys if they actually needed to be answered. e.g. in mempool.c's btc_mempool_verify, I have no clue what "Annoying process known as sigops counting" refers to, but even without that comment, the simple if condition's pieces are well-named so I could go search for more info on sigops, which I wouldn't even expect to be part of the code (at least here) anyway. (Edit: It also occurs to me that a low ratio of comments and explanation to code could also be what is meant by obfuscation. To me that's not a large part of the cleanliness concept, though it does factor into other qualities. I consider the sqlite codebase to be some of the most beautiful C code on the planet, wonderfully documented and tested, and as a whole its beauty more than makes up for some stylistic or organizational quirks I don't exactly like. Not to say that style is totally unimportant, but neither this nor sqlite are exemplars of ugly C with lots of insane typedefs, super macros, inconsistencies, syntax abuses everywhere, and mngld_nms like vowels cost $100 a pop. For a project I consider "not so good" C code, I reference Enlightenment Foundation Libraries...)
In Show HN: Mako – a full Bitcoin implementation in C
> I obsess over clean code Yep, it shows. I got curious over the GP's comment, and I spot checked json.c[1] and json.h[2]. They're cleanly written, your data structures reflect your use and I can get an idea of what does what through the code alone. Trying to figure out what could be considered obscure. For example would if (!btc_amount_import(&x, obj->u.string.ptr)) return 0; be considered obscure? Cause if you know the structure of a json_value, then you get what the phrase says. Well thought out and cleanly written code, I'd say. [1] https://github.com/chjj/mako/blob/master/src/json.c [2] https://github.com/chjj/mako/blob/master/include/mako/json.h
In Show HN: Mako – a full Bitcoin implementation in C

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.