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

101–110 of 129 posts

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

#101

Post by matvore »

smt88 wrote: post #99
matvore wrote: post #96

Earlier quoted context omitted.

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 guara…

I am saying you indeed should have descriptive function names.

I also agree that if the function's name leaves something to be desired then it should be commented.

You are conflating function names--global and relatively non-contextual--with variable names--which have limited scope and rely on the function name for their meaning.

In the setColor example, I would use setColor for the function name and c for the parameter name (with the caveat that C language doesn't have method names, so my reasoning about context has limited applicability to non-C languages)

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

#102

Post by [deleted] »

bluejekyll wrote: post #91
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

[deleted]

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

#104

Post by AlexanderTheGr8 »

chjj wrote: post #78
andrewqu wrote: post #72

Great work! Curious what you used as a reference when writing ?

My first bitcoin reimplementation was written in node.js and called bcoin[1]. So this is my second time reimplementing the bitcoin protocol, albeit in a very different language. Bcoin was frequently used as a reference along with bitcoin core v0.8.0-v0.11.0 when I felt like double checking consensus functions (among other things). As an aside, I personally think bitcoin core v0.8.0 is the best version of core if you…

When you say "reading bitcoin core v0.8.0", do you mean reading the source code? I want to learn more about the fundamentals (technical part) of bitcoin, but am not sure if diving into the 600k+ lines of src code is worth it. Do you know any way to understand bitcoin (or cryptocurrencies in general)?

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

#105

Post by saagarjha »

shatteredspace wrote: post #73
pizza234 wrote: post #32

Earlier quoted context omitted.

Independent researches (Microsoft/Mozilla) showed that around 70% of security vulnerabilities are caused by memory safety bugs. That's one heck of a "memory safety and stuff" :) Here's one reference: https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...

That reference and the original blog post where 70% was indicated is only dealing with security vulnerabilities in Microsoft's software, not everyone's. So while other software that isn't Microsoft most certainly has memory safety bugs, this blog doesn't speak for those, only Microsoft's. The only part that Mozilla is indicated is in reference to Rust.

Google has done similar research on their codebases and found results in line with Microsoft’s.

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

#106

Post by inter_netuser »

chjj wrote: post #19
sizzzzlerz wrote: post #18

Cloned and built on my Mac without any issues. Everything compiled and linked without warnings. A huge plus in my opinion. Other than stating that it builds two executables, there doesn't seem to be any documentation on using it. Did I miss it?

Still experimental and documentation is lacking, but right now the CLI behavior is almost identical to `bitcoind` and `bitcoin-cli`. So, for example, `$ makod -datadir=foobar -chain=testnet` will create a data directory in `./foobar` and start syncing testnet. `$ mako getblock 100 2 -chain=testnet` will return block #100 to you serialized as json. In other words, it's something akin to this: https://man.archlinux.org…

How did you write this so fast?

did you leverage anything from core or other impls at all, or entirely from scratch?

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

#108

Post by Jach »

bluejekyll wrote: post #91
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

Huh, I feel somewhat old: https://github.com/AlDanial/cloc

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

#109

Post by oars »

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

This is a great discussion of how to count code lines of code. Thanks.

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

#110

Post by jrop »

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…

"Clean code reads like prose" (Uncle Bob C. Martin)

This is quickly becoming my goto standard for measuring how clean my code is, and in my case this means ultra-descriptive variable names. I usually code in two passes: first rough things out using single-character/short names, and then go back and use LSP features to rename the variables using the language-aware tools in any modern code editor.

Post reply on HN