moneromooo: unlock time PR synced fine

Thanks

Someone mentioned the FloodXMR attack today, and reviewing all the details around how Monero's scaling and privacy mitigates/reduces the threat made me want to shoot out a thank-you to all of you working so hard to make Monero what it is.

So many layers at work here, and so masterfully thought out and engineered. It's not perfect (yet), but the constant iteration and growth in Monero is (IMO) unmatched, and shows how dedicated each of you are to making Monero into the tool we so desperately need.

Any conclusions from revisiting floodxmr?

IIRC the original report was _wildly_ flawed

and had no solid understanding of the protocol

Basically that while the initial report was massively flawed and poorly written, the overall attach vector is possible, but impractical because a sufficient flood would require making it extremely visible what is happening, while also costing massive amounts of XMR in fees.

Its more of a DoS vector, honestly, as users would just not use Monero while the attack is ongoing, and then once it stops they would be able to use the chain again without much risk within a few days.

Sure, "you can make a lot of outputs if you can afford them" is always a true statement

More detailed thoughts here: paste.debian.net/1163341

Thats what I shared in another community as I worked through the question "out loud"

I haven't looked at that preprint in a while to see if they revised their flawed analysis

Yeah I do wonder if it was revised and if it was ever passed through peer-review.

e.g. they didn't realize that fees scaled according to transaction weight, not size

specifically to avoid the kind of direct DoS they initially proposed

They also didn't know there was an output limit

The fact that the preprint was widely shared by knowledgeable people without any kind of review was annoying and sad

Ah yes, that too

Trivial errors

No kidding, it was basically useless as-written

AFAIK it never received formal review

I responded to several of the errors

Because every calculation was just made up out of thin air against an ideal version of Monero (to them)

and was assured they were reviewing it

but I never heard back with results

Basically, yes

They never tried their attack in a simulation using a Monero client

It was reckless to post such a flawed preprint

Yeah, didn't substantiate any claims with code etc.

Was your link from a recent reddit post?

Sad, honestly, but like most of those it was a good chance to revisit our defense against similar attacks

And it was good to see we were already practically prepared

Sure, but the BP design was specifically to address those kinds of DoS attacks

the preprint just ignored it entirely

because reasons

<sarang "Was your link from a recent redd"> No, the old original one from a year ago

it was brought up in a Decred chat-room as an "easy" attack vector against Monero after someone shared the IRS news lol

Heh

It's "easy" if you're rich enough to overwhelm the network

It's not nearly as easy as the flawed preprint implied

Yeah for sure

It's also required that any such flood be kept up indefinitely

Since decoy selection isn't uniform

Its easy to do but is quickly caught and easily avoided. It's really just a DoS, not a privacy attack.

<sarang "It's also required that any such"> yeah I focused on that :)

Stop the attack, and the effects quickly dissipate

So many moving parts that all combat it

Well, it's a privacy attack if the attacker controls enough outputs

In that it reduces the uncertainty of the transaction graph

This depends on ring size

But because it's so visible, you could just not use Monero till it dissipates.

Well, it's visible if you do it all at once

Since it requires a minimum of 65% output control for long periods to have even a small amount of efficacy

If you're clever, you slowly ramp up and people cheer the increase in volume

True, but even then could be shot down by info from exchanges, XMR.to, minko.to, etc. operators

If the conclusion is "oh man, if only Monero had a protocol that used the full output set for anonymity" then the answer is yes, it would

But this can't be efficiently done without central trust, as we know

But would be harder to refute with hard evidence if properly ramped up