Add get_wallet_summary to WalletRead

[nuttycom]

No description provided.

[str4d]

Reviewed 1e5eae8

[daira]

Defining this to include all zero-conf funds means that an adversary will be able to arbitrarily inflate it above the realistic balance, as soon as we implement detection of zero-conf funds.

If I send you funds in a bunch of transactions that each have 50 unpaid actions and expire at the next block, I can be pretty confident that at most one (probably zero) of them will be mined. So, using this value as defined for anything opens the wallet up to the transparent equivalent of a Faerie Gold attack (and to various social engineering attacks, such as refund scams, if it is ever shown to a user). This is also a potential DoS attack on auto-shielding.

I agree that we haven't yet implemented the things that would enable these attacks, but still, it should not be defined that way.

Suggested change

	/// Unshielded balances are not subject to confirmation-depth constraints, because the only
	/// possible operation on a transparent balance is to shield it, it is possible to create a
	/// zero-conf transaction to perform that shielding, and the resulting shielded notes will be
	/// subject to normal confirmation rules.
	/// Unshielded balance, with a minimum confirmation depth of 1.
	///
	/// The only possible operation on a transparent balance is to shield it, and the resulting
	/// shielded notes will be subject to normal confirmation rules. Nevertheless, the unshielded
	/// balance should not be over-reported, and including zero-conf UTXOs without restriction
	/// would make it too easy for an adversary to cause such over-reporting. This policy might
	/// be refined in future.

[nuttycom]

Zero-conf balances have essentially become the standard among zcash (and Bitcoin and Ethereum) wallets, and the functionality to provide zero-conf balance is highly in demand. I don't know how we get around that; users in general would prefer to immediately see incoming funds as being recognized, at the cost of having to be diligent about waiting for important transactions to be mined.

[daira]

We spent a huge amount of time, effort, and protocol complexity preventing Faerie Gold attacks. I don't see why we would just throw up our hands and accept a transparent attack with similar impact because not caring about it is "the standard".

What do Bitcoin and Ethereum wallets do these days about minimum-relay-fee transactions that definitely won't get mined? Are you really saying they just show them as balance anyway?

[str4d]

Reviewed in a pairing with @nuttycom, so the PR kept changing to reflect these as we went. Marking as "changes requested" and then we can check they all were addressed.

[nuttycom]

force-pushed to address comments from code review

[str4d]

utACK 6cbb107

[str4d]

There is a slight issue here regarding notes that are just about to expire. Without the max(_, 1), with min_confirmations == 0 this would set summary_height to the "mempool height" (chain_height + 1), which is precisely what we want for any transaction in the mempool (that still has a chance of being mined, and thus mined before expiry). Down below in the note selection code, we exclude transactions that have expired as of summary_height (because expiry_height < summary_height) from the balance, which means if someone calls this API with min_confirmations == 0, then about-to-expire funds will disappear from the wallet balance, only to reappear again if the transaction does actually get mined in the last block it can.

I'm fine with this being an edge case we don't handle yet, and instead merging @daira's suggested comment change that we treat min_confirmations == 0 as min_confirmations == 1 for shielded notes.

[daira]

Let's file an issue so that we don't forget this.

[daira]

Filed as #940.

[str4d]

Re-utACK 1e12e9d

Blocking comments addressed.

[daira]

Post-hoc ACK with comment.