01:48:30 <selsta> please no tag yet
01:48:36 <Snipa> K.
01:49:00 <Snipa> I haven't started on the release merges yet.
01:49:11 <Snipa> Looking over 7102 before I start in on the branches.
01:52:48 <Snipa> Clear to get all the merges into the release branch, even if not tagged yet selsta?
01:54:24 <selsta> should be good
01:54:34 <Snipa> The merging shall continue.
01:55:53 <selsta> :D thanks
01:57:23 <Snipa> Merges done
02:04:25 <gingeropolous> yay!
02:10:26 <gingeropolous> wiat Snipa don't do anything
02:10:29 <gingeropolous> 10k commits.
02:10:51 <Snipa> Hahaha.
02:10:57 <Snipa> Preserve this moment in history?
02:45:20 -xmr-pr- moneromooo-monero opened pull request #7123: protocol: revert incoming chain height check against local chain
02:45:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7123
03:23:36 <gingeropolous> ok u can touch things again
07:00:20 -xmr-pr- jscoobyced opened issue #7125: [raspberrypi-4-4gb-ram] [monerod] Constantly fail downloading the chai...
07:00:20 -xmr-pr- > https://github.com/monero-project/monero/issues/7125
08:18:40 <sech1> moneromooo selsta I see a lot of rushed PRs yesterday. While they seem rather simple, more testing is needed instead of just tagging .7. Eventually a mistake can creep in the code that will fracture the p2p network by nodes banning each other in some conditions. This is what attacker wants.
08:19:01 <selsta> We did not tag yet.
08:19:12 <sech1> I'm just saying don't tag right after all PRs are merged
08:19:44 <selsta> yep
08:19:50 <sech1> A few people (like 10 at least) need to run them and see if they ban a lot of innocent peers or not
08:22:46 <selsta> Mooo and I have been running them since yesterday. Hope others try them too.
08:23:47 <selsta> But I doubt 10 people will try them. Even with large releases we don't have 10 testers.
08:28:30 <sech1> Seeing https://github.com/monero-project/monero/pull/7123 is already worrying me
08:28:36 <sech1> I can test this time :)
08:29:22 <selsta> mooo found 7123 with testing :D
08:52:46 <selsta> 7123 does not seem correct to me
08:53:17 <selsta> it breaks the detection we wanted in the first place
08:57:46 <sech1> but it has many false positives
08:59:02 <selsta> it did not in my testing, maybe for others
08:59:38 <selsta> all IPs that were banned after running for 12 hours were out of my block list
09:01:05 <selsta> but the patch has a reason most likely, so more work is needed there
09:02:22 <sech1> "We can actually request a chain that's further away from what we have as we buffer more and more"
09:02:29 <sech1> So maybe syncing peers can be blocked by this?
09:09:43 <cvg8> has been  running the master-ebdc617 for hours, what logging level needed or something settings for  test?
09:12:27 <selsta> do you see IPs getting banned that are not in https://gui.xmr.pm/files/block.txt ?
09:17:07 <cvg8> just now
09:17:08 <cvg8> 2020-12-11 09:09:43.329	I Host 87.98.224.123 blocked.
09:17:10 <cvg8> 2020-12-11 09:12:07.180	I Host 145.239.118.5 blocked.
09:18:00 <cvg8> I Host 51.68.222.162 blocked.
09:18:16 <selsta> these are fine
09:18:38 <sech1> All OVH
09:18:55 <selsta> sech1: it is likely that the issue only becomes visible with --log-level 1
09:19:25 <selsta> because innocent peers would only get kicked once / twice
09:19:32 <selsta> still something we have to fix
09:20:04 <cvg8> 2020-12-11 09:09:24.588	E Exception at [core::handle_incoming_txs()], what=ge_frombytes_vartime failed at 380
09:20:29 <selsta> this is unrelated
10:06:27 <moneromooo> Some peers are banned because they're too slow. If that's the reason, the comms get reset, and in turn this gets them kicked by the "receiving message out of sequence" system. That's a bit annoying, but acceptable to me.
10:07:08 <moneromooo> That'll be made more lenient sometime later, needs something else first.
10:12:40 <sech1> Are you talking about 7123?
10:14:47 * moneromooo looks
10:15:05 <moneromooo> No.
10:15:48 <sech1> So what was wrong about 7123? I asked about that line of code yesterday and you said it was ok :D
10:16:33 <selsta> with 7123 the +2 detection stops working
10:17:44 <moneromooo> Oh really.
10:18:44 <moneromooo> OK, I'll look at it soon.
10:23:42 <selsta> could allowing `--ban-list url` lead to security issues?
10:24:51 <selsta> Some people find it difficult to download the file and specify the patch correctly. This would also allow that users stay up to date.
10:25:50 <selsta> the path*
10:30:39 <sech1> this can be solved by a simple bash script (run wget, run monerod) for startup
10:30:49 <sech1> no need to add it in monerod
10:31:42 <selsta> Yes, but Windows users (who have to most issues) don't know how to use a bash script.
10:31:50 <selsta> Not sure if bash even runs on Windows.
10:32:47 <selsta> not all Windows users obviously, those that have issues
10:44:46 <moneromooo> It's unrelated, it'd happen also before yesterday's changes.
11:28:07 <moneromooo> New patch pushed.
11:29:01 <selsta> together with 7123?
11:30:19 -xmr-pr- moneromooo-monero opened pull request #7128: protocol: stricter checks on received chain hash list
11:30:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7128
11:30:20 -xmr-pr- moneromooo-monero opened pull request #7127: protocol: stricter checks on received chain hash list
11:30:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7127
11:41:42 <moneromooo> No, new patch.
11:41:48 <moneromooo> 7127
11:42:00 <selsta> right, but should I test together with 7123?
11:42:05 <selsta> 7123 + 7128 looks good again, +2 attack getting stopped
11:42:20 <moneromooo> Yes, and all others you intend to use for the release.
11:42:37 <selsta> ok
11:44:43 <selsta> I have been running release-v0.17 + 7123 + 7128, looks good so far, will let it run a bit to check for innocent bans
11:54:41 <moneromooo> 7129 increases the number of out connections when syncing, some people reported a substantial sync time decrease with more out peers.
11:55:00 <moneromooo> It'd be interesting to see if this patch also shows the improvement, and whether it makes things worse for others.
11:55:11 <moneromooo> It doesn't seem to help me, for example.
11:55:29 <selsta> I had the idea to increase out_peers until the last checkpoint, but doing it in sync mode generally should also work.
12:00:19 -xmr-pr- moneromooo-monero opened pull request #7129: bump the number of out connections in sync mode
12:00:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7129
12:14:37 <moneromooo> I think it does hinder if your connection is maxed out already with 12.
13:48:50 <gingeropolous> ive got master up for 10 hrs now
15:10:13 <selsta> .merge+ 6495 7123 7124 7127 7128
15:10:14 <xmr-pr> Added
18:21:16 <moneromooo> Whoever wants to review, see 7131. I'll be using that later, so it'd be nice to have a good portion of nodes already setup to include this data, though it is noop now.
18:21:55 <moneromooo> Basically, check PoW for the first block before considering a claimed chain.
18:22:44 <moneromooo> (and the rest isn't ready, though it works as a PoC)
18:30:20 -xmr-pr- moneromooo-monero opened pull request #7131: protocol: include first new block in chain entry response
18:30:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7131
18:30:21 -xmr-pr- moneromooo-monero opened pull request #7130: protocol: include first new block in chain entry response
18:30:21 -xmr-pr- > https://github.com/monero-project/monero/pull/7130
19:30:20 -xmr-pr- moneromooo-monero opened pull request #7133: protocol: wait till we get blocks to update target height
19:30:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7133
19:30:21 -xmr-pr- moneromooo-monero opened pull request #7132: protocol: wait till we get blocks to update target height
19:30:21 -xmr-pr- > https://github.com/monero-project/monero/pull/7132
20:31:23 <hyc> 7132 sounds like it defeats the purpose of target_height
20:35:46 <moneromooo> It's also set when getting the blocks.
20:36:04 <moneromooo> Getting the first block in the series, I mean.
20:36:55 <hyc> you just closed these anyway, so, didn't work out as expected?
20:37:25 <moneromooo> Apparently. Worked for me, but not selsta. And tbh I can't be bothered debugging that one since this is just an addon anyway.
20:37:59 <moneromooo> It should get closed once we have the PoW check. Which will be... probably at next fork, to avoid disrupting.
22:06:52 <Kronovestan> selsta, Ummm we still have an issue?... https://i.imgur.com/6Z9pcWJ.png
22:07:37 <sech1> check which IPs in sync_info show +2 target height and post them here
22:09:28 <Kronovestan> I closed the daemon and reopened it
22:09:33 <Kronovestan> it's now at 100%
22:09:37 <Kronovestan> if it does it again I will post for you.
22:10:53 <selsta> Kronovestan: do you have the ban list applied?
22:11:00 <Kronovestan> no
22:11:08 <selsta> We might need one or two more releases to resolve this issue.
22:11:13 <Kronovestan> 10-4
22:11:17 <selsta> In the meantime use the ban list.
22:11:18 <Kronovestan> I will reapply ban list.