moneromooo: could you close 6987?

.merges

what's up

luigi1111w: guiii merges

yes but does that help :)

also 6983

help how

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

in this release*

.msrges

.merges

Merge queue empty

should we put #6948 into 0.17? seems pretty useful

hmmm. I started with --add-priority-node zbjkbsxc5munw3qusl7j2hpcmikhqocdf4pqhnhtpzw5nt5jrmofptid.onion:18083 and I have no outbound tor peers again

it was definitely connected when I started up

but definitely gone now, and not present in print_pl output either

We can include it if someone reviews it

.merges

Merge queue empty

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

I found Tor more stable but that might be due to more Tor nodes

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

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?

Lyza: did you try with both Tor and I2P?

nah I've never set up tor for my node, it's i2p only

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

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

I'm sure having more peers to rotate between is better for privacy though

anyone know how to get from an i2pd private.dat to the keypair used in i2p-zero's tunnels.json ?

looks like keyinfo just gives me one of the 2 keys

hmm. I had out and in tor connection to same node ID

then the out connection dropped

and now I have no out tor connections

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 github.com/i2p-zero/i2p-zero/blob/m…ro/i2p/zero/TunnelControl.java#L450

thanks

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

hyc i use the i2p java base64 encoder/decoder library net.i2p.data.Base64

so i use their code to do the encoding, not mine

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.

ah I see.

createDestination writes out destination,privatekey,signingprivatekey

and d.writeBytes writes out pubkey+signingPubkey

you're writing the destination info twice

that is, what you're writing as "seckey" is actually both sec+pubkey already. and then you write pubkey again.

.merges

Merge queue empty

selsta plan is what

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

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

ok. and looks like I was wrong about the padding discrepancy

the private.dat file has 4 extra bytes on the pubkey, so its base64 output needed padding

you must have a vanity address you're really proud of :)

lol it took all day yesterday to find :P

haha

and now I'm spending all day today to figure out how to use it !!

yeah waiting for i2p warmup isn't fun

luigi1111w: Think 6985 and 6990 and then tag

^ selsta, moneromooo: please confirm

ok I have 2 outbound i2p connections now. again, had my initial outbound tor connection too but it's dropped already

I could also add my tor seed node. It's going to conflict with selsta's PR so will have to be rebased.

6897 (minus the moot one)

wait, no, wrong one

6874

And now 6991 for the branch.

dEBRUYNE: and 6991 yes

Perhaps we can tag tonight?

Would probably be easier for the maintainers if 6991 was added to selsta's PR, right?

should not take long to rebase

ok luigi1111w please merge 6985 and 6990

or wait, merge 6990 and 6991, then I will rebase 6985

.merge+ 6990 6991 6985

Added

I can rebase too, no bother.

should I add #6948 to 0.17 branch?

I would be okay with including it but someone has to review it

though PR does not look too big

fairly trivial PR, yes

but I didn't see it still needed review. never mind, if there's no time for reviews

I wonder if tor and i2p themselves have idle timeouts, and that's why the connections keep dropping

all of my i2p and tor out conns are gone now

still have several tor inbound

my i2p connections drop often but tor seem more stable

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

either that or the long-lived incoming connections have silently idled out or something

monerod sometimes lists connections that don't exist.

90% confidence maybe.

There's a longstanding but about this.

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

is it bad enough that you think maybe none of those 4 inc connections actually exist?

No.

It is rare AFAIK.

Though who knows, maybe tor/i2p trigger this easier.

yeah could be

.merges

if this is the final list, I'll merge and tag tonight yet

please quadruple confirm

Looks right.

3 more confirms required :)

yes

final

hmm

not final merge list

have to do one more PR

please review monero-project/monero #6992

.merge+ 6992

Added

done

ok now the list is final

double final

.merges

moneromooo: please reapprove

Hmm. I don't know... How about 3 instead ?

(done)

triple final now

luigi1111w: but don’t tag yet

moneromooo: can you test monero-project/monero #6990 with a freshly deleted p2pstate ?

second time this happened now

it does not find any peers

vtnerd: ping also

OK, will be a bit.

6991 conflicts

fixed

moneromooo: this is with tor / i2p seed nodes merged, in case it makes a difference in testing

so basically release-v0.17 branch

.merges

luigi1111w: so tag has to wait until mooo looked into this issue, but yea do merge the remaining gui PRs in the meantime

ok tag up

ok lol

(haha kidding)

don’t troll me :D

can someone give vtnerd voice?

ok, I ran a quick test with a fresh data directory and it still connects to seed nodes

was the issue seen with tor/i2p ?

no

normal seed nodes

try the release-v0.17 branch

I did

it started downloading mainnet blocks

I still have the daemon open and print_cn returns nothing

maybe try a couple times?

2020-11-06 23:42:04.111 E Exception at server worker thread, what=map::at

That kills the thread, no more attempts to connect.

ok I’m not imagining things :D

Unless you just imagined what I typed...

I just moved the default ~/.bitmonero directory too in case it picked that up through some bug, and it still started connecting+downloading

It did so a few times here, and borked twice.

Maybe an invalid seed node address ?

two are offline currently according to community.xmr.to/xmr-seed-nodes

hmmm, if a seed node for the wrong zone ends up in a different m_peerlist it should bjork I think

gingeropolous: these are your seed nodes ^^

so `.onion` in the `ipv4.m_peerlist`

can you take a look?

if you were using one of your patches with tor/i2p seed nodes you cannot put in the same list

vtnerd: so this is incorrect? monero-project/monero #6985/files

how else should we add them

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)

Is s3l6ke4ed3df466khuebb4poienoingwof7oxtbo6j4n56sghe3a.b32.i2p:18080 a valid I2P address ?

I don't know how to tell :)

yeah the function is called get_ip_seed_nodes() now

And I don't have i2p setup here, and it's trying to connect to it.

get_seed_nodes() is what you want to poke at

it was funky, but thing was we didn't want to ranomdly select from i2p/tor peers when randomly selecting an ipv4 node

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?