<r​ucknium:monero.social> There was unusual fee behavior yesterday and today. There are four standard fee tiers: 20, 80, 320, and 4000 nanoneros per byte. On March 11, the share of "non-spam" txs paying 320 nanoneros/byte was 4.5%. It had been steady for a few days until then, too. Then on March 12 and today the share of those 320 fee txs increased to about 35%.

<r​ucknium:monero.social> In the block tabulation, it looks like this set of 320 fee txs started at block 3103476 (2024-03-12 14:04:08 UTC) and ended after block 3104042 (2024-03-13 08:42:57 UTC). These 320 fee txs are almost all 1in/2out.

<r​ucknium:monero.social> It could be a big centralized service turning on and off its fee priority. Or the suspected spammer could be changing its behavior.

<r​ucknium:monero.social> The auto fee fix to the GUI/CLI wallet only increases fee from 20 to 80 nanoneros per byte when the mempool is congested.

<r​ucknium:monero.social> Fee tabulation by block: paste.debian.net/hidden/fb7ec136

<r​ucknium:monero.social> Ah, wait that tabulation was just for today. Here is yesterday and today: paste.debian.net/hidden/8d45e207

<r​ucknium:monero.social> MRL meeting in this channel in about two hours

<r​ucknium:monero.social> By the way, the numbers for the lowest fee tier (80) don't add match the blockchain data since I remove a portion of the low-fee 1in/2out txs as "spam".

<r​ucknium:monero.social> I mean lowest fee tier (20)

<r​ucknium:monero.social> Meeting time! monero-project/meta #978

<r​ucknium:monero.social> 1) Greetings

Hello

hi

<d​angerousfreedom:matrix.org> Hi

<0​xfffc:matrix.org> Hi everyone

<c​haserene:matrix.org> hi

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<r​ucknium:monero.social> me: Analyzing the blockchain and mempool data from the last week and a half of the suspected spam incident.

I was working on finding a segfault lws (still not found), unit testing the lws rest api, and a little bit on figuring out how to enable multi-machine scanning in lws

I may punt on the last one, as its looking pretty complicated

until someone explictly needs it (its probably unlikely)

Like some sort of load balancing?

<0​xfffc:matrix.org> Me: I updated RW lock (9181) last week, the lock is final at this point. Worked here and there on few GitHub issues. But main thing I am working on is performance benchmarks suite for XMR. I finished a prototype yesterday. ( github.com/0xFFFC0000/monero-perf/tree/main/private-testnet ). The prototype does have 3 wallet limitation. Now I am implementing it in C++ ( https://<clipped message>

<0​xfffc:matrix.org> github.com/0xFFFC0000/benchmark-project ). Numbers from these performance benchmarks can help us a lot in evaluating different PRs (including the 9181).

rbrunner: yes, send account scanning over socket to other machines for scanning

<r​ucknium:monero.social> 3) Discussion. We have the possible spam incident: bitinfocharts.com/comparison/monero-transactions.html#3m

<r​ucknium:monero.social> I've been estimating the mean/median/percentile effective ring size of this is actually the prophesied black marble flooding.

<r​ucknium:monero.social> The mean has been about 5.5 for the last few days. If the "spam" volume stays the same, it will decrease slowly now as more of the probability mass of the decoy selection algorithm moves into the spam time interval.

<r​ucknium:monero.social> isthmus might try to re-run the scripts that we wrote to analyze the 2021 spam incident. The database workflow that we were using us broken, so it has to be repaired or a new workflow written. The 2021 analysis was mostly to provide evidence for or against the txs being produced by a single entity.

<r​ucknium:monero.social> Is there a critical threshold for effective ring size that should not be crossed, assuming this is a black marble flood? What do we think?

Hard to say. Rings are only 1 of 3 privacy mechanisms, amounts stay invisible, stealth addresses hold, even if the effective rings size continues to go lower.

We lived for quite some time with a ringsize of 5, I think. Because that just was the ringsize back then, period.

<c​haserene:matrix.org> I think we're already in the red zone. but going below 3 (historical ring size) would be critically bad

<r​ucknium:monero.social> If the spam stays at its current level indefinitely (about 400kB blocks), the median effective ring size will decrease to 3 eventually. That may be low enough to allow chain reaction analysis. And we shouldn't forget about the extremes. 3 or 5.5 may be average, but some rings will pick up more spam tx outputs by chance.

Well, I think we are mostly aware that if we are not careful any "cure" we come up might turn out to be worse than the "disease"

<r​ucknium:monero.social> Some of the countermeasure that I have seen: 1) Raise fees, 2) Raise ring size, 3) Change dynamic block size algorithm, 4) See if miners will voluntarily limit block size, 5) Launch decentralized counterspam to reduce the share of outputs owned by the spammer. 1-3 would require a hard fork AFAIK.

Blocksize growth seems pretty limited so far. You could speak of a "spam wave", but not, or not yet anyway, a "flood"

<r​ucknium:monero.social> Do we want to try to figure out if a single node (or a small number) is broadcasting the txs?

<c​haserene:matrix.org> I don't think that would be conclusive, the spammer could use many nodes

<r​ucknium:monero.social> The suspected spammer is letting the block size algorithm's 100 block median fall down. Not sure if it's deliberate or accidental. That's limiting the block growth rate.

Yeah, so far it has been a pretty nice spammer ...

<r​ucknium:monero.social> Do you think it would be conclusive if one node were found? You could confirm the hypothesis, but lack of evidence for a single node origin would not confirm that it is not spam.

<c​haserene:matrix.org> that will work against them once eniugh nodes update to the fee patch, but I don't know if we see that yet in fee usage

<r​ucknium:monero.social> Work against them? The auto fee adjustment is wallet-level, not node-level AFAIK. Users have to update.

Yes, the wallet decides the fee factor to apply

<c​haserene:matrix.org> yes, I would conseder that conclusive. so it may be worthy to investigate

<d​angerousfreedom:matrix.org> How do we know that the 20k average txs/day that we had previously were not poisoned by 10k or 15k txs from a spammer?

How would we go on to defeat Dandelion++? Some sort of coordinated listening?

<r​ucknium:monero.social> dangerousfreedom: We do not know that. A slow rise in spam has been theorized before.

<c​haserene:matrix.org> you're right, that's the wallet. if.tney keep stepping back, the block size can't grow and *if* they keep their tx's on the cheap fee level, more honest tx's will be included

<r​ucknium:monero.social> Basically D++ is a statistical obfuscation technique. If the signal is huge, like with spam, then it can be heard above the noise.

<r​ucknium:monero.social> The spammer can keep pushing up block size even if all users update to the auto fee fix.

But that would probably need some daemon instrumentation, to get some statistics, I guess. Or some third program that speaks the protocol.

<r​ucknium:monero.social> Sharma, P. K., Gosain, D., & Diaz, C. 2022. "On the anonymity of peer-to-peer network anonymity schemes used by cryptocurrencies." moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=130

<r​ucknium:monero.social> ^ This paper analyzed D++'s resistance to a specific form of statistical analysis. I thought this paper was unrealistic since they needed huge tx volumes to determine the node origin of txs. But now we have a huge tx volume, so it could work. I tried the paper's python code a while ago and it seemed to work ok.

<r​ucknium:monero.social> Yes the main data you need is tx arrival times at many nodes in the network. Not quick or easy to set up. You would have to get volunteer nodes or nodes that try to place themselves strategically in the network.

<c​haserene:matrix.org> they can, but at at a slower rate compared to a scenario where they increase their fees too, no? there's a chance the increased budget requirement could keep them back

Basically a lot of the analysis here just shows how good Monero is at privacy :)

<j​effro256:monero.social> One problem I have with D++ right mow is that node connections are unencrypted which means that ISPs have an advantage in being able to tell where transactions originated from if they decided to collude

<r​ucknium:monero.social> Did you see my comments before the meeting? Recently there was a big increase in high fee txs. Then that stopped.

<j​effro256:monero.social> Dummy stems don't mean much against DPI

<r​ucknium:monero.social> Yes, IRC the D++ paper says that it doesn't protect against ISP surveillance.

<r​ucknium:monero.social> IIRC*

If we go up with the ringsize and stay in "reasonable" territory, say 20, will that help? And if yes how much? Just needs a bit more spam to overcome?

it's possible that the spammer is using Tor/I2P

<r​ucknium:monero.social> rbrunner: I can run some scenarios

<c​haserene:matrix.org> I didn't, will read the backlog. that's not good

That would be splendid, rucknium

"Not good" as in "making matters worse"?

<j​oiboi.crypto:matrix.org> #FreeOfrnxmr

<r​ucknium:monero.social> Basically, when spam txs increase, effective ring size decays exponentially. So the largest drop happens when the spam volume is "small".

<r​ucknium:monero.social> I have a few plots I can post soon

<c​haserene:matrix.org> rbrunner: I think so, yes

<r​ucknium:monero.social> If the spammer is willing to make high fee (320 nanoneros/byte) txs, then they have a large budget.

Maybe a dumb idea, but we could make the ringsize user-selectable again, with a minimum of 16. So people basically could choose their level of privacy ... or so, maybe that fails somewhere

<r​ucknium:monero.social> I will do rbrunner's suggested analysis of simulating ring size increases. Other suggestions for analysis I could do?

<c​haserene:matrix.org> re: changing minimum fee or dynamic block size algo, I would appreaciate input from ArticMine:

<j​effro256:monero.social> Selectable ring sizes leads to fingerprinting

Yup. It would be a question of the "lesser evil".

And it seems there are no really easy options on the table, sadly

<j​effro256:monero.social> Yeah. If we allow different ring sizes we should probably change the tx weight mechanism since a 2x increase in CLSAG verification time wouldn't lead to a 2x increase in weight

<m​onerobull:matrix.org> Custom ringsize is dumb

<m​onerobull:matrix.org> Isn't that partially at fault for wanacry payments getting traced or was that something else?

<c​haserene:matrix.org> doing this would be a tradeoff. I'm more against than for (horrible optics and UX), but if for, you could prescribe a few ring sizes, not the way it worked in the old days where any amount could go.

<m​onerobull:matrix.org> It's silly, if the attacker owns 90% of decoys they still do that whether you have 15 or 500 decoys but with the later it's way more fingerprintable

Ok :)

<m​onerobull:matrix.org> All of this is solved with fcmps

<m​onerobull:matrix.org> 2 million decoys let's go

rucknium: Maybe try to find out what the effects of "counterspam" would be? How much does the community have to spam to keep "effective ringsize up"?

<r​ucknium:monero.social> I can do that

Counterspam is of course also bad, but well ...

<c​haserene:matrix.org> sounds impossible, but could a FCMP upgrade be feasibly done separately from Seraphis?

<s​emisimple:monero.social> Actually, why not try to counterspam and see if that causes a reaction of the "real" spammer

<c​haserene:matrix.org> because that would be a trump card

Even if possible, that would probably take a year to go into effect. If we don't rush with inacceptable risks

<j​effro256:monero.social> Technically yes, but then you would basically have to remake seraphis lol

<m​onerobull:matrix.org> Biggest issue with counter spam is not knowing when to stop if there are multiple counter spammers

We have to consider that the *whole* reason for the exercise may be to drive us to do something unwise.

<m​onerobull:matrix.org> At this point it's most likely about chainalysis raising money

<r​ucknium:monero.social> IMHO, probably the best short term countermeasure, if it is really a black marble flood, is to see if miners would set a limit on the block size that they will not go above. Only a majority of hashpower would be enough to reduce the 100 block median

That's also my "pet theory", as recently explained on Reddit

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

<m​onerobull:matrix.org> The worst part is, when chainalysis inevitably releases their "tracing monero" report the fud will be immense even though monero still protects amounts and receiver

<m​onerobull:matrix.org> So they can only get down to a 50/50?

<r​ucknium:monero.social> ^ That long term projection is if all decoys are selected from the spam time interval. Since some decoys are being selected from before the spam start point, we are not there yet.

Not immediately clear to me why limiting blocksize is beneficial?

Not as a flood protection, but keeping the effective ringsize up

<c​haserene:matrix.org> that's somithing to keep in mind, yes

<r​ucknium:monero.social> I stopped it at effective ring size 2. I can extend the visualization.

<m​onerobull:matrix.org> I don't think it's needed

<r​ucknium:monero.social> But that's just average. Some txs would have effective ring size 1 since they would select all spammer-controlled outputs by chance.

<m​onerobull:matrix.org> How many TX per day would that even be at effective ringsize 2m

<m​onerobull:matrix.org> How many TX per day would that even be at effective ringsize 2?

<r​ucknium:monero.social> rbrunner: Since limiting block size limits the amount of spam that can be packed in. And keeps the number of real txs constant. I guess that last part assumes that users update to the auto fee fix.

<r​ucknium:monero.social> monerobull: Looks like about 200,000 tx/day would be needed for that.

Yes, and that the spammer does not go higher with fees themselves?

<m​onerobull:matrix.org> 👍

<r​ucknium:monero.social> Yes, also assuming that.

All a bit unfortunate

a company like Chainanalysis would try to keep things under the radar. they wouldn't start spamming 7x the tx amount from one day to another, creating a 20mb txpool, harming UX and making everyone aware that something is going on

Well, who would then?

It's not that all their employees are competent for sure. Who knows who got the job :)

<m​onerobull:matrix.org> Selsta: they might have not expected the auto fee to be broken lol

yeah - someone incompetent

hey, yes, Chainanalysis alright, but they outsorced the job

<c​haserene:matrix.org> if a sensible ring size increase (=doesn't disadvantage many potential users) could get us a significant advantage, that's one intervention that won't have catastrophic downsides and isn't a regression

<m​onerobull:matrix.org> How about a temporary rushed implementation of triptych/s

monermooo must still have a branch around somewhere with that

<a​rticmine:monero.social> A ring size increase combined with parallel verification can work here

<a​rticmine:monero.social> Also we can target the estimated tx size for full membership proofs

there's already a high degree of parallelism on incoming verify

That's an interesting argument: To "adjust" already today to the FCMP tx size

<a​rticmine:monero.social> This would create a seamless transition to full membership proofs from a scaling perspective

<m​onerobull:matrix.org> How big of an increase would that be Artic?

<a​rticmine:monero.social> We could also consider a 4x increase in the minimum node relay fee

+1 for higher fees

<j​effro256:monero.social> I wouldn't be opposed to a fee increase

Even without any idea how deep "their" pockets are?

<a​rticmine:monero.social> How big is the current estimates for a 2 in 2 out full membership proofs Tx in bytes?

That's one of the dangers that I personally see: to rush into some unwise fee increase

i would be in favor of higher fees even if there isn't an attack, sub one cent is too low

is it too low? low tx fee was a seling point

<c​haserene:matrix.org> I don't think we'll ever know how deep their pockets are until they stop

<a​rticmine:monero.social> The consideration is that fees are node relay not consensus

<r​ucknium:monero.social> kayabanerve, jberman : Do you have an estimate for 2in/2out FCMP tx size?

<m​onerobull:matrix.org> I'd be fine with the current "normal" tier fees of about 1.6 euro cents per standard tx. Going above 5 cents kills the "digital cash" aspect imo

<a​rticmine:monero.social> I asked the above question in the last MoneroKon

<m​onerobull:matrix.org> My bank charges 10 cents per tx and I absolutely despise them for it

<a​rticmine:monero.social> That is my idea

<m​onerobull:matrix.org> Besides, it's only cheap in fiat terms at current fiat evaluation

<a​rticmine:monero.social> By the way I can now speak freely after the end of the trial

<r​ucknium:monero.social> If there were a way to have a purchasing power oracle for a unit of XMR, the exchange rate changes wouldn't be a big problem. Maybe it could be linked to network hashpower since hashpower is linked to XMR purchasing power. That makes assumptions about how RandomX hashpower will change in the future.

<a​rticmine:monero.social> There is a justification for a 4x increase in the minimum node relay fee while keeping the current quadratic fee scaling

<a​rticmine:monero.social> There is tx per day and block size

<a​rticmine:monero.social> In the absence of spam

<c​haserene:matrix.org> tying anything to oracles is a huge can of worms and very large attack surface, even just to hash rate

<a​rticmine:monero.social> By the way I am not convinced this is a spam attacj

Fee level is _okay_, panic raising fees is stupid. When price pumps eventually will we panic drop fees? Hardfork every time?

<a​rticmine:monero.social> Attack

<s​emisimple:monero.social> Also fee increase does not fix the underlying security problem, assuming there is one. Just makes it more expensive, which would still be ridiculously cheap for large scale actors

And to be fair 140k tx/day is nothing. Increasing ring size is most sensible thing to do, if do anything

<a​rticmine:monero.social> We need to take a very close look at the impact of the Binance delisting on DEXs, instant exchanges, peer to peer trading and even CEX customer behavior

<c​haserene:matrix.org> note that this works only against DoS, not black marbles. I know you don't think at all this is a black marble scenario, and I think you're wrong on that

<r​ucknium:monero.social> IIRC this paper says basically you can use congestion pricing to form a fee oracle just from user bids for block space: Huberman, G., Leshno, J. D., & Moallemi, C. (2021). "Monopoly without a Monopolist: An Economic Analysis of the Bitcoin Payment System." moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=78

<a​rticmine:monero.social> It does increase the cost

<r​ucknium:monero.social> But that would require accepting a lot of congestion I think.

<a​rticmine:monero.social> ... I am suggesting this combine with a ring size increase

<a​rticmine:monero.social> So a multi faceted approach

<r​ucknium:monero.social> After the Mordinal incident, analysis of P2Pool outputs, and the 2021 spam incident, I have thought for a while that current ring size provides a safety margin that is too low.

<r​ucknium:monero.social> We are 25 minutes past the hour. Should we continue to monitor the suspected spam and continue discussing next Wednesday?

<a​rticmine:monero.social> I have my doubts. That being said there are solutions that can deter a black marble attack until we move to full membership proofs

<c​haserene:matrix.org> thanks. if this paper implies congestion in the sense of tx volume, there are live working examples for that

<a​rticmine:monero.social> Yes but Monero has an adaptive block size

We can revive Mordinals so people will start spamming their NFT transactions

Problem solved

<a​rticmine:monero.social> So Bitcoin solutions will not work

<r​ucknium:monero.social> Black marble flooding was one of the first theorized attacks against Monero privacy. It was analyzed in the first MRL research bulletin. So...plenty of time to develop a solution. almost 10 years

<j​effro256:monero.social> Lol when tx_extra weight clawback?

<r​ucknium:monero.social> ArticMine: IIRC the paper suggested modifying bitcoin's block size limit to adjust to congestion. It was supposed to provide a constant miner revenue from txs in purchasing power terms.

<a​rticmine:monero.social> The best solution is to increase the ring size. Ideally to infinity with full membership proofs

Limit tx extra to 256 bytes so each Mordinal will create a dozen tx

<r​ucknium:monero.social> If the ring size were to increase, what would be a reasonable hard fork schedule?

Hard fork is +6 months after binary release

Not earlier

<a​rticmine:monero.social> Which is not relevant to Monero with its adaptive block size and tail emission

<r​ucknium:monero.social> This is in the paper: "To summarize, this analysis suggests the following simple adaptations to the current protocol. First, a smaller block size K is preferable. Second, an adjustment of the block rate to μ = λ/(Kρ∗) in response to demand λ. This keeps congestion constant at ρ∗, yielding a stable, desired level of revenue."

<r​ucknium:monero.social> Yes, it is probably not feasible because there are a lot of economic assumptions.

<a​rticmine:monero.social> The trouble with Bitcoin like coins is the need to replace falling block rewards with Tx fee

<a​rticmine:monero.social> This premise has never been shown to work

<a​rticmine:monero.social> We only need to be concerned with pricing out spam while keeping the ham affordable

<c​haserene:matrix.org> "~5.5kb" (monero-project/research-lab #100#issuecomment-1609536076)

<j​effro256:monero.social> Tangentially related (and not proposing we do anything now): but does anyone feel that the emissions is currently too low compared to other chains which makes XMR comparably less profitable to mine ? IMO security budget could be higher

<a​rticmine:monero.social> Once I have an estimate on the full membership proofs Tx size I can get to work on the modifications to the scaling algorithm and fees

<a​rticmine:monero.social> So 6000 bytes

<r​ucknium:monero.social> IMHO changing anything about the emission would reduce the purchasing power of the block reward more than keeping it the same. It would reduce confidence

<a​rticmine:monero.social> I will review the GitHub link

<c​haserene:matrix.org> I have thought about it, but I'm vastly deterred from touching a monetary policy we have good consensus on

<j​effro256:monero.social> Yes I'm of the same opinion. Wish it was higher from the get go

<a​rticmine:monero.social> This is very workable with the additional flexibility on increasing the minimum node relay fee

<j​effro256:monero.social> Doing it now is a bad look

<d​angerousfreedom:matrix.org> If we consider the spammer with unlimited resources then increasing the ring size wont stop him, neither limiting the block size nor letting the fees go up (like btc). I also cant see what could be done. Maybe a solution that encopasses all of that (increased ring size, smaller blocks, higher fees). The question would be then, what users want the most? Privacy, low fees, constant <clipped me

<d​angerousfreedom:matrix.org> blocksizes... I personally think that Monero has a pretty damn good privacy already. I wouldnt care about smaller blocks and higher fees. I actually think it is a greater selling point to know what will be the maximum blockchain size in 5 years from now then saying that the fees will remain this low (in XMR terms) in five years. I think money should be scarce (not only in the supp<clipped me

<d​angerousfreedom:matrix.org> ly but also in the resources required to operate it) as well as acceptable. So it is a personal trade-off. But anyway, at this point, I dont think any changes are necessary, if things get bad in the future, I'm of the opinion that we should reduce the block size so txs with higher fees have higher priorities and the spammer would need to pay more and therefore benefit the miners.

<a​rticmine:monero.social> No company has an unlimited budget. Also a flood XMR could likely be illegal and at best a public nightmare

<j​effro256:monero.social> Increasing ring size makes it exponentially harder to get a deterministic hit FWIW

<c​haserene:matrix.org> an attacker doesn't care about legality, it actually may be approved by a government

<d​angerousfreedom:matrix.org> In the current money printing system everything is legal and unlimited

<r​ucknium:monero.social> I think we can end the meeting. We'll keep monitoring. Read you next week.

hopefully next week we will have more information how the spam evolved

<c​haserene:matrix.org> this reminds me of Artic bringing up Nielsen's Law (en.wikipedia.org/wiki/Jakob_Nielsen…usability_consultant)#Nielsen's_law) in his recent interview. would it make sense to define constraints in the (dynamic) block size according to it, or something like it? this could be one way to gain predictability without sticking to static parameters.

<a​js_:matrix.org> MoneroKon CFP deadline is this Friday… if you would like to do a talk or host a workshop, submit proposal here: apply.monerokon.org

<a​rticmine:monero.social> My take is a reference tx size of 6000 bytes. This will allow for a 2.5x increase in ring size. When combined with a 4x increase in the minimum node relay fee we are looking at a 10x increase in the cost of a potential spam attack while only having a 4x increase in the cost of ham

<a​rticmine:monero.social> We can also implement the ideas of capping the growth to Nielsen's Law l proposed in the last MoneroKon

<a​rticmine:monero.social> This can be implemented as an interim solution until full membership proofs are available.

<a​rticmine:monero.social> The beauty here is that when full membership proofs are available it will be seamless from a scaling point of vie

<a​rticmine:monero.social> View

<c​haserene:matrix.org> as an aside, even without FCMP, we're looking at 2500-3000 byte Seraphis transactions (depending on variant), assuming ring size = 128

<a​rticmine:monero.social> The use of graphics processors for parallel processing of verification is required here particularly for devices such as the Monero Nodo that has a powerful and idle graphics processor

<a​rticmine:monero.social> This can be accommodated with the current reference tx size of 3000 bytes.

<a​rticmine:monero.social> So if it is available it is an option

<a​rticmine:monero.social> I am proposing doubling the reference tx size to 6000 bytes

<a​rticmine:monero.social> So ring 40 under the current proofs, ring 512 under Seraphis without FCMP

<c​haserene:matrix.org> if an attacker establishes a communication channel with a miner/miners who use modified node software, can't they lower the cost imposed on them by the minimum relay fee?

<a​rticmine:monero.social> Yes

<c​haserene:matrix.org> I prefer to treat miners as rationally selfish actors who instasell every spendable reward they earned

<a​rticmine:monero.social> This is the danger with going too high on the minimum node relay fee

without Seraphis we also don't have privacy perserving light wallets for mobile. that means too large ring sizes can make monero unusably slow on mobile phones.

<c​haserene:matrix.org> are you suggesting that with a "moderate" minimum relay fee bump, like 4x, it's less likely that such channels are established?

<a​rticmine:monero.social> Which is why graphics processor verification is important. Mobile phones have powerful graphics processors

<j​effro256:monero.social> IIRC wallets don't download or validate proofs so ring size doesnt affect them

we also don't have GPU verification code, most of the nodes run on systems that don't have a GPU, writing portable GPU code between different vendors is difficult, so I don't think that is anything we should take into account in the short term

<a​rticmine:monero.social> Yes. If it is just over the threshold

also isn't there a risk of a network split when using GPU verification due to implementation differences between different GPU vendors? that was one of the reasons why we never implemented ASM optimizations on the node side for block verification

<a​rticmine:monero.social> The exception is servers. One can write for multi core / thread CPUs at the same time. All consumer and small business devices have GPUs

<a​rticmine:monero.social> Also if one sets up a server at home or in a small business it is trivial to add aGPU

<a​rticmine:monero.social> There are cross device platforms for coding this

<a​rticmine:monero.social> GPU verification is inevitable

<a​rticmine:monero.social> Your mobile phone has a very powerful GPU. It just does not have whirling fans

GPU verification on the wallet side doesn't cause chain splits

<m​onerobull:matrix.org> does this have anything to do with matrix calculations?

sech1: I think he means on the node side

<m​onerobull:matrix.org> (matrix calculations are used for machine learning and will presumably get asics with insane performance gains in the near future)

<a​rticmine:monero.social> It is basically massive parallel processing

On the node side, CPU can double check all rejected tx, although it still leaves space for false positives

<a​rticmine:monero.social> That is what GOU are very good at

<a​rticmine:monero.social> GPYs

<a​rticmine:monero.social> GPUs

<c​haserene:matrix.org> I'm sure we'll continue monitoring it and discuss developments as they happen

<a​rticmine:monero.social> Yes we need to monitor the suspected spam. We also should reach out to the community to determine what if any impact has the Binance delisting had on transaction rates on chain via DECs instant exchanges peer to peer trading etc

<c​haserene:matrix.org> I agree that's an interesting data point. however, saying that CEX trading transactions (where parties didn't withdraw to a wallet after each trade) are now happening on DEXs and instant exchanges in a meaningful scale sounds unrealistic. the inherent fees and the settlement times are so high in comparison that they price a lot of that action out, and these people weren't interest<clipped message>

<c​haserene:matrix.org> ed in self-custody to begin with.