.merge+ 7017 7069

Added

I see that recently it's all double PRs, one for master and one for the branch, isn't that a bit annoying for everybody? Shouldn't master and branch be even at this point? Double PRs that get reviewed twice, two different commits for the same thing and unnecessary notifications. Is there a better way to deal with that?

ErCiccione[m]: not all PRs are double

but bug fixes have to be applied to both master and branch

yeah i see. I was asking myself if there isn't a better way to deal with that, like cherry-picking the needed commits instead of opening two PRs

the problem is that master and branch diverge

so maintainers would have to solve merge conflicts

which is something we don't want

the original author should make sure it applies cleanly

that's why opening 2 PRs is the best solution right now

got it.

Writing up some details on the ongoing network attacks for a blog post, and trying to piece together an accurate timeline and have some questions, but wasn’t sure if it’s best to ask here or over DM to someone more in the know

Questions like: Was this PR targeted at the attacks — monero-project/monero #6916?

Or if it’s generally a better idea to keep details to a minimum I can go that route, just thought it would be helpful to have a third-party post about it for those interested in an “unofficial” account of whats been going on and whats been done about.

sethsimmons "Was this PR targeted at the attacks" -> it was

Thanks, I’ll toss some more questions in here as I work through it 🙂

the PR was aimed to reduce a chance of complete node isolation

Yeah, eclipse attack was one of the first noticed attacks IIRC

v0.17.1.6 merge list: 7054 7063 7065 (maybe 7067) 7069 7071 7073

Was this one of the mitigations to the attack, vtnerd xiphon

And does anyone know the PR that is helping to let wallets sync when some peers report block height +2?

7066 / 7067 but not sure if we will merge it

7018 tries to avoid selecting attacker nodes during Dandelion++ stem phase

Ah, ok, saw that one but seemed conflicted so wasn't sure

I think this is a complete list then and timeline of the fixes:

But I could be missing some, and not sure if the attack was noticed earlier/other symptoms were noticed that I've missed

Also not sure when this was first spotted: - ~11/10/2020 - User's notice that wallet will not sync as malicious nodes are reporting a block height of +2 to the

actual height

That's a rough estimate but couldn't track down a first sighting

would add -> "proposed to prevent malicious nodes spamming large peer list"

Thanks, updated :)

"11/10/2020" is it MM-DD-YYYY format?

Yeah, sorry, US with our backward dates over here

I prefer YYYY-MM-DD as a programmer, but normal people are not familiar with it :D

.merge+ 7070 7071 7072 7073

Added

.merges

.merge+ 7062 7063

Added

7070 and 7072 would benefit from a second review

.merge- 7069

Removed

we need some more eyes on 7054, 7070, 7072

.merge+ 7065

Added

.merge+ 7076

Added

.merges

always use ISO dates. YYYY-MM-DD.

Should have months on 4 digits, to be safe from 988 more emperors adding a month with their name.

Snipa: please wait with 7054, 7070, 7072 (and master equivalents)

I'd seen, will note them.

they are ready but maybe good to get some more reviews

I meant branch equivalents*

.merge- 7070 7071 7072 7073

Removed

the others are fine to merge

Woohoo! Maximum laziness.

.merges

:D

Hello everyone :), selsta I added the wallet-cli.log too to the issue. You can check it out :). Both in files, rpcpayserver.log and monero-wallet-cli.log. Here is the direct link for the issue (monero-project/monero #7041). Thanks

If you need anything else from me let know. :)

I guess we should have mentioned that they should have been *matching* logs.

okay, I cut only the part where the error shows up. Let me put the whole log. :/

The file is 99,4 MB, github doesn't let me paste it. Now I remember, I had to cut it because of that. That's the reason.

I could paste less lines, let me know. But is the log that connects to the server, I connect from my local machine to the outreach's server, so not sure if someone is already connecting to the server too. We shared it already to the public in some public location.

Maybe that's why they look different? Not sure.

You can cut just one part with an error, as long as it's the same time frame, and not two unrelated logs.

How can I know they are unrelated?

let me check them out

There are timestamps at the beginning of each line.

sethsimmons: AHPs from OVH subnets were first noticed in early July 2019. IIRC, 5732/5733 and 5737/5738 were the first mitigations.

Oh wow, that’s much earlier than I realized.

I’ll add a note of that, thanks!