<a​ck-j:matrix.org> I missed the meeting but just caught up. Interesting that no one brought up the possibility of adding a TXPoW requirement similar to what tevador made for TOR.

<a​ck-j:matrix.org> If done correctly it could stop the spam without knee-jerk changes to the fee structure or blocksize. This would need to be carefully thought through with an adversarial mindset as it could add a DOS vector if an adversary discovers a way to cheaply increase the TXPoW requirement to something infeasible. There should be a cap.

<c​haserene:matrix.org> ZK-SNARKs are based on the Knowledge of Exponent/Coefficient Assumption and the hardness of lattice problems. KAE was theorized in the early 90s. lattice problems sufficient for cryptographic use exist since the mid-90s. (even the SNARK authors mention that the former is a non-standard assumption that belongs to a lower falsifiability category.)

<c​haserene:matrix.org> contrast that with the integer factorization problem and the discrete log problem that have been known and seem to hold since the mid-70s. hardness assumptions are those, assumptions, and cryptography in a way is about making assumptions and disproving them until we find ones that seem to hold well enough. naturally, newer assumptions have received less scrutiny on aggregate.

<c​haserene:matrix.org> re: proof size, isn't the practical outcome the same -- you end up with a constant-sized proof as the root of verifiability?

<c​haserene:matrix.org> I didn't say the math is wrong ("moon math" is not pejorative from my mouth).

<c​haserene:matrix.org> I would be very surprised if currently more cryptographers had experience with ZK cryptography than with solutions based on e.g. discrete logs. but I would also like to be wrong on this, because it is an important field.

<k​ayabanerve:matrix.org> ... ZK-SNARKS are largely based on discrete logs.

<k​ayabanerve:matrix.org> I won't say lattice-based SNARKs don't exist. I will say the most popular SNARKs rely on the ECDLP.

<k​ayabanerve:matrix.org> (and sure, additional assumptions on top of that)

<k​ayabanerve:matrix.org> As for *what* additional assumptions on top, there are works which are solely DL I believe.

<k​ayabanerve:matrix.org> > re: proof size, isn't the practical outcome the same -- you end up with a constant-sized proof as the root of verifiability?

<k​ayabanerve:matrix.org> SNARKs don't require a constant-sized proof, solely a smaller proof than circuit size. I believe the general agreement is even sqrt complexity is acceptable though there's a strong preference of logarithmic.

<k​ayabanerve:matrix.org> > "moon math" is not pejorative from my mouth

<k​ayabanerve:matrix.org> If you restate disrespect for no other reason than to spread the disrespect, it is from your mouth.

<k​ayabanerve:matrix.org> Again,

<k​ayabanerve:matrix.org> > We use the library to build a transparent zkSNARK in the random oracle model where security holds under the discrete logarithm assumption.

<k​ayabanerve:matrix.org> Knowledge of exponent assumptions are frequent with pairing-curve-based SNARKs. That doesn't mean all SNARKs rely on them.

<c​haserene:matrix.org> yes, if those additional assumptions are broken, that is an issue for the scheme. I'm glad to hear not all schemes use it, or that others are in the works.

<k​ayabanerve:matrix.org> ... this is incredibly ironic given 1) CLSAG was deployed with uncommon assumptions 2) CLSAG's security proof was just found flawed

<c​haserene:matrix.org> (this was in comment to how Mina uses recursive proofs, not SNARKs in general)

<k​ayabanerve:matrix.org> The CLSAG security proof was rewritten and now supposedly holds again. I wouldn't disparage the knowledge of exponent assumption when we have believed to have deployed less common assumptions (at least, I believe less common).

<k​ayabanerve:matrix.org> You can have a recursive proof with isn't even sublinear to circuit size.

<k​ayabanerve:matrix.org> Nove, inherently, is linear to circuit size. Their sublinearity is from instantiating it with Spartan.

<c​haserene:matrix.org> so if I point out that some people use moon math as derogatory, then I'm one of those people? come on.

<k​ayabanerve:matrix.org> *If* there was no other reason to bring it up, yes.

<k​ayabanerve:matrix.org> You can only argue it as having factual benefit if you had a factual reason to bring it up. I don't believe you did. You distinctly established the smaller talent pool.

<k​ayabanerve:matrix.org> When asked downsides, you said they're called "moon math", repeating a derogatory term without factual benefit. For you to have stated it factually, IMO, you should have said "They're largely disparaged by community members who refer to it with derogatory terms such as 'moon math'". That would've shifted it from a drive-by to a discussion on social push back.

<k​ayabanerve:matrix.org> But I really don't care to play the language police game when the insulted party is a group of mathematical algorithms and would rather move on.

<k​ayabanerve:matrix.org> I just wanted to counter the label applied to reduce its spread as community push back built on fear of the idea, due to that language being used, will solely harm Monero in the future.

<k​ayabanerve:matrix.org> Distinctly, CLSAG was proven and deployed with the κ-OMDL assumption.

<k​ayabanerve:matrix.org> I'm unsure that's actively considered more likely to hold than Knowledge of Exponent assumptions so not only would I not say SNARKs require weaker assumptions, I'm unsure I'd say most modern SNARKs do.

<c​haserene:matrix.org> I was talking to someone who, judged by what and how they asked, weren't familiar with the concept, and how it's viewed in the Monero space by some people. that's the sole reason I brought that up. yeah, I think this here is nit-picking on me being concise and language-policing. I right after said how amazing innovations take place in zero knowledge (whatever the hardness assumpti<clipped message>

<c​haserene:matrix.org> ons). I didn't disparage. the difference in talent pool size and novelty are objective observations.

<k​ayabanerve:matrix.org> Distinctly, Halo, which isn't a SNARK yet is an IVC which would allow folding input/output proofs, is also solely DL.

<c​haserene:matrix.org> I was talking about the second counterfeiting bug, that was noticed in 2018 by Gabizon. the first one was caught by the MS researcher you mentioned, sometime before Zcash launched. and true, it wasn't an operator, it was an upper limit that was omitted from a group of formulas.

<k​ayabanerve:matrix.org> In that case, sorry, we are discussing two incidents.

<k​ayabanerve:matrix.org> I'm only aware of a single incident post-launch.

<k​ayabanerve:matrix.org> Apologies for being unaware of a prior incident and assuming you were referring to the one I knew about.

<k​ayabanerve:matrix.org> Err, no, I'm discussing the one noticed by Gabizon where extra elements were included in the transcript which should have been erased.

<k​ayabanerve:matrix.org> It has nothing to do with an upper limit according to Zcash's disclosure.

<k​ayabanerve:matrix.org> > Some of these elements are unused by the prover and were included by mistake; but their presence allows a cheating prover to circumvent a consistency check, and thereby transform the proof of one statement into a valid-looking proof of a different statement. This breaks the soundness of the proving system.

<c​haserene:matrix.org> that is the one I know to have been present post-launch

<k​ayabanerve:matrix.org> Right, so we are discussing the same incident then.

<k​ayabanerve:matrix.org> They published variables which, in hindisght, should not have been published.

<c​haserene:matrix.org> inflation-bug.png

<k​ayabanerve:matrix.org> It's not about a faulty mathematical operation or about bounds on range.

<k​ayabanerve:matrix.org> Oh.

<k​ayabanerve:matrix.org> So sorry. I've been working with integer protocols recently where range means something quite distinct.

<c​haserene:matrix.org> this is the diff, they look like upper bounds to me

<k​ayabanerve:matrix.org> Yes, if you mean a range of polynomial elements, completely agree.

<c​haserene:matrix.org> no problem

<k​ayabanerve:matrix.org> I thought you meant they allowed keys > the modulus or some similar behavior which enabled undefined arithmetic bla bla bla

<k​ayabanerve:matrix.org> (I actually am storing at a protocol which isn't ZK if the witness leaves an interval)

<k​ayabanerve:matrix.org> (I actually am staring at a protocol which isn't ZK if the witness leaves an interval)

<r​brunner7:monero.social> Just saw that the logs for the last 2 MRL meetings are not present in the corresponding GitHub issues, for the meeting yesterday and the one 1 week earlier. Not sure, is plowsof the right person to remind here, or do you Rucknium usually post yourself? I noticed this because I wanted to post a link of yesterday's discussion regarding possibly rising fees to Reddit, because that ma<clipped messag

<r​brunner7:monero.social> y be of general interest.

I can get to them later today rbrunner thnx

<r​brunner7:monero.social> Thanks!

<r​ucknium:monero.social> rbrunner7: I posted the logs. Thanks for the reminder.

<r​ucknium:monero.social> xmrack: PoW for txs was suggested by BawdyAnarchist. Nano's original spam-prevention was PoW, but they got spammed anyway. IIRC Nano added "output" age and coin amount as prioritization criteria to fix their spam. Monero's amount and output age are hidden of course.

just checked, our min relay fees are twice as much per kilobyte as bitcoin's (1 sat/byte) ---- in chain-native terms, no USD, basically we are charging "2 monero-sats per byte" i.e. 0.00000002 xmr per byte

not sure if that's a comparison I've seen made in the fee convo

Yws sech1 noted that fees are "expensive" in terms of monero and we 5*d them recently

The easier way is to multiply Monero tx fees by Bitcoin price and see the result

Thank you for the comparison Lyza, didnt know this

They're NOT cheap

sech1: I got $2.43 as the *minimum* fee if xmr price == btc price :O

If Monero gets to Bitcoin levels of usage, fees will go down

So it won't be $2.43

right right

If my math is correct, a 1/2 transaction fee (31 micromonero) is equivalent to 9-10 minutes of mining at 20 kh/s. Does it count as cheap or not?

in some ways that seems v cheap, in others pretty expensive

I guess I would say mostly it feels cheap

an average laptop user could "afford" like 20-30 TX per day from a laptop

which is way more than most people send

(I suspect)

anotehr way of thinking about it, a network that probably settled a quarter billion USD in value collects what, dozens of dollars in fees prior to the recent transaction surge? more like 10k usd now (order of magnitude estimate) so an overall fee rate of umm, 0.004%

250,000,000 would be 10% of the market cap, is where that random-looking guess comes from, plus there's 80 million in volume visible on exchanges according to coingecko, so any kind of reasonable estimate puts the overall ratio of fees to value moved ludicrously low.... obviously fees don't scale with transaction value but, still

lots of kinda arbitrary ways to looks at this :/

what do you mean?

<a​rticmine:monero.social> Raise the fee but don't force the user to mine it. Keep in mind the spammer can also mine the spam. Even worse the spammer can move to a cold place and launch the spam from there

The real value of the network is the use so it's better the network to be usable by lowering transactions fees as possible, like that people will want use it and there will be real value, the DN teach us Bitcoin is shit, pretty no one use it anymore in real life, just speculate... bitcoin is pretty worthless in real life, will you buy a coffee for

5$ fees? Ligtning will be censored as hell so... as lowering fees, it's usable, we want that, so price will go up and mining reward will be more in $ that's a real win win... if fees go up, people will don't like that and let it, price will go down and mining reward will go down in $ please never never rise fees, Monero is the last stand, it should

be usable by everyone

<a​rticmine:monero.social> The idea of TxPOW is because there is no cost effective way to make micro payments. It simply makes no sense in Monero

Now that sounds like a James Bond plot. Evil Dr Bytecoin builds a secret lair under the north pole and plots to destroy privacy worldwide, using the fossil fuel to, er, fuel his quest to pierce Monero's shield...

Well, I had a neat idea for off chain micropayments, mining to a service. There are RPC for this in monerod.

tw pow seems interesting

tx pow seems interesting

but will it be usefull for the network?

<a​rticmine:monero.social> Replace TxPOW with Monero micro payments

<f​r33_yourself:monero.social> I'm not very smart, and I'm not saying something needs to be done at all. I think a wait and see approach is a good idea for the short-term. But what if fundamentally enabling the attack from my perspective, is that the fees are not or will not jump up high enough on the single entity doing the high tx volume. If fees went up enough in accordance with their spam then the attack wo<clipped me

<f​r33_yourself:monero.social> uld probably cease as it wouldn't be financially feasible. I don't understand the algorithms all that well, but isn't it fairly unlikely that the spammer will be able to pay enough to keep the blocksize elevated after the Long Term Median gets boosted up? Like he could keep this up for the next 65 days or whatever, but once the blocksize gets a boost upward I would think that woul<clipped me

<f​r33_yourself:monero.social> d increase the total amount he has to pay to continuously fill blocks.

<f​r33_yourself:monero.social> I'm not very smart, and I'm not saying something needs to be done at all. I think a wait and see approach is a good idea for the short-term. But what is fundamentally enabling the attack from my perspective, is that the fees are not, or will not, jump up high enough on the single entity doing the high tx volume. If fees went up enough in accordance with their spam then the attack <clipped me

<f​r33_yourself:monero.social> would probably cease as it wouldn't be financially feasible. I don't understand the algorithms all that well, but isn't it fairly unlikely that the spammer will be able to pay enough to keep the blocksize elevated after the Long Term Median gets boosted up? Like he could keep this up for the next 65 days or whatever, but once the blocksize gets a boost upward I would think that wo<clipped me

<f​r33_yourself:monero.social> uld increase the total amount he has to pay to continuously fill blocks.

<a​rticmine:monero.social> One issue here is the supposed spam occurred for the most part before the penalty was triggered

<f​r33_yourself:monero.social> Yes, so that restrains the extent to which they can commit spam right?

<a​rticmine:monero.social> Yes. It puts a limit on the growth of the spam

<f​r33_yourself:monero.social> My point is the following: Is this tx spam really that big of a deal IF the flooder's expenses (to fill blocks) rise each time that the Long Term Median increases? If their expenses actually do not increase when the Long Term Median increases, then this flood is more likely to persist (as they continue expending the same level of financial resources to produce even greater tx volume).

<a​rticmine:monero.social> No need to burn any additional fossil fuels. Just redirect home hating to spamming

<a​rticmine:monero.social> Green spam

Man... something powered by hate would be unstoppable.

I think someone actually built space heaters that mine.

<f​r33_yourself:monero.social> If we expect their expenses to rise meaningfully when the next bump in the Long Term Median occurs, then I think we should just wait and see if they have adequate financial resources to continue flooding at a (meaningfully) more expensive price. This is my uneducated / n00b / rube take. If we expect that their total expenses (price to fill blocks with their own transactions) wil<clipped me

<f​r33_yourself:monero.social> l NOT rise meaningfully enough after the next bump in the Long Term Median, then maybe tweaking the fee or dynamic block algorithms is a good idea to make it such that it is increasingly more expensive for a single entity to fill blocks with only their own transactions. (If this is even possible).

<f​r33_yourself:monero.social> I don't know if Monero can possibly prevent a black marble attack, but it could (possibly) be made expensive enough to deter people from performing such an attack. Where they would have to expend increasingly more resources as their tx volume bumps up blocksizes.

<a​rticmine:monero.social> For a constant rate of spam the cost over time is constant

<f​r33_yourself:monero.social> Ok I follow, but when the block size (Long Term Median) increases that requires them to increase their rate of spam and therefore the cost over time will rise correct?

<f​r33_yourself:monero.social> Ok I follow, but when the block size (Long Term Median) increases that requires them to increase their rate of spam (to fill the new larger blocks) and therefore the cost over time will rise (as blocks are bigger post-expansion) correct?

<a​rticmine:monero.social> In a constant rate of spam the block size remains constant unless the ham rate changes

<f​r33_yourself:monero.social> And in our current scenario, the spammer is simply keeping the rate of spam constant? It doesn't look like they are trying to bump the blocksize up?

<a​rticmine:monero.social> It is a spam

<a​rticmine:monero.social> If it is spam

<a​rticmine:monero.social> I am far from convinced

<f​r33_yourself:monero.social> But does it look like their intention is to maintain current spam levels in a careful manner so as to not increase the Long Term Median? Or does it appear they are spamming as much as possible in order to increase the Long Term Median (in about 60 days from now or whenever)?

<a​rticmine:monero.social> The long term median would increase by 20% or so at this rate

<f​r33_yourself:monero.social> ah the answer is right here. This is interesting. So it implies that they aren't obsessively pre-occupied with the simple objective of sending the maximum amount of transactions possible given the algo. If they were obsessed with this purpose then they would surely be smart enough not to let the block median fall down.

<a​rticmine:monero.social> If they let the short term median fall then they have to start all over again. That is by design

<f​r33_yourself:monero.social> I think a wait and see approach is fine. Based on Rucknium's comment if I had to speculate then the attacker IS NOT trying to push up the Long Term Median about two months from now. They are (if this is truly adversarial and malevolent) simply trying to poison as many outputs within the current bounds of the blocksize. This will likely decrease effective ring-size, but I don't kno<clipped me

<f​r33_yourself:monero.social> w if it's worth a hardfork to try to tweak things in this case currently. Not that my single opinion means anything anyways haha

<r​ucknium:monero.social> matrix.monero.social/_matrix/media/…ero.social/qDIIRbkGvldebHZuGaGGVZxD

<r​ucknium:monero.social> ^ The 100 block median has fallen back down a few times, but the block size is still increasing.

<r​ucknium:monero.social> In the plot you can also see when miners push the block size up when there are high-fee txs that compensate for the block reward penalty for going over the limit.

<a​rticmine:monero.social> Yes but the question is how to interpret the data before and after 300,000 byte block size

<a​rticmine:monero.social> As the tx pool fills up one expects a stable block size

<a​rticmine:monero.social> Since the tx pool acts as temporary tx storage to compensate for fluctuations in tx demand

<a​rticmine:monero.social> By the way the bump in December 2023 is consistent with the seasonal retail surge. In the VISA case this can be 16x the annual average. Here we can have an average of say 1500 retail Rx a day surging to 20,000 tx per day just before the holidays

<a​rticmine:monero.social> This is critically important when sett the amount by which the short term median can surge over the long term median

<a​rticmine:monero.social> The degree of fluctuation in the block size is not consistent in my view with a spam attack. .The frequency of the fluctuations is way too high. Also look at the small fluctuations after the block size is over 300,000 bytes

Is it a good design that the short-term median can just drop all the way back to 300 Kb, if the flood stops just for a couple hours? It dropped again today

Even if the flood stays at the same level, many blocks are found faster than in 2 minutes, so they will be smaller, and it can eventually drop the median

<m​onerobull:matrix.org> Isn't it good to drop it quickly?

It's not good when we will have a real flow of transactions above 300 kb block size. We'll get congestion periodically every time the median drops

sech1: It is designed with the expectation that normal tx volume doesn't massively surge and the sustain itself at a much higher volume. The short term is flexible to accommodate temporary short-term bursts but otherwise to be (relatively) expensive for spam.

then*

But what if "normal tx volume" is above 300 kb, will the median stay above 300 kb without dropping? Was it tested?

assuming all transactions come at the same steady rate

Yes when the long term median catches up

<r​ucknium:monero.social> rbrunner7: For the analysis of how different ring sizes would defend against black marble flooding, should I compare ring sizes by block size or flood tx volume? When ring size increases, the bytes per tx increases of course. Basically, what should be the X axis? What I've written so far compares ring sizes by block size.

<r​brunner7:monero.social> Well, I'm a bit out of my depth here.

<j​ack_ma_blabla:matrix.org> what if pre 18.2.2 decoy selection algo was used ?

<r​brunner7:monero.social> You linked to a nice graph in the MRL meeting, [this one](matrix.monero.social/_matrix/media/…ero.social/bGgVqJzYAtzSQXUdTKOcWunA)

<r​brunner7:monero.social> Would your work result in a "family" of such graphs, one per ring size that is "interesting"?

<r​brunner7:monero.social> (With the approach that you currently follow, "compares ring sizes by block size")

<r​ucknium:monero.social> Yes. Multiple lines on the same plot

<r​brunner7:monero.social> I guess that would be informative and easy to grasp, yes.

<r​ucknium:monero.social> I guess which comparison makes the most sense depends on if the dynamic block size algorithm would change when the ring size changes.

<r​brunner7:monero.social> It's all so very dynamic, it's hard to get a good grip on.

<r​ucknium:monero.social> jack_ma_blabla: 18.2.2 just fixed the off by one block error. The before and after decoy selection algorithms are very close.

<r​brunner7:monero.social> You probably can't cram everything into two-dimensional graphs, and with reasonable effort to make the graphs

<r​brunner7:monero.social> An extension of the linked graph with several lines for several possible ring sizes should give us something at hand to discuss and maybe decide.

<j​ack_ma_blabla:matrix.org> Rucknium: if we increase ringsize and limit number of decoys we select from recent blocks will that help ?

<r​ucknium:monero.social> Ok. Here are my assumptions: There is a set of non-spam txs. I have data on their number of outputs and inputs. I multiply the inputs by a factor, assuming that the impact of +1 ring member creates a linear increase in the amount of input data. That non-spam set of txs fills blocks by a certain kB. Then I have all the spam txs as 1in/2out. The size of each spam tx also increase wh<clipped message

<r​ucknium:monero.social> en ring size increases.

<r​ucknium:monero.social> jack_ma_blabla: Increasing the ring size helps reduce the impact of any attempted black marble flooding, but if more old outputs are selected as decoys, then that opens a different type of attack vector. Moser et al. (2017) and Kumar et al. (2017) both exploit the divergence between the real spend age distribution and the decoy distribution to guess the real spend with high probability of success

<r​ucknium:monero.social> Decoys must be credible. They must look like the real thing. They must actually draw the attention of the adversary. Lots of very old decoys are not credible. An adversary would ignore them.

<r​ucknium:monero.social> Moser et al. (2018) I mean. They use the "Guess newest heuristic"

<j​ack_ma_blabla:matrix.org> but currently if you are spending old outputs with recent decoys as most are from same attacker, that would also stand out ?

<j​ack_ma_blabla:matrix.org> also if 90% of recent decoys are owned by attacker, those are useless anyways 🤔

<r​ucknium:monero.social> How would they stand out?

<j​ack_ma_blabla:matrix.org> those recent outputs decoys are already known to the attacker that those are fake

<j​ack_ma_blabla:matrix.org> those recent output decoys are already known to the attacker that those are fake

<r​ucknium:monero.social> The attacker also know that old outputs are unlikely to be the real spend

<j​ack_ma_blabla:matrix.org> sorry but i do spend old outputs too

<r​ucknium:monero.social> And there are many, many rings on the blockchain that have old ring members but the old ring members are not the real spend. That is the theory of ring signature K-anonymity. So an adversary do not know that your rings, that actually spend the older output, are the ones where the old output is the real spend

<j​ack_ma_blabla:matrix.org> but using recent ouputs which we know are 99% poisoned is not a smart thing to do, if we are increasing ringsize then we should limit the amount of recently used decoys

<r​ucknium:monero.social> This is Remark 2 of Ronge, V., Egger, C., Lai, R. W. F., Schröder, D., & Yin, H. H. F. (2021). "Foundations of ring sampling." moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=19

<r​ucknium:monero.social> > Attentive readers might observe the following peculiar phenomenon: Suppose the real signer happens to be Alice who has very low signing probability according to S. It is likely that the mimicking sampler produces a ring in which all members except Alice have high signing probabilities, making Alice stand out. This is paradoxical since the mimicking sampler is close to optimal.

<r​ucknium:monero.social> > The answer to the riddle is that the sampled ring could be, with similar probability (not the same due to potential collision), the result of someone else in the ring being the real signer, and picking Alice as a ring member.

<r​ucknium:monero.social> > With the same reasoning, the mimicking sampler naturally resists timing attacks described in Section 2.1, which assumes that the signing probability of a signer depends on its age (c.f. Section 7.1). Indeed, the event that a young signer ending up in the ring could be with similar (high) probabilities the result of him being the signer or him being chosen by another signer.

<r​ucknium:monero.social> The share of recently owned outputs keeps rising in your example. The real amount (about 75%) to 90% and then to 99%.

<j​ack_ma_blabla:matrix.org> what are the chances of algo picking non-poisioned outputs from recent blocks ?

<r​ucknium:monero.social> We don't know a way that the decoy selection algorithm could automatically detect black marbles. The adversary could just change their txs to avoid the detection. Having multiple standard decoy selection algorithms being used on the blockchain also opens another attack vector: github.com/Rucknium/misc-research/t…o-Fungibility-Defect-Classifier/pdf

<r​ucknium:monero.social> So a change in the decoy selection algorithm is safest at a hard fork boundary when all wallets must upgrade

<j​ack_ma_blabla:matrix.org> yes, change dsa when we increase ringsize and increasing ringsize now should be ok as there has been no HF for quite sometime

<r​ucknium:monero.social> If there is a hard fork in 6 months, a large share of the decoys should be selected from more than 6 months prior because that's when the black marble flooding started? Not a good idea.

<j​ack_ma_blabla:matrix.org> we did emegency hf's before for pow, we can do it now

<r​ucknium:monero.social> Maybe it would be a good idea to select even more decoys from the spammed time interval so that the non-black-marble decoy selection distribution is closer to the intended decoy selection distribution. But like I said, it is too difficult to write wallet software to identify black marble outputs automatically.

<a​rticmine:monero.social> The interim solution I see is:

<a​rticmine:monero.social> 1) Increase the reference TX size to 8000 bytes

<a​rticmine:monero.social> 2); Only increase the penalty free minimum to 400,000 bytes

<a​rticmine:monero.social> 3) Increase the minimum node relay fee 4x before the start of the penalty.

<a​rticmine:monero.social> This will accommodate Tx sizes of around 6000 bytes. Full membership proofs or at least ring 40 with the current proofs

<a​rticmine:monero.social> Actually this can accommodate a ring size of even 50 with the current proofs

<a​rticmine:monero.social> The key tool that will also be needed is graphics parallel verification

<r​ucknium:monero.social> I plan to run scenarios of effective ring size with ring size 16, 25, 40, and 60. Is this a good set of ring sizes?

<a​rticmine:monero.social> Yes

<a​rticmine:monero.social> We can also add the proposals I discussed at the last MoneroKon

<a​rticmine:monero.social> 1) Increase the scaling rate of the long term median from 1.7 to 2 and lower the surge factor for the short term median from 50 to 16

<a​rticmine:monero.social> 2) Introduce an ultra long term sanity median of 1000000 bytes. This will follow Nielsen's law. The surge of the long term median will be based upon the upload bandwidth of a high end consumer or small business bandwidth. This is currently about 3Gbps

<a​rticmine:monero.social> This is what I am working on

<a​rticmine:monero.social> My take is that this will make the transition to full membership proofs seamless from a scaling point of view