00:01:30 If we assume this is a spam attack, is a fair estimate for the maximum ongoing daily cost: 00:01:31 $145 x (0.1 XMR/block fees) x (60 mins) * (24 hrs) / (2 mins/block) = $10,000 00:15:57 not sure about that math, I figure 80k transactions at half a cent each is 400 USD 00:36:57 Yea, 400usd 00:38:11 Sweep singles are very likely churns, i expect to see a flood of consolidations > splits > churns once the outputs are dust 00:38:54 Though, if same person as 1/16 spam, who knows what took them so long to start using the oyt 00:38:59 outputs* 00:47:13 I doubt. the Zcash attack cost literally $15/day until they introduced resource pricing, and it wasn't useful for reducing user privacy, only DoSing a chain that was already, well, heavily underutilized. it could have been pulled off by anyone with minimal expenditure, like a prank (there was actually name-calling encoded into unspendable T-addresses). the current flood in Monero 00:47:13 comes conveniently after the price drop amid the Binance delisting, which could have also been a good time for buying XMR cheaply to spend in a later attack. I suspect a more serious entity/intention here. 00:48:12 has this hypothesis been explored? - an attack like this may essentially lower privacy for all participants because eventually one can assume that all txs with a non-lowest fee is a real user and not the attacker. I gotta go re-read the flood MRL paper from... way back. 00:55:30 would need binning on fees essentially 01:09:02 sorry if obvious -- what would fee binning look like? 01:14:56 despite it's shortcomings, I see great potential in isthmus's idea of discretized fees (https://gist.github.com/UkoeHB/f508a6ad973fbf85195403057e87449e#transaction-uniformity). I've also been toying with how an EIP-1559 fee structure (https://eips.ethereum.org/EIPS/eip-1559) could be applied to Monero. the economic outcome of this solution is very elegant and resilient, but the im 01:14:56 plementation (especially as applied to Monero) incurs an awful lot of complexity. 01:20:25 (IIRC that conversation, it may be even impossible, but no one was sure) 02:44:54 "has this hypothesis been explored? - an attack like this may essentially lower privacy for all participants because eventually one can assume that all txs with a non-lowest fee is a real user and not the attacker. I gotta go re-read the flood MRL paper from... way back." < enforce auto relay says ofrnxmr 02:47:09 "comes conveniently after the price drop amid the Binance delisting, which could have also been a good time for buying XMR cheaply to spend in a later attack. I suspect a more serious entity/intention here." << i highly doubt this 02:47:37 Discretized fees are currently implemented in the Seraphis WIP upgrade. 02:47:50 Buyinf xmr involves withdrawing it. Now, unless they are doing 100k withdrawals, how exacly did they obtain so many outputs? 02:48:42 And big withdrawal would have had the funds consolidates on chain in multiple tx, and THEN youd have to split that back up 02:49:01 We have a 10 block lock, so they couldnt have dont it using 1/2 outputs without waiting 20mins between spends 02:49:57 without evidence of the contrary, i think they _must_ have already owned at least 5000 outputs 02:50:46 s/evidence/a theory that explains how one would accumulate such firepower 03:22:52 split a big output in two, then split those in two, then split those in two... 03:25:13 you get 4k outputs in 12 generations this way so like.... 4 hours? 03:38:50 assuming that the blockchain during the spam has only 1-in/2-out transactions, and 20k/day organic transactions, to start filling up 300 kB blocks, a spammer needs to have ~1723 enotes ready. if you assume they started with a single enote, they can get to >1723 enotes in 3 rounds of splitting every available enote via 16-out transactions, which imposes only 1h 20m waiting time on 03:38:50 them. which is nothing. from there on, they can get even more if their 2-outs generate 2 real outs (not sweep_single). 03:41:06 ^^ 03:51:48 where is this UI from? I found https://xmr-tw.org/xmr-eta/ as one way visualize the mempool/blocksize/etc, but it's not flexible, is in Chinese, and some charts don't work (and yet it still has some interesting data). 04:19:36 https://github.com/lalanza808/docker-monero-node 04:19:59 Note that the map part seam to be broken 09:57:43 Assuming this is a flood attack, it is too affordable for the entity to carry-out. At the estimate of $400/day, we can think of that being the cost to reveal the transaction graph. It would be costlier if the automatic fee estimation was working properly, but probably even then not costly enough to deter a bad actor. While mining is still near as unprofitable as it has ever been, I don't know if burning fees via a EIP-1559 is the best idea. 09:59:01 It's $700/day right now, with current price and block size 10:00:31 if we assume this costs nodes 20$ in storage per year and we have 18k nodes 10:01:06 thats 360k damage vs 255k cost 10:02:08 now, i dont want to know how much fees companies in the ecosystem are loosing out on 10:02:27 but this would be fixed if auto fee worked 10:03:16 For a long long time I've had the opinion that fees on Monero are TOO cheap. If privacy is the main goal, and we sell the ability to view the transaction graph at $700/day, then cheap fees are counter to our goal. 10:03:29 Interested to see what the cost would be if automatic fees were working. 10:03:40 yeah 10:04:02 imo fees should be max 5 cents though 10:04:18 i already get really annoyed when my bank charges 10 cents per tx 10:07:12 they're too cheap only at the current price level 10:07:22 in terms of Monero coins, they're not cheap 10:07:46 p2pool miners feel it already when they consolidate their funds. They spend up to 5% on fees 10:09:12 Or, another angle: a block full of the lowest fee transactions adds 1% to the block reward. 0.6 -> 0.606 XMR 10:09:42 the next tier of fees is 0.6 -> 0.63 XMR, and so on 10:12:46 The current price level will continue to drop if the transaction graph can be bought for $700/day tho, because ring sigs are essentially defeated, miners are unprofitable, hashrate drops, chain is less secure and less private. So we didn't compromise, and for that monero get delisted from exchanges, and what was it all for? Fee levels as we have currently only make sense once we have FCMPs. 10:14:27 my 2 piconero 10:18:33 To be fair, the tx spam levels we're seeing is not enough to get anything even close to a full transaction graph. 10:19:36 Yes true, I was exaggerating a bit admittedly. 10:20:36 Also, as a "fun" countermeasure, you can spam the network with your own txs and thereby dilute the effect of the attacker, assuming that the attacker is doing this to unmask outputs and not to DoS or other reasons that aren't related to privacy. 10:21:50 Been doing this actually. Must have sent 20ish transactions yesterday. Its just a drop in the bucket, but im doing my part 🤣 10:22:40 there are always 2-3 decoys which are old, like weeks to years old 10:22:55 so they need to keep spamming for a long time to get any results 10:23:07 and the moment the second spammer appears, it's all futile 10:24:01 thats good, wasn't aware of that. 10:32:00 The pace seems to be increasing daily though. 90k tx first day, then 96k, yesterday 120k, and for past 24 hours count is at 142k currently. 11:33:01 we ruled out incognito market closing shop right? 11:36:34 Unlikely 11:36:51 If you empty a wallet, you do sweep_all and then a bunch of 146 input transactions is created 11:36:59 here we have a flood of 1 input transactions 11:59:40 assuming the users create account, deposit, buy, never touch the account again 12:00:10 would this still be that unlikely? 12:00:27 imagine you have 400k wallets like this 12:00:57 Those would be subaddresses 12:01:01 they can all be swept together 12:01:22 depends on if incognito used subaddresses 12:02:50 even if it were separate wallets, the flood is approaching 0.5 million transactions now 12:02:59 I don't think they had that many users 12:03:31 > Now that you have an address send the funds to the XMR address. 12:03:31 > 12:03:32 > After sending the funds to the XMR address and the transaction has obtained one onchain confirmation, click the "rescan" button on the deposit page in order for our system to scan for new transactions on that address. Note that expiry no longer exists on XMR deposits, so rest assured the transactions get credited even if you do the rescan outside of the time limit. 12:03:34 from their faq 12:04:06 you wouldnt have to manually request scanning for subaddresses 12:05:40 it depends on how long theyve been operating 12:06:07 if it suddenly stops at some point, i would assume this was actually it 12:07:19 the outcome of that can easily be that at least two "white hat spammers" join the effort who don't coordinate. the original spammer could have already ran out of money and it could be just white hats unknowingly fighting against each other in the fog of war. much like the TheDAO wallet drain in 2016, only here isn't a bottom to it, we just keep having bigger blocks (and we can onl 12:07:19 y hope the white hats will destroy the wallets they did the spam with, because if there were few enough participants, that data can be used for mass effective ring size reduction). so I don't recommend this. 12:11:07 white hats will also run out of money, it will stop naturally 12:17:51 not if your average ccs-funding-whale decides they want to help out the network 12:19:24 If it's just 1 white hat, they'll eventually see that they control 90% of outputs :D 12:20:20 "are we the baddies?" 12:24:10 true, there is a bound to it. but that bound is very unknowable. depending on the number and resources of white hats, this can drag out for a very long time (multiples of what the black hat had resources for), requiring massive capital expenditure from benevolent players (->opportunity cost), chain bloat, and, well, "toxic waste". I want to make the costs of this solution clear, a 12:24:11 nd it's not obvious to me it's worth it. I'd first get the fee auto switch patch out ASAP and see what that does. 12:28:03 as I can remember, white house market had close to 400k users before it shutdown. I dont think incognito published their stats though. 12:33:59 " p2pool miners feel it already when they consolidate their funds" ... that's because consilidation trasnactions are dummy inefficient which I would also support fixing 12:34:23 yes, spending coinbase outputs should be made more efficient 12:37:47 It's a good point though that if XMR were $1500 we'd have nickel fees already, and if we had nickel fees now we'd have 50 cent fees then :/ 12:53:49 can we simulate the on-going costs of the spam once the auto fee switch is patched? 12:56:04 the costs for the attacker will not change 12:56:23 they can just flood the mempool with low fee transactions to make sure it stays full 12:58:34 is there a way to limit mempool size on the node? seems like no 13:00:06 but in that case, less of the spam tx's will be mined, because benevolent users will use higher fees and push the low-fee spam out, no? 13:00:21 i believe its capped at 600 mb 13:00:36 not sure what happens then 13:01:18 648 mb is the cap 13:01:23 you can reduce it in the command line 13:01:37 --max-txpool-weight arg (=648000000) Set maximum txpool weight in bytes. 13:01:56 what happens afterwards 13:02:02 once the limit is reached 13:02:04 when it hits the cap, oldest transactions get removed 13:02:21 oldest = lowest fee because they didn't get mined for a long time 13:02:25 ok thanks 13:02:44 but it only matters if big mining pools do this 13:03:19 do transactions time out by themself if they dont get mined for a specific amount of time? 13:03:27 or can they chill in mempool forever? 13:03:36 IIRC default timeout is 3 days 13:03:51 👍️ 13:04:27 #define CRYPTONOTE_MEMPOOL_TX_LIVETIME (86400*3) //seconds, three days 13:05:07 and 648 mb limit corresponds to 3 days worth of full blocks 13:05:23 300k*720*3 = 648m 13:09:53 whew, imagining public noeds crying and dying with a 600 MB mempool and wallets constantly requesting it all. good stuff 13:10:30 could we use view tags to have wallets only request relevant transactions 13:10:42 in mempool, or maybe it already does 13:11:40 Well, to play devil's advocate, this way getting more people to run their own nodes would not be necessarily too bad .. 13:12:36 it's true, I just know that's unfortuantely not practical for a bunch of people. I mean, maybe if we had a nice GUI tool for node management, but at the moment you either do it by CLI (very high barrier) or through the GUI (horrible experience that makes it almost impossible to run a 24/7 node) 13:13:17 I guess there's like, Umbral, if you have a whole machine to dedicate to it, but again kind of a high barrier 13:14:49 also I think a lot of people don't want to run an XMR node over clearnet and keep 100% of their activity on tor, and we don't exactly make it easy to run a node fully over tor either. gotta use torsocks 13:15:28 so they end up connecting to whatever onion nodes are avail 14:37:16 "if you assume they started with a single enote, they can get to >1723 enotes in 3 rounds of splitting every available enote via 16-out " << mhm.. via 16 out 14:37:25 Not via 2 out 14:39:05 "It would be costlier if the automatic fee estimation was working properly, " < no, it would cost less 14:39:29 It depends on when you want to start going for transaction flooding 14:40:03 If you want 100% of the fees going to flooding, splitting it into 2 is the most efficient 14:40:04 It would also be the most visible though 14:40:42 with solely 2-outs, the preparation took 4 hours, as Lyza already mentioned. I just calculated the shortest "time-to-market" possible. 14:41:08 "The pace seems to be increasing daily though. 90k tx first day, then 96k, yesterday 120k, and for past 24 hours count is at 142k currently." < attack didnt work bcuz autofee wasnt enablef 14:42:58 "with solely 2-outs, the preparation took 4 hours, as Lyza already mentioned. I just calculated the shortest "time-to-market" possible" < math? 14:43:30 Shorted time to market is what i said, they already did 1/16 spam and already owned outputs 14:45:46 they don't need many outputs to sustain the spam, just enough to overcome the 10 block waiting time. So 20*120*2 = 4800 outputs to sustain 2 tx/s spam 14:47:49 ^ 14:49:17 boring 14:49:23 i want to see monero overtake bitcoin 14:49:23 (roundup(log(2,1723))+1) * 20 minutes 14:49:24 the 1723 isn't a magic number, if you think it's off, I can later write more how I arrived to it 14:49:41 and the maxis cry about how "all the transactions happen on lightning aynways" 14:49:43 150k tx/day is the max without an actual fee bump 14:49:54 Anything more than that its a bigbang 14:50:28 (Unless the spam pays fees, or we all pay fees for them) 14:51:14 (the max today*. Grows very slowly at min fee) 14:55:56 no, it's 10*120*2 = 2400 outputs 14:56:02 10 blocks, 120 seconds per block, 2 tx/s 15:15:15 sech, what math is this for? The 10 blocks 15:15:49 ~1.65 tx/s is max at ~300kb blocks 15:21:19 10 blocks wait time 15:21:39 2 tx/s is to have a leeway for bigger blocks 15:23:17 so the fee mechanism, when it works as intended, offers low fees during high demand, but conversely it also makes an effective ring size-reduction attack economically sustainable. once it will work again as intended, at least the current DoS will be remedied, but not the deanonymization risk. is this correct? 15:39:00 Maybe someone could make the fake out selection weigh outputs from txes with higher fee more ^_^ 15:44:27 hmm 15:44:34 it can work in current situation, but not in general 17:34:43 higher fee transactions were sent urgently and therefore maybe more likely to be re-spent soon? maybe???