00:01:01 <vtnerd> because one thing that was funky was how things "fell back to" dns seeds
00:01:06 <vtnerd> we didnt want to do with that i2p/tor
00:01:42 <vtnerd> or no sorry dns seeds are the primary I think
00:01:47 <vtnerd> thats why I did it like that
00:03:01 <vtnerd> I have to run for a bit, but it should be a matter of moving those seeds from `get_ip_seed_nodes()` to `get_seed_nodes()` (or to a function that `get_seed_nodes()` calls, etc)
00:10:29 <selsta> moneromooo: it should be correct, it did find i2p peers with this format
00:17:15 <moneromooo> I'm running with https://paste.debian.net/hidden/34f90182/ atm, seems good.
00:17:21 <moneromooo> Safer too.
00:21:46 * selsta testing
00:29:36 <selsta> .merge+ 6993
00:29:37 <xmr-pr> Added
00:31:08 -xmr-pr- moneromooo-monero opened pull request #6993: p2p: fix accessing non existent element of map
00:31:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6993
00:32:15 <selsta> it takes a couple minutes until first tor peers show up but seems to work
00:33:09 <selsta> also no more issues with clearnet peers
00:34:20 <selsta> moneromooo: if you want to setup i2p with inbound at some point: https://github.com/i2p-zero/i2p-zero/blob/master/mipseed.md
00:34:48 <moneromooo> Thanks.
00:34:56 <moneromooo> I keep meaning to do it later :)
00:35:03 <selsta> it only takes 5 mins :P
00:35:14 <moneromooo> Cool, I'll do it later hten :P
00:35:17 <selsta> but it seems less stable than tor overall
00:48:21 <selsta> luigi1111w: ok 6993 and then tag
00:48:24 <selsta> for real this time™
00:52:30 <luigi1111w> how many confirms
00:56:24 <selsta> lol
00:56:43 <selsta> I'm sure something is missing but we will only find out once you tag
01:01:33 <selsta> luigi1111w: ping me once you tagged, I also have to update the gui submodule
01:02:05 <luigi1111w> catch-22
01:02:55 <luigi1111w> it's up
01:09:38 <nioc> selsta: ping ^^
01:10:08 <selsta> ty i saw it
02:25:24 <iDunk> https://paste.debian.net/hidden/3c5fb377/
02:27:39 <scoobybejesus> mine agree
02:48:21 <hyc> just started a build
02:49:11 <hyc> and still no outbound tor connections. but I still see the node ID of the last outbound tor peer I had, on an inbound
02:49:31 <hyc> so for whatever reason, that direction seems to be preferred
02:50:37 <hyc> if this is going to be a normal thing now, where two peers always settle into a single direction, that's going to be problematic
02:57:03 <selsta> hyc: did you ever try without anonymous-inbound ?
02:57:10 <selsta> e.g. how stable out connections are then
03:26:21 <selsta> .merge+ 6747 6826 6829 6830 6849 6856 6858 6873 6892 6895 6898 6903 6913 6915 6920 6921 6922 6924
03:26:21 <xmr-pr> Added
03:27:46 <selsta> not sure if the tor / i2p seed node code works, at least it does not break anything clearnet related
03:29:51 <selsta> but I only managed to connect to a tor peer once out of various tries
03:37:47 <selsta> ok got it working twice now, seems random
03:39:47 <selsta> nice starting the daemon with --tx-proxy tor,127.0.0.1:9050,disable_noise means transactions show up almost instantly in the mempool like pre dandelion,
03:39:52 <selsta> nioc: ^^
03:43:06 <hyc> ah, haven't tried without inbound yet
03:47:47 <hyc> ok. with that, my tor priority node is connected (outbound)
03:48:00 <hyc> I see several i2p handshake attempts but so far none of stayed open
03:48:18 <hyc> ... and just lost my tor out again
03:51:52 <selsta> they don’t last longer than 5 minutes or so
03:52:48 <hyc> Nov  6 22:50:55 highlandsun Tor[12437]: Tried for 120 seconds to get a connection to [scrubbed]:28083. Giving up. (waiting for rendezvous desc)
03:53:30 <selsta> yea I have that too often
03:53:32 <selsta> also Closed 1 streams for service [scrubbed].onion for reason resolve failed. Fetch status: No more HSDir available to query
03:54:57 <hyc> so it sounds like it's not a problem on the initiator's end
03:55:07 <hyc> something not working on the destination
03:55:29 <hyc> or within the tor network itself
04:01:45 <hyc> also getting these every 3-5 seconds
04:01:46 <hyc> Nov  6 23:01:29 highlandsun Tor[12437]: Invalid onion hostname [scrubbed]; rejecting
04:01:54 <hyc> continuous stream of those
04:02:06 <selsta> I don't see these
04:02:39 <hyc> I assume someone is trying to resolve an onion address it doesn't like
04:03:29 <hyc> mebbe I should turn off safelogging, to see what this offending address is
04:06:28 <hyc> hmph. it's the address I put as a priority node
04:06:35 <hyc> which I copied from mooo's tor script PR
04:07:17 <selsta> https://github.com/monero-project/monero/pull/6984/files
04:07:21 <selsta> these two are mine ^
04:07:32 <selsta> might want to try if you get the same message there
04:08:05 <hyc> cool
04:10:53 <hyc> same error for xwvz3ekocr3dkyxfkmgm2hvbpzx2ysqmaxgter7znnqrhoicygkfswid.onion:18083
04:11:08 <hyc> now I got a msg that my tor client is out of date
04:11:37 <hyc> Nov  6 23:10:06 highlandsun Tor[17514]: At least one protocol listed as recommended in the consensus is not supported by this version of Tor. You should upgrade. This version of Tor will eventually stop working as a client on the Tor network. The missing protocols are: Link=5
04:12:35 <selsta> https://www.irccloud.com/pastebin/YSo8hrRz/
04:12:56 <selsta> hmm this also looks like a bug, I have 5 out connections but it writes "Unable to send transaction(s), no available connections"
04:19:29 <selsta> hmm I might know why, I had both tor and i2p enabled
04:19:35 <selsta> and no i2p connections
04:26:19 <selsta> yep removing i2p solved it
04:31:10 <vtnerd> outbound was preferred for i2p/tor because in the reverse direction a fixed identity is possibly known via the hidden service address
04:35:11 <vtnerd> I made a comment on that patch from earlier, all you did was suppress the error, when the more question was the origin
04:35:11 <selsta> vtnerd: "Tor/I2P seeds are still in the incorrect location"
04:35:44 <selsta> can you comment how it is supposed to look?
04:35:57 <vtnerd> in fact one of the purposes of the `.at` was to identify stuff like that
04:36:14 <vtnerd> I stated this earlier, theres a a function `get_seed_nodes()` with a switch for i2p and tor now
04:36:51 <vtnerd> I did this because the existing code tried dns seed first before trying hard-coded ip addresses. this isn't desireable for i2p/tor connections so it jumps to another list
04:37:21 <selsta> yes but they are inside `std::set<std::string> node_server<t_payload_net_handler>::get_seed_nodes(cryptonote::network_type nettype) const` function so I did not understand your comment
04:37:23 <vtnerd> I suppose I could've added calls to that list then "filtered" out nodes for the wrong network
04:37:55 <vtnerd> you put the seeds in that function
04:39:28 <vtnerd> like, the `.at` throw was intended to catch the existing error that just happened and now its ghosted, I'll just submit a pr in a second I guess to show you what I mean
04:39:38 <selsta> ok
04:40:09 <gingeropolous> selsta, thanks. turns out 66.85.74.134:18080 is not responsive to ssh
04:40:15 <selsta> would you prefer a new tag? or is the code we have now not dangerous and we can fix it in the next release?
04:40:46 <gingeropolous> and the other is Height: 2225120/2225120 (100.0%) on mainnet, not mining, net hash 1.64 GH/s, v14, 246(out)+27(in) connections, uptime 1d 6h 18m 46s
04:40:59 <gingeropolous> so i dunno why its not showing up as working
04:41:16 <selsta> the other one showed up again afaik
04:41:50 <selsta> hmm not sure, it is red
04:42:20 <gingeropolous> this one ( 104.238.221.81:18080 )  is running the latest patches
04:42:26 <gingeropolous> 66.85 is not
04:43:19 <gingeropolous> i am getting ERRORS in the log
04:43:43 <selsta> what kind of errors?
04:43:45 <gingeropolous> dunno why that would effect the p2p port though
04:44:16 <gingeropolous> net
04:44:19 <gingeropolous> lemme pastdump
04:45:11 <gingeropolous> https://paste.debian.net/hidden/63a33143/
04:45:26 <gingeropolous> im not gonna figure out the 66.85 problem tonight :(
04:45:58 <selsta> do you run the block list on 104.238.221.81 ?
04:46:05 <selsta> or do you have them blocked using firewall?
04:46:54 <gingeropolous> not blocked. i assumed the new patches did the things that need doing
04:47:09 <selsta> no
04:47:20 <selsta> hmm
04:47:46 <selsta> which log level are you running?
04:48:51 <gingeropolous> 1
04:49:24 <selsta> so default or did you add --log-level 1 ? not sure what default is
04:50:25 <gingeropolous> i added log-level=1
04:50:30 <gingeropolous> i think default is 0
04:54:59 <selsta> can you do "set_log 2"
04:55:06 <selsta> save some logs
04:55:11 <selsta> and then do set_log 1 again
04:57:57 <gingeropolous> https://termbin.com/1jfw
04:58:00 <gingeropolous> thats 500 lines
04:59:27 <selsta> ok then save https://gui.xmr.pm/files/block.txt somewhere on your disk and restart the daemon with --ban-list /path/to/list
05:05:46 <gingeropolous> aight, that nodes i son the list again
05:41:59 <hyc> ok, looks like I just needed a newer tor binary. no more Invalid onion hostname messages
05:43:55 <selsta> any changes to dropped peers for you?
05:44:14 <selsta> without --anonymous-inbound it seems like I constantly have out peers
05:44:42 <selsta> but with anonymous-inbound I have a lot of inbound peers but most of the time 0-2 out peers
05:54:41 <vtnerd> Im wondering if latency is causing the connection issues - timeouts are almostly certainly set too low
05:54:50 <vtnerd> 5 seconds for handshake and 2 seconds for ping
05:57:59 <hyc> I have tor out peers now, so yes that's improved
05:58:18 <hyc> and I've turned on anonymous inbound again, both in and out seem to be present
06:00:08 <selsta> vtnerd: are these timeouts for i2p / tor only?
06:00:13 <selsta> if yes we can try increasing them a bit
06:01:08 -xmr-pr- vtnerd opened pull request #6994: Fix i2p/tor seed nodes [0.17]
06:01:09 -xmr-pr- > https://github.com/monero-project/monero/pull/6994
06:01:58 <vtnerd> wait I was probably wrong about that, I'd have to look at the code again to see relevant timeouts
06:02:20 <selsta> ah now I see why I didn’t understand your seed node comment, I looked into master branch
06:02:33 <vtnerd> yes, master doesn't have any of that merge
06:02:35 <vtnerd> d
06:02:40 <selsta> yep, makes sense now
06:03:33 <vtnerd> I saw it pull some nodes through the seed nodes, so it should work (hopefully)
06:03:50 <vtnerd> *pull some non-seed nodes through a seed node
06:05:35 <selsta> it did not work for me hmm
06:05:49 <selsta> had the previous issue again
06:07:20 <selsta> it worked after a restart
06:07:22 <vtnerd> unfortunately your p2pstate may have tor and/or i2p addresses in the ip peerlist section from previous runs
06:07:31 <selsta> this was with fresh p2pstate
06:08:22 <selsta> will try again
06:09:19 <selsta> ok it worked the other tries now
06:10:19 <selsta> vtnerd: okay seems good, maybe I was too impatient
06:15:26 <selsta> yea ideally we would tag v0.17.1.3, though a bit annoying for those who did reproducible builds
06:51:17 <selsta> vtnerd: how much privacy do you lose when running tx-proxy with disable_noise?
06:51:24 <selsta> instead of without disable_noise
07:05:23 <vtnerd> one annoying thing about the implementation is that it tries to make a full-set of ip connections before moving onto tor or i2p
07:06:01 <vtnerd> its difficult to quantify how much privacy you lose. an attack with it disabled would be pretty advanced but plausible
07:06:53 <vtnerd> I did a wireshark with a snapt of bandwidth usage over time - which I showed in my monerokon presentation (I need to put that on the web btw) - and the usage was not uniform
07:08:01 <vtnerd> you might be able to spot when a tx is outgoing, but again, its not dead-simple since its indirect through statistics of data over the privacy network
07:09:24 <vtnerd> if we allowed block syncing and broadcasting over tor/i2p it might help mask/noise the traffic, but it would be more "by chance" unfortunately
07:10:40 <vtnerd> the thing thats difficult is that an isp can still see incoming/outgoing bytes at all times
07:14:29 <vtnerd> this is the "long-tail" though - we probably need to encrypt ip traffic too. I partially regret rejecting moo's tls patch based on openssl sketchiness. our best options are probably tls 1.3 or noise_xk (or another noise option). the latter has some optimization benefits and has some formal verifications iirc
07:15:02 <vtnerd> ive been writing a proposal for that to go into a github issue for discussion since there are a couple of things to consider
08:32:24 <dEBRUYNE> Do we need to retag/bump for 6994?
12:15:52 <gingeropolous> im still gettin those errors: 2020-11-07 12:15:27.714	[P2P8]	ERROR	net	contrib/epee/include/net/abstract_tcp_server2.inl:765	Setting timer on a shut down object
12:17:54 <gingeropolous> im building the tag now
13:49:38 <hyc> TLS makes a channel private, but it doesn't make the existence of that channel secret.
13:49:44 <hyc> noise is probably the only safe route.
14:31:08 -xmr-pr- xiphon opened pull request #6995: epee: readline_buffer - fix thread safety, fix sync() after stop()
14:31:09 -xmr-pr- > https://github.com/monero-project/monero/pull/6995
14:56:44 <selsta> dEBRUYNE: I would prefer so, we can also include 6995 and have an additional crash fix
15:01:40 <selsta> xiphon: can you also open 6995 against branch?
15:43:30 <dEBRUYNE> Let's include those two PRs and tag .3 then
15:46:09 -xmr-pr- xiphon opened pull request #6996: [release-v0.17] epee: readline_buffer - fix thread safety, fix sync() ...
15:46:09 -xmr-pr- > https://github.com/monero-project/monero/pull/6996
17:12:59 <selsta> .merge+ 6994 6996
17:12:59 <xmr-pr> Added
17:25:09 <selsta> https://github.com/monero-project/monero/pull/6996 needs a second review, then we can tag v0.17.1.3
17:31:08 -xmr-pr- selsta opened pull request #6997: build: prepare v0.17.1.3
17:31:08 -xmr-pr- > https://github.com/monero-project/monero/pull/6997
17:53:05 <selsta> .merge+ 6997
17:53:05 <xmr-pr> Added
18:01:31 <selsta> .merges
18:01:31 -xmr-pr- 6747 6826 6829 6830 6849 6856 6858 6873 6892 6895 6898 6903 6913 6915 6920 6921 6922 6924 6994 6996 6997
18:01:36 <selsta> hmm
18:05:07 <selsta> luigi1111: 6994 6996 6997 and then tag v0.17.1.3 please
19:11:00 <luigi1111w> selsta done
19:12:26 <selsta> luigi1111w: ty now also gui, the remaining 2 PRs and tag
19:20:31 <luigi1111w> done
19:35:52 <selsta> binaryFate: will have binaries ready tomorrow, do you have time to upload them to the website?
20:31:52 <iDunk> https://paste.debian.net/hidden/b881a789/
20:35:14 <hyc> ok, starting a v0.17.1.3 ...
20:56:37 <scoobybejesus> same hashes
21:49:29 <selsta> running v0.17.1.3 for the last 12 hours and did not have a single "no outbound peers" message (this is with tor / i2p tx-proxy and without anonymous-inbound)
21:50:06 <selsta> so it seems the issue seems to show up with anonymous-inbound due to the daemon preferring inbound over outbound
23:09:46 <hyc> same hashes here too
23:34:39 <binaryFate> <selsta> binaryFate: will have binaries ready tomorrow, do you have time to upload them to the website? <-- sure, might be afk 1h or 2 at some point but otherwise can do when ready