<s​gp_:monero.social> I love this chart, but I am a little worried that the data suggests that the best ringsize for the given cost is effectively unlimited. The CE that's given for the default values for ringsize one billion is only 0.15, unless I'm misunderstanding

<s​gp_:monero.social> matrix.monero.social/_matrix/media/…ero.social/KxoVPhOComFQGwYsoikCtgVp

<s​gp_:monero.social> (I didn't try the formulas from the paper by hand)

<s​gp_:monero.social> If I set the adversary budget to only 0.001 XMR per day (which means their spam attack is totally ineffective), the model says the best ringsize for cost effectiveness is a billion, which doesnt make intuitive sense

<s​gp_:monero.social> Or maybe it's fine and we fit the min ringsize to the desired level and then try to fit on that line

<s​gp_:monero.social> Which is the green dot. I suppose a human set upper bound for the max acceptable ringsize might be totally fine. Fwiw, I've been trying to think of how to improve this, but I can't think of how to do so. The formula makes logical sense to me

<r​ucknium:monero.social> sgp_: Last meeting I said that I have a solution concept that gives Alice a budget constraint. The budget constraint will appear as a downward sloping line. (Well, almost a line. It is a little convex because the cost for transacting users is based on tx weight, but the cost for node operators is based on tx size.) I am working on how to visualize this.

<r​ucknium:monero.social> This will fix the problem of an unbounded "best" ring size if you set the search space for ring size very wide.

<r​ucknium:monero.social> There is another solution concept for the best ring size/fee combination when you want to achieve a specific effective ring size exactly. This is the best cost effectiveness when on the black curve in the plot.

<r​ucknium:monero.social> Thanks for the feedback.

<s​gp_:monero.social> Ok, really cool. Thanks for your thoughts into this; it certainly helps my understanding as well