12:02:48 ryo_ru: If i was on their place i would crap bricks daily from recognising a thought thatactually more inclined and financial backed guys can come and knock you down. So i would rush for resolution asap 12:02:48 fice: But they are stupid and short sighted, with each release they think it is the last one, pat themselves on the back and declare victory. Welcome to Monero. Are you tired of winning yet? 16:38:18 I plan to open a new github issue on raising the ringsize tomorrow, but I expect to propose a ringsize increase from 11 to 15 when bp+ are implemented 16:38:43 15 feels like the magic number to me 16:40:55 I feel slight unease by not choosing a prime number 16:41:10 lol, it is the way 16:41:30 17 is a prime though 16:41:32 as is 13 16:43:50 15 -> 17 would require an additional ~3% of evenly-distributed outputs (72->75%) to be visible to deduce 1% of arbitrary rings 16:44:18 How much benefit do we obtain from raising it though? 16:44:31 Especially if one considers that stuff like Triptych is somewhat being pursued too 16:45:57 https://usercontent.irccloud-cdn.com/file/q3DdYJzK/excel 16:51:45 there was some concern here that as the transaction count increased and more people are looking at Monero, that someone might be attempting a spam attack 16:58:40 The substantial reduction in tx per day since the activation of the DoS attack kind of insinuates most of it is organic 17:00:15 I also have a lot of reason to believe that a good portion of the increase at least is organic growth 17:00:26 I think people partially just want a bit more buffer 17:01:36 could we potentially go back to the previous model where the exact ringsize wasn't part of the consensus? 17:01:57 eww 17:02:09 no, we want uniformity 17:02:11 we're a cult, remember? 17:02:15 so all transactions must look alike 17:02:21 I know there are some problems around to it, but bibles salesman in NK which have a different threat model than sgp_ and fluffypony could benefit from it 17:02:44 ComplyLast: it introduces more problems than it solves 17:02:47 single ringsize bump isn't going to help in that case 17:02:54 bible salesmen in NK can just churn 17:03:07 when using the cli to transfer funds whats the reason for not having the ringsize set to a default 17:03:08 then they get the equivalent of a ring size 1000 without risking a metadata leak 17:03:21 donkeydonkey[m]: people do stupid stuff 17:03:43 fluffypony, the problem then becomes that the bible salesman needs to use CLI, GUI, Mobile wallets, etc are no longer an option 17:04:01 Bible salesman sells bibles, might not necessarily be tech savvy 17:04:03 I agree, GUI and mobile wallets need to be able to churn easily 17:04:09 nah, that would be even more the case if some allowed different ringsizes and others did not 17:04:33 "ringsize 22 hmm, must be using the CLI..." 17:04:57 Allowing custom ring sizes has more detriments than benefits, imo 17:05:23 this standard ringsize is so amazing tbh 17:05:28 going back would probably kill me lol 17:05:30 could we potentially explore a model where 3 sizes each an order of magnitude bigger than the previous are part of consensus? potentially incurring fee penalties 17:05:46 so no more random dudes using 666 and stuff like that 17:05:56 mitigating metadata leakage. 17:05:58 I think even 2 would cause far more harm than good 17:07:04 using a larger ringsize screams I WANTED MORE PRIVACY 17:07:40 if it screams that it might become popular with the average monero user :P 17:07:50 nah history says it will be a muddled mess 17:08:24 muddled mess to some extent makes the job of our known (and not theoretical attackers) harder to some extent too 17:08:44 as per that gentleman from Chainalasys own admission, so it's not as clear cut 17:10:01 it's almost always a net negative 17:10:16 for the use-cases you describe, ringsize 1000 won't help you 17:11:13 better for people to (in theory) make several transactions like the others and try to fit in 17:15:04 that could still be Bible salesman in north korea, depending on output management which is something not really doable on anything other than CLI and Feather 17:16:34 it doesn't help the bible salesman in a tainted output -> bible salesman -> exchange scenario 17:17:48 that's true 17:50:49 well, at least in this case, users who practice coin control don't stick out to the public 18:04:24 Sgp 72%->75% is a 10% increase 18:04:37 Or thereabouts 18:04:39 Not 3% 18:05:34 4% 18:05:36 For illustration, It's like saying 98%->99% is a 1% change, when you need to actually control 100% more outputs 18:06:50 sure, each additional % costs more than the preceding one 18:07:47 I'm not sure describing 72%->75% as a '3% increase' is the best wording for readers to understand 18:08:11 It's technically correct, of course 18:08:24 Technically not correct 18:08:37 3% increase is when you multiply by 1.03 18:09:00 Adding/subtractring percentages is generally wrong unless they refer to the exactly same value 18:10:25 in any case I wasn't trying to be confusing :p 18:35:09 increasing the ringsize from 11 to 12 would be an increase of 9.09%, and the proportion of outputs required to deduce 1% of arbitrary rings grows by 4.21% from 62.85% to 65.5% 18:35:42 the crossover point was ringsize 7 18:36:49 crossover point will be later for stricter requirements than 1% deduce 18:39:13 ~ ringsize 8/9 for 0.1% for example 20:28:31 I am not opposed to a ring size increase to 15. My preference though would be between 19 and 25 20:31:34 Wownero uses ring 22 by the way.with a 2 in 2 out tx of 2700 bytes before BP+ 20:32:40 by between 19 and 25 I mean a fixed ringsize in that range 20:39:46 It's a half-measure IMHO. It's better to increase it to 60+ when Triptych or some other log(N) scheme is implemented. Right now it'll just add more bloat. 20:40:11 y'all were talking about bumping ringsize to combat spam attacks, which sounds great, but just to toss it out there: a minimum fee bump would also discourage by making it more expensive. Also, increased ring size means larger TX means more expensive transactions? so there's a knock-on effect to increasing ring size 20:41:09 yeah hard to say if the size trade-off is worth it Idk a way to be, like, very objective about that 20:42:04 Not really we increase now to where a Triptych tx would likely lie just under 3000 bytes. I would not consider doubling the number of fakes from 10 to 20 (ring 21) half a measure 20:43:11 take a look at the Triptych paper where CLSAG intersects with Triptych in tx size 20:45:44 This is why I would prefer 19 to 25 as opposed to say 15 20:47:09 Also if we go 11 --- > 25 that is a 2.4x in the number of fakes. Another 2.4x increase puts us at 60 20:47:37 So it is a reasonable interim step 20:57:27 I don't know, in my mind "a full measure" would be going from 10 to 100 fake output (squaring, not doubling). Then a single new tx would achieve the same result of two consecutive old tx. 21:12:36 ... but we can still cook the surveillance frog to a boil slowly. CLSAG/BP+ 2.4x, Tryptych ~4x, Arcturus ~4x etc 21:12:54 rather than have the frog jump out pof the pot and take a bite 21:45:59 We know that correlation and inference are the primary tools being employed to deanon XMR txns (Ciphertrace + data from exchanges, ISPs, etc) 21:47:12 A moderate increase in ring size seems an effective defense against such an attack. Whether that's 15 or 25 is not clear to me, but either are reasonable short- to medium-term responses 22:37:11 I agree it's a half-measure, but that doesn't mean half-measures should be non-starters 22:37:32 I totally get the argument that increasing for no net benefit is a waste 22:38:07 but given the recent scrutiny, a modest bump is probably still reasonable until triptych. I wouldn't go 25 or something though 22:39:44 11 leaves us less "wiggle room" than I ideally feel comfortable with, even for these simple, non-targeted attacks. I feel more comfortable with 15 even, and obviously much more at sizes 64/128 22:40:42 I see 15 as adding a reasonably large buffer against these things, which I don't see as waste. From now until Triptych, 11 may be cutting it too close to the line for mass surveillance prevevention 22:41:10 that said, I don't think 11 is "unsafe" 23:24:45 +1 for fixed prime number ring sizes :- P 23:31:09 Recently wrote a (mostly philosophical) article that's tangentially relevant RE selecting parameters for privacy tech 23:31:09 https://mitchellpkt.medium.com/mental-models-for-security-and-privacy-part-i-f182c0775d86 23:31:09 I think I even included a joke about how hard it is to determine the optimal value for ring size 23:33:08 Thanks @sgp_ or whomever put together that spreadsheet crunching the numbers for flood level and compromised fraction 23:34:16 yw! I've had it for a while but updated some of the terms finally today to be more useful to most people