<s​yntheticbird:monero.social> Oh great matrix didn't relayed my message

<s​omeoneelse495495:matrix.org> kayabanerve: is FCMP scheme a performance improvements or regressions over CLSAG ?

<s​omeoneelse495495:matrix.org> (and sorry for the future spam, in case matrix decide to relay my old message)

kayabanerve: that sounds at least vaguely plausible, so I look forward to a formal description with all the details.

<k​ayabanerve:matrix.org> Notable regression

<a​rticmine:monero.social> That depends on the ring size for CLSAG. For example a ring size of 40 or 64 for CLSAG would place tx sizes and verification times a lot closer

<s​gp_:monero.social> If the estimate is 5 years I change my mind

It would be less time without a curve change. A FCMP solution for RingCT is at least a 1.5-year endeavor from this point based on the current landscape. Writing papers and reviewing very advanced cryptography takes time, in addition to the dev effort required.

<b​lurt4949:matrix.org> Probably a stupid question, but does the added time to implement FCMP's with Seraphis largely come from FCMP's themselves, or a (hypothetical) curve change? Or do those contribute about evenly?

<w​izeguyy:tchncs.de> Is community consensus that FCMP is the best immediate action to mitigate black marble attacks? I agree FCMP is desirable long term, but there were other proposals that can be enacted more quickly that may be sufficient to buy us time until a proper Seraphis + FCMP upgrade is ready

<w​izeguyy:tchncs.de> For example, churning guides and tools. This could be quick and easy to deploy, providing some defense against black marbles

Is community consensus that FCMP is the best immediate action to mitigate black marble attacks? I agree FCMP is desirable long term, but there were other proposals that can be enacted more quickly that may be sufficient to buy us time until a proper Seraphis + FCMP upgrade is ready <---- While FCMP is optimal to just mitigate but eliminate black marble attacks we can implement a hard fork on scaling and increase the ring size to 40 and

up to 64. This will support the transaction sizes of both pre and post Seraphis FCMP with a verification time of about 50ms. The advantage is when the cryptography is ready for either pre or post Seraphis FCMP there will be no need to make further scaling changes.

At the same time the combination of a 4x fee increase, a ring size of 40 - 64 and reducing the surge of the short term median from 50 to 15 will drastically mitigate if not practically eliminate the risk of a black marble attack

<w​izeguyy:tchncs.de> Yeah, ring bump is another practical quick fix. If we're considering short term solutions as we wait for the long term, these seem like better options than FCMP on RingCT. Given these can be deployed much more quickly

<w​izeguyy:tchncs.de> And FCMP+RingCT has some unknown scope, while ring bump and churning tools are known quantities

The other significant advantage here is that we implement the scaling changes when the ham is still below the penalty which is simple to do from a transitional point of view. In addition it is best for the network to deal with the change at a time of relativly low transaction rates that in the future if there is a significant increase in the ham transaction rates

The scaling I am working on will accommodate both discussed versions of FCMP.

50ms verification time? how much of an increase would that be compared to current ring size?

Correction the short term median surge change is from 50 to 16. This is what I presented at MoneroKon 2023. The one consensus change from what I proposed at MoneroKon 2023 is increasing the minimum penalty from 300000 bytes to 800000 bytes. The fee changes are moving back to linear scaling of fees and increasing the minimum growth rate of the short term median from 1% to 2% The latter will support transaction up to 16000 bytes in size

for minimum scaling.

<selsta> 50ms verification time? how much of an increase would that be compared to current ring size? <--- Actually it is closer to 40 ms for ring 64 vs round 14ms for ring 16 Less for ring Hre are the graphs 40 monero-project/research-lab #91

Also the way to mitigate verification time is parallel processing on multi core CPU of GPU. Using all the trads of a 32 thread processor as opposed to 1 thread will reduce verification time by a factor of 32

This is very doable

<c​haserene:matrix.org> sech1: you have previously said that a fork is at best 6 months after binaries are ready. to what extent can this be shortened, and what would be the the trade-offs?

<r​brunner7:monero.social> Alex | LocalMonero | AgoraDesk: "wouldn't you agree that privacy is the highest priority for Monero?" I indeed do not agree. At least 2 things are more important, because without them you won't have any more coin, whether private or not: 1) We have to stay viable as a project team, 2) we have to keep the software in a working state and without serious bugs. If we lose our cool aft<clipped messag

<r​brunner7:monero.social> er such a small attack, 1) is in danger, and if we rush into some FCMP adventure, 2) is in danger.

<r​brunner7:monero.social> As my personal exercise in strenghtening my self-discipline and self-control, I will try to refrain from any more such discussion contributions. Personally I expect that we will next see something like the "huge container ship versus bridge, with container ship winning of course and bridge collapsing just like that", alluding to the event at Baltimore.

<r​brunner7:monero.social> The "bridge" is kayabanerve's proposal of putting FCMPs into current, pre-Seraphis Monero with reasonable effort in a reasonable timeframe, and the container ship is the pesky thing called "reality".

chaserene I was talking about 6 months from binaries to the fork in the context of changing PoW algorithm where all miners need to update their software

<c​haserene:matrix.org> sech1: by "PoW algorithm" you meant consensus rules, right? no one brought up changing RandomX in the context of black marble attacks, but almost every countermeasure we've talked about does require miners to upgrade. such a fork was the context for my initial question.

PoW algorithm is part of consensus. Every hardfork requires everyone to update their Monero nodes, but only PoW changes require all miners (even miners who don't run nodes) to update as well.

So hardforks with PoW changes require more effort

<j​ack_ma_blabla:matrix.org> @sech1 Can we initiate an emergency 3-month fork to increase ringsize and fees, followed by a 6-month fork for proof of work (PoW)? The PoW code would be included in the 3-month fork but wouldn't activate until the 6-month fork date.

Please no panic emergency forks

<s​yntheticbird:monero.social> Maybe opening a github issue summarizing the current proposals be a good idea ?

<s​yntheticbird:monero.social> Lot of the comments here are about discussing things already discussed. It might be good to make a summary for everyone

<s​yntheticbird:monero.social> That could help at *repragmatizing* the discussion

<r​ucknium:monero.social> SyntheticBird: chaser already did that: "potential measures against a black marble attack #119" monero-project/research-lab #119

<s​yntheticbird:monero.social> Thanks I should have check it :P

rushed/emergency protocol changes are *exactly* what an attacker would want us to do. It's a great way to introduce bugs, break existing software, cripple our (already sketchy) scalability, and set back safe long-term investments like seraphis

safer*, I guess I should say

<j​ack_ma_blabla:matrix.org> @MatrixRufugee Increasing ringsize and adjusting fees doesn't require breakthrough technology; it involves modifying existing code with just a few parameter changes, which can be done after reaching a consensus. Waiting for fcmp/seraphis, which hasn't even been audited on paper, is like inviting attackers to exploit vulnerabilities and compromise everyone's privacy any time.

<r​brunner7:monero.social> > compromise everyone's privacy any time

<r​brunner7:monero.social> I guess anything less than "everyone" and "any time" won't do?

I was more referring to the idea to rush FCMP pre-seraphis, but the point still stands for a large ringsize bump. A more moderate increase is one thing, but making rings 2.5x as large is another. A fee bump is likely justified.

also the issue still persists with rings, no matter the size (unless we get 100's/1000's or members)

of*

<j​ack_ma_blabla:matrix.org> @brunner7 As we are using many recent decoys, the effective ringsize can be reduced by an attacker simply by spamming for a few days or weeks, affecting everyone's transactions conducted during this period.

<j​ack_ma_blabla:matrix.org> @MatrixRufugee The proposed 2.5x ringsize bump is not yet a consensus

<j​ack_ma_blabla:matrix.org> @brunner7 As we are using many recent decoys, the effective ringsize can be reduced by an attacker simply by spamming for a few days or weeks, affecting everyone's transactions conducted during this period.

<j​ack_ma_blabla:matrix.org> @MatrixRufugee The proposed 2.5x ringsize bump is not yet a consensus

<k​ayabanerve:matrix.org> rbrunner7: Fully agree on integrity over experimentation. It's why one of the first steps was immediately calling for GBP proofs.

<c​haserene:matrix.org> sech1: "only PoW changes require all miners (even miners who don't run nodes) to update as well." thanks, I wrongly assumed mining requires a node. so, absent a PoW algo or address scheme change (miners need to be able to be paid), could the timeline be shorter? to be clear, I too am against a rushed fork. no protocol change should happen without in-depth consideration.

<a​rticmine:monero.social> These are very different issues.

<a​rticmine:monero.social> 1) FCMP before Seraphis is totally new technology

<a​rticmine:monero.social> 2) A ring size increase is all about existing technology. What many people ignore is that technology does not stand still.

<a​rticmine:monero.social> For example Nielsen's Law of Bandwidth has bandwidth growing at the rate of 50% a year.

the best way to prevent spam would be to raise the node relay fee

but then again, the user should have low fees

its a catch 22

i do have an argument wich is rather a question

<a​rticmine:monero.social> Ring size 11 was introduced in 2018. That is like ring size 125 in 2024

21 million btc makes as much sense as "full" chain membership proofs

because, say an alien lands on monerotopia

where the chain has been running for millenia

no one keeps track of the genesis block anymore

but there is the myth of the largest chain over the montain next to the easter bunny

my point is

<a​rticmine:monero.social> I disagree. Only raising the node relay fee can lead to the spammer cooperating with miners to bypass the nodes

how would that departure from the genesis block

look like

or is it an illusion of mine?

as demonstrated by the issues the nodes had with the increase in txs there is more than bandwidth to consider

ArticMine has technology really been progressing that quickly in recent years, though? It seems to me that storage and memory prices in particular (maybe CPU and bandwidth as well, haven't really been looking at them) haven't decreased nearly as much as they "should have" since 2019

<a​rticmine:monero.social> Verification time can be addressed by parallel processing. Take a 16 core / 32 thread CPU that is like a 32x improvement right there.

can fcmp be done over a time window instead of the entire chain?

a take away I got from discussion here and elsewhere there are also inefficiencies with networking that need to be addressed. Some work towards that has been done.

I guess my point is that many things need improvement to enable a ring size increase that will work without issue

certainly doable

and its an indirect way to force the attacker to pay moar fees

:)

I disagree. Only raising the node relay fee can lead to the spammer cooperating with miners to bypass the nodes

?

what does that mean articmine

<a​rticmine:monero.social> My argument is that we can move to the tx size and verification time of

<a​rticmine:monero.social> 1) Post. Seraphis FCMP tx size. That is ~5500 bytes

<a​rticmine:monero.social> 2) A pre Seraphis FCMP verification is ~40 ms

<a​rticmine:monero.social> That is like a 64 ring size with the current proofs

<a​rticmine:monero.social> Then the network is ready for FCMP when it becomes available

<a​rticmine:monero.social> It is also better to take the hit now when tx rates are low than waiting for FCMP when tx rates could be a lot higher

<a​rticmine:monero.social> Here is an example: When I moved to North Vancouver in 2018 the best the phone company could do for me over ADSL was like 4 Mbps upload bandwidth. Now it is 3Gbps over fiber

<a​rticmine:monero.social> To get the real picture one has to look over longer periods of time.

<a​rticmine:monero.social> By the way the biggest bottleneck for Monero scaling is upload bandwidth.

<a​rticmine:monero.social> It is not processing or storage

If we're talking at scale, maybe. But we're nowhere near the endgame of big blocks, the network is still run by hobbyists and will be for the foreseeable future.

and regardless, what are your thoughts on storage and CPU progression? Storage doesn't seem to be improving nearly as close to Moore's law or Nielsen's law as we would like

i agree on that

and the argument that people will buy more storage because the price of xmr goes up

...

is a tight rope

for example me i am an honnyist of monero

that does not mean that i have the xmr or the eur to buy storage

*hobbyist

The analysis definitely works on a scale closer to PayPal IMO, but we're multiple orders of magnitude away from that. I'm not to worried about typical consumer hardware at that point, but right now? That's the entire backbone of the network

<a​rticmine:monero.social> Storage has followed over time ~50 a year increase at constant price. That being said I expect a major surge in storage capacity at constant price once the technology fully changes to solid state.

<a​rticmine:monero.social> As for CPU the growth for parallel processing has been more like 60% per year. Similar for GPU. Where the growth has not occurred is in single thread processing.

<a​rticmine:monero.social> That being said there is a major reservoir of untapped processing power if we simply moved to parallel processing

Are you referring to CPU or GPU processing?

and thank you for the additional info

<a​rticmine:monero.social> CPU parallel processing and GPU

<a​rticmine:monero.social> Not CPU single thread

utilizing threads on CPU makes sense, but IMO if we rely on GPUs then we're basically saying "you need a decent GPU to node a Monero node"

<a​rticmine:monero.social> You mean the GPU in your smartphone?

would that be capable?

<a​rticmine:monero.social> Easily

Would that primarily be used during IBD or needed consistently?

<a​rticmine:monero.social> The Monero Nodo has a very powerful GPU that is currently basically idle

Sorry for the question spam, but I'm trying to understand :)

<a​rticmine:monero.social> The biggest verification demand is during the initial synchronization. It is also needed to keep up with the network. Seriously we are dealing with a very large untapped resources here

<a​rticmine:monero.social> When it comes to graphics processors

So in other words, GPU utilization wouldn't be necessary to keep the node synced, correct?

only IBD or other large sync gaps

<a​rticmine:monero.social> At current transaction rates not even close.

<a​rticmine:monero.social> ... But say a laptop that can support 2 4K screens might only be able to support one

Alright, thank you for that explanation. How much work would be needed to get GPU verification implemented and running on mainnet nodes?

(Rough estimate)

<a​rticmine:monero.social> That is a very good question that I will leave for others to answer

<a​rticmine:monero.social> It comes down to finding one or more programmers to do the work.

<a​rticmine:monero.social> Also it only needs to be done for the current and later code.

<s​yntheticbird:monero.social> I would like to remember that while GPU is an unused processing power. VPS don't provide any PCI passthrough or CL-compatible gpu multiplexing. We really can't rely on that type hardware since they represent imo a minor portion of the network. Moreover, rare are the platform that natively support OpenCL or provide Mesa installed on it.

it would make sense to find a dev that tries to find bottlenecks in the existing code instead of directly jumping to GPU

<s​yntheticbird:monero.social> Yes. This is indeed what must be done. Cuprate ( boog900 will correct me if i'm wrong ) parallelize this work. It would be time for monerod to do the same

historical block sync is multithreaded but doesn't take well advantage of multiple cores at all. why is that? where is the bottleneck?

if it can't take full advantage of 8 CPU cores there's no point in using a GPU

<s​yntheticbird:monero.social> According to ArticMine, the RingCT calculation could be parallelize. That imply that monerod is single-threading this RingCT math. Tho I've no idea what they is exactly referring to. It might worth checking monerod src

that's why I meant it would be best to find someone that scans the existing codebase for bottlenecks and try to take full advantage of all CPU cores before jumping to GPU

`src/ringct/rctSigs.cpp` does use threadpools in multiple places but it's possible that i can be further optimized, same for `src/cryptonote_core/blockchain.cpp`