Ensure that vpub_in and vpub_out are not both nonzero

[ebfull]

Pour A values:

vpub_in = 5
oldcoin_0 = 0
oldcoin_1 = 0
newcoin_0 = 1
newcoin_1 = 0
vpub_out = 4

Pour B values:

vpub_in = 1
oldcoin_0 = 0
oldcoin_1 = 0
newcoin_0 = 1
newcoin_1 = 0
vpub_out = 0

Do these pours have the same semantics? They both validate and both affect the "value pool" in the exact same way. One of them just requires the value pool has more value in it than is really necessary.

Perhaps this should be a well-formedness check on pours if it has anonymity implications? If not, we can add this constraint later in a softfork.

[nathan-at-least]

As with many other possible restrictions to transaction semantics, we have these choices: consensus rule, soft-fork later to a consensus rule, define a default policy, don't do anything.

In discussion, we agree to postpone this to post-1.0 (although I'm not certain it's a problem yet).

[daira]

It's a potential distinguisher between clients, so a client should only generate Pours with either v^old_pub = 0 or v^new_pub = 0 or both, to maximise indistinguishability. If there is such an implicit rule, then Pours that don't follow it will stick out, so I think we should reconsider enforcing it as a consensus rule for 1.0. I can't see any harm in doing so, and it is very simple.

[daira]

Note that the Mint/Pour unification could alternatively have been expressed in terms of allowing negative v^new_pub. I think the only reasons we didn't do that were avoiding signed arithmetic in the circuit (this was when we weren't as confident about circuit changes; it would actually have been quite simple), and some aesthetic symmetry between Pour inputs and outputs.

[ebfull]

You're right @daira. I wish we could go back and fix that. I do think analysis of the code surrounding pours was simpler when all the values were positive, though.

[daira]

This is in the current spec.

[daira]

Oh wait, is this ticket supposed to be for implementing the restriction, not just specifying it?

Note that it doesn't need to be enforced in the circuit, because v^old_pub and v^new_pub are public.

[nathan-at-least]

Closed by #897