createHash('SHA256').update(timestamp+data+index+previousHash).

I always worry about the security impact of serializing like this.

If my data was "10" and the index was "110", can I just claim the data was "101" and the index was "10" and have the blockchain assert my statement is correct?

Or in other words, can I claim to own 91 more dollars than I should?

Yes, it even has a name: https://en.wikipedia.org/wiki/Length_extension_attack

Yes.

I don't have an immediate reference, but I've seen this situation addressed in may tutorials concerning properly salting passwords.

The general rule of thumb is to not serialize and hash data this way precisely because of the risk of collision that you have outlined.

I believe that something more along the lines of

    createHash('SHA256').update(timestamp).update(data).update(index).update(previousHash)

though, that isn't a complete fix.

This code is equivalent.

It does seem unsafe to serialize like this, without adding a separator between the properties being concatenated, or at least zero-filling the index

I know what you mean, but that scenario would also require the 'previousHash' of index 9 and 109 to be identical no?

FYI: Big fan of building your own blockchains (learn by doing), thus, I've started to collect starter blockchains (in 20 lines of JavaScript, Python, Ruby, ...) and articles (like BrewChain) over at the Awesome Blockchains page [1]. Anything missing? Contributions welcome. Happy blockchaining. [1]: https://github.com/openblockchains/awesome-blockchains

Blockchains are pretty lit. Here's another implementation in Node for comparsion.

https://github.com/lhartikk/naivechain

Lisk is also implemented with Node.js (and PostgreSQL):

https://github.com/LiskHQ/lisk

https://coinmarketcap.com/currencies/lisk/

https://lisk.io/

Handle one time events with EventEmitter#once rather than EventEmitter#on

This has a terrible name and will easily be confused with HomeBrew.