> 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…
Show HN: An educational blockchain implementation in Python
31–40 of 44 posts
Re: Show HN: An educational blockchain implementation in Python
#32> 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…
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
#33Thanks! 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…
"Protocol documentation" https://en.bitcoin.it/wiki/Protocol_documentation
Re: Show HN: An educational blockchain implementation in Python
#34> 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."
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
#35Re: Show HN: An educational blockchain implementation in Python
#36Earlier 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…
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
#37Re: Show HN: An educational blockchain implementation in Python
#38Earlier 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.
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> 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…
Re: Show HN: An educational blockchain implementation in Python
#40Earlier 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…