because one thing that was funky was how things "fell back to" dns seeds

we didnt want to do with that i2p/tor

or no sorry dns seeds are the primary I think

thats why I did it like that

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)

moneromooo: it should be correct, it did find i2p peers with this format

I'm running with paste.debian.net/hidden/34f90182 atm, seems good.

Safer too.

.merge+ 6993

Added

it takes a couple minutes until first tor peers show up but seems to work

also no more issues with clearnet peers

moneromooo: if you want to setup i2p with inbound at some point: github.com/i2p-zero/i2p-zero/blob/master/mipseed.md

Thanks.

I keep meaning to do it later :)

it only takes 5 mins :P

Cool, I'll do it later hten :P

but it seems less stable than tor overall

luigi1111w: ok 6993 and then tag

for real this time™

how many confirms

lol

I'm sure something is missing but we will only find out once you tag

luigi1111w: ping me once you tagged, I also have to update the gui submodule

catch-22

it's up

selsta: ping ^^

ty i saw it

mine agree

just started a build

and still no outbound tor connections. but I still see the node ID of the last outbound tor peer I had, on an inbound

so for whatever reason, that direction seems to be preferred

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

hyc: did you ever try without anonymous-inbound ?

e.g. how stable out connections are then

.merge+ 6747 6826 6829 6830 6849 6856 6858 6873 6892 6895 6898 6903 6913 6915 6920 6921 6922 6924

Added

not sure if the tor / i2p seed node code works, at least it does not break anything clearnet related

but I only managed to connect to a tor peer once out of various tries

ok got it working twice now, seems random

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,

nioc: ^^

ah, haven't tried without inbound yet

ok. with that, my tor priority node is connected (outbound)

I see several i2p handshake attempts but so far none of stayed open

... and just lost my tor out again

they don’t last longer than 5 minutes or so

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)

yea I have that too often

also Closed 1 streams for service [scrubbed].onion for reason resolve failed. Fetch status: No more HSDir available to query

so it sounds like it's not a problem on the initiator's end

something not working on the destination

or within the tor network itself

also getting these every 3-5 seconds

Nov 6 23:01:29 highlandsun Tor[12437]: Invalid onion hostname [scrubbed]; rejecting

continuous stream of those

I don't see these

I assume someone is trying to resolve an onion address it doesn't like

mebbe I should turn off safelogging, to see what this offending address is

hmph. it's the address I put as a priority node

which I copied from mooo's tor script PR

these two are mine ^

might want to try if you get the same message there

cool

same error for xwvz3ekocr3dkyxfkmgm2hvbpzx2ysqmaxgter7znnqrhoicygkfswid.onion:18083

now I got a msg that my tor client is out of date

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

hmm this also looks like a bug, I have 5 out connections but it writes "Unable to send transaction(s), no available connections"

hmm I might know why, I had both tor and i2p enabled

and no i2p connections

yep removing i2p solved it

outbound was preferred for i2p/tor because in the reverse direction a fixed identity is possibly known via the hidden service address

I made a comment on that patch from earlier, all you did was suppress the error, when the more question was the origin

vtnerd: "Tor/I2P seeds are still in the incorrect location"

can you comment how it is supposed to look?

in fact one of the purposes of the `.at` was to identify stuff like that

I stated this earlier, theres a a function `get_seed_nodes()` with a switch for i2p and tor now

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

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

I suppose I could've added calls to that list then "filtered" out nodes for the wrong network

you put the seeds in that function

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

ok

selsta, thanks. turns out 66.85.74.134:18080 is not responsive to ssh

would you prefer a new tag? or is the code we have now not dangerous and we can fix it in the next release?

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

so i dunno why its not showing up as working

the other one showed up again afaik

hmm not sure, it is red

this one ( 104.238.221.81:18080 ) is running the latest patches

66.85 is not

i am getting ERRORS in the log

what kind of errors?

dunno why that would effect the p2p port though

net

lemme pastdump

im not gonna figure out the 66.85 problem tonight :(

do you run the block list on 104.238.221.81 ?

or do you have them blocked using firewall?

not blocked. i assumed the new patches did the things that need doing

no

hmm

which log level are you running?

1

so default or did you add --log-level 1 ? not sure what default is

i added log-level=1

i think default is 0

can you do "set_log 2"

save some logs

and then do set_log 1 again

thats 500 lines

ok then save gui.xmr.pm/files/block.txt somewhere on your disk and restart the daemon with --ban-list /path/to/list

aight, that nodes i son the list again

ok, looks like I just needed a newer tor binary. no more Invalid onion hostname messages

any changes to dropped peers for you?

without --anonymous-inbound it seems like I constantly have out peers

but with anonymous-inbound I have a lot of inbound peers but most of the time 0-2 out peers

Im wondering if latency is causing the connection issues - timeouts are almostly certainly set too low

5 seconds for handshake and 2 seconds for ping

I have tor out peers now, so yes that's improved

and I've turned on anonymous inbound again, both in and out seem to be present

vtnerd: are these timeouts for i2p / tor only?

if yes we can try increasing them a bit

wait I was probably wrong about that, I'd have to look at the code again to see relevant timeouts

ah now I see why I didn’t understand your seed node comment, I looked into master branch

yes, master doesn't have any of that merge

d

yep, makes sense now

I saw it pull some nodes through the seed nodes, so it should work (hopefully)

*pull some non-seed nodes through a seed node

it did not work for me hmm

had the previous issue again

it worked after a restart

unfortunately your p2pstate may have tor and/or i2p addresses in the ip peerlist section from previous runs

this was with fresh p2pstate

will try again

ok it worked the other tries now

vtnerd: okay seems good, maybe I was too impatient

yea ideally we would tag v0.17.1.3, though a bit annoying for those who did reproducible builds

vtnerd: how much privacy do you lose when running tx-proxy with disable_noise?

instead of without disable_noise

one annoying thing about the implementation is that it tries to make a full-set of ip connections before moving onto tor or i2p

its difficult to quantify how much privacy you lose. an attack with it disabled would be pretty advanced but plausible

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

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

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

the thing thats difficult is that an isp can still see incoming/outgoing bytes at all times

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

ive been writing a proposal for that to go into a github issue for discussion since there are a couple of things to consider

Do we need to retag/bump for 6994?

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

im building the tag now

TLS makes a channel private, but it doesn't make the existence of that channel secret.

noise is probably the only safe route.

dEBRUYNE: I would prefer so, we can also include 6995 and have an additional crash fix

xiphon: can you also open 6995 against branch?

Let's include those two PRs and tag .3 then

.merge+ 6994 6996

Added

monero-project/monero #6996 needs a second review, then we can tag v0.17.1.3

.merge+ 6997

Added

.merges

hmm

luigi1111: 6994 6996 6997 and then tag v0.17.1.3 please

selsta done

luigi1111w: ty now also gui, the remaining 2 PRs and tag

done

binaryFate: will have binaries ready tomorrow, do you have time to upload them to the website?

ok, starting a v0.17.1.3 ...

same hashes

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)

so it seems the issue seems to show up with anonymous-inbound due to the daemon preferring inbound over outbound

same hashes here too

<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