david wong

Hey! I'm David, cofounder of zkSecurity and the author of the Real-World Cryptography book. I was previously a crypto architect at O(1) Labs (working on the Mina cryptocurrency), before that I was the security lead for Diem (formerly Libra) at Novi (Facebook), and a security consultant for the Cryptography Services of NCC Group. This is my blog about cryptography and security and other related topics that I find interesting.

What might have been going on at Mtgox posted December 2014

I ran into an old post from nullc (Greg Maxwell one of the core Bitcoin developer) and it's interesting how small details might have been the fall of Mtgox.

First. You can't spend bitcoins you just mined.

Freshly generated Bitcoins (from mining) can not be spend until they are at least 100 blocks deep in the blockchain. This prevents the funds from vanishing forever if the chain reorgs.

see chain reorganization.

The term "blockchain reorganization" is used to refer to the situation where a client discovers a new difficultywise-longest well-formed blockchain which excludes one or more blocks that the client previously thought were part of the difficultywise-longest well-formed blockchain. These excluded blocks become orphans.
Chain reorganization is a client-local phenomenon; the entire bitcoin network doesn't "reorganize" simultaneously.

see orphan block.

An orphan block is a well-formed block which is no longer part of the difficultywise-longest well-formed blockchain.
The block reward in an orphaned block is no longer spendable on the difficultywise-longest well-formed blockchain; therefore whoever mined that block does not actually get the reward (or the transaction fees). This phenomenon must be taken into account by mining pools that use any payout strategy other than "proportional".

And here is a misunderstand of the padding of ECDSA (Elliptic Curve version of the Signature Scheme DSA) that might have be the problem:

This issue arises from several sources, one of them being OpenSSL's willingness to accept and make sense of signatures with invalid encodings. A normal ECDSA signature encodes two large integers, the encoding isn't constant length— if there are leading zeros you are supposed to drop them.
It's easy to write software that assumes the signature will be a constant length and then leave extra leading zeros in them.

Well done! You've reached the end of my post. Now you can leave a comment or read something else.


leave a comment...