15:58:33 Meeting 1hr 16:58:52 Hello. 17:00:05 meeting time https://github.com/monero-project/meta/issues/763 17:00:05 1. greetings 17:00:05 hello 17:00:24 Hello 17:00:31 Hi 17:00:51 hi 17:00:59 Hi 17:01:12 Greetings 17:01:47 hello 17:03:03 2. updates, what's everyone working on? 17:03:08 Hiya 17:04:14 I read cover-to-cover Sharma, P. K., Gosain, D., & Diaz, C. 2022. "On the anonymity of peer-to-peer network anonymity schemes used by cryptocurrencies." https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=130 and the original Dandelion++ paper https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=122 If we have time I will share my thoughts about it. 17:05:30 me: have been doing cleanup/review on my seraphis_lib branch (should take 2-4 more weeks), started PRing stuff from that branch to upstream (reviews would be great :) ), and updated jamtis address tag hints to use blake2b instead of a layered cipher https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4392414#gistcomment-4392414 17:06:59 "Address tags" are the proposed shortened version of the very long seraphis addresses, yes? 17:07:25 Or are these being called "address tag hints"? 17:08:43 no further contact with the bp++ author since the last email where he said he was working on adding security proofs. at this point, im wondering how long we should wait before putting the peer review forward for funding. 17:08:43 me: finished stress testing the pool and found a bottleneck + identified a couple changes I think would be good for PR 8076 (reducing trips to the daemon). I talked to rbrunner and I'm going to submit a PR to their branch implementing those changes, and separately will make a new PR to alleviate the existing bottleneck 17:08:44 Then moving over to Seraphis impl work 17:09:03 plowsof: 3+ months IMHO 17:09:32 address tags are encrypted address indices, and the address tag hint is a hint that lets you know if the associated address might be yours (so you don't have to do expensive crypto ops for testing most addresses that aren't yours, during balance recovery) 17:10:10 plowsof11: 2 weeks of no contact is a good time frame for a follow-up 17:10:35 +1^ 17:11:08 What I mean by three months is that we might want to get the current paper reviewed if there is no update to it after 3 months 17:11:21 Thanks UkoeHB. What is "the pool" that you stress testing jberman @jberman:matrix.org? 17:11:21 november 30th was the last email i sent 17:12:17 blankpage: you were thinking of RID's (recipient identifiers) = proposed shortened version of very long seraphis addresses (they're an easy-to-read hash of the address) 17:12:27 the tx pool 17:13:01 when you submit txs to the network, they enter the tx pool. I've been stress testing how it handles heavy load when lots of txs come in at once 17:14:19 txs enter the tx pool before they're confirmed, and miners mine txs from the pool. once a tx is mined and included in a block, txs are evicted from the pool 17:15:01 3. discussion period 17:17:58 * h4sh3d sits in the back 17:18:11 Sharma, Gosain, & Diaz (2022) investigate the anonymity of BTC Lightning Network, Dandelion, and Dandelion++. Lightning privacy is poor, as expected. The paper claims to show that improvements can be made to D++ anonymity with some changes to the parameters, but I am not completely convinced. 17:18:54 OK so "address tags" are more like what has previously been called "view tags". Yes I was thinking of these RIDs from a presentation I saw. 17:19:17 First, this paper uses a set of tools with a lower level of rigor than the original D++ paper. The D++ paper proved many of its statements mathematically (Theorem: Proof). Sharma, Gosain, & Diaz (2022) mostly use monte carlo simulations. 17:20:03 blankpage[m]: the address tag hint is like a view tag, it's 2 bytes appended to the encrypted address index 17:20:35 Sharma, Gosain, & Diaz (2022) arrives at a different conclusion that the original D+++ paper mostly because (1) They are using a different metric of anonymity. (2) They say that an adversary learning the "private subgraph" is easier than expected. 17:22:02 The D++ paper's metric was basically a measure of the guessing probability. The probability of guessing correctly which node originated which tx. The Sharma, Gosain, & Diaz (2022) paper uses an anonymity set measure (they use an information entropy measure that can be translated into an anon set) 17:22:47 So we may want to evaluate which metric is more important, taking into account threat models and Monero's overall anonymity issues, including on-chain info 17:23:46 For (2), either I am missing something about Sharma, Gosain, & Diaz (2022) or Sharma, Gosain, & Diaz (2022) is missing something about the D++ protocol, IMHO. I don't find their analysis very realistic 17:24:44 The the D++ paper, the private subgraph, i.e. the set of nodes and edges that are supposed to be used in the "stem" phase change every 10- minutes. That should limit an adversary's ability to learn the private subgraph 17:25:36 The Sharma, Gosain, & Diaz (2022) paper assume that there are 50 txs broadcasted per node, which gives the adversaries info to learn the subgraph. I don't think that's realistic in the D+ epoch time window 17:26:03 We could see what happens if much fewer txs are broadcasted since they have published their simulation code to GitHub 17:27:09 is that 50 new txs created by that node, or 50 txs relayed by that node? in the long run it's reasonable to assume nodes will be broadcasting tons of txs 17:27:10 In summary, take no action at this time. See if this paper gets updates or peer review. It would be nice to have Monero D++ implementation specification written out if it doesn't already exist. The D++ leaves some parameters of the protocol open to be decided by the implementation. 17:27:23 relaying tons of txs* 17:27:24 50 txs per 10 minutes sounds only realistic to me for the busiest nodes used by many people as remote nodes 17:28:11 At least as tx origin 17:28:12 I don't think you can assume any less, even the contrary, that nodes will have a uniform distribution on a very high number (or that one node will broadcast many) 17:28:43 UkoeHB: IMHO, they could have written it more clearly. To be certain, we would want to review their simulation code. Their wording is "We send 50 transactions per honest node before analyzing the distribution of diffusions per node." I'm not sure if the adversary nodes or the honest nodes are sending these txs. 17:28:50 Should have, not will have* 17:29:33 Rucknium[m]: I'd imagine the honest nodes, for an attack? But yea wording is not clear at all 17:29:35 sounds like each honest node is originating 50 txs 17:30:04 For the D++ analysis, they assume basically random uniform for the network topography and node behavior. For Lightning, they use the actual LN topology, which has a high centrality degree 17:31:07 The network topology is know to LN nodes by design, which is one reason why the sender privacy is found to be so low 17:31:15 is known* 17:33:46 Their main suggestions for D++ is to have high p_f (the probability that a node continues sending a tx in stem phase rather than fluffing it), which may already be true for Monero, and have a higher number of outward edges in the private subgraph, i.e. higher number of possible nodes that a node will send a stem-phase tx to 17:33:51 I'd be interested to hear vtnerd 's take on the paper 17:34:50 So, in short, more hops? 17:34:51 IMHO, not a very difficult paper to read, technically. Unclear in some parts, as mentioned. 17:36:06 More hops is the p_f recommendation (which corresponds to 1 - q in the original D++ paper). The original paper recommended high p_f anyway. And then more than two nodes chosen to send the stem phase transactions to. 17:36:23 Isn't this just making the problem a little harder? 17:36:46 Making the problem a little harder? 17:37:57 Of deanonymizing nodes.. 17:38:59 (monero's fluff probability is currently 20%: https://github.com/monero-project/monero/pull/7025) 17:39:07 Small changes can have big effects. One of the main improvements of D++ over the original Dandelion was to move from 1 out-edge for the stem phase to 2 out-edges. 17:39:51 Aha, interesting 17:40:06 jberman: Thanks. Like I said, it would be good to have our implementation documented...maybe in a document 17:45:52 hmm, any other topics people would like to touch on today? 17:46:36 I just want to mention that we are finally reaching the end of last milestone for farcaster 17:46:57 congrats :) 17:47:08 Wow 17:47:29 We’ll have next a final sprint, and you can expect a Reddit post at the end of the week :) 17:48:23 Took us way longer than expected but here we are… and now I said it so we cannot take longer haha 17:49:05 One more thing: One of the authors of the Sharma, Gosain, & Diaz (2022) paper is the Chief Scientist for Nym Technologies. There could be a small interest in suggesting that existing anon network systems do not work well. 17:49:13 Anyway, also expect a bit more info next research lab meeting as we’ll be near to release what we consider mainnet ready 17:50:04 Does this mean we should stop trying to fix the COMIT atomic swap implementation? Only half-joking. 17:53:07 Rucknium[m]: so, conflict of interest in a research paper? shocking 17:53:47 Is the annotation/commenting on moneroresearch.info used or are the papers on there discussed in this room? 17:53:59 Well, the issue is often that people who know the research area well also have a competing service/product 17:55:37 blankpage[m]: papers should be discussed here, you can back-fill comments into the site if you want 17:55:51 blankpage: Right now the annotation feature isn't used much, but I hope that it will be. I will add a link to my comments here to the paper on MoneroResearch.info . We specifically chose the WIKINDX software for its annotation capabilities (and overall feature creed ;) ) 17:55:51 feature creep* 17:59:01 ok looks like the meeting is done, thanks for attending everyone 18:03:24 Thanks 18:06:31 Thank you 20:07:58 I contacted one of the authors of Sharma, Gosain, & Diaz (2022). He said he would read my comments and respond in a few days. 22:58:39 Hi Rucknium you are cool and smart