12:02:35 thoughts on incognito extortion and the flood being linked? 12:03:06 incognito could be compromised / always been a honeypot and now flooding + EAE attack is used to de-anon vendors paying the ransom 12:16:37 How do you know it’s incognito flooding ? 12:17:03 Vendors would be paying ransom if they are doxed 12:17:58 Flood is coming from chain analysis company not some dnm 13:16:42 monerobull: why do you think incognito has always been a honeypot? 14:25:27 PSA before today's meeting: it seems Matrix accounts on the matrix.org server still don't receive messages from monero.social accounts. I'd advise people with only a matrix.org account to register a new one on the matrix.monero.social home server (easiest on app.element.io) and use that for now. 14:46:15 Hmm, but people with two Matrix accounts sounds a bit like a recipe for confusion, e.g. if I want to DM them ... 14:47:34 chaser: Thanks. people with matrix.org home servers could also just refresh https://libera.monerologs.net/monero-research-lab a lot during the meeting to see the conversation instead of making a Matrix account on monero.social 14:47:39 Maybe they could come over to the dark side for a while and use IRC directly. Old school, but after an initial shock it doesn't hurt too much ... 14:48:58 ^ Probably someone would need to post that from a matrix.org Matrix account for the intended audience. 14:49:09 Right :) 14:54:42 Is the matrix broken? 14:58:51 Yeah, someone took the green pill. Somehow. 15:01:39 MRL meeting in this room in two hours. 15:05:14 did it taste of apple or pear? 16:17:25 yes, it is a mess. my temporary solution is to use a Matrix client that supports being logged in with multiple accounts (the most feature-rich and cross-platform one seems to be FluffyChat). 16:39:37 to clarify: app.element.io is a way to run a client in the browser, but you can also use your current instance (but then you have to log out) of a Matrix client that supports registering accounts (not all do), or install the same in a different packaging format (on GNU/Linux: your distro's package manager, flatpak, snap, appimage, etc), or install a different one (https://matrix.o 16:39:38 rg/ecosystem/clients/). what matters is to, during registration, set the home server to matrix.monero.social. the trouble of multiple accounts can be helped by using a Matrix client that leds you handle multiple accounts at once. I found FluffyChat to be the most feature-rich such client. 16:46:01 other ways to not miss messages are to refresh frequently the IRC log page (https://libera.monerologs.net/monero-research-lab) or to connect to IRC directly with an IRC client. 16:46:01 (and apologies to every non-matrix.org user for repeating the info from the other side.) 17:01:17 Meeting time! https://github.com/monero-project/meta/issues/981 17:01:29 1) Greetings 17:01:45 Hello 17:02:04 hello 17:04:47 Hello 17:05:09 Hi 17:05:40 2) Updates. What is everyone working on? 17:07:33 me: Working on analyzing the possible spam black marble flood. I have a PDF draft, but it's very rough. I have the draft plots ready to share: https://github.com/Rucknium/misc-research/tree/main/Monero-Black-Marble-Flood/pdf/images 17:07:53 Hiya. Intermittently here, but multitasking 17:08:38 "work" would be an overstatement, but I collected all the measures I can think of that can be effective against a black marble flood: https://github.com/monero-project/research-lab/issues/119 17:09:09 chaser: Thanks a lot :) 17:10:04 Good text, helpful 17:10:54 I worked a little on frontend for lws, but stopped after I discovered woodser was already on it. Otherwise have been working on "remote" scanning for lws. A little more confident that it will be possible without destroying the code, but still a possibility that I punt on the feature 17:12:29 3) Discussion. The large tx volume is still happening. A little lower now, but still filling almost all blocks to the 300 kB minimum limit. 17:13:45 I put some plots here: https://github.com/Rucknium/misc-research/tree/main/Monero-Black-Marble-Flood/pdf/images The most important ones are empirical-effective-ring-size.png, spam-share-outputs.png, and projected-effective-ring-size-non-log.png 17:15:38 If the tx volume is a black marble flood attempt, an effective ring size low enough to allow chain reaction analysis to deterministically figure out the real spend would be the greatest threat. Effective ring size is about 5.5 now. Less than 1% of rings would be drawing black marbles for all 15 decoys. 17:17:49 "projected-effective-ring-size-non-log.png" is a bit depressing, if I understand that correctly: With ringsize 25 the adversary only needs to double blocksize to about 600, and it's again down to 5.5 17:17:53 Doing actual chain reaction simulation would take time. Chervinski et al., (2021) did a chain reaction simulation. Looking at their parameters, I don't think it's a problem now with the suspected spam volume. 17:19:18 Yes. ArticMine suggested raising ring size to 40. 17:19:41 ArticMine should have suggested bumping the min fee 4x :p 17:20:33 bumping fee is not smart. 17:20:48 he did actually, but only the relay fee. I think if fees are modified, it makes sense to do it on the protocol level. 17:20:59 Raising the ringsize with the current technology is relatively costly. Arguably more harmful than bumping the minimum fee imo 17:21:08 Looking at the list from chaser, I don't think we have any immediate "smart" countermeasures 17:21:13 The budget of the suspected adversary is unknown. There was a 24 hour burst of 1in/2out 320 nanonero/byte txs that was either the spammer or a service that paid a lot temporarily to get fast confirmations. The rest of the suspected spam pays fees much lower (20 nanoneros/byte) 17:22:08 a spammer with a truly unlimited budget will always consume 100% of new available block space, making the attach unavoidable. So that's what we're up against 17:22:15 a spammer with a truly unlimited budget will always consume 100% of new available block space, making the attack unavoidable. So that's what we're up against 17:22:18 320 nanoneros/byte is the 3rd tier of fees. The GUI/CLI only increases fees from the 1st to 2nd tier if the txpool is congested. 17:23:38 Can anyone confirm that increasing the ring size would not increase the pruned node storage space very much? 17:26:06 The only way the monero network gets around this is assuming that the attacker doesn't have unlimited resources (since then we have to assume it's a lost cause), and we make it significantly more expensive for them 17:26:30 Don't know enough details about pruning to be sure. But for sure the pruned blockchain growth would also accelerate 17:26:33 no attacker has unlimited budget. we don't know their budget until they stop. the cost requirement is like a fence, what we can do is to raise it in some or multiple ways, which will raise our general defense, and may make an attacker retreat/not raise their volume 17:27:10 I could project the expenditure to achieve some effective ring size. Vary the fee and the nominal ring size. 17:27:19 the cost of raising fees is only passed onto the senders. Higher fees also subsidize mining, making mining attacks more expensive as well, assuming no material change to organic demand 17:28:01 It might be worth trying to guess the realistic amount an attacker would be willing to spend, and trying to model around that. There will always be some implied number there to target 17:28:19 Raising fees could reduce the volume of txs sent by real users. That would increase the adversary's share of outputs, ceteris paribus. 17:28:58 yes, but for them to maintain the same ratio of outputs that we're worried about, the math works in our favor 17:29:04 yay ring signatures :) 17:29:39 for every 1 real tx cost paid by a user, the attacker needs to pay what, 10x that? for a concerning ratio 17:30:09 That's an interesting way to look at it 17:30:23 Raising the ring size is the best deterrence against a black marble attack 17:30:52 Real users and the suspected adversary do not have the same willingness to pay per tx. 17:30:58 Let me put it this way: if making new transactions costs effectively nothing, then even ringsize 100 wouldn't matter, since there's no cost to spam transactions 17:31:33 I'm not saying ringsize is truly irrelevant, it's just that fees matter a lot more 17:32:38 attacker will need to spend exponentially more with higher ringsize ? 17:32:52 IMHO raising the ring size to 40 would be great, given what I know at this point in time. 17:32:58 Of course 17:33:57 Do you mean because of the impact on the output distribution 17:34:02 projected-effective-ring-size-non-log.png tries to accurately project block weight as ring size increases by the way. 17:34:08 Interesting that so far no attempt to drive the effective ringsize lower than about 5, but 5 is still a quite good protection. Is that even useful what they do here, as a black marble attack? 17:35:02 I find this quite a bit puzzling 17:35:12 I'm not going to stand against a ringsize increase. You all should know I've advocated in favor of all the previous ones. But, it would be silly imho to bump the ringsize but do nothing about fees. 17:35:12 Increasing the ringsize has a permanent network cost. Increasing fees has no direct network cost. 17:35:27 let's not rule out that it is organic 17:36:20 ArticMine: I mean because of the estimates that I've done in https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/images/projected-effective-ring-size-non-log.png . If nominal ring size is 40, there would still be a healthy effective ring size if the suspected spammer is filling 300 kB blocks. Actually it would be larger than current nominal ring size (16) 17:36:23 sgp - it has social effect, people want to use the cheapest means of transacting 17:36:58 Monero should not compete to be the cheapest network. Monero won't win that fight :p It needs to be a very private option for a totally reasonable cost 17:37:59 yes but people care more about money than privacy, that's why low fees are more attractive with the added "privacy" bonus 17:38:48 I think it might be interesting to brainstorm a bit more about possible forms of "PoW before submitting a transaction" 17:38:51 it doesn't matter if it's organic or not, because we can't know, and we can't afford to think it's the optimistic scenario. and even if it is organic, this event is an invitation to any adversary in the sidelines to come and attack, especially if they see that there is no pushback. 17:38:55 I prefer raising the ring size as the most robust way to address this. However I would not object to fee adjustments as part of the response 17:39:24 Maybe we can connect the amount of PoW needed with some network parameters / network statistics, so normally it's negligible 17:39:42 Raise ring size and slightly adjust fees. Ez. 17:39:45 For txn pow with existing format could just reroll randomizer until some field is sufficiently low/high :- P 17:39:48 Monero is a privacycoin, not a "cheap transactions with privacy bonuses" coin. 17:40:07 There is a technical statistical point to keep in mind. Mean effective ring size = 5.5 does not mean that random guessing success is 1/5.5. Effective ring size is a random variable since decoys are selected randomly. 1/x is a strictly convex fucntion. By Jensen's inequality, E[1/x] > 1/[E[x]. The current probability of correctly guessing the real spend is about 25%. Check empirica l-guessing-probability.png 17:40:10 Liam Eagen to give talk on Bulletproofs++ at MoneroKon 17:40:21 I strongly suggest you hike the fees a higher multiple than the ringsize increase 17:40:47 If the attacker continues to consume the majority of the block space, then they will pay the majority of the fee increase 17:41:11 I am not opposed to a reasonable increase in fees, too. 17:41:55 maybe that's the point of the attack ? so we increase the fees ? 17:42:20 unfortunately the motivation doesn't really matter 17:42:22 as pointed out, it has no effect on privacy 17:42:39 there is absolutely a privacy risk and rucknium demonstrated 17:42:44 Ariel Gabizon will also give a talk on Circle STARKs https://eprint.iacr.org/2024/278 17:42:45 there is absolutely a privacy risk as rucknium demonstrated 17:43:32 these charts are very good, thank you! 17:43:43 I said in Saturday's #monero-community:monero.social meeting that I am planning to write a statistical research CCS to analyze the black marble flooding and other Monero research tasks. Input is appreciated :) . nioCat suggested that I work with ArticMine to model some scenarios. 17:44:25 If the current amount of spam does not change, it won't get much worse than it already is, right? 17:44:26 And Stefanos Chaliasos on Security Vulnerabilities in SNARKs 17:44:58 I understand that people have an emotional attachment to small fees. However, it really is important to consider the consequences of having a super low cost of spam. A low cost of spam makes enforcing privacy protections significantly more expensive (through a much larger, less efficient required ringsize) 17:45:07 Yeah, still working on OSPEAD in parallel, but the black marble is more urgent since OSPEAD adjustments probably have to happen at a hard fork to be safest. 17:45:36 I disagree. A critical part of privacy is to increase the ham transactions. This means increasing the anonymity set 17:45:54 I don't know if this has already been mentioned but although the effective ring size is ~5 wont these decoys that are left be more likely to be older i.e the ones less likely to be the real spends 17:45:59 I would agree with you ArticMine if we already had FCMP 17:46:06 rbrunner: The effect on privacy is not going to become severe quickly if the current tx volume stays the same. It will get worse gradually 17:46:58 Think of drowning the blockchain Surveillance companies in ETH, which is starting to happen 17:47:53 Yes I agree 17:48:12 drowning in ETH? I don't understand 17:48:35 boog900: Yes, this is true for certain investigation scenarios. It makes out of band information over these periods more valuable, if that makes sense 17:48:54 I don't know if I can explain it simply here 17:49:41 boog900: Yes, but https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/images/projected-effective-ring-size-non-log.png projects what happens if the spam continues for a very long time at current levels. It doesn't get much worse than effective ring size 5.5 when blocks have 300 kB total weight. Effective ring size about 4.5 I think. 17:49:42 unfortunately, all these will be possible only with a fork 17:50:04 FCMP is the goal. My interim solution is to all for a tx size of around at least 5000 - 6000 which is the estimated size for FCMP 17:50:44 So we have the scaling in place for when FCMP come on line 17:50:50 Why 4x the cost of transactions to be stored permanently if we could instead 4x the cost of fees paid by the attacker for the same privacy improvement 17:51:24 Because that improvement is not assured? 17:51:27 not if they have large budget 17:51:30 chaser: Yes, but the hard fork node parameters need to be ready before the wallet parameters need to be ready. Ring size is node. Decoy selection algorithm with OSPEAD is wallet. 17:51:34 They might be ready to pay 4x 17:52:12 I think we need a sanity check. Are there really reasonable use-cases where a Monero transaction *should* cost less than, say, $0.10? What demand does that actually turn away 17:52:21 increasing fees may even decrease privacy as people will use lower than default fees and just wait longer 17:52:43 They have have paid 16x when we saw the 320 nanoneros/byte burst. 17:53:32 A 4x increase in fees below the minimum penalty free blocksize is part of my proposal. So both 17:54:29 There are a lot of people in the world who would not transact at $0.10 per tx 17:54:45 Well, maybe people would even grudgingly put up with USD 1 as a fee. Does not mean that makes sense as a course of action 17:54:46 currently the cost is $0.004 per tx, right? 17:55:01 I agree 17:56:01 a 4x proposal would make the per tx fee $0.016. Which would cost the attacker how much in USD terms per day Rucknium? Apologies if you don't have the # of txs they make handy 17:56:10 We will need 3D images :D 17:56:10 I will do some more projections on fees, ring size, and privacy impact. 17:56:37 ~$2400 17:57:04 I see about 3 XMR per day spent by the suspected spam now. 17:57:21 And that's why "let's rise fees" is such a slippery sloppy: USD 2400 is still almost nothing for certain adversiaral "use cases" 17:57:35 assuming same tx volume as during peak 17:57:40 so about 98k spam tx/day? 17:57:53 .... and combining this with ring 40 we have an additional ~2.5x 17:58:08 and if monero drops 80% in usd price .... or increase to the same as btc 17:58:48 sadly there's always some implicit price assumption in these calculations, and we can't predict the future. Yay hard forks (or at least soft forks) :p 18:00:00 You mean all on chain like BTC or staying decentralized. There is a big difference here when considering fees and spam attacks 18:00:01 a 4x to fees will bring their cost to roughly $46k/mo, which is still low 18:00:08 IMHO, ways to link fees to the purchasing power of XMR should be researched. Does not mean a formal oracle. 18:00:57 The question here is settlement on chain or on a centralized ledger 18:01:14 Nice idea, but raises the complexity of the system yet again. Already now we may have the most complex fee algorithm of them all 18:01:18 For example, fees could be linked to network hashpower. Since aggregate mining revenue is 0.6 XMR per block and hashpower is proportional to revenue (mostly), maybe that could help. 18:01:48 what centralized ledger? monero was already delisted everywhere! /s, kinda 18:01:57 articmine is your proposal documented somewhere, or just in chats thus far? 18:02:30 I am working on putting this together with documentation 18:02:36 The BTC fees are linked to BTC purchasing power by demand and completely inelastic block space supply. It's not a model to follow exactly, but it has a link there. 18:02:46 I agree that we shouldn't be *too* attached to measuring these costs in dollars. markets are fickle. what we can know is that higher attack costs raise the probabilistic security. 18:03:30 You need to be able to mitigate the spam risk by causing actual USD equivalent costs to a potential attacker, that's what it comes down to 18:03:56 yes, I know it's inevitable, as you said 18:05:44 You can link to USD cost if one assumes no settlement on centralized ledgers. Then the equation of exchange predicts a linear relationship between blocksize and price over time assuming a constant velocity 18:06:20 clearly this attack proves there's no given relationship between blocksize and price 18:06:31 M is constant, assuming V is constant the PQ is constant 18:07:28 add captcha before sending tx /s :D 18:07:39 Most of the recent growth in transactions rates have been below the penalty minimum 18:08:13 With no penalty. pricing 18:09:39 how do you all feel about the resource requirement increase that a larger ring size would impose? can Seraphis/Seraphis+FCMP justify pre-introducing these requirements? 18:10:31 imo, no, not really. But it an important consideration if we consider the other costs reasonable for their advantages 18:10:40 Graphics verification is required in my opinion for the current and subsequent proofs 18:10:57 IMHO, node performance should be benchmarked if ring size would increase to 40. It has to pull lots of data from the database when there are a lot more outputs referenced per ring., 18:11:20 We have to take advantage of parallel processing on CPU and GPU 18:12:04 yes but that takes time, resources, testing, etc. bumping the fee does not take effort and comes with no network costs 18:13:00 if the network fee was raised to $0.10, the attacker would be spending $300k per month. Just to give you an idea of how much the fee matters for these mitigations 18:13:28 versus today's $11k 18:13:46 Not necessarily if the ham drops down by a factor of 10 18:14:09 It is a band aid, not address the issue 18:14:57 do you approach it as "delay that bump as much as possible, hopefully hardware and uplink will grow by then"? 18:15:46 chaser: sure, that's part of this. Performance improves over time. Further, FCMP benefits are far greater than a moderate ringsize increases. We get a lot more benefit for the same cost 18:16:34 Uplink is not an issue, and hardware is heavily underutilized with little or no parallel processing 18:17:11 the cake nodes are already having major issues handling rpc connections fwiw. That can be improved, but not in an immediate fashion 18:17:37 Take the Monero Nodo for example. These devices have a very personal graphics processor that literally sits idle 18:18:06 They could not take advantage of parallel processing 18:18:36 no, it's the speed of the monerod locks (and related) that's the issue. The whole blockchain currently needs to be stored in ram 18:18:46 yes, FMCP is the silver bullet, the cost is that we can't have it at least for over a year, probably more 18:18:48 We have to deal with the cause instead of just focusing on the symptoms 18:18:49 Doesn't the RPC performance have little to do with ring size? 18:19:18 the monero blockchain does not reside in RAM 18:19:31 larger transactions will slow down all connections, read/write, etc 18:19:40 Monero needs to be run on SSD 18:19:42 Not HDD 18:19:47 it is an ssd :p 18:19:50 nvme 18:20:11 cake nodes already need ram cache to keep up 18:20:35 monerod locking is the biggest problem there 18:20:43 absolutely 18:21:00 and again, these things can be solved, but not with a snap of our fingers 18:21:11 _unlike the minimum fee_ 18:21:35 Why is it locking 18:21:38 4x will do nothing to a professional adversary 18:21:45 that's how monerod is written 18:22:09 If there was something like a bitcoin electrum server for Monero, maybe you would not have conflicts: https://blog.keys.casa/electrum-server-performance-report-2022/ 18:22:14 because back in the mists of time, when monerod's blockchain was entirely RAM resident, you needed fine-grained locking to be able to use it safely 18:22:40 with LMDB transactions you don't really need that any more, but it's a major rewrite to change the interaction style 18:23:00 So is this a database issue? 18:23:08 no, the database is lock-free. 18:23:15 it is an interface to the database issue 18:23:19 cake is bottlenecked by the lock implementation currently, yes 18:23:30 So Monero needs to be optimized 18:23:37 Monerod 18:23:42 yes 18:23:47 which they can design around, but that will take months of testing or for a completely fresh rewrite 18:24:10 the whole blockchain_db pile of code is fuggly 18:24:54 but it was a shim layer between the memory-only blockchain and the DB-oriented one, so it is heavily compromised in many ways 18:27:52 I agree with articmine that this stuff can be optimized, at that it's good to take advantage of the performance that we have. But, I also think Monero should have much higher fees to discourage attacks like this, and yes, even micropayments 18:28:25 *even micropayments - step back in adoption ? 18:28:44 and how much of increase would be enough ? because i don't believe 4x will do anything to an adversary like this 18:28:47 I will draw some budget lines and indifference curves :D 18:29:11 thanks rucknium, these are always very useful to use in discussions like these 18:29:12 10 cents is still reasonable territory imo. 18:29:36 10 cents - if price stays at course 18:29:59 sgp_: I can't tell if you're serious or not 😁 18:30:11 I will try to figure out a way to compare these things 18:30:13 if we make changes to the fees and suddently price increases 10x which would not be a sci-fi event - it would grow to $1 USD per tx ? 18:30:26 I know you will :) 18:30:56 Fees impact both ham and spam. To put it bluntly a crude tool. Furthermore imposing an artificially high node relay fee can cause miners to accept transactions directly. This can be a privacy and decentralizion nightmare 18:31:02 soft fork or hard fork, just like we're discussing now. Unfortunately, that's the way it'll have to be to protect privacy before FCMP 18:33:04 there must be a better tool to deter spam. like a PoW required before submitting a txn 18:33:07 Also if the ham falls by 10x then we are effectively back at 0.01 USD from a spam cost perspective 18:33:48 yup, and hooray, we would need to adjust again. I don't see another way around it, unless we find some pow thing promising I guess 18:34:19 seems that PoW until FMCP is the way ? 18:34:33 PoW to submit is even worse. For starters it discriminates against most of the developing world 18:34:39 new plan: everyone needs to have an account at the monero kyc blockchain to send transactions 18:34:44