04:19:03 <noobcake2465[m]> <selsta> "noobcake2465: did you check on..." <- i don't have multiple accounts no
04:19:39 <noobcake2465[m]> selsta: figured out where it went though.... 
04:19:44 <noobcake2465[m]> i sent it to my friend twice
04:21:12 <noobcake2465[m]> and yeah i think you're 100% right, the client crashed and didn't record the TX key
04:21:16 <noobcake2465[m]> or where i sent it
04:21:26 <noobcake2465[m]> he says:
04:21:26 <noobcake2465[m]> > sure enough, 8 hours after the first 1.75 XMR, I received another 1.75 😆
04:26:01 <Xair[m]> interesting
04:26:04 <Xair[m]> glad it got solved man!
04:26:11 <Xair[m]> hopefully it can get send back :)
04:26:29 <noobcake2465[m]> but i think your theory about not writing the TX key and address it was sent to straight away
04:26:33 <noobcake2465[m]> is exactly a what i would expect software to do
04:26:55 <Xair[m]> sadly what software should do and what users expect is generally at odds haha
04:27:06 <Xair[m]> makes UX design hard sometimes
04:27:21 <noobcake2465[m]> maybe, even if it it was cached to disk
04:27:26 <noobcake2465[m]> it should still sync some data to disk
04:27:34 <noobcake2465[m]> so that it can be recovered when reopened
04:27:40 <Xair[m]> yeah I think they suggested syncing it to disk immediately
04:27:44 <Xair[m]> to make this less of an issue
06:26:04 <noobcake2465[m]> should i lodge a bug?
06:27:40 <Xair[m]> I'm not sure
06:28:05 <Xair[m]> I don't think it's a bug per-say, but maybe opening an issue to discuss adding this functionality would be good
08:31:42 <selsta> noobcake2465[m]: ok, that's what I expected :)
12:06:22 <lightloved[m]> What's the right way to connect to a remote onion node with the CLI?
12:07:19 <lightloved[m]> ./monero-wallet-cli --proxy 127.0.0.1:9150 --daemon-host site.onion:port OR torsocks ./monero-wallet-cli --daemon-address site.onion:port?
12:08:17 <lightloved[m]> And what can be leaked considering a) you're not using Whonix/Tails as base OS and b) you don't own the remote node?
12:09:16 <lightloved[m]> I'm just evaluating if it's even worth it to torify the connection in the first place.
12:09:56 <lightloved[m]> This can be useful for people with threat models that include their ISP awareness of Monero at the top of the list. But they don't/can't use Whonix/Tails as base os.
12:10:02 <Xair[m]> do not use torsocks with the monero client
12:10:12 <Xair[m]> use the built in proxy code
12:10:13 <Xair[m]> it is far more reliable
12:10:45 <Xair[m]> the proxy code is configured to work over socks4/5 and will correctly connect to Tor for you
12:11:10 <Xair[m]> `./monero-wallet-cli --proxy 127.0.0.1:9150 --daemon-address <onion URL>` is the correct way to do that`
12:11:47 <Xair[m]> although `9150` is the default port for the node which the tor browser bundle runs, I would suggest you run a dedicated tor node for this, which will  use port 9050 instead :)
12:12:09 <Xair[m]>  * `./monero-wallet-cli --proxy 127.0.0.1:9150 --daemon-address <onion URL>` is the correct way to do that
12:14:21 <lightloved[m]> Xair[m]: How would one go about doing that?
12:14:38 <Xair[m]> on a linux distribution it is generally provided by the distro repos
12:14:46 <Xair[m]> you can install it the same way you usually install other software
12:15:14 <lightloved[m]> I already have tor on Debian and the 9050 port is used.
12:15:56 <lightloved[m]> I assume you'd want to use a different port so there's no overlap over the monero wallet and the browser, right?
12:16:39 <Xair[m]> mostly yes, the potential problems from doing that are kinda low... it doesn't have much of an impact on your traffic since tor routes each TCP flow independently anyway, but it's best practice to keep them separated just to be sure
12:17:03 <Xair[m]> if 9050 is used by the tor daemon running on debian, best to just use 9050 anyway
12:18:46 <lightloved[m]> What about all the warnings when connecting to the remote onion? Should I add the trusted daemon flag?
12:19:23 <lightloved[m]> Warning: using an untrusted daemon at <onion>
12:19:37 <lightloved[m]> Using your own without SSL exposes your RPC traffic to monitoring
12:19:43 <lightloved[m]>  * `Using your own without SSL exposes your RPC traffic to monitoring`
12:19:50 <lightloved[m]>  * `Warning: using an untrusted daemon at <onion>`
12:20:47 <Xair[m]> do not trust remote daemons
12:21:02 <Xair[m]> they are by nature untrusted unless you run a private daemon
12:21:32 <Xair[m]> the warning about RPC traffic being monitored is ok, since tor connections to onion addresses are end-to-end encrypted by default
12:21:54 <Xair[m]> so SSL is not required in this case, but it's good to keep in mind, especially if connecting to daemons on the regular web
12:22:16 <lightloved[m]> Oh so they kept it for "http" over clear net. Makes sense.
12:22:31 <Xair[m]> yeah pretty much :p
12:22:50 <Xair[m]> the monero wallet doesn't understand the difference between an onion address and a normal website since Tor handles all that behind the scenes
12:23:42 <lightloved[m]> I see `--trusted-daemon` allows some extra commands like `rescan_spent` and mining. I guess you should only use it with your own self hosted remote node daemon.
12:23:53 <Xair[m]> yes pretty much
12:24:01 <Xair[m]> using those on a random node exposes you to security risks
12:29:34 <lightloved[m]> So essentially this is a decent way of using the network to preserve middle-way privacy I guess (ISP threat model): normal OS (Debian) + cli wallet + proxy tor to remote onion. Am I close? I assume running your own remote node might enhance this a bit. 
12:30:09 <lightloved[m]> But assuming tor usage is more normal to your ISP vs monero usage, I see no other better way really.
12:30:41 <Xair[m]> well, yes, it depends on your specific threat model
12:30:59 <Xair[m]> but that is a decently private and secure way to use monero
12:31:18 <lightloved[m]> Yeah. Thanks for your comments, appreciate your input! <3
12:38:58 <Xair[m]> np man
14:42:39 <NicholasvonKlitz> What ended up happening to Kovri?
14:42:46 <NicholasvonKlitz> https://gitlab.com/kovri-project/kovri/
14:42:53 <NicholasvonKlitz> It looks like it's been very inactive
14:43:18 <sethsimmons> Never materialized due to many different issues, mostly around the main contributor.
14:43:18 <sethsimmons> Tor/i2p and Dandelion++ mostly replaced it.
14:46:18 <NicholasvonKlitz> Is dandelion live by default now?
14:46:26 <Xair[m]> iirc yes
14:46:31 <Xair[m]> has been for a long time
14:46:44 <sethsimmons> Yup
14:46:53 <sethsimmons> It's by default for all nodes.
14:47:05 <NicholasvonKlitz> is there still an advantag of using tor/i2p if dandelion is enabled
14:47:17 <Xair[m]> btw is there a release to mitigate that statistical issue in decoy selection yet?>
14:47:18 <Xair[m]>  * btw is there a release to mitigate that statistical issue in decoy selection yet?
14:47:29 <sethsimmons> Higher anonymity but also higher risk of Sybil attacks and other issues.
14:47:38 <sethsimmons> Xair[m]: No, being worked on as we speak.
14:47:44 <sethsimmons> #soon AFAIK
14:47:52 <Xair[m]> ahh nice, hopefully soon :)
14:48:37 <sethsimmons> NicholasvonKlitz: For most threat models, no IMO.
14:49:01 <sethsimmons> But if you do use Tor to relay TXs it automatically disables Dandelion++ usage.
14:49:27 <NicholasvonKlitz> ah okay. interesting
14:49:47 <Xair[m]> why is that?
14:49:59 <Xair[m]> I would assume it could work regardless
14:50:17 <sethsimmons> You wouldn't want to use Dandelion++ over Tor, and don't need to as the broadcasting node is hidden via Tor.
14:50:38 <sethsimmons> It would just cause more problems with propagation/Sybil attacks without any benefit.
14:50:49 <Xair[m]> ahh, yeah that makes sense
21:12:59 <sgp_[m]> I scheduled a Telegram voice chat in 45 mins: https://t.me/monero?voicechat
21:59:15 <carrington[m]> <sgp_[m]> "I scheduled a Telegram voice cha" <- "Link is no longer active"?
21:59:44 <sgp_[m]> try t.me/monero
22:01:16 <carrington[m]> That worked
23:16:45 <plowsof[m]> Interesting call, thanks!
23:24:03 <hyperviper[m]> why is the majority of the community on matrix instead of other websites?