Source Article Link: https://monero.observer/meeting-log-summary-monero-research-lab-meeting-15-may-2024/
This is a comprehensive summary, with added reference links, of the MRL meeting1 from May 15th 2024, 1700 UTC.
The raw, unedited, full log file for this meeting:
240515-mrl.log (176 lines)
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 (rucknium2, tevador3, chaser4, rbrunner5, articmine6, jeffro2567, jberman8, kayabanerve9, rottenwheel10, sgp_11, hinto12, diego13, aaron14)
(1) Updates
kayabanerve was continuing ongoing work on FCMPs15 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 JAMTIS16 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
articmine 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
chaser 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)17
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’18:
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%'
rucknium was mostly successful in setting up koe’s Seraphis performance test for CLSAG verification time estimates19 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’ research20:
kayabanerve 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
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 Seraphis21 with columns for # of inputs, tx size, verification time (for both approaches pow-2 / not)
rucknium called for auditing parallelized implementations so they can be deployed confidently on mainnet
kayabanerve 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 quote22
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
diego confirmed that CS would appreciate getting to work on this
sgp_ was not concerned with the current proposal, although being generally in favor of multiple quotes
jeffro256 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 kayabanerve confirmed
tevador was unsure if the provided quote included the F-S property and thought that if not, it should be added
aaron agreed to add forward secrecy to scope (Sections 2, 3, and 5.523) and noted that it should take an extra couple of days and +23 XMR according to diego, for a total of 198 XMR
rucknium 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
/kayabanerve-submits-ccs-proposal-full-chain-membership-proofs/ ↩
https://gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96 ↩
https://github.com/monero-project/research-lab/issues/96#issuecomment-2107521580 ↩
https://github.com/UkoeHB/monero/blob/seraphis_perf/tests/performance_tests/main.cpp ↩
https://gist.github.com/AaronFeickert/c24d42d9180ddba515462d4468f25831 ↩
(PDF!) https://github.com/kayabaNerve/fcmp-ringct/blob/develop/fcmp%2B%2B.pdf ↩
License: CC BY 4.0, no changes were made to the article.