03:50:35 <vtnerd> moneromooo , others ? : should an unrestricted monero-daemon rpc list all txes, even those in the stem phase?
03:51:30 <vtnerd> currently thats the blocker for the test, and my only hack left is running multiple daemons in the functional test (txpool in particular) to simulate stem->fluff
03:51:57 <vtnerd> that test arguably should be added anyway
10:58:17 <moneromooo> vtnerd: I'd say all of them.
15:48:38 <binaryFate> Anyone has experience about the Chinese firewall wrt. Hong-Kong IPs? https://github.com/monero-project/monero/issues/6422
21:14:26 <vtnerd> hmm, so if multiple wallet owners are accessing a single unrestricted rpc, is that considered a misconfiguration?
21:15:17 <vtnerd> I suppose it is, but it would be nice if things could automagically do what every daemon/wallet owner expects/wants. unrealistic I guess
21:19:32 <moneromooo> That should work fine. The functional tests do that.
21:20:13 <vtnerd> do what?
21:21:23 <moneromooo> Accessing a single unrestricted (daemon) RPC from multiple wallets.
21:22:18 <moneromooo> I think I did not get your point.
21:22:50 <vtnerd> I meant if an unrestricted rpc returns txes in the stem phase, someone who is accessing a friends daemon via an unrestricted rpc can "see" their friends txes and vice-versa
21:23:08 <vtnerd> its very brief mind you, and arguably is less of a concern since most open relays _should_ be restricted
21:23:36 <moneromooo> Well, that's the point of restricted. It currently does that with local rpc txes AFAIK.
21:24:21 <vtnerd> thats what I mean, I'm probably trying to hard to ensure the daemon is setup as the user intends, but that is always going to be impossible to some extent
21:24:35 <vtnerd> plus if the advice is always "run your own node for privacy", it cuts down most of this stuff
21:24:59 <moneromooo> If you're worried someone might set unrestricted access by mistake, they'll find out soon since their computer wlil be mining for whoever finds it.
21:25:08 <vtnerd> yeah good point
21:25:37 <vtnerd> Ill issue a separate PR to fix this issue, with the dandelion++ as the first commit in the PR. the changes are worth a separate PR to verify
21:26:04 <vtnerd> at least that way we can verify the tests are "green", and then have an immediate fix already in the PR queue
21:28:43 <moneromooo> Did you not add a "confirm bind to external" error by default anyway ?
21:30:09 <moneromooo> Ah, it does not mention --restricted-rpc. Maybe it should.
21:30:22 <vtnerd> yeah it warns by default if listening to external connections
21:30:28 <vtnerd> yeah I'll add that in the PR then