16:02:28 <m-relay> <r​ucknium:monero.social> MRL meeting in this room in one hour.
17:00:53 <m-relay> <r​ucknium:monero.social> Meeting time! https://github.com/monero-project/meta/issues/959
17:01:03 <m-relay> <r​ucknium:monero.social> 1) Greetings
17:01:24 <rbrunner> Hello
17:01:26 <vtnerd> hi
17:03:34 <m-relay> <r​ucknium:monero.social> 2) Updates. What is everyone working on?
17:05:25 <m-relay> <r​ucknium: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.
17:05:59 <m-relay> <r​ucknium:monero.social> ("Why am I getting all these segfaults?") gingeropolous got it back running quickly.
17:06:32 <vtnerd> me : still working on pow difficulty tracking in LWS - still not certain whether its worth hacking LWS to get crude pow verification
17:07:15 <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?
17:08:09 <rbrunner> (Maybe I asked that before, but must be quite some time ago ...)
17:08:09 <m-relay> <r​ucknium: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.
17:08:43 <rbrunner> Ok. Sounds good.
17:09:25 <m-relay> <r​ucknium: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.
17:10:22 <m-relay> <r​ucknium:monero.social> I have mirrored wallet's calculation of the flow of outputs per second. (seconds per output, actually.)
17:10:57 <m-relay> <r​ucknium:monero.social> And the unspendable outputs because of lock time (most relevant for coinbase outputs with 60 block lock instead of 10 block lock
17:11:20 <m-relay> <r​ucknium:monero.social> So this is supposed to be a drop-in replacement for what wallet2 does now.
17:12:03 <m-relay> <r​ucknium:monero.social> But that brings me to a question that I have wondered about: Will there be a hard fork this calendar year?
17:12:46 <rbrunner> No idea. It must be a long time already ago that I read anybody writing something about a possible hardfork.
17:13:14 <m-relay> <r​ucknium: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.
17:13:19 <rbrunner> But you completing your work might provide a push. And I think some nice RandomX changes are waiting.
17:13:40 <m-relay> <r​ucknium: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.
17:14:09 <m-relay> <r​ucknium:monero.social> Yes, I think the possible changes are to PoW and Bulletproofs++
17:14:21 <rbrunner> Yeah, those as well.
17:14:33 <m-relay> <r​ucknium:monero.social> AFAIK, the coding changes to PoW are complete.
17:14:57 <rbrunner> Think so as well
17:15:04 <m-relay> <r​ucknium:monero.social> The soundness of BP++ is still being researched by CypherStack.
17:17:08 <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 ...
17:18:11 <m-relay> <r​ucknium: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?
17:19:37 <rbrunner> Nope. Would they need a large sum?
17:20:54 <m-relay> <r​ucknium:monero.social> They are requesting about 24,000 USD. It is one post-doc, one PhD student, and one professor supervising.
17:21:20 <m-relay> <r​ucknium:monero.social> From the Blockchain & Distributed Ledger Technologies Group at UZH
17:22:14 <rbrunner> Hard to say whether that would find funding, but maybe worth a try?
17:23:09 <rbrunner> Although it does not look too good with exchanges and Monero nowadays, so that EAE problem may become smaller over time ...
17:24:34 <m-relay> <r​ucknium: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.
17:25:58 <m-relay> <r​ucknium: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.
17:26:48 <m-relay> <r​ucknium: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.
17:26:55 <vtnerd> thats a good question, and I don't remember off-hand, let me check
17:27:09 <m-relay> <g​hostway:matrix.org> I'm reading and trying to process GBPs and reading kayabanerve's code
17:27:19 <m-relay> <r​ucknium:monero.social> Thanks :)
17:27:30 <m-relay> <g​hostway:matrix.org> If anyone cares :)
17:28:09 <m-relay> <r​ucknium:monero.social> ghostway: Good. Anything you want to share about it?
17:28:44 <vtnerd> it prints this error message : 'Unable to send transaction(s) via Dandelion++ stem' and then initiates a fluff
17:29:10 <m-relay> <r​ucknium:monero.social> vtnerd: Thank you!
17:29:20 <vtnerd> and its the opposite, its no outgoing connections
17:30:01 <m-relay> <r​ucknium:monero.social> Oh. Then it still sends stem phase txs without any incoming connections?
17:31:05 <m-relay> <r​ucknium: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.
17:31:56 <m-relay> <r​ucknium:monero.social> I'm not certain if immediate-fluff or stem phase is better or worse for privacy in this case.
17:33:40 <m-relay> <r​ucknium: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.
17:34:31 <vtnerd> yes, stem phase uses outgoing connections
17:36:03 <vtnerd> that comes straight from the paper
17:38:02 <m-relay> <r​ucknium: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.
17:38:24 <m-relay> <r​ucknium:monero.social> By deduction.
17:38:56 <m-relay> <r​ucknium:monero.social> So those nodes would know for sure that the stem phase txs belong to wallets that submitted txs to node `A`.
17:39:31 <m-relay> <r​ucknium: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.
17:39:49 <vtnerd> I'm not following. the node would still have stem-phase because it has outgoing links?
17:41:17 <m-relay> <r​ucknium: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.
17:42:37 <m-relay> <r​ucknium: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").
17:44:26 <vtnerd> yes, if there are no incoming connections, it should still use stem mode on the outgoing links
17:44:50 <m-relay> <r​ucknium: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?
17:45:46 <m-relay> <r​ucknium: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.
17:46:31 <m-relay> <r​ucknium:monero.social> Anyway, a small network privacy issue for node operators who have their ports closed or who reject incoming connections.
17:47:03 <m-relay> <r​ucknium:monero.social> Anything more to discuss?
17:51:36 <vtnerd> ok, yes, that is a privacy leak that I dont recall being discussed
17:52:46 <vtnerd> a tx could also come inbound via tor, but if they have tor inbound enabled they likely have tcp inbound enabled
17:53:19 <m-relay> <r​ucknium: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
17:54:19 <m-relay> <r​ucknium:monero.social> Sharma, P. K., Gosain, D., & Diaz, C. 2022. On the anonymity of peer-to-peer network anonymity schemes used by cryptocurrencies.
17:54:44 <m-relay> <r​ucknium:monero.social> I downloaded the Python simulation months ago and it seemed to work.
17:56:05 <m-relay> <r​ucknium:monero.social> We can end the meeting here.
17:57:15 <xFFFC0000> Thanks everyone. 
18:57:22 <m-relay> <k​ayabanerve:matrix.org> all Serai TXs are public. It's not just to the validators yet to everyone.
20:51:13 <m-relay> <g​ingeropolous:monero.social> sweeeeeeeeeeeeeeeeeeeet
20:54:29 <m-relay> <g​ingeropolous:monero.social> though i wonder how they plan to handle coinjoins and other bitcoin "privacy" approaches.
21:41:13 <m-relay> <r​ucknium:monero.social> gingeropolous: We have a list of questions to ask them. I will add yours.