Meeting summary: Monero Research Lab, 1 March 2023

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from March 1st 2023, 1700 UTC.

Logs

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

230301-mrl.log (146 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: 11 (UkoeHB², tevador³, rbrunner⁴, one-horse-wagon⁵, Rucknium⁶, ArticMine⁷, sech1⁸, hbs⁹, moneromooo¹⁰, ofrnxmr¹¹, ghostway¹²)

• (1) Updates

  • (1.1) on exploring trustless zk-SNARKs for Monero’s payment protocol¹³:

    • tevador mentioned finding a few options in his search for new curve cycles

  • (1.2) on OSPEAD¹⁴ and ‘tx_extra’¹⁵:

    • Rucknium confirmed that returned code passed the tests after sending C++ test for R wrappers to isthmus¹⁶

    • Rucknium also reported some progress after 8 hours of research into possible statistical tests of encrypted tx_extra contents

  • (1.3) on Seraphis¹⁷:

    • UkoeHB merged dangerousfreedom’s draft of seraphis knowledge proofs¹⁸ to seraphis_lib and updated it to production quality, and was planning to work on the Seraphis paper¹⁹ after refactoring enote scanning into a state machine that will be more flexible/reusable in the long run

• (2) Open discussions

  • (2.1) on what to do with the ‘tx_extra’ field¹⁵:

    • UkoeHB reminded everyone of the choice matrix:

      • A) [remove tx extra]: tx utility flexibility tied to hardfork (or steganography)
      • B) [keep tx extra in some optimized form]: uniformity and scaling trade-offs depending on the solution
        • 1) leave as unlimited-size TLV field
        • 2) mandate maximum tx extra size (e.g. anything in 0 - 1000 bytes) (option: encrypted by default)
        • 3) mandate optional fixed-length tx extra size + encrypt by default
        • 4) mandate fixed-length tx extra for all txs + encrypt by default
        • 5) other

    • one-horse-wagon was eager to start voting and opted for A: Get rid of it.; rbrunner didn’t think voting right away was a good idea with so few people attending the meeting: the vote would probably get ignored

    • ArticMine was more inclined towards a vote to narrow down to A or B3 first

    • tevador thought that B3 would be a good compromise, confirmed to sech1 that option A meant removing tx_extra only for regular transactions (not for coinbase), and that this decision is for the Seraphis fork

    • UkoeHB shared his view of the problem as being a conflict between three of Monero’s core design goals: privacy, scalability, and longevity

    • sech1 voted for A, but only after gathering all current uses of tx_extra from all parties; hbs noted that with B3 the same would apply, as some uses may exceed the fixed-length that B3 would install

    • tevador mentioned the Pre-Seraphis availability of the #8733 size limit patch¹⁹

    • ArticMine voted for B3 with 256 bytes

    • rbrunner was all for narrowing it down to a vote between A and B3 256 bytes, unless something important would not fit the proposed fixed-length

    • moneromooo noted that B3 would remove the ability for public data

    • sech1 was wondering if the field would affect atomic swaps in any way; tevador replied that none of the atomic swap protocols for Monero need tx_extra

    • UkoeHB liked B3 because it would be an incremental improvement in privacy and longevity, and only a minor regression for scalability

    • ArticMine proposed narrowing it down to A or B3 256 bytes; rbrunner and moneromooo agreed

    • Rucknium wondered if there was a clear plan for implementation of B3 256; tevador pointed to PR #8733²⁰; UkoeHB stated that there is no concrete design for B3 yet and that it would require some discussion

    • ofrnxmr shared his strong support for option A

    • ghostway voted for B3

    • UkoeHB called for less discussion about voting and more focus on design goals/philosophy; ofrnxmr agreed

    • Rucknium was in support of tevador’s plan to narrow it down to A or B(3)

    • tevador noted that a soft fork would still be possible with option A

    • UkoeHB was unhappy to waste time with the narrowing it down process, but acknowledged the loose consensus was to tentatively narrow the choices to A/B3 pending further direction changes

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

Feedback, edits always welcome @/about.

-3RA

Update: added link to isthmus’s OSPEAD update¹⁶.