Block.js

[dcousens]

Resolves #279 .

The API right now is very simple, but provides the basic building blocks.
I'm not sure whether we should put merkle tree hashing in here or some where else.

Mostly this abstraction was created to be able to parse blocks, further functionality can be added when necessary?

@weilu thoughts?

[dcousens]

ping @weilu

[coveralls]

Coverage increased (+0.09%) when pulling 8fe80b9 on block into 929d926 on master.

[sidazhang]

the API LGTM

Is this going to be available before 3.0.0?

[weilu]

I'm trying to evaluate the API by using it: weilu/cb-blockr@c522315 @dcousens I'll have something for you by the end of this week. Sorry for the delay

[dcousens]

No worries, look forward to your feedback.

webbtc.com provide a hex end point if you're looking for one.

[weilu]

Is this function necessary? When I parse dates it's normally for display reasons, where local timezone would be more useful than UTC.

[weilu]

Can this problem be solved with documentation instead of exposing a function may or may not be useful to users?

[dcousens]

I don't mind if we have getUTCDate or getLocalDate, but the important point is that the block.timestamp is UTC seconds, not your typical JS Date.
Personally, I find the UTC date useful because it outputs in your timezone anyway.

[weilu]

My point is that this is a utility function that I expect to write myself as an app dev. I don't think it's relevant to block parsing

[dcousens]

Well, this is a Javascript interface to a Block, so it seemed pertinent to provide a Javascript Date which deals with the .timestamp being stored in seconds correctly.
I'm open to other interpretations though.

[dcousens]

Still conflicted on this. But I think I'm going to err on the side of minimizing possible user error by providing it, and if we don't see usage we can deprecate it later?

[weilu]

ok

[weilu]

Looks good overall. When constructing a block by hand (as opposed to using the deserialization function), it wasn't immediately obvious that prevHash and merkleRoot are of type Buffer. I don't have a very good solution to this. Perhaps we can establish a convention where *Hash is always of type Buffer, and document it in readme?

[weilu]

Just a note: network.js pubKeyHash and scriptHash are integers

[dcousens]

I think that is a good point about *Hash, I'm not against that always being a Buffer if appropriate. Though, I'm not sure what else you would have expected.

Just a note: network.js pubKeyHash and scriptHash are integers

What is the relevance here?

[weilu]

Those two will need to be renamed if we were to decide to go ahead with the *Hash => Buffer naming convention

[dcousens]

Right. Not sure on that change.

[weilu]

@dcousens if you don't want to make any amendments go ahead merge it as-is. It's a small enough API can iterate on

[kyledrake]

+1 from me. This is an awesome feature to add to the library!

[dcousens]

Rebased on HEAD

[coveralls]

Coverage increased (+0.09%) when pulling b6b5b56 on block into 936f791 on master.