[HN Gopher] Show HN: Mako - a full Bitcoin implementation in C
___________________________________________________________________
Show HN: Mako - a full Bitcoin implementation in C
Author : chjj
Score : 67 points
Date : 2021-11-15 17:40 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| [deleted]
| cfferry wrote:
| This look cool! great job, congrats.
|
| What are you using as data storage? I understand btcd uses
| leveldb, are you using something similar?
| jlrubin wrote:
| nicely done jj!
| noxer wrote:
| Can't help but shake my head over this incredibly impressive
| waste of time.
| sizzzzlerz wrote:
| 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?
| chjj wrote:
| 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/man/bitcoind.1
|
| https://man.archlinux.org/man/community/bitcoin-cli/bitcoin-...
|
| Please let me know how things go on Apple. I have yet to test
| it on a Mac. It's possible Mac has some issues since the event
| loop backend is using poll(2). Apple has been known to break
| poll every now and then.
| tmaly wrote:
| This looks super interesting.
|
| One thing that kinda bothers me is that most of the tests are
| just
|
| #include <stdint.h> #include <stdlib.h> #include <string.h>
| #include "lib/tests.h"
|
| int main(void) { return 0; }
| chjj wrote:
| Yeah, I'm embarrassed about that. It's way behind on tests.
|
| The past 2 months of limited sleep were a massive scramble just
| trying to get everything implemented and trying to get the damn
| thing to sync properly. Things seem to work in practice, but
| it's very scary not having high test coverage, especially with
| a project like this. Now that everything has solidified and my
| sleep schedule has normalized a bit, it's my intention to take
| the time to write proper tests.
| brighton36 wrote:
| Did you learn that 'the implementation is the spec' ? (Does
| that mean Bitcoin is fiat?)
| potiuper wrote:
| Not to belittle the work, but it is always prudent to research
| what the other implementations are before possibly doing
| duplicate work and providing that comparison along with the new
| work for justification of it. For example,
| https://en.bitcoin.it/wiki/Software#C shows picocoin (libccoin),
| which Github also lists as being C. What makes this or what is
| desired to for this to be different from the alternative(s)? It
| certainly seems a non-trivial matter to have completely
| reimplemented the necessary GNU Multiple Precision Arithmetic
| Library or similar dependencies such as specific compiler
| extensions.
| vmception wrote:
| The point wasn't for this to be desired by anyone
|
| It is just a show and tell
|
| And now we also have a new client on the network!
| chjj wrote:
| Right. Perhaps I should explain this in the readme.
|
| To be clear:
|
| Libbtc is a small bitcoin library meant for everyday things:
| signing transactions, maintaining an SPV wallet, etc. It's good
| at what it does, but you wouldn't be able to actually sync and
| validate an entire blockchain with it.
|
| I suppose picocoin is the most similar to mako, but I think it
| falls short of being a "full node" in that it doesn't provide a
| mempool, miner, or RPC (from what I can tell). I'm also not
| clear on how it is storing UTXOs. It looks incomplete right
| now, but maybe jgarzik could give more insight on that.
|
| Mako is a _full_ reimplementation of bitcoin. It's an
| alternative to bitcoin core.
| auggierose wrote:
| It's not a paper, and no academic who is not interested in it
| anyway is going to make stupid comments about related work. No
| need to justify making what you wanted to make. Well done.
| zackham wrote:
| 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!
| chjj wrote:
| Thanks. This was definitely the hardest project I've worked on
| in my life. I fear I may have shaved a few years off my life
| with all of the all-nighters I pulled with this, so it's good
| to hear recognition for the work. :)
| spuz wrote:
| Very impressive work. Was there a deadline that you were
| trying to meet? What was the reason for the all-nighters?
| chjj wrote:
| 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.
| johnnyApplePRNG wrote:
| When you really love working on something, sometimes you
| just can't sleep.
|
| I love that state of being.
| nynx wrote:
| This is very impressive, but I'll be honest, I wouldn't want to
| expose any new software written in C to the internet.
| 0xFFFFFFFFF wrote:
| Can I ask you why? I mean, I know about memory safety and
| stuff, but it is _that_ bad?
| pizza234 wrote:
| 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...
| roca wrote:
| Yes it is.
| [deleted]
| jazzyjackson wrote:
| I wouldn't be too worried about a bitcoin node since the whole
| point is to stay in consensus with the rest of the network
| yardstick wrote:
| Anything interesting on your choice of project name?
| chjj wrote:
| Its placeholder name was originally "libsatoshi", but I was
| worried that would cause confusion between this project and
| bitcoin core.
|
| I spent the past few days thinking of names. Mako came to mind
| because I had recently been playing through the original FF7
| (maybe the first time in ~10 years). It's short, memorable,
| looks cool. It checked all the boxes. On top of that, pretty
| much every name involving the words "btc", "coin", etc. is
| already taken when it comes to bitcoin projects.
|
| That said, apparently there is a wayland notifier also named
| "mako", so I may have to think up a different name here. =/
| jazzyjackson wrote:
| I'm loving the well commented and standalone inplementations of
| crypto-primatives, will definitely be studying these.
|
| One question, in src/crypto/rand.c:25 you have a standalone RNG
| but comments say it is not used internally? what is it used for?
| chjj wrote:
| Most of the crypto is from my more general crypto library
| libtorsion: https://github.com/bcoin-org/libtorsion
|
| I originally wanted to vendor my libtorsion code and link to
| it, but it felt clunky since libtorsion pulls in a ton of
| crypto that bitcoin doesn't need. Also, since I was focusing on
| just a few algorithms, it gave me the opportunity to optimize a
| lot of them (in particular, the ECC backend was optimized for
| secp256k1 whereas in libtorsion it supports all kinds of
| curves).
|
| Because of all of this, there's probably some leftover
| comments. That comment isn't true anymore. rand.c is definitely
| used internally for libmako, just not libtorsion.
|
| edit: fixed link.
| beebmam wrote:
| Some of this C code looks extremely obfuscated. Not a fan.
| chjj wrote:
| Do you mind elaborating? I obsess over clean code, so any
| criticism is appreciated.
| arcticbull wrote:
| It looks super clean to me, the only exception being for the
| love of all that's good and holy always brace your one-line
| if statements and loops.
|
| You don't want your own "goto fail" do you? ;) [1]
|
| I think you did a great job.
|
| [1] https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-
| got...
| MonkeyClub wrote:
| > 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
| dang wrote:
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| https://news.ycombinator.com/newsguidelines.html
|
| Would you mind reviewing the Show HN rules too? Your comment
| broke them as well, and we're especially trying to avoid the
| culture of shallow putdowns when people are sharing their own
| work.
|
| https://news.ycombinator.com/showhn.html
| defgeneric wrote:
| I found it to be quite neat. The separation of compilation
| units alone shows the author knows what he's doing. Perhaps you
| have trouble with C idioms.
| isaiahg wrote:
| As someone who's teaching themselves C could you elaborate?
___________________________________________________________________
(page generated 2021-11-15 23:00 UTC)