Meeting summary: Monero Research Lab, 15 May 2024

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from May 15th 2024, 1700 UTC.

Logs

The raw, unedited, full log file for this meeting:

240515-mrl.log (176 lines)

Summary

Note: it is possible that some relevant information may be missing from this summary; read the full log file for the complete, unedited discussion.

• Participants: 13 (rucknium², tevador³, c​haser⁴, rbrunner⁵, a​rticmine⁶, j​effro256⁷, jberman⁸, k​ayabanerve⁹, r​ottenwheel¹⁰, s​gp_¹¹, h​into¹², d​iego¹³, a​aron¹⁴)

• (1) Updates

  • k​ayabanerve was continuing ongoing work on FCMPs¹⁵ and also met with various auditors and got various quotes

  • jberman was implementing the curves tree in C++ for fcmp’s

  • tevador was working on JAMTIS¹⁶ specs: mainly forward-secrecy improvements and some updates based on recent discussions

  • rucknium was monitoring a recent increase of 1in/16out txs on the blockchain while working on estimating tx verification time with different ring sizes and inputs/outputs

  • a​rticmine was working on scaling and fees for ~ 3000 bytes 2/2 tx and 1/2 tx weight and was wondering how the number of inputs impact tx size under FCMP

    • tevador thought it was ~2.2 KB per input and noted that we could restrict inputs to powers of two with dummy inputs

    • c​haser commented that it’s a neat idea but was unsure how it plays out before sharing a link to a recent comment by tevador in MRL #96 (Dummy transaction inputs)¹⁷

    • kayabanerve noted that additional inputs can only add an extra few hundred bytes and we must consider if the performance of any wasted inputs is acceptable and also decide if we want to limit inputs to 16

    • tevador thought that the overhead would be reasonable, as most transactions would fit into the 2/2 envelope considering the consensus limit would be 64 inputs, ~145 KB size

• (2) Open discussions

  • (2.1) on ‘Potential measures against a black marble attack’¹⁸:

    • r​ucknium reported that transactions with 1 input and 8-16 outputs produced about 15% of outputs recently and proposed that these transactions could be related to Local Monero’s cessation of operations (batched withdrawals):

      Timeline:
          May 11: 'the number of these types of transactions started rising'
          May 14: 'they were producing 52% of outputs'
          May 15: 'in the first twelve hours of today their share of outputs was 33%'
    

    • r​ucknium was mostly successful in setting up koe’s Seraphis performance test for CLSAG verification time estimates¹⁹ and was planning to interpolate the verification time for different ring sizes by Ordinary Least Squares (OLS) regression and publish a comprehensive draft by Monday; it should include feedback of the different options for fee and ring sizes, effective ring size when a black marble flooder has different budgets, users’ cost to send txs [..]

    • rucknium thanked nioCat for noticing the 1in/16out tx increase first

  • (2.2) on ‘Pre-Seraphis Full-Chain Membership Proofs’ research²⁰:

    • k​ayabanerve replied to tevador’s questions about FCMP++ inputs, noting that there’s no wasted work if we consider a power of two system, while if we do an aggregate system (lowest overall bandwidth), 33 inputs causes 64 inputs of work

      • tevador concluded that the choice is basically between wasted work or wasted space and pointed out that wasted space would come with the benefit of quantizing transaction shapes, leading to better uniformity

    • rbrunner was wondering about p2pool payout transactions with 150 outputs in this context

      • tevador noted that coinbase txs have no limit because they have no range proofs

      • kayabanerve replied that FCMP++ only affects the input side of things and had no ideas/comments on coinbase outputs

    • jberman thought that it would be useful to create a table similar to how koe did it for Seraphis²¹ with columns for # of inputs, tx size, verification time (for both approaches pow-2 / not)

    • r​ucknium called for auditing parallelized implementations so they can be deployed confidently on mainnet

    • k​ayabanerve mentioned that he solicited 1 quote from Cypher Stack regarding the composition and endorsed moving forward with Diego Salazar’s 2.5 weeks, 175 XMR quote²²

      • jberman was in favor of moving forward with CS for composition review

      • rbrunner pointed out that only 2.5 weeks sounded pretty attractive

      • tevador thought that the audit quote is reasonable and might even result in a more efficient proof and noted that forward secrecy should be among the properties to be audited

      • d​iego confirmed that CS would appreciate getting to work on this

      • s​gp_ was not concerned with the current proposal, although being generally in favor of multiple quotes

      • j​effro256 was okay with CS reviewing FCMP-RCT composition for 175 XMR (including F-S variant)

        • tevador clarified to jeffro256 that only the F-S variant is on the table and k​ayabanerve confirmed

        • tevador was unsure if the provided quote included the F-S property and thought that if not, it should be added

        • a​aron agreed to add forward secrecy to scope (Sections 2, 3, and 5.5²³) and noted that it should take an extra couple of days and +23 XMR according to diego, for a total of 198 XMR

      • r​ucknium was OK with approving it at this meeting and considering the lack of objections, concluded that there is loose consensus for this 198 XMR expense with the Forward-Secrecy modification

Let me know if you find this kind of report helpful.

Feedback, edits always welcome @/about.

-3RA