<p​reland:monero.social> Are peer lists saved between monerod sessions? If so, where?

<p​reland:monero.social> Never mind I figured it out

<p​reland:monero.social> Is there a reason why tx-proxy has to be specified even when proxy is specified?

<p​reland:monero.social> I mean that monerod simply will not run if you only specify proxy once, but if you specify tx-proxy with the same address and port it is completely fine afaik

<v​tnerd:monero.social> —proxy controls how to connect to public ip addresses. normal behavior is direct connect. —proxy behavior is to route everything through socks (typically to tor daemon)

<v​tnerd:monero.social> —tx-proxy controls how txes are sent to a hidden service node (or the i2p equivalent)

<v​tnerd:monero.social> its confusing because tor in particular has hidden services AND exit nodes. these are different things

<v​tnerd:monero.social> we should likely change it so connections can be made over hidden services, but haven’t done so. configuring this could be even more confusing than it already is

<p​reland:monero.social> Now, I would’ve normally accepted this as fair

<p​reland:monero.social> Though today I found out that you can just straight up set .b32 addresses directly in bootstrap and set —proxy to the correct local port and everything just….works? It’s slow, but it works flawlessly other than that

<p​reland:monero.social> The *only* thing that seems broken is using the “auto” setting to find i2p nodes

<p​reland:monero.social> I thought the issue would be finding the nodes, but that was as simple as nabbing one of the hardcoded i2p addresses and manually setting it as a seednode to get some starters. What was the actual issue is that none of the addresses found using discovery worked even slightly; not one out of over 80+ nodes discovered. Using nodes from monero.fail inputted manually worked like a cha<clipped message>

<p​reland:monero.social> rm, but any I2P node discovered naturally would fail. What confounds things even more is that not a single node listed on Monero.fail seems to be added in the peerlist.

<p​reland:monero.social> I’m still crossing my fingers that I won’t have to change anything in monerod, but unless something changes after I sleep on it I’ll probably have to cross that bridge

<p​reland:monero.social> (Although admittedly I may end up fixing things upstream even if I don’t technically have to; the current system still attempts to use any clearnet hosts in the peerlist if it can find any)

<p​reland:monero.social> One more thing: *if* I can get this working, I will definitely need to go through the information currently sent through the P2P protocol to make sure there isn’t any identifying information sent over it. Using strace doesn’t appear to show anything glaringly bad (like ip addresses), but it is a concern since 1. I2P doesn’t (and realistically can’t) sanitize SOCKS packets <clipped message>

<p​reland:monero.social> for identifying information, and 2. afaik these packets were never directly intended to obscure the identity of the sending node (citation needed)

<a​ntilt:we2.ee> vtnerd's valid point was, we dont want ppl to use a tor exit node, when they actually try to use a hidden service inside the tor network. Big difference.

<o​frnxmr:xmr.mx> No.. try sending a tx..

<o​frnxmr:xmr.mx> ... wow. Lol.

<o​frnxmr:xmr.mx> Theres so much wrong about what yoy said, idek where to start ...

<o​frnxmr:xmr.mx> preland @preland:monero.social .. p2p != rpc

<o​frnxmr:xmr.mx> anonymous-inbound is counterparty to tx-proxy. It != normal p2p

<o​frnxmr:xmr.mx> Bootstrap is rpc. Monero.fail is rpc. Nodes "discovered naturally" are anonymous-inbound.

<o​frnxmr:xmr.mx> Your "just worked" is essentially running gui with "simple mode". = bootstrapping rpc and `no-sync`ing the daemon(blockchain)

<v​tnerd:monero.social> as per the Boost crash - I went through the changes again. The ASIO bug previously referenced is reasonably high the culprit, but I haven’t done a direct test for this

<p​reland:monero.social> I did, and it worked perfectly

<v​tnerd:monero.social> basically I had to change from deprecated interface, and one of the changes was from `iter == end_iter` to `results.empty()`. So thats why it triggers after that patch

<v​tnerd:monero.social> The non-check cases in TCP server are possibly a red-herring (as I’ve stated), because its basically using the same structure as before

<o​frnxmr:xmr.mx> I sent this before reading that youre using tx-proxy

<p​reland:monero.social> Ah wait. Does the current peer list discovery assume that the rpc port is on the same ip as the P2P service

<o​frnxmr:xmr.mx> No

<o​frnxmr:xmr.mx> --public-node is where the bootstrap discovery comes from

<o​frnxmr:xmr.mx> And --public-node has no knowledge of onion/i2p rpc

<o​frnxmr:xmr.mx> Erm. No was like "no, xmyproblem.info, youre coming at this in the wrong direction"

<p​reland:monero.social> So even though it can find P2P addresses for I2P nodes, it can’t find the rpc address?

<o​frnxmr:xmr.mx> Peer list discovery comes from tx-proxy for hidden services, and clearnet 18080 for clearnet

<p​reland:monero.social> Oh ok

<o​frnxmr:xmr.mx> Monerod has no knowledge of hidden service rpc.

jeffro256: 9135 fails the p2p test in CI, can you check if you notice something?w

we had this before in master but monero-project/monero #9796 fixed it, it's now showing up again with 9135

<v​tnerd:monero.social> selsta: Im only on mobile, so it's hard for me to check but I think jeffros patch hasn't been rebased since that change got merged

yes i'm not sure if github action rebases automatically or not

<o​frnxmr:xmr.mx> It doesn't

<o​frnxmr:xmr.mx> the pr actions are build the pr as-is, so jeffro256 would have to rebase to pull in the latest changes

<j​effro256:monero.social> I thought it runs the tests as if it was merged into master, could definitely be wrong tho

<j​effro256:monero.social> I also touch the p2p functional tests in that PR and might have re-introduced the bug into the tests

<o​frnxmr:xmr.mx> it runs the tests as they are in the branch that you push from

<o​frnxmr:xmr.mx> I thought it would use the upstream workflows, but i dont think it does.. at least not in my experience on other repos

it depends on how the checkout action is setup

Should I just rebase #9135 with the p2p test fix commit pulled in to remove doubt ?

HEAD is now at 3d68522 Merge 064b3c76e405db3c39397b26b67ed02da8ae2bb4 into 0232839913b13cf0ab0bb7ad25fff0c05f37d2fe

it merges it into the master / release branch so rebasing should not be necessary