<c​haser:monero.social> they are anonymous, reputationless, practically homogenous contractors that coin holders (in the form of supply inflation) and senders (tx fees) hired.

<f​r33_yourself:monero.social> Forgive me if it's out of turn to comment here aftering the meeting. But sgp's concise statement here accurately summarizes my take as well. Increased ringsize is ok, but really the fee and dynamic structure should be adequate to deter even fairly serious attackers in the first place. (Assuming it is possible to do so).

<f​r33_yourself:monero.social> I think sgp is on the right track here. I do think some current users will be a bit miffed by $0.10 transaction fees. But I think the people who are willing to go through wallet syncs, 10 block lock, and other UX problems are also willing to pay slightly higher fees. There are many digital garbage payment methods that have very low fees. There is currently only one fair launch POW<clipped me

<f​r33_yourself:monero.social> crypto-currency with tail emission and encrypted amounts. Monero shouldn't be overly concerned about competing with other payment methods that are cheaper. I have access to more than a handful of ways to send money for cheaper than Monero, but none of them are non-custodial, private, and resistant arbitrary dilution of the currency supply.

<f​r33_yourself:monero.social> I think sgp is on the right track here. I do think some current users will be a bit miffed by $0.10 transaction fees. But I think the people who are willing to go through wallet syncs, 10 block lock, and other UX problems are also willing to pay slightly higher fees. There are many digital garbage payment methods that have very low fees. There is currently only one fair launch POW<clipped me

<f​r33_yourself:monero.social> crypto-currency with tail emission and encrypted amounts. Monero shouldn't be overly concerned about competing with other payment methods that are cheaper. I have access to more than a handful of ways to send money for cheaper than Monero, but none of them are non-custodial, private, and resistant to arbitrary dilution of the currency supply.

<g​fdshygti53:monero.social> 10 cents fee is not the same for everyone

<g​fdshygti53:monero.social> While it's nothing for you or me, it's can be 1% of your salary somewhere in africa

<g​fdshygti53:monero.social> But he is right, that is going to increase for the spammer a lot

<s​gp_:monero.social> Again, while I understand the emotional reason for low fees, the reality is that if they are too low to deter a damaging amount of spam, then they are too low.

<s​gp_:monero.social> And privacy loss is only one of the damages, setting aside permanent blockchain storage, node data, wallet sync time and data, etc

<s​gp_:monero.social> I'm not saying AT ALL to throw out affordability as a goal. But having low fees to the detriment of security and privacy is an issue

<a​rticmine:monero.social> How do you propose to enforce a few that is 25x what is needed for scaling? If the answer is node relay what is to stop a miner or mining pool from accepting transactions directly on a website in exchange for personal information?

<a​rticmine:monero.social> A fee

<a​rticmine:monero.social> What if there is a sudden increase in the price? This has happened before.

<s​gp_:monero.social> Unfortunately, price in the future is a total unknown. Sadly, we need be be kinda restrictive and allow a fee market to form. And in the meantime, I don't know a better solution than adjusting each fork as necessary. However, in the future, perhaps some mechanism where miners could vote to adjust the minimum could be researched and used.

<s​gp_:monero.social> There likewise could be a major decrease in price. No matter what, some adjustment is needed in those cases to be safe, either done by the market or by social consensus

<s​gp_:monero.social> We're not going to be able to predict the future price accurately. It's not a function of the number of transactions. It's not about the mining hashrate. We can't create an algorithm to predict it :(

<s​gp_:monero.social> Anchoring to hashrate might be the most sensible of those ideas though, since at least there's a direct, real cost

<s​gp_:monero.social> Even so, there's a built in prediction of future hashrate costs, which are unknowable

<a​rticmine:monero.social> Monero has a fee market that actually . If you mean the Bitcoin so called fee market that is another matter

<s​gp_:monero.social> Monero only very recently has a fee market :)

<s​gp_:monero.social> Thank you spammers ❤️

<a​rticmine:monero.social> You mean when we went into the penalty

<s​gp_:monero.social> Yeah. We need a fee market that is robust enough to keep spam from consuming most block space. For Bitcoin, the fees are high enough that people aren't spending just to mess around, at least in large numbers

<s​gp_:monero.social> (yes I know "spam" is undefined and a moving target, but again, we gotta start somewhere)

as far as using hash rate/difficulty for setting fees, Monero lost ~35% of its HR when Zephyr became the thing to mine

<s​gp_:monero.social> That wasn't a serious suggestion by me to use, and yes there are certainly many challenges with that approach. At least RandomX is a very market-efficient algorithm

<s​gp_:monero.social> There are nearly 0 barriers to entry which is important

<a​lex:agoradesk.com> sgp_: am I understanding correctly that you would be for a fee increase even if we had FCMP?

<a​lex:agoradesk.com> You just think sending txs is too cheap to not be subject to spam attacks in general?

<a​lex:agoradesk.com> Regardless of the privacy implications?

<s​gp_:monero.social> Versus the fee level we have today, yes. These transactions will be even larger (though clearly worth the cost for their great privacy), so it'll be sensible to have higher (but still reasonable) fees

<a​lex:agoradesk.com> And what is your measuring principle for what fee will deter a sufficient amount of spam?

<a​lex:agoradesk.com> I mean, look at Bitcoin, there's a huge amount of spam even with fees of multiple dollars per tx.

<s​gp_:monero.social> It would need to be an analysis of the costs of running a node (estimated strain on the network) more than anything. Take the current bandwidth cost of maybe $5/TB, multiply transaction size by ~10 to account for propagation, take current basic SSD storage costs for the space, discount that into perpetuity by maybe 10-20% a year, etc.

<s​gp_:monero.social> We'll never stop all spam and that's not the goal

<s​gp_:monero.social> Yes, this still involved future assumptions as well. So ultimately there still needs to be a competitive fee market

<a​lex:agoradesk.com> How exactly would that analysis yield an optimal anti-spam fee figure? The price of XMR is in constant flux, and spam can be done as much by a single big actor as by a huge amount of small actors.

<a​lex:agoradesk.com> There's too many variables that change too fast.

<a​lex:agoradesk.com> Best we can hope for if preventing spam is such a huge priority is setting it as high as bitcoin and hoping for the best.

<s​gp_:monero.social> There's no perfect in every way solution. You either need small blocks and a competitive fee market, or a social method for updating the minimum fee. Or something else :p

<f​r33_yourself:monero.social> In my opinion it might be the case that the current fee level is "fine". But I think the fee should increase at a "steep enough" rate in lockstep with the block size expansion to disincentivize the spammer from perpetually bloating the chain.

<f​r33_yourself:monero.social> I think chain bloat is a bigger issue that could be at risk than a decrease in effective ring size

<a​lex:agoradesk.com> If we just ad-hoc increase the fee every time we don't like how fast txs are coming in, would't that be weird? I mean, let's pretend that this tx volume increase was due to organic growth and not a spam attack, would we be discussing raising fees here? I don't think so.

<s​gp_:monero.social> Oh yeah, before FCMP, we also need to consider an attacker's cost to get to x% of the network, where x% is the amount of new outputs they need to get other network transactions to effective ringsize y

<f​r33_yourself:monero.social> If the attacker just wants to sit there and flood the current blocksize I don't think there is much that we should worry about. But I think his expenses should increase at least proportionally as the block size expands. As long as this is the case then we have a "high enough" fence to deter flooders and bloaters

<a​lex:agoradesk.com> OK so this attack would need to run for a *long* time before a worrying decrease in privacy would occur, right? By that time we'll probably have FCMP.

<s​gp_:monero.social> One way out of this is to get a bunch of organic people willing to use Monero and pay more than the spammer. That's another choice haha

<s​gp_:monero.social> No, see rucknium

<s​gp_:monero.social> He had graphs during the meeting showing a meaningful drop from this alone

<f​r33_yourself:monero.social> I don't think there's a way to stop a flood attack on a low fee and low honest usage network. But if the flooder wants to spam SO HARD that he increases the blocksize then he should have to pay a meaningful increase

<a​lex:agoradesk.com> Forgive me, what was the number? We're down to how many now?

<s​gp_:monero.social> I think 6 but I don't recall. One sec, let me fetch

<a​lex:agoradesk.com> From 16 to 6 just from these two weeks? That can't be right.

<g​fdshygti53:monero.social> 5.5 I think

<s​gp_:monero.social> Here. It's 5

<s​gp_:monero.social> Yes it's at least close, the selection biases new. And the attacker has something like 80-90% of outputs

<f​r33_yourself:monero.social> Like imagine that the number of honest transactions stays the same and the flooder continues to flood the network WITHOUT increasing the blocksize. Then increasing fees marginally in USD terms probably doesn't do much to him. and we may just decrease the honest transaction count in this case. But we can make them pay a drastically higher rate if blocksize expands (or at least a me<clipped me

<f​r33_yourself:monero.social> aningfully higher rate)

<a​lex:agoradesk.com> OK, so it seems that due to the nature of how this works it quickly drops down to 5 but doesn't drop lower.

<a​lex:agoradesk.com> And for it to drop way lower you'd need to sustain the attack for years

<s​gp_:monero.social> Right. If they have x% of new outputs, they pay roughly that x% of the network fees

<f​r33_yourself:monero.social> basically we can't stop the attacker right now, but if he wants to increase blocksize he should have to pay some big bucks. Also even if Monero's effective ringsize has meaningfully deteriorated it is still more private than all other currencies online

<a​lex:agoradesk.com> Sounds like ArticMine has the right solution

<s​gp_:monero.social> Yes, dropping further would take a while and/or a much larger spam % of outputs

<a​lex:agoradesk.com> Up the rings to 40 and we'll get a floor of around 16 until we get FCMP, as well as the fees being higher.

<a​lex:agoradesk.com> Yes, extra disk space. Yes, extra load on the nodes. But the opportunity cost of not increasing rings is also a factor.

<s​gp_:monero.social> You can do that, but I also recommend bumping fees regardless. They're paying almost nothing for this spam. It's a security vulnerability

<f​r33_yourself:monero.social> I wonder how much more they would have to pay if they chose to maximum flood the network after the block size expanded. I feel like that is the more pressing issue. If an intelligence agency can just flood the network cheaply indefinitely even as block sizes go up 1.7x every 70 days then they might choose to do that. Then again they could also choose to majority hash attack and mi<clipped me

<f​r33_yourself:monero.social> ne empty blocks which is even more powerful attack

<a​lex:agoradesk.com> We'll have to do a hard fork if we're doing this. So might as well bump rings.

<s​gp_:monero.social> Theoretically a fee bump can be a soft fork

<a​lex:agoradesk.com> Nah, too easy to sidestep.

<a​lex:agoradesk.com> And financially incentivized.

<f​r33_yourself:monero.social> This is my point too. I don't care if they pay almost nothing to spam the current blocksize. But imagine if they can trivially continue to bloat the chain with cheap transactions while pushing up the long term median every 70 days. This is not a good situation (if it is indeed possible and cheap / trivial given the current structure of how fee's adjust when block size expands)

<s​gp_:monero.social> Yes, they can continue to grow the blocksize. But I don't think it'll grow much with the lowest fee multiplier, by design

<s​gp_:monero.social> There's a lot involved with the formula

<f​r33_yourself:monero.social> I don't understand the way that fees would react to block size expansion haha. I'm just saying if their total expenses don't move up at least in proportion to the expansion of the blocksize then this will likely be an issue in the future

<c​haser:monero.social> I would, because it's still a public demonstration for a future attack.

<s​gp_:monero.social> The current dynamic block size is very permissive for growth fwiw

<a​lex:agoradesk.com> Bitcoin had spam even with fees of 20 USD

<s​gp_:monero.social> The absolute XMR costs per transaction will decrease as the block size grows

<f​r33_yourself:monero.social> I know. I'm talking about how fees themselves would change when after the expansion occurs. Would fees generally go up, down, or stay the same? Even if fees stay the same, by logical consequence for the attacker to push up the new long term median he must proportionally increase his flood and hence his expenses correct?

<s​gp_:monero.social> Yes, the total fees per block still increases

<a​lex:agoradesk.com> Perhaps the real solution to spam is less about fees and more about the ability to prune away all but the strictly necessary data.

<a​lex:agoradesk.com> Because if disk space was free spam wouldn't really matter

<f​r33_yourself:monero.social> Ah that is a bit of a dicey situation then. Basically at best we are hoping that fiat value of fee per tx stays the same and that the attacker has to increase the number of tx's to meet new blocksize cap. So basically we're hoping his expenses increase proportionally with block size. But theoretically they could fall if Monero's price goes down and the blocksize expands

<s​gp_:monero.social> Currently, verification time and the monerod database lock design are the main annoyances, not strictly the size

<a​lex:agoradesk.com> Right. So it would seem to me then that optimizing software should be the priority, before any fee increases

<f​r33_yourself:monero.social> yes, but the trouble is we have to keep all transactions forever because we don't know if a transaction has been spent. this is not the case for the UTXO networks

<a​lex:agoradesk.com> Indeed. At least that's our current understanding.

<s​gp_:monero.social> Fee increases are uniquely well-suited because they can be applied immediately and trivially. But yes, monerod should be improved, and that is tough code to work around.

<a​lex:agoradesk.com> Hard forks aren't trivial.

<s​gp_:monero.social> Ringsize increase is equally trivial as well, but there's a network cost to nodes

<s​gp_:monero.social> Yes, this assumes the hard fork would be uncontentious. Perhaps it would be contentious, idk

<a​lex:agoradesk.com> Not due to contentiousness, but due to having to apply it to the entire ecosystem.

<s​gp_:monero.social> And of course I don't want to hard form without good reason. But a decrease in effective ringsize by >50% suggests there's at least an argument in favor

<s​gp_:monero.social> *fork

<f​r33_yourself:monero.social> I have a problem / question about the dynamic block size: Why would we want the minimum xmr fee per transaction to fall if the long term median goes up? I would think the minimum xmr fee per transaction should stay steady regardless of what the long term median does. I guess the consequence is that if the price of Monero goes up then the fiat value of the miniumum tx fee would als<clipped me

<f​r33_yourself:monero.social> o go up, but I don't really see the problem with that.

<s​gp_:monero.social> Also to your earlier point Alex, the Monero network won't collapse if the status quo continues. Action isn't strictly mandatory

<a​lex:agoradesk.com> Yup. We don't have to rush this.

<s​gp_:monero.social> One of the built-in assumptions is that with adoption comes price increases. But this at least somewhat falls apart when discussing spam

<f​r33_yourself:monero.social> I think the minimum fee in Monero should stay the same and a fee market should develop to push the long term median up. then at the new blocksize where congestion is less, fees will be able to fall some back to the initial mininum fee rate. The need for a decreasing minimum fee measure in XMR seems like an engineering flaw in my opinion

<j​ack_ma_blabla:matrix.org> but the privacy usecase goes out of the window

<f​r33_yourself:monero.social> the gloves are off artic haha

<s​gp_:monero.social> Transaction graph privacy is certainly a lot more questionable now in my opinion, yes. Especially with the view of the spammer's wallet key

<f​r33_yourself:monero.social> jack_ma, you are wrong. Monero just has to be better than all alternatives

<s​gp_:monero.social> Monero had ringsize 5 in what, 2017? Lol

<j​ack_ma_blabla:matrix.org> also currenrly with increase in tx, the price hasnt increased much ; it has just made attack even cheaper

<c​haser:monero.social> the difference is that spam on Bitcoin doesn't weaken the security it guarantees to a user, because it's gives zero privacy. Monero requires different considerations.

<f​r33_yourself:monero.social> To be more concise, I don't understand why it would ever be deisrable to have a minimum fee denominated in XMR that falls as the Long Term Median goes up. To me this seems like a bad idea as it makes it easier to bloat the chain. Instead the minimum fee in XMR at the initial blocksize should remain the minimum fee forever. And a fee market should develop that is the mechanism for <clipped me

<f​r33_yourself:monero.social> pushing up the Long Term Median

<f​r33_yourself:monero.social> I agree 100% with you on this

<s​gp_:monero.social> Bitcoin has spam but it's not 90% of blocks for weeks at a time

<a​lex:agoradesk.com> Oh that's more of a FCMP problem. The fee increase camp seems to favor the fee increase regardless.

<a​lex:agoradesk.com> Rings will remain a weakness for as long as FCMP isn't deployed.

<f​r33_yourself:monero.social> My problem is less so with the current fees, but the way fees behave when the long term median expands. The minimum network fee in Monero should be untouched and the fee market should determine the minimum practical fee to get mined like in Bitcoin. The difference is that we have an algorithm that allows blocks to expand over time and help alleviate congestion whereas bitcoin does not.

<s​gp_:monero.social> Fwiw, I at least mostly agree with you. Mostly instead of completely only because I need to think about it more :)

<s​gp_:monero.social> I like the dynamic scaling, but the other stuff seems to risky and permissible to me

<f​r33_yourself:monero.social> I mean think about it. Why should th minimum relay fee in Monero ever change? It should stay the minimum forever.

<f​r33_yourself:monero.social> If the network is congested enough and fees are high and people are complaining, then eventually after 70 days the blocksize will expand which will alleviate some of the congestion. and the process can repeat indefinitely in a virtuous cycle.

<f​r33_yourself:monero.social> The only reason in my mind that minimum relay fee denominated in Monero should ever be touched is if there is an absolutely huge price pump where the initially established minimum relay fee is now worth a considerable amount of real goods and services. But let's be real here that probably won't happen

<c​haser:monero.social> yes. and we have no idea when FCMP will be deployed. know that it may not even happen with Seraphis. there's a time window between now and the future point of FCMP deployment, during which we have to defend ourselves.

<a​lex:agoradesk.com> Sure, let's bump the rings to 40 and that way even with spam we have the same ring size as now.

<f​r33_yourself:monero.social> What is the current minimum relay fee in Monero in XMR units? and what is it in BTC? In btc it is 1 satohsi per vbite or something like that?

<f​r33_yourself:monero.social> I also have an idea about how self-interested parties could alleviate the black marble attack. It has been said that self-churning if done correctly can mitigate transaction graph tracing? If this is true then won't intelligent high threat model users simply churn more or their coins before moving them to counter the reduced effective ring size?

<f​r33_yourself:monero.social> I also have an idea about how self-interested parties could alleviate the black marble attack. It has been said that self-churning if done correctly can mitigate transaction graph tracing? If this is true then won't intelligent high threat model users simply churn more or their coins before moving them, in order to counter the reduced effective ring size?

I believe that monero currently has similar fees to btc as far as units

<f​r33_yourself:monero.social> This theory is worthless if churning isn't actually beneficial for privacy thoguh

no one knows what correct churning is

<s​gp_:monero.social> Maybe instead of a spammer, this is someone churning their million outputs one at a time :p

<f​r33_yourself:monero.social> Ok, so if that is the case regarding minimum relay fee in Bitcoin and in Monero, then I see absolutely no reason where the minimum transaction fee in XMR units should ever fall as the Long Term Median expands. It is unnecessary and simply makes it cheaper for a malicious flooder or bloater like whoever is currently attacking the network.

<f​r33_yourself:monero.social> If someone can come up with a fairly sound reason for wny the mininum fee in XMR should fall when Long Term Median goes up then I will be watching for that reply. But the response can't be, but what if the price goes up 10,000x lol

<s​gp_:monero.social> Blasphemy! Haha

<j​ack_ma_blabla:matrix.org> there are better options and effective ringsize of 5.5 doesnt work for vendors

<f​r33_yourself:monero.social> dude there are not better options

<f​r33_yourself:monero.social> any dark net vendor using zcash or pirate chain those are joke coins buddy

<f​r33_yourself:monero.social> ok zcash has some good tech but premined and no tail emission

<f​r33_yourself:monero.social> and shielded and unshielded pool i mean reallY? vendors are gonna use zcash over monero with effective 5.5 ring size are you really telling me that?

<f​r33_yourself:monero.social> if dark net vendors actually quit using monero for privacy reasons and use a different coin with programmed self destruction or that was a scam simply because it may over similar privacy then monero is indeed in a tricky situation

<f​r33_yourself:monero.social> if dark net vendors actually quit using monero for privacy reasons and use a different coin with programmed self destruction or that was a scam simply because it may have similar privacy then monero is indeed in a tricky situation

<f​r33_yourself:monero.social> I'm curious to hear what other currency a smart vendor or admin who isn't a stupidhead is using.

<j​ack_ma_blabla:matrix.org> you cant have a sub cent tx fees, when there is a fiat printer which prints unlimited money; sane fees like a few cents is enough for users to transact

<c​haser:monero.social> yes, this is an option for power users who delved deep enough into Monero's mechanics. currently on average you can get pre-flood effective ring size by doing a churn (5^2 > 16). but there is a 99% stratum of users who you can't expect to know that, and not providing them with the privacy that they previously relied on is dangerous (and they may not even know it decreased). churni<clipped message>

<c​haser:monero.social> ng can be theoretically great if you spent years thinking how to do it well, and even then it's not easy *at all*. otherwise it can even lower your overall privacy.

<a​lex:agoradesk.com> I'm not sure this makes sense in terms of preventing a spam attack. It's a slippery slope and it doesn't really solve the issue.

<j​ack_ma_blabla:matrix.org> does that even fix the effective ringsize if spammer just increases the % of spam outputs ?

<f​r33_yourself:monero.social> Yes, it was simply a theory though. What you said about normies is true. I am a normie too. I don't care to churn nor know how to churn. So it may decrease their safety under a given threat model

<a​lex:agoradesk.com> They'd have to increase the % exponentially to further reduce the effective ring size.

<j​ack_ma_blabla:matrix.org> churning doesnt work with this black marble attack

<f​r33_yourself:monero.social> that's what i thought jack ma you dodged my question. Everybody with a brain that is a vendor or site admin should be using Monero and nothing else

<j​ack_ma_blabla:matrix.org> agreed, making it cheaper to attack is stupid

<f​r33_yourself:monero.social> I don't understand churning that well. I just thought it could be a possibility for people who do truly need that crazy tier threat model. but honestly for those acters there are other points of failure with much higher risk than the effective ring size

<j​ack_ma_blabla:matrix.org> allowing someone to lower moneros privacy at no cost is a slope itself, making it cheaper to bloat the chain is even more crazy

<j​ack_ma_blabla:matrix.org> yah so they can increase it & if the fees are cheap, they can do it

<a​lex:agoradesk.com> They can do it with $0.1 fees as well.

<a​lex:agoradesk.com> It's not a question of "if only we had the will to put $0.1 we would stop all spam"

<j​ack_ma_blabla:matrix.org> 0.1 * 100k * 2.5 day cost @ 40ring

<j​ack_ma_blabla:matrix.org> 0.1 \* 100k \* 2.5 /day cost @ 40ring

<j​ack_ma_blabla:matrix.org> compare that to 0.001 fee rn

<f​r33_yourself:monero.social> I actually have come full circle and think the current fees are perfect. But it is a pinhead move to have the minimum fee drop after the Long Term Median expands. Bad Engineering IMO

<f​r33_yourself:monero.social> And to be honest if you think about people who are practically using Monero today in high threat model circumstances, the loss in anonymity they incur from the effective ring size falling by 66% is trivial in comparison to the probabilistic risks they face when they cash out their Monero

<j​ack_ma_blabla:matrix.org> or we can just let the chain bloat, expose users till mythical fcmp gets implemented in monero

<a​lex:agoradesk.com> Those risks aren't for us to control though

<f​r33_yourself:monero.social> Their offramp risk is still much higher relative to the relative decrease in on-chain anonymity from a lower effective ring size

<a​lex:agoradesk.com> It's not either or, we can implement arcticmine's proposal first and then see if further action is necessary.

<f​r33_yourself:monero.social> you make a fair point. I'm just saying in practice this isn't a chicken little situation. It is not a good situation, but Monero's death isn't iminent from this black marble attack at its current scale

<j​ack_ma_blabla:matrix.org> effective ring size decrease for transaction they do to cashout, is the issue; EAE and EABE attacks are much easier with current effective ringsize

<a​lex:agoradesk.com> Without a doubt this is not a existential threat to XMR, at the moment.

<j​ack_ma_blabla:matrix.org> and how many weeks/months before we fail and then comeback to again wait to implement it ?

<a​lex:agoradesk.com> Maybe a few, maybe infinity.

<a​lex:agoradesk.com> You don't know.

<f​r33_yourself:monero.social> I actually think raising fees is an admission of defeat. We don't have enough honest competition for blockspace to deter an attacker. That is a Monero problem not an attacker problem or a fee problem. If there was more honest demand for blockspace and fees were higher then the attack probably wouldn't be happening right now

<j​ack_ma_blabla:matrix.org> there is no existential threat, even bitconnect coin trades somewhere on the internet

<f​r33_yourself:monero.social> dude if you are a dark net market participant and you cash out via a centralized exchange your fate is sealed lol. That is horrible risk management

<j​ack_ma_blabla:matrix.org> get some outside help with decoy selection, it will fix half of the problem

<f​r33_yourself:monero.social> the solution to the EAE attack is simply to buy p2p.

<j​ack_ma_blabla:matrix.org> but no, you will stick to some paper which talks about some random coins which actually are not used for reference as spend pattern & get yourself exposed badly to this blackmarble attack

<j​ack_ma_blabla:matrix.org> good luck boys, hope you figure it out

<f​r33_yourself:monero.social> you sound a bit salty big fella. maybe a zcasher trying to come in here and tell us that people will use it on the dark web haha. You don't seem like a total troll though haha

<w​izeguyy:tchncs.de> I want to bump this. You laughed it off, but it may not be that crazy. I would happily volunteer to pay multi-dollar fees, and contribute to this effort. There's some details to work out, but I think its possible, and I think there are others in the community willing to fight that fight

<w​izeguyy:tchncs.de> Every service provider I pay easily charges several dollars in processing fees. I might as well spend a dollar or two to contribute valuable outputs to the anonymity set

<g​ingeropolous:monero.social> mah gerd the scrollback. another idea - change the shape of the block reward penalty curve

<g​ingeropolous:monero.social> it's probably linear currently (?)

<a​rticmine:monero.social> There is a rough correlation between Tx per day and average USD price bitinfocharts.com/comparison/transactions-price-xmr.html#log&alltime

<a​rticmine:monero.social> This is apart from what the explanation of exchange predicts

<a​rticmine:monero.social> Also en.m.wikipedia.org/wiki/Metcalfe%27s_law Metcalfe's Law

<a​rticmine:monero.social> It ranges from linear to quadratic for various coins XMR, LTC,, DOGE, DASH and BTC before 2015

<a​rticmine:monero.social> The big difference was BTC after 2015 when the blocksize growth was artificially restricted

<a​rticmine:monero.social> So yes one would expect the price to grow between linear and quadratic with the blocksize

<a​rticmine:monero.social> Also the point is that a spammer has to keep up the spam attack for over two months to trigger the long term median.

<a​rticmine:monero.social> Only then is the reduction in fees triggered.

<a​rticmine:monero.social> ... and as I said before a minimum node relay fee that is too high can trigger miners bypassing the nodes and accepting transactions directly. This will be disastrous for privacy and decentralization.

<a​rticmine:monero.social> Also I recommend this talk on Blockchain Surveillance from Monertopia youtu.be/ky_euJ4067o

<a​rticmine:monero.social> It will open your eyes on Blockchain Surveillance (BS) and the real need to harden Monero's privacy and at the same time encouraging organic growth in Monero BS is a real threat even to Monero

<a​rticmine:monero.social> The most likely cause of this kind of black marble attack is a BS company testing the waters. This is what I suspect happened before. They will find out it does not work but they may try to sell it to the government anyway. There is a lot of money to be made. So the ideal is to remove the illusion of surveillance. A fee increase will not do that but ring 40 is a good start especia<clipped messag

<a​rticmine:monero.social> lly when combined with an increase in organic growth.

We could come up with a PROPER churning guide for users ASAP. If many users start churning properly, it will not only increase their anonymity set exponentially, it will also increase the number of transactions, thus reducing the spam efficiency. Good plan?

<a​rticmine:monero.social> This is a good idea. It will help.

spackle_xmr^

<g​fdshygti53:monero.social> I approve ^

<a​lex:agoradesk.com> So, basically decentralized counterspam.

<g​fdshygti53:monero.social> I think ideally you also want to churn with 1:2, With minimum fees, and do it during peaking spam period (It might not change anything vs the people who own the spammer keys, but for other observers, your the spammer)

Work to analyze proper churning has been previously attempted and resulted in nothing conclusive.

I believe done before our current ringsize of 16

Has any more recent work been done on this?

<g​fdshygti53:monero.social> matrix.monero.social/_matrix/media/…ero.social/zbxDYuYwlmdGjZFhnNjNXbRX

<g​fdshygti53:monero.social> Just an idea like that

<g​fdshygti53:monero.social> It usually start at a round hour (so don't churn if TX go up at 3h27)

<g​fdshygti53:monero.social> Seam to have bigger peak every day at 13H UTC

<g​fdshygti53:monero.social> It usually start at a round hour (so don't churn if TX go up at 3h27)

<g​fdshygti53:monero.social> Seam to have peak than average every day at 13H UTC (not necessarily biggest peak of the day)

<u​nkn8wn69:matrix.org> How much did the average input/output ratio change since the attack began? Can someone Rucknium: maybe find this out? This would be very solid proof for a spam attack

<g​fdshygti53:monero.social> Could the DSA be altered to use decoy out of peek spam time? Higher change to get non spam output?

<g​fdshygti53:monero.social> matrix.monero.social/_matrix/media/…ero.social/oZfrhgTWqjkwbcBFEDpxdALZ

<r​ucknium:monero.social> EAE/churning is MRL's white whale. Many researchers have gone down with the ship. Call me Ishmael.

<r​ucknium:monero.social> spackle_xmr's idea to send a churn txs at a random time drawn from the decoy selection distribution (right-truncated distribution at 3 days) seems reasonable to me. The perfect (rigorous analysis) may be the enemy of the good enough (reasonable guess). But then the CryptoNote developers thought users choosing their own ring size as low as 1 was reasonable. Later analysis found tha<clipped message

<r​ucknium:monero.social> t it was a very bad idea.

<r​ucknium:monero.social> unkn8wn69: That was the first item in our "Fingerprinting a Flood" analysis: mitchellpkt.medium.com/fingerprinti…ero-transaction-volume-a19cbf41ce60 . I am not focusing on evidence for/against the spam hypothesis now. I am focusing on the privacy impact under the assumption that it is spam so that countermeasures c<clipped message

<r​ucknium:monero.social> an be discussed. But I can create that plot pretty quickly.

<r​ucknium:monero.social> unkn8wn69: Here is the volume of the eight most common input/output tx types: github.com/Rucknium/misc-research/b…df/images/in-out-tx-type-volume.png

<r​ucknium:monero.social> The vertical axis is on a log scale. Only 1in/2out transactions increased on March 4.

<r​ucknium:monero.social> There is a "clue" in the 1in/2out volume. What conclusion the clue is pointing to, I'm not sure yet. In the July/August 2021 suspected spam there were a lot of 1in/2out _and_ 2in/2out suspected spam. The spam volume increased suddenly at the beginning and gradually reduced. Maybe the volume reduced because outputs were getting consolidated in the 2in/2out txs. The sudden increase <clipped message

<r​ucknium:monero.social> and gradual decrease also occurred in the December 2023 suspected spam.

<r​ucknium:monero.social> `wallet2` has logic that constructs txs with 2 inputs even if there is enough to pay the tx with one input. Specific conditions need to be met, but I think they are usually met: monero.stackexchange.com/questions/…two-or-more-inputs-for-transactions

<r​ucknium:monero.social> Say I create lots of outputs for spamming. Then I set the wallet to spam txs as much as possible. Eventually all those outputs will be consolidated because of the `wallet2` logic even if the value of the outputs is large enough to pay for 1in/2out txs. The current suspected spammer probably is using coin control, has the outputs in separate accounts in the same wallet, or using se<clipped message

<r​ucknium:monero.social> parate wallets for each output.

No, just using sweep_single command is enough to produce 1/2

<a​rticmine:monero.social> Just churning to a single input to a single output will generate 1/2 because of the second dummy output

<a​rticmine:monero.social> If this is a BS company testing the waters they do not want to create clustering so empty outputs will fit the bill.

<a​rticmine:monero.social> Still to avoid detection it would make sense to balance the spam with a promotional number of 2 in 2 out at least

<a​rticmine:monero.social> Proportional

<a​rticmine:monero.social> On another note I do not see the December 2023 as spam. This is very consistent with a surge in reta transactions just before the holidays. By the way VISA gets like a 16x surge in the same time period

<a​rticmine:monero.social> Retail transactions just before Christmas

<p​oliticalweasel:matrix.org> A few people were saying earlier that this attack may be intended to force a fee hike, but... hastily increasing the ringsize by 150%, thus more-than-doubling node resource usage, still not solving the fundamental vulnerabilities of the decoy model, and increasing fees anyway, seems like a much more potent attack to pull off than making users pay a couple pennies more per transaction.

<p​oliticalweasel:matrix.org> Especially when the spam is 1/2 (optimal for a bloat attack) instead of 1/16 (optimal for a denanonymization attack)

<p​oliticalweasel:matrix.org> It's not as if the spammer is trying to be stealthy, either

<a​lex:agoradesk.com> Well yeah, only FCMP will fundamentally solve it. Bumping the rings to 40 is just a (hopefully) temporary measure to get us back to an effective ring size of ~16 while it's being implemented.

<p​oliticalweasel:matrix.org> Right, but it's not clear that the drawbacks of such an aggressive bump would be worth the benefits. At least with FCMPs, in exchange for the increased burden on nodes, we get 1) an actual solution for deanonymization attacks, 2) with Seraphis, an actual solution for privacy-respecting light wallets, and 3) vastly more effective pruning capabilities.

<p​oliticalweasel:matrix.org> Piling more permanent bloat onto nodes, especially when Monero tx's are already way too big, needs a very good justification. Doing it for a bandaid solution is not, IMO.