Monero Research Lab Meeting - Wed 24 January 2024, 17:00 UTC

Logs

< rucknium:monero.social > MRL meeting in this room in one hour.

< rucknium:monero.social > Meeting time! https://github.com/monero-project/meta/issues/959

< rucknium:monero.social > 1) Greetings

< rbrunner > Hello

< vtnerd > hi

< rucknium:monero.social > 2) Updates. What is everyone working on?

< rucknium:monero.social > me: OSPEAD. I originally set an internal deadline of January 31, but it is best to inform everyone in the project of internal deadlines 😅. isthmus is working on getting me some additional data. Also, I killed one of the Monero Research Computing Server's computers. Or, you cannot prove anything, but I was at the scene of the crime.

< rucknium:monero.social > ("Why am I getting all these segfaults?") gingeropolous got it back running quickly.

< vtnerd > me : still working on pow difficulty tracking in LWS - still not certain whether its worth hacking LWS to get crude pow verification

< rbrunner > If your part of OSPEAD work is finished, does this need a next step of "coding" it? And if yes, is that much work still?

< rbrunner > (Maybe I asked that before, but must be quite some time ago ...)

< rucknium:monero.social > You mean the edits to wallet2? AFAIK, only a few lines need to be changed. Maybe someone will need to implement an unusual parametric distribution if an unusual one is the one that fits best.

< rbrunner > Ok. Sounds good.

< rucknium:monero.social > Taking pains, I have mirrored what wallet2 does. That means that the probability distribution is not modeled as time-since-block, but as output index.

< rucknium:monero.social > I have mirrored wallet's calculation of the flow of outputs per second. (seconds per output, actually.)

< rucknium:monero.social > And the unspendable outputs because of lock time (most relevant for coinbase outputs with 60 block lock instead of 10 block lock

< rucknium:monero.social > So this is supposed to be a drop-in replacement for what wallet2 does now.

< rucknium:monero.social > But that brings me to a question that I have wondered about: Will there be a hard fork this calendar year?

< rbrunner > No idea. It must be a long time already ago that I read anybody writing something about a possible hardfork.

< rucknium:monero.social > isthmus and I discussed implementation of the new decoy selection algorithm. We could try to compute the privacy impact of introducing a new DSA without a hard fork. But isthmus thinks the research time for that isn't work it. And it will be hard to forecast certain important variables.

< rbrunner > But you completing your work might provide a push. And I think some nice RandomX changes are waiting.

< rucknium:monero.social > So probably we would wait for the next hard fork so all wallet2-based wallets have the same DSA instead of a slow adoption.

< rucknium:monero.social > Yes, I think the possible changes are to PoW and Bulletproofs++

< rbrunner > Yeah, those as well.

< rucknium:monero.social > AFAIK, the coding changes to PoW are complete.

< rbrunner > Think so as well

< rucknium:monero.social > The soundness of BP++ is still being researched by CypherStack.

< rbrunner > We could also pair the hardfork with a push to a broader introduction of Polyseed, although of course technically not related. But if you update anyway ...

< rucknium:monero.social > The University of Zurich research group has applied to MAGIC for funding their idea to replicate the BTC transaction graph with Monero's ring signatures to analyze EAE-like attacks. We talked about that a few months ago here IIRC. Any further thoughts?

< rbrunner > Nope. Would they need a large sum?

< rucknium:monero.social > They are requesting about 24,000 USD. It is one post-doc, one PhD student, and one professor supervising.

< rucknium:monero.social > From the Blockchain & Distributed Ledger Technologies Group at UZH

< rbrunner > Hard to say whether that would find funding, but maybe worth a try?

< rbrunner > Although it does not look too good with exchanges and Monero nowadays, so that EAE problem may become smaller over time ...

< rucknium:monero.social > Yes, that is an interesting development. The group plans to use data on who owns the BTC addresses like exchanges, etc., to get a realistic picture of how successful EAE-like attacks would be.

< rucknium:monero.social > vtnerd: Question about Dandelion++. If a node operator has no incoming connections, do all txs submitted to that node from wallets immediately enter the fluff phase? I assume that they do because the node's outgoing connections would know that a stem-phase tx actually originates with that node because they have no incoming connections that could be stem phase.

< rucknium:monero.social > But, for example, Serai or a DEX that functions in a similar way would sort of have a EAE problem since the incoming and outgoing txs would be known to the Serai validators IIRC.

< vtnerd > thats a good question, and I don't remember off-hand, let me check

< ghostway:matrix.org > I'm reading and trying to process GBPs and reading kayabanerve's code

< rucknium:monero.social > Thanks :)

< ghostway:matrix.org > If anyone cares :)

< rucknium:monero.social > ghostway: Good. Anything you want to share about it?

< vtnerd > it prints this error message : 'Unable to send transaction(s) via Dandelion++ stem' and then initiates a fluff

< rucknium:monero.social > vtnerd: Thank you!

< vtnerd > and its the opposite, its no outgoing connections

< rucknium:monero.social > Oh. Then it still sends stem phase txs without any incoming connections?

< rucknium:monero.social > AFAIK, this "attack" would require the adversary to be a little active since the adversary would have to check if the node was accepting incoming connections to conclude that any seen stem txs originated with the node.

< rucknium:monero.social > I'm not certain if immediate-fluff or stem phase is better or worse for privacy in this case.

< rucknium:monero.social > The outgoing connections are chosen by the node, so in theory they are supposed to be "friendlier" than an incoming connection that could be from anyone. AFAIK.

< vtnerd > yes, stem phase uses outgoing connections

< vtnerd > that comes straight from the paper

< rucknium:monero.social > Right. I mean that if an operator of node A does not open ports and the node's outgoing connections know that the ports are not open by probing them, then the nodes on the outgoing connections know that node A will have no stem phase txs except for the ones that originate from itself.

< rucknium:monero.social > By deduction.

< rucknium:monero.social > So those nodes would know for sure that the stem phase txs belong to wallets that submitted txs to node A.

< rucknium:monero.social > But maybe if the txs were in fluff mode they would not know for sure because a fluff phase may have been sent to node A by one of its other outgoing connections.

< vtnerd > I'm not following. the node would still have stem-phase because it has outgoing links?

< rucknium:monero.social > My question is if the txs that are submitted to node A by wallets are set to be stem phase when they are first relayed to the outgoing connections. In the case that node A has no incoming connections.

< rucknium:monero.social > Normally, all txs submitted to a node will be relayed to another node in stem mode (except maybe if they are in that 20% in the epoch that has its mode switched to "always fluff").

< vtnerd > yes, if there are no incoming connections, it should still use stem mode on the outgoing links

< rucknium:monero.social > The only way that a node will relay a tx in stem mode is if (1) it received the tx in stem mode from another node that is an incoming connection or (2) if the tx was submitted directly to that node by a wallet. Right?

< rucknium:monero.social > So if a node has ports closed, then possibility (1) is eliminated and (2) remains. Nodes connected by outgoing connections could check if node A has its ports closed.

< rucknium:monero.social > Anyway, a small network privacy issue for node operators who have their ports closed or who reject incoming connections.

< rucknium:monero.social > Anything more to discuss?

< vtnerd > ok, yes, that is a privacy leak that I dont recall being discussed

< vtnerd > a tx could also come inbound via tor, but if they have tor inbound enabled they likely have tcp inbound enabled

< rucknium:monero.social > Maybe that could be analyzed using some of the nice formulas from the D++ paper. Or from the other paper with python simulation

< rucknium:monero.social > Sharma, P. K., Gosain, D., & Diaz, C. 2022. On the anonymity of peer-to-peer network anonymity schemes used by cryptocurrencies.

< rucknium:monero.social > I downloaded the Python simulation months ago and it seemed to work.

< rucknium:monero.social > We can end the meeting here.

Automated by this

monero-project / meta

Monero Research Lab Meeting - Wed 24 January 2024, 17:00 UTC #959

957