-
UkoeHB
Meeting 1hr
-
one-horse-wagon[
Hello.
-
UkoeHB
-
UkoeHB
1. greetings
-
UkoeHB
hello
-
rbrunner
Hello
-
Rucknium[m]
Hi
-
plowsof11
hi
-
ArticMine[m]
Hi
-
ghostway[m]
Greetings
-
jberman[m]
hello
-
UkoeHB
2. updates, what's everyone working on?
-
sneurlax[m]
Hiya
-
Rucknium[m]
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."
moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=130 and the original Dandelion++ paper
moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=122 If we have time I will share my thoughts about it.
-
UkoeHB
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
gist.github.com/tevador/50160d160d2…ment_id=4392414#gistcomment-4392414
-
blankpage[m]
"Address tags" are the proposed shortened version of the very long seraphis addresses, yes?
-
blankpage[m]
Or are these being called "address tag hints"?
-
plowsof11
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.
-
jberman[m]
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
-
jberman[m]
Then moving over to Seraphis impl work
-
Rucknium[m]
plowsof: 3+ months IMHO
-
UkoeHB
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)
-
UkoeHB
plowsof11: 2 weeks of no contact is a good time frame for a follow-up
-
jberman[m]
+1^
-
Rucknium[m]
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
-
blankpage[m]
Thanks UkoeHB. What is "the pool" that you stress testing jberman @jberman:matrix.org?
-
plowsof11
november 30th was the last email i sent
-
jberman[m]
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)
-
jberman[m]
the tx pool
-
jberman[m]
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
-
jberman[m]
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
-
UkoeHB
3. discussion period
-
» h4sh3d sits in the back
-
Rucknium[m]
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.
-
blankpage[m]
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.
-
Rucknium[m]
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.
-
UkoeHB
blankpage[m]: the address tag hint is like a view tag, it's 2 bytes appended to the encrypted address index
-
Rucknium[m]
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.
-
Rucknium[m]
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)
-
Rucknium[m]
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
-
Rucknium[m]
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
-
Rucknium[m]
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
-
Rucknium[m]
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
-
Rucknium[m]
We could see what happens if much fewer txs are broadcasted since they have published their simulation code to GitHub
-
UkoeHB
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
-
Rucknium[m]
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.
-
UkoeHB
relaying tons of txs*
-
rbrunner
50 txs per 10 minutes sounds only realistic to me for the busiest nodes used by many people as remote nodes
-
rbrunner
At least as tx origin
-
ghostway[m]
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)
-
Rucknium[m]
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.
-
ghostway[m]
Should have, not will have*
-
ghostway[m]
Rucknium[m]: I'd imagine the honest nodes, for an attack? But yea wording is not clear at all
-
UkoeHB
sounds like each honest node is originating 50 txs
-
Rucknium[m]
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
-
Rucknium[m]
The network topology is know to LN nodes by design, which is one reason why the sender privacy is found to be so low
-
Rucknium[m]
is known*
-
Rucknium[m]
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
-
UkoeHB
I'd be interested to hear vtnerd 's take on the paper
-
rbrunner
So, in short, more hops?
-
Rucknium[m]
IMHO, not a very difficult paper to read, technically. Unclear in some parts, as mentioned.
-
Rucknium[m]
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.
-
ghostway[m]
Isn't this just making the problem a little harder?
-
Rucknium[m]
Making the problem a little harder?
-
ghostway[m]
Of deanonymizing nodes..
-
jberman[m]
(monero's fluff probability is currently 20%:
monero-project/monero #7025)
-
Rucknium[m]
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.
-
ghostway[m]
Aha, interesting
-
Rucknium[m]
jberman: Thanks. Like I said, it would be good to have our implementation documented...maybe in a document
-
UkoeHB
hmm, any other topics people would like to touch on today?
-
h4sh3d
I just want to mention that we are finally reaching the end of last milestone for farcaster
-
UkoeHB
congrats :)
-
rbrunner
Wow
-
h4sh3d
We’ll have next a final sprint, and you can expect a Reddit post at the end of the week :)
-
h4sh3d
Took us way longer than expected but here we are… and now I said it so we cannot take longer haha
-
Rucknium[m]
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.
-
h4sh3d
Anyway, also expect a bit more info next research lab meeting as we’ll be near to release what we consider mainnet ready
-
Rucknium[m]
Does this mean we should stop trying to fix the COMIT atomic swap implementation? Only half-joking.
-
hyc
Rucknium[m]: so, conflict of interest in a research paper? shocking
-
blankpage[m]
Is the annotation/commenting on moneroresearch.info used or are the papers on there discussed in this room?
-
Rucknium[m]
Well, the issue is often that people who know the research area well also have a competing service/product
-
UkoeHB
blankpage[m]: papers should be discussed here, you can back-fill comments into the site if you want
-
Rucknium[m]
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 ;) )
-
Rucknium[m]
feature creep*
-
UkoeHB
ok looks like the meeting is done, thanks for attending everyone
-
ArticMine[m]
Thanks
-
blankpage[m]
Thank you
-
Rucknium[m]
I contacted one of the authors of Sharma, Gosain, & Diaz (2022). He said he would read my comments and respond in a few days.
-
CidadodoMonerist
Hi Rucknium you are cool and smart