<s​gp_:monero.social> If we assume this is a spam attack, is a fair estimate for the maximum ongoing daily cost: 

<s​gp_:monero.social> $145 x (0.1 XMR/block fees) x (60 mins) * (24 hrs) / (2 mins/block) = $10,000

not sure about that math, I figure 80k transactions at half a cent each is 400 USD

Yea, 400usd

Sweep singles are very likely churns, i expect to see a flood of consolidations > splits > churns once the outputs are dust

Though, if same person as 1/16 spam, who knows what took them so long to start using the oyt

outputs*

<c​haserene:matrix.org> 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 <clipped message>

<c​haserene:matrix.org> 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.

<g​ingeropolous:monero.social> 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.

would need binning on fees essentially

<c​haserene:matrix.org> sorry if obvious -- what would fee binning look like?

<c​haserene:matrix.org> despite it's shortcomings, I see great potential in isthmus's idea of discretized fees (gist.github.com/UkoeHB/f508a6ad973f…03057e87449e#transaction-uniformity). I've also been toying with how an EIP-1559 fee structure (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<clipped message>

<c​haserene:matrix.org> plementation (especially as applied to Monero) incurs an awful lot of complexity.

<c​haserene:matrix.org> (IIRC that conversation, it may be even impossible, but no one was sure)

"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

"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

Discretized fees are currently implemented in the Seraphis WIP upgrade.

Buyinf xmr involves withdrawing it. Now, unless they are doing 100k withdrawals, how exacly did they obtain so many outputs?

And big withdrawal would have had the funds consolidates on chain in multiple tx, and THEN youd have to split that back up

We have a 10 block lock, so they couldnt have dont it using 1/2 outputs without waiting 20mins between spends

without evidence of the contrary, i think they _must_ have already owned at least 5000 outputs

s/evidence/a theory that explains how one would accumulate such firepower

split a big output in two, then split those in two, then split those in two...

you get 4k outputs in 12 generations this way so like.... 4 hours?

<c​haserene:matrix.org> 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 <clipped message>

<c​haserene:matrix.org> them. which is nothing. from there on, they can get even more if their 2-outs generate 2 real outs (not sweep_single).

^^

<c​haserene:matrix.org> where is this UI from? I found 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).

<g​fdshygti53:monero.social> github.com/lalanza808/docker-monero-node

<g​fdshygti53:monero.social> Note that the map part seam to be broken

<u​ntraceable:monero.social> 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, <clipped mess

<u​ntraceable:monero.social> I don't know if burning fees via a EIP-1559 is the best idea.

It's $700/day right now, with current price and block size

<m​onerobull:matrix.org> if we assume this costs nodes 20$ in storage per year and we have 18k nodes

<m​onerobull:matrix.org> thats 360k damage vs 255k cost

<m​onerobull:matrix.org> now, i dont want to know how much fees companies in the ecosystem are loosing out on

<m​onerobull:matrix.org> but this would be fixed if auto fee worked

<u​ntraceable:monero.social> 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.

<u​ntraceable:monero.social> Interested to see what the cost would be if automatic fees were working.

<m​onerobull:matrix.org> yeah

<m​onerobull:matrix.org> imo fees should be max 5 cents though

<m​onerobull:matrix.org> i already get really annoyed when my bank charges 10 cents per tx

they're too cheap only at the current price level

in terms of Monero coins, they're not cheap

p2pool miners feel it already when they consolidate their funds. They spend up to 5% on fees

Or, another angle: a block full of the lowest fee transactions adds 1% to the block reward. 0.6 -> 0.606 XMR

the next tier of fees is 0.6 -> 0.63 XMR, and so on

<u​ntraceable:monero.social> 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.

<u​ntraceable:monero.social> my 2 piconero

<a​lex:agoradesk.com> To be fair, the tx spam levels we're seeing is not enough to get anything even close to a full transaction graph.

<u​ntraceable:monero.social> Yes true, I was exaggerating a bit admittedly.

<a​lex:agoradesk.com> 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.

<u​ntraceable:monero.social> Been doing this actually. Must have sent 20ish transactions yesterday. Its just a drop in the bucket, but im doing my part 🤣

there are always 2-3 decoys which are old, like weeks to years old

so they need to keep spamming for a long time to get any results

and the moment the second spammer appears, it's all futile

<u​ntraceable:monero.social> thats good, wasn't aware of that.

<u​ntraceable:monero.social> 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.

<m​onerobull:matrix.org> we ruled out incognito market closing shop right?

Unlikely

If you empty a wallet, you do sweep_all and then a bunch of 146 input transactions is created

here we have a flood of 1 input transactions

<m​onerobull:matrix.org> assuming the users create account, deposit, buy, never touch the account again

<m​onerobull:matrix.org> would this still be that unlikely?

<m​onerobull:matrix.org> imagine you have 400k wallets like this

Those would be subaddresses

they can all be swept together

<m​onerobull:matrix.org> depends on if incognito used subaddresses

even if it were separate wallets, the flood is approaching 0.5 million transactions now

I don't think they had that many users

<m​onerobull:matrix.org> > Now that you have an address send the funds to the XMR address.

<m​onerobull:matrix.org> >

<m​onerobull:matrix.org> > 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.

<m​onerobull:matrix.org> from their faq

<m​onerobull:matrix.org> you wouldnt have to manually request scanning for subaddresses

<m​onerobull:matrix.org> it depends on how long theyve been operating

<m​onerobull:matrix.org> if it suddenly stops at some point, i would assume this was actually it

<c​haserene:matrix.org> 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<clipped message>

<c​haserene:matrix.org> 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.

white hats will also run out of money, it will stop naturally

<m​onerobull:matrix.org> not if your average ccs-funding-whale decides they want to help out the network

If it's just 1 white hat, they'll eventually see that they control 90% of outputs :D

<m​onerobull:matrix.org> "are we the baddies?"

<c​haserene:matrix.org> 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<clipped message>

<c​haserene:matrix.org> 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.

<u​ntraceable:monero.social> as I can remember, white house market had close to 400k users before it shutdown. I dont think incognito published their stats though.

"<sech1> p2pool miners feel it already when they consolidate their funds" ... that's because consilidation trasnactions are dummy inefficient which I would also support fixing

yes, spending coinbase outputs should be made more efficient

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 :/

<c​haserene:matrix.org> can we simulate the on-going costs of the spam once the auto fee switch is patched?

the costs for the attacker will not change

they can just flood the mempool with low fee transactions to make sure it stays full

is there a way to limit mempool size on the node? seems like no

<c​haserene:matrix.org> 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?

<m​onerobull:matrix.org> i believe its capped at 600 mb

<m​onerobull:matrix.org> not sure what happens then

648 mb is the cap

you can reduce it in the command line

--max-txpool-weight arg (=648000000) Set maximum txpool weight in bytes.

<m​onerobull:matrix.org> what happens afterwards

<m​onerobull:matrix.org> once the limit is reached

when it hits the cap, oldest transactions get removed

oldest = lowest fee because they didn't get mined for a long time

<m​onerobull:matrix.org> ok thanks

but it only matters if big mining pools do this

<m​onerobull:matrix.org> do transactions time out by themself if they dont get mined for a specific amount of time?

<m​onerobull:matrix.org> or can they chill in mempool forever?

IIRC default timeout is 3 days

<m​onerobull:matrix.org> 👍️

#define CRYPTONOTE_MEMPOOL_TX_LIVETIME (86400*3) //seconds, three days

and 648 mb limit corresponds to 3 days worth of full blocks

300k*720*3 = 648m

whew, imagining public noeds crying and dying with a 600 MB mempool and wallets constantly requesting it all. good stuff

could we use view tags to have wallets only request relevant transactions

in mempool, or maybe it already does

Well, to play devil's advocate, this way getting more people to run their own nodes would not be necessarily too bad ..

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)

I guess there's like, Umbral, if you have a whole machine to dedicate to it, but again kind of a high barrier

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

so they end up connecting to whatever onion nodes are avail

"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

Not via 2 out

"It would be costlier if the automatic fee estimation was working properly, " < no, it would cost less

<p​reland:matrix.org> It depends on when you want to start going for transaction flooding

<p​reland:matrix.org> If you want 100% of the fees going to flooding, splitting it into 2 is the most efficient

<p​reland:matrix.org> It would also be the most visible though

<c​haserene:matrix.org> with solely 2-outs, the preparation took 4 hours, as Lyza already mentioned. I just calculated the shortest "time-to-market" possible.

"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

"with solely 2-outs, the preparation took 4 hours, as Lyza already mentioned. I just calculated the shortest "time-to-market" possible" < math?

Shorted time to market is what i said, they already did 1/16 spam and already owned outputs

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

^

<m​onerobull:matrix.org> boring

<m​onerobull:matrix.org> i want to see monero overtake bitcoin

<c​haserene:matrix.org> (roundup(log(2,1723))+1) * 20 minutes

<c​haserene:matrix.org> the 1723 isn't a magic number, if you think it's off, I can later write more how I arrived to it

<m​onerobull:matrix.org> and the maxis cry about how "all the transactions happen on lightning aynways"

150k tx/day is the max without an actual fee bump

Anything more than that its a bigbang

(Unless the spam pays fees, or we all pay fees for them)

(the max today*. Grows very slowly at min fee)

no, it's 10*120*2 = 2400 outputs

10 blocks, 120 seconds per block, 2 tx/s

sech, what math is this for? The 10 blocks

~1.65 tx/s is max at ~300kb blocks

10 blocks wait time

2 tx/s is to have a leeway for bigger blocks

<c​haserene:matrix.org> 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?

Maybe someone could make the fake out selection weigh outputs from txes with higher fee more ^_^

hmm

it can work in current situation, but not in general

higher fee transactions were sent urgently and therefore maybe more likely to be re-spent soon? maybe???