HN Explorer

12 comments

[ 5.1 ms ] story [ 34.1 ms ] thread
partycoder
Handle one time events with EventEmitter#once rather than EventEmitter#on
technion 

    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?

sturadnidge
I know what you mean, but that scenario would also require the 'previousHash' of index 9 and 109 to be identical no?
johnhenry
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.
ctz
This code is equivalent.
johnhenry
Not entirely...

Depending upon the types of "timestamp", "data", "index", and "previousHash", the value, "timestamp+data+index+previousHash", may be interpreted as a number or a string, affecting the final hash.

Splitting it up prevents this uncertainty.

GordonS
It does seem unsafe to serialize like this, without adding a separator between the properties being concatenated, or at least zero-filling the index
geraldbauer
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
nsnick
This has a terrible name and will easily be confused with HomeBrew.