00:09:25 what about using tor isolation more liberally? for example every transaction sent through the node would have an isolated tor circuit. to augment dandelion++ 00:10:37 isolation is just a random password auth (user is part of the tor socks5 spec) 00:11:51 dandelion++ is disabled when broadcasting to Tor for obvious reasons 00:14:19 all the more reason to isolate transactions. multiple wallets using the same local node can be linked because they are using the same tor circuit 00:15:26 > can be linked because they are using the same tor circuit 00:15:26 That is assuming you manage to trace onion service/exit ip to original IP, which is the whole thing Tor swear to prohibit. 00:15:43 Its not 00:16:06 sir 00:16:09 it's shorten 00:16:24 dandelion++ skips stem phase if using tx-proxy with disable_noise 00:16:53 If not using disable_noise, it stems to onion -> stems to clearnet 00:16:55 that doesnt follow. you dont need to trace anything to observe two transactions originating from the same tor circuit nd infering they come from the same local node of someone. then if the recievers of both transactions collude they can determine it. 00:18:47 should you be using disable_noise? 00:19:14 I use it liberally 00:19:37 what does it accomplish? 00:19:41 > you dont need to trace anything to observe two transactions originating from the same tor circuit 00:19:42 Tor do not protect against an adversary capable of observing the whole circuit. So I'll just assume you mean "two transactions originating from the same exit node"? 00:19:44 > then if the recievers of both transactions collude they can determine it. 00:19:46 And how exactly would they know that the receivers are the same? 00:19:48 Speeds up broadcast, and clearnet nodes dont know which node it originated from 00:20:32 onion node it originated from* 00:21:10 clearnet have a hard time figuring oht which clearnet node received it first as well 00:21:43 is it more secure to use disable_noise or not? 00:22:53 Depends on threat model. If you think youre sybilled, i think disable noise is more secure. If your trust your peers to be honest, then you can trust stemming to them 00:23:32 Two wallets using the same local torified node send a transaction each. because each transaction is not isolated (tor socks5 random auth) they can get sent over the same circuit. An adversary can conclude that the controller of both transactions is one the same even though the purpose of using multiple wallets is to break this relationship. this is not good. 00:24:01 torified node? 00:24:06 or tor node? 00:24:14 because that's the not the same 00:24:33 i know. local implied private. so not onion. 00:25:13 alright i originally assumed you meant onion so it just felt weird to me. yeah you're right. 00:25:44 multiple wallets doesnt really break relationship. If your threat model is such, youre better off using onion remote nodes. 00:26:18 but why would you broadcast through a torified node? instead of just using `tx-proxy` ? 00:27:21 what you are afraid of impossible when broadcasting to onion nodes 00:28:31 https://github.com/monero-project/monero/pull/8774 00:28:46 the torified node is a pruned node running on the same pc. 00:30:05 This probably hurts future use of onion for block sync 00:31:16 Also, i2p doesnt have stream isolation, so doesnt really work as one would hope if using tor and i2p together 00:34:12 this seems gorssly overcomplicated. when all you need to do is use random auth? 00:38:00 How would that prevent reuse of a stream though? It can ensure each peer uses a different stream, but not each tx 00:39:27 a tx will 'consume' a circuit closing it 00:40:51 only applies to local tx's which would be assumed to not be that common. merchants that spam tx's may choose to disable it or tolerate tor thrashing 22:31:34 Full-source bootstrap of the build environment on a 9900X (12-core). Without rust: 8h30m. With rust (total): 13h30m 22:31:46 Once Guix bootstraps from mrustc 1.74 instead of 1.54, I expect that to drop to ~10h total (for Rust 1.82). 22:41:26 https://matrix.monero.social/_matrix/media/v1/download/monero.social/MVOxZcvJCrqCUQkvtWMcnYFH 22:41:30 I don't know who to report this too but the GUI wallet is bugged out on Fedora 41 running Gnome 22:41:42 Who do I file a bug report to? 22:45:45 Me, sup 22:46:06 Come join us in Monero GUI 23:28:19 paranoia_machinery: Can't reproduce on Fedora 41 23:28:34 Go to Settings -> Info. What is 'Graphics mode' set to? 23:30:41 Sorry, meant to reply in #monero-gui:monero.social.