Cool to study. Disappointed there are zero comments and the most terse variable names as possible. Almost like it was js-minified.
It's called C
Show HN: Mako – a full Bitcoin implementation in C
71–80 of 129 posts
Re: Show HN: Mako – a full Bitcoin implementation in C
#72Great work! Curious what you used as a reference when writing ?
Re: Show HN: Mako – a full Bitcoin implementation in C
#73Earlier quoted context omitted.
Can I ask you why? I mean, I know about memory safety and stuff, but it is that bad?
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.
Re: Show HN: Mako – a full Bitcoin implementation in C
#74Cool to study. Disappointed there are zero comments and the most terse variable names as possible. Almost like it was js-minified.
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;
...
}
void setColor(int color) {
label.color = color;
...
}
Re: Show HN: Mako – a full Bitcoin implementation in C
#75Re: Show HN: Mako – a full Bitcoin implementation in C
#76Some of this C code looks extremely obfuscated. Not a fan.
What do you mean "obfuscated"? This is the cleanest C code I've ever read in quite a while.
Re: Show HN: Mako – a full Bitcoin implementation in C
#77Earlier 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.
If one of the largest software companies around can't get memory safety right, it does make a guy start to think that maybe most people should avoid having to handle it if they can.
Re: Show HN: Mako – a full Bitcoin implementation in C
#78Great 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 want to learn bitcoin from it. It's a lot more straightforward than later versions. I personally don't enjoy reading any version beyond v0.11.0.
This is also the reason mako doesn't support taproot yet. That code is very new and isn't present in upstream bcoin. I could try to implement it from the BIPs alone, but I won't know what intricacies are present in the actual bitcoin core code until I actually read it.
Re: Show HN: Mako – a full Bitcoin implementation in C
#79Earlier quoted context omitted.
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.
If one of the largest software companies around can't get memory safety right, it does make a guy start to think that maybe most people should avoid having to handle it if they can.
I don't have a fully developed opinion on that, so I won't try to come up with one on the spot. My comment is purely because I felt the parent left out details about the blog post that should have been pointed out.
Re: Show HN: Mako – a full Bitcoin implementation in C
#80Earlier quoted context omitted.
I disagree. The function name gives context as to what they're meant to represent if you understand the convention. One of the conventions in mako is something like: int btc_tx_import(btc_tx_t *z, const uint8_t *xp, size_t xn); This function deserializes a raw transaction of `xn` bytes at `xp` and stores the result in the transaction `z`. Zero is returned on failure. What would be the alternative here? I suppose I co…
Your english language description of it gives some good clues to the alternative: int btc_tx_import(btc_tx_t *transaction, const uint8_t *raw_transaction, size_t raw_transaction_size); Or since clearly `tx` is already a convention for "transaction", it could be `tx`, `raw_tx`, and `raw_tx_size`. And sure, I have no problem with the `p` and `n` stuff, so it could be `txp`, `raw_txp`, `raw_txn`. But from your descripti…
Pythonic