Why did you pick a modp group instead of an EC group?
Why doesn't Bob send y? Y is derivable from what Bob sends. (Your zero knowledge claim is at least a bit wrong, since Bob is sending correlated numbers and, in fact, y can be derived from them.)
Bob's sent values can be rewritten as y2^b, y2^c, and y^-1 * f_1 * f_2, which makes me wonder why f_3 is sent.
Why does Bob prove knowledge of x+b+c? Can you clarify the spoofing attack?
What prevents double spending if the tracker is malicious?
So, what I mean by zero knowledge is that there is zero knowledge of the secret key x, the discrete log of y. Y itself is supposed to be derived, that's part of the protocol. But when Bob randomly offsets the x-value before sending it, he is committing to a value of x, c, and b which he must then verify. It will be impossible for him to verify the c and b if he doesn't know x, which is important (see below).
modp groups are easier to implement, I was look into EC but I may come back to it later.
Bob doesn't want to send y directly because then another man in the middle could, before the transaction times out, forward y, spoof his own b and c, forward the verification of x and then verify his own b and c. Then he cannot spend the coin but he can make it unspendable.
If one tracker is malicious, he'll be out of sync with all the other trackers to which the transaction is also broadcast to. Every single known tracker would need to be compromised (they are all public).
Why did you pick a modp group instead of an EC group?
Why doesn't Bob send y? Y is derivable from what Bob sends. (Your zero knowledge claim is at least a bit wrong, since Bob is sending correlated numbers and, in fact, y can be derived from them.)
Bob's sent values can be rewritten as y2^b, y2^c, and y^-1 * f_1 * f_2, which makes me wonder why f_3 is sent.
Why does Bob prove knowledge of x+b+c? Can you clarify the spoofing attack?
What prevents double spending if the tracker is malicious?