[Discussion] Move to a Fixed Ringsize

[SamsungGalaxyPlayer]

I would like to receive feedback on moving to a fixed ringsize for the September 2018 (v8) protocol upgrade (hardfork). This will happen regardless of the selected ringsize. The current minimum ringsize is 7.

Scope of Discussion

This discussion includes the impact of setting a mandatory ringsize and support for a mandatory ringsize in wallet software and merchant services (eg: CLI, GUI, MyMonero, and Monero Integrations).

Please keep all comments and discussion related to these topics only, not the broader issues of different ringsizes. However, if you support this proposal under certain situations, such as supporting only if the ringsize is greater than x, you can comment with that information.

Major reasons for the change:

1. Few people use the non-default ringsize. At the time of writing, >96% of transactions in the past month used a ringsize <10 [1]. This is consistent with other findings where the minimum ringsize is used for the vast majority of transactions.

2. Non-default ringsizes reduce entropy and therefore decrease privacy. Ringsize is an important piece of metadata, and having people use different values allows users to more easily be identified.

3. Unusual ringsizes for multiple transactions can be linked. If a user sends multiple transactions with an atypical ringsize, then it is likely that these transactions are associated with each other. If this behavior is not permitted, users will not have their transactions linked this way.

4. Non-default ringsizes complicate research. Having exceptions to the number of decoys used complicates analysis on the effectiveness of Monero's privacy claims. Most analyses to-date assumed that all transactions use the minimum ringsize.

Major reasons against the change

1. A configurable ringsize provides flexibility. If a user would like to send transactions with a different ringsize for some purpose, they are able to do with a configurable ringsize.

2. Increasing ringsize increases privacy. Some people believe that increasing the ringsize increases privacy. While this is strictly true since there are more decoys included in the ring signature, the possibility of leaked metadata typically results in the opposite effect.

3. Support for services using non-default ringsizes. Users may be upset if they are unable to send transactions from outdated wallet software.

---

Overall, I believe that the pros outweigh the cons. I recommend setting a fixed ringsize in the September protocol upgrade (hardfork) and updating the CLI and GUI to support only a single ringsize.

[cryptochangements34]

I think that the loss of flexability, especially with a ring size as low as 7, can be a major downside. If for some reason it is a good idea for people to use a non standard ring size then it can't be done without changing the consensus rules again. For example, with the MoneroV fork it was recommended that users use a higher ring size than the default (at the time 5) if transacting within a couple days from the fork because of the possibility of the MoneroV airdrop deanonymizing some transactions, essentially making some decoys useless. This was an unforseen event that nobody had thought of before and by fixing the ring size we lose the flexibility that could be useful if another more serious unforseen event comes

[Gingeropolous]

In general I support move to a fixed ringsize, but I think a lot more needs to be put in stone before this kind of shift. Primarily, how will the fixed ringsize change over time? If we fix it at 12 this fall, is it going to stay 12 forever?

That, in my opinion, would be bad. Ideally, the ringsize will increase as computational ability increases.

I had discussed this in this proposal to algorithmify the ringsize: https://github.com/monero-project/monero/issues/3069 , basically do with the ringsize what monero did with the blocksize.

Because I see the ringsize having similarities to the blocksize debate. "We should change it to be fixed ringsize of 200! Because privacy!" and the other side going "we need to keep it at 12, because decentralization!"

I really think this is another case where we have to remove humans from the decision as much as possible.

[anonimal]

2. Non-default ringsizes reduce entropy and therefore decrease privacy. Ringsize is an important piece of metadata, and having people use different values allows users to more easily be identified.

Yes, when constructing the RingCT language, ring-count diversity creates an unintended vocabulary.

For example, this type of weakness from diversity has been proven in Tor's random guard selection F=(k/N)^2 where the observer of (k/N) can "de-anon" F. Your claim also implies uniform distribution across multiple transactions on a per-user basis, no?

Regardless, where are the samplings? Where are the distribution models? Where are the equations backing these variable-fixed-ringsizes per hardfork? Why aren't the Noethers proposing this issue?

3. Unusual ringsizes for multiple transactions can be linked. If a user sends multiple transactions with an atypical ringsize, then it is likely that these transactions are associated with each other. If this behavior is not permitted, users will not have their transactions linked this way.

This is under the assumption that the 'unusual' ringsize is static per-user, i.e., one static 'unusual' size per transaction? Where is the formal study disproving the effectiveness of random-N of random sets? Are you claiming to disprove the effectiveness of differential privacy equations? If not, why can't we apply a new working definition here?

4. Non-default ringsizes complicate research. Having exceptions to the number of decoys used complicates analysis on the effectiveness of Monero's privacy claims. Most analyses to-date assumed that all transactions use the minimum ringsize.

Good. Fix the claims until the math can prove otherwise. The math must evolve. The claims must evolve.

[SamsungGalaxyPlayer]

@cryptochangements34 generally consensus is pointing to churning being more effective than increasing the ringsize for cases like these.

@Gingeropolous this proposal does not imply that the ringsize will be fixed forever. It is compatible with your algorithmic ringsize proposal. Whatever the algorithm picks will be the fixed size.

@anonimal I need you to elaborate more on your connections to the Tor analogy, but I will explain more about what I mean with the metadata.

No matter what ringsize you select with a Monero transaction, it is recorded on the blockchain.

If everyone uses the same ringsize, this metadata is meaningless. An attacker could learn nothing by knowing the ringsize is the same as every other transaction's.

However, if a user uses a default ringsize of a different wallet (suppose MyMonero recommends a ringsize of 20), then this metadata could suggest that the transaction was sent from a MyMonero wallet. Or if an attacker is transacting with a party and trying to find more about their identity, they could notice that the attacker is using a random ringsize each time. These are potential vulnerabilities that arise from unusual, unique metadata. Even if different ringsizes are used, heuristics can be formed from any of these patterns in an attempt to find unusual behavior.

This is under the assumption that the 'unusual' ringsize is static per-user, i.e., one static 'unusual' size per transaction? Where is the formal study disproving the effectiveness of random-N of random sets? Are you claiming to disprove the effectiveness of differential privacy equations? If not, why can't we apply a new working definition here?

My topic was mostly focused on a user selecting and reusing a single ringsize (eg: 23). However, even if you were to choose a random selection, eg: select a ringsize between 10 and 50 for each transaction you send, this is still susceptible to heuristics. There are no studies I am aware of that specifically speak to this vulnerability, but given the small proportion of transactions that use a different ringsize at all, I feel comfortable claiming that the entropy is too small to even protect users in this scenario. The random-ringsize solution could be instituted in all wallets to increase entropy, but this would have severe downsides. Most importantly, different wallets could ignore this, and there would be no way to reasonably establish consensus to enforce this behavior.

Good. Fix the claims until the math can prove otherwise. The math must evolve. The claims must evolve.

I do not think you understand the significance of this effort. It is immense, and we do not have an unlimited number of people contributing. Unless someone from MRL says otherwise, I do not feel comfortable recommending further research resources being allocated to something that does not need allocation. In any case however, this is the smallest point of those that I have made. Research will continue to improve, but it takes time. Finding the nuances that are introduced by <5% of transactions is low priority.

[Gingeropolous]

@SamsungGalaxyPlayer ,

this proposal does not imply that the ringsize will be fixed forever.

Indeed, but it also doesn't propose any mechanism to increase the fixed ringsize. I mean, every fork are we just gonna come to a rough consensus and say "yeah, we should totally bump it by 2"... or is it gonna be an algorithm... or are we going to setup one of those lottery ball systems with the ping pong balls with numbers on them.

[SamsungGalaxyPlayer]

@Gingeropolous I understand you concern, but I recommend opening a different issue to discuss this. If we include this discussion here, I don't think we can keep it focused.

[OFRBG]

I'm not a Monero dev, but I think fixed sized rings matter from the point of view of end-users. For someone familiar with the environment, choosing a ring size is an educated choice. However, for end-users choosing the size adds choice complexity. Users will randomly pick either the smallest number possible, the highest one available on the UI or some random default.

If you want to take into consideration how people choose their signatures, maybe take into account the power of default choice: make every transaction have a default ring signature size which may be explicitly increased or decreased for a fee. This avoids the problem of MM transactions being "linked" to the default suggested signatures, as well as letting users who know what they are doing use different sizes.

People are very willing to simply use default options when dealing with tough decisions. In order to keep the freedom of choice for the size, you can allow users to change the ring size with a fee: said cost being the consequence of disturbing the entropy.

(Previous discussion related here: https://www.reddit.com/r/Monero/comments/6ryeln/ring_size_vs_transaction_cost/)

---

TL;DR: set a chain-level default N that may be overridden at a higher cost. People are highly likely to use default options on difficult questions. Users who wish to use a different ring size may do so at a cost representing the disturbance of the entropy. Overall this should make the chosen ring size converge to the default.

[SamsungGalaxyPlayer]

@OFRBG you are explaining the situation which has existed since Monero's inception. You have always been able to increase the ringsize for an additional fee. The default is currently the minimum. We learned through past experience that the minimum is the most widely-used, since exchanges and merchants use this to save money.

In practice, increasing the ringsize typically causes more harm than good. Wallets should instead recommend a churning process for users that want to spend more Monero for greater privacy.

[OFRBG]

@SamsungGalaxyPlayer from what I read on that reddit thread, the cost difference between 5 signatures and 21 is not significant, making the decision irrelevant for individual users. I would personally like to see a fixed ringsize, but this comes at a community cost of "forcing" said size. Monero's community is one I admire a lot, and while most users will not even understand the relevance of the choice, others might feel like their choices are being unfairly cut down.

Perhaps I didn't really get my idea across. I would set a default ringsize N for no "extra" charge, and add scaling costs to adding more signatures. As long as people don't see the difference between N and N+1 signatures the choice problem remains. A simple example would be like this:

Tx0 with default 10 signatures:         Y XMR base fee, 0 extra fee
Tx0 with 20 signatures:                 Y XMR base fee, Y extra fee
Tx0 with 30 signatures:                 Y XMR base fee, 3Y extra fee

I'm trying to keep the more "radical" members in mind who wish to keep their freedom of choice. A good middle ground could be allowing a default ringsize and then 10 signature steps with higher cost each. It would probably be best if people just agreed to move to a fixed size, but I'm bringing this up this solution in case there is opposition.

[julian1]

By all means disable choice it in the GUI, but I don't think fixed size should be part of the conensus layer. 2c

[tekcash]

NACK

[ancap19]

Middle ground: we could allow to choose just between two or three standard ring sizes

[dnaleor]

If a fixed size is too contentious, at least I would propose to use fixed multiplicators. For example, if minimum ring size is 10, then only allow: 10, 20, 40, 80, 160, 320, ... This will mitigate some of the analysis risks already

@OFRBG , your idea is similar to mine, but I guess exponential increase in ring size makes more sense. The lesser choices, the better: more people will be using the same size, hence better entropy.

It also makes more sense: what's the difference between ring size 40 and ring size 50? Not that much. If you want more privacy, just go for the next double, 80. Hence, exponential increase.

[OFRBG]

@dnaleor I was using linear increases of ringsize with exponential cost, but you make a good point about the difference between 40 and 50. Sticking to a system of exponentially increasing sizes with scaling costs might do the trick.

[moneromooo-monero]

The ring size is moved to 11 for next fork. ArticMine's new fee formula is based on this.

[laachoir]

As far as I remember that formula is flexible enough to take different ringsizes into account. Also, ruling the decision without having the discussion first feels a little excluding.

[dnaleor]

11 then, no problem. Just limit the allowed ring sizes to 11, 22, 44, 88, 176, 352, ...

The huge befit is that if people desire to sometimes use a bigger ring size, there are probably others who used the same ring size as well sometimes. This is way more likely then when every ring size is allowed.

Also, especially for the bigger ones, it's not that unlikely if you use ring size 176 that a certain decoy is the result of a spent with ring size 176. SO this even adds a bit of plausible deniability to the assumption that if you see this pattern, the real input is the one previously spent with ring size 176.

[moneromooo-monero]

Also, ruling the decision without having the discussion first feels a little excluding.

If you did not participate in this discussion, it is irrelevant. Maybe you were not here yet at the time, but we will not delay something forever just because new people arrive all the time. If you're interested in contributing, you're welcome, but complaining that you're being ignored when you arrive after something was done is NOT contributing.

If you have arguments not presented in the previous discussion, you present your arguments. You do not complain you were ignored.

Read https://github.com/monero-project/monero/issues/1673 first. If you did not know it existed, then maybe you should have looked before complaining.

[paulshapiro]

I second @moneromooo-monero's sentiment. This has been under discussion for ages.

[laachoir]

I apologize for rousing your emotions. Of course there's no reason to wait for potential newcomers, and I did not mean to complain on my regard. Reading through the corresponding reddit thread it seems like at least one more party shared my concerns. Starting a new issue with such a fundamental decision now made it seem like there was no discussion before. Because if there was, why start a new issue? Linking to previous discussions might also have been helpful, thanks for the pointer @moneromooo-monero Anyway. Back to the topic at hand.

[paulshapiro]

@laachoir we have dev meetings on IRC every second Sunday

[moneromooo-monero]

Thanks. If you want to participate, then #monero-dev on IRC. But keep it to monero development please. Other stuff in #monero.

[SamsungGalaxyPlayer]

@moneromooo-monero with the ringsize 11 change, will the ringsize also be fixed at 11?

[cryptochangements34]

I would be in favour of a fixed ring size 11

[moneromooo-monero]

Yes, it is fixed. See https://docs.google.com/document/d/1Y3IsjH7ywJOvFeZd1qT1fRfz2lw8APp8ptcyDXzYrxk/edit from ArticMine, and https://github.com/monero-project/monero/pull/4219/commits/6700eb0cddef083c02a0e9488be8e332811e9337 for the code.

[SamsungGalaxyPlayer]

Thanks @moneromooo-monero.

[SamsungGalaxyPlayer]

Here are the logs from the July 23 Monero Research Lab meeting. Relevant section is below:

2018-07-23 17:38:39< ArticMine> One other point here is increasing the ring size to 11 or using a fixed ring size of 11 2018-07-23 17:39:02< ArticMine> This actually helps mitigate the verification issue 2018-07-23 17:39:08<@sarang> This is where I'd hoped we would have better data on churn/diffusion and its relationship to ring size 2018-07-23 17:39:20< sgp[m]> Why 11? 2018-07-23 17:39:22<@suraeNoether> oh, gosh, moneromoo o built me a utility that i can use to figure out whether there is a numerical solution to that! 2018-07-23 17:39:31<@suraeNoether> i forgot! i've been so busy finishing multisig 2018-07-23 17:39:36<@sarang> yup yup 2018-07-23 17:39:38< sgp[m]> Likewise 2018-07-23 17:39:54<@suraeNoether> moneromooo built a utility that computes the # of unique transaction outputs in the history of any given transaction 2018-07-23 17:39:58< ArticMine> I piked 11 as the largest ring that would still allow for an 80% fee reduction 2018-07-23 17:40:10<@suraeNoether> oh, that's a good metric :D 2018-07-23 17:40:15<@sarang> We should have concrete data to show the benefit 2018-07-23 17:40:24<@sarang> Otherwise we're just saying "surely bigger is better" 2018-07-23 17:40:29< ArticMine> So all the fee calculations are based upon a ring size of 11 and a 2 in 2 out tx 2018-07-23 17:40:41<@sarang> and then there's a counterargument about keeping ring size and taking smaller txn size 2018-07-23 17:41:03< rehrar> at the very least we wanted to moved to a fixed ringsize this upcoming hard fork, yes? 2018-07-23 17:41:08< rehrar> regardless of bigger or not 2018-07-23 17:41:16<@sarang> I believe that is best 2018-07-23 17:41:19<@suraeNoether> i think that would be beneficial, yes 2018-07-23 17:41:25<@suraeNoether> we are at 7 now? 2018-07-23 17:41:26<@suraeNoether> is that rihgt? 2018-07-23 17:41:33< ArticMine> In my proposal my recommendation is fixed 11 2018-07-23 17:41:33< rehrar> yes 2018-07-23 17:41:35< sgp[m]> Yes 2018-07-23 17:41:36<@sarang> that is rihgt 2018-07-23 17:41:56< sgp[m]> Yes 7 2018-07-23 17:42:05<@sarang> We can at least make fun Spinal Tap references to convince people it's a good thing 2018-07-23 17:42:10<@suraeNoether> i'd support a fixed number between 7 and 11. i have no skin in this game, so to sepak 2018-07-23 17:42:27<@sarang> I'd support learning the effects 2018-07-23 17:42:31<@suraeNoether> sarang: oh yeah we can brand this the spinal tap update, with bulletproofs and ring size all the way to 11 2018-07-23 17:42:32<@sarang> and making a decision based on that 2018-07-23 17:42:43< unknownids> 11 rings when you need 1 more ring than 10 2018-07-23 17:42:53< oneiric> lol 2018-07-23 17:42:53< unknownids> why not just make 10 bigger? cause ours go to 11 2018-07-23 17:43:10< moneromooo> I see you got the idea rihgt. 2018-07-23 17:43:52< ArticMine> The case for a fixed 11 are 1) User simplicity 2) No ring profiles 3) There may also be a regulatory advantage in taking away control from the user here 2018-07-23 17:44:07<@sarang> I still think we need to start naming our changes (PoW, network upgrades, etc.) to make them seem less contentious 2018-07-23 17:44:12<@suraeNoether> i'll run moneromoo's utility, it'll take a day or three of boiling my ram, then i'll have an answer about "what ring size is so large that improvements become negligible? 2018-07-23 17:44:23<@sarang> ty suraeNoether 2018-07-23 17:44:29<@sarang> keep me in the loop 2018-07-23 17:44:48< rehrar> post results here, I wanna know too 2018-07-23 17:44:59< ArticMine> Any questions? 2018-07-23 17:45:07<@suraeNoether> rehrar: of course 2018-07-23 17:45:16< rehrar> Will we be ready for the "freeze"? 2018-07-23 17:45:19< dEBRUYNE> Moving to a static ring size is more important than bumping it imo ... 2018-07-23 17:45:40< ArticMine> Is there support for static 11 ring size? 2018-07-23 17:45:47< moneromooo> Yes. ... 2018-07-23 17:46:14<@suraeNoether> ArticMine: i support a static ring size. i will hold off on a number for a day or three 2018-07-23 17:46:21< oneiric> Are there any arguments/reasons against using a static ring size? 2018-07-23 17:46:24< sgp[m]> ArticMine I need to compile more info before agreeing, but I think the number is generally reasonable 2018-07-23 17:46:32< sgp[m]> I definitely support static 2018-07-23 17:46:33<@sarang> Some users will argue they want "greater privacy" 2018-07-23 17:46:41<@suraeNoether> i think 11 in general is fine, actually 2018-07-23 17:46:44<@sarang> I think those users are wrong 2018-07-23 17:46:50<@suraeNoether> i may support a slightly higher number 2018-07-23 17:46:52< scoobybejesus> i tentatively support static 11 2018-07-23 17:46:55< moneromooo> No, they're not. Everyone should want greater privacy. 2018-07-23 17:47:11< moneromooo> They get to send to themselves once, and wait for a day or so. 2018-07-23 17:47:16< sgp_[m]> People who REALLY know what they're doing lose flexibility 2018-07-23 17:47:24<@sarang> I think they're wrong about the big ring size moneromooo, not wanting privacy 2018-07-23 17:47:29< tnsepta> isn't there a balance between privacy and prices? 2018-07-23 17:47:36< ArticMine> Yes 2018-07-23 17:47:46<@suraeNoether> tnsepta: there is, the question is whether the balance will be on the side of privacy or prices. :P 2018-07-23 17:48:03< isthmuscrypto> @xmrhaelan et al over in Monero Outreach could do some preemptive education about "ringsize > default ---> LESS privacy, not more" 2018-07-23 17:48:04< dEBRUYNE> tnsepta: Price as in fee price or? 2018-07-23 17:48:08< hyc> but it's misguided to believe "I want greater privacy than the average monero user so whatever ringsize they use, I'm going to use a bigger one" 2018-07-23 17:48:21< ArticMine> A increase over 11 will require a modification of the fees. 2018-07-23 17:49:14< ArticMine> Basically what matters is the ratio of the reference transaction weight to the effective minimum block weight 2018-07-23 17:50:09<@suraeNoether> okay, let's move on for now; seems like a static ring size is supported regardless of whether we increase it or not or by how much

Again, please note the discussion about the ringsize 11 is off-topic for this discussion unless your opinion on a fixed ringsize is contingent on a specific ringsize.

[pepsidrinkinglurker]

Increasing the default minimum ring size to 11+ is the correct path. If with bulletproofs the tx fees as related to tx size can tolerate a higher ring size such as 20 then that would be the way to go. Setting the ring size as a fixed value however is unwise. The mainnet is not and should not be a testnet. You are proposing a major change without any concrete information or study on the impact of it. Citing that "Non-default ring sizes complicate research" is not a valid reason since non-default ring sizes also complicate statistical analysis by advisories and this is a very good thing. I urge you to reconsider

Edit: Also for proposals such as this a short time frame for input from others is not optimal. Rounded for sanity a 48 hour window is too small.

[julian1]

Reading the discussion, it seems ring-size choice is determined/curtailed by fee calculation. What is it about fee calculation, that mean that fees do not scale linearly with tx bytes, or with total inputs + outputs + proof size?

Also, is it always true that diverging from the common/default ring-size makes a tx more identifiable in all cases?

A specific deception could involve choosing a less common ring-size to lend the appearance of association with other txs in the anonymity set of that ring-size, when in fact there is no underlying relation.

And what about a merchant might who might want to collect low value outputs, that are only profitable to aggregate with a lower fee/smaller ring-size profile?

[hyc]

@julian1 The entire point of bulletproofs is that the proofs are sub-linear in size wrt number of outputs. But verification cost remains linear. So the fee must scale linearly with verification cost, not size.

[SamsungGalaxyPlayer]

@pepsidrinkinglurker the discussion on ringsize 11+ is off-topic for this discussion.

My argument on research is the most minor point of those mentioned and comes down to the following: all research so far has been for a fixed ringsize. We have little to no research on the effects of unusual, non-default ringsizes and their effects. You may claim that there are benefits, but these have never been shown. Instead, mounting evidence points to the opposite. The ringsize metadata is a potential attack surface that can be eliminated, so it should be. Especially if there is no evidence that this potential attack surface should remain.

Respectively, this discussion has been ongoing for many months. The research meeting received a higher approval for a fixed ringsize than for a ringsize of 11. The concept of a fixed ringsize was introduced at least a year ago. Just because this is a new discussion does not mean it was the only discussion on this topic. Yes, it seems that this specific discussion should have been opened earlier, but it definitely has received the buy-in from the majority of contributors over the past several months.

@julian1 I cannot think of a reasonable case where selecting a specific ringsize in an attempt to be deceptive is realistic. It should always be less effective than hiding among the greatest entropy set.

Furthermore, we absolutely need minimum ringsizes to prevent 0-decoy-like issues. Even if a merchant prioritizes low fees, they should not be able to directly harm the network. Since there is already a network minimum and a ringsize increase is not considered in this discussion, it is irrelevant.

[moneromooo-monero]

For those who want to read what was said before, here's another: https://github.com/monero-project/monero/issues/3035

[SamsungGalaxyPlayer]

@Wigmnd @anonimal researchers have supported a fixed ringsize in Monero for several months, going back to at least December 2017 in the linked discussion by @moneromooo-monero and reinforced in the logs provided. I believe the burden should instead be placed on those who wish to preserve a non-fixed ringsize, since ringsize is a specific point of metadata that can be removed. Unless there are significant, evidence-based reasons to keep this potential metadata leak available, it should be closed.

[SamsungGalaxyPlayer]

@Wigmnd please read the top comment under Scope of Discussion. I make absolutely no recommendation or argument here for an increased ringsize.

Please keep all comments and discussion related to these topics only, not the broader issues of different ringsizes. However, if you support this proposal under certain situations, such as supporting only if the ringsize is greater than x, you can comment with that information.

The amount of time that has passed since the issue*2 mentioned by @moneromooo-monero and the one mentioned by @Gingeropolous has been more than adequate enough for research to be preformed if the assumed threat of none default ring sizes was perceived to be so impacting. I am unaware of any such study that has been announced, preformed or published. You have not provided evidence of its existence. It is unclear to me if you did not bother to read my response fully or if a misunderstanding has occurred.

Simply saying that time for research to be conducted does not mean that it has been conducted. The researchers have been busy on far more important matters such as bulletproofs and multisig. I am not here to provide evidence of such research, yet nevertheless, the researchers have consistently supported a fixed ringsize even in this absence. We feel generally (see the quoted MRL meeting) that a fixed ringsize is preferable. There is no evidence to support other ringsizes are helpful, and there is some evidence that they are harmful. As a result, since there is no significant reason voiced here not to adopt a fixed ringsize other than user choice/flexibility, and most people so far generally support it, then we should adopt a fixed ringsize.

[SamsungGalaxyPlayer]

@Wigmnd 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.

I do not believe that you fully understand how ring signatures work, and the scope of potential metadata that is leaked with unusual ringsizes. Allow me to create some hypothetical scenarios where an unusual ringsize is harmful:

1. 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.

2. 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.

3. 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.

I have mentioned before that I am not aware of any sweeping research that looks into these details. Nevertheless, these attacks are are considered possible, and can be easily mitigated or eliminated by setting a fixed ringsize. Since the threat of these attacks are >0, and there is no significant privacy reason for maintaining the current flexible ringsize that has ever been shown, we should move towards a fixed ringsize. It's that simple.

I have heard your argument that you would like more research before proceeding, and it is noted here. I disagree for the other reasons that I have provided in this thread and elsewhere.

If you would like to join these discussions years earlier, I strongly recommend joining #monero-community, #monero-dev, and #monero-research-lab. 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.

I am happy that you made your voice heard in this thread. If you have any research or even circumstantial evidence to suggest that a flexible ringsize is beneficial, please comment again here.

[laachoir]

Scenario 1 and 2, standard ringsize

Carol creates a transaction to Dave. It enters the mempool at blockheight 27, referencing the freshly unlocked transaction of the exchange to Alice. Both transactions are included in block 28.

Who can distinguish whether or not Carol is in fact Alice?

Scenario 1 and 2, non-uniform ringsize.

Carol creates a transaction to Dave. She uses ringsize 73. Her transaction enters the mempool at blockheight 27, referencing the freshly unlocked transaction of the exchange to Alice. It also references an output that was part of a transaction with ringsize 73. Both transactions are included in block 28.

For an outside observer, circumstantial evidence suggests that the two transactions using ringsize 73 are indeed from the same entity. Thus, the other transaction referencing Alices input is far more likely to be in fact created by Alice.

This is, if I understand it correctly, the biggest issue @SamsungGalaxyPlayer has with non-uniform ringsizes.

For the record, I'm not yet fully convinced we should make the move to a fixed ringsize in the way we're currently doing it. If you want to count, count me as withholding my vote lacking necessary evidence in either direction.

[laachoir]

The distribution with which mixins are selected is something done by wallet software, the protocol is unaffected by this. Whether or not you use a gamma distribution over the mixins age doesn't matter to the protocol, as long as you reference at least seven mixins (one of which is of course the true input).

Along the same lines, concerning my above example of Carol creating a transaction at the same time as Alice, referencing at least one identical input as Alice: Since Alice can in fact spend her output at that time (block 27), it is also a valid mixin for Carol. Whether or not currently existing wallet software picks up on transactions that just became available I do not know. But for the protocol, that doesn't matter, since there's no telling who of the two used it as a mixin only.

This also means that the claim that you can't broadcast a transaction sharing any input with ones currently in the mempool is highly unlikely. If it were true, I can sketch a very straight-forward DoS that I have never heard of before: Imagine I want to prevent a given output from ever being spent. I create a transaction referencing this output as a mixin. As soon as that "blocking" transaction is confirmed, I create another such transaction. And so on. Since outputs are spendable independ of the current mempool, your claim cannot be true. (I'd be glad to be enlightened if such a DoS is in fact possible.)

Apart from all this, we're taking the discussion way off-topic again.

[SamsungGalaxyPlayer]

@Wigmnd @laachoir thanks for these discussions.

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.

This is literally the entire point though. Having a non-fixed ringsize creates the opportunity for error, the opportunity for nefarious wallets to add metadata to better differentiate users. I understand these are extreme examples, but the absolutely are possible with a fixed ringsize. We saw a similar scare with X Wallet, who wanted to use an unusual number of outputs for each transaction. I understand these are not the same, but the effect is essentially the same: a piece of information can identify users of a specific wallet.

I'm not going to comment further on the input selection algorithm. Of course, a better input selection algorithm supports all ringsizes, including fixed and flexible ringsizes. Luckily with the new gamma distribution that will be included in 0.13, this is mostly solved. See the Moser, Miller, et. all paper for the research here.

Under the scenarios you explained, it unfortunately is relatively weak support for a flexible ringsize. Your argument boils down to the following: a flexible ringsize allows Alice to select a larger ringsize to protect herself, especially in short scenarios.

Unfortunately, Alice could increase her ringsize to 100, and there would still be generally high evidence that she was the real spender, even under the current distribution. When we discuss churning, we discuss significantly higher entropy sets than 10,000. While you are correct that any number >7 is strictly better than 7, the effective protection here is essentially impossible to quantify. Yes, it means there are more likely to be more outputs from a recent transaction, but depending on the attacker, these ringsizes likely have no practical impact. Unfortunately, Monero ring signatures are simply ineffective at providing protection against powerful heuristics in a quick-turnaround scenario. Even if Moneor had a minimum ringsize of 100, I would need more research before recommending people put themselves in this position, especially against a motivated attacker.

Essentially what I'm getting to is this: we have two threat models to consider. One is against an attacker who is only looking for plausible deniability, and another is an attacker who is using advanced heuristics. For any given minimum ringsize >2, plausible deniability is guaranteed in most circumstances. Ringsize 7 was selected to provide plausible deniability even in the most reasonable extreme circumstance we have discovered. It's possible that several of these attacks can work together, but I digress. Such scenarios would be evidence for increasing the minimum ringsize, since you need the whole network to be on board to provide significant protection.

For an attacker with advanced heuristics (including those we haven't thought of yet), any reasonable ringsize is likely ineffective for a single transaction. Although higher is better, there is evidence to support that any of these entropy sets for a standalone transaction probably don't matter much. I recommend asking more in #monero-research-lab, since research here is ongoing. I will say that for churning, we originally were looking at entropy sets of at least 73,000 for a "reasonable recent zone" and 25,000,000 for a near-complete "entire Monero entropy set." These are all a far cry from any reasonable ringsize unfortunately.

Getting back to your scenarios, you are technically correct that Alice is better protected with a ringsize >7 than 7, at least from a strict ring signature perspective. However, the effect is likely limited. It likely will not matter. Furthermore, it opens up opportunities for people to make mistakes, for merchants to look for and collect information about people who use non-default ringsizes, etc. Especially for in-person transactions, using a non-default ringsize may lead to increased scrutiny of these transactions. Remember that this is a point of metadata that can be used for whatever purpose. Every time you interact with a different ringsize, you need to be extremely careful. As heuristics get more advanced, this metadata could be used in incredible attacks that we have not theorized yet. I make no claims here though for the sake of this argument, since I know it's relatively far-fetched.

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 statistically 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 by default.

Unfortunately this is essentially security/privacy through obscurity. The information is there, and attackers can perform more sophisticated models to learn more. We already have forms of a relatively sophisticated tool (see monero-blockchain-blackball) to seach unusual ringsizes. This does not reasonably provide a significant enough burden for attackers.

The distribution with which mixins are selected is something done by wallet software, the protocol is unaffected by this. Whether or not you use a gamma distribution over the mixins age doesn't matter to the protocol, as long as you reference at least seven mixins (one of which is of course the true input).

This is another example of the same effect of non-default ringsizes. If I created a wallet that used a non-default distribution (ahem... MyMonero... ahem... [it's since been patched]), then this is potentially severely damaging to the network and could separate transactions in this wallet from others. While technically ring signatures provide as much protection as the number of outputs they control, the real protection provided with a decent selection algorithm is far greater than under a weak selection. I make a similar argument for a fixed ringsize: it would increase the real effectiveness against heuristics.

[ArticMine]

I would suggest that dnaleor's idea is a very reasonable compromise at this point. We allow a ring size of 11*2^N with N >= 0 and N an integer. (ring=11 N=0, ring=22 N=1, ring=44 N=2, ring=88 N=3, ring=176 N=4, etc.) This will mitigate the ring persona issue by eliminating non trivial ring size changes. It is also the approach that we are taking on fees for the same reason, namely avoiding fee personas. I should point out that the fee formula will still work since there would be a significant number of transaction with ring = 11 to allow the block weight to scale with the default fee. This is also the situation now with some transactions at the default fee that would not allow the block weight to scale if they were the only transaction type.

My read of the situation is that there is not enough community consensus to move to a fixed ringsize at this point.

[iamsmooth]

@ArticMine I don't agree about community consensus. People showing up at the last minute after months or even years of discussion and quite broad consensus among the continuously active participants who have devoted a lot of time and resources to the matter is not lack of consensus. That includes, by the way, both of the MRL researchers quoted above. It's pretty stupid to pay full time researchers and then disregard them based on a few last minute objections from mostly non-participants.

There will always be some disagreement, from someone (and if there isn't, those seeking to disrupt will invent them). That can't be a reason to stop progress.

IMO the better process on the matter is to perhaps open discussion on whether or how to reintroduce variable ring sizes in the future, in particular based on what benefits they supposedly provide, if someone actually wants to carry that torch on it and make a real contribution, and not just throw bombs at other people's work.

Unless someone can come up with a clear reason why fixed ring sizes are seriously harmful which would justify reversing course. That hasn't happened yet as far as I can see.

@Wigmnd

The issue of ring size 0 decoy usage comes down to the lack of users using blackballing

No it doesn't, that is wrong. Users can't blackball 0 decoy spends that happen after their own. It requires either entirely prohibiting them altogether or a different model of non-fungible outputs. The issue of non-uniform ring sizes is somewhat similar. It causes harm to others because everyone is trying to hide among others' transactions. That is facilitated by those transactions being uniform and harmed by them being non-uniform. Even if there is some benefit (which is questionable) to the person using the non-standard ring size, the cost to others is an offsetting consideration.

[fluffypony]

I think we have a pretty solid understanding of what "broad consensus" is and how to measure it. My reading is that there's "broad consensus" for a fixed ring size, but perhaps for the sake of caution we push this out to April 2019 and let the MRL demonstrate how broken a non-fixed ring size is.

[iamsmooth]

for the sake of caution we push this out to April 2019

I don't see any identified danger that would suggest this sort of caution is useful. It is just as likely (and indeed based on the consensus of people who have been looking at this for years, more likely) that caution points toward switching ASAP and considering switching back later if anyone can demonstrate a benefit.

We know there are methods of analyzing ring signature usage on the blockchain that can be used to hurts people. Leaving identified weaknesses (or even identified likely risks) in place longer than necessary is not caution, it is the opposite.

[fluffypony]

@iamsmooth it's more to give the MRL time to publish a paper on it - I don't think that "just check these old GitHub issues" is a reasonable way to demonstrate how the conclusion was reached. Or maybe more to the point: "we know that X" is true, but we still need to communicate that to the next generation of Monero contributors and maintainers.

[iamsmooth]

I wouldn't say old GitHub issues is the point. There have been numerous discussions in public channels (including GitHub issues, but not specifically that) both on an ad hoc basis and as part of organized meetings which have resulted in the consensus.

I suppose a paper couldn't hurt though.

But I do think there is an ongoing risk of further analysis of identifying chain data along the lines of monerolink that ends up being harmful and remains unmitigated. One of the things that we saw with monerolink was that most if not all of the issues in the paper were already mitigated (at least to some extent) by the time the paper came out. Most of those didn't have a paper written first, it happened through a process of continuous improvement. Throwing a monkey wrench into that process of continuous improvement because of a few last minute objectors seems dangerous to me.

[ArticMine]

My initial thought when I made the recommendation was that there was broad consensus for a fixed ring size; however after reading some of the comments and more importantly giving this some more thought myself I have come up with some possible arguments against a fixed ring size:

1) It embeds a parameter into the consensus code that is dependent upon technological change. For example: Consider a future where the cost of computing power, digital storage, memory and bandwidth falls by a factor of say 10^9, as has happened in the past. In such a future a ring size of say ~10^5 would be economically very reasonable; however since it would require a consensus change it may not happen if there were interests against it. Also an attacker would also enjoy the same lower costs. 2) There could be an unforeseen security threat as occurred with the XMO and XMV forks. In the XMO case one way to achieve an effective ring size of say ~5-7 and spend on both chains was to use a ring size of about 20 in order to ensure 5-7 fake inputs were from before the fork. The latter could then be input into the XMR spend.

I still consider the idea proposed by @dnaleor I mentioned above a very good first step. We can allow for six months to give the MRL time to publish a paper making the case for a fixed ring size as @fluffypony has suggested. Also the fixed ring size would not be tested against the current broken situation but against the idea proposed by @dnaleor.

[fluffypony]

@iamsmooth I don’t disagree, but my recommendation has always been that the dev workgroup chooses to implement recommendations by the research lab. I fear we’ve become so accustomed to doing it the other way that we we no take that as the norm.

I also think we’re at a high enough min ring size that most of the obvious attacks are quite mitigated.

I like @articmine’s idea of putting a paper out that compares both ideas, if that’s not massively objectionable.

[iamsmooth]

@fluffypony This is a recommendation from the research lab. At least one of the researchers (I don't remember which one) has been informally recommending this for 1-2 years at least. Maybe we just need them to write up a half page research note stating that?

[ArticMine]

@iamsmooth I agree with the process issue of late comers disrupting existing consensus; however sometimes there is significant value to look at ideas that solve most of a problem while avoiding long term issues especially in the case of consensus code. In this case I would put @dnaleor idea in that category.

I see @dnaleor idea as a solid stepping stone while the paper is produced. It is also no secret that the MRL see ring signatures as a weak point. .

[iamsmooth]

@ArticMine In the event of an unforeseen situation such as XMV (or really for any reason), one can achieve the same effect of ring size N*2 (minus 1) by performing one round of churn with ring size N (with sensible delay to prevent the obvious timing attack). An attacker would have to control all of the fake outputs on both of the transactions to successfully identify the true source, which is really the same as one transaction with twice the ring size. This introduces an undesirable time delay, and some additional cost for the additional outputs (much smaller with bulletproofs), but I don't find that objectionable considering we are looking at a "how to mitigate some unforeseen disaster" scenario.

Perhaps this can be addressed in a paper.

In practice, we will still see (as we always have) that these non-standard ring sizes are almost never used anyway, so I guess from that perspective the objective harm is low of not fixing it is somewhat low. I would say this is largely true whether or not @dnaleor 's proposal is adopted.

Still, I very much do not like the process of people showing up at the last minute and throwing bombs at work that other people have contributed to and collaborated on for months/years (without the bomb throwers having identified and clearly-articulated a serious problem that everyone else has missed). Nor do I like the precedent of backing out code which has already been implemented, reviewed and merged as a result of this lengthy collaboration, also due solely to last minute bomb throwers. I feel it is a mistake to proceed on that basis, and it emboldens future bad actors.

I would rather see the MRL researchers promptly write a brief research note documenting and explaining their (otherwise somewhat informal) recommendation which gave rise to the aforementioned implementation, but of course that is up to then, as I won't volunteer someone else's effort.

[iamsmooth]

BTW, this issue is indeed addressed, if somewhat indirectly, in MRL-0004, specifically section 3.2

Any data available to an observer about the transactions used to fashion a ring signature can be used in a combinatorial analysis to draw a conclusion about funds ownership ... This information can be used in tandem with other routes of attack ... Our definition of a combinatorial attack seems strikingly general ...

A fixed ring size is minimizing the attack surface of "Any data available to an observer about the transactions"