01:13:44 My scaling proposal that I am working on is designed to accommodate FCMP. It can also accommodate a ring size of 40 with the existing proofs The transaction size is roughly the same, around 5500. If we implement this with a ring 40 then there would be no need to change the scaling or fees for FCNP 01:14:02 5500 bytes 01:14:19 FCMP 01:59:02 Especially when the spam is 1/2 (optimal for a bloat attack) instead of 1/16 (optimal for a denanonymization attack) <<>> I don't recall this point being made before. 01:59:40 Enlightening 02:15:53 1/2 is optimal to avoid clustering. The spammer simply makes a transfer to another address and the empty extra output is created by the network. So there is no need to reassemble the output s 02:22:17 It is also optimal for churning 02:45:30 The attacker would create 15 no-value throwaway outputs to fill 1/16's, instead of just 1 to fill 1/2's. 02:45:40 Unless I'm just not understanding what you mean 02:48:20 Back to the 40-ringsize thing though, I understand (but disagree with) the reasoning for picking 40. Like I said, there ought to be a very good reason to increase stress on nodes by that much, and this does not seem to justify it 02:48:59 Also, is the matrix bridge being weird for anyone else? Or just me? 08:22:36 Yeah, matrix is having some issues syncing messages between homeservers 08:46:49 As far as I know suspicion is that right now Matrix.org is not in the mood to receive any messages from Monero.social. It seems that people with other homeservers than Matrix.org do receive such messages. All pretty strange. 11:23:23 so now we'll all move to i2p-irc? :) 18:49:27 If the attacker is targeting below the penalty free zone you do have a point in that 1/16 is more efficient, a little above 20%. There is a weight penalty added to more than 2 output transactions before applying the fee. In this case the where the miner has to pay the penalty, large weight transactions easily could not be included if they pay only the minimum fee 18:51:57 An attack based upon transactions whose weight is larger than 3000 bytes will fail once the penalty is encountered unless they pay a fee significantly higher than the minimum node relay fee 18:53:50 The reason is the transaction weight is greater than the rate of scaling the minimum node relay fee can support 18:55:15 So far even for a black marble / flood XMR attack 1/2 is optimal 18:55:22 Transaction can enter the penalty zone only partially 18:55:46 if block size is 296 Kb and tx size is 5 Kb for example 18:56:52 Yes I know there are ege cases, but what was suggested here was an attack based up 1/16 transactions 18:56:58 Edge 18:57:32 1/16 is more efficient in terms of outputs per byte of a block 18:57:35 This cannot work at minimum fee 18:58:41 I know but how do you get the miners to scale at minimum fee with just 1/16 transactions 18:59:01 The weight is just too high 18:59:26 There are always other transactions from regular users, 1/2 and 2/2 and some other types 19:00:01 Attacker doesn't need to scale, all they need is to get 80% or more outputs in each mined block 19:00:09 Yes but then the miner prioritizes the more nimble ham 19:01:15 It only works below the penalty 19:01:51 ... and possibly at the edge 19:02:53 Smart attacker can always submit a few higher fee transactions for each block to push the limit 19:03:35 Sure. What is the weight of 1/16 tx? 19:03:59 Then divide by 3000 19:04:24 ... 19:04:25 and square the result 19:05:06 For example this tx is smallers than 3000 bytes https://p2pool.io/explorer/tx/3375404880f09308e04495cdcfbd7040d9f2038ece818ee800c2f6bd1ab2cdc4 19:05:14 But I think the weight is higher? Explorer doesn't show it 19:05:21 That is how much greater a fee is required. 19:05:22 Way more than the 20% or so saving 19:05:36 Look at the fee 19:06:53 It is a clawback of 80% of the savings in size reduction. The weight penalty 19:07:21 Most explorers don't show it 19:09:09 It was put in place to account for verification time 19:16:13 On another note I am also taking a hard look at what is a reasonable growth rate for the short term median to accommodate a holiday surge in retail transactions. VISA has a ~20x surge capability to deal with this. 19:25:53 This could justify a higher minimum node relay fee 19:37:34 If we take (see below) 1 as an example of a 1/16 tx, and 2 as an example of a 1/2 tx, the 1/16 method is over 4.4x as efficient per byte compared to 1/2. The attacker wouldn't need to push past 300kb with 1/16's, since that would be the equivalent of >1.3mb blocks full of 1/2 spam, more than enough to dominate the decoy set. But that's not what they're doing, probably because that 's a lot less efficient for bloating. 19:37:35 1) https://xmrchain.net/tx/3375404880f09308e04495cdcfbd7040d9f2038ece818ee800c2f6bd1ab2cdc4 19:37:39 2) https://xmrchain.net/tx/d111971b7d5b7389766e6d9f1828a0aafabbbc18667494196440a111ffa3dffd 21:42:37 Yes I understand. But the fee paid by the spammer is based upon the weight not the size of the transaction. So is how it is treated for penalty purposes. Take a look at the fee on xmrchain and ratio that 21:43:15 The fee is not proportional to the size in bytes 21:44:42 There is a significant surcharge levied by the network on 1/16 transactions 21:49:00 I was involved in designing this surcharge back in 2018. This was done to avoid a verification time attack 21:53:49 The difference between size and weight is this surcharge 22:00:30 I mean I do agree increasing the ring size does not deter a bloating attack, but there is a very real market for braking Monero's privacy 22:00:31 22:00:31 Even worse there is a market for the ILLUSION of breaking Monero's privacy with government agencies offering millions of USD for this. It is called Blockchain Surveillance (BS) 22:02:26 This is why there's a real community concern regarding a possible black marble or flood XMR attack. 22:06:46 Right but my point is that any deanon attacker doesn't practically have to worry about the block size limit with 1/16's, so any difficulties with raising the median are moot. The minimum fee level will work fine. 22:08:43 1/16's have a higher cost per KB, sure, but that's exactly my point. The fact that they're not spamming 1/16's seems to indicate that their attack is targeting blocksizes, not decoys. Even with the extra penalty for higher output counts, 1/16's would still be the clear choice in the latter scenario. 22:09:32 ("penalty" is just referring to the fee. I didn't mean to touch on blocksize terminology) 22:13:34 Once you are above 300000 bytes the attack needs a higher fee level with 1/16 than with 1/2 because of the much larger transaction weight. 22:13:34 One cannot scale at minimum fee with 1/16 transactions. 22:14:27 Yes, but my point is that they wouldn't need to go above 300kb for a deanon attack using 1/16's 22:15:06 300kb full of 1/16's = 1.3mb full of 1/2's, in terms of number of outputs 22:15:30 The 20% saving is just not worth it for the spammer if the spammer also has to include transactions with at least 4x or more the fee 22:16:10 But they did go over 300000 bytes 22:19:31 Yes, because they're using 1/2's. My point was that IF the attacker is trying to deanonymize rings, then 1/16's would be the clearly more effective option. They wouldn't need to go above 300kb, probably not even close to 300kb, in order to control a sufficient % of outputs. Since this is not what's actually happening, this attack does not seem to be a deanonymization attack. Hence why they're using 1/2's, and increasing blocksizes. The goal, in my view, is probably to maximize bytes per dollar, not outputs per dollar. 22:21:26 In other words, I think that their usage of 1/2's is itself very strong evidence that this is a bloat attack, not a deanonymization attack. 22:21:42 They actually need way more than 300009 bytes for an effective blue marble attack. Take a look at Rucknium' a analysis 22:24:02 One can get around 4x the number of outputs for black marble under 300000 bytes vs a ring 16 22:24:37 Not enough 22:24:46 if it was to bloat attack, why stop at 300kb ? its both deanon+bloat & if they did 16outputs what would be the chances of dsa selecting decoys from same tx ? 22:26:42 They need more than 300kb to denanonymize rings *using 1/2 spam*. My point is that, if they were instead using 1/16 spam, they wouldn't need large blocksizes. 300kb full of 1/2's equals roughly 400 outputs. 300kb full of 1/16's equals roughly 1800 outputs. 22:27:52 No because of the weight surcharge 22:28:09 jack_ma_blabla: I think this is a long term play. Their current script seems to keep slipping the median blocksize down, so I wouldn't be surprised if that were fixed, possibly including a pause in spam, and then a much more consistent increase in the median blocksize 22:32:37 The 300000 bytes is a limit on weight including the surcharge and not size. So more like 220 22:33:28 More like 20% More outputs 22:33:48 With 1/16. If that 22:34:49 ...oh. I had thought that transaction weight was only utilized for fee calculation, but I think I see what you're saying now. 22:38:58 What does the bloat attack actually achieve in real terms though? Is it just the cost of creating/running/maintaining a node? Seems a fairly long term payback for the attacker. 22:39:57 The key aspect with Monero scaling is that fees are ultimately driven by the consensus level protocol controlling block weight, penalty and scaling 22:39:57 The key principle is how much penalty paid by a miner is a user willing to compensate the miner for. 22:40:30 Plus, if its "just" the bloat attack, any negative consequence for node operators is at least someway offset by a privacy gain for the whole network. 22:45:21 Yes, primarily increased node resource usage. As well as increased wallet syncing times, but I don't think that would be the main objective. 22:45:45 It would make sense if a bloat attack is coming from a BTC maxi in particular. For example, fiatjaf (or whatever his name is) was very publicly looking into launching a bloat attack against Monero. 22:53:24 If it was a bloat attack it would have increased exponentially as it’s cheap, 1btc worth of xmr can spam us for weeks and xmr price drop as it would be unusable to general public; a spiral not costing much in terms of btc 😅 22:53:24 Ppl wanting cheap fees need to understand how this all can go down the drain 23:25:23 to offer another angle on bloat attack: this spam wave had caused my node to blow through my isp's data allowance for the month 23:30:36 i upgraded to unlimited data, but i imagine many residential node operators could not afford to do so