Hacker News Reader

Comment by magnat | Hacker News Reader

> It is NOT secure neither a real blockchain and you should NOT use this for anything else than educational purposes.

It would be nice if non-secure parts of implementation or design were clearly marked.

What's the point of education article, if bad examples aren't clearly marked as bad? If MD5 usage is the only issue, author could easily replace it with SHA and get rid of the warning at the start. If there are other issues, how can a reader know which parts to trust?

Even if fixing bad/insecure parts are "left as an exercise for the reader", learning value of the article would be much greater if those parts would be at least pointed at.

View on HN

OP here.

erikb is spot on in the sibling comment. This hasn't been expert-reviewed, hasn't been audited so I'm pretty confident there is a bug somewhere that I don't know about.

It's educational in the sense that I tried as best a I could to implement the various algorithmic parts (mining, validating blocks & transactions, etc...).

I originally used MD5 because I thought I would do more exploration regarding difficulty and MD5 is faster to compute than SHA. In the end, I didn't do that exploration, so I could easily replace MD5 with SHA. I'll update the notebook to use SHA, but I'm still not gonna remove the warning :)

I'll also try to point out more explicitly which parts I think are not secure.

> I'll also try to point out more explicitly which parts I think are not secure.

Things I've noticed:

* Use of floating point arithmetic.

* Non-reproducible serialization in verify_transaction can produce slightly different, but equivalent JSON, which leads to rejecting transactions if produced JSON is platform-dependent (e.g. CRLFs, spaces vs tabs).

* Miners can perform DoS by creating a pair of blocks referencing each other (recursive call in verify_block is made before any sanity checks or hash checks, so they can modify block's ancestor without worrying about changing its hash).

* mine method can loop forever due to integer overflow.

* Miners can put in block a transaction with output sum greater than input sum - only place where it is checked is in compute_fee and no path from verify_block leads there.

Those are all very good points I didn't think about, thanks for these.

I'll fix the two bugs with verify_block and the possibility for a miner to inject invalid a output > input transaction.

I'll add a note for the 3 others.

For deterministic serialization (~canonicalization), you can use sort_keys=True or serialize OrderedDicts. For deseialization, you'd need object_pairs_hook=collections.OrderedDict.

Most current blockchains sign a binary representation with fixed length fields. In terms of JSON, JSON-LD is for graphs and it can be canonicalized. Blockcerts and Chainpoint are JSON-LD specs:

> Blockcerts uses the Verifiable Claims MerkleProof2017 signature format, which is based on Chainpoint 2.0.

https://github.com/blockchain-certificates/cert-verifier-js/...

FYI, dicts are now ordered by default as of Python 3.6.

That's an implementation detail, and shouldn't be relied upon. If you want an ordered dictionary, you should use collections.OrderedDict.

True, but if you need both key ordering and performance, dict is the better option.

It's now the spec for 3.6+.

> #python news: @gvanrossum just pronounced that dicts are now guaranteed to retain insertion order. This is the end of a long journey.

https://twitter.com/raymondh/status/941709626545864704

More here: https://www.reddit.com/r/Python/comments/7jyluw/dict_knownor...

OrderedDicts are backwards-compatible and are guaranteed to maintain order after deletion.

For what it's worth, MD5 is perfectly safe for use as a proof of work algorithm. You just don't want to use it for authentication / data integrity

Being secure is the lack of attack surface. So it's really hard to say. Often what hits you is something you haven't considered.

So what the author is saying he doesn't take responsibility for when you use the result of his work and get problems. If you want to act responsibly build a team of different experts, have tests for security scenarios, have automated tests, from time to time pay people to attack your system and show the weaknesses you have.

Or, do it like 99.9% of people and just accept that there are risks but don't try to put resulting failures on people who provide free solutions for you online.

PS: Incorporation is a good way to protect yourself. Then having even ineffective due diligence processes is enough to protect your personal life from the risks of doing business.

HN is a tough crowd to please. Without the disclaimer, I guarantee you that the top comment would have been one requesting the author to add one, along with a warning about not writing your own crypto.

>"What's the point of education article, if bad examples aren't clearly marked as bad?"

The doc string for the hash function states:

    An INSECURE hash function that you should not use in the real world.
    Returns an hexadecimal hash

I'm not sure how much clearer you could mark that.

The point in the article seems to be understanding the blockchain protocol and concepts and not "how to write secure crypto."

> I'm not sure how much clearer you could mark that.

It's not about this warning. It's about that it's the only warning. From the intro and from discussion here on HN, I imply author knows about other shortcuts made for the sake of simplicity/explanation/readability - I just wished those shortcuts were pointed at more directly in the article, instead of blanket disclaimer.

just gives you a sense of the protocol, which is probably GTK if you’re technically inclined and speculating.

Reply on news.ycombinator.com