Monero Observer

Meeting summary: Monero Research Lab, 19 February 2025

Thu, 20 Feb 2025 UTC

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from February 19th 2025, 1700 UTC.

Logs

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

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: 9 (rucknium², chaser³, syntheticbird⁴, rbrunner⁵, sagewilder⁶, jberman⁷, jeffro256⁸, sech1⁹, kayabanerve¹⁰)
(1) Updates
- rucknium was learning Rust and doing some more analysis of subnet deduplication peer selection against spy nodes¹¹, while preparing all OSPEAD-related documents and code¹² for public release (expected Febuary 20)
- jberman managed to get FCMP++ txs validating at consensus¹³ and was now working on re-reviewing jeffro256’s blockchain sync PR #9135¹⁴; he also announced that the FCMP++ optimization competition¹⁵ details are now ready for preliminary review
- jeffro256 was working on debugging release issues and review¹⁶
- rucknium reminded participants that anyone can suggest MRL agenda items, noting that: I have been composing the agenda based on my own judgement recently
(2) Open discussions
- (2.1) on the ‘Prize contest to optimize some FCMP cryptography code’¹⁵:
  - jberman shared a list of the main things he did during the previous week: a) settled on a method of scoring helioselene, weighting specific arithmetic operations as a % of the final score, b) fixed an issue in the wasm-cycles counter used to check for constant time, and c) updated the README’s
    - rbrunner wondered how hard it will be to achieve constant time execution for the submitted code and whether people may overlook that requirement and then stumble over it
      - jberman suggested looking at how the current reference code uses ops like ct_eq and conditional_select to achieve constant time and noted that kayabanerve previously mentioned it would be relatively trivial to speed up the code by like 300% if non-constant time code was allowed; then underlined that it is an important requirement that he should highlight more significantly
        
        rucknium was curious why the constant-time is so important in this application
        
        syntheticbird thought that constant-time is only useful for construction and nodes that only proceed to verification don’t need it
        
        syntheticbird pointed out the attractiveness of advocating for two separate implementations - one for proving that is constant-time, and one for verifying that is variable time - if what kayabanerve stated is true
        
        jberman clarified that constant time isn’t necessary for verifying and the 300% figure was for ec-divisors prove; he also shared that kayabanerve has explicitly expressed a lack of interest in maintaining/reviewing multiple implementations
        
        kayabanerve commented that Non-constant-time means leaked private keys and no privacy under side-channel attacks and stressed - in agreement with what jberman stated - that the 300% comment was for proving, not for node operations
    - rucknium shared a statement made by kayabanerve on the issue the previous week: FYI I will explicitly and publicly opt-out of being a judge, as I already have, yet with the additional comment I may enter (publicly or anonymously) as a contestant in the above proposed contest.
      - syntheticbird and rbrunner half-jokingly hinted at potential issues with the contest by mentioning the fact that kaybanerve created the contest, abandoned it, then ultimately decided to participate only after it was picked up by someone else
        
        rucknium agreed that there are some ethics issues involved that need to be discussed - specifically self-dealing - although it was unclear if those were important enough to bar kayabanerve from participating in the contest
        
        chaser wondered if the specific issue was Kayaba raising the funds, writing the code, and then entering the contest to improve the code and winning part the funds he raised; rucknium explained that setting the contest rules - Which writing the code in the first place is part of was a particular worry
        
        syntheticbird recommended some delay between the announcement of the contest and opening the contest
        
        jberman agreed: announcement first, delay, then contest opens
        
        kayabanerve stated that if there are sufficient ethical concerns he will drop out, noting that jberman has been working on the scoring framework without my commentary other than what little I’ve said here. I also haven’t advocated for larger prizes and didn’t write the rules with intent to participate.
        
        jberman shared some figures: the total proposed payout right now is 350 XMR (250+100) after taking into consideration the estimate for expected time to complete. Original proposed was 300 XMR (150+75 + 50+25)
        
        rucknium pointed out that currently the loose consensus appears to be to allow kayabanerve to participate in the contest
        
        kayabanerve was keen to underline that his interest in the contest isn’t due to free time or personal love for the subject and stated that he would be ready to accept 1m/y to operate the contest, and not participate accordingly, for the time spent working on the contest: I believe the current code is fine. It just got bumped up to a very large $ figure after I dropped it.
        
        jberman noted that the bump was only due to discussions that weren’t accurately taking into consideration expected time to complete the work and clarified that it was brought down again after taking your prior estimate into consideration
        
        kayabanerve replied: And like magic, I’ve lost interest and will go find other places to pay my bills
  - sech1 was unsatisfied with the competition being Rust-only, which cuts a lot of devs, including me
    - syntheticbird noted that it is never too late to learn Rust and also suggested trying to team up with a Crab master and he will translate your improvements
    - jberman pointed out that rust is really not that hard to learn and thought the core of this competition will be implementing faster algorithms, not necessarily niche micro-optimizations that are language specific
    - kayabanerve did not believe that Rust, at this level of programming, should be a blocker, given that The end-goal of the Helioselene arithmetic is just operations over arrays which Rust doesn’t really do with novelty UNLESS you explicitly expect the C preprocessor.
- (2.2) on ‘FCMP research progress status’¹⁷:
  - rucknium asked participants if there is anything we can be doing now to prepare for the next steps of protocol proving and code auditing
  - jberman noted that Veridise is making solid progress on their leg of EC divisors R1CS but had no updates on CS progress yet; he suggested bringing in a new 3rd party to start on some impl audits
  - chaser wondered if both audits started yet; jberman confirmed Veridise started but was unsure of CS
- (2.3) on ‘Fluffy blocks efficiency improvements’¹⁸:
  - rucknium shared that jeffro256 was looking into this topic
  - chaser was looking for a link to get a better meta on the fluffy blocks improvements topic; rucknium noted that it is very early stages
  - jeffro256 thought that PR #9135¹⁹ will probably get merged with relaying empty blocks at first although it would be nice to know if the scheme of relaying transactions you didn’t know about doesn’t leak information
    - jberman was ok with relaying empty blocks but wanted to re-review that full flow of requesting missing / responding
    - rucknium thought that there could be a small info leak and offered to check it empirically in the node logs from last year since the log level recorded fluffy blocks and when txs were “missed” by the nodes

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

Feedback, edits always welcome @/about.

-3RA

Meeting summary: Monero Community Workgroup, 28 September 2024

Mon, 30 Sep 2024 UTC

This is a comprehensive summary, with added reference links, of the Monero Community Workgroup meeting¹ from September 28th 2024, 1500 UTC.

Logs

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

240928-community.log (173 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 (plowsof², diego³, vostoemisio⁴, vthor⁵, illecors⁶, ofrnxmr⁷, spirobel⁸, snowman⁹, nioCat¹⁰, rucknium¹¹, tobtoht_¹²)
(1) Community highlights
- plowsof mentioned tobtoht’s recently released Feather Wallet alpha client with multisig wallet support¹³: excited to test it later with some small amounts, the UX is smoothless
- plowsof relayed vostoemisio’s request for final feedback for their CCS, which is still looking for funding¹⁴, and commented: i think everyone is still ok with whats written in that proposal.. correct the facts in the intro video @ getmonero, refresh the graphics.. in light and dark mode
  - vostoemisio shared a link to their most recent 3 new videos, at diego’s request: We never redone previously, but made 3 new ones; #6,7,8¹⁵; plowsof shared a link to vostoemisio’s video channel¹⁶
- plowsof reminded everyone that vthor recently completed their XmrSigner CCS¹⁷ with a PR to monero gui (and core) and offline signing via QR codes (as in feather and anonero)¹⁸
- plowsof was interested in updates about the ongoing Feather Wallet targeted phishing attack and linked to tobtoht’s WiP gist¹⁹
- plowsof noted that docs.getmonero.org is now running the monero-docs²⁰ master branch
(2) CCS updates
- (2.1) on DiosDelRayo/vthor’s ‘offline signing library for XmrSigner’ proposal²¹:
  - vthor replied to plowsof’s question regarding CCS edits (mainly after tobtoht’s feedback): I’m down with my nerves, my energy and now busy to get monero-gui built outside QtCreator; plowsof concluded that feedback can be postponed
- (2.2) on Spirobel’s ‘wallet-rpc library’ proposal²²:
  - plowsof underlined the fact that the proposal had some major changes since the last meeting: reduction in total and a deliverable
  - plowsof noted that a new draft proposal of an atomic swap implementation using monero-ts was recently created by mainnet_pat²³ after spirobel mentioned discussions with sneurlax and others about the monero-ts library
    - spirobel acknowledged the existence of the draft proposal: I dont see this as an either or thing, confirmed that the direction is towards web, and pointed out that he is open to talk with anyone who has questions - both publicly and privately
  - plowsof concluded that the proposal is a clear merge and invited others to comment
    - ofrnxmr asked spirobel if his library could be used by projects similar to Haveno and BTCPayServer; spirobel confirmed that it is useful for payment gateway projects
- (2.3) on HardenedSteel’s ‘2 months of part-time Getmonero.org work’ proposal²⁴:
  - plowsof noted that there are currently few monero-site contributors and 5 XMR / month seems ok
  - ofrnxmr voted for a merge, as long as HardenedSteel is still working/on board: Not sure whats going on with a couple of the active prs, if theyre still being addressed
- (2.4) on jeffro256’s ‘full-time dev work 2024Q4’ proposal²⁵:
  - rucknium noted that they thumb-ed up the proposal after jeffro256 removed wallet-side FCMP tree building
  - ofrnxmr was in favor: Jeffro’s always available to push core prs and reviews
  - nioCat voted yes: he will work on whatever is needed
  - plowsof, tobtoht, diego - all voted for a merge
- (2.5) on mainnet_pat’s ‘XMR-BCH atomic swaps’ proposal (draft)²⁶:
  - ofrnxmr noted that pat will potentially be adding bch atomic swaps to basicswap; Stalled for 3 weeks (so far) due to payout
  - rucknium pointed out that mainnet_pat needs to explain why 175 BCH wasn’t enough to complete the original work in the Flipstarter²⁷ and also what role BCHautist has played so far: I assumed that the delay was because pat and Mr-Zwets were re-factoring the Cashonize wallet, which seemed to be a basis for Monujo. I may be wrong.
(3) AOB
- ofrnxmr was interested in discussing overpayments to ccs and purgatory ccs funds²⁸: I want to vote on making this change officially at next meeting. Keeping funds in ccs; funds should be able to be used like haveno’s. no need to make requests from GF
- rucknium asked diego if he can work with pat to find a better name for Monujo²⁹ by using rejected names that he came up with for Stack wallet
/end

Let me know if you found this report helpful.

Feedback, suggestions and edits always welcome @/about/.

-3RA

/monero-community-workgroup-meeting-28-september-2024/ ↩
https://github.com/plowsof/ ↩
@diego:cypherstack.com ↩
@vostoemisio:matrix.org ↩
https://github.com/DiosDelRayo/ ↩
@illecors:matrix.org ↩
https://github.com/nahuhh/ ↩
https://github.com/spirobel/ ↩
@snowman:tetaneutral.net (Matrix) ↩
nioCat (IRC/Libera) ↩
https://github.com/Rucknium/ ↩
https://github.com/tobtoht/ ↩
/plowsof-20/ ↩
/vostoemisio-animated-videos-ccs-proposal-ready-funding/ ↩
https://www.getmonero.org/get-started/faq/#videos ↩
https://redirect.invidious.io/@VostoEmisio ↩
/diosdelrayo-completes-xmrsigner-ccs-proposal/ ↩
https://github.com/monero-project/monero/pull/9492, https://github.com/monero-project/monero-gui/pull/4358 ↩
https://gist.github.com/tobtoht/4039fa3cf922d4fe8bca2f8e3ddac63b ↩
https://github.com/monero-project/monero-docs/ ↩
/diosdelrayo-ccs-proposal-offline-signing-library-xmrsigner/ ↩
/spirobel-submits-ccs-proposal-robust-modular-wallet-rpc-library/ ↩
/mainnet_pat/ ↩
/hardenedsteel-submits-ccs-proposal-2-months-part-time-getmonero-org-work/ ↩
/jeffro256-submits-full-time-monero-carrot-dev-work-ccs-proposal-q4-2024/ ↩
https://paste.debian.net/1330674/ ↩
https://atomic-flip.pat.mn/en, https://gist.github.com/mainnet-pat/267fe6f0111ce2198559b3e19040ba26 ↩
https://github.com/plowsof/scrape_ccs_fr/tree/main ↩
/mainnet-pat-teases-bch-xmr-atomic-swaps-wallet-monujo/ ↩

Meeting summary: Monero Research Lab, 31 July 2024

Tue, 06 Aug 2024 UTC

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from July 31st 2024, 1700 UTC.

Logs

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

240731-mrl.log (73 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 (rucknium², vtnerd³, jeffro256⁴, rbrunner⁵, one-horse-wagon⁶, 0xfffc⁷, jberman⁸, kayabanerve⁹, sgp_¹⁰, basses¹¹, aaron¹²)
(1) Updates
- rucknium was reading papers on gossip protocols and their privacy, bandwidth, and speed and commenting on some tx broadcast PRs (probably #9334¹³)
- vtnerd was doing LWS frontend stuff¹⁴ while working on jeffro256’s blockchain syncing PR¹⁵
- 0xfffc started implementing Boog900’s proposal to change how transactions are broadcasted to significantly reduce P2P bandwidth usage¹³ while reading the Erlay paper¹⁶ trying to get familiarized with broadcast mechanisms
- jeffro256 was writing the documentation for Carrot (Cryptonote Address on Rerandomizable-RingCT-Output Transactions) addressing protocol¹⁷
- kayabanerve reported preparing crates for auditing¹⁸
- jberman was working on adding fcmp++’s to the cryptonote::transaction class
(2) Open discussions
- (2.1) on ‘Stress testing monerod’¹⁹:
  - rucknium reported that spackle-xmr released Monero Stressnet Node v250.18.3.3.3²⁰: it pulled in everything that is in the new monero master plus the invalid blocks fix and jeffro256’s PR to reduce tx writes from 2 to 1
  - one-horse-wagon thought that the stressnet should not end until every stress idea has been exhausted
    - 0xfffc noted that they and rucknium will maintain the repo after Aug 8-9 when spackle-xmr is scheduled to leave the stressnet project: we expect to continue stress-net but with much less nodes
    - rucknium confirmed that’s the loose plan
- (2.2) on ‘Potential measures against a black marble attack’²¹:
  - rucknium mentioned that the AntiDarknet group claimed responsibility for the suspected spam transactions earlier this year²²
  - kayabanerve commented that there was no evidence of their claims, and it didn’t completely make sense
  - jeffro256 agreed with kayabanerve, noting that the claim is currently unverified, added that it might be a mistake to assume that a black marble attack did not occur because some rando on a forum said so, and shared a link to a potential followup²³
  - rucknium did not disagree, but pointed to the fact that they did say something that a person who prepared spam txs would know: that wallet2 does not perform well when 200,000 accounts are created
  - rucknium thought that it would be bad for user privacy if the suspected spammer actually released the spam wallet(s) view key(s); kayabanerve agreed
- (2.3) on ‘Pre-Seraphis Full-Chain Membership Proofs’ research²⁴:
  - kayabanerve noted that Veridise is moving forward with the R1CS gadget for evaluating this week, and there’s preliminary opinions on the GBP proof review
    - aaron was very curious on the GBP opinion and shared that the Cypher Stack review of the Veridise report should be released to kayabanerve today as an initial draft for comment
  - rucknium shared a link to a Bulletproofs++ paper that introduces some clarification and corrections²⁵
  - jeffro256 was interested in potential auditors for the new addressing protocol (Jamtis or Carrot)
    - aaron thought that CS should put in a bid for reviewing the new addressing protocol
  - rucknium mentioned Cypher Stack’s review of the Salvium protocol²⁶ that seemed to add return addresses to Monero-like txs, which has been on getmonero.org’s roadmap for a while²⁷
    - rbrunner thought that the Salvium project was pretty ambitious and was confident that CS were in a good spot to review Monero stuff as well

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

Feedback, edits always welcome @/about.

-3RA

/monero-research-lab-meeting-31-july-2024/ ↩
https://github.com/Rucknium/ ↩
https://github.com/vtnerd/ ↩
https://github.com/jeffro256/ ↩
https://github.com/rbrunner7/ ↩
@one-horse-wagon:monero.social ↩
https://github.com/0xFFFC0000/ ↩
https://github.com/j-berman/ ↩
https://github.com/kayabaNerve/ ↩
@sgp_:monero.social ↩
@basses:matrix.org ↩
https://github.com/AaronFeickert/ ↩
https://github.com/monero-project/monero/issues/9334 ↩ ↩²
https://github.com/vtnerd/monero-lws/ ↩
https://github.com/monero-project/monero/pull/9135 ↩
https://arxiv.org/abs/1905.10518 ↩
https://github.com/jeffro256/carrot/blob/master/release/carrot_0.1.md ↩
https://github.com/serai-dex/serai/pull/584 ↩
https://github.com/monero-project/monero/issues/9348 ↩
/spackle-xmr-releases-monero-stressnet-node-v250.18.3.3.3/ ↩
https://github.com/monero-project/research-lab/issues/119 ↩
/antidarknet-collective-claims-responsibility-suspected-monero-spam-attack/ ↩
https://antidark.net/board/viewtopic.php?t=15 ↩
/kayabanerve-submits-ccs-proposal-full-chain-membership-proofs/, https://www.getmonero.org/2024/04/27/fcmps.html ↩
(!PDF) https://distributedlab.com/whitepaper/Bulletproofs-Construction-and-Examples.pdf ↩
https://github.com/salvium/salvium/ ↩
(!PDF) https://github.com/cypherstack/salvium-review/releases/download/final/final.pdf ↩

Meeting summary: Monero Research Lab, 19 June 2024

Thu, 20 Jun 2024 UTC

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

Logs

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

240619-mrl.log (81 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: 10 (rucknium², isthmus³, rbrunner⁴, kayabanerve⁵, vtnerd⁶, spackle⁷, jberman⁸, emsczkp⁹, 0xfffc¹⁰, aaron¹¹)
(1) Updates
- isthmus was working on their library for detecting a particular anomaly created by some non-wallet2 codebase that caches decoys and reuses them¹²
- rucknium created a Shiny app to collect and display stressnet data¹³, set up a stressnet explorer¹⁴ and wrote a transaction spamming script
- jberman was still working on the fcmp trim_tree algo implementation
- kayabanerve presented at Monerokon¹⁵ and had an update on the Veridise audit¹⁶
- vtnerd finished stress testing LWS remote scanning and found one outstanding bug report that was unrelated to remote scanning¹⁷; he was also working on updating the serialization code and was planning to reduce the PR in order to attract more reviews
- emsczkp was working on the implementation of the compressed sigma-ipa and compared it with bp ipa
(2) Open discussions
- (2.1) on ‘Stress testing monerod’¹⁸:
  - rucknium shared a link to Boog900’s Monero Stress Testing Tools¹⁹ after noting that the node died earlier: xmrblocks uses more RAM and CPU than I expected
  - rucknium invited Monero protocol developers who want to test performance patches to sync a node to stressnet: It’s a good time now to test. AFAIK we want to run stressnet for about two months.²⁰
  - rbrunner was wondering if there are any plans for coordinated spamming
    - rucknium replied that the spam timing will be loosely coordinated
- (2.2) on ‘Potential measures against a black marble attack’²¹:
  - rucknium didn’t have anything to add to this agenda item: I think I will have the update that gives Alice a budget constraint by next meeting.
- (2.3) on ‘Pre-Seraphis Full-Chain Membership Proofs’ research²²:
  - kayabanerve announced that Veridise has completed a proof of the divisor technique and was hoping to have a quote for the review of the proofs by next meeting
    - aaron was interested if that was publicly available; kayabanerve replied that he will share it ideally in a few days as soon as he gets the final PDF or their confirmation that the one thus far shared is okay to publish
  - emsczkp stated that their implementation was showing a 50% optimization on verification times compared to the BP’s IPA
    - kayabanerve asked for a link and wanted to find out if emsczkp was intending to delaying the verification to a final multiexp
    - emsczkp posted a link to the IV-IPA public repository²³ and replied that they haven’t implemented the multi-exp version yet and was working on it
    - aaron was wondering if this approach was formalized anywhere; rucknium and emsczkp confirmed and pointed to the relevant research paper: Scala, E., & Mostarda, L. 2024, Efficient inner-product argument from compressed $sigma$-protocols and applications²⁴
    - kayabanerve was ready to move to auditing after disclosing that he has been soliciting review of the GBP proofs for a week or so: There’s one candidate in mind so I’m hoping that works out. Else, it’ll be another candidate spread, likely Goodell and one or two other groups.
    - aaron confirmed to kayabanerve that the report made available at the CS repository should be fine for review by anyone interested²⁵ and that they did reach out to the original authors in early May, but did not hear back

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

Feedback, edits always welcome @/about.

-3RA

Meeting summary: Monero Research Lab, 15 May 2024

Sat, 18 May 2024 UTC

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³, chaser⁴, rbrunner⁵, articmine⁶, jeffro256⁷, jberman⁸, kayabanerve⁹, rottenwheel¹⁰, sgp_¹¹, hinto¹², diego¹³, aaron¹⁴)
(1) Updates
- kayabanerve 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
- 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)¹⁷
  - 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’¹⁸:
  - rucknium 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%'
```
  - rucknium 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²⁰:
  - 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
    - 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)
  - 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 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
    - 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.5²³) 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

Meeting summary: Monero Research Lab, 14 February 2024

Thu, 15 Feb 2024 UTC

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

Logs

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

240214-mrl.log (144 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: 7 (rucknium², dangerousfreedom³, alex⁴, jeffro256⁵, rbrunner⁶, xFFFC0000⁷, plowsof⁸)
(1) Updates
- rucknium was working on both OSPEAD⁹ and some empirical analysis of unlock time
- jeffro256 was working on seraphis tx serialization¹⁰
- xFFFC0000 was working on fixing locking mechanism on blockchain.cpp¹¹
(2) Open discussions
- (2.1) on ‘Removing/Fixing/Encrypting monero’s timelocks’¹²:
  - rbrunner noted that his recent Reddit post (‘Timelocks: Let us finally retire a rarely used and dangerous feature of Monero’¹³) has 99% upvotes: I would guess 8 or even 9 out of every 10 comments are pro removal
  - rucknium linked to their recent analysis¹⁴ which includes usage stats and some estimates of the privacy impact on users who are creating txs with custom lock times and noted that 95% of custom unlock times have no effect since the wallet developer(s) do not understand that block height is absolute and also the real spend can be correctly guessed in 34-91% of the custom unlock times that I evaluated
    - jeffro256 suggested the possibility that developers actually DO understand that the height is absolute, but they’re putting other meta information in that field
  - alex pointed out that timelocks can be a good feature and shared how LocalMonero¹⁵ occasionally uses it to disincentivize users that repeatedly ignore bans from trying to return to the platform: we take the XMR that they placed in the arbitration bond and send it to them in a timelocked transaction to disincentivize them from trying to return again
    - plowsof was unhappy with LM’s usage of timelocks: The fact that you can punish people (deserving or not) is terrible
    - rbrunner acknowledged that timelocks do have uses - including alex’s use case which has a novel edge - but remained skeptical that they are net positive: for me they in no way outweigh the negatives
  - rucknium was wondering if a compromise was possible: Maybe wallet2 can consider custom-locked outputs as “not received” by default
  - alex mentioned other cases where a timelocked tx might be useful: where a person might know ahead of time that they will be entering a dangerous situation (travel, jail, mandatory conscription, etc) and want to ensure that their coins will not be spent until they are out of the situation, so they send themselves a timelocked tx
    - rbrunner noted that some use cases with rents, subscriptions and similar pay-ahead things can be very dangerous if circumstances change, and the XMR absolutely can’t
  - jeffro256 thought that LM’s use case can be replicated by choosing to send the funds later or sending to a time lock puzzle¹⁶
    - alex replied to jeffro256 noting that a timelocked transaction is better than choosing to send the funds later: the person might start to claim that we never intend to send them and start some sort of reputation damaging action
    - jeffro256 suggested sending the funds in a time lock puzzle and proving that they will be able to access the funds after s bounded amount of computation; alex was interested, although unsure how to implement it
  - jeffro256 listed the main concerns with time locks for 99.9% users:
    - 1) receiving time locked funds leads to confusion why it isnt spendable
    - 2) you can’t pick locked decoys which degrades on chain privacy and makes making non fingerprint able decoy selection harder
    - 3) you cant pick locked decoys which can open you up to privacy attacks from an untrusted daemon
    - 4) it makes transactions less uniform which degrades on chain privacy
  - alex was considering the fact that the lock is per TX as opposed to per output to be the actual unintuitive part
  - plowsof thought that by merging jeffro256’s PR (‘Enforce Tx unlocktime is Zero by Relay Rule’¹⁷) instead of disabling with a hardfork could encourage devs to not care about unlock_time
    - rbrunner noted that a separate discussion might be needed for this topic, but only if/after consensus to remove the feature is first reached
  - rucknium pointed out a bigger issue that needs to be solved, which is Nonstandard txs fees¹⁸: Right now usage of custom unlock time is very low. Nonstandard txs fees, which about 5% of txs use now I think, are a much bigger problem
  - alex finally agreed with rbrunner and noted that the simplicty and privacy of the XMR protocol is more important than [LM’s] use case and was cool with the removal of timelocks: If it’s a hazard to privacy it should be removed, just like tx_extra.
  - rucknium was keen to point out that locked transactions are not just a theoretical risk and linked to a 2023 discussion¹⁹ about 133 XMR that were blocked for a period of 4 years
  - dangerousfreedom was in favor of disabling it (for the sake of privacy) for future transactions but not void the current ones that uses it and suggested using a robust and easy to use multisig to fix many of the timelock issues
  - alex concluded that existing timelocks should be honored, but for the sake of simplifying XMR and strengthening privacy they should be removed, assuming that time lock puzzles are a practical solutions as jeffro256 says
    - jeffro256 agreed with alex: no more new non-zero tx unlock times, but honor the old unlock times
  - rucknium noted that having the off-chain time lock puzzles working would be a good compromise
  - jeffro256 was ready to discuss some extra issues, including a slight change to the unix-time-based unlock times, a small modification to the consensus rules also related to the unlock time, and disallowing v1 transactions for “unmixable” input amounts in the next network upgrade but rbrunner pointed out that those issues would need a handful of meetings
    - rbrunner suggested xFFFC0000 could look into off-chain time lock puzzles; xFFFC0000 agreed to take a look after fixing the locking mechanism on blockchain.cpp

Update: added reference link to time-lock puzzles technical report¹⁶ (credit to Rucknium for sharing link).

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

Feedback, edits always welcome @/about.

-3RA

Meeting summary: Monero Research Lab, 10 January 2024

Thu, 11 Jan 2024 UTC

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

Logs

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

240110-mrl.log (65 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: 4 (Rucknium², rbrunner³, tobtoht⁴, chaserene⁵)
(1) Updates
- (1.1) on the Multisig Messaging System⁶:
  - tobtoht has integrated most of the MMS in Feather Wallet, finished a first iteration for a wizard that guides users through setting up a new multisig wallet, shared a PoC for sending a 2/3 transaction, and was hoping to have a MVP ready soon
- (1.2) on OSPEAD⁷ and Monero research papers⁸:
  - Rucknium was working on OSPEAD and reported the addition of about 20 recent papers to moneroresearch.info
- (1.3) on BCH-XMR atomic swaps⁹:
  - Rucknium mentioned the first ever mainnet BCH-XMR atomic swap performed by PHCitizen¹⁰ and pat’s fundraiser for a BCH<>XMR atomic swap frontend¹¹
(2) Open discussions
- (2.1) on the MMS code:
  - tobtoht was impressed with the MMS: beautifully written and the abundance of clearly written comments make it easy to understand and a joy to read
- (2.2) on BCH community support for BCH-XMR atomic swap development:
  - Rucknium confirmed to rbrunner that the BCH community is indeed interested in the swaps, as BCH developers created the swap implementation¹², and the BCH fundraiser for a front-end¹¹ already received 101 BCH in 4 days
- (2.3) on new Moneroresearch.info papers summaries:
  - rbrunner was wondering if there is anything directly about Monero in the new papers; Rucknium noted that there are a few useful papers that mention Monero, besides a few others that are focused on ‘How can we create a Monero-like system, but allow a central authority info about tx information’
  - Rucknium shared short summaries for several relevant papers:
    - Vijayakumaran (2023) ‘Analysis of Cryptonote transaction graphs using the Dulmage-Mendelsohn decomposition’¹³ (potentially relevant to Mordinal analysis when ‘black marbles’ reduce the effective ring size)
    - Wang, Lin, Huang, & He (2023). ‘Anonymity-enhancing multi-hop locks for Monero-enabled payment channel networks.’¹⁴ (a N + 1 of payment channel network (PCN) on Monero)
    - Buccafurri, De Angelis, & Lazzaro, (2023) ‘A traffic-analysis proof solution to allow k-anonymous payments in pseudonymous blockchains.’¹⁵ (a possible replacement for Dandelion++ according to Rucknium)
    - Scheid, Küng, Franco, & Stiller (2023) ‘Opening Pandora’s box: An analysis of the usage of the data field in blockchains’¹⁶ (potentially useful for Mordinal analysis)
    - Dijk & Schröder (2023). ‘Proof of concept for a Ethereum virtual machine on Cryptonote.’¹⁷ (Rucknium considered the PoC to be just embed plaintext Ethereum contracts in tx_extra and noted that this paper could be sent to anyone that asks ‘how can smart contracts exist on Monero?’)
    - Movsowitz Davidow, Manevich, & Toch (2023) ‘Privacy-Preserving Transactions with Verifiable Local Differential Privacy.’¹⁸ (Rucknium thought that this could help with keeping file data out of Monero signatures and with requiring a specific decoy selection algorithm, but noted it requires a trusted setup)
  - Rucknium invited meeting participants to add papers or write their own notes about the papers: I can create a user for you
  - chaserene proposed putting some [papers] in the ‘Open Research Q’s’ GH issue¹⁹; Rucknium agreed to add the PCN paper and noted that 3 other payment channel papers are already listed in the open research questions list
- (2.4) on JAMTIS²⁰:
  - Rucknium reposted chaserene’s pre-meeting question: could there be a method of of deriving Jamtis addresses such that once/if EdDSA is swapped for a post-quantum sig algo, the addresses remain the same? I’m very quietly hopeful because this would mean the migration could be undetectable from an end-user perspective
  - No one was able to answer chaserene’s question, but rbrunner had a a gut feeling that the answer is no

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

Feedback, edits always welcome @/about.

-3RA

Meeting summary: Monero Community Workgroup, 11 November 2023

Sun, 12 Nov 2023 UTC

This is a comprehensive summary, with added reference links, of the Monero Community Workgroup meeting¹ from November 11th 2023, 1500 UTC.

Logs

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

231111-community.log (361 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: 17 (plowsof², binaryFate³, sneedlewoods_xmr⁴, ofrnxmr⁵, rbrunner7⁶, ctrej⁷, spackle_xmr⁸, rucknium⁹, btclovera¹⁰, hinto.janaiyo¹¹, nioc¹², tuxsudo¹³, v1docq47¹⁴, selsta¹⁵, luigi1111¹⁶, lordx3nu¹⁷, midipoet¹⁸)
Focus: The future of the CCS after the recent incident¹⁹
- plowsof recommended skipping the CCS ideas list²⁰: The agenda/goal of this meeting should be to help clarify where Core and the community are at in terms of short / long term solutions for a path forward, whilsts disrupting Moneros development as little as possible
- ofrnxmr was keen to get [the] ball rolling in the short term and focus on setting up the infrastructure for funds moving forward in the long term (2-4 weeks)
- plowsof noted that the Monerokon events team went their own way for funding²¹ and are planning to return to the CCS in spring~ depending on how things are resolved
- Rucknium reminded everyone that the MAGIC Monero Fund²² was unaffected by the CCS wallet theft
- plowsof hinted at the fact that Monero multisig is still experimental²³
- Rucknium was against security through obscurity in the eventuality that the CCS would end up using escrow again: the process to create and manage the wallet should be documented publicly
- plowsof was wondering if binaryFate would agree to create a seperate [secure] ccs wallet and send funds from this new wallet on to luigi (for payouts);
  - ofrnxmr was opposed to the idea, hinting at the fact that binaryFate already has too much responsibility as he is also holding the keys to the General Fund wallet;
    - selsta suggested a separate discussion for the GF
- binaryFate asked the community if there would be support for delegating full responsibility for the wallet to luigi1111;
  - ofrnxmr was against the idea, unless luigi would be a multisig signer: not solo. Worst opsec.;
  - Rucknium pointed out to the probable lack of trust in luigi from the perspective of potential donors;
  - nioc noted that they would be fine with luigi in charge;
  - tuxsudo and btclovera both objected and mentioned the OPSEC failure;
  - rbrunner7 noted that no one knows how luigi was targeted and that could be reason enough to choose somebody else for the time being;
    - nioc agreed with rbrunner7’s line of thought
- ctrej was wondering if it would be possible to temporarily use a ledger or trezor until the community figures out multisig proper;
  - plowsof pointed out that a hardware wallet would have defeated the evil hackers
- Rucknium floated the idea of direct funding to workers’ XMR wallets as a short term solution;
  - ofrnxmr was interested in isolating the GF from the CCS: Core needs to use that GF to deal with infra; they dont need to be bank tellers
- ctrej was looking for a guide or a link collection for hardening a PC (removing intelME²⁴ etc.);
  - plowsof linked tobtoht’s osresearch.net website²⁵
- selsta suggested a potential workflow/setup: luigi can for example use a hardware wallet for a hot wallet to payout devs while the cold wallet that gets the actual funds are in someone else’s hands
- hinto.janaiyo was wondering who would be trusted enough to hold funds long term, before suggesting plowsof as a temporary custodian;
  - ofrnxmr voted for plowsof to handle the new wallet, but wanted multisig for the long term;
  - btclovera nominated both binaryFate and plowsof and suggested RINO²⁶ or some multisig schema and then also recommended Vik from cake wallet;
  - sneedlewoods_xmr thought that plowsof is trustworthy for the new short term wallet;
  - rbrunner7 wondered if plowsof would agree to take the responsibility
- binaryFate stated that he is not comfortable piggybacking on different wallet when we have different requirements on how frequently to access funds in response to rbrunner7’s suggestion to use the GF security setup to create a new wallet
- Rucknium was looking for a direct answer from plowsof to the obvious question: do you want this responsibility?;
  - plowsof replied: i would like more responsibility, but my first rodeo should not be ‘the CCS wallet’
- Rucknium recommended going with the direct funding with no escrow option as there is (currently) no arrangement that satisfies all groups - donors, workers, people that vet proposals, and the escrower;
  - hinto.janaiyo wanted to know if proposers would directly receive funds even before milestones are complete;
    - Rucknium confirmed (yes)
- ofrnxmr nominated selsta as a potential candidate;
  - selsta was not interested
- nioc indirectly suggested Rucknium
- plowsof assured everyone that the work in progress proposals are covered by the general fund / have already been paid out
- Rucknium mentioned that binaryFate is probably already escrowing the bounties.monero.social²⁷ funds;
  - binaryFate confirmed: I escrow the bounties wallet and perform payouts as directed to me (usually by plowsof);
  - ofrnxmr thought that was too much for 1 person
- midipoet proposed using a custodial account at somewhere like Kraken as a short term solution: This will solve the immediate Opsec issue and also provide us some time to organise properly;
  - selsta noted a risk of Kraken locking the account due to large inflow / outflow of funds, probably get flagged by some algorithm;
  - midipoet also suggested LocalMonero, in order to benefit from the wallet’s view key;
  - selsta favored a solution that doesn’t involve a third party service
- rbrunner7 tried to redirect the discussions back to the most immediate bottleneck: finding trustworthy users that are ready to take the responsibility
- binaryFate posted his final comment of the meeting: I don’t think you should expect a magical solution from Core. In that context core and core members at most can be tools for the community to use, not much more.
- hinto.janaiyo proposed to temporarily hold future community meetings every week
- plowsof noted that consensus was reached to merge/retrofund the monero-core/seraphis devs proposals
- selsta was more interested in using the CCS instead of direct funding
- rbrunner7 thought that the CCS is an important cornerstone of our “culture”, of our “identity”. More than a simple tool to pay people.
/end

Let me know if you found this report helpful.

Feedback, suggestions and edits always welcome @/about/.

-3RA

/monero-community-workgroup-meeting-11-november-2023/ ↩
https://github.com/plowsof/ ↩
https://github.com/binaryFate/ ↩
https://matrix.to/#/sneedlewoods_xmr:matrix.org ↩
https://matrix.to/#/ofrnxmr:monero.social ↩
https://github.com/rbrunner7/ ↩
https://matrix.to/#/ctrej:matrix.org ↩
https://matrix.to/#/spackle_xmr:matrix.org ↩
https://github.com/Rucknium/ ↩
https://repo.getmonero.org/xmrLovera/ ↩
https://github.com/hinto-janai/ ↩
[TBD] @nioc (IRC) ↩
https://matrix.to/#/tuxsudo:tux.pizza ↩
https://github.com/v1docq47/ ↩
https://github.com/selsta/ ↩
https://github.com/luigi1111/ ↩
https://matrix.to/#/lordx3nu:matrix.org ↩
https://repo.getmonero.org/midipoet/ ↩
/luigi-discloses-critical-ccs-wallet-breach/ ↩
https://ccs.getmonero.org/ideas/ ↩
/monerokon-to-abandon-ccs-for-self-hosted-crowdfunding-solution/, https://funding.monerokon.com/ ↩
/jehrenhofer-announces-magic-grants-monero-fund/, https://monerofund.org/ ↩
https://libera.monerologs.net/monero-research-lab/20231108#c301310 ↩
/cypherpunk-transmission-016-1vyrain-soft-disable-intel-me-xx30-thinkpads/ ↩
https://osresearch.net/ ↩
/rino-wallet-live-mainnet/, https://rino.io/ ↩
https://bounties.monero.social/ ↩

Meeting summary: Seraphis Wallet Workgroup, 9 October 2023

Fri, 13 Oct 2023 UTC

This is a comprehensive summary, with added reference links, of the Seraphis Wallet Workgroup meeting¹ from October 9th 2023, 1800 UTC.

Logs

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

231009-seraphis.log (28 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: 3 (rbrunner7², dangerousfreedom³, jberman⁴)
On Seraphis⁵ progress reports and planned work:
dangerousfreedom cleaned up tx_history and invited contributors to review his Initial tx history draft PR #1⁶: comments about the functionality and the direction are very welcome; rbrunner7 promised to have a look and suggested that jberman’s input would be welcome
dangerousfreedom also wrote the most basic naked version of a variant⁷ in reply to the transaction_class issue⁸
jberman announced the completion of his final TODO’s on the background sync PR #8619⁹ and invited reviews before submitting the changes; he was looking to return to Seraphis work by the end of the week - most likely on fcmp’s (full chain membership proofs¹⁰)
dangerousfreedom was planning to begin working on tasks listed in his most recent CCS proposal (!409)¹¹ for the next weeks, starting with the creation of basic functions for wallet initialization, program flow and terminal handling
rbrunner7 asked jberman how soon we could expect a PR for his scanning code¹²; jberman estimated 2-3 days for a draft PR and 1-2 weeks of work for a completed PR

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

Feedback, edits always welcome @/about.

-3RA

Meeting summary: Monero Research Lab, 4 October 2023

Sat, 07 Oct 2023 UTC

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from October 4th 2023, 1700 UTC.

Logs

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

231004-mrl.log (86 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: 5 (Rucknium², tevador³, jeffro256⁴, rbrunner⁵, UkoeHB⁶)
(1) Updates
- (1.1) on JAMTIS, wallet2’s decoy selection algorithm⁷:
  - jeffro256 has been working with Rucknium, discussing and implementing Jamtis changes, trying to formalize wallet2 decoy selection algorithm
- (1.2) on statistical research:
  - Rucknium was also working on excluding the set of txs with nonstandard fees from analysis of on-chain ring member age⁸
(2) Open discussions
- (2.1) on JAMTIS design changes:
  - tevador asked if there was enough consensus to go forward with the Jamtis changes
  - jeffro256 was looking to dive deeper into one issue⁹ that he recently mentioned on the JAMITS gist: multiple self-send enotes within a transaction creates a significant statistical fingerprint for finding outgoing enotes for anyone with knowledge of the find-received/assist-filter/filter-involved key
  - tevador generally agreed with the change regarding self-send enotes, but noted that it has a potential to increase the required wallet traffic 2.5x or more
  - jeffro256 thought that most people are already in agreement about using the extra public key to guard against third-parties knowing the nominal address tags
  - tevador brought up previous pushback against dynamic view tags and reiterated his opinion that the proposed Jamtis changes might not be worth it without them¹⁰
  - rbrunner mentioned that a Reddit poll for support of variable size viewtags only had around 40 voters in total and felt like things were still pretty much in flux, not yet ‘converging’ to a solution
  - Rucknium was interested in finding other potential use cases for pre-signed transactions, signed days+ in advance besides atomic swaps and shared a link to the LightSwap: An Atomic Swap Does Not Require Timeouts At Both Blockchains paper¹¹; jeffro256 replied, mentioning dead man switch scenarios and transaction ceremonies that can take a while to complete but don’t necessarily make fingerprintable decoy selections
  - jeffro256 thought that light wallets will take a bigger part in the ecosystem from Jamtis onwards, especially with mobile wallets
  - tevador noted that although possible to hardfork in the future to adjust the view tag, Monero would be stuck with the address format forever
  - tevador confirmed to rbrunner that deciding how many keys to have is much more important than choosing between fixed size and flexible viewtags
  - jeffro256 thought that the pros of the extra public key in the address far outweigh the downsides and proposed flexible sized view tags by hard consensus rules, but which the relay rules enforce a constant size
  - tevador noted that the 3rd key would help everyone with the Janus attack protection and a separate key to view amounts, while the 4th key would only benefit light wallet users
  - UkoeHB was wondering if consensus was reached for the proposed JAMTIS changes; jeffro256 replied that he is in agreement with tevador on most issues: a key derivation tree, public address layout, and sender-receiver secret derivation scheme if we choose to add the extra pubkey to the address, and underlined the main point of contention: how to do the view tags
  - tevador thought that a soft-rule for view tags would probably work, but considered the 3-key/4-key debate unsettled regardless of the view tag decision; jeffro256 added that a soft-rule flexible view tag would allow switching to dynamic view tags without a consensus change; tevador agreed
  - tevador was wondering if there is any data on the number of 3rd party scanners users, which could make the 4th key most likely worth it
  - rbrunner thought that light-wallet use under Jamtis has the potential to become a stampede and mentioned third-world countries where you still buy your mobile data traffic in megabytes
  - Rucknium quoted and linked fluffypony’s comment on MyMonero users/txs - Whilst we don’t disclose user numbers, I can assure you that the number of viewkeys we have is not even double-digit percentages¹², before concluding that discussions about dynamic view tag length and the 4th public key will continue in future meetings

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

Feedback, edits always welcome @/about.

-3RA

Meeting summary: Monero Research Lab, 3 May 2023

Sun, 07 May 2023 UTC

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from May 3rd 2023, 1700 UTC.

Logs

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

230503-mrl.log (53 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: 7 (UkoeHB², Rucknium³, shalit⁴, vtnerd_⁵, jeffro256⁶, ghostway⁷, kayabanerve⁸)
(1) Updates
- (1.1) on Seraphis⁹:
  - UkoeHB finished a draft of the implementing seraphis paper¹⁰
  - ghostway and shalit were both planning to restart their work on Seraphis in 2-3 weeks
- (1.2) on statistical research:
  - Rucknium was working on their Monerotopia talk (A Statistical Research Agenda for Monero¹¹)
- (1.3) on the Monero Light Wallet Server¹² and Bulletproofs++¹³:
  - vtnerd_ reported working on LWS unit-tests for webhooks and bp++, but was a little worried that he won’t be able to complete the bp++ code; Rucknium noted that the code implementation can be some time away since BP++ is still yet to be confirmed cryptographically sound
(2) Open discussions
- (2.1) on exploring trustless zk-SNARKs for Monero’s payment protocol¹⁴ and Post-Quantum Ring Signatures:
  - Rucknium proposed discussing MRL #100, wondering if any trustless zk-SNARKs are under a bounty program
  - UkoeHB had no comments about the issue
  - jeffro256 thought that the big question was if it would be better to work towards replacing Ed25519 with a prime order curves with Seraphis vs keeping ed25519 with Seraphis and changing the address scheme again later; kayabanerve didn’t see any reason to redo the migration post-Seraphis
  - Rucknium mentioned another less reviewed and battle-tested option, the quantum-resistant ring signatures¹⁵; kayabanerve noted that the main issue with PQ schemes was the lack of composability
  - kayabanerve reiterated that he doesn’t believe tevadors indirect cycle is possible: we have to prove an EC OP on the tower yet membership on the cycle. I’m unsure we can feasibly maintain ZK through that

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

Feedback, edits always welcome @/about.

-3RA

/monero-research-lab-meeting-3-may-2023/ ↩
https://github.com/UkoeHB/ ↩
https://github.com/Rucknium/ ↩
@shalit:matrix.org ↩
https://github.com/vtnerd/ ↩
https://github.com/jeffro256/ ↩
@ghostway:matrix.org ↩
https://github.com/kayabaNerve/ ↩
https://github.com/UkoeHB/Seraphis/ ↩
https://github.com/UkoeHB/Seraphis/commit/4d3ed3492b18d1f2286aa6a336d40da183b13282 ↩
https://github.com/Rucknium/presentations/blob/main/Rucknium-Monerotopia-2023-Slides.pdf ↩
https://github.com/vtnerd/monero-lws/ ↩
https://github.com/Liam-Eagen/BulletproofsPP/ ↩
https://github.com/monero-project/research-lab/issues/100 ↩
https://dl.acm.org/doi/10.1145/3319535.3354200, https://link.springer.com/chapter/10.1007/978-3-319-93638-3_32 ↩

Meeting summary: Monero Research Lab, 5 April 2023

Fri, 07 Apr 2023 UTC

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from April 5th 2023, 1700 UTC.

Logs

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

230405-mrl.log (158 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: 17 (UkoeHB², ArticMine³, compdec⁴, rbrunner⁵, Rucknium⁶, tevador⁷, hbs⁸, jeffro256⁹, vtnerd__¹⁰, narodnik¹¹, blankpage¹², ofrnxmr¹³, Alex-LocalMonero¹⁴, Lyza¹⁵, plowsof11¹⁶, sech1¹⁷, politicalweasel¹⁸)
(1) Updates
- (1.1) on decoy selection improvements & the Monero Light Wallet Server¹⁹:
  - jeffro256 implemented the solution for MRL issue #109 (Avoid selecting coinbase outputs as decoys²⁰) in PR #8815²¹
  - Rucknium started reviewing jeffro256’s code to avoid selecting coinbase outputs when spending non-coinbase outputs
  - vtnerd was working on LWS stuff and also reviewed jberman’s Decoy selection algo off-by-1 patch²²
- (1.2) on Seraphis/JAMTIS:
  - UkoeHB referenced his new CCS²³, updated the Seraphis paper²⁴ (minor cleanup, cut out implementation recommendations, simplified composition proof writeup, added grootle proof construction + security proof), and was preparing to write the jamtis-instantiation companion paper next
- (1.3) on Mordinals²⁵:
  - Rucknium noted, after monitoring the ‘Mordinals’²⁶ project, that in the last 3 days Mordinal minting has essentially ceased and announced plans to do a write-up next week on the empirical privacy effects of Mordinals (+ coinbase outputs)
- (1.4) on elliptic curves²⁷:
  - narodnik started writing the benchmarks: now im doing the normal pedersen commit, have the scheme written in sage, then will begin constructing circuits with modified ECIP proof to benchmark against normal pedersen commit
(2) Open discussions
- (2.1) on tx_extra²⁸:
  - UkoeHB reiterated his position²⁹ against removing the tx_extra field; blankpage agreed 99% with UkoeHB’s comment
  - Rucknium thought that UkoeHB’s encrypted by default statement was a little misleading to most readers if the encryption rule would have no enforcement mechanism whatsoever; UkoeHB clarified that there would not be wallet2, since the change is planned for Seraphis, and the core library would encrypt/decrypt tx extra contents by default
  - jeffro256 mostly agreed with UkoeHB’s stance, but argued in favor of making the field mandatory, assuming there is consensus to keep tx_extra: giving transaction constructors the option of having it be present is a bigger privacy issue than initially assumed
  - tevador agreed that the field should be made mandatory if the portion of transactions using tx_extra will be significant
  - UkoeHB shared what the conservative development path would look like: unconstrained -> optional -> mandatory (-> removed); ofrnxmr didn’t see a use for the in-between optional step
  - rbrunner pointed at the clear lack of consensus about the main question (‘remove’ versus ‘keep in some form’): We are stuck there
  - plowsof11 dropped in to announce that the relevant Monero version 0.18.2.2 was tagged³⁰
  - ofrnxmr was interested in tevador’s thoughts about standardizing outputs; rbrunner thought the addition of this adjacent topic to the already difficult tx_extra debate would not make things easier
  - Alex-LocalMonero thought that keeping tx_extra was signaling that arbitrary data injection has a stable standardized place on the Monero blockchain, which would be counter-productive towards Monero’s goals, concluding that arbitrary data storage on the XMR chain should be disincentivized to the greatest practical extent; however, if arbitrary data was to be stored on the chain it should look just like any other tx data
  - sech1 replied to Alex’s position, noting that arbitrary data can be stored in outputs, ~30 bytes per output and it’s impossible to stop it and a fixed small tx_extra is better than forcing arbitrary data into outputs; Alex commented that Nobody is forcing anyone to use outputs, people can use CLSAG too
  - UkoeHB announced plans to implement tx_extra pruning + optional encrypted field in the seraphis library as a temporary solution and noted that he would be open to future incremental changes
  - Alex-LocalMonero called for making arbitrary data unstable, inefficient, costly, and ideally indistinguishable from other data; sech1 was not prepared to change his opinion until a way to prevent stuffing arbitrary data into outputs is discovered; UkoeHB thought that protocol instability was the opposite of what the project should aim for; Alex disagreed in the context of arbitrary data injectors
  - rbrunner proposed abbreviating arbitrary data injectors to ADIs; Alex liked the idea
  - ofrnxmr proposed adding the standardizing in/out discussion to agenda of future MRL meetings

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

Feedback, edits always welcome @/about.

-3RA

/monero-research-lab-meeting-5-april-2023/ ↩
https://github.com/UkoeHB/ ↩
https://r.nf/user/ArticMine/ ↩
@compdec:matrix.org ↩
https://github.com/rbrunner7/ ↩
https://github.com/Rucknium/ ↩
https://github.com/tevador/ ↩
https://github.com/hbs/ ↩
https://github.com/jeffro256/ ↩
https://github.com/vtnerd/ ↩
https://github.com/narodnik/ ↩
@blankpage:matrix.org ↩
https://nitter.net/nahuhhXMR/ ↩
https://r.nf/user/Alex_LocalMonero/ ↩
TBD ↩
https://github.com/plowsof/ ↩
https://github.com/SChernykh/ ↩
@politicalweasel:matrix.org ↩
https://github.com/vtnerd/monero-lws ↩
https://github.com/monero-project/research-lab/issues/109 ↩
https://github.com/monero-project/monero/pull/8815 ↩
https://github.com/vtnerd/monero-lws/pull/64 ↩
/ukoehb-submits-seraphis-ongoing-support-ccs-proposal/ ↩
https://github.com/UkoeHB/Seraphis/ ↩
/monero-punks-inscribes-first-nft-collection-monero/ ↩
https://mordinals.org ↩
https://github.com/narodnik/arithmetic-elliptic-curves-silverman ↩
https://github.com/monero-project/monero/issues/6668 ↩
https://github.com/monero-project/monero/issues/6668#issuecomment-1476531556 ↩
/monero-v0.18.2.2-fluorine-fermi-tagged/ ↩

Meeting summary: Monero Research Lab, 8 March 2023

Tue, 14 Mar 2023 UTC

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

Logs

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

230308-mrl.log (111 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: 16 (ghostway², shalit³, UkoeHB⁴, CasCremers⁵, bewa_c⁶, dangerousfreedom⁷, ArticMine⁸, Rucknium⁹, jlo¹⁰, hbs¹¹, rbrunner¹², blankpage¹³, vtnerd¹⁴, xmrack¹⁵, AlexLocalMonero¹⁶, tevador¹⁷)
(1) Main topics
- (1.1) on the new ‘A Holistic Security Analysis of Monero Transactions’ paper¹⁸:
  - UkoeHB reminded everyone that the authors of the new preprint are attending this meeting to discuss it and answer questions [CasCremers⁶, bewa_c⁷, jlo¹¹]
  - CasCremers immediately opened up for questions after briefly introducing the team and the paper: we are three academics at the CISPA Helmholtz Center for Information Security in Germany; the paper tries to give a more complete analysis of the security of Monero transactions as opposed to the isolated analyses previously
  - dangerousfreedom was interested in several things: a) if there is any part of the security analysis that is not 100% clear and what they would potentially investigate next, b) if the analysis was purely theoretical, and then linked to some issues¹⁹ he found while attempting to make a ‘holistic’ analysis, wondering c) if it is worth to further investigate it in a formal way
  - CasCremers replied to dangerousfreedom’s first two questions: a) although there is a limitations section describing part of the analysis that were not completed yet that would be interesting to investigate, currently there is no project tailored towards that; and b) confirmed that the analysis is, indeed, theoretical
  - bewa_c jumped in to tackle dangerousfreedom’s last question: As stated in the limitations, we assume that we have a prime order group
  - UkoeHB noted that the format is fairly informal and that he is currently in the process of reviewing it (~1/4 through); he was curious if they found anything interesting/surprising during the research; jlo replied that on the practical side they did not find anything particularly surprising, confirming that Monero’s transaction system is secure in their model, but they did encounter many technical obstacles during the proof due to the non-standard uses of the crypto in the Monero transaction system
  - Rucknium invited the team to get funding for studying Monero multisig via MoneroFund²⁰ or the CCS²¹; CasCremers was interested in setting up a further project on Monero with PhD students
  - CasCremers acknowledged that they are not yet considering privacy in their work, underlining that removing the limitations and moving closer to the implementation is very challenging
  - Rucknium wondered what motivated the team to write the paper and focus on studying Monero; CasCremers replied that it seemed like a sizeable challenge of scientific interest from a proof technique angle
  - UkoeHB noted that he was not expecting such an impressive paper, having assumed that the task was too large for anyone to tackle; CasCremers stated that work took over a year
  - Rucknium mentioned that the Monero Project will most probably need help with creating formal security proofs for some of Seraphis²²; UkoeHB confirmed that the holistic analysis paper will be a very strong starting point for a security analysis of seraphis
  - ArticMine mentioned that extensive audit work will also be required
  - CasCremers asked about the intended timeline for Seraphis; UkoeHB shared his keenness to get security proofs done this year, as the implementation and addressing scheme (JAMTIS²³) are already done
  - CasCremers was interested and proposed discussing options in a separate mail discussion; Rucknium and UkoeHB agreed
- (1.2) on exploring trustless zk-SNARKs for Monero’s payment protocol²⁴:
  - UkoeHB noted that there may not be enough time to discuss other agenda items and asked if anyone had a topic they wanted to discuss; AlexLocalMonero suggested MRL #100 (zk-SNARKs)
  - UkoeHB asked tevador and kayabanerve to summarize where #100 is heading
  - tevador noted that he is currently looking for curve cycles that are compatible with ed25519 and suggested that the next step would be prototyping curve trees in sage with the seraphis key format
  - UkoeHB wondered if that is different from the indirect cycle²⁵; tevador replied that he is looking for a better cycle that has 255-bit fields instead of 266 bits for performance reasons
  - ArticMine asked if the approach would require a transaction format change after Seraphis; UkoeHB stated that it would require switching out the membership proof and a bunch of implementation work to handle merkle trees
  - ArticMine wanted to know the rough size for a 2 in 2 out transaction; tevador repied that the Curve Trees demo was around 4 KB for 2/2, with 1 merged proof for both inputs
(2) Open discussions
- (2.1) on MoneroKon 2023²⁶:
  - blankpage invited everyone to submit proposals²⁷ to present at Monerokon in Prague in June, and suggested spreading the message to other relevant researchers

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

Feedback, edits always welcome @/about.

-3RA

/monero-research-lab-meeting-8-march-2023/ ↩
@ghostway:matrix.org ↩
@shalit:matrix.org ↩
https://github.com/UkoeHB/ ↩
@CasCremers:matrix.org ↩
@bewa_c:matrix.org ↩ ↩²
https://github.com/DangerousFreedom1984/ ↩ ↩²
https://r.nf/user/ArticMine/ ↩
https://github.com/Rucknium/ ↩
@jlo:matrix.org ↩
https://github.com/hbs/ ↩ ↩²
https://github.com/rbrunner7/ ↩
@blankpage:matrix.org ↩
https://github.com/vtnerd/ ↩
@xmrack:matrix.org ↩
https://r.nf/user/Alex_LocalMonero/ ↩
https://github.com/tevador/ ↩
https://eprint.iacr.org/2023/321 ↩
https://www.moneroinflation.com/issues ↩
https://monerofund.org/apply_research ↩
https://ccs.getmonero.org/what-is-ccs/ ↩
https://github.com/UkoeHB/Seraphis/ ↩
https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024 ↩
https://github.com/monero-project/research-lab/issues/100 ↩
https://github.com/monero-project/research-lab/issues/100#issuecomment-1443923679 ↩
https://monerokon.com/ ↩
https://cfp.monerokon.com/2023/cfp ↩

Meeting summary: Monero Research Lab, 1 March 2023

Tue, 07 Mar 2023 UTC

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¹⁶.

/monero-research-lab-meeting-1-march-2023/ ↩
https://github.com/UkoeHB/ ↩
https://github.com/tevador/ ↩
https://github.com/rbrunner7/ ↩
https://github.com/One-horse-wagon/ ↩
https://github.com/Rucknium/ ↩
https://r.nf/user/ArticMine/ ↩
https://github.com/SChernykh/ ↩
https://github.com/hbs/ ↩
https://github.com/moneromooo-monero/ ↩
@ofrnxmr:matrix.org ↩
@ghostway:matrix.org ↩
https://github.com/monero-project/research-lab/issues/100 ↩
https://github.com/Rucknium/OSPEAD, /rucknium-ospead-ccs-proposal/ ↩
https://github.com/monero-project/monero/issues/6668 ↩ ↩²
https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/375#note_20836 ↩ ↩²
https://github.com/UkoeHB/Seraphis/ ↩
https://github.com/UkoeHB/monero/pull/5 ↩
https://gist.github.com/UkoeHB/f508a6ad973fbf85195403057e87449e ↩ ↩²
https://github.com/monero-project/monero/pull/8733 ↩

Meeting summary: Monero Research Lab, 18 January 2023

Tue, 24 Jan 2023 UTC

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from January 18th 2023, 1700 UTC.

Logs

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

230118-mrl.log (83 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: 7 (UkoeHB², Rucknium³, rbrunner⁴, vtnerd⁵, one-horse-wagon⁶, dangerousfreedom⁷, isthmus⁸)
(1) Updates
- (1.1) on Seraphis⁹:
  - UkoeHB continued cleanup of the seraphis library¹⁰ (ie. updated the legacy balance recovery stuff to support non-default hw devices)
  - dangerousfreedom was still working on the knowledge proofs
- (1.2) on Monero Light Wallet Server¹¹:
  - vtnerd added admin-rest-api functions to monero-lws¹² and was looking forward to working on Bulletproofs++¹³
- (1.3) on statistical analysis, privacy, fungibility, P2Pool research¹⁴:
  - Rucknium did some historical analysis of the P2Pool outputs issue¹⁵ and how that affects the privacy of non-mining users
  - ishtmus has been doing housekeeping on the fungibility defect labeling framework and other drafts
(2) Open discussions
- (2.1) on Seraphis⁹:
  - UkoeHB attempted to initiate a discussion about the tradeoff/issue of having seraphis tx implementations in separate structures versus the alternative of making every tx component a variant
- (2.2) on OSPEAD¹⁶ and MAGIC Monero Fund¹⁷:
  - Rucknium was still waiting for ArticMine’s feedback on his draft: it’s been 4 months so at some point I will just have to implement the plan in the document hyc and isthmus gave a green light to the general plan¹⁸
  - Rucknium also noted that OSPEAD will have some blind spots due to lack of C++ support after other members of the MAGIC Monero Committee voted to close mj’s fundraiser¹⁹ due to a lack of funds raised after two months
  - UkoeHB was wondering how much code is needed to get OSPEAD in shape; Rucknium shared a very rough guess: the total number of C++ lines that would need to be written for tasks 1 - 3 there is…maybe 2k
  - isthmus was curious if the analysis code could be written in something other than C++; Rucknium thought that a fast language like C, Rust, and even Fortran would be nice and revealed that he is planning to write it in R; hyc noted that Fortran might actually be most appropriate for the job
  - rbrunner suggested a somewhat pragmatic first attempt to get ‘something’ better than now out of the door; Rucknium agreed and underlined that not having fast code doesn’t stop the project: It creates some blind spots. I will make it work with the resources that we have.

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

Feedback, edits always welcome @/about.

-3RA

/monero-research-lab-meeting-18-january-2023/ ↩
https://github.com/UkoeHB/ ↩
https://github.com/Rucknium/ ↩
https://github.com/rbrunner7/ ↩
https://github.com/vtnerd/ ↩
https://github.com/One-horse-wagon/ ↩
https://github.com/DangerousFreedom1984/ ↩
https://github.com/mitchellpkt/ ↩
https://github.com/UkoeHB/Seraphis/ ↩ ↩²
/ukoehb-submits-long-term-seraphis-library-ccs-proposal/ ↩
https://github.com/vtnerd/monero-lws/ ↩
https://github.com/vtnerd/monero-lws/pull/62/ ↩
https://github.com/Liam-Eagen/BulletproofsPP/ ↩
https://github.com/Rucknium/misc-research/tree/main/Monero-p2pool-Output-Stats/ ↩
https://github.com/monero-project/research-lab/issues/109/ ↩
/rucknium-ospead-ccs-proposal/ ↩
https://monerofund.org/ ↩
/rucknium-publishes-ospead-fully-specified-estimation-plan/ ↩
https://monerofund.org/projects/statistical_attack_reduction/ ↩

Meeting summary: Seraphis Wallet Workgroup, 16 January 2023

Tue, 17 Jan 2023 UTC

This is a comprehensive summary, with added reference links, of the Seraphis Wallet Workgroup meeting¹ from January 16th 2023, 1800 UTC.

Logs

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

230116-seraphis.log (113 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: 10 (one-horse-wagon², ghostway³, rbrunner7⁴, dangerousfreedom⁵, gingeropolous⁶, jberman⁷, ofrnxmr⁸, Rucknium⁹, JoshBabb¹⁰, UkoeHB¹¹)
(1) On Seraphis¹² progress reports:
dangerousfreedom reported that he is still working on the knowledge proofs and expects to present a first complete draft by next week
jberman successfully used UkoeHB’s Seraphis library to scan a legacy testnet chain from scratch and recover a wallet’s balance¹³
(2) On using a formalized formatting system for comments (Doxygen)¹⁴:
ghostway thought that Doxygen with clang format would be okay; dangerousfreedom agreed
rbrunner7 shared an example of what comments in ‘Doxygen style’ look like in the existing Monero codebase¹⁵ and noted that the system is quite big and it looks a bit like overkill; ghostway pointed out that using just a subset is still ok
JoshBabb noted that although doxygen-generated comments aren’t terribly useful, one can appreciate them alongside code styles and linting as a reminder to comment by providing a designated and pre-styled place for them
rbrunner7 acknowledged that the recommendation was to more or less follow koe’s style as visible in the header files of the Seraphis library
(3) On the ambiguity of the term ‘account’ (vs ‘wallet’)¹⁶:
rbrunner7 was wondering if the use of the term ‘account’ as a synonym for ‘wallet’ is widespread and proposed the workgroup finds a way to circumvent the clash of using the term ‘account’ for 2 different things
UkoeHB shared his point of view: a wallet is a stateful thing, while an account is more abstract and noted that calling the base keys your wallet creates ambiguity
rbrunner7 linked to the Moneropedia ‘Account’ entry¹⁷, for reference
one-horse-wagon suggested getting rid of the term account and sticking with wallets, since there is very little difference between the two terms
dangerousfreedom liked the straight hierarchy of wallet->account->addresses
jberman thought that it makes more sense to change the CryptoNote class ‘account’ and keep the term ‘account’ as used to describe the feature to divide wallets by accounts, in an effort to avoid confusing users

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

Feedback, edits always welcome @/about.

-3RA

/seraphis-wallet-workgroup-meeting-16-january-2023/ ↩
(Matrix) @one-horse-wagon:matrix.org ↩
(Matrix) @ghostway:matrix.org ↩
https://github.com/rbrunner7/ ↩
https://github.com/DangerousFreedom1984/ ↩
https://github.com/Gingeropolous/ ↩
https://github.com/j-berman/ ↩
(Matrix) @ofrnxmr:matrix.org ↩
https://github.com/Rucknium/ ↩
(Matrix) @JoshBabb:matrix.org ↩
https://github.com/UkoeHB/ ↩
https://github.com/UkoeHB/Seraphis/ ↩
https://github.com/j-berman/monero-cpp/commit/bb270104b83c4d660cecfe5122fcd0f98a6f01bd ↩
https://github.com/seraphis-migration/wallet3/issues/26 ↩
https://github.com/monero-project/monero/blob/master/src/cryptonote_core/blockchain.h ↩
https://github.com/seraphis-migration/wallet3/issues/44 ↩
https://www.getmonero.org/resources/moneropedia/account.html ↩

Meeting summary: Seraphis Wallet Workgroup, 2 January 2023

Tue, 03 Jan 2023 UTC

This is a comprehensive summary, with added reference links, of the Seraphis Wallet Workgroup meeting¹ from January 2nd 2023, 1800 UTC.

Logs

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

230102-seraphis.log (73 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: 7 (rbrunner7², dangerousfreedom³, woodser⁴, jberman⁵, UkoeHB⁶, Rucknium⁷, plowsof⁸)
(1) On the state of Seraphis⁹ dev work:
UkoeHB confirmed that he is still busy improving the Seraphis library¹⁰ but doesn’t plan any more interface refactoring: I am still chipping away at cleanup and review, making minor adjustments and bug fixes
rbrunner7 noted that jberman has produced code using the library¹¹
jberman explained that he implemented a basic “block scanner” using the Seraphis lib and is planning to use the library to implement a legacy full wallet scanner that makes network requests for chain data to a daemon
jberman acknowledged that UkoeHB’s library is nice to use, usable functions are easy to find, the code is clean and structured well and confirmed that most of his time goes into Seraphis and Jamtis work
dangerousfreedom was not able to attend, but reported just before the meeting that he started implementing the audit proofs and will probably have something to show in the next meeting
rbrunner7 was wondering if dangerousfreedom developed some of the proofs himself; UkoeHB replied that some things require custom proofs, others can reuse existing proof structures and pointed to a relevant discussion¹²
(2) On the Seraphis paper draft¹³:
Rucknium was looking for some feedback on his suggestion¹⁴ to do the Seraphis paper update before asking CypherStack to create a road map; UkoeHB stated that he will continue review until it is done
(3) On Seraphis’s cryptography:
Rucknium was wondering who is going to fix any potential problems with part of Seraphis’s cryptography; rbrunner7 pointed to tevador and kayabanerve as likely candidates; UkoeHB replied that he can probably take care of relatively minor issues and speculated that a major issue could push them to maybe bin the whole thing
(4) On dev recruitment efforts:
rbrunner7 mentioned his getmonero.org dev recruitment article pull request: blog: Developer Opportunities at the Monero Project #2119¹⁵

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

Feedback, edits always welcome @/about.

-3RA

/seraphis-wallet-workgroup-meeting-2-january-2023/ ↩
https://github.com/rbrunner7/ ↩
https://github.com/DangerousFreedom1984/ ↩
https://github.com/woodser/ ↩
https://github.com/j-berman/ ↩
https://github.com/UkoeHB/ ↩
https://github.com/Rucknium/ ↩
https://github.com/plowsof/ ↩
https://github.com/UkoeHB/Seraphis/ ↩
/ukoehb-submits-long-term-seraphis-library-ccs-proposal/ ↩
https://github.com/j-berman/monero-cpp/commit/9f788b40c60d469381d8b9790a0d50aee917f59e ↩
https://github.com/seraphis-migration/wallet3/issues/42 ↩
https://raw.githubusercontent.com/UkoeHB/Seraphis/master/Seraphis-0-0-16.pdf ↩
https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/369#note_20224 ↩
https://github.com/monero-project/monero-site/pull/2119 ↩

Meeting summary: Monero Research Lab, 7 December 2022

Sun, 11 Dec 2022 UTC

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from December 7th 2022, 1700 UTC.

Logs

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

221207-mrl.log (83 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², rbrunner³, Rucknium⁴, plowsof11⁵, ArticMine⁶, ghostway⁷, jberman⁸, sneurlax⁹, blankpage¹⁰, h4sh3d¹¹, hyc¹²)
(1) Updates
- (1.1) on research papers (P2P network anonymity solutions, and Dandelion++¹³):
- Rucknium reported reading Sharma, P. K., Gosain, D., & Diaz, C. 2022. On the anonymity of peer-to-peer network anonymity schemes used by cryptocurrencies.¹⁴ and the original Dandelion++ paper¹⁵
- (1.2) on Monero dev work, Seraphis¹⁶ and JAMTIS¹⁷:
- UkoeHB was working on cleanup/review on his seraphis_lib branch¹⁸, a process that should take 2-4 more weeks; he extended an invitation for PR reviews from that branch to upstream; UkoeHB also updated jamtis address tag hints to use blake2b instead of a layered cipher¹⁹
- UkoeHB explained the difference between address tags and address tag hints to blankpage
- jberman explained to blankpage that RID’s (recipient identifiers) are the proposed shortened version of very long seraphis addresses (they’re an easy-to-read hash of the address)
- jberman finished stress testing the pool and found a bottleneck + identified a couple changes for PR #8076²⁰: reducing trips to the daemon; he is planning to submit two pull requests: one to rbrunner’s branch and another to alleviate the existing bottleneck, before moving over to Seraphis impl work
- (1.3) on Bulletproofs++²¹’²²:
- plowsof11 was wondering how long the community should wait before putting the peer review forward for funding, considering that there was no further contact with the bp++ author since the last email where he said he was working on adding security proofs; plowsof11 noted that he sent the last email on november 30th
- Rucknium suggested that the community might want to get the current paper reviewed if there is no update to it after 3 months
- UkoeHB thought 2 weeks of no contact is a good time frame for a follow-up; jberman agreed
(2) Open discussions
- (2.1) on the research papers mentioned by Rucknium earlier in the meeting¹⁴’¹⁵:
  - Rucknium was not completely convinced that improvements can be made to D++ anonymity with some changes to the parameters, as the Sharma, Gosain, & Diaz paper claims, noting that he does not find their analysis very realistic; Rucknium recommended that no action should be taken at this time and suggested waiting for updates or peer reviews
  - UkoeHB was interested to hear vtnerd’s take on the paper
  - Rucknium hinted at a potential conflict of interest (in suggesting that existing anon network systems do not work well), considering the fact that one of the authors of the Sharma, Gosain, & Diaz (2022) paper is the Chief Scientist for Nym Technologies
  - (2.2) on Farcaster XMR-BTC atomic swaps²³:
  - h4sh3d mentioned that his team is finally reaching the end of last milestone for farcaster and after a final sprint, we can expect a Reddit post at the end of the week and a bit more info next research lab meeting: we’ll be near to release what we consider mainnet ready
  - (2.3) on discussing research papers:
  - blankpage was wondering if the moneroresearch.info annotation feature was being actively used in discussing research papers
  - UkoeHB noted that papers should be discussed here and comments can optionally be back-filled into the site
  - Rucknium acknowledged that the feature is not currently used much, but he hopes that it will be in the future: I will add a link to my comments here to the paper on MoneroResearch.info. We specifically chose the WIKINDX software for its annotation capabilities

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

Feedback, edits always welcome @/about.

-3RA

/monero-research-lab-meeting-7-december-2022/ ↩
https://github.com/UkoeHB/ ↩
https://github.com/rbrunner7/ ↩
https://github.com/Rucknium/ ↩
https://github.com/plowsof/ ↩
https://libredd.it/user/ArticMine/ ↩
@ghostway:matrix.org ↩
https://github.com/j-berman/ ↩
@sneurlax:matrix.org ↩
@blankpage:matrix.org ↩
https://github.com/h4sh3d/ ↩
https://nitter.net/hyc_symas/ ↩
https://www.monerooutreach.org/stories/dandelion.html ↩
https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=130 ↩ ↩²
https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=122 ↩ ↩²
https://github.com/UkoeHB/Seraphis ↩
https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024 ↩
https://github.com/UkoeHB/monero/commits/seraphis_lib ↩
https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024?permalink_comment_id=4392414#gistcomment-4392414 ↩
https://github.com/monero-project/monero/pull/8076 ↩
https://github.com/Liam-Eagen/BulletproofsPP/ ↩
/plowsof-submits-ccs-proposal-bulletproofs++-paper-peer-review/ ↩
https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/168 ↩

Meeting summary: Seraphis Wallet Workgroup, 14 November 2022

Thu, 17 Nov 2022 UTC

This is a comprehensive summary, with added reference links, of the Seraphis Wallet Workgroup meeting¹ from November 14th 2022, 1800 UTC.

Logs

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

221114-seraphis.log (130 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: 10 (rbrunner7², one-horse-wagon³, jberman⁴, JoshBabb⁵, UkoeHB⁶, Rucknium⁷, moneromoooo⁸, interloper⁹, BusyBoredom¹⁰, spacekitty420¹¹)
(1) On the Seraphis HF ETA
rbrunner7 was wondering when the hardfork to Seraphis might take place; one-horse-wagon suggested 3 years if all goes well; UkoeHB and jberman agreed on a more optimistic 2 years estimate
(2) On choosing a project name¹²
rbrunner7 shared some options: Seraphis wallet and wallet3
jberman voted for wallet3, arguing that calling it Seraphis wallet would limit it to Seraphis and could potentially cause confusion if there is some significant upgrade in the future
UkoeHB voted against wallet3, as that would imply another monolith, and suggested xmr wallet suite (wallet_suite) instead
one-horse-wagon suggested The Seraphis Project, as that could help with advertising/funding: we need a name that sells out there; UkoeHB didn’t particularly care about the marketing aesthetic
rbrunner7 voted for Seraphis wallet, discarding wallet3 as non-descript and a bit boring
JoshBabb voted for wallet3, as that is related to wallet2 and to Monero by context: Seraphis doesn’t relate to Monero to me yet; rbrunner7 noted that wallet2 is insider-knowledge
Rucknium suggested the group should also consider threats of users being scammed
rbrunner7 acknowledged the lack of consensus and closed the subject: maybe the people over in #monero-community can duke it out
(3) On nesting Seraphis folders in the Monero core repo¹³
UkoeHB commented that they plan to, later this week, do a commit to reorganize things accordingly
rbrunner7 offered to help set up a repository and guide UkoeHB when he reorganizes his library
rbrunner7 shared the main proposed approaches: 1) Add a number of Seraphis-related “top level” folders, i.e. in /src., and 2) Add something like 2 such top-level folders, and then go one level deeper within those.
UkoeHB thought that it doesn’t make sense to have subfolders: Multisig utilities depend on seraphis crypto and seraphis mulitisig depends on the multisig utilities, and multisig utils are in the main src/
rbrunner7 wondered if anyone would object to adding 10 more folders to the existing 30 folders in /src¹⁴, considering that people attach to such folders and folder names
UkoeHB commented that although rearranging files and folders is a bit tedious, it is not a big deal
jberman didn’t have anything to object, but noted that he would prefer to avoid a ton of new top-level folders
BusyBoredom noted that he would expect to see, from the perspective of a new Monero developer, a wallet/ folder inside src/ with contents broken out further bellow that, as opposed to things relating to wallet internals inside src/
rbrunner7 remarked that it is a bit early to decide something and some experimentation is probably in order before changing topics
(4) Seraphis terminology
- (4.1) on term to use for ‘output’ (enotes)¹⁵:
- rbrunner7 asked if everyone is in agreement to replace the term output with the new enote term coined by UkoeHB
- one-horse-wagon, interloper, rbrunner7, spacekitty420 and jberman agreed
- JoshBabb wondered if the existence of the ‘enotes’ cryptocurrency project¹⁶ and a registered trademark for two different applications could be a deal breaker; rbrunner7 didn’t see any problem with that
- rbrunner7 noted that everyone present is in agreement and unless there are any objections post-meeting, enote will replace output
- (4.2) on naming unique transaction identifiers (transaction id/transaction hash)¹⁷:
- rbrunner7, spacekitty420 and UkoeHB voted for using ‘transaction id’ instead of ‘transaction hash’
- (4.3) on avoiding the term ‘transfer’¹⁸:
- rbrunner7 voted to avoid using the potentially misleading term for the Seraphis wallet, noting that transfer is currently being used in various ways in wallet2, in CLI wallet commands, and RPC server commands
- one-horse-wagon agreed with rbrunner7 and noted that the term is a catchall for everything and it can be easily misunderstood
- UkoeHB didn’t think that it makes sense to fully ban the term: in our world a transaction is a thing and transfer funds is what it does

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

Feedback, edits always welcome @/about.

-3RA

/seraphis-wallet-workgroup-meeting-14-november-2022/ ↩
https://github.com/rbrunner7/ ↩
(Matrix) @one-horse-wagon:matrix.org ↩
https://github.com/j-berman/ ↩
(Matrix) @JoshBabb:matrix.org ↩
https://github.com/UkoeHB/ ↩
https://github.com/Rucknium/ ↩
https://github.com/moneromooo-monero/ ↩
(IRC/Libera) interloper ↩
https://github.com/busyboredom/ ↩
(Matrix) @spacekitty420:matrix.org ↩
https://github.com/seraphis-migration/wallet3/issues/15/ ↩
https://github.com/seraphis-migration/wallet3/issues/29/ ↩
https://github.com/monero-project/monero/tree/master/src/ ↩
https://github.com/seraphis-migration/wallet3/issues/1/ ↩
https://www.enotes.online/ ↩
https://github.com/seraphis-migration/wallet3/issues/14/ ↩
https://github.com/seraphis-migration/wallet3/issues/18/ ↩

Meeting summary: Monero Research Lab, 5 October 2022

Tue, 11 Oct 2022 UTC

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from October 5th 2022, 1700 UTC.

Logs

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

221005-mrl.log (57 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: 9 (UkoeHB², rbrunner³, dangerousfreedom⁴, vtnerd⁵, ArticMine⁶, Rucknium⁷, jberman⁸, premined_POS⁹, isthmus¹⁰)
(1) Updates
- (1.1) on outreach initiatives / MRL recruitment efforts¹¹:
- Rucknium noted that the MAGIC Monero Fund¹² will soon submit its grant application to some research grant databases in hopes of attracting more researchers
- (1.2) on Seraphis¹³ (library, bug fixes, wallet, audit framework¹⁴):
- dangerousfreedom has been investigating the grootle proofs in seraphis and trying to make a parallel implementation of it in an attempt to correct any potential flaws
- UkoeHB was planning to focus on the remaining seraphis library updates: finish unit testing legacy balance recovery for the legacy-seraphis transition, add legacy inputs to multisig, add coinbase tx type
- jberman finished work on PR #8566¹⁵ (wallet2: fix rescanning tx via scan_tx) and was getting ready to finish background sync mode, before moving on to Seraphis wallet work
- rbrunner found the Seraphis library interesting after taking a closer look at the code
- (1.3) on P2P E2E encryption¹⁶ and the Noise Protocol¹⁷:
- vtnerd was considering dropping the planned noise method due to fingerprinting
- (1.4) on multisig security proofs:
- jberman reported that no answer was received from veorq one week after contact and he was still waiting on a response from the Inference¹⁸ security team
(2) Open discussions
- (2.1) on the need for a Seraphis formal peer review:
  - dangerousfreedom was wondering about the legal implications of formality and if there is a real need for a ‘paper’ of Seraphis to be peer-reviewed
  - UkoeHB noted that the seraphis composition proof is a novel scheme and it is standard practice to at least have security proofs for signature schemes
  - premined_POS pointed out that precautions, redundancy and tests are good even in trivial scenarios
  - Rucknium thought that a formal peer review is important and a paper is the best way to have a review of the math, noting that in case of a critical error, the Monero network would probably be destroyed
  - UkoeHB answered rbrunner’s question about the current state of security proofs for Seraphis: it’s in limbo until I get a chance to properly refresh the paper; after that we need to find someone to help us

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

Feedback, edits always welcome @/about.

-3RA

/monero-research-lab-meeting-5-october-2022/ ↩
https://github.com/UkoeHB/ ↩
https://github.com/rbrunner7/ ↩
https://github.com/DangerousFreedom1984/ ↩
https://github.com/vtnerd/ ↩
https://libredd.it/user/ArticMine ↩
https://github.com/Rucknium/ ↩
https://github.com/j-berman/ ↩
@premined_POS:matrix.org ↩
https://github.com/mitchellpkt ↩
https://libredd.it/pkg3d6/ ↩
https://magicgrants.org/funds/monero/ ↩
https://github.com/UkoeHB/Seraphis ↩
/dangerousfreedom1984-ccs-proposal-seraphis-cli-wallet-audit-framework/ ↩
https://github.com/monero-project/monero/pull/8566 ↩
https://github.com/monero-project/monero/pull/8028 ↩
https://noiseprotocol.org/ ↩
https://inference.ag/ ↩

Meeting summary: Monero Research Lab, 14 September 2022

Fri, 16 Sep 2022 UTC

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from September 14th 2022, 1700 UTC.

Logs

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

220914-mrl.log (54 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: 9 (dangerousfreedom², one-horse-wagon³, jberman⁴, rbrunner⁵, Rucknium⁶, ajs_⁷, UkoeHB⁸, xmrack⁹, chch3003¹⁰)
(1) Updates
- (1.1) on Monero inflation tools¹¹ and Seraphis¹²:
- dangerousfreedom finished scanning the blockchain: bp and clsag era, using his own Rust tools, and is planning to create auditability proofs to seraphis and help develop a minimum useful seraphis wallet¹³
- dangerousfreedom confirmed that no new anomalies turned up while scanning, thanks to Bulletproofs
- (1.2) on statistical analysis / OSPEAD¹⁴:
- Rucknium included the statement: “I consider exploration of ring classification to be out of scope of this OSPEAD CSS.” into a newly added section on classification of rings by Decoy Selection Algorithm.
- Rucknium announced that the disclosable part of OSPEAD fully specified plan will be released as soon as the MAGIC Monero Fund campaign¹⁵ to raise funds for mj-xmr’s C++ work for OSPEAD begins, probably next week
- (1.3) on Monero dev work, Seraphis and Jamtis:
- jberman was mostly doing dev work for the past week, fixing various bugs¹⁶, and is planning to complete background sync mode next and then prepare to dive into Seraphis/Jamtis¹⁷ along with rbrunner and dangerousfreedom
- rbrunner invited contributors to join the #no-wallet-left-behind:haveno.network¹⁸ Seraphis/Jamtis project¹⁹ Matrix room
- UkoeHB continued their work on the Seraphis library²⁰ legacy integration and a non-multisig working demo could be ready by next week
- (1.4) on Monero’s deterministic build process²¹:
- one-horse-wagon was intently looking for ways to increase the number of deterministic builders before a code version is released, but concluded that the process cannot be made any more easier
- (1.5) on Monero Konferenco 2023²² and MRL recruitment:
- ajs_ and a few others started making plans for MoneroKon 2023 and would like to seek technical co-sponsorship with IEEE Computer Society²³ in an effort to attract more researchers to the conference and help with MRL recruitment efforts²⁴
- (1.6) on Monero research papers:
- Rucknium mentioned that xmrack’s Lord of the Rings: An Empirical Analysis of Monero’s Ring Signature Resilience to Artifically Intelligent Attacks (PDF²⁵, report²⁶) MAGIC-funded research paper is making the rounds.
(2) Open discussions
- (2.1) on Monero funding systems:
- Rucknium explained the need for both the CCS²⁷ and MAGIC Grant’s Monero Fund²⁸ to chch3003
- (2.2) on quantum resistance:
- one-horse-wagon expressed concerns about the coming era of quantum computers: Big corporations and governments will have them. The MRL will not at least initally.
- dangerousfreedom thought that quantum computers are so far from being a threat and proposed exploring the algorithms that are in the final phase of NIST; tevador linked to their Zero-cost post-quantum mitigations for Seraphis²⁹ draft

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

Feedback, edits always welcome @/about.

-3RA

/monero-research-lab-meeting-14-september-2022/ ↩
https://github.com/DangerousFreedom1984/ ↩
@one-horse-wagon:matrix.org ↩
https://github.com/j-berman/ ↩
https://github.com/rbrunner7/ ↩
https://github.com/Rucknium/ ↩
https://repo.getmonero.org/ajs ↩
https://github.com/UkoeHB/ ↩
https://github.com/ACK-J/ ↩
@chch3003:matrix.org ↩
https://github.com/DangerousFreedom1984/monero_inflation_checker ↩
https://github.com/UkoeHB/Seraphis ↩
/dangerousfreedom1984-ccs-proposal-moneroinflation-seraphis-jamtis/ ↩
/rucknium-ospead-ccs-proposal/ ↩
https://github.com/MAGICGrants/Monero-Fund/issues/21 ↩
https://github.com/monero-project/monero/commits?author=j-berman&since=2022-09-01&until=2022-09-14 ↩
https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024 ↩
https://matrix.to/#/#no-wallet-left-behind:haveno.network ↩
/rbrunner7-calls-dedicated-effort-establish-migration-path-monero-seraphis-jamtis-hf/ ↩
https://github.com/seraphis-migration/wallet3/issues/8 ↩
https://github.com/monero-project/monero/blob/master/contrib/gitian/README.md ↩
https://monerokon.com/ ↩
https://www.computer.org/ ↩
https://leddit.xyz/pkg3d6/ ↩
https://github.com/ACK-J/Monero-Dataset-Pipeline/blob/main/Lord_of_the_Rings__An_Empirical_Analysis_of_Monero_s_Ring_Signature_Resilience_to_Artificially_Intelligent_Attacks.pdf ↩
/ack-j-completes-magic-funded-research-proposal/ ↩
https://ccs.getmonero.org/ ↩
https://magicgrants.org/funds/monero ↩
https://gist.github.com/tevador/23a84444df2419dd658cba804bf57f1a ↩

Meeting summary: Monero Research Lab, 10 August 2022

Tue, 23 Aug 2022 UTC

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from August 10th 2022, 1700 UTC.

Logs

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

220810-mrl.log (62 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: 6 (UkoeHB², dangerousfreedom³, rbrunner⁴, tevador⁵, Rucknium⁶, jberman⁷)
(1) Updates
- (1.1) on cryptography libraries and Monero addressing schemes:
- tevador published their X25519⁸ code and was planning to update the JAMTIS⁹ specs
- (1.2) on Seraphis¹⁰:
- UkoeHB reported finishing the legacy balance recovery for their Seraphis library and started unit testing it
- (1.3) on statistical analysis / OSPEAD¹¹:
- Rucknium published an analysis of the evolution of the distribution of spent output age on BTC, BCH, LTC, and DOGE¹²’¹³
- (1.4) on zero knowledge schemes:
- dangerousfreedom reported reading about different zero knowledge schemes and started scanning the blockchain (BP and so forth) in Rust
- (1.5) on the HF¹⁴:
- jberman was monitoring PR reviews, pool updates and other related things, to make sure the hard fork goes smooth
(2) Open discussions
- (2.1) on Rucknium’s research post¹²:
- rbrunner and tevador appreciated Rucknium’s article as interesting and an excellent write-up
- Rucknium was getting ready to finish the documentation for the chart and concluded that the “dynamic risk” for a static Monero decoy selection algorithm would be higher if Monero’s distribution is similarly unstable
- (2.1) on mining pool centralization issues and MineXMR closure¹⁵:
- Rucknium was keen on eventually resuming research efforts to estimate the effect of minexmr’s increased pool fee on their share of hashpower, although preliminary results suggested very little effect, if any
- Rucknium also suggested that the Monero community should put in more effort into trying to resolve the challenges of tevador’s anti-pool [Pro-p2pool] proposal¹⁶
- (2.2) on Seraphis¹⁰
- dangerousfreedom offered to help UkoeHB develop the wallet so we could have a working full prototype asap; UkoeHB suggested dangerousfreedom could start by looking at unit tests and get an understanding how the library is put together
- (2.3) on JAMTIS⁹
- tevador was looking to remove “certified addresses” from the main specs and shared some proposed changes to the Jamtis key hierarchy¹⁷

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

Feedback, edits always welcome @/about.

-3RA

/monero-research-lab-meeting-10-august-2022/ ↩
https://github.com/UkoeHB/ ↩
https://github.com/DangerousFreedom1984/ ↩
https://github.com/rbrunner7/ ↩
https://github.com/tevador/ ↩
https://github.com/Rucknium/ ↩
https://github.com/j-berman/ ↩
https://github.com/tevador/mx25519 ↩
https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024 ↩ ↩²
https://github.com/UkoeHB/Seraphis ↩ ↩²
/rucknium-ospead-ccs-proposal/ ↩
https://rucknium.me/html/spent-output-age-btc-bch-ltc-doge.html ↩ ↩²
https://github.com/Rucknium/OSPEAD/tree/main/General-Blockchain-Age-of-Spent-Outputs ↩
/monero-hard-fork-rescheduled-13-august-2022/ ↩
/minexmr-delays-closure-august-19-2022/ ↩
https://github.com/monero-project/research-lab/issues/98 ↩
https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024#gistcomment-4259423 ↩

Meeting summary: Monero Research Lab, 13 July 2022

Sun, 17 Jul 2022 UTC

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from July 13th 2022, 1700 UTC.

Logs

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

220713-mrl.log (80 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: 10 (UkoeHB², rbrunner³, jberman⁴, Rucknium⁵, ArticMine⁶, dangerousfreedom⁷, kayabanerve⁸, hyc⁹, wernervasquez¹⁰, r4v3r23¹¹)
(1) Updates
- (1.1) on Monero fixes and the upcoming network upgrade¹²:
- jberman submitted perfect-daemon’s PR 7760 socket connection fixes with merge conflicts resolved (#8426¹³), submitted a patch for zmq to publish txs submitted to the daemon (#8427¹⁴) and updated openmonero¹⁵ for the v15 hard fork
- (1.2) on Monero address specs:
- kayabanerve published a new address specification (Featured Addresses¹⁶); one variant (the Guaranteed¹⁷ feature) removes the potential for the burning bug¹⁸
- (1.3) on Bulletproofs¹⁹:
- dangerousfreedom announced plans to implement BP in Rust by the end of this month or next one
- (1.4) on Seraphis²⁰:
- UkoeHB reported starting work on integrating legacy cryptonote outputs into the main transaction type so they can be spent alongside normal seraphis enotes
- (1.5) on outreach initiatives:
- Rucknium announced that MAGIC Monero Fund²¹ was considering targeted outreach to external researchers to apply for research grants
(2) Open discussions
- (2.1) on Bulletproofs++²²:
- rbrunner was wondering if BP++ was peer reviewed; Rucknium clarified that it was not (yet)
- (2.1) on Seraphis and Jamtis²³ next steps:
- UkoeHB shared plans to integrate cryptonote inputs and add coinbase tx type and was looking for anyone else interested in looking at the code and perhaps investigate/implement the wallet-side features of Jamtis, build wallets that use the seraphis library interface for building/handling txs and enotes and integrate Seraphis into the daemon/ledger
- rbrunner was interested to contribute, but unsure when, how and how much they could get involved; dangerousfreedom was also keen to contribute, probably in two months after building skills and understanding
- Rucknium was interested in ways to get the cryptography in Seraphis to be peer-reviewed
- UkoeHB posted a PSA related to their CCS proposal²⁴ after underestimating how much work was necessary to reach the point of ‘write a wallet’: I won’t actually make a wallet proof-of-concept, since designing the API and internal caches isn’t really my domain. The remaining time of my CCS will be spent finishing the core library
- (2.2) on future research plans:
- Rucknium was thinking about researching churning²⁵ best practices, after OSPEAD²⁶
- UkoeHB thought that jberman’s suggestion to get the poc audited and paper reviewed was a good idea

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

Feedback, edits always welcome @/about.

-3RA

/monero-research-lab-meeting-13-july-2022/ ↩
https://github.com/UkoeHB ↩
https://github.com/rbrunner7/ ↩
https://github.com/j-berman ↩
https://github.com/Rucknium ↩
https://libredd.it/user/ArticMine ↩
https://github.com/DangerousFreedom1984 ↩
https://github.com/kayabaNerve ↩
https://github.com/hyc ↩
@wernervasquez:matrix.org ↩
https://github.com/r4v3r23 ↩
/monero-hard-fork-rescheduled-13-august-2022/ ↩
https://github.com/monero-project/monero/pull/8426 ↩
https://github.com/monero-project/monero/pull/8427 ↩
https://github.com/moneroexamples/openmonero/pull/181 ↩
https://gist.github.com/kayabaNerve/01c50bbc35441e0bbdcee63a9d823789 ↩
https://gist.github.com/kayabaNerve/8066c13f1fe1573286ba7a2fd79f6100 ↩
https://www.getmonero.org/pl/2018/09/25/a-post-mortum-of-the-burning-bug.html ↩
https://www.getmonero.org/resources/moneropedia/bulletproofs.html ↩
https://github.com/UkoeHB/Seraphis ↩
https://magicgrants.org/funds/monero/ ↩
https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=83 ↩
https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024 ↩
/ukoehb-submits-second-seraphis-wallet-poc-ccs-proposal/ ↩
https://monero.stackexchange.com/a/4568 ↩
/rucknium-ospead-ccs-proposal/ ↩

Meeting summary: Monero Research Lab, 22 June 2022

Sat, 25 Jun 2022 UTC

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from June 22nd 2022, 1700 UTC.

Logs

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

220622-mrl.log (71 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², rbrunner³, jberman⁴, Rucknium⁵, tobtoht⁶, ooo123ooo1234567⁷, ArticMine⁸, SerHack⁹, selsta¹⁰, ofrnxmr¹¹, sech1¹²)
(1) Updates
- (1.1) on statistical analysis and the decoy selection algorithm:
- Rucknium reported writing an R implementation based on mj-xmr’s Python implementation of the wallet2 decoy selection algorithm¹³
- (1.2) on Monero fixes and the upcoming network upgrade:
- jberman finished the Ledger integration and was almost done reviewing 8076¹⁴; he also announced plans to submit a new CCS soon
- (1.3) on Seraphis¹⁵, Jamtis¹⁶ and MoneroKon22 presentations:
- UkoeHB reported running some basic unit tests of enote scanning and noted that although there are various todos to address, currently there is enough code in his Seraphis library to begin writing a wallet
- jberman was happy with how the recent MoneroKon22 presentation on Seraphis/Jamtis features¹⁷ went
- UkoeHB was hopeful that a video of his MoneroKon22 presentation about Seraphis balance recovery¹⁸ would become available at some point
- ArticMine mentioned his own Monerokon22 presentation (On The Security and Ecological Sustainability of Monero¹⁹), before announcing his plans to start working on a comprehensive overview of the whole fee, scaling, and related security and spam issues
- Rucknium suggested ArticMine should reach out to endor00, as they are currently working on an analysis of the Monero “security budget”
(2) Open discussions
- (2.1) on the persistent many-input transactions observed since last fall:
- Rucknium mentioned the ring caching possibility, that was previously suggested by jberman
- ooo123ooo1234567 didn’t think the issue of broken tx relay and harmful edge case for ring signature cache was particularly interesting to discuss from a research point of view
- (2.2) on reasons behind the HF²⁰ delay:
- selsta proposed a 2-week HF delay that would move the fork height from 2668888 to 2678888, after mentioning that the auditors were planning to send a draft last Friday, but he wasn’t aware of any updates
- UkoeHB and jberman had no objections, but jberman suggested postponing the delay until there was better clarity regarding multisig, which was tied up by a 3rd party
- ArticMine questioned the proposed length of the delay
- selsta suggested that a final decision should be taken during the next dev meeting (date TBD); ArticMine agreed;
- Rucknium proposed keeping the current date and delaying the multisig fix to a post-HF release; ofrnxmr agreed; selsta stressed the importance of giving everyone enough time to update
- jberman agreed with ooo123ooo1234567: HF date should be set after code is ready, not before
- selsta confirmed that the code is almost ready, specified that the remaining tasks were 1) trezor firmware update date and 2) ledger finishing integration and stated that the HF is not months away
- selsta pointed out that since luigi was also unavailable for a bit, the 2 weeks delay is the only viable option

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

Feedback, edits always welcome @/about.

-3RA

/monero-research-lab-meeting-22-june-2022/ ↩
https://github.com/UkoeHB ↩
https://github.com/rbrunner7/ ↩
https://github.com/j-berman ↩
https://github.com/Rucknium ↩
https://git.featherwallet.org/tobtoht ↩
https://matrix.to/#/@ooo123ooo1234567:matrix.org ↩
https://libredd.it/user/ArticMine ↩
https://github.com/serhack ↩
https://github.com/selsta ↩
https://matrix.to/#/@ofrnxmr:matrix.org ↩
https://github.com/SChernykh ↩
https://github.com/mj-xmr/monero-mrl-mj/pull/3 ↩
https://github.com/monero-project/monero/pull/8076 ↩
https://github.com/UkoeHB/Seraphis ↩
https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024 ↩
https://github.com/MoneroKon/meta/raw/main/slides/2022/j-berman.pdf ↩
https://github.com/MoneroKon/meta/raw/main/slides/2022/Seraphis%20Balance%20Recovery.pdf ↩
https://github.com/MoneroKon/meta/raw/main/slides/2022/articmine.pdf ↩
/monero-consensus-hard-fork-16-july-2022/ ↩

Meeting summary: Monero Research Lab, 8 June 2022

Fri, 10 Jun 2022 UTC

This is a comprehensive summary, with added reference links, of the MRL meeting¹ from June 8th 2022, 1700 UTC.

Logs

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

220608-mrl.log (65 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: 8 (UkoeHB², rbrunner³, jberman⁴, Rucknium⁵, xmr-ack⁶, ooo123ooo1234567⁷, ArticMine⁸, cryptogrampy⁹)
(1) Updates
- (1.1) on Monero fixes:
- jberman has been working on PR 7760¹⁰ exclusively (WIP branch¹¹)
- (1.2) on statistical analysis and the decoy selection algorithm:
- Rucknium did some BCH-related work which can be re-purposed to improve https://monero.com/charts/shielded, was working alongside mj to re-implement the C++ decoy selection algorithm in Python¹² and expects to have a formal specification for the DSA soon
- (1.3) on Seraphis¹³:
- UkoeHB was working on the enote scanning workflow for seraphis
(2) Open discussions
- (2.1) on producing deanonymized dataset of stagenet Monero transactions¹⁴:
- xmr-ack reported fixing a memory leak in their script which processes the collected dataset, added some multiprocessing in places to speed up the undersampling process and expects to have the new version of the preliminary dataset soon, on which to start retraining models on
- (2.2) on decoy selection improvements:
- Rucknium noted that Monero’s weighting of the decoy selection by number of txs in each block would in fact not mitigate the issue with a spike in speculative activity shifting the real spend distribution, contrary to what he previously thought; UkoeHB agreed
- (2.3) on the MRL meeting agenda:
- UkoeHB proposed removing agenda items 6 (Examine sample size and random seed matters in Monero’s unit tests¹⁵’¹⁶) and 7 (Multisig Drijvers attack mitigation¹⁷’¹⁸); Rucknium agreed
- (2.4) on Seraphis concerns:
- Rucknium mentioned Monero community vaguely defined concerns¹⁹ about additional view key options with Seraphis; UkoeHB agreed that there is no ideal solution and that it is important to discuss the pros and cons that go into design decisions, hoping that his recent comment²⁰ helped clear up any confusion
- rbrunner and Rucknium agreed that the topic itself is controversial and tricky
- ArticMine chimed in to state that he prefers the Jamtis²¹ approach than relying on heuristics, as the heuristics approach would favor blockchain surveillance companies
- cryptogrampy proposed discussing the concept of subscription services / user accounts, but wasn’t yet ready to explain to UkoeHB specifically how such a workflow would look like
- Rucknium provided some examples²²’²³’²⁴’²⁵ to cryptogrampy, for inspiration
- (2.5) on MRL visibility and the MAGIC Monero Fund:
- Rucknium suggested that it would be nice to somehow get more visibility for MRL on the IACR jobs board²⁶; UkoeHB suggested setting a large bounty for it
- Rucknium didn’t feel like the MAGIC Monero Fund²⁷ had enough funds to be looking for lots of grant applications
- xmr-ack proposed funding a prize for a Kaggle competition which would attract high quality datascience talent from all over to look into Monero, once their current MAGIC grant²⁸ is finished; Rucknium agreed that Kaggle is a good idea

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

Feedback, edits always welcome @/about.

-3RA

https://github.com/monero-project/meta/issues/712 ↩
https://github.com/UkoeHB ↩
https://github.com/rbrunner7/ ↩
https://github.com/j-berman ↩
https://github.com/Rucknium ↩
https://github.com/ACK-J/ ↩
@ooo123ooo1234567:matrix.org ↩
https://libredd.it/user/ArticMine ↩
https://github.com/CryptoGrampy ↩
https://github.com/monero-project/monero/pull/7760 ↩
https://github.com/j-berman/monero/commits/7760-streamlined-logic ↩
https://github.com/Rucknium/monero-mrl-mj/tree/master/decoy ↩
https://github.com/UkoeHB/Seraphis ↩
/ack-j-may-2022-magic-grants-research-report/ ↩
https://libera.monerologs.net/monero-dev/20211018#c39593 ↩
https://libera.monerologs.net/monero-research-lab/20211018 ↩
https://github.com/UkoeHB/drijvers-multisig-tech-note ↩
https://github.com/haveno-dex/haveno/issues/103 ↩
https://libredd.it/v4wq1g/ ↩
https://github.com/monero-project/research-lab/issues/92#issuecomment-1146810255 ↩
https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024 ↩
https://read.cash ↩
https://noise.cash ↩
https://memo.cash ↩
https://member.cash ↩
https://www.iacr.org/jobs/ ↩
https://magicgrants.org/Monero-Fund/ ↩
/magic-monero-fund-committee-funds-first-research-proposal/ ↩

Meeting summary: Monero Community Workgroup, 29 May 2022

Sun, 05 Jun 2022 UTC

This is a comprehensive summary, with added reference links, of the Monero Community Workgroup meeting from May 29th 2022, 1700 UTC.

Logs

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

220529-community.log (201 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: 14 (plowsof¹, msvb-web², binarybaron³, spackle_xmr⁴, monerobull⁵, Morpheus⁶, selsta⁷, Rucknium⁸, ofrnxmr⁹, sethforprivacy¹⁰, mj-xmr¹¹, ajs_¹², ooo123ooo1234567¹³, cryptogrampy¹⁴)
(1) Community highlights
- (1.1) on the upcoming v15 network update¹⁵:
- plowsof thanked Sethforprivacy for helping with the HF (testnet monerod nodes¹⁶) and for writing a BTCPay Server guide¹⁷
- (1.2) on general updates:
- plowsof mentioned Ditatompel’s new remote node list¹⁸ fee estimate feature, Monero.fail’s new Web compatible¹⁹ filter, that P2Pool has been growing²⁰, that noot has made progress with her XMR-ETH atomic swaps project²¹ and that RINO was willing to partly fund an audit for multisig fix (#8149²²)
- monerobull was skeptical about MajesticBank’s move to give away 40 free tickets to MoneroKon 2022 event²³ and again called for the closure of spirobel’s Afghanistan expansion strategy ccs²⁴
- plowsof reminded everyone that spirobel was currently reinventing that proposal and a new one should be submitted soon
(2) CCS updates
- (2.1) on Morpheus’s ‘Moneroj.net’ proposal²⁵:
- plowsof underlined the fact that Morpheus created 10 new charts and also split it in half as a sign of good faith (2 CCS proposals, as initially suggested by plowsof)
- Morpheus assured monerobull that website speed would improve to less than a second to load when everything is done and was open to Rucknium’s suggestion to add a hidden service
- plowsof clarified selsta’s funding question: 35 XMR for the first proposal and there will be a second proposal for the same amount
- Rucknium voiced a slight concern over the website’s content being quite focused on Monero as a speculative investment
- ofrnxmr thought the funding requested was still a lot and wondered whether the project would require constant funding and voted against the proposal as rates are higher than researcher rates
- selsta was worried about the usage of darknet related statistics and everyone pretty much agreed that the core team has to decide if they are ok with funding something like that on the CCS; Morpheus agreed to not build darknet markets charts
- selsta requested a more clearly written hourly rate and hours planned to work per month and Morpheus obliged²⁶
- plowsof concluded that the proposal needs more discussion and input from core
- (2.2) on binarybaron’s ‘XMR BTC Atomic Swaps Desktop GUI - Continued development’ proposal²⁷:
- plowsof suggested the current atomic swaps process is not noob friendly at all and that part of this proposal was to tackle this issue
- ofrnxmr compared the total funding requested to Haveno’s UI CCS proposal: 150xmr for an interface
- plowsof was concerned about funding a gui for an abandoned project instead of potentially funding a gui for ‘farcaster’²⁸, but wasn’t doubtful of the popularity of the proposal and was sure that people would donate to the project
- plowsof echoed binarybaron’s assurance that the atomic swaps are functional and will continue to be after the hard fork
- selsta wondered how dependent would the gui be on swap-cli from comit and suggested the proposal should state the hourly rate and approx worked hours per week
- (2.3) on jeffro256’s ‘part-time dev work 2022 Q3’ proposal²⁹:
- selsta voted for: support from my side, with focus on gui, rpc, protocol spec
- (3) Open Ideas
- ooo123ooo1234567 started criticizing mj’s SolOptXMR project³⁰
- plowsof mentioned cryptogrampy’s HotShop project³¹
- msvb-web made himself available to questions about implementing NFC interactions in hardware
- cryptogrampy was ready to collect his M2 payout
/end

Let me know if you found this report helpful.

Feedback, suggestions and edits always welcome @/about/.

-3RA

https://github.com/plowsof ↩
msvbweb (irc) ↩
https://github.com/binarybaron ↩
https://matrix.to/#/@spackle_xmr:matrix.org ↩
https://libredd.it/user/monerobull ↩
https://nitter.net/CryptoMorpheus_ ↩
https://github.com/selsta ↩
https://github.com/Rucknium ↩
https://matrix.to/#/@ofrnxmr:matrix.org ↩
https://matrix.to/#/@sethforprivacy:matrix.optoutpod.com ↩
https://github.com/mj-xmr ↩
https://repo.getmonero.org/ajs ↩
https://matrix.to/#/@ooo123ooo1234567:matrix.org ↩
https://github.com/CryptoGrampy ↩
/monero-consensus-hard-fork-16-july-2022/ ↩
https://libredd.it/r/utzyyz/ ↩
/sethforprivacy-shares-monero-btcpayserver-guide ↩
https://www.ditatompel.com/monero/remote-node ↩
https://monero.fail/?web_compatible=true ↩
/p2pool-mini-reaches-1000-active-miners ↩
/noot-completes-milestone-5-xmr-eth-atomic-swaps-project ↩
https://github.com/monero-project/monero/pull/8149 ↩
/majesticbank-to-give-away-40-monerokon-2022-tickets ↩
/spirobel-wants-write-monero-afghanistan-expansion-strategy-paper ↩
/cryptomorpheus_-submits-moneroj-ccs-proposal/ ↩
https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/318#note_16622 ↩
/binarybaron-second-btc-xmr-atomic-swap-desktop-gui-css-proposal/ ↩
https://github.com/farcaster-project/ ↩
/jeffro256-part-time-monero-dev-ccs-proposal-q3-2022/ ↩
/mjxmr-submits-ccs-proposal-soloptxmr/ ↩
/cryptogrampy-submits-ccs-proposal-hotshop-monero-pos/ ↩

Meeting summary: Monero Research Lab, 18 May 2022

Fri, 20 May 2022 UTC

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

Logs

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

220518-mrl.log (121 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: 10 (UkoeHB², jberman³, mj-xmr⁴, Rucknium⁵, kayabaNerve⁶, merope⁷, hyc⁸, dangerousfreedom⁹, moneromooo¹⁰, jeffro256¹¹)
(1) Updates
- (1.1) on the decoy algorithm:
- mj-xmr has delivered the first working Python implementation of the Gamma Picker algo¹² and plans on forwarding the finalized work to Rucknium by Sunday
- (1.2) on Seraphis and Jamtis:
- UkoeHB has implemented a robust input selection solver for Seraphis, pushed multisig PRs forward a bit, updated Jamtis to support self-spends better (e.g. churn) and plans to finally implement the full enote scanning workflow
- (1.3) on statistical analysis (re: Minexmr fee increase¹³):
- Rucknium decided to go with Vector Autoregression, essentially treating the fee increase as an exogenous shock and fiat/XMR exchange rate and hashing difficulty as endogenous
- (1.4) on ring signatures:
- dangerousfreedom has been learning about and implemented (in Python) Bulletproofs and CLSAG as it is in the C++ code; they are also continuing to scan the blockchain with the LibSodium library
- (1.5) on optimizations and fixes:
- jberman has finished up patching relatively trivial tor/i2p daemon connectivity bugs, reviewed/provided guide to rbrunner on completing 8076¹⁴, and is moving back over to reviewing 7760¹⁵
- rbrunner announced that they will start to work on 8076 shortly
(2) Reducing the 10 block lock discussion¹⁶
- UkoeHB and moneromooo agreed that it will be difficult to evaluate whether changing the block limit is a good idea
- Rucknium mentioned the active attacker scenario in UkoeHB’s MRL issue #95, triggering a discussion about different potential attack vectors
- moneromooo mentioned Townforge¹⁷ and how players can freely move money between output based and balance based and there is no lock period for balance based transactions
- no clear consensus was reached regarding this proposal, due to complexity of the issue and the timing of such a change in the context of the current pool situation

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

Feedback, edits always welcome @/about.

-3RA

https://github.com/monero-project/meta/issues/706 ↩
https://github.com/UkoeHB ↩
https://github.com/j-berman ↩
https://github.com/mj-xmr ↩
https://github.com/Rucknium ↩
https://github.com/kayabaNerve ↩
@merope:matrix.org ↩
https://github.com/hyc ↩
https://github.com/DangerousFreedom1984 ↩
https://github.com/moneromooo-monero ↩
https://github.com/jeffro256 ↩
https://github.com/mj-xmr/monero-mrl-mj/blob/decoy/decoy/README.md#results ↩
/minexmr-top-monero-pool-hashrate-drops-from-50-to-38-percent/ ↩
https://github.com/monero-project/monero/pull/8076 ↩
https://github.com/monero-project/monero/pull/7760 ↩
https://github.com/monero-project/research-lab/issues/95 ↩
https://www.townforge.net/ ↩

Meeting summary: Monero Development Workgroup, 7 May 2022

Tue, 10 May 2022 UTC

This is a comprehensive summary, with added reference links, of the Monero Development Workgroup meeting from May 7th 2022, 1700 UTC.

Logs

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

220507-dev.log (92 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: 8 (UkoeHB¹, selsta², jberman³, ErCiccione⁴, rbrunner⁵, sech1⁶, hyc⁷, garth⁸)
(1) Network update: situation
- ErCiccione mentioned UkoeHB’s Multisig: signature fixes #8149 PR⁹
- UkoeHB suggested vtnerd could potentially review #8149 before merging it
- UkoeHB mentioned that multisig: add post-kex verification round #8220 PR¹⁰ is in the merge queue
- hyc stated that the gitian arm macosx should be ready to merge before then
- ErCiccione reminded everyone that everything should be ready by May 16th, as previously established¹¹
- rbrunner and jberman have almost finished reviewing #8076¹²
- jberman thinks #7760¹³ could also be included, if he can review it in time
- selsta reminded everyone that this “feature complete” date was never really strict and PRs can still be merged after May 16th
- UkoeHB answered garth’s question after clarifying that the multisig fixes are not consensus-breaking changes
- garth thought that non-consensus breaking upgrades should not be listed in the already pretty long network upgrade history
(2) Decide stagenet fork date/height
- selsta suggested that the stagenet fork is usually 1 week before mainnet (July 9th)
- jberman volunteered to handle the pull request and set the block height for the testnet fork (1982800 and 1983520)
- ErCiccione summed up the definitive plan:
  - Branch/feature complete: May 16th, 2022 Release date: June 16th, 2022 Testnet hard-fork: May 16th, 2022, block 1982800 and 1983520 Stagenet hard-fork: July 9th Mainnet hard-fork: July 16th, 2022, block 2668888

Let me know if you find this kind of report helpful. If not, I will redirect time spent on this to other tasks.

Feedback, edits always welcome @/about.

-3RA

https://github.com/UkoeHB ↩
https://github.com/selsta ↩
https://github.com/j-berman ↩
https://github.com/erciccione ↩
https://github.com/rbrunner7/ ↩
https://github.com/SChernykh ↩
https://github.com/hyc ↩
https://github.com/garth-xmr ↩
https://github.com/monero-project/monero/pull/8149 ↩
https://github.com/monero-project/monero/pull/8220 ↩
https://github.com/monero-project/meta/issues/630 ↩
https://github.com/monero-project/monero/pull/8076 ↩
https://github.com/monero-project/monero/pull/7760 ↩

Meeting summary: Monero Research Lab, 27 April 2022

Fri, 06 May 2022 UTC

This is a comprehensive summary, with added reference links, of the Monero Research Lab meeting from April 27th 2022, 1700 UTC.

Logs

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

220427-mrl.log (108 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: 10 (UkoeHB¹, selsta², jberman³, xmr-ack⁴, mj-xmr⁵, Rucknium⁶, cryptogrampy⁷, kayabaNerve⁸, merope⁹, gingeropolous¹⁰)
(1) Updates
- (1.1) on Seraphis¹¹:
- UkoeHB implemented binned reference sets and plans to work on the 16/2 jamtis address index discussion/possible implementation, then discretized fees
- (1.2) on statistical analysis:
- mj-xmr reported progress with the decoy selection algo analysis¹², having summarized both the results and the strategy, and is planning to perform statistical analysis with Rucknium and jberman
- mj-xmr mentioned the next (parallel) task of simulating the behavior of the system (fee and block size) in case of a sudden increase of transactions
- Rucknium is working on estimating the effect (if any) of Minexmr’s increase in its pool fee from 1.0% to 1.1% on April 1st¹³
- (1.3) on view tags and security:
- jberman added support for view tags to the block explorer + monero-lws, helped add support for view tags to monero-python, and helped patch a vulnerability reported by kayabaNerve¹⁴
(2) Larger JAMTIS¹⁵ address tags (and address indices)
- UkoeHB explained the address tag’s MAC and how increasing the size from 8 -> 18 will increase the blowfish ciphers from 1 to 3, but increasing the mac from 1 -> 2 bytes will reduce the cost of filter-failures by 1/256
- jberman pointed out that 10 bytes per output would probably be more significant if the idea to have all tx’s use 16 outputs was implemented¹⁶
- UkoeHB mentioned plans to do performance tests comparing 7/1 vs 16/2 jamtis address tags (size in bytes)
(3) Ending comments
- cryptogrampy mentioned HotShop¹⁷
- selsta was looking for someone to do an updated multisig writeup of the cryptography that should help the next audit (preferably before the launch of Haveno)
- Rucknium suggested MAGIC¹⁸ could help fund the writeup and audit, and pinged coinstudent2048
- jberman pinged dangerousfreedom for the task

Let me know if you find this kind of report helpful. If not, I will redirect time spent on this to other tasks.

Feedback, edits always welcome @/about.

-3RA

https://github.com/UkoeHB ↩
https://github.com/selsta ↩
https://github.com/j-berman ↩
https://github.com/ACK-J ↩
https://github.com/mj-xmr ↩
https://github.com/Rucknium ↩
https://github.com/CryptoGrampy ↩
https://github.com/kayabaNerve ↩
@merope:matrix.org ↩
https://github.com/Gingeropolous ↩
/ukoehb-submits-second-seraphis-wallet-poc-ccs-proposal/ ↩
https://github.com/mj-xmr/monero-mrl-mj/tree/decoy/decoy ↩
/minexmr-top-monero-pool-hashrate-drops-from-50-to-38-percent/ ↩
/kayabanerve-discovers-security-vulnerability-monero-python-module/ ↩
https://gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024 ↩
https://github.com/monero-project/research-lab/issues/96 ↩
/cryptogrampy-submits-ccs-proposal-hotshop-monero-pos/ ↩
/magic-monero-fund-starts-accepting-research-grant-applications/ ↩

Meeting summary: Monero Community Workgroup, 1 May 2022

Thu, 05 May 2022 UTC

This is a comprehensive summary, with added reference links, of the Monero Community Workgroup meeting from May 1st 2022, 1700 UTC.

Logs

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

220501-community.log (172 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: 7 (plowsof¹, monerobull², cryptogrampy³, merope⁴, w⁵, Rucknium⁶, midipoet⁷)
(1) Community highlights
- (1.1) on the upcoming v15 network update⁸:
- plowsof mentioned Sethforprivacy’s hardfork checklist⁹
- monerobull got a reply from Kraken support stating that their developers will keep things up to date [with the upcoming network update]
- (1.2) on malicious remote nodes tricking users into paying high fees¹⁰:
- plowsof mentioned the malicious nodes that were causing trouble with high tx fees, the warning that was added to the Monero GUI wallet¹¹ and the proposed long term fix (list of trusted nodes)
- monerobull suggested including a fallback to random nodes
- w argued against a fall back to random, citing malicious actors that would try to get on the auto-lists
- merope jumped in to suggest taking advantage of the already trusted main seed nodes of the network that are used for bootstrapping the network
- plowsof added that Feather wallet also has some list of nodes it performs health checks on
- cryptogrampy warned of a potential increase in reliance on the seeds
- (1.3) on the latest Monero GUI/CLI releases¹²:
- plowsof reminded everyone to upgrade to the newest version, 0.17.3.2
(2) CCS Ideas
- (2.1) on spirobel’s ‘Monero Afghanistan Expansion Strategy’ proposal¹³:
- monerobull voted against
- w expressed their skepticism about how this CCS could help an entire country
- cryptogrampy suggested spirobel should reintroduce the proposal in a more palatable way in the future
- (2.2) on oeAdgK01’s ‘Translation of Monero GUI Wallet, CLI Wallet, monero-site, Behavioral Finance, Cryptocurrency Markets (subtitles), Moneropedia, User Guides to Greek’ proposal¹⁴:
- plowsof mentioned the ongoing problem related to the lack of reviewers
- monerobull expressed their frustration with the current translation system that essentially renders translations that were already funded entirely worthless
- (2.3) on Moneroist’s ‘Patronero - Open Source project for donating by mining’ proposal¹⁵:
- monerobull voted against, expressing doubts about the practicality of the project: who would ever download a miner to support someone[?]
- cryptogrampy suggested that a public api that uses an agreed upon shared database (git repo?) of public addresses people would like to receive donations at would be more useful than a one off mining thing
- merope voted against, pointing to the extremely low profitability of mining: unless the donor has a ton of hashrate, it won’t be very useful, and doubted the need for two separate apps which apparently serve the same function
- Rucknium chimed in to state that Patronero may cost more in CCS funds than it raises
- (2.4) on willk’s ‘Monero business kit’ proposal¹⁶:
- cryptogrampy found the idea of a an all in one docker deployable web shop very cool but insisted on getting an answer on why it should get community funded / why people need it over existing solutions
- w wondered if the proposer had any plans of monetizing the project
- monerobull wondered if the requested funding was reasonable: is that worth 100+ xmr[?]
- Rucknium stated that the proposal was strongly improved from its initial draft but it should go out and get more engagement
- (2.5) on koe’s ‘Seraphis Wallet PoC 2 funding proposal’¹⁷:
- w, merope, monerobull, plowsof, all voted for
(3) WiP CCS proposals
- plowsof mentioned Rucknium’s OSPEAD¹⁸ proposal in context of the recently set HF date
- Rucknium confirmed that the timeline for OSPEAD is now more clear and the hard fork (and rise of ring size from 11 to 16) should help with the statistical estimation
- plowsof has been trying to re-unite funds from the CCS to their rightful owners, looking to see if any of the devs are having issues¹⁹
- plowsof confirmed that hinto, maintainer of monero-bash²⁰, has been paid out in full after completing all CCS milestones, and all other overdue payment issues were resolved
- plowsof stated that m0n3r0d1c3’s (proposer of the Monero casino CCS²¹) IRC/Matrix connectivity issues should also be resolved soon
- midipoet confirmed that they have received half of the funds as a payout and organised flight and hotel for Oslo²²
- midipoet asked the community what type of educational material they should hand out at the event
- (4) Open Ideas
- plowsof suggested adding –rpc-access-control-origins=* to a public node config to help the monero-javascript ecosystem
- plowsof asked if anyone is interested in podcasting 2.0 using Monero
- merope suggested an idea for a potential future CCS proposal about promoting Monero in the UAE
/end

Let me know if you find this type of report helpful. If not, I will redirect time spent on this to other tasks.

Feedback, suggestions and edits always welcome @/about.

-3RA

https://github.com/plowsof ↩
https://libredd.it/user/monerobull ↩
https://github.com/CryptoGrampy ↩
@merope:matrix.org ↩
@w:matrix.org ↩
https://github.com/Rucknium ↩
https://github.com/midipoet ↩
/monero-consensus-hard-fork-16-july-2022/ ↩
https://github.com/monero-project/meta/issues/690 ↩
/xmrmfjj2-tricked-paying-exorbitant-19.73-xmr-fee-malicious-remote-node/ ↩
https://github.com/monero-project/monero-gui/pull/3897 ↩
/monero-gui-v0.17.3.2-oxygen-orion-point-release-p2pool-mining-support/ ↩
https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/282 ↩
https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/296 ↩
https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/310 ↩
https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/311 ↩
https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/314 ↩
/rucknium-ospead-ccs-proposal/ ↩
/plowsof/ ↩
/hinto-janaiyo-releases-monero-bash-v1.5-completes-ccs-proposal/ ↩
/m0n3r0d1c3-submits-ccs-proposal-deploy-monero-dice-casino/ ↩
/midipoet-submits-ccs-proposal-oslo-freedom-forum-attendance/ ↩

Monero Observer

Meeting summary: Monero Research Lab, 19 February 2025

Logs

Summary

Meeting summary: Monero Community Workgroup, 28 September 2024

Logs

Summary

/end

Meeting summary: Monero Research Lab, 31 July 2024

Logs

Summary

Meeting summary: Monero Research Lab, 19 June 2024

Logs

Summary

Meeting summary: Monero Research Lab, 15 May 2024

Logs

Summary

Meeting summary: Monero Research Lab, 14 February 2024

Logs

Summary

Meeting summary: Monero Research Lab, 10 January 2024

Logs

Summary

Meeting summary: Monero Community Workgroup, 11 November 2023

Logs

Summary

/end

Meeting summary: Seraphis Wallet Workgroup, 9 October 2023

Logs

Summary

Meeting summary: Monero Research Lab, 4 October 2023

Logs

Summary

Meeting summary: Monero Research Lab, 3 May 2023

Logs

Summary

Meeting summary: Monero Research Lab, 5 April 2023

Logs

Summary

Meeting summary: Monero Research Lab, 8 March 2023

Logs

Summary

Meeting summary: Monero Research Lab, 1 March 2023

Logs

Summary

Meeting summary: Monero Research Lab, 18 January 2023

Logs

Summary

Meeting summary: Seraphis Wallet Workgroup, 16 January 2023

Logs

Summary

Meeting summary: Seraphis Wallet Workgroup, 2 January 2023

Logs

Summary

Meeting summary: Monero Research Lab, 7 December 2022

Logs

Summary

Meeting summary: Seraphis Wallet Workgroup, 14 November 2022

Logs

Summary

Meeting summary: Monero Research Lab, 5 October 2022

Logs

Summary

Meeting summary: Monero Research Lab, 14 September 2022

Logs

Summary

Meeting summary: Monero Research Lab, 10 August 2022

Logs

Summary

Meeting summary: Monero Research Lab, 13 July 2022

Logs

Summary

Meeting summary: Monero Research Lab, 22 June 2022

Logs

Summary

Meeting summary: Monero Research Lab, 8 June 2022

Logs

Summary

Meeting summary: Monero Community Workgroup, 29 May 2022

Logs