02:56:15 <ridauhebauye[m]> Just posted an approach to broadcasting txs over Tor that eliminates the circuit reuse issue. It's very simple but I might be missing something. Any feedback would be great. https://github.com/monero-project/monero/pull/8423
10:34:18 <NorrinRadd> ridauhebauye[m] ok i had a hard time reading the long matrix messages before.  have you confirmed your line of thinking that there are no incoming transactions with your configuration? 
10:45:02 <ridauhebauye[m]> <NorrinRadd> "ridauhebauye ok i had a hard..." <- Using --proxy with --p2p-bind-ip 127.0.0.1 there are no incoming connections, yes
10:47:39 <ridauhebauye[m]> The crux of the issue is that to broadcast transactions without worrying about the ISP, you need to use --tx-proxy (tor/i2p). But this allows the remote hidden services to link transactions broadcast by the same person.
10:48:11 <NorrinRadd> ridauhebauye[m] i asked about transactions though
10:48:16 <NorrinRadd> not connections
10:49:48 <ridauhebauye[m]> My current thinking is that I can run a second monerod instance remotely, configure it as a hidden service and use it as the exclusive node for my local monerod. 
10:50:45 <ridauhebauye[m]> NorrinRadd: No I haven't confirmed that. But I've read the Dandelinon++ code and it only sends to outoging connections
10:53:08 <ridauhebauye[m]> Sorry, which configuration are you referring to? I haven't really verified any configuration in practice I've just been reading the code
10:55:32 <NorrinRadd> ok a test might be in order.  because that would be a flaring oversight.  
10:55:42 <NorrinRadd> maybe someone that worked on that feature can be tracked down 
10:55:51 <NorrinRadd> s/flaring/glaring 
10:59:10 <ridauhebauye[m]> Well, I've read the Dandelion++ paper as well as the BIP (yes, I know that is Bitcoin) and there's very good reason to only relay transactions to outgoing connections
10:59:17 <ridauhebauye[m]> And the code isn't particularly complex, so I think I've got it right
11:02:14 <ridauhebauye[m]> Confirmation is always good though. Is there an easy way to access debug logs for this? 
11:07:13 <sech1> Dandelion++ sends only to ougoing connections in the stem phase
11:07:20 <sech1> all nodes should see all transactions eventually
11:07:47 <sech1> because when a tx enters the fluff phase, it's just broadcasted to everyone
11:09:51 <NorrinRadd> ridauhebauye[m] ^
11:15:46 <ridauhebauye[m]> I wonder what the anonymity proerties of Dandelion nodes that only relay fluffed transactions are 
11:16:18 <ridauhebauye[m]> I don't think it's something I'd be comfortable relying on
11:16:30 <ridauhebauye[m]> Or is that a known case?
11:17:36 <ofrnxmr[m]> vtnerd: 
11:57:00 <ridauhebauye[m]> Have to go offline but will be monitoring here. Very interested to know how the three options stack up against each other 
11:57:00 <ridauhebauye[m]> 1) Dandelion with --proxy
11:57:00 <ridauhebauye[m]> 2) --tx-proxy with random remote nodes
11:57:00 <ridauhebauye[m]> 3) --tx-proxy with singular remote node owned by us 
11:57:47 <ridauhebauye[m]>  * Have to go offline but will be monitoring here. Very interested to know how the three options stack up against each other
11:57:47 <ridauhebauye[m]> 1. Dandelion with --proxy
11:57:47 <ridauhebauye[m]> 2. --tx-proxy with random remote nodes
11:57:47 <ridauhebauye[m]> 3. --tx-proxy with singular remote node owned by us (--add-exclusive-node)
12:49:02 <sgp[m]> <ridauhebauye[m]> "I wonder what the anonymity..." <- Only relay fluffed transactions? Why would you want to configure something like this?
13:04:57 <selsta> ridauhebauye[m]: --tx-proxy is preferred over --proxy for sending transactions
17:14:17 <vtnerd> dandelion++ with --proxy is a bit constrained because all traffic is going out through a smaller number of exit nodes 
17:14:27 <vtnerd> (assuming tor or eventually nym)
17:14:47 <vtnerd> with a VPN for --proxy, everything is being routed to a single entity
17:15:44 <vtnerd> encryption of the p2p links will help, assuming these entities do not mitm the link (this is difficult to prevent entirely for reasons, another topic entirely)
17:16:47 <vtnerd> but even with encryption, there might be some data pattern analysis that helps identify the dandelion++ link, thats difficult to eradicate entirely without sending dummy packets. this is a rather extreme edge case but plausible
17:17:08 <vtnerd> --tx-proxy with a single remote node, Im not sure if there are any benefits to that
17:18:23 <vtnerd> I mean, the remote node is still doing a dandelion++, but the only benefit is that it changes which entity (ISP vs VPS provider or something) can see traffic
17:19:09 <vtnerd> with random remote nodes, the security is basically provided by the transmission layer (tor, etc)
17:19:15 <vtnerd> so you are limited by that basically
17:22:49 <UkoeHB> vtnerd: in case you missed it https://libera.monerologs.net/monero-dev/20221016#c151626
17:28:44 <vtnerd> yeah I saw that, its in my calendar. did you want other people to comment and participate, or is it mainly a presentation?
17:28:49 <vtnerd> I guess there could be a q/a session ?
17:29:37 <UkoeHB> Oh I need to know who wants to attend so I can send invite links
17:30:28 <UkoeHB> It’s not a presentation, comments and questions are welcome throughout
17:31:05 <vtnerd> ok, then I'll assume a pm with a link sometime before the presentation
17:31:26 <UkoeHB> Yep 👍
17:31:30 <vtnerd> I can definitely make that time slot, I'll let you know if that changes for some reason
17:31:40 <UkoeHB> Great :)
17:31:44 <vtnerd> yeah I think the problem is limited connections with ninja thing?
17:33:03 <UkoeHB> Just don’t want to get overwhelmed by accident, since it’s an active meeting
18:43:52 <ghostway[m]> <UkoeHB> "vtnerd: in case you missed it..." <- Hello! That sounds quite interesting, where would the recording be if you recorded them?
18:50:25 <UkoeHB> ghostway[m]: I guess youtube somewhere, sgp[m] any suggestions?
18:56:03 <sgp[m]> <UkoeHB> "ghostway: I guess youtube..." <- I can host on the Monero Space or Monero Community Workgroup channel if you like. Easy :)
18:57:52 <sgp[m]> UkoeHB: do you want this livestreamed, or recorded and uploaded later? I'm luckily free at 17 UTC, so I can handle either
19:08:17 <UkoeHB> oh that would be super helpful, hmm maybe recorded would be best so we can fully focus on the meeting
19:12:21 <sgp[m]> Okay. You can have me focus on the recording with vdo.ninja so you don't have to do anything
19:13:26 <UkoeHB> awesome thanks :)
22:12:15 <ridauhebauye[m]> <vtnerd> "--tx-proxy with a single..." <- If you are using random remote nodes and want to broadcast multiple transactions then these can be linked together by the hidden service operators. I can't see anything in the code that prevents circuit reuse. I also couldn't find anywhere that hidden service connections are replaced, so this linkage is inevitable. Have I missed something?
22:29:29 <ridauhebauye[m]> <vtnerd> "dandelion++ with --proxy is a..." <- I'm aware of this. My concern was more that with --proxy (and --p2p-bind-ip 127.0.0.1) no other nodes can create outbound connections to my node. So the only transactions that my node will relay on its stem edges are already-fluffed transactions (as they're the only transactions sent out on inbound connections) and locally generated transactions. A dishonest node that I've chosen as a
22:29:29 <ridauhebauye[m]> stem would be aware of this if I'm connecting to them via a Tor exit and ultimately they would have an easier time linking my transactions together (if I'm broadcasting multiple). 
22:31:29 <ridauhebauye[m]> <vtnerd> "with a VPN for --proxy, everythi..." <- What does this mean? The monerod --help output says that --proxy is for SOCKS. Is this just how you refer to running a VPN on the same system as monerod?
22:34:03 <vtnerd> SOCKS is an open protocol for making proxy connections. the tor daemon implements so that other apps can make outbound connections through a tor exit node
22:34:33 <vtnerd> there is no control in _how_ the tor daemon is making the connection, only that it guarantees somehow a connection is made _through_ the tor network
22:34:40 <ridauhebauye[m]> * node will receive from other nodes and in turn relay on
22:35:02 <vtnerd> some VPN providers also provide outgoing connections via a SOCKS approach - SSH-SOCKS is only such example Ive seen
22:35:15 <vtnerd> you can also run a VPS that accepts SSH+SOCKS connections
22:36:18 <vtnerd> if you are using --proxy, you can still have inbound connections especiall with a VPS (and ocassionally VPN) provider, but with tor yeah its trickier
22:36:43 <vtnerd> in fact, I don't think its possible because you don't know the exit node address
22:37:21 <ridauhebauye[m]> Even if you did know the exit node address you couldn't connect back through it, right?
22:37:25 <vtnerd> it might be possible with socks5 which should reply with the exit node ip, and socks allows request for inbound listening, but Im not sure if tor implements this
22:37:26 <ridauhebauye[m]> I don't think Tor allows that
22:37:42 <ridauhebauye[m]> 99% sure it doesn't
22:38:02 <vtnerd> correct, that is roughly my assessment. I've never heard of this, but I;ve also never looked
22:38:17 <ridauhebauye[m]> I think I'm going to go with the --tx-proxy option then
22:38:26 <vtnerd> --proxy + --tx-proxy is probably useful in this situation
22:38:31 <vtnerd> you can combine them
22:38:38 <ridauhebauye[m]> So is there anything that prevents circuit reuse? Is it something on the horizon? Could I help?
22:39:01 <vtnerd> outgoing txes are routed to a hidden service, and all other connections are routed to some exit node(s)
22:39:32 <vtnerd> tor has a custom control protocol, you'd have to implement this in monero somehow
22:39:55 <vtnerd> so definitely yes you could theoretically help, although tor automatically cycles the circuits to preven this kind of issue
22:40:03 <ridauhebauye[m]> I know how to prevent circuit reuse over Tor, but I don't know how it would need to be done in monerod
22:40:23 <vtnerd> the default behavior is probably "good enough" in many cases, but could use tweaking in ours Im sure. However, Im guessing you could make hte defaults worse too
22:40:36 <ridauhebauye[m]> Based on the anonymity network documentation, the circuit cycling isn't happening how the author thinks it is
22:40:48 <vtnerd> in the tor repo is documentation for the connection protocol
22:40:50 <ridauhebauye[m]> Hidden service circuits are refreshed whenever data is sent out on them
22:40:54 <vtnerd> *control protocol
22:41:35 <ridauhebauye[m]> And circuits don't die after 10 minutes, only new connections are prevented after 10 minutes
22:41:43 <vtnerd> what do you mean? someone posted a potential attack with --tx-proxy, but its tricky because if you immediately tear down a circuit after sending a "real tx" you blow up the white noise feature
22:41:50 <vtnerd> which maybe is useless, but its worth thinking about too
22:42:04 <vtnerd> changing circuits manually is an event observable externally
22:42:38 <vtnerd> yes, you could close connections periodically with --tx-proxy, that could be a good starting point
22:42:55 <ridauhebauye[m]> Yes that is the only option I believe
22:42:58 <vtnerd> because otherwise is relying on it to happen "organically"
22:43:42 <vtnerd> yeah Im not sure of the best place to do it, probably in `src/p2p/net_node.inl` there's a periodic event thing
22:43:46 <ridauhebauye[m]> They aren't currently dropped at all because Tor doesn't drop connections ever 
22:43:56 <ridauhebauye[m]> It just prevents a circuit from being reused for future connections after a certain period of time
22:43:56 <vtnerd> so like every few minutes just close a random tor connection to let a new one replace it
22:44:35 <vtnerd> its easy to distinguish --tx-proxy connections because they are in a separate std::map node
22:45:47 <ridauhebauye[m]> The other thing is, what if somebody wants to transact REALLY frequently
22:45:53 <vtnerd> its not a bad feature to have; most people are sending out txes frequently enough to matter so its not a huge difference (although still worth doing)
22:46:05 <ridauhebauye[m]> Like every few seconds
22:46:05 <vtnerd> yeah, its always messed up in that scenario
22:46:30 <vtnerd> its going to be noticeably externally no matter what probably, but maybe not
22:46:43 <vtnerd> d++ with encryption maybe? otherwise dunno
22:47:03 <vtnerd> actually no, d++ stinks for this because it uses the same route. although it mixes other txes so its harder to pinpoint
22:47:06 <ridauhebauye[m]> Is there an issue with creating a whole bunch of circuits and just using 1 at a time for broadcasting
22:47:07 <ridauhebauye[m]> Instead of broadcasting to all of them
22:47:13 <vtnerd> in that regard d++ is preferrable because it carries potentially other txes
22:47:23 <vtnerd> it only broadcasts to one
22:47:29 <vtnerd> or maybe 2? not all
22:47:41 <vtnerd> for this reason. it however changes only periodically because of the white noise feature
22:48:00 <vtnerd> you could also detect with white noise off and round-robin, etc
22:48:13 <vtnerd> the round-robin thing is not implemented with white noise on or off
22:49:20 <vtnerd> iirc I limited the broadcast over tor because in most cases a txes occurs at most only every couple mins, and the white noise feature periodically changes the outgoing path
22:49:22 <ridauhebauye[m]> This is why I was asking about d++ with --proxy earlier. It's the better solution than hidden services in my opinion
22:49:36 <ridauhebauye[m]> For anyone transacting frequently
22:51:22 <vtnerd> umm ... I dunno. you need inbound connections, otherwise nothing is gained until d++ changes the next hop
22:51:46 <vtnerd> because the exit node is just watching only your txes, its basically the isp case moved to an exit node.
22:52:17 <vtnerd> of course, the exit node isn't fully aware of some routing tricks you might be pulling, like having a second node connect back into yours
22:57:48 <ridauhebauye[m]> Sorry, net keeps cutting out
22:58:17 <ridauhebauye[m]> But even with no inbound connections, you are still receiving some connections due to fluffed transactions coming in, right?
22:58:24 <ridauhebauye[m]> Some transactions*
23:00:04 <ridauhebauye[m]> I think the way d++ is currently implemented, those would then get sent out the stems. That would be sufficient to fool the exit nodes
23:03:06 <vtnerd> you need p2p encryption to fool it, hopefully soon ^tm
23:03:27 <vtnerd> the problem is the p2p protocol has a flag to indicate stem vs fluff, and its observable unless the inner p2p conn is encrypted
23:03:46 <vtnerd> this is why the isp case is currently a bit jacked, and p2p encryption is definitely needed
23:04:54 <ridauhebauye[m]> Any links to encryption implementation?
23:05:19 <ridauhebauye[m]> Only been looking at monero for a week or so, not too sure what
23:05:30 <ridauhebauye[m]> 's on the horizon
23:10:44 <ridauhebauye[m]> How difficult would it be to get Dandelion++ working with hidden service inbounds?
23:15:04 <ridauhebauye[m]> Also just to clarify, when you refer to the white noise feature you mean the periodic dummy data that is sent over circuits every 10 - 15 seconds, right?
23:19:19 <vtnerd> it already works with hidden service inbounds
23:19:52 <vtnerd> so, you receive someone txes over tor, it forwards/relays over p2p with dandelion++ (instead of immediate fluff)
23:20:04 <vtnerd> so I forgot about this setup, that could be used with --proxy to properly mix txes
23:20:20 <vtnerd> and yes, white noise is the feature where a dummy packet is sent in randomized 10-15 second intervals
23:23:50 <vtnerd> https://github.com/monero-project/monero/pull/8028
23:23:57 <vtnerd> for p2p encryption proposal
23:24:20 <vtnerd> might change due to fingerprinting issues, theres an annoying tradeoff with zero-rtt, authentication, and fingerprinting
23:24:40 <vtnerd> but otherwise its going to similar to that. everything should be noise for beginning to end
23:25:19 <vtnerd> er wait. if the static key is dropped due to fingerprinting, making the first ephermal key look like "noise" is also a bit harder
23:25:30 <vtnerd> so a couple of things going on there
23:28:59 <ridauhebauye[m]> So anonymous inbound + Tor --proxy is the best way to broadcast frequently?
23:30:57 <ridauhebauye[m]> No crazy circuit count (as would inevitably be required by --tx-proxy), no ISP leakage, d++ removes the ability for the outbound connections to link transactions as they could have arrived from the anonymous inbound 
23:33:21 <ridauhebauye[m]> I made some comments https://github.com/monero-project/monero/pull/8423 but since this conversation they now need to be changed or removed. I think the configuration I just described needs to be documented because even people who transact semi-frequently are susceptible to the transaction linking if they're using --tx-proxy 
23:34:44 <ridauhebauye[m]> Actually, doesn't each zone have a separate d++ map? Meaning the anonymous inbounds would not use the same map as the --proxy?
23:44:29 <vtnerd> the daemon stores the tor-inbound tx temporarily for a randomized amount of time (I forget interval) then forwards over d++ using a different "map" yes
23:44:41 <vtnerd> which is what you'd want, I think
23:45:20 <ridauhebauye[m]> Yes it makes sense when not using --proxy with Tor 
23:45:23 <vtnerd> or wait - it forwards immediately if the remote side (inbounds over tor) does _not_ use whitenoise. if white noise is used the forward is randomized
23:45:47 <vtnerd> this policy might need changing, but its primarily due to user expectations
23:45:57 <vtnerd> the white noise feature delays the broadcast a bit, and some people find that very annoying
23:46:07 <ridauhebauye[m]> Otherwise you could have it so that it provides stem transactions for the --proxy d++
23:54:45 <ridauhebauye[m]> When I get the chance I'll look into implementing the --tx-proxy disconnection stuff and also making it so that local transactions will never reuse the same circuit. For an immediate solution I would recommend the best way for anyone to transact frequently is to use --tx-proxy with your own exclusive node (via hidden service)