00:41:54 <selsta> moneromooo: could you close 6987?
00:56:49 <luigi1111w> .merges
00:56:49 -xmr-pr- 6983
00:56:51 <luigi1111w> what's up
01:07:03 <selsta> luigi1111w: guiii merges
01:07:16 <luigi1111w> yes but does that help :)
01:07:31 <selsta> also 6983
01:08:51 <selsta> help how
01:15:01 <selsta> ping vtnerd, if you can PR 6897 to release-v0.17 branch in the next hours we can include it in the next release, else we will include it in the next one
01:15:09 <selsta> in this release*
06:40:21 <Snipa> .msrges
06:40:27 <Snipa> .merges
06:40:27 <xmr-pr> Merge queue empty
08:57:51 <hyc> should we put #6948 into 0.17? seems pretty useful
09:08:41 <hyc> hmmm. I started with --add-priority-node zbjkbsxc5munw3qusl7j2hpcmikhqocdf4pqhnhtpzw5nt5jrmofptid.onion:18083 and I have no outbound tor peers again
09:08:53 <hyc> it was definitely connected when I started up
09:09:04 <hyc> but definitely gone now, and not present in print_pl output either
10:03:01 <selsta> We can include it if someone reviews it
12:44:33 <Snipa> .merges
12:44:34 <xmr-pr> Merge queue empty
12:46:12 <Lyza> hyc if you were talking about dropped i2p connections, I think resetting i2p or clearing i2p state or something along those lines may be a big help, because after rebooting my server yesterday my outbound i2p connections all of a sudden started lasting 10x longer. now though, about 24 hours after the reboot, out connections are back to only lasting 3 - 5 minutes
12:58:11 <selsta> I found Tor more stable but that might be due to more Tor nodes
13:21:59 <Lyza> do you mean individual connections were more stable, or you dropped all the OUT connections at once less often? The latter would make sense but I can't see how more nodes would impact the former, which is the real head scratcher for me, why connections are dropping after ~5 minutes
13:23:38 <Lyza> also, I feel like the daemon should actively try to maintain at least two (maybe more?) anonymity network peers when that is enabled, so that number of connections is less likely to go to zero. As it stands, if they aren't priority nodes, the daemon just seems to, Idk, not care that much that there are no out connections. It seems lazy about maintaining them. y'know?
14:02:45 <selsta> Lyza: did you try with both Tor and I2P?
14:05:43 <Lyza> nah I've never set up tor for my node, it's i2p only
14:06:19 <Lyza> I thought i2p was going to end up as the primary solution and kind of don't want the association of running tor from my IP
14:08:28 <Lyza> I get the impression there are more tor peers rn, so perhaps it's worth considering, but using only i2p is largely functional, despite the issues
14:08:52 <Lyza> I'm sure having more peers to rotate between is better for privacy though
17:11:10 <hyc> anyone know how to get from an i2pd private.dat to the keypair used in i2p-zero's tunnels.json ?
17:11:30 <hyc> looks like keyinfo just gives me one of the 2 keys
17:35:25 <hyc> hmm. I had out and in tor connection to same node ID
17:35:34 <hyc> then the out connection dropped
17:35:44 <hyc> and now I have no out tor connections
17:36:39 <knaccc> hyc i have no idea what format private.dat is in, but I do know that in tunnels.json, the format is seckey,pubkey where both are base64 encoded. see https://github.com/i2p-zero/i2p-zero/blob/master/org.getmonero.i2p.zero/src/org/getmonero/i2p/zero/TunnelControl.java#L450
17:36:55 <hyc> thanks
17:37:40 <hyc> just wanted to use the vanity address I had already generated, but not getting the formatting correct. looks like tunnels.json omits trailing base64 padding chars
17:39:15 <knaccc> hyc i use the i2p java base64 encoder/decoder library net.i2p.data.Base64
17:39:26 <knaccc> so i use their code to do the encoding, not mine
17:46:08 -xmr-pr- mj-xmr opened pull request #6989: Clang IWYU header checker script
17:46:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6989
18:07:44 <hyc> knaccc: I think you're outputting more than just seckey,pubkey though. notice that in your tunnels.json output, the beginning of your "seckey" field is always identical to the pubkey field. it just has some extra stuff appended.
18:19:32 <hyc> ah I see.
18:19:57 <hyc> createDestination writes out destination,privatekey,signingprivatekey
18:22:47 <hyc> and d.writeBytes writes out pubkey+signingPubkey
18:31:04 <hyc> you're writing the destination info twice
18:36:42 <hyc> that is, what you're writing as "seckey" is actually both sec+pubkey already. and then you write pubkey again.
18:58:23 <luigi1111w> .merges
18:58:23 <xmr-pr> Merge queue empty
18:58:29 <luigi1111w> selsta plan is what
19:17:19 <knaccc> hyc ah yes, you're right. i think i2p likes to keep the seckey and pubkey together for the same reason that other encryption libraries do, which is because there are catastrophic consequences (secret key revealed) under certain signing circumstances if you ever mix the secret key from one pair with the public key from another
19:18:13 <knaccc> and i stored them separately so that i don't cause a catastrophic situation by failing to extract the pubkey from the seckey/pubkey string properly
19:19:17 <hyc> ok. and looks like I was wrong about the padding discrepancy
19:19:53 <hyc> the private.dat file has 4 extra bytes on the pubkey, so its base64 output needed padding
19:20:22 <knaccc> you must have a vanity address you're really proud of :)
19:20:36 <hyc> lol it took all day yesterday to find :P
19:20:40 <knaccc> haha
19:20:57 <hyc> and now I'm spending all day today to figure out how to use it !!
19:22:38 <knaccc> yeah waiting for i2p warmup isn't fun
19:31:08 -xmr-pr- vtnerd opened pull request #6990: Add support for i2p and tor seed nodes [0.17]
19:31:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6990
19:41:33 <dEBRUYNE> luigi1111w: Think 6985 and 6990 and then tag
19:43:52 <dEBRUYNE> ^ selsta, moneromooo: please confirm
19:50:43 <hyc> ok I have 2 outbound i2p connections now. again, had my initial outbound tor connection too but it's dropped already
19:55:16 <moneromooo> I could also add my tor seed node. It's going to conflict with selsta's PR so will have to be rebased.
19:56:06 <moneromooo> 6897 (minus the moot one)
19:56:21 <moneromooo> wait, no, wrong one
19:56:44 <moneromooo> 6874
19:56:53 * moneromooo removes the other one
19:59:12 <moneromooo> And now 6991 for the branch.
20:01:08 -xmr-pr- moneromooo-monero opened pull request #6991: p2p: add a tor seed
20:01:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6991
20:09:03 <selsta> dEBRUYNE: and 6991 yes
20:09:34 <dEBRUYNE> Perhaps we can tag tonight?
20:09:54 <dEBRUYNE> Would probably be easier for the maintainers if 6991 was added to selsta's PR, right?
20:11:00 <selsta> should not take long to rebase
20:14:33 <selsta> ok luigi1111w please merge 6985 and 6990
20:15:46 <selsta> or wait, merge 6990 and 6991, then I will rebase 6985
20:18:13 <selsta> .merge+ 6990 6991 6985
20:18:13 <xmr-pr> Added
20:20:40 <moneromooo> I can rebase too, no bother.
20:22:43 <hyc> should I add #6948 to 0.17 branch?
20:29:11 <selsta> I would be okay with including it but someone has to review it
20:29:25 <selsta> though PR does not look too big
20:33:27 <hyc> fairly trivial PR, yes
20:33:52 <hyc> but I didn't see it still needed review. never mind, if there's no time for reviews
21:04:09 <hyc> I wonder if tor and i2p themselves have idle timeouts, and that's why the connections keep dropping
21:05:19 <hyc> all of my i2p and tor out conns are gone now
21:06:14 <hyc> still have several tor inbound
21:12:40 <selsta> my i2p connections drop often but tor seem more stable
21:15:05 <Lyza> I regularly have inbound i2p connections that last (according to monerod) for thousands of seconds, 10x longer than my outbound connections. it leads me to believe that outbound i2p connections are stable for at least some users sometimes, since each in connection must be somebody else's out connection
21:15:18 <Lyza> either that or the long-lived incoming connections have silently idled out or something
21:15:31 <moneromooo> monerod sometimes lists connections that don't exist.
21:15:50 <moneromooo> 90% confidence maybe.
21:16:11 <moneromooo> There's a longstanding but about this.
21:16:51 <Lyza> well rn I have 4 inbound i2p connections that have lasted between 3500 and 70,000 seconds. my longest lived OUT connection is 163 seconds
21:17:06 <Lyza> is it bad enough that you think maybe none of those 4 inc connections actually exist?
21:25:39 <moneromooo> No.
21:25:50 <moneromooo> It is rare AFAIK.
21:26:17 <moneromooo> Though who knows, maybe tor/i2p trigger this easier.
22:06:05 <Lyza> yeah could be
22:23:04 <luigi1111w> .merges
22:23:04 -xmr-pr- 6985 6990 6991
22:23:25 <luigi1111w> if this is the final list, I'll merge and tag tonight yet
22:23:31 <luigi1111w> please quadruple confirm
22:30:13 <moneromooo> Looks right.
22:30:26 <moneromooo> 3 more confirms required :)
22:38:10 <selsta> yes
22:38:15 <selsta> final
22:59:40 <selsta> hmm
22:59:43 <selsta> not final merge list
22:59:51 <selsta> have to do one more PR
23:07:25 <selsta> please review https://github.com/monero-project/monero/pull/6992
23:09:46 <selsta> .merge+ 6992
23:09:46 <xmr-pr> Added
23:10:24 <moneromooo> done
23:10:43 <selsta> ok now the list is final
23:10:49 * selsta keeps forgetting about bumping version
23:11:03 <luigi1111w> double final
23:11:04 <luigi1111w> .merges
23:11:04 -xmr-pr- 6985 6990 6991 6992
23:12:46 <selsta> moneromooo: please reapprove
23:12:51 * selsta runs
23:13:54 <moneromooo> Hmm. I don't know... How about 3 instead ?
23:14:06 <moneromooo> (done)
23:14:15 <selsta> triple final now
23:16:01 <selsta> luigi1111w: but don’t tag yet
23:16:08 -xmr-pr- selsta opened pull request #6992: build: prepare v0.17.1.2
23:16:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6992
23:18:35 <selsta> moneromooo: can you test https://github.com/monero-project/monero/pull/6990 with a freshly deleted p2pstate ?
23:18:47 <selsta> second time this happened now
23:18:56 <selsta> it does not find any peers
23:19:10 <selsta> vtnerd: ping also
23:19:51 <moneromooo> OK, will be a bit.
23:20:06 <luigi1111w> 6991 conflicts
23:20:17 <selsta> https://www.irccloud.com/pastebin/uh6ML9OD/
23:21:32 <moneromooo> fixed
23:26:02 <selsta> moneromooo: this is with tor / i2p seed nodes merged, in case it makes a difference in testing
23:26:20 <selsta> so basically release-v0.17 branch
23:33:58 <luigi1111w> .merges
23:33:58 -xmr-pr- 6991 6992
23:34:43 <selsta> luigi1111w: so tag has to wait until mooo looked into this issue, but yea do merge the remaining gui PRs in the meantime
23:34:58 <luigi1111w> ok tag up
23:35:05 <selsta> ok lol
23:35:11 <luigi1111w> (haha kidding)
23:35:20 <selsta> don’t troll me :D
23:35:45 <selsta> can someone give vtnerd voice?
23:39:41 <vtnerd> ok, I ran a quick test with a fresh data directory and it still connects to seed nodes
23:39:57 <vtnerd> was the issue seen with tor/i2p ?
23:40:01 <selsta> no
23:40:07 <selsta> normal seed nodes
23:40:29 <selsta> try the release-v0.17 branch
23:40:34 <vtnerd> I did
23:41:02 <vtnerd> it started downloading mainnet blocks
23:41:15 <selsta> I still have the daemon open and print_cn returns nothing
23:41:44 <selsta> maybe try a couple times?
23:42:24 <moneromooo> 2020-11-06 23:42:04.111	E Exception at server worker thread, what=map::at
23:42:32 <moneromooo> That kills the thread, no more attempts to connect.
23:42:47 <selsta> ok I’m not imagining things :D
23:42:58 <moneromooo> Unless you just imagined what I typed...
23:43:14 <vtnerd> I just moved the default ~/.bitmonero directory too in case it picked that up through some bug, and it still started connecting+downloading
23:44:58 <moneromooo> It did so a few times here, and borked twice.
23:50:38 <moneromooo> https://paste.debian.net/hidden/489093b7/
23:52:15 <moneromooo> Maybe an invalid seed node address ?
23:53:18 <selsta> two are offline currently according to https://community.xmr.to/xmr-seed-nodes
23:54:39 <vtnerd> hmmm, if a seed node for the wrong zone ends up in a different m_peerlist it should bjork I think
23:54:49 <selsta> gingeropolous: these are your seed nodes ^^
23:54:52 <vtnerd> so `.onion` in the `ipv4.m_peerlist`
23:54:52 <selsta> can you take a look?
23:56:35 <vtnerd> if you were using one of your patches with tor/i2p seed nodes you cannot put in the same list
23:57:25 <selsta> vtnerd: so this is incorrect? https://github.com/monero-project/monero/pull/6985/files
23:57:28 <selsta> how else should we add them
23:57:43 <vtnerd> where the ipv4 seeds go. it was easier to have them completely separate. we might need extra checks that don't hit a hard error in there, buts likely the cause (a tor/i2p seed being loaded into the ipv4 list without enabliong tor/i2p)
23:57:59 <moneromooo> Is s3l6ke4ed3df466khuebb4poienoingwof7oxtbo6j4n56sghe3a.b32.i2p:18080 a valid I2P address ?
23:58:08 <moneromooo> I don't know how to tell :)
23:58:23 <vtnerd> yeah the function is called get_ip_seed_nodes() now
23:58:35 <moneromooo> And I don't have i2p setup here, and it's trying to connect to it.
23:58:53 <vtnerd> get_seed_nodes() is what you want to poke at
23:59:17 <vtnerd> it was funky, but thing was we didn't want to ranomdly select from i2p/tor peers when randomly selecting an ipv4 node
23:59:50 <vtnerd> I could've done a filter from a master list, but it seemed just as easy to put them in distinct spots. Perhaps this was the worse approach?