How to Build Your Own Blockchain Part 3 – Writing Nodes That Mine and Talk | Hacker News Reader

How to Build Your Own Blockchain Part 3 – Writing Nodes That Mine and Talk

bigishdata.com

282 pointssidcool21 comments

Hey guys, I'm actually the one who wrote this. Really glad to see it here and that people think it's worthwhile.

I mention this in the post, but the reason I started this is to learn more about how blockchains operate. I've never been that into them, I don't invest in the coins that the big ones operate with, but am more interested in how they work and other use cases. As with everything, the best way to learn is to write one yourself. I definitely don't consider myself an expert, but when I go back and read the Satoshi paper and Ethereum's white paper, it makes way more sense than before.

Let me know if you have questions, or if you don't agree with something I wrote. Want to make sure people reading this can get more info out of it than many of the other articles on this topic.

also posted here: https://coursefriend.com/tag/blockchain/new

Thanks for the blog series, Jack! When is your ICO?

Hah yeah that's not gonna happen. If it were, you'd get to give it a name though. Maybe something to do with Master and Margarita, one of the better books people have said I should read.

Who's ready to buy Behemoth?

FYI: I've collected more article series and samples about building your own blockchain(s) at the Awesome Blockchains page [1]. Anything missing? Let us know. Happy blockchaining. [1] https://github.com/openblockchains/awesome-blockchains#artic...

Small nitpick, I ran the example and found I could only create 3 blocks. (I'm on ubuntu if that matters) looking more into it, it seems like the issues is the glob.glob in sync.py is not always read in order so the chain is out of order. My solution was to move the add block to chain call lower, and to sort the blocks first. After changing that code it seemed to work fine.

Ahh yeah, on a Mac, using os.list_dir leaves 10.json ahead of 2.json. I heard from someone else on Linux that had that problem. If you have the code that works would you make a pull request and I'll throw that in?

This is pretty universal. Use lexicographic sorting.

Well yes. That's why I put at least 6 characters of 0 in front of the index of a block,so the filenames were 000001.json, and used glob rather than list_dir. But that didn't work for Linux.

Can't wait for part 4, I've been following this series very closely and really appreciate the details the author has included. Way more in-depth than the typical "build your own blockchain" submission.

Thanks, really like hearing people like what I wrote. And definitely trying to write more in depth than some of the other posts on this topic. Hopefully more to come.

This is really neat...I've been working on the exact same thing in my spare time with the intent to learn the guts of blockchains. Our code is very similar, unsurprisingly. Mine is also Python but I'm running in with Serverless using Redis at the block store.

What I've found is that it's pretty easy to build out the basics, but then very complicated to cover all of the hard cases (specifically, resolving disparate chains between nodes). The deeper I dig the more appreciation I have out there for the "real" blockchain implementations and implementors.

Random idea: a logging/audit framework with built in blockchain support to prove events happened/didn't happen. Maybe an extension to slf4j?

You can sign log messages several ways without blockchain. Even systemd (cough) has support for one crude form, which it calls forward secure sealing. Not sure what proof-of-work, which seems to be the subtext and is really intended for distributed lack of trust, would buy you in this situation.

I can think of a reasonable blockchain-like implementation for logs, actually: chunk up the log, sign, include the hash of the prior sig as the first log message in the new chunk. Boom, blockchain! Throw in Merkle trees somehow and you’ve got yourself a VC-funded startup. You’re welcome.

This would be useful to ensure you aren't missing any log data...an issue near and dear to my heart these days.

Indeed. That might actually be a good idea for government records and other legal documents.

Blockchains don’t help with ensuring you’re not missing any data, their purpose is to define which series of logs is the “right one”, which doesn’t make much sense in anything but a distributed context. The purpose of the Bitcoin blockchain is to define the “right” log of transactions, that everyone agrees is the right log.

This series has been so in-depth, I can't wait to part 4, thanks so much, this really helped.

I also agree with the extension to slf4j.

I also agree also with the extension to slf4j.

Reply on news.ycombinator.com