Kris Nuttycombe

After #589, we can save some potential computation by sorting the keys that are most likely to decrypt a particular output first when providing multiple keys for wallet scanning. An...

As of #341, ZcashLightClientKit uses direct access to the `zcash_client_sqlite::wallet::delete_utxos_above` method because it is not exposed in the `WalletWriteTransparent` interface. However, this is really a low-level implementation detail of higher-level...

https://github.com/zcash/librustzcash/pull/341#discussion_r794939024

In #341, `zcash_client_backend::data_api::wallet::decrypt_and_store_transaction` was modified to persist transactions if any transparent inputs are present. While this is presently safe because we expect this method to only be called for transactions...

Noted from https://github.com/zcash/librustzcash/pull/472/files#r785147960 Also, `signature_hash_v4` is poorly named, and should be renamed to reflect the actual ranges of versions it handles.

Change unified address parsing to not treat unknown receiver types as shielded

1

ZIP-316 specifies that unified addresses must be rejected if they don't contain a shielded receiver. The current implementation of the unified address parsing logic treats all unknown protocol types as...

The data access api provides a view over on-chain data that is relevant to a particular wallet. One current limitation is that if outgoing data from a wallet is encrypted...

Update signature hashes to inhibit "Possible large transaction fee via two Segwit transactions"

1

Noted [here](https://github.com/zcash/librustzcash/pull/286/files#r482234232): > Amounts were added to sighash following the SegWit design, but per [this SegWit bug](https://blog.trezor.io/latest-firmware-updates-correct-possible-segwit-transaction-vulnerability-266df0d2860) it was insufficient to protect hardware wallets from incorrectly computing fees. Given that...