00:21:03 Oh great matrix didn't relayed my message 00:21:27 kayabanerve: is FCMP scheme a performance improvements or regressions over CLSAG ? 00:22:46 (and sorry for the future spam, in case matrix decide to relay my old message) 00:28:42 kayabanerve: that sounds at least vaguely plausible, so I look forward to a formal description with all the details. 00:46:43 Notable regression 00:52:25 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 00:53:16 If the estimate is 5 years I change my mind 01:35:51 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. 01:44:34 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? 02:21:07 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 02:21:52 For example, churning guides and tools. This could be quick and easy to deploy, providing some defense against black marbles 02:36:53 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 02:36:53 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. 02:39:27 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 02:39:43 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 02:40:39 And FCMP+RingCT has some unknown scope, while ring bump and churning tools are known quantities 02:42:03 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 02:44:08 The scaling I am working on will accommodate both discussed versions of FCMP. 02:48:58 50ms verification time? how much of an increase would that be compared to current ring size? 02:53:00 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 02:53:00 for minimum scaling. 03:00:41 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 https://github.com/monero-project/research-lab/issues/91 03:02:22 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 03:02:50 This is very doable 04:06:23 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? 06:25:44 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 er such a small attack, 1) is in danger, and if we rush into some FCMP adventure, 2) is in danger. 06:29:02 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. 06:29:47 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". 08:23:56 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 08:56:44 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. 09:17:32 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. 09:18:13 So hardforks with PoW changes require more effort 15:53:58 @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. 15:54:34 Please no panic emergency forks 16:29:29 Maybe opening a github issue summarizing the current proposals be a good idea ? 16:30:13 Lot of the comments here are about discussing things already discussed. It might be good to make a summary for everyone 16:31:30 That could help at *repragmatizing* the discussion 16:41:47 SyntheticBird: chaser already did that: "potential measures against a black marble attack #119" https://github.com/monero-project/research-lab/issues/119 17:22:57 Thanks I should have check it :P 18:49:24 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 18:54:51 safer*, I guess I should say 19:54:59 @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. 20:03:26 > compromise everyone's privacy any time 20:03:35 I guess anything less than "everyone" and "any time" won't do? 20:03:49 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. 20:04:39 also the issue still persists with rings, no matter the size (unless we get 100's/1000's or members) 20:05:02 of* 20:39:28 @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. 20:39:28 @MatrixRufugee The proposed 2.5x ringsize bump is not yet a consensus 20:39:40 @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. 20:39:40 @MatrixRufugee The proposed 2.5x ringsize bump is not yet a consensus 20:44:25 rbrunner7: Fully agree on integrity over experimentation. It's why one of the first steps was immediately calling for GBP proofs. 21:22:28 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. 21:49:20 These are very different issues. 21:49:20 1) FCMP before Seraphis is totally new technology 21:49:21 2) A ring size increase is all about existing technology. What many people ignore is that technology does not stand still. 21:49:21 For example Nielsen's Law of Bandwidth has bandwidth growing at the rate of 50% a year. 21:54:38 the best way to prevent spam would be to raise the node relay fee 21:55:03 but then again, the user should have low fees 21:55:11 its a catch 22 21:55:57 i do have an argument wich is rather a question 21:56:26 Ring size 11 was introduced in 2018. That is like ring size 125 in 2024 21:56:44 21 million btc makes as much sense as "full" chain membership proofs 21:57:41 because, say an alien lands on monerotopia 21:58:02 where the chain has been running for millenia 21:58:32 no one keeps track of the genesis block anymore 21:59:15 but there is the myth of the largest chain over the montain next to the easter bunny 21:59:42 my point is 21:59:49 I disagree. Only raising the node relay fee can lead to the spammer cooperating with miners to bypass the nodes 22:00:05 how would that departure from the genesis block 22:00:09 look like 22:00:26 or is it an illusion of mine? 22:01:08 as demonstrated by the issues the nodes had with the increase in txs there is more than bandwidth to consider 22:03:12 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 22:03:36 Verification time can be addressed by parallel processing. Take a 16 core / 32 thread CPU that is like a 32x improvement right there. 22:06:31 can fcmp be done over a time window instead of the entire chain? 22:10:49 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. 22:11:00 I guess my point is that many things need improvement to enable a ring size increase that will work without issue 22:11:06 certainly doable 22:12:22 and its an indirect way to force the attacker to pay moar fees 22:12:25 :) 22:15:57 I disagree. Only raising the node relay fee can lead to the spammer cooperating with miners to bypass the nodes 22:16:00 ? 22:16:43 what does that mean articmine 22:17:58 My argument is that we can move to the tx size and verification time of 22:17:58 1) Post. Seraphis FCMP tx size. That is ~5500 bytes 22:17:59 2) A pre Seraphis FCMP verification is ~40 ms 22:17:59 That is like a 64 ring size with the current proofs 22:18:37 Then the network is ready for FCMP when it becomes available 22:20:43 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 22:24:07 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 22:25:15 To get the real picture one has to look over longer periods of time. 22:27:10 By the way the biggest bottleneck for Monero scaling is upload bandwidth. 22:27:33 It is not processing or storage 22:29:53 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. 22:30:02 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 22:37:33 i agree on that 22:37:59 and the argument that people will buy more storage because the price of xmr goes up 22:38:01 ... 22:38:07 is a tight rope 22:38:27 for example me i am an honnyist of monero 22:38:56 that does not mean that i have the xmr or the eur to buy storage 22:40:02 *hobbyist 22:40:33 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 22:41:08 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. 22:41:08 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. 22:42:15 That being said there is a major reservoir of untapped processing power if we simply moved to parallel processing 22:42:41 Are you referring to CPU or GPU processing? 22:42:54 and thank you for the additional info 22:43:11 CPU parallel processing and GPU 22:43:33 Not CPU single thread 22:44:23 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" 22:45:12 You mean the GPU in your smartphone? 22:45:29 would that be capable? 22:45:49 Easily 22:46:21 Would that primarily be used during IBD or needed consistently? 22:46:29 The Monero Nodo has a very powerful GPU that is currently basically idle 22:46:55 Sorry for the question spam, but I'm trying to understand :) 22:50:04 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 22:50:33 When it comes to graphics processors 22:51:02 So in other words, GPU utilization wouldn't be necessary to keep the node synced, correct? 22:51:17 only IBD or other large sync gaps 22:52:58 At current transaction rates not even close. 22:54:09 ... But say a laptop that can support 2 4K screens might only be able to support one 22:55:10 Alright, thank you for that explanation. How much work would be needed to get GPU verification implemented and running on mainnet nodes? 22:55:19 (Rough estimate) 22:55:57 That is a very good question that I will leave for others to answer 23:01:37 It comes down to finding one or more programmers to do the work. 23:01:37 Also it only needs to be done for the current and later code. 23:20:00 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. 23:20:28 it would make sense to find a dev that tries to find bottlenecks in the existing code instead of directly jumping to GPU 23:21:49 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 23:22:02 historical block sync is multithreaded but doesn't take well advantage of multiple cores at all. why is that? where is the bottleneck? 23:22:29 if it can't take full advantage of 8 CPU cores there's no point in using a GPU 23:24:32 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 23:45:16 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 23:45:40 `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`