Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Mako – a full Bitcoin implementation in C

github.com

Post reply on HN
Print view View original

91–100 of 129 posts

Re: Show HN: Mako – a full Bitcoin implementation in C

#91

Post by bluejekyll »

cantrevealname wrote: post #81

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://…

Tokei is my go to for counting lines of code in a project: https://github.com/XAMPPRocky/tokei

Re: Show HN: Mako – a full Bitcoin implementation in C

#92

Post by kahlonel »

nynx wrote: post #9

This is very impressive, but I’ll be honest, I wouldn’t want to expose any new software written in C to the internet.

Yeah it’s not like the browser you are using, the OS you have installed, or even the firmware of the keyboard you’re typing this on is written in C.

Re: Show HN: Mako – a full Bitcoin implementation in C

#93

Post by anonporridge »

debo_ wrote: post #45
zackham wrote: post #8

This looks like a herculean effort over just the past few months. Congratulations on hitting this milestone and hopefully you can take a breather and tie up loose ends at a more comfortable pace. As much as HN has changed over the years I still think this is a place where there are a lot of people who can appreciate how you feel right now. Nicely done!

Agreed! I'm confused by the number of comments that suggest this was a waste of time because other potentially similar implementations exist. There could be a hundred of these and I'd still be interested in looking at them.

When I was young, I was taught that Benjamin Franklin taught himself to write well by reading a work, and then trying to rewrite it from memory.

I imagine a similar principle is in play here.

There's value in rewriting what already exists and works, even if it will only ever be useful to yourself.

Re: Show HN: Mako – a full Bitcoin implementation in C

#94

Post by thangalin »

rweichler wrote: post #83
cantrevealname wrote: post #81

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://…

Thx for [3]. I usually just do wc -l *.c */*.c */*/*.c */*/*/*.c */*/*/*/*.c */*/*/*/*/*.c */*/*/*/*/*/*.c

    wc -l $(find . -type f -name "*.c")

Re: Show HN: Mako – a full Bitcoin implementation in C

#95

Post by kazinator »

rweichler wrote: post #83
cantrevealname wrote: post #81

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://…

Thx for [3]. I usually just do wc -l *.c */*.c */*/*.c */*/*/*.c */*/*/*/*.c */*/*/*/*/*.c */*/*/*/*/*/*.c

  wc $(git ls-files '*.c')
This avoids counting things like generated code that is not checked in (lex.yy.c, y.tab.c or what have you), and any local test code or other junk you have laying around in the tree.

Re: Show HN: Mako – a full Bitcoin implementation in C

#96

Post by matvore »

optymizer wrote: post #74
chjj wrote: post #55

Earlier quoted context omitted.

Some of the terse variable names are the result of my adherence to a GMP-like naming convention, which I find easy to read and aesthetically pleasing. The GMP naming convention is something like: - Pointer/Data - single letter followed by a "p" - Size/Length - single letter followed by an "n" So a function declaration might look like: static void process_bytes(uint8_t *zp, const uint8_t *xp, size_t xn); The above fun…

Which code is clearer? void f(int c) { l.c = c; ... } or void setColor(int color) { label.color = color; ... } Names are more important than matching data types and sizes because they convey intent and meaning better than types.

I just did this grep for single-character function names on the Mako codebase:

    grep -r '\
And there were no matches. There were some one-character macros but they were macros repeated dozens of times in a localized area.

It seems like what's being proposed is descriptive function names with simple variable names. If the function bodies are short enough (e.g. fit on a single screen) then this seems like a good trade-off to me. IOW, the variable names are symbolic but the function names are descriptive.

The short variable names should be clear enough if you understand the purpose of the function.

Re: Show HN: Mako – a full Bitcoin implementation in C

#97

Post by kazinator »

parhamn wrote: post #84
rweichler wrote: post #83

Earlier quoted context omitted.

Thx for [3]. I usually just do wc -l *.c */*.c */*/*.c */*/*/*.c */*/*/*/*.c */*/*/*/*/*.c */*/*/*/*/*/*.c

In bash/zsh and many other shells '*/*.c' would be similar.

I don't think so. In Bash you can do this:

  bash$ shopt -s globstar
Then you can use double star syntax like this:

  bash$ wc **/*.c
The **/ will match any number of directory components, including zero; I think it's like *.c */*.c */*/*.c and so on, like what OP wrote.

Somewhat sadly, the Glibc glob function does not have an equivalent GLOB_ option for this; it's just in Bash.

Re: Show HN: Mako – a full Bitcoin implementation in C

#98

Post by cfferry »

chjj wrote: post #39
cfferry wrote: post #24

This look cool! great job, congrats. What are you using as data storage? I understand btcd uses leveldb, are you using something similar?

I considered using leveldb initially, but that would require a C++ compiler and it also requires linking to libstdc++. So at that point, you might as well just write the project in C++, which defeats the point of this project. Mako uses LMDB. Aside from Berkeley DB, it's pretty much the only key-value store in town if you want a pure C project. In the end, it worked out well because I really like LMDB. It has a very…

I am really impressed with your work! If you ever need or look for C++ collabs, let me know!

Also, consider opening a discord server to talk more about this project!

Re: Show HN: Mako – a full Bitcoin implementation in C

#99

Post by smt88 »

matvore wrote: post #96
optymizer wrote: post #74

Earlier quoted context omitted.

Which code is clearer? void f(int c) { l.c = c; ... } or void setColor(int color) { label.color = color; ... } Names are more important than matching data types and sizes because they convey intent and meaning better than types.

I just did this grep for single-character function names on the Mako codebase: grep -r '\ And there were no matches. There were some one-character macros but they were macros repeated dozens of times in a localized area. It seems like what's being proposed is descriptive function names with simple variable names. If the function bodies are short enough (e.g. fit on a single screen) then this seems like a good trade-o…

> The short variable names should be clear enough if you understand the purpose of the function.

I shouldn't have to read the function implementation to understand its purpose. Code is buggy! If the function has no name or comment explaining what it's supposed to do, I only have the (often buggy) implementation to go by.

There is no reason to use terse, non-descriptive names in 2021. It's an awful practice that guarantees easy-to-avoid bugs.

Re: Show HN: Mako – a full Bitcoin implementation in C

#100

Post by X6S1x6Okd1st »

> Contrary to what some people might tell you, multiple implementations of a protocol are a good thing. In bitcoin's case, they are necessary to mitigate the harm of developer centralization.

Important point that I didn't really get until I read more on this topic coming out of Ethereum community

Post reply on HN