[monero-project/monero] [Discussion] Move to a Fixed Ringsize (#4229)

@SamsungGalaxyPlayer

> it seems like you have bigger quarrels with Monero Research Lab and the work that they do. This is not the time or place for you to accuse them of having incorrect priorities. If you feel that bulletproofs and multisig are frivolous «features,» then please do not bring these up here. Please re-read the discussion scope before commenting further. I have needed to mention this several times.

If you are interpreting me raising questions I have based off of previous observation and something you have said directly in this issue as me having a quarrel with the MRL you are mistaken.
I will be developing and expanding them in a separate issue. My side comment mention of them however does not make my point any less more accurate and was made to reinforce the benign negative impact of non uniformed ring sizes. Simply put if it was viewed as a issue it would merit special attention, since it has not it is not a issue.

> Allow me to create some hypothetical scenarios where an unusual ringsize is harmful:

> You always use ringsize 73 for your transactions. Even if there is only circumstantial evidence that these transactions are all sent by you, it is strong circumstantial evidence.
>
> You use a specific wallet client that always uses 13 as its ringsize. You reveal a strong likelihood that you are using a specific wallet by sending transactions.
>
> It exacerbates many other attacks by adding another level of metadata to circumstantial evidence. Trying to catch someone with poisoned decoys? The ringsize metadata can help. Looking at timing attacks? The ringsize metadata can help.

These examples are somewhat comical as the improper usage of anything can and will have negative results. They are also highly dependent on the user to re use a static ring size continuously and to be the only user to use that ring size. While they also depend on meta data which is seriously way outside of the scope of this issue I will entertain the notion somewhat.

Some of what currently makes transactions overall stand out will be solved with the usage of gamma distribution for ring selection. Please see #1673 , and the pull for it is #3528 and my reason for mentioning this will now follow as yes it is relative.

As of now we know that 50% of the decoys in a TX are from the recent zone which is 1.8 days
`#define RECENT_OUTPUT_RATIO (0.5) // 50% of outputs are from the recent zone
#define RECENT_OUTPUT_DAYS (1.8) // last 1.8 day makes up the recent zone (taken from monerolink.pdf, Miller et al)
#define RECENT_OUTPUT_ZONE ((time_t)(RECENT_OUTPUT_DAYS * 86400))
#define RECENT_OUTPUT_BLOCKS (RECENT_OUTPUT_DAYS * 720)`
https://github.com/monero-project/monero/blob/release-v0.12/src/wallet/wallet2.cpp

We also know that
1. Just from looking at the blockchain it is impossible to determine who is the sender of a TX and who is the recipient. We need more data.
2. Monero only really provides privacy for the sender, not the recipient, and only when used correctly. I.e when sending the receiver does not know which input in the ring that made up the TX is the real one but the sender knows which outputs are generated. Also not waiting to spend freshly received inputs or improperly churning. Full churn MRL pending
3. Inputs especially from mining pools, exchanges and currency conversion services like shapeshift should be considered as high risk inputs. To obtain these inputs more meta data to link the user to the input can, is and will be obtained and or stored by the services. I will specially focus on shapeshift. Please see https://www.reddit.com/r/Bitcoin/comments/6q319b/shapeshifts_cio_is_an_advisor_for_law_enforcement/ and feel free to investigate further but the extent or even the validity of the claims do not matter much. The point is mining pools, exchanges and currency conversion services are known to generate overall more meta data than a simple Alice to Bob transaction does.

Looking at why 1.8 days was selected as the value for the recent zone or why that 50% of the decoys will be from it is up to you, I will not elaborate further. Now Please follow along with what are to be considered somewhat detailed real world based scenarios.

For both we will assume the service is running software which tracks the outputs of TXs it creates

Scenario 1
1. Alice uses a service to obtain xmr. The service retains whatever information generated from the actions required by alice to obtain the xmr and also the information about the TX.
2. TX block acceptance 16, TX block unlock 26
3. Alice pays Bob for a ride home, as this was the only input in her wallet it is the one which is used. The TX enters the mempool at block 27 and is included in block 28.

Scenario 2
1. Alice uses a service1 to obtain xmr. The service retains whatever information generated from the actions required by alice to obtain the xmr and also the information about the TX.
2.TX block acceptance 16, TX block unlock 26
3. Alice pays service2 for a item, as this was the only input in her wallet it is the one which is used. The TX enters the mempool at block 27 and is included in block 28. Service2 does not know the real input in the ring but it knows and retains whatever information is generated from the actions required by alice related to the payment and information about the TX which is obtainable from looking up the TX hash.

Standard ring size
1. For both Scenario 1 and 2 because Alice was so quick to spend the input and used a standard ring size the effectiveness of ringCT to protect her is greatly diminished. I would even go so far as to hint at it being completely negated.
2. For Scenario 2, meta data and just general data obtained from interactions with services is not apart of the scope.

Non uniform ring size
1. For both Scenario 1 and 2 because Alice was so quick to spend the input but used a non uniform ring size she has increased the amount of decoys that share a closer block relation to hers within the 1.8 day range. The effectiveness of ringCT remains intact.
2. For Scenario 2, meta data and just general data obtained from interactions with services is not apart of the scope however a higher ringCT will increase the chance of plausible deniability exists to a extent.

Point 2 exists regardless if you use a Standard ring size or a Non uniform ring size since if the two services where to compare data, especially the online fingerprint and the amount of coins obviously the transaction now suffers a higher chance of being linked and this holds a strict relationship to immediate usage of a fresh input and its chances of already being used as a decoy in another TX.

A network wide benefit of using a non uniformed ring size does in fact exist. By increasing the ringsize you increase the amount of decoys, this means if someone was to be tracking outputs of TXs to see when they are being reused as inputs for TXs the amount of reuse would grow in a non conforming manner that would be very difficult to preform statically analysis on and it will also make certain statistical known truths to become false. Also statistically the benefit should increase once we switch to gamma because of the likeness of the decoys selected.

> Even if we do not understand the full impact of something does not mean that we cannot move towards something that most contributors feel is beneficial. We never had a huge discussion to establish that flexible ringsizes are good, either. If the majority of people support a fixed ringsize, and if there is more evidence to suggest it is better than not with limited potential harm to the network, we should move towards a fixed ringsize.

So rather than to postpone for the research to be preformed you would rather act on unproven assumptions. Wing it as they call it and hope for the best. I once again ask what?!?!

Добавить комментарий