08:54:25 <ridauhebauye[m]> 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?
08:55:20 <ridauhebauye[m]> What's the etiquette around here, is it rude to ping the developers involved? 
08:56:20 <ridauhebauye[m]>  * 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
08:56:20 <ridauhebauye[m]> wrong somewhere?
09:10:42 <ridauhebauye[m]> Fuck it, vtnerd 
10:48:35 <ridauhebauye[m]> As I was in the process of updating my comments (https://github.com/monero-project/monero/pull/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
10:48:35 <ridauhebauye[m]> this configuration, I have inbound transactions arriving via the hidden service which are mixed in with my locally generated transactions
10:48:35 <ridauhebauye[m]> 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. 
10:48:45 <ridauhebauye[m]> s/__public__/**public**/
10:49:01 <ridauhebauye[m]> 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.
13:42:31 <vtnerd> ridauhebauye[m]: I do not recall the paper saying that (always put through stem), but I can re-read
13:48:28 <vtnerd> and yes, that your later comments are correct, with the additional usual caveat about --proxy risks with eclipse attacks, etc
13:57:37 <vtnerd> crap, this is definitely a bug compared to the paper that needs correction
13:58:06 <vtnerd> the paper states "all relayed tranactions" at one point, but that is referring to other transactions not your own
13:59:25 <vtnerd> this likely ruins privacy by some amount, but it is hard to quantify
14:00:14 <vtnerd> or so I think, Id have to think about the attacker scenario a bit more to know what they can do with it
14:01:06 <vtnerd> Ill work on 0.18 fix and test update immediately
14:23:36 <hyc> 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?
14:23:54 <hyc> if they can't see that fact, then there is no problem
14:25:25 <hyc> 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?
14:37:49 <sech1> if you monitor all incoming and outgoing traffic of a node, you can already tell which transactions are local
14:40:42 <hyc> true. the only defense is to make the traffic nmonitorable. using tor/i2p would do that
14:40:53 <hyc> not sure that TLS on p2p would really achieve that
14:41:42 <vtnerd> 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
14:42:05 <vtnerd> the specific command and tx size range + timing is a giveaway
14:42:48 <hyc> we would benefit from migrating away from HTTP-based protocols
14:43:11 <hyc> use a binary protocol with single byte opcodes
14:43:33 <hyc> and a fixed size structure for all parameters (random garbage for unused fields)
14:44:25 <hyc> I guess fixed size for everything isn't really practical
14:54:16 <hyc> 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
15:05:18 <vtnerd> yeah so I think the fallout - as already mentioned - is that this would have to be targeted attack to exploit this bug
15:05:56 <vtnerd> 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
15:06:14 <vtnerd> you can do that at the ISP level anyway, but this would allow at the p2p level
15:06:42 <vtnerd> I think you have to periodically send a stem tx to your target, trying to determine if its in a stem vs fluff
15:07:12 <vtnerd> this is aided by 2 connections to the target
15:08:06 <vtnerd> 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
15:08:38 <vtnerd> 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
15:09:37 <vtnerd> the problem is some other node could be using you as a stem relay, which and the attacker has to filter that somehow
15:10:50 <hyc> yeah we should stick to the paper, or commission the research to prove that our code still meets the security claims
15:10:55 <vtnerd> 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
15:11:37 <vtnerd> its kind of messy edge case either way, and I think either scenario is difficult for an attacker to determine
15:12:08 <vtnerd> *the last two statements were assuming algorithm based on paper
15:13:15 <vtnerd> 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
15:14:25 <vtnerd> its probably always safer to send txes while in stem mode
15:14:52 <hyc> 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
15:21:50 <UkoeHB> 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).
15:22:01 <UkoeHB> until the fluff phase ends *
15:26:38 <vtnerd> ~10mins
15:27:20 <vtnerd> its randomized every 10mins, so you can enter back-to-back fluff phases, with a ~20% probability
15:27:35 <vtnerd> er each event is 20%, so back-to-back if obviously lower
15:32:11 <UkoeHB> 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?
15:41:01 <vtnerd> um. there's nothing an external attacker can manipulate with phases, the algorithm just runs regardless of what other connections are doing
15:47:30 <UkoeHB> an attacker could not manipulate per-tx dice rolls as well
15:54:33 <vtnerd> oh you mean per-own-tx, nor per-received-tx, misread
15:55:14 <UkoeHB> well I mean per any tx
15:55:31 <UkoeHB> I should probably read the paper though lol
15:57:14 <vtnerd> the paper and algorithm are primarily focused on preventing the mass surveillance of tx<->ip correlation 
15:57:42 <vtnerd> targeted stuff gets kind-of funky, but the algorithm should be decent against that
15:57:56 <vtnerd> its just that the paper was modeling how to find ip origin of any/all txes being broadcast
17:29:41 <font-deny[m]> 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.
17:32:15 <dEBRUYNE> 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
17:32:40 <dEBRUYNE> 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
17:32:51 <dEBRUYNE> There are also weekly research discussions in #monero-research-lab
17:33:05 <dEBRUYNE>  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?
17:37:56 <font-deny[m]> I work best by having a goal rather than e.g. looking around the codebase.
17:37:56 <font-deny[m]> 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).
17:37:56 <font-deny[m]> 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.
17:45:47 <dEBRUYNE> I am sure the developers will have some recommendations, may take a bit of time though before someone else responds!
17:47:28 <font-deny[m]> In the meantime I'll be hanging around and getting set up!
18:00:44 <moneromooo> How low level ? Really low, like asm, you could look at PoW. Not that low, maybe wallet refresh concurrency.
18:01:25 <moneromooo> Or you could just look at github issues and see if anything seems tailor made.
18:01:56 <moneromooo> A rwlock for blockchain access is also a nice thing, though that will require a lot of testing/review.
18:02:41 <moneromooo> The last two do need detail oriented, so that seems like a good fit.
18:03:00 <moneromooo> Especially the rwlock.
18:03:17 <moneromooo> It might need a fair bit of work though.
18:03:19 <font-deny[m]> Yeah down to asm. So far x86_64 and ARM.
18:03:47 <font-deny[m]> 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.
18:05:13 <moneromooo> 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.
18:05:39 <moneromooo> You'd want to look at wallet2::refresh
18:05:48 <moneromooo> and ::pull_*
18:05:54 <moneromooo> Well, all it calls.
18:07:31 <font-deny[m]> Sounds good. Is there an issue about it?
18:08:17 <moneromooo> 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.
18:09:00 <moneromooo> If concurrency is your thing.
18:13:32 <moneromooo> lol, looking at older entries in my todo list, I have "p2pool", guess I can take that one out :D
18:14:35 <font-deny[m]> 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?
18:15:37 <moneromooo> Yes.
18:16:06 <moneromooo> Currently it runs "fetch blocks from node" and "parse blocks received from node" in parallel.
18:16:21 <moneromooo> And some of the parsing is also parallel.
18:16:40 <moneromooo> But I did not spend a lot of time on this, so I'm sure it can be made better.
18:21:38 <font-deny[m]> 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).
18:21:43 <font-deny[m]> Thanks!
18:38:02 <moneromooo> It's alright. If you do, you do, if you don't, you don't. No pressure,
21:50:18 <ridauhebauye[m]> <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 
22:05:23 <ridauhebauye[m]> 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.
22:07:01 <ridauhebauye[m]> 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 (https://github.com/dandelion-org/bitcoin/tree/dandelion-feature-commits)
22:07:23 <ridauhebauye[m]> vtnerd: 
22:14:08 <Rucknium[m]> +1 Adhere to the specification unless there is a compelling reason not to.
22:16:19 <Rucknium[m]> 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?
22:44:37 <ridauhebauye[m]> <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
22:44:37 <ridauhebauye[m]> 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
22:44:43 <ridauhebauye[m]> > <@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 (https://github.com/dandelion-org/bitcoin/tree/dandelion-feature-commits)
22:44:43 <ridauhebauye[m]>  * 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
22:44:43 <ridauhebauye[m]> nodes but this isn't something covered in the paper and ideally the authors would be part of this discussion
22:45:27 <ridauhebauye[m]>  * 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
22:45:27 <ridauhebauye[m]> stem nodes but this isn't something covered in the paper and ideally the authors would be part of this discussion
22:46:02 <ridauhebauye[m]>  * 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
22:46:02 <ridauhebauye[m]> stem nodes but this isn't something covered in the paper and ideally the authors would be part of this discussion