A few comments:

• There's a compilation error in tests. You'll have to change usize to u64 in tests as well.
• Run cargo fmt and cargo clippy before pushing your code. This will properly format your code and also warn you about non-idiomatic Rust code. Current CI has lint and formatting checks in place so, build won't succeed without properly formatted code.

I think the basic fix looks OK, but needs a few small changes.
In addition to @devashishdxt suggestions here (cargo fmt, cargo clippy, cargo test): #133 (review)

It'd be good to follow the patch convention for commit / pull request message: https://rfc.zeromq.org/spec:42/C4/#23-patch-requirements
Here, it could be, for example:

Problem: latest parity/scale-codec fails to compile (CRO-161) #120

Solution: converted usize fields (in datatypes that use scale-codec) to u64

Reviewed 20 of 20 files at r1.
Reviewable status: all files reviewed, 8 unresolved discussions (waiting on @leejw51crypto)

chain-abci/src/app/validate_tx.rs, line 72 at r1 (raw file):

                let min_fee = state
                    .fee_policy
                    .calculate_fee(_req.tx().len() as u64)

I think calculate_fee could keep usize? it's a function, so no effect on parity/scale codec encoding

chain-abci/src/storage/tx.rs, line 158 at r1 (raw file):

        match txo {
            Ok(Some(v)) => {
                let bv = BitVec::from_bytes(&v).get(txin.index as usize);

perhaps create a casted value in the beginning:

let input_index =  txin.index as usize;

and then use this later instead of all the casts?

 BitVec::from_bytes(&v).get(input_index);
...
if input_index >= outputs.len()  {
...
let txout = &outputs[input_index];

?

chain-core/src/init/address.rs, line 27 at r1 (raw file):

/// Keccak-256 crypto hash length in bytes
pub const KECCAK256_BYTES: u64 = 32;

is it necessary to change this constant's type? I think it's only used in defining the array sizes?

chain-core/src/tx/fee/mod.rs, line 70 at r1 (raw file):

pub enum MilliError {
    /// An invalid length of parts (should be 2)
    InvalidPartsLength(u64),

MilliError doesn't seem to need Encode/Decode, so I think it could be kept as usize?

chain-core/src/tx/fee/mod.rs, line 154 at r1 (raw file):

    }

    pub fn estimate(&self, sz: u64) -> Result<Fee, CoinError> {

I think calculate_fee / estimate could keep usize? They are functions, so no effect on parity/scale codec encoding

client-core/src/service/root_hash_service.rs, line 114 at r1 (raw file):

}

fn combinations(public_keys: Vec<PublicKey>, n: u64) -> Result<Vec<RawPubkey>> {

does n need to be u64 here? @devashishdxt

client-core/src/wallet/default_wallet_client.rs, line 677 at r1 (raw file):
as mentioned:

I think calculate_fee / estimate could keep usize? They are functions, so no effect on parity/scale codec encoding

client-rpc/src/wallet_rpc.rs, line 259 at r1 (raw file):

I think calculate_fee / estimate could keep usize? They are functions, so no effect on parity/scale codec encoding

@leejw51crypto looks good, just three small requests before merging it:

• upstream master changed, so just sync up with that (git pull origin master + resolve conflicts)
• usize can be kept where it's not related to binary encoding/serialisation (i.e. the fee algorithm function arguments + error data types that don't implement binary serialization)
• if there's a block of code where one value needs to be re-casted multiple times, it could be recasted once let recasted_val = original_val as ...; and then used in those places

Reviewable status: all files reviewed, 8 unresolved discussions (waiting on @leejw51crypto)