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

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?

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

15 feels like the magic number to me

I feel slight unease by not choosing a prime number

lol, it is the way

17 is a prime though

as is 13

15 -> 17 would require an additional ~3% of evenly-distributed outputs (72->75%) to be visible to deduce 1% of arbitrary rings

How much benefit do we obtain from raising it though?

Especially if one considers that stuff like Triptych is somewhat being pursued too

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

The substantial reduction in tx per day since the activation of the DoS attack kind of insinuates most of it is organic

I also have a lot of reason to believe that a good portion of the increase at least is organic growth

I think people partially just want a bit more buffer

could we potentially go back to the previous model where the exact ringsize wasn't part of the consensus?

eww

no, we want uniformity

we're a cult, remember?

so all transactions must look alike

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

ComplyLast: it introduces more problems than it solves

single ringsize bump isn't going to help in that case

bible salesmen in NK can just churn

when using the cli to transfer funds whats the reason for not having the ringsize set to a default

then they get the equivalent of a ring size 1000 without risking a metadata leak

donkeydonkey[m]: people do stupid stuff

fluffypony, the problem then becomes that the bible salesman needs to use CLI, GUI, Mobile wallets, etc are no longer an option

Bible salesman sells bibles, might not necessarily be tech savvy

I agree, GUI and mobile wallets need to be able to churn easily

nah, that would be even more the case if some allowed different ringsizes and others did not

"ringsize 22 hmm, must be using the CLI..."

Allowing custom ring sizes has more detriments than benefits, imo

this standard ringsize is so amazing tbh

going back would probably kill me lol

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

so no more random dudes using 666 and stuff like that

mitigating metadata leakage.

I think even 2 would cause far more harm than good

using a larger ringsize screams I WANTED MORE PRIVACY

if it screams that it might become popular with the average monero user :P

nah history says it will be a muddled mess

muddled mess to some extent makes the job of our known (and not theoretical attackers) harder to some extent too

as per that gentleman from Chainalasys own admission, so it's not as clear cut

it's almost always a net negative

for the use-cases you describe, ringsize 1000 won't help you

better for people to (in theory) make several transactions like the others and try to fit in

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

it doesn't help the bible salesman in a tainted output -> bible salesman -> exchange scenario

that's true

well, at least in this case, users who practice coin control don't stick out to the public

Sgp 72%->75% is a 10% increase

Or thereabouts

Not 3%

4%

For illustration, It's like saying 98%->99% is a 1% change, when you need to actually control 100% more outputs

sure, each additional % costs more than the preceding one

I'm not sure describing 72%->75% as a '3% increase' is the best wording for readers to understand

It's technically correct, of course

Technically not correct

3% increase is when you multiply by 1.03

Adding/subtractring percentages is generally wrong unless they refer to the exactly same value

in any case I wasn't trying to be confusing :p

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%

the crossover point was ringsize 7

crossover point will be later for stricter requirements than 1% deduce

~ ringsize 8/9 for 0.1% for example

I am not opposed to a ring size increase to 15. My preference though would be between 19 and 25

Wownero uses ring 22 by the way.with a 2 in 2 out tx of 2700 bytes before BP+

by between 19 and 25 I mean a fixed ringsize in that range

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.

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

yeah hard to say if the size trade-off is worth it Idk a way to be, like, very objective about that

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

take a look at the Triptych paper where CLSAG intersects with Triptych in tx size

This is why I would prefer 19 to 25 as opposed to say 15

Also if we go 11 --- > 25 that is a 2.4x in the number of fakes. Another 2.4x increase puts us at 60

So it is a reasonable interim step

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.

... but we can still cook the surveillance frog to a boil slowly. CLSAG/BP+ 2.4x, Tryptych ~4x, Arcturus ~4x etc

rather than have the frog jump out pof the pot and take a bite

We know that correlation and inference are the primary tools being employed to deanon XMR txns (Ciphertrace + data from exchanges, ISPs, etc)

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

I agree it's a half-measure, but that doesn't mean half-measures should be non-starters

I totally get the argument that increasing for no net benefit is a waste

but given the recent scrutiny, a modest bump is probably still reasonable until triptych. I wouldn't go 25 or something though

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

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

that said, I don't think 11 is "unsafe"

+1 for fixed prime number ring sizes :- P

Recently wrote a (mostly philosophical) article that's tangentially relevant RE selecting parameters for privacy tech

I think I even included a joke about how hard it is to determine the optimal value for ring size

Thanks @sgp_ or whomever put together that spreadsheet crunching the numbers for flood level and compromised fraction

yw! I've had it for a while but updated some of the terms finally today to be more useful to most people