freenode #monero-dev

8 Apr 2020

Official repo: github.com/monero-project/monero || Don’t ask to ask, just ask:) || Non-dev questions -> #monero, please || Next dev meeting is detailed on the Monero meeting issue on Github: github.com/monero-project/meta/issues

• 03:50
  vtnerd
  moneromooo , others ? : should an unrestricted monero-daemon rpc list all txes, even those in the stem phase?
• 03:51
  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
  vtnerd
  that test arguably should be added anyway
• 10:58
  moneromooo
  vtnerd: I'd say all of them.
• 15:48
  binaryFate
  Anyone has experience about the Chinese firewall wrt. Hong-Kong IPs? monero-project/monero #6422
• 21:14
  vtnerd
  hmm, so if multiple wallet owners are accessing a single unrestricted rpc, is that considered a misconfiguration?
• 21:15
  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
  moneromooo
  That should work fine. The functional tests do that.
• 21:20
  vtnerd
  do what?
• 21:21
  moneromooo
  Accessing a single unrestricted (daemon) RPC from multiple wallets.
• 21:22
  moneromooo
  I think I did not get your point.
• 21:22
  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
  vtnerd
  its very brief mind you, and arguably is less of a concern since most open relays _should_ be restricted
• 21:23
  moneromooo
  Well, that's the point of restricted. It currently does that with local rpc txes AFAIK.
• 21:24
  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
  vtnerd
  plus if the advice is always "run your own node for privacy", it cuts down most of this stuff
• 21:24
  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
  vtnerd
  yeah good point
• 21:25
  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
  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
  moneromooo
  Did you not add a "confirm bind to external" error by default anyway ?
• 21:30
  moneromooo
  Ah, it does not mention --restricted-rpc. Maybe it should.
• 21:30
  vtnerd
  yeah it warns by default if listening to external connections
• 21:30
  vtnerd
  yeah I'll add that in the PR then