Live data from Hacker News

Show HN: An educational blockchain implementation in Python

github.com

31–40 of 44 posts

Re: Show HN: An educational blockchain implementation in Python

#31
post #4

> 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…

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.

Re: Show HN: An educational blockchain implementation in Python

#32
post #21
post #4

> 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…

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 difficul…

> 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.

Re: Show HN: An educational blockchain implementation in Python

#33

Thanks! Simplest explanation I've seen. Here's an nbviewer link (which, like base58, works on/over a phone): https://nbviewer.jupyter.org/github/julienr/ipynb_playground... Note that Bitcoin does two rounds of SHA256 rather than one round of MD5. There's also a "P2P DHT" (peer-to-peer distributed hash table) for storing and retrieving blocks from the blockchain; instead of traditional database multi-master replicatio…

My mistake, it's BitTorrent that has a DHT. Instead of finding the most network local peer with the block identified by a (prev_hash, hash) hash table key, the Bitcoin blockchain broadcasts all messages to all nodes; which must each maintain a complete backup of the entire blockchain.

"Protocol documentation" https://en.bitcoin.it/wiki/Protocol_documentation

Re: Show HN: An educational blockchain implementation in Python

#34
post #4

> 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…

>"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.

Re: Show HN: An educational blockchain implementation in Python

#36
post #32
post #21

Earlier quoted context omitted.

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 difficul…

> 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 e…

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.

Re: Show HN: An educational blockchain implementation in Python

#38
post #36
post #32

Earlier quoted context omitted.

> 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 e…

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/...

Re: Show HN: An educational blockchain implementation in Python

#39
post #21
post #4

> 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…

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 difficul…

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

Re: Show HN: An educational blockchain implementation in Python

#40
post #36

Earlier quoted context omitted.

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 Merkl…

FYI, dicts are now ordered by default as of Python 3.6.
Post reply on HN