00:45:19 <selsta> moneromooo: unlock time PR synced fine
00:46:03 <moneromooo> Thanks
18:48:39 <sethsimmons> 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.
18:49:20 <sethsimmons> 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.
18:55:36 <sarang> Any conclusions from revisiting floodxmr?
18:55:46 <sarang> IIRC the original report was _wildly_ flawed
18:55:54 <sarang> and had no solid understanding of the protocol
18:56:38 <sethsimmons> 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.
18:57:06 <sethsimmons> 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.
18:58:24 <sarang> Sure, "you can make a lot of outputs if you can afford them" is always a true statement
18:58:39 <sethsimmons> More detailed thoughts here: https://paste.debian.net/1163341/
18:58:57 <sethsimmons> Thats what I shared in another community as I worked through the question "out loud"
18:58:58 <sarang> I haven't looked at that preprint in a while to see if they revised their flawed analysis
18:59:19 <sethsimmons> Yeah I do wonder if it was revised and if it was ever passed through peer-review.
18:59:33 <sarang> e.g. they didn't realize that fees scaled according to transaction weight, not size
18:59:47 <sarang> specifically to avoid the kind of direct DoS they initially proposed
19:00:03 <sethsimmons> They also didn't know there was an output limit
19:00:10 <sarang> The fact that the preprint was widely shared by knowledgeable people without any kind of review was annoying and sad
19:00:15 <sarang> Ah yes, that too
19:00:19 <sarang> Trivial errors
19:00:27 <sethsimmons> No kidding, it was basically useless as-written
19:00:27 <sarang> AFAIK it never received formal review
19:00:33 <sarang> I responded to several of the errors
19:00:40 <sethsimmons> Because every calculation was just made up out of thin air against an ideal version of Monero (to them)
19:00:40 <sarang> and was assured they were reviewing it
19:00:46 <sarang> but I never heard back with results
19:00:50 <sarang> Basically, yes
19:01:04 <sarang> They never tried their attack in a simulation using a Monero client
19:01:18 <sarang> It was reckless to post such a flawed preprint
19:01:22 <sethsimmons> Yeah, didn't substantiate any claims with code etc.
19:01:40 <sarang> Was your link from a recent reddit post?
19:01:42 <sethsimmons> Sad, honestly, but like most of those it was a good chance to revisit our defense against similar attacks
19:01:49 <sethsimmons> And it was good to see we were already practically prepared
19:02:06 <sarang> Sure, but the BP design was specifically to address those kinds of DoS attacks
19:02:16 <sarang> the preprint just ignored it entirely
19:02:18 <sarang> because reasons
19:02:23 <sethsimmons> <sarang "Was your link from a recent redd"> No, the old original one from a year ago
19:02:44 <sethsimmons> it was brought up in a Decred chat-room as an "easy" attack vector against Monero after someone shared the IRS news lol
19:03:16 <sarang> Heh
19:03:25 <sarang> It's "easy" if you're rich enough to overwhelm the network
19:03:36 <sarang> It's not nearly as easy as the flawed preprint implied
19:03:40 <sethsimmons> Yeah for sure
19:03:51 <sarang> It's also required that any such flood be kept up indefinitely
19:03:59 <sarang> Since decoy selection isn't uniform
19:04:04 <sethsimmons> Its easy to do but is quickly caught and easily avoided. It's really just a DoS, not a privacy attack.
19:04:10 <sethsimmons> <sarang "It's also required that any such"> yeah I focused on that :)
19:04:14 <sarang> Stop the attack, and the effects quickly dissipate
19:04:21 <sethsimmons> So many moving parts that all combat it
19:04:30 <sarang> Well, it's a privacy attack if the attacker controls enough outputs
19:04:41 <sarang> In that it reduces the uncertainty of the transaction graph
19:04:50 <sarang> This depends on ring size
19:04:51 <sethsimmons> But because it's so visible, you could just not use Monero till it dissipates.
19:05:03 <sarang> Well, it's visible if you do it all at once
19:05:07 <sethsimmons> Since it requires a minimum of 65% output control for long periods to have even a small amount of efficacy
19:05:13 <sarang> If you're clever, you slowly ramp up and people cheer the increase in volume
19:05:41 <sethsimmons> True, but even then could be shot down by info from exchanges, XMR.to, minko.to, etc. operators
19:05:51 <sarang> 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
19:05:59 <sarang> But this can't be efficiently done without central trust, as we know
19:06:06 <sethsimmons> But would be harder to refute with hard evidence if properly ramped up