Clarifying the Balance Proof about wabisabi HOT 8 CLOSED

@nothingmuch looks good to me now 👍

from wabisabi.

cancelling out M_{v_i} from C_{v_i} is not right because those refer to different credentials, M_{v_i} are the attributes for the credentials being requested, and C_{v_i} are the ones being presented. Combined with G^{\Delta_v}, the amounts should cancel which results in G_h^0, while the other terms remain, perhaps r should be renamed \Delta_r.

we should find a better notation for these, it's really terrible, created #46

from wabisabi.

Thanks, that's an important point about 4.3.

about footnote 8: we're still bikeshedding how much should go in, because it's kind of implementation dependent and out of scope, but the intuition is that with the separate input/output protocols you get a bipartite graph of registrations where the coordinator can't observe the edges between them (the credentials) but you know the out degree of each input registration vertex is at most k. the reissuance would allow more linkage by adding a third part to the graph, but it may be arbitrarily small and therefore fingerprintable. unified registration makes this bipartite graph into an arbitrary directed acyclic graph between registrations with max out degree k. with k=2 each of the n inputs may be linked to arbitrary outputs by a graph of network of depth log_2(n), and with conversely k bound by O(log(n)) a constant number of registrations can implicate an arbitrarily connected graph. with k=1 inputs could still be linked but the user is forced to make O(n) sequential actions to consolidate or split in the worst case.

from wabisabi.

the first bit about 4.3 - there's a mistake in the verification eqn, without addressing the 2nd issue, i think it should have been:

deleted some nonsense here, i'll fix it when i can sit down and work it out with a clear head instead of making more mistakes

I think I must have messed it up when I changed everything from separate input/output registration to the the unified protocol. The coordinator can calculate the top of the RHS, compute \prod M_i directly because it doesn't see the M_i.

However, like you said because the message space is small this reveals enough for the coordinator to link together outputs by searching can link inputs and this statement should be proven in zero knowledge instead.

from wabisabi.

sorry, i worked it out on paper, and yes, should be like you said, where r'_{v_i} is the G_g based randomness term of C_{v_i} and r_{v_i} is the one in M_{v_i}. I must have gotten the two r's conflated when I wrote this.

As for fixing the privacy leak, I think it's a simple knowledge of exponent proof, where . if i'm not mistaken that's how it's done in CT just as an ECDSA signature instead of Schnorr identity?

@seresistvanandras

from wabisabi.

it can't just be a signature because i forgot that the proof also needs to cover the z term. anyway, here's my attempt at redoing 4.3:

from wabisabi.

I think there is a problem with the generators.

from wabisabi.

Thank you. Now it finally make sense to me (what means the code works ;)

var B = (request.DeltaValue * Generators.Gh) +
	Sum(C_v0, C_v1, C_v2, C_v3) +
	Sum(M_v0, M_v1, M_v2, M_v3).Negate(); 

VerifyProofOfBalance(B, request.BalanceProof);  // True

from wabisabi.