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

121–129 of 129 posts

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

#121

Post by HappySweeney »

chjj wrote: post #35
spuz wrote: post #22

Earlier quoted context omitted.

Very impressive work. Was there a deadline that you were trying to meet? What was the reason for the all-nighters?

No deadline. I just have a tendency towards obsession when I'm working on a project I'm very interested in. I tend to get into a kind of manic phase where I can't sleep even if I wanted to. There's no real telling when that phase will end. So I end up coding for an unhealthy amount of time. I don't recommend it to anyone.

I have the same thing, self-diagnosed as monomania. I had to train myself to stop thinking about my obsession when not at it, and the condition eventually subsided enough that it doesn't completely screw up my life anymore.

nb: looking it up on wikipedia, it seems that monomania was a 19th century psychiatric diagnosis, and is no longer considered a real condition.

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

#122

Post by marto1 »

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

this looks hilarious and I guess it works. nice one!

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

#124

Post by timobile »

AlexanderTheGr8 wrote: post #104
chjj wrote: post #78

Earlier quoted context omitted.

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)?

I highly recommend the books "Mastering Bitcoin" by Andreas Antonopoulos (technical, for beginners) and "Programming Bitcoin" by Jimmy Song (very technical, advanced).

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

#125

Post by sanderjd »

freemint wrote: post #123
sanderjd wrote: post #90

Earlier quoted context omitted.

Self documenting code is good in every language.

Self documenting code is not good in BrainFuck.

It would be, if it were possible. That it isn't is why that is a bad language. There are others in that same boat.

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

#126

Post by UncleMeat »

postalrat wrote: post #60
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...

"memory safety bugs" sounds pretty broad. What sort of vulnerability doesn't involve memory access?

Something like SQL injection is a vulnerability that is not exploiting a memory error.

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

#127

Post by sanderjd »

defgeneric wrote: post #117
sanderjd wrote: post #68

Earlier quoted context omitted.

I believe that this is a cop out, an excuse for a culture of poor conventions. In all languages, good functions should be named well, simply organized, and doing only one or two things, and without many arguments passed in. Also in all languages, parameters and variables should be named expressively. There's no reason C should be exempt from this.

Not really. It's because the interfaces in C tend to follow a common pattern that verbose variable names can get in the way. If we have int alter_struct(some_struct_t *s, void *xp, size_t xn); then it's pretty obvious that the data pointer xp with size xn is going to modify whatever struct object we have at pointer s. The variable names can be shortened because the function interface follows a common convention. The…

"The data pointer is going to modify the struct" is not the only information that is useful.

Again, it is true in every language that there are some basic patterns to what interfaces look like. That doesn't tell you anything about what the application-specific logic implementing those interfaces is intended to do. For that, it is useful to name things such that they describe what they represent in the domain of the application or library.

If it is a generic function, there are good names for that as well (for instance, some kind of copy function would still have meaningful names like "from" and "to").

But the example given by the author here was not that, it specifically acted on transactions. In that case, the input bytes were meant to represent a "raw transaction" and the output struct is meant to represent a "transaction".

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

#128

Post by rweichler »

kazinator wrote: post #97
parhamn wrote: post #84

Earlier quoted context omitted.

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.

    -bash: shopt: globstar: invalid shell option name

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

#129

Post by kazinator »

rweichler wrote: post #128
kazinator wrote: post #97

Earlier quoted context omitted.

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.

-bash: shopt: globstar: invalid shell option name

Bash's NEWS file says that globstar was added between bash-3.2 and bash-4.0.

In the git repo, there is a 2009-dated commit 3185942a5234e26ab13fa02f9c51d340cec514f8 where the material appears, as a snapshot import.

Make sure you're using "shopt -s globstar" and not "shopt -o globstar".

Post reply on HN