Monero Research Lab Meeting - Wed 08 November 2023, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Join the Monero Matrix server if you don't already have a Matrix account.

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Discuss: Reducing 10 block lock: Investigate possibility of reducing 10-blocks lock research-lab#102 (comment)

3. Discuss: Exploring Trustless zk-SNARKs for Monero's payment protocol. What are the bottlenecks for potential implementation?

4. Improvements to the decoy selection algorithm ( Decoy Selection Algorithm - Areas to Improve, Binning PoC, OSPEAD ) @j-berman @Rucknium

5. Seraphis. ( UkoeHB's Seraphis Proof of Concept work, Seraphis repo ).

6. MRL Meta: "Cat herding", i.e. prioritization of research areas and features. Active recruitment of technical talent, MRL structure, funding (@Rucknium & others) MoneroResearch.info repository of Monero-related research papers, Reddit discussion

7. Any other business

8. Confirm next meeting agenda

Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs:

#915

[plowsof]

Logs

< r​ucknium:monero.social > Meeting time! #925

< r​ucknium:monero.social > 1) Greetings

< vtnerd > hi

< rbrunner > hello

< r​ucknium:monero.social > 2) Updates. What is everyone working on?

< r​ucknium:monero.social > me: I have a draft of comments and statistical simulations on jeffro256's PR 9023 to slightly change the decoy selection algorithm: https://gist.github.com/Rucknium/5562ac14e75e34ee04ed5093c660e083

< j​effro256:monero.social > Thank you for doing that Rucknium

< vtnerd > completed subaddresses in lws, did some bugs and other odds and ends in lws. now working on whether p2p-ssl tests are possible in monerod

< r​ucknium:monero.social > And I think I have a way to find candidate consolidation transactions from PocketChange-like transactions using the Hungarian algorithm. I may share some draft code and results later.

< rbrunner > Is this before OSPEAD, or later alongside OSPEAD?

< hyc > what's up with sorting out the licensing for OSPEAD?

< r​ucknium:monero.social > PR 9023? It can be implemented before OSPEAD. It is a small change that is probably not statistically detectable at current tx volume and ring size.

< rbrunner > Ok. And later OSPEAD will supersede this all anyway, right?

< r​ucknium:monero.social > hyc: The author of the library has said by email that he is OK with open source licensing (instead of no license), but hasn't push the change publicly.

< hyc > we won't begin work on it until that's done

< hyc > I had a summer intern lined up for it but we've lost him now that summer's over

< r​ucknium:monero.social > rbrunner: No. PR 9023 reduces a distortion in the decoy selection algorithm that would have been there regardless of what the original probability distribution was supposed to be.

< rbrunner > I see

< r​ucknium:monero.social > 3) Discussion. What do we want to discuss?

< j​effro256:monero.social > Speaking of decoy selection, is anyone against allowing duplicate membership proof members in Seraphis?

< r​ucknium:monero.social > In a single ring?

< j​effro256:monero.social > Yes

< r​ucknium:monero.social > Would that be done to eliminate the distortion that PR 9023 reduces?

< j​effro256:monero.social > Yeah it would

< r​ucknium:monero.social > I don't think the distortion would become large enough to outweigh "sacrificing" ring member slot by having duplicates. We could try to quantify that.

< rbrunner > Is this for some edge cases where we had a "lull", very few transactions over the last few hours, say?

< r​ucknium:monero.social > If that's the only reason to allow duplicates.

< r​ucknium:monero.social > rbrunner: The way that the current code works, the lull would have to last about a year. I think.

< j​effro256:monero.social > I guess so, but people can always mis-use input slots or otherwise signal that a certain input is the true spend

< r​ucknium:monero.social > Even in the standard wallet2 case you would sometimes have duplicates. That would waste a slot since you cannot spend an output twice.

< rbrunner > I am afraid I don't fully understand the issue at hand, but duplicating ring members as part of the normal algorithm, even if only rarely, sounds very strange.

< j​effro256:monero.social > Fair enough

< r​ucknium:monero.social > My simulations with realistic data directly from monerod's get_output_distribution call suggests that the distortion is minor. The KS statistic is below 0.01 in the 4 scenarios I ran.

< rbrunner > In any case, it's pretty counter-intuitive to claim that a ring with a duplicate would be better somehow than a ring where just any random decoy gets picked to get rid of the duplicate ...

< rbrunner > But well, maybe intuition is not a good approach here :)

< j​effro256:monero.social > Yeah in either case the difference would be tiny

< r​ucknium:monero.social > rbrunner: I have not done a rigorous analysis of that, but at this moment I agree.

< j​effro256:monero.social > Yeah intuition might be correct here

< r​ucknium:monero.social > The problem that PR 9023 fixes involves the large set of candidate decoys that are chosen to make sure there are enough spendable outputs once the outputs with custom unlock time and the longer (60 block) coinbase lock are removed from the candidate set.

< r​ucknium:monero.social > More things to discuss? Anything about the CCS theft?

< j​effro256:monero.social > My initial idea for a solution was to have an RPC request which collects all unusable outputs before picking, then it would work 100% of the time without having to pick extras, but it would be like 15x more work lol

< j​effro256:monero.social > rbrunner7, tangentially related to the CCS theft, do you know how many people use MMS?

< j​effro256:monero.social > Like are you aware of any groups or forums etc

< rbrunner > Not many, I am pretty sure. It does not work with the latest version of PyBitmessage, and only a few days ago somebody told me that.

< j​effro256:monero.social > Oh did they change the API?

< rbrunner > I made a small PR to get it working again. With that, people can at least easily play with multisig, to get an impression

< rbrunner > No, two more strange error messages to ignore

< j​effro256:monero.social > I tried finding other BitMessage implementations besides PyBitMessage, do you know of any?

< rbrunner > And well, there is no way to deny that PyBitmessage is still on Python 2, and that's end of life. Not a good starting point if you want to get more secure

< j​effro256:monero.social > I ask b/c I tried setting up the MMS but Ubuntu 23 doesn't support pyqt4 so I can only use it as a daemon

< j​effro256:monero.social > MMS -> PyBitMessage

< rbrunner > I am pretty sure that PyBitmessage is the only implementation that has an API, which is crucial

< rbrunner > The latest version is available as an appimage which solves those problems quite nicely

< j​effro256:monero.social > Okay I'll take a look thanks

< rbrunner > https://appimage.bitmessage.org/releases/20230116/

< rbrunner > And the PR needed to make it work: monero-project/monero#9059

< rbrunner > Hopefully, as I still have a quite mysterious problem with somebody how tried that. For me it works, for them receiving messages by the MMS fails, no idea yet why

< rbrunner > Would be interesting if you tried as well, jeffro256

< j​effro256:monero.social > I want to see if the BitMessage PoW is prohibitively expensive for UX purposes for large setup ceremonies

< rbrunner > Don't think so, but the messages to exchange explode into the hundreds

< rbrunner > And well, "large" starts at 6 or 7. If you are thinking about 20 or so, don't think that's feasible at all.

< rbrunner > But do play with it, to see firsthand, if it works for you

< r​ucknium:monero.social > Could we explore what it would take to bring Monero's multisig theory and implementation from experimental to "known secure"?

< r​ucknium:monero.social > Do we know what the failure modes could be with the current multisig implementation? Would a failure mode be that a single signer could pay themselves the funds? Or even someone who does not have any of the multisig keys?

< rbrunner > Well, no idea. I think some proofs would be needed, at least in principle.

< rbrunner > Security proofs? Does that sound right?

< rbrunner > And about failure modes, maybe UkoeHB would know more.

< r​ucknium:monero.social > Sounds correct to me.

< r​ucknium:monero.social > I could place multisig as an agenda item next week. Could invite kayabaNerve and koe if they want to come.

< rbrunner > Not a bad idea

< r​ucknium:monero.social > I will put multisig on the agenda. We can end the meeting here.

Automated by this