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. monero-project/monero #8423

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?

<NorrinRadd> "ridauhebauye ok i had a hard..." <- Using --proxy with --p2p-bind-ip 127.0.0.1 there are no incoming connections, yes

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.

ridauhebauye[m] i asked about transactions though

not connections

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.

NorrinRadd: No I haven't confirmed that. But I've read the Dandelinon++ code and it only sends to outoging connections

Sorry, which configuration are you referring to? I haven't really verified any configuration in practice I've just been reading the code

ok a test might be in order. because that would be a flaring oversight.

maybe someone that worked on that feature can be tracked down

s/flaring/glaring

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

And the code isn't particularly complex, so I think I've got it right

Confirmation is always good though. Is there an easy way to access debug logs for this?

Dandelion++ sends only to ougoing connections in the stem phase

all nodes should see all transactions eventually

because when a tx enters the fluff phase, it's just broadcasted to everyone

ridauhebauye[m] ^

I wonder what the anonymity proerties of Dandelion nodes that only relay fluffed transactions are

I don't think it's something I'd be comfortable relying on

Or is that a known case?

vtnerd:

Have to go offline but will be monitoring here. Very interested to know how the three options stack up against each other

1) Dandelion with --proxy

2) --tx-proxy with random remote nodes

3) --tx-proxy with singular remote node owned by us

* Have to go offline but will be monitoring here. Very interested to know how the three options stack up against each other

1. Dandelion with --proxy

2. --tx-proxy with random remote nodes

3. --tx-proxy with singular remote node owned by us (--add-exclusive-node)

<ridauhebauye[m]> "I wonder what the anonymity..." <- Only relay fluffed transactions? Why would you want to configure something like this?

ridauhebauye[m]: --tx-proxy is preferred over --proxy for sending transactions

dandelion++ with --proxy is a bit constrained because all traffic is going out through a smaller number of exit nodes

(assuming tor or eventually nym)

with a VPN for --proxy, everything is being routed to a single entity

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)

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

--tx-proxy with a single remote node, Im not sure if there are any benefits to that

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

with random remote nodes, the security is basically provided by the transmission layer (tor, etc)

so you are limited by that basically

vtnerd: in case you missed it libera.monerologs.net/monero-dev/20221016#c151626

yeah I saw that, its in my calendar. did you want other people to comment and participate, or is it mainly a presentation?

I guess there could be a q/a session ?

Oh I need to know who wants to attend so I can send invite links

It’s not a presentation, comments and questions are welcome throughout

ok, then I'll assume a pm with a link sometime before the presentation

Yep 👍

I can definitely make that time slot, I'll let you know if that changes for some reason

Great :)

yeah I think the problem is limited connections with ninja thing?

Just don’t want to get overwhelmed by accident, since it’s an active meeting

<UkoeHB> "vtnerd: in case you missed it..." <- Hello! That sounds quite interesting, where would the recording be if you recorded them?

ghostway[m]: I guess youtube somewhere, sgp[m] any suggestions?

<UkoeHB> "ghostway: I guess youtube..." <- I can host on the Monero Space or Monero Community Workgroup channel if you like. Easy :)

UkoeHB: do you want this livestreamed, or recorded and uploaded later? I'm luckily free at 17 UTC, so I can handle either

oh that would be super helpful, hmm maybe recorded would be best so we can fully focus on the meeting

Okay. You can have me focus on the recording with vdo.ninja so you don't have to do anything

awesome thanks :)

<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?

<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

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).

<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?

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

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

* node will receive from other nodes and in turn relay on

some VPN providers also provide outgoing connections via a SOCKS approach - SSH-SOCKS is only such example Ive seen

you can also run a VPS that accepts SSH+SOCKS connections

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

in fact, I don't think its possible because you don't know the exit node address

Even if you did know the exit node address you couldn't connect back through it, right?

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

I don't think Tor allows that

99% sure it doesn't

correct, that is roughly my assessment. I've never heard of this, but I;ve also never looked

I think I'm going to go with the --tx-proxy option then

--proxy + --tx-proxy is probably useful in this situation

you can combine them

So is there anything that prevents circuit reuse? Is it something on the horizon? Could I help?

outgoing txes are routed to a hidden service, and all other connections are routed to some exit node(s)

tor has a custom control protocol, you'd have to implement this in monero somehow

so definitely yes you could theoretically help, although tor automatically cycles the circuits to preven this kind of issue

I know how to prevent circuit reuse over Tor, but I don't know how it would need to be done in monerod

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

Based on the anonymity network documentation, the circuit cycling isn't happening how the author thinks it is

in the tor repo is documentation for the connection protocol

Hidden service circuits are refreshed whenever data is sent out on them

*control protocol

And circuits don't die after 10 minutes, only new connections are prevented after 10 minutes

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

which maybe is useless, but its worth thinking about too

changing circuits manually is an event observable externally

yes, you could close connections periodically with --tx-proxy, that could be a good starting point

Yes that is the only option I believe

because otherwise is relying on it to happen "organically"

yeah Im not sure of the best place to do it, probably in `src/p2p/net_node.inl` there's a periodic event thing

They aren't currently dropped at all because Tor doesn't drop connections ever

It just prevents a circuit from being reused for future connections after a certain period of time

so like every few minutes just close a random tor connection to let a new one replace it

its easy to distinguish --tx-proxy connections because they are in a separate std::map node

The other thing is, what if somebody wants to transact REALLY frequently

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)

Like every few seconds

yeah, its always messed up in that scenario

its going to be noticeably externally no matter what probably, but maybe not

d++ with encryption maybe? otherwise dunno

actually no, d++ stinks for this because it uses the same route. although it mixes other txes so its harder to pinpoint

Is there an issue with creating a whole bunch of circuits and just using 1 at a time for broadcasting

Instead of broadcasting to all of them

in that regard d++ is preferrable because it carries potentially other txes

it only broadcasts to one

or maybe 2? not all

for this reason. it however changes only periodically because of the white noise feature

you could also detect with white noise off and round-robin, etc

the round-robin thing is not implemented with white noise on or off

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

This is why I was asking about d++ with --proxy earlier. It's the better solution than hidden services in my opinion

For anyone transacting frequently

umm ... I dunno. you need inbound connections, otherwise nothing is gained until d++ changes the next hop

because the exit node is just watching only your txes, its basically the isp case moved to an exit node.

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

Sorry, net keeps cutting out

But even with no inbound connections, you are still receiving some connections due to fluffed transactions coming in, right?

Some transactions*

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

you need p2p encryption to fool it, hopefully soon ^tm

the problem is the p2p protocol has a flag to indicate stem vs fluff, and its observable unless the inner p2p conn is encrypted

this is why the isp case is currently a bit jacked, and p2p encryption is definitely needed

Any links to encryption implementation?

Only been looking at monero for a week or so, not too sure what

's on the horizon

How difficult would it be to get Dandelion++ working with hidden service inbounds?

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?

it already works with hidden service inbounds

so, you receive someone txes over tor, it forwards/relays over p2p with dandelion++ (instead of immediate fluff)

so I forgot about this setup, that could be used with --proxy to properly mix txes

and yes, white noise is the feature where a dummy packet is sent in randomized 10-15 second intervals

for p2p encryption proposal

might change due to fingerprinting issues, theres an annoying tradeoff with zero-rtt, authentication, and fingerprinting

but otherwise its going to similar to that. everything should be noise for beginning to end

er wait. if the static key is dropped due to fingerprinting, making the first ephermal key look like "noise" is also a bit harder

so a couple of things going on there

So anonymous inbound + Tor --proxy is the best way to broadcast frequently?

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

I made some comments monero-project/monero #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

Actually, doesn't each zone have a separate d++ map? Meaning the anonymous inbounds would not use the same map as the --proxy?

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

which is what you'd want, I think

Yes it makes sense when not using --proxy with Tor

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

this policy might need changing, but its primarily due to user expectations

the white noise feature delays the broadcast a bit, and some people find that very annoying

Otherwise you could have it so that it provides stem transactions for the --proxy d++

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)