BBR: forced anonymity proposal

Discussion of code updates and pull requests proposed by the community across all CryptoNote currencies.

BBR: forced anonymity proposal

Postby mancoin » Mon Jul 21, 2014 4:44 pm

In the recent article by Boollberry the author claims that the Boollberry’s developers have significantly improved CN code. Any comments?
Posts: 2
Joined: Tue Apr 01, 2014 1:05 pm

Re: BBR: forced anonymity proposal

Postby O.S.G. » Fri Jul 25, 2014 5:35 pm

Firstly, the problem mentioned above occurs only in case of small ambiguity degree (4-5 of less). If user chooses sufficiently big AD value (10+ random keys), the other keys' owners are highly inlikely to deanonymize themselves ALL together. Random choice is essential, because it also prevents (or decreases almost to zero probability) a chance of the keys' owners cooperation against the user.

Now about the BBR feature. Every sender chooses the value N which will be the lower bound for the size of any ring signature the output can participate in. Presumably, there is also some default value. At first glance it indeed eliminates the case of accidental deanonymization: any user can choose secured outputs for his own signature.

But also it introduces an excess power for the sender. Or, better to say, unnecessary dependence from senders' good will. Let's have a look at some extreme cases:

1) Every sender chooses N=0. This is how the original CN scheme works (as if no lower bounds at all). No benefits for users, only increased tx size.
2) Every sender sets N very high (100 or more). It makes all the receivers create huge signatures and pay additional fees.
3) And a concrete example. There are three unknown ouputs with N=4: x, y and z. And five people (with outputs A, B, C, D, E, each with N=0, i.e. with no restrictions) who are willing to spend money anonymously, but can't pay fee for large signatures. All other ouputs have N very high or N=0, so our five users are obliged to choose from a very poor set. Note that there is no point in using each others' keys A-E, because they also have N=0 and can be deanonymized (users don't trust each other). It is a waste of storage and fees. The resulting signatures will be (A,x,y,z), (B,x,y,z) ... (E,x,y,z). As you can conclude, it's a poor privacy.

All these cases, of course, are very unlikely, but the main point is still true: while helping the other users (by providing a secured output) a sender restricts the recepient's freedom. If he cares about it, he would set N=0 (to allow the recipient to choose a comfortable ambiguity degree). The sender may assume that other people set N larger, so there will still be many secured outputs. This is classic example of the Tragedy of the Commons . If everybody thinks like that, case #1 becomes much less improbable.

Sender and recipients may agree on the comfortable N, but this is not always possible, as you understand.

All I want to say is that this feature can not be considered as an unconditional improvement over original CN scheme. So be careful with its pitfalls.
Posts: 9
Joined: Fri Mar 28, 2014 9:41 am

Re: BBR: forced anonymity proposal

Postby puppydogfish » Thu Apr 09, 2015 9:55 am

Sender and sellaion recipients may agree on the comfortable
Posts: 2
Joined: Thu Apr 09, 2015 9:30 am

Return to Features & code updates discussion

Who is online

Users browsing this forum: No registered users and 1 guest