Block header parsing and transaction ID computation

[str4d]

No description provided.

[ebfull]

Just fun complaints, nothing urgent. Nice PR!

[ebfull]

We're bringing in two different versions of this crate apparently.

[str4d]

The older version is coming in through the aes crate, which is used via the fpe by zip32. We can bump fpe to the latest aes crate, which will resolve this discrepancy.

[str4d]

I've opened str4d/fpe#9 with this change, along with some minor cleanups and improvements. I've confirmed that it reduces the number of dependencies by three (two of which were older versions of crates we still depend on).

[ebfull]

Sigh! Rust should have added a hex literal.

[ebfull]

Instead, you could initialize a local clone of the self.0: [u8; 32] and then [T]::reverse() on that, rather than allocating.

(Not blocking.)

[ebfull]

Same as the other review comment about something similar to this.

[str4d]

Rebased on master to fix merge conflicts. Now the only merge conflicts will be trivial ones with #68 and #69, due to adding modules to the same file in zcash_primitives.

[str4d]

Rebased the last few commits again because I forgot to correct the Cargo.lock after rebasing.

[Eirik0]

Aside from the name, BlockHash is the same as TxId and in this commit we write the same fn fmt twice. This makes me wonder if there should be a single type (named ByteArray32 or something like that) rather than two.

[str4d]

I'm not convinced that the extra indirection to the underlying bytes is worth it yet. If we find the reverse-hex format is bleeding in too much from zcashd then we can revisit this.

[Eirik0]

It feels we are going back and forth a bit having to construct the transaction and write it's data to an array before we can set the txid. It would be possible to do this all at once, but maybe it's not worth the trouble.

[str4d]

By design, I chose to only allow serialization of complete transactions (so that the transaction format is not used for storing "partially-complete transactions", which greatly complicates the job of the transaction parser). Thus it is necessary either to do what we do here, or to have the transaction serializer be a standalone function that takes all the transaction components as inputs. I don't think the complexity of the latter is worth it; the txid field of Transaction is private, so we know that only this module (and submodules) will be able to see and/or modify it directly.

[Eirik0]

This could be done by moving the write<W: Write>(&self, mut writer: W) function from Transaction to TransactionData, but I could see this being beyond the scope of this PR and we can revisit it later.

[str4d]

Addressed @Eirik0's comments (and I'd addressed @ebfull's before that).

[hdevalence]

Not sure if this is out of scope for the PR, but the BlockHash is a typed wrapper for a [u8; 32]; are the merkle_root and final_sapling_root comparable 32-byte arrays, or semantically-different types? Should they also be newtype wrappers?

[str4d]

They are all hash outputs, but of at least two different hash functions. In zcashd they are represented by the same 256-bit binary blob type, which has the "feature" that when rendered in hex in zcashd RPC output, the bytes are reversed (behaviour inherited from Bitcoin Core).

I use separate types for block hashes and transaction IDs because those are the only two that external code is likely to actually interact with, whereas other block header fields (thus far) will only be used internally. Once the refactor is further along and we get to the stage of cleaning up the crate APIs, we should revisit this.

[str4d]

Opened #73.

[hdevalence]

I don't think there's anything wrong with this code, but I get a little anxious about the let mut bytes = zeros; read bytes; pattern, since (considering the reading, not the zeroing, as the "real" initialization) the variable initialization is unlinked from its declaration, and the resulting variable is left mutable even if it doesn't need to be.

Since reading 32 bytes is a pretty common idiom, maybe it would make sense to define some extension behaviour like so:

pub trait ReadExt {
    fn read_32_bytes(&mut self) -> io::Result<[u8; 32]>;
}

impl<R: Read> ReadExt for R {
    #[inline]
    fn read_32_bytes(&mut self) -> io::Result<[u8; 32]> {
        let mut bytes = [0; 32];
        self.read_exact(&mut bytes)?;
        Ok(bytes)
    }
}

so that this byte-handling code can become, e.g.,

let prev_block = BlockHash(reader.read_32_bytes()?);
let merkle_root = reader.read_32_bytes()?;
let final_sapling_root = reader.read_32_bytes()?;

[str4d]

This is a commonly-used idiom throughout the existing codebase, so we should address this comprehensively. Opened #72

[Eirik0]

utACK. My comments are non-blocking.