cryptocoinjs hierarchy/interactions

[Brooks Boyd]

Guys, I created this diagram of how I think the various components of the cryptocoinjs suite work together; does this look accurate to you?

[Sidney Zhang]

Looks pretty good

Seems fairly accurate.

After working on the scriptinterpreter, I think we will need bring in an additional module- sha1 

[Brooks Boyd]

'sha1' is another one of the algorithms the Crypto module in Node handles on its own, so we could just let it handle that hashing math. JP, have you any further thoughts on how I set up a "universal hashing interface" here: https://github.com/MidnightLightning/crypto-hashing ? Or Sidney, have any thoughts on that too? If we like that structure, it's fairly trivial to extend it with more convenience functions to match the names of the algorithms.

--
You received this message because you are subscribed to the Google Groups "Bitcoin Hackers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to BitcoinHacker...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Sidney Zhang]

I would prefer the crypto-hashing package. So that everything is in one place. And then we can also provide convenience function such as 

sha256+ripemd160 for op_hash160

[JP Richardson]

Nice work on the diagram! Brooks, I looked over crypto-hashing and I like it as well. It makes sense since we decided to target Node / Browserify. Eventually, I'll need AES, but that'll probably make sense to throw into a "crypto-cipher" library or something.

--
Follow me on Twitter: http://twitter.com/jprichardson

[Brooks Boyd]

Okay, I transferred ownership of the "crypto-hashing" library to cryptocoinjs, and published it, so we can start moving things that require sha256/ripemd160 onto that new one.

AES being two-directional, I wonder if it should lump in with base-64-encoding and base-58-encoding? In the same way the crypto-hashing library has a generic function that gets modified by the algorithm used, there could be a generic "encode/decode" function, and different "algorithms" passed into it. I'm thinking if each of those "ciphers" were written as a Node Transform Stream (actually two, one for encoding, one for decoding), some generic wrapper module could swap out the appropriate one and be pretty extensible?

Brooks

[JP Richardson]

I can't see a compelling reason to move AES in with base-64 and base-58. Since they have dramatically different use cases, it doesn't make much sense. Although dumping  the base-64 library that we have may make sense since base 64 is supported in Node and Browserify should take care of that for us.

[Brooks Boyd]

Different use cases, yes. However the interface would be similar (encode/decode functions, with an options object like crypto-hashing) which was why I thought of it.

Brooks

[Brooks Boyd]

FYI, I updated this diagram and added it to the main "cryptocoin" module's wiki: https://github.com/cryptocoinjs/cryptocoin/wiki/Module-Flowchart

I reversed the ecurve/ecurve-names order, since in reality, "ecurve" is the most basic library and "ecurve-names" depends on it, not the other way around. I replaced the sha256 and ripemd160 nodes with crypto-hashing, and added in crypto-binary as a new node.

Brooks