00:05:42 yeah we rotate Tor peers at random 00:07:22 so you could have 2 txs go to the same peer if they are chosen twice, we do also have a TODO to decide if this behavior should be changed 00:09:20 [#monero-support:monero.social](https://matrix.to/#/%23monero-support:monero.social) 00:10:23 I think monerod does as well, but i dont know if its random per tx or how. Also dont know how it decides between tor and i2p 00:10:54 But rotating peers isnt the same as reusing a circuit or circuit isolation 00:11:00 Thank you 00:13:59 I thought for onion addresses they are on different circuits anyway 00:14:56 we do also have the option to enable circuit isolation on Arti in our config 00:18:29 i honestly dont know 00:19:49 Simplex enables circuit isolation for every contact, so its probably not too difficulty to do the same for peers(?) 00:22:56 https://www.whonix.org/wiki/Stream_Isolation#Onion_Services 00:23:15 thats where I seen it 00:32:49 every connection to a unique peer is on a different circuit. its when you connect to the same peer within 15 minutes that a circuit will be reused unless you explicitly isolate it with having different socks5 authentication combo. 00:36:05 I think that there needs to be logic such that when you send a transaction it will choose a peer and then disconnect it after sending. 00:36:34 but then if it doesnt go through it would have to retry. 00:37:49 also every single connection made in tor mode needs to have a random socks5 password. 00:38:09 otherwise it may reuse a circuit if it connects to the same peer 00:38:42 there is a or started for this, but this sounds like a nightmare if your node is handling many transactiona 00:40:07 could gate this behind a flag. a node that sends many transactions may choose to tradeoff this capability. it would have to be a lot to matter. tor is capable of forming 100s of circuits very quickly. 00:40:45 also this only applies to transactions originating form the RPC... 00:40:55 It also wouldnt work for i2p iiuc 00:41:43 so yeah, imo it would have to be sone --tx-proxy=tor,ip:port,paranoid modifier or smthn 00:42:54 is it really paranoid when right this moment if you send two transactions there is a chance you send them to a spy node that will note those two transactions are probably tied and then have the connection show up in a tool later? 00:45:10 i'm not sure how monerod does it but if it doesn't even close the connection than tying two transaction would be 100% certain. 00:45:45 assuming enough spy nodes to rule out retransmissions. 00:49:02 it looks like bitcoin has a PR doing this pending: https://github.com/bitcoin/bitcoin/pull/29415 00:58:50 I think the better solution would be to transmit other peoples txs over onion nodes too 01:03:41 so not just txs from RPC 01:18:37 When coming from onion, its immediately fwd'd to clearnet, either stemmed dandelion or immediately fluffed 01:22:52 im not sure i see the benefit of super paranoid relaying. If use specific peers if youre paranoid 🤷‍♂️ 01:25:54 yeah that should change IMO 01:33:05 Why? Imo the whole point is to hide which node the tx originates on (which is does) 01:38:42 increase the set of txs being sent over Tor, no need to disconnect after every tx, reduces impact of any bugs that allow finding the tor peer like the one that existed not that long ago. 01:40:52 FWIW we don't do this in Cuprate as I didn't know the best way to do it, so my opinion is more this should be looked at rather than it should definitely changed 01:44:15 I use disable_noise, so it sends to all of my onion peers anyway