The section "Over-spending prevention by balance proof" doesn't make sense about wabisabi HOT 4 CLOSED

Yes, indeed, you're right! This is a bug in the paper! Thanks for pointing it out. However, I'm not sure about whether your suggested fix would work. The statement does not bind the prover to the attributes of the credentials being requested, namely , for .

I think the only adjustment we need to make is to change the right hand side of the verification equation to . So essentially, our statement is a knowledge of representation of the point (left hand side of the verification equation), with respect to generators . This ensures that indeed the client is the one who rerandomized the credentials (knows the sum of the randomizing scalars) and the summation of the amount attributes also match.

from wabisabi.

I think I did a stupid mistake: in the section "Over-spending prevention by balance proof" has nothing to do with the from the section "Unconditional Hiding". Now it does make sense to me, since:

So it's a bit misleading but correct.

from wabisabi.

thanks for this, it's a good feeling knowing that you are because of all of what you found in Wasabi already!

i will try and think of a way to improve this notation, the r' vs. r in the balance proof is kind of confusing even without an additional unrelated r', but it's the best i could come up with. maybe just a note in the perfect hiding section saying that although that is possible the rest of the document omits those terms are not added for simplicity so that at least there is only one r'.

FWIW right now for the proof of concept we are not implementing unconditional hiding, but i insisted on keeping that in the paper because i think it's attractive from a coercion point of view, there would be no point in e.g. coercing the coordinator give up records or something to a nation level attacker who may become a post quantum adversary eventually thereby gaining the ability to retroactively deanonymize users).

if we end up using bulletproofs or compressed sigma protocols then i believe this would only be needed for the serial number, because the proofs are only p-special sound due to the compression, and it would be logical to collapse an entire request into a single batch proof in that case for communication efficiency anyway

from wabisabi.

see also #46 and #40 (second time this confusion has happened, although back then it was way worse because i didn't even put a ' on the vars ;-)

from wabisabi.