[jre]

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.

[magnat]

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

[jre]

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.

[tfha]

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