Doing some more analysis of the d++ code and came across what appears to be a deviation from the d++ paper. In the paper, locally generated transactions are always sent in stem phase regardless of whether the local node is fluffing or not. From my understanding of monero's implementation, local transactions will be fluffed if the node is fluffing. Can anyone explain why the deviation or if I have it wrong somewhere?

What's the etiquette around here, is it rude to ping the developers involved?

* Doing some more analysis of the d++ code and came across what appears to be a deviation from the d++ paper. In the paper, locally generated transactions are always sent as stem transactions regardless of whether the local node is fluffing or not. From my understanding of monero's implementation, local transactions will be sent as fluff transactions if the node is fluffing. Can anyone explain why the deviation or if I have it

wrong somewhere?

Fuck it, vtnerd

As I was in the process of updating my comments (monero-project/monero #8423) I realized that I had something wrong. With --anonymous-inbound set, transactions will arrive via the hidden service and be relayed in the __public__ zone. With --proxy set to a Tor proxy, the public zone connects via Tor (exit nodes). Without --tx-proxy set, locally generated transactions are relayed via the public zone. So with

this configuration, I have inbound transactions arriving via the hidden service which are mixed in with my locally generated transactions

and sent out the d++ stems of the public zone (via Tor). This means that I can send transactions very frequently and neither the exit node or the d++ stems can assume any of the transactions going out are linked as they could be from different --tx-proxy clients.

s/__public__/**public**/

If you could please confirm this is correct so that I can update my comments on the pull request. It's important to be accurate with this.

ridauhebauye[m]: I do not recall the paper saying that (always put through stem), but I can re-read

and yes, that your later comments are correct, with the additional usual caveat about --proxy risks with eclipse attacks, etc

crap, this is definitely a bug compared to the paper that needs correction

the paper states "all relayed tranactions" at one point, but that is referring to other transactions not your own

this likely ruins privacy by some amount, but it is hard to quantify

or so I think, Id have to think about the attacker scenario a bit more to know what they can do with it

Ill work on 0.18 fix and test update immediately

if the node is fluffing, then the question is can an observer see that the local txn, amongst all the other fluffed txns, never came from somewhere else to the fluffing node?

if they can't see that fact, then there is no problem

also, an observer has to specifically target a particular node, to monitor all of its incoming and outgoing traffic. so, why do they pick one particular node or any other?

if you monitor all incoming and outgoing traffic of a node, you can already tell which transactions are local

true. the only defense is to make the traffic nmonitorable. using tor/i2p would do that

not sure that TLS on p2p would really achieve that

correct, p2p encryption helps, but fingerprinting via size is somewhat rough. my proposal included randomized padding to make it harder, but its still might be doable

the specific command and tx size range + timing is a giveaway

we would benefit from migrating away from HTTP-based protocols

use a binary protocol with single byte opcodes

and a fixed size structure for all parameters (random garbage for unused fields)

I guess fixed size for everything isn't really practical

or go the other way - pair a monerod with a regular http server. randomly inject normal HTTP requests (from a co-resident browser, or just generated) into the stream, with actual content proxied from a co-resident http server

yeah so I think the fallout - as already mentioned - is that this would have to be targeted attack to exploit this bug

the d++ paper was designed to prevent origin tracing of a tx. you can't really magically do that because of this bug, but you might be able to target a specific node

you can do that at the ISP level anyway, but this would allow at the p2p level

I think you have to periodically send a stem tx to your target, trying to determine if its in a stem vs fluff

this is aided by 2 connections to the target

then if the target sends a tx while its in fluff, the attacker will likely have to determine the probability of _another_ node selecting the target as an outgoing stem

its kind of a mess actually, Im not sure how viable the attack is, but might as well follow the paper sense the simulation was done based on that

the problem is some other node could be using you as a stem relay, which and the attacker has to filter that somehow

yeah we should stick to the paper, or commission the research to prove that our code still meets the security claims

of course in the _worse_ case you happen to send an attacker your tx via stem while it somehow knows you are in fluff epoch

its kind of messy edge case either way, and I think either scenario is difficult for an attacker to determine

*the last two statements were assuming algorithm based on paper

to me it still makes more sense to "follow the crowd" (i.e. do what monerod is currently doing), but as hyc stated we should stick to the paper for now

its probably always safer to send txes while in stem mode

if we could show that either way, an attacker can only guess what's really happening, then there'd be no need to change anything

How long is the fluff phase? You could maybe delay steming local txs until in the fluff phase. Or even do randomized mixed stem/fluff so you are never truly mono-modal (spitballing).

until the fluff phase ends *

~10mins

its randomized every 10mins, so you can enter back-to-back fluff phases, with a ~20% probability

er each event is 20%, so back-to-back if obviously lower

is there an advantage to doing phases vs just per-tx? the probability that when a tx encounters a node it will be fluffed is 20%, does it matter whether other txs encountering the same node are also fluffed in the same time period?

um. there's nothing an external attacker can manipulate with phases, the algorithm just runs regardless of what other connections are doing

an attacker could not manipulate per-tx dice rolls as well

oh you mean per-own-tx, nor per-received-tx, misread

well I mean per any tx

I should probably read the paper though lol

the paper and algorithm are primarily focused on preventing the mass surveillance of tx<->ip correlation

targeted stuff gets kind-of funky, but the algorithm should be decent against that

its just that the paper was modeling how to find ip origin of any/all txes being broadcast

Hello! I'm a relatively low-level developer and wish to contribute. I'm particularly interested by the core and CLI parts. I'm proficient in C++, also detail and security-oriented. I had a brief look at the open issues but they don't give much guidance on where to start. So I'm hoping to get some more here.

font-deny[m]: The typical advice seems to be to get acquainted with the codebase and run the software. If you incur a bug / issue, you can open a new pull request and others will review it

Also being present in this channel is a good idea, as there are often discussions from which you can learn or in which you can participate

There are also weekly research discussions in #monero-research-lab

I had a brief look at the open issues but they don't give much guidance on where to start <= Did you see any issues that you could potentially tackle?

I work best by having a goal rather than e.g. looking around the codebase.

To be honest I did not look into many of them as 361 open issues and there doesn't seem to be a newbie label (there is "easy" but just a handful of closed issue).

Pretty sure there must be some that I could tackle. I can have a longer look, but it's also hard to know what's meaningful and tacklable, so I thought maybe someone here can suggest a starting point.

I am sure the developers will have some recommendations, may take a bit of time though before someone else responds!

In the meantime I'll be hanging around and getting set up!

How low level ? Really low, like asm, you could look at PoW. Not that low, maybe wallet refresh concurrency.

Or you could just look at github issues and see if anything seems tailor made.

A rwlock for blockchain access is also a nice thing, though that will require a lot of testing/review.

The last two do need detail oriented, so that seems like a good fit.

Especially the rwlock.

It might need a fair bit of work though.

Yeah down to asm. So far x86_64 and ARM.

I'm thinking it would be nice for a first one to not be too sizable for getting acquainted with everything and getting in the flow of things.

Wallet refresh concurrency seems to hit all of those then. I don't think it's a lot of stuff, it's fairly naive atm so improvements aren't going to be too hard to get.

You'd want to look at wallet2::refresh

and ::pull_*

Well, all it calls.

Sounds good. Is there an issue about it?

If you mean a github issue, not that I know of. It works. I just suspect it can be sped up without too much hard work.

If concurrency is your thing.

lol, looking at older entries in my todo list, I have "p2pool", guess I can take that one out :D

Yeah that's what I meant. Just to get a feel of what's to do. Do I interpret correctly that it's about making the wallet refresh multi-threaded to speed it up?

Yes.

Currently it runs "fetch blocks from node" and "parse blocks received from node" in parallel.

And some of the parsing is also parallel.

But I did not spend a lot of time on this, so I'm sure it can be made better.

Alright. I'll get started on this then. Though I already have a full-time job and activities that take up my time, just to say that it may not have blazingly fast progress. But I'll post updates (and struggles, most likely).

Thanks!

It's alright. If you do, you do, if you don't, you don't. No pressure,

<hyc> "if the node is fluffing, then..." <- I was thinking the same thing, but have you read the whole d++ paper? There's a lot of theory involved and I would be hesitant to deviate from the paper in any way without contacting the authors

Something that is still unclear to me after reading the d++ paper is that when a node is fluffing, all of its peers will know that it is fluffing (because every tx will be a fluff), so the locally generated txs will stand out as they will be the only txs with the stem flag set.

To mitigate this you would want to make sure that you never fluff over the outbound connection that you're using as the stem for local transactions. I don't think this is mentioned in the paper, perhaps I'll review the reference implementation (github.com/dandelion-org/bitcoin/tree/dandelion-feature-commits)

vtnerd:

+1 Adhere to the specification unless there is a compelling reason not to.

Another issue: The paper says that tx propagation latency (for bitcoin) would not increase when D++ is used. But Monero tx latency is high with D++. Is it because the bitcoin tx propagation method circa 2018 was slow?

<ridauhebauye[m]> "To mitigate this you would..." <- Perhaps this isn't necessary. The Dandelion destination (remote node selected as stem) might not be able to determine whether a node is fluffing or simply just not receiving many relay transactions. I think a motivated attacker could observe enough traffic over time to come up with some statistical model to determine likelihood that a node is fluffing though. I still think it

makes sense to not diffuse transactions to the stem nodes but this isn't something covered in the paper and ideally they'd be part of this discussion

> <@ridauhebauye:matrix.org> To mitigate this you would want to make sure that you never fluff over the outbound connection that you're using as the stem for local transactions. I don't think this is mentioned in the paper, perhaps I'll review the reference implementation (github.com/dandelion-org/bitcoin/tree/dandelion-feature-commits)

* Perhaps this isn't necessary. The Dandelion destination (remote node selected as stem) might not be able to determine whether a node is fluffing or simply just not receiving many relay transactions. I think a motivated attacker could observe enough traffic over time to come up with some statistical model to determine likelihood that a node is fluffing though. I still think it makes sense to not diffuse transactions to the stem

nodes but this isn't something covered in the paper and ideally the authors would be part of this discussion

* Perhaps this isn't necessary. The Dandelion destinations (remote node selected as stems) might not be able to determine whether a node is fluffing or simply just not receiving many relay transactions. I think a motivated attacker could observe enough traffic over time to come up with some statistical model to determine likelihood that a node is fluffing though. I still think it makes sense to not diffuse transactions to the

stem nodes but this isn't something covered in the paper and ideally the authors would be part of this discussion

* Perhaps this isn't necessary. The Dandelion destinations (remote nodes selected as stems) might not be able to determine whether a node is fluffing or simply just not receiving many relay transactions. I think a motivated attacker could observe enough traffic over time to come up with some statistical model to determine likelihood that a node is fluffing though. I still think it makes sense to not diffuse transactions to the

stem nodes but this isn't something covered in the paper and ideally the authors would be part of this discussion