08:08:06 .merge+ 7017 7069 08:08:06 Added 10:35:00 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? 10:36:34 ErCiccione[m]: not all PRs are double 10:37:05 but bug fixes have to be applied to both master and branch 10:37:07 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 10:37:37 the problem is that master and branch diverge 10:37:47 so maintainers would have to solve merge conflicts 10:37:54 which is something we don't want 10:38:04 the original author should make sure it applies cleanly 10:38:20 that's why opening 2 PRs is the best solution right now 10:38:57 got it. 10:55:17 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 10:55:22 Questions like: Was this PR targeted at the attacks — https://github.com/monero-project/monero/pull/6916? 10:58:10 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. 11:44:10 sethsimmons "Was this PR targeted at the attacks" -> it was 11:45:30 Thanks, I’ll toss some more questions in here as I work through it 🙂 11:46:05 the PR was aimed to reduce a chance of complete node isolation 11:48:23 Yeah, eclipse attack was one of the first noticed attacks IIRC 14:17:40 v0.17.1.6 merge list: 7054 7063 7065 (maybe 7067) 7069 7071 7073 14:28:40 Was this one of the mitigations to the attack, vtnerd xiphon 14:28:43 https://github.com/monero-project/monero/pull/7018 14:34:56 And does anyone know the PR that is helping to let wallets sync when some peers report block height +2? 14:36:22 7066 / 7067 but not sure if we will merge it 14:37:06 7018 tries to avoid selecting attacker nodes during Dandelion++ stem phase 14:37:08 Ah, ok, saw that one but seemed conflicted so wasn't sure 14:37:47 I think this is a complete list then and timeline of the fixes: 14:37:56 https://paste.debian.net/1175585/ 14:38:12 But I could be missing some, and not sure if the attack was noticed earlier/other symptoms were noticed that I've missed 14:39:03 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 14:39:03 actual height 14:39:14 That's a rough estimate but couldn't track down a first sighting 14:43:30 would add -> "proposed to prevent malicious nodes spamming large peer list" 14:44:40 Thanks, updated :) 14:44:46 "11/10/2020" is it MM-DD-YYYY format? 14:45:01 Yeah, sorry, US with our backward dates over here 14:45:28 I prefer YYYY-MM-DD as a programmer, but normal people are not familiar with it :D 14:56:54 .merge+ 7070 7071 7072 7073 14:56:54 Added 16:06:23 .merges 16:06:23 -xmr-pr- 7017 7030 7043 7068 7069 7070 7071 7072 7073 16:06:29 .merge+ 7062 7063 16:06:29 Added 16:18:07 7070 and 7072 would benefit from a second review 17:33:46 .merge- 7069 17:33:46 Removed 19:35:25 we need some more eyes on 7054, 7070, 7072 20:30:25 .merge+ 7065 20:30:26 Added 20:41:52 .merge+ 7076 20:41:52 Added 20:41:57 .merges 20:41:57 -xmr-pr- 7017 7030 7043 7062 7063 7065 7068 7070 7071 7072 7073 7076 20:52:01 always use ISO dates. YYYY-MM-DD. 21:16:58 Should have months on 4 digits, to be safe from 988 more emperors adding a month with their name. 21:22:23 Snipa: please wait with 7054, 7070, 7072 (and master equivalents) 21:22:47 I'd seen, will note them. 21:22:50 they are ready but maybe good to get some more reviews 21:22:59 I meant branch equivalents* 21:24:26 .merge- 7070 7071 7072 7073 21:24:26 Removed 21:24:29 the others are fine to merge 21:24:41 Woohoo! Maximum laziness. 21:24:43 .merges 21:24:43 -xmr-pr- 7017 7030 7043 7062 7063 7065 7068 7076 21:24:49 :D 21:31:18 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 (https://github.com/monero-project/monero/issues/7041). Thanks 21:34:24 If you need anything else from me let know. :) 21:43:50 I guess we should have mentioned that they should have been *matching* logs. 22:16:34 okay, I cut only the part where the error shows up. Let me put the whole log. :/ 22:19:20 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. 22:20:36 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. 22:20:59 Maybe that's why they look different? Not sure. 22:22:53 You can cut just one part with an error, as long as it's the same time frame, and not two unrelated logs. 22:32:29 How can I know they are unrelated? 22:33:39 let me check them out 22:35:08 There are timestamps at the beginning of each line. 23:33:07 sethsimmons: AHPs from OVH subnets were first noticed in early July 2019. IIRC, 5732/5733 and 5737/5738 were the first mitigations. 23:44:45 Oh wow, that’s much earlier than I realized. 23:44:45 I’ll add a note of that, thanks!