<sgp_> To summarize the audit quotes we received for the Helios/Selene review:

<sgp_> * The 7 quotes ranged from $15,000 to $100,000.

<sgp_> * The most affordable for $15,000 would be an honest review, but they appear to be less qualified than some others. I believe it is the second best option overall.

<sgp_> * One for $35,000 is probably the best blend of affordability and expertise.[... more lines follow, see mrelay.p2pool.observer/e/nKy02YsLTVZFNE1K ]

<syntheticbird> 100k is Zellic

<syntheticbird> calling it

<sgp_> They did not submit a bid for this one unfortunately

<syntheticbird> damn it

<fireine:matrix.org> MONEROCHAN OS

<fireine:matrix.org> A Freestanding RISC-V Microkernel with Capability-Gated IPC for Privacy-Coin Workloads

<fireine:matrix.org> doi.org/10.31224/7266

<jpk68:matrix.org> @fireine:matrix.org: Did you mean to cite Goodell instead of Feickert for the CryptoNote whitepaper review?

<fireine:matrix.org> @jpk68:matrix.org: No.

<fireine:matrix.org> web.getmonero.org/es/resources/rese…arch-lab/pubs/whitepaper_review.pdf

<jpk68:matrix.org> I was under the impression that Goodell was Surae, I could be wrong :P

he is

<fireine:matrix.org> @jpk68:matrix.org: reddit.com/r/Monero/comments/31jz5u…onero_devs_with_the_surname_noether

<fireine:matrix.org> mrelay.p2pool.observer/m/matrix.org/mILYEiYhzjpMqrQYurieFNRt.png (Screenshot 2026-06-10 at 11.24.53 AM.png)

<fireine:matrix.org> nioc: S Noether is all three?

yes :)

sarang, surae and shen

<fireine:matrix.org> I'm sure if it's an issue they'll send me another eail.

<fireine:matrix.org> nioc: exactly.

<jpk68:matrix.org> nioc: He's which, Surae?

<rucknium> MRL meeting in this room in 1.5 hours.

<fireine:matrix.org> @rucknium: was the agenda already posted?

<fireine:matrix.org> nioc: bc S Noether is legit all three, attribution is kind of confusing here when writing the bibliography from memory (esp if you have a terrible memory). we will fix at v2 of the MONEROCHAN OS preprint. Surae and Sarang I had assumed were the same individual (S Noether).

<jpk68:matrix.org> I am 99.5% sure that Surae is Goodell and not Feickert

I am 100% sure

<rucknium> @fireine:matrix.org: I just posted now: monero-project/meta #1402

<fireine:matrix.org> nioc: Well, in this case I'll need to refine the bibtex accordingly but will do that at version 2 of the preprint once we've finished the network driver and ARMv8 port for MONEROCHAN OS. S. Noether is indeed all three — which caused the confusion.

<fireine:matrix.org> @rucknium: THX!

<brandon:cypherstack.com> Goodell = surae

<brandon:cypherstack.com> There are at least three S Noethers

<fireine:matrix.org> @brandon:cypherstack.com: which one are you, @brandon:cypherstack.com

<fireine:matrix.org> I need to make sure I don't f*** up the bibtex at the future

<fireine:matrix.org> @brandon:cypherstack.com: Ok. Aaron is Surang, you are...?

Aaron is Sarang not Surang

<brandon:cypherstack.com> Aaron is sarang, I am surae, and when I believe is still pseudonymous?

<fireine:matrix.org> @brandon:cypherstack.com: Goodell isn't Brandon. But U are @brandon:cypherstack.com

<fireine:matrix.org> nioc: Ok.

<jpk68:matrix.org> @fireine:matrix.org It looks like there are a number of other errors in your paper.

<fireine:matrix.org> @jpk68:matrix.org: not really.

<brandon:cypherstack.com> Shen*

<fireine:matrix.org> it's a preprint

<fireine:matrix.org> not a peer reviewed manuscript

<jpk68:matrix.org> @fireine:matrix.org: For example: you say SHA256 is used for transaction construction in Monero

<fireine:matrix.org> @jpk68:matrix.org: there might be typos in the paper.

<fireine:matrix.org> but the OS runs

<jpk68:matrix.org> It's not a typo, it's a factual error, but okay

<fireine:matrix.org> @jpk68:matrix.org: curves are themselves rational errors at a pq blockchain technology, but okm

<fireine:matrix.org> @jpk68:matrix.org: I am working on like 3 different projects at the same time, some use different curves or NIST primitives.

<fireine:matrix.org> your critique is pedantic.

<fireine:matrix.org> what's important is the reduction of attack surface

<fireine:matrix.org> from 30 million lines of code, to under 2000.

<fireine:matrix.org> again, I hope you understand this is a preprint — not a journal.

<fireine:matrix.org> docs.getmonero.org/cryptography/asymmetric/edwards25519

<fireine:matrix.org> @jpk68:matrix.org: edwards25519 elliptic curve. curve typo. there are tons of curves and I work on blockchain tech spanning many

<syntheticbird> what are you guys talking about ?

<fireine:matrix.org> like at substrate

<fireine:matrix.org> @syntheticbird: MONEROCHAN OS

<fireine:matrix.org> it's this experimental thing

<fireine:matrix.org> for exchanges and large holders.

<fireine:matrix.org> mostly exchanges.

<syntheticbird> do you have a link or something? never heard about it

<fireine:matrix.org> @syntheticbird: google MONEROCHAN OS

<fireine:matrix.org> second on search results

<fireine:matrix.org> mrelay.p2pool.observer/m/matrix.org/iwTxzbsWnfUKlwoakwRwAYIs.jpeg (IMG_2247.jpeg)

<syntheticbird> yes im reading it

<fireine:matrix.org> @syntheticbird: it's for exchanges mostly so maybe not of interest to you. don't waste cpu cycles if u don't need to :)

<fireine:matrix.org> it was just this thing that might make sense for enterprise investors / exchanges

<fireine:matrix.org> this can be run at $130 hardware, btw

<syntheticbird> ok sounds like a fun project

<syntheticbird> fun is about it, I don't expect this to ever be used in production

<fireine:matrix.org> @syntheticbird: Indeed, it is. My Japanese friend from Isesaki is helping out on the hardware end.

<fireine:matrix.org> @syntheticbird: exchanges might use it or enterprises. if monero continues to scale.

<syntheticbird> whats his name? you didn't name it in the paper ?

<jpk68:matrix.org> This is going to be a fun meeting 🙄

<fireine:matrix.org> @syntheticbird: he might be at a later version of the work when we run some tests at his hardware recommendations

<fireine:matrix.org> but his name is sage.

<rucknium> This is going to be an orderly meeting. Or at least semi-orderly.

<fireine:matrix.org> @freeman:cypherstack.com has seen him at the wild, lol.

<ofrnxmr> @brandon:cypherstack.com: Yeah, i don't think shen ever revealed himself

<syntheticbird> you said Aaron has shown interest in collaborating on your work. You collaborated already on this ?

<fireine:matrix.org> monero is a fun project. one such project that should be secure and auditable (at least for exchanges and enterprises) > <@syntheticbird> ok sounds like a fun project

<fireine:matrix.org> @syntheticbird: oh no thats at the @freeman:cypherstack.com universe.

<syntheticbird> what

<fireine:matrix.org> we aren't anywhere near publishing that lol

<fireine:matrix.org> @syntheticbird: we are extending Aaron's work

<fireine:matrix.org> more specifically — Helsing.

<syntheticbird> why are you talking about freeman

<syntheticbird> idu

<ofrnxmr> he needs to ping people every 0.5 seconds

<ofrnxmr> @fireine:matrix.org you know that you can say someone name without sending them a notification, right?

<fireine:matrix.org> Given the growing interest in formal verification and security-hardened systems within the cryptocurrency space, labeling this as "just for fun" may ignore its potential as a blueprint for future, ultra-secure node deployments. > <@syntheticbird> fun is about it, I don't expect this to ever be used in production

<ofrnxmr> Right, so why is this discussion here 🫡 > <@syntheticbird> ok sounds like a fun project

<fireine:matrix.org> @syntheticbird: well, I work with freeman lol. informally thru private channels

<ofrnxmr> Aside from the name, what is the relevance to monero?

<fireine:matrix.org> @ofrnxmr: clearly you didn't read the paper

<rucknium> It's a good topic for #monero-community-dev:monero.social

<fireine:matrix.org> @rucknium: Nope. It's non-trivial.

<ofrnxmr> Who tokd you that community dev was for trivial projects?

<fireine:matrix.org> @ofrnxmr: this is an important research direction

<fireine:matrix.org> lack of formal verification is why zcash got pwned recently

<ofrnxmr> important for the monero network?

<fireine:matrix.org> @rucknium: The project is specifically designed to be minimalist to solve a non-trivial problem

<ofrnxmr> @fireine:matrix.org: The problem being solved is what?

<fireine:matrix.org> @ofrnxmr: By explicitly targeting RISC-V and utilizing its specific MMU (SV32) and trap-handling capabilities, the project integrates software security with hardware architecture, which is a core tenant of modern systems security engineering.

<syntheticbird> > <@fireine:matrix.org> Given the growing interest in formal verification and security-hardened systems within the cryptocurrency space, labeling this as "just for fun" may ignore its potential as a blueprint for future, ultra-secure node deployments.

<syntheticbird> You are coming here with a preprint with multiple obvious errors that shows you don't even have a PoC, because that is obviously a slop. And you are there seriously trying to make anyone swallow your deranged document have any value whatsoever in the real world. I would hope for the best case you were delusional. "Fun" is abou [... too long, see mrelay.p2pool.observer/e/rIar3osLSHJiSTBY ]

<jpk68:matrix.org> @fireine:matrix.org: Thanks, the paper does have an abstract at the top...

<fireine:matrix.org> @syntheticbird: a typo at the curve and author? lol

<fireine:matrix.org> you're just a hater

<jbabb:cypherstack.com> @fireine:matrix.org: usually people start discussions in matrix.to/#/#monero-community-dev:monero.social then move to posting just work (papers, git issues, etc) here with extended discussion in matrix.to/#/#monero-research-lounge:monero.social

<jbabb:cypherstack.com> discussing things in the various rooms just help keep discussions focused, so that ONLY technical matters and concerns can be discussed here, wider-ranging discussions in the Lounge, and basically everything starts in Community Dev and is "promoted" upwards through interest and acclaim

<rucknium> Could this conversation move to #monero-research-lounge:monero.social ?

<fireine:matrix.org> @jbabb:cypherstack.com: where are the community guidelines articulating this pipeline

<fireine:matrix.org> @jbabb:cypherstack.com: an OS is technical. this hasn't ben done.

<rucknium> Matrix room topic says: "Casual chats: #monero-research-lounge:monero.social | Meetings Wednesday @ 17:00 UTC | Be excellent to each other"

<syntheticbird> As anyone managed to prove his identity whatsoever ? Because if not he should just be banned. We would have a much better meeting.

<fireine:matrix.org> this is technical work

<fireine:matrix.org> @rucknium: not a casual chat

<rucknium> But are we being excellent to each other? We must always ask ourselves this.

<jpk68:matrix.org> @fireine:matrix.org It looks like you have been requested to move this convo elsewhere. Keep in mind, you're publishing this paper under your real name; reacting to actual researchers with clown emojis and insulting people is probably not doing wonders for your academic career

<fireine:matrix.org> @rucknium: Current Monero nodes rely on the security of millions of lines of code in a host OS kernel, which is a fragile perimeter.

<syntheticbird> @jpk68:matrix.org: its not his

<fireine:matrix.org> Our project provides a concrete path toward an open-hardware, low-TCB alternative that removes reliance on proprietary TEEs (like SGX) or massive hypervisors (like Xen).

<fireine:matrix.org> thats technical. full stop

<jpk68:matrix.org> @syntheticbird: Ah, I should have known :P

<jbabb:cypherstack.com> but the discussion has not been

<rucknium> We don't need to prove anyone's identity for contributions to be helpful (converse is also true).

<syntheticbird> let's stop the bullshit he is obviously not stephenson. He has multiple time referenced collaboration with people that didn't confirm. He is an anonymous person, pushing useless crap into the channel, disrupting meeting, being provocative to any critics.

<fireine:matrix.org> @syntheticbird: it's not useless crap

<syntheticbird> @rucknium:monero.social, its a matter of whether he is lying or not

<rucknium> Please move this conversation to #monero-research-lounge:monero.social now.

<jbabb:cypherstack.com> the discussion has not been technical in nature*. it's just really hard to keep up with every message and I'm finding that it's not important to do so

<jbabb:cypherstack.com> so because topics are "promoted" to "important" through mutual acclaim and interest, seeking consesus--and the sentiment seems to be sour--I just try to offer some social norms/cues that may be helpful

<fireine:matrix.org> @rucknium: Sure. But you can't claim MONEROCHAN OS is trivial. The software blueprint is certaily non-trivial

<fireine:matrix.org> and felt it made sense to share

<fireine:matrix.org> @jbabb:cypherstack.com: it's a technical paper

the preprint is clearly LLM generated slop

<fireine:matrix.org> people are pushing pedantic arguments

<fireine:matrix.org> tobtoht: thats all cap.

<fireine:matrix.org> prove it.

<rucknium> I activated enhanced moderation in this room.

<freeman:cypherstack.com> Hey man, I dunno if I would say that we work together > <@fireine:matrix.org> well, I work with freeman lol. informally thru private channels

<freeman:cypherstack.com> I’m not a part of this, sorry for any miscommunication

<syntheticbird> ## LMAO

<freeman:cypherstack.com> He (whoever he is) appended my name as an author to a GitHub repo that I had no part in. I asked him to take my name off it. I deny any personal association completely

<jpk68:matrix.org> I am willing to bet that every message in this meeting will have a clown emoji on it, if someone's reaction permissions aren't revoked

<syntheticbird> fireine you haven't clowned my lmao message can you do it

<syntheticbird> oh you retracted

<syntheticbird> good boy

<rucknium> I changed moderation back to normal.

<rucknium> Meeting time! monero-project/meta #1402

<rucknium> 1. Greetings

Hi

<jberman> waves

<sgp_> hello

<boog900> hi

Hello

<jpk68:matrix.org> Hello

<vtnerd> hi

<jeffro256> Howdy

<rucknium> 2. Updates. What is everyone working on?

hi

<articmine> Hi

me: Jamtis specs

me: reviewed jberman's curve tree builder, probably start reviewing carrot_impl/etc.

<syntheticbird> Hi

<rucknium> me: I wrote a preliminary review of the monerosim network simulator public beta: Fountain5405/monerosim #3 . I may have uncovered some connection stability issues that @gingeropolous:monero.social is working through. Also I'm keeping stressnet stressed.

<jeffro256> Me: updating some crypto code according to Cypherstack's FCMP++ audit, stressing the stressnet, working on header-only sync and wallet-side fee calculation logic locally

<jberman> Continued remediation from phase 1 of the FCMP++ integration audit (Cypher Stack's audit was of comparable quality to the Trail of Bits audit they caught mostly the same informational issues [well done Cypher Stack], working with Trail of Bits to complete the final task from Phase 1B ensuring all expected legacy enotes remai [... too long, see mrelay.p2pool.observer/e/oqH734sLem1Zc1RN ]

<vtnerd> me: primarily ssl related fixes to tests, and beginnings of the wallet metadata encryption lib I proposed in my ccs

<vtnerd> also Im somewhat stalled on the block size limit issue, as I’ve exhausted ways to alleviate the limits of de-serialization unless we switch to a DOMless parser that knows what values its unpacking

<gingeropolous> me: monerosim , responding to review

<vtnerd> I thought I could sneak something in the existing code, but it doesn’t work with pruned txes being sent via p2p

<jpk68:matrix.org> @vtnerd: Boost.JSON is DOMless, right? That might also allow us to remove a dependency

<rucknium> @vtnerd:monero.social: Is this the 100MB limit?

<rucknium> 3. Helios/Selene review.

<rucknium> @sgp_:monero.social ^

<sgp_> MAGIC Grants has received 7 quotes ranging from $15,000 to $100,000

<sgp_> The $15,000 one would be an honest review, but I recommend a review for $35,000 since the auditors appear to have more experience. It seems like the best compromise between cost and skill

<sgp_> Jeffo, Luke, and Berman can also add their comments if they like

<vtnerd> @jpk68:matrix.org: afaik, it is not domless

<sgp_> I would like to get approval during this meeting to go forward with the $35,000 one as the selected option

<vtnerd> @rucknium:monero.socialthis is the vague limit set by the epee decoder. I recally @ofrnxmr:monero.socialclaiming it was actually limited around ~33MiB due to hitting the hard limits on strings

<sgp_> unless people strongly feel that it's best to select the cheapest one, or have other opinions

<jberman> I second that opinion, $35k quote appears the best value

+1 for the 35K quote

<rucknium> Did we get 24 hours notice on the H/S reviewer options?

<vtnerd> and @jpk68 the issue is not related to json, its that the epee format only has parsing to dom, unless we switch to my custom domless epee parser

<rucknium> I don't want to delay, but I am wondering why we have this informal rule that is being broken more often than followed. Or did I miss a prior message?

<sgp_> I thought I posted it here earlier but I guess it was only this morning. Long day

<rucknium> op @irc_articmine:monero.social 10

<rucknium> Oops

<rucknium> Have @jeffro256:monero.social , @kayabanerve:matrix.org , and @jberman:monero.social seen more details about the review quotes? > <@sgp_> Jeffo, Luke, and Berman can also add their comments if they like

<sgp_> I'll let them answer but if someone else wants to review as well, please ask

<jberman> We have 2 layers of beaureaucracy now for managing audits, and multiple audit tasks in flight. I don't fault sgp on this. We have been discussing the candidates internally as well > <@rucknium> I don't want to delay, but I am wondering why we have this informal rule that is being broken more often than followed. Or did I miss a prior message?

<jberman> @rucknium: Yes

<sgp_> I do fault sgp on this :p

Any info about the lead time on the audit?

<jberman> 35k candidate was also my number 1 prior to this meeting

<jeffro256> SGP sent info last week, but I just haven't gotten around to analyzing it deeply, sorry

<sgp_> tevador: Give me one sec to double check

<sgp_> In the quote they put June 8th as the suggested start date, but we are past that. So we will need to confirm new dates while finalizing

OK, it means they will probably start without a delay

<sgp_> Hopefully so. Before finalizing acceptance with them, I will get clarity on the new start date and ensure it's acceptable to berman, jeffro, luke

Does anyone object to going with the 35K quote?

<sgp_> fwiw, MAGIC Grants hired the same auditor for the June 8th slot because that other project moved a bit faster. Let me check when that ends; that end date might be the most likely new start date

<sgp_> that project is June 9 to 29. So if they can't do concurrent with different team members, then possibly a June 29th/30th start

I am not sure about accepting ... we have now only statements from sgp and jberman, if I followed correctly. Would be assuring to have at least 1 more IMHO

<sgp_> fwiw, I don't think this review is blocking anything, at least strictly speaking. It's something that needs to get done, but there's no expected work that is waiting on this afaik

<jberman> End of June start date would be acceptable to me

<sgp_> @jeffro256:monero.social: do you have time to review it now?

So we have time to postpone the decision until the next meeting

<sgp_> We can, I just won't move to finalize anything until the funds are in order

There would be 2 reasons to postpone: 1) the 24h notice and 2) giving jeffro256 time to review it

<jeffro256> The firm for 35K is one that I have never worked with directly, but I have heard goof things about them

<jeffro256> *good

<syntheticbird> MINOR SPELLING MISTAKES

<rucknium> rbrunner: How do you feel about accepting now?

<rucknium> Not to pressure you or anything.

Let's say I don't oppose :)

<sgp_> let's just wait then. Ideally luigi could be ready to go after the meeting

<rucknium> Sounds good. Thank you for arranging things.

<jeffro256> Yes, thanks @sgp_:monero.social

+1

<rucknium> 4. Post-quantum encryption (monero-project/research-lab #151#issuecomment-4412416686). Jamtis (gist.github.com/tevador/639d083c994…32#appendix-c-instant-sync-protocol).

I have published the interactive payment protocol (IPP) and the instant sync protocol (ISP) in the Jamtis draft appendix. I'd like to discuss these today.

<jberman> My opinion on the ISP is that I don't like the UX and am pretty eh on its inclusion in the spec as its a tacit encouragement for wallets to implement it

<jberman> But it's a cool idea and I respect that it's 0 added cost on addresses / chain space

<jeffro256> Re: UX, I would assume that wallets can implement this exchange automatically. Bob and Alice wouldn't actually be copying and pasting messages 4 times

<jeffro256> I mean, you could if you wanted it to be airgapped ig

Hmm, isn't this the same problem as with multisig data exchanges earlier: wallets can't directly see each other?

Note that jberman is speaking about Appendix C, while jeffro256 is speaking about Appendix B

<jberman> ^

<jbabb:cypherstack.com> Jamtis-ISP > Monero-PSK

<jeffro256> Oh oops, sorry, yeah I was talking about IPP

Yes, Appendix C was added in response to the Monero-PSK proposal

It's the closest thing we can do with Jamtis

<jberman> One thing to be clear about for IPP: is there a way to restore an IPP wallet from blockchain data? I was under the impression that wasn't the case, but the spec isn't perfectly clear on that

Exchanging data directly between wallets is a problem that I thought long and hard and found no easy and straightforward way

<jeffro256> rbrunner: Are you taking about IPP or ISP? For IPP, you wouldn't need a transport layer with long-term storage like Bitbucket since messages can fail at any point and you end up okay. Whereas the same can't necessarily be said about multisig. Also you only need 2-way comms, not N-way comms

jberman: the interactive payment is restorable from blockchain data (as an internal payment)

<spirobel:kernal.eu> yes and there is another way to do it in one round. so wallets can be shared publicly and users can directly send the tx without having to wait for the other party to be online > <@jeffro256> Re: UX, I would assume that wallets can implement this exchange automatically. Bob and Alice wouldn't actually be copying and pasting messages 4 times

<jeffro256> *bitmessage

jeffro256: Data exchange between wallets quite in general. If if only "both online" and "only 2 way", how would they find each other?

*Even if only ...

<spirobel:kernal.eu> i am not a fan of jamtis. and pushing it down everyones throat. but i dont want to stand in your guys way if you want to implement it

<spirobel:kernal.eu> i personally dont want to use it because i think this pq crypto is too new and unproven

<spirobel:kernal.eu> people can just use signal or other messaging apps and treat the addresses as secret key material

<jberman> Aka public key sharing infrastructure? > <@spirobel:kernal.eu> yes and there is another way to do it in one round. so wallets can be shared publicly and users can directly send the tx without having to wait for the other party to be online

Well, standing up to a task, actually producing something, and then proposing it, is not "pushing it down my throat" in my book

<jeffro256> Lots of ways. For example, if a merchant has a website that you interact with anyways, you could use a HTTP API (hopefully somewhat standardized)

"PQ crypto new and unproven" - that's why we have hybrid encryption, IMO that's not a real reason against Jamtis.

Exactly, let's standardize something :)

<spirobel:kernal.eu> @jeffro256: yes i am currently working on exactly this. i have a few endpoints already specified and working.

<jberman> @jeffro256: Specifically for the case of friend wants to pay a friend e.g. not a merchant payment

<jberman> Or merchant hasn't set up a server

"people can just use signal" - good luck doing that with a static donation address

<jpk68:matrix.org> I think having to use public key-sharing infrastructure is way more of a UX hurdle than, say long addresses with Jamtis

<jpk68:matrix.org> Look at how unusable PGP is for the average person

Getting something accepted as new standard in our, well, quite chaotic ecosystem, is a bit of a challenge, me things ...

*me thinks

<jberman> tevador: And with the scheme, as soon as you share a static address from your wallet, your wallet then has to scan the chain into perpetuity to identify receives

<rucknium> Is anyone very familiar with BitPay? I think they have wallet-specific interaction protocols for BTC and other coins.

<spirobel:kernal.eu> @jberman: i want to add messaging functionality anyway. so there is the possibility to do it automated and standardized but the user is not forced to. they can also send the receiver a snippet / link over any other (encrypted) chat app / email

<spirobel:kernal.eu> @jpk68:matrix.org: yes its not good. so we have to do better

<jberman> Automated = via a messaging server in the middle

<jeffro256> If neither of you run a server of your own (e.g. you're both on mobile), and you're okay with bouncing messages off another server, Websockets is a good option > <@jberman> Specifically for the case of friend wants to pay a friend e.g. not a merchant payment

jberman: my response was directed to spirobel, who thinks we don't need to support static addresses at all (see Monero-PSK)

<spirobel:kernal.eu> no use to private payments if people communicate non encrypted or over centralized services all the time

<rucknium> BitPay as a whole model isn't very good because they require a lot of controls. I think they did KYC of consumers for merchant txs in some jurisdictions.

<jberman> Lol

<spirobel:kernal.eu> @rucknium: no idea never heard of them

<jberman> @spirobel argue your case why Monero should get rid of static addresses

Jamtis ISP is a way to get instant sync while still supporting static addresses (with the caveat that you lose instant sync if you use a static address)

<rucknium> BitPay is big. So get familiar maybe

<spirobel:kernal.eu> @jberman: i never made this case. i am saying that there should be the option for people to have addresses that dont require syncing. and there should be the option to have static addresses where the sender notifies the receiver out of band, and the receiver then notes down the channel opening so he can recover from seed

<jeffro256> If you are in-person, RFC payments > <@jberman> Specifically for the case of friend wants to pay a friend e.g. not a merchant payment

<spirobel:kernal.eu> and my case is: there is no contradiction to jamtis there you guys can do your pq stuff with 400 bytes addresses and i do my stuff

<spirobel:kernal.eu> no need for this discussion

<rucknium> bitjson, who does a lot of Bitcoin Cash protocol work, used to work at BitPay: github.com/bitjson blog.bitjson.com

Everyone can do their stuff, but the official software cannot support everyone's stuff.

<jberman> @spirobel:kernal.eu: So receiver has to have info saves from the channel opening in order to recover from seed = receiver can't recover instant sync from seed alone

<jberman> Saved*

<spirobel:kernal.eu> @jberman: yes the receiver can recover from seed. both can recover from seed

<jberman> How can the receiver recover from seed alone in that case?

If someone needs to post a static address somewhere, Jamtis offers better long term privacy than a legacy address.

<spirobel:kernal.eu> by finding the channel opening the receiver noted down as i mentioned

<jberman> How do they find it from seed alone?

So that's "from seed", but not "from seed alone"?

jberman: We've been asking spirobel for a draft proposal for a long time. All I've seen are hand waving arguments.

<spirobel:kernal.eu> by noting it down in a tx. in both cases a secret that is derived from seed is embedded in a tx so it can be found later

<jberman> I've also seen insults and poor logic

<spirobel:kernal.eu> doesnt matter who writes it

<spirobel:kernal.eu> i dont know what your point is just move on

<spirobel:kernal.eu> the logic is very simple

The proposal needs to be written by someone who knows the solution, which only seems to be you.

<jberman> This is an interesting idea. A scheme expanding on this and explaining how it works would be interesting to read > <@spirobel:kernal.eu> by noting it down in a tx. in both cases a secret that is derived from seed is embedded in a tx so it can be found later

What speaks against a draft proposal? Things still in flux? Lack of time right now?

<spirobel:kernal.eu> yes i will write it down and build a poc once I have more time

<rucknium> Next agenda item is supposed to be Monero-PSK. It's being discussed now, so:

<rucknium> 5. Monero-PSK (gist.github.com/tevador/9169235b3c0c97e735f58a8c2ba92502).

<rucknium> Should we return to it when spirobel has a draft proposal?

If spirobel's wallet also supports static addresses, I don't think it can be done without scanning. And after restoring from a seed, you can't be sure no static address was ever used. So in the end, you end up with something very similar to Jamtis ISP.

<spirobel:kernal.eu> yes. good idea. I am still busy with other work atm.

<spirobel:kernal.eu> I also want to state that this is not an either or discussion vs jamtis. So there is no need to debate this like a life and death situation :D

<jpk68:matrix.org> Unfortunately, I don't think Q-Day is going to wait with you

<rucknium> 6. FCMP beta stressnet (github.com/seraphis-migration/monero/releases).

<spirobel:kernal.eu> @jpk68:matrix.org: trust me. it will be done before the quantum puter arrives and tells us the answer is 42 :)

<rucknium> I pushed up the stress to 6MB blocks, which is the short-term median. But in the last 24 hours the main spamming server has had an outage.

<spirobel:kernal.eu> and it will be possible to use it in a PQ secure way

<rucknium> I hope I didn't accidentally cause the outage, but it's too early to tell now.

<jberman> @spirobel:kernal.eu: It's ideal for the entire Monero ecosystem to have a standardized protocol for transacting. It's also beneficial to have a complete picture of protocol options before settling on an address protocol

There is no way to do a static PQ secure address without a PQ key exchange. Prove me wrong.

<jeffro256> @rucknium: Thank you for doing that

<spirobel:kernal.eu> @jberman: then lets agree to disagree here. no urgency to this. and no way to force this 400 bytes addressing protocol on everyone

<jpk68:matrix.org> It can fit in an IRC message and that

<jeffro256> Besides the spamming server going out, the daemons seems to be pretty stable AFAICT

spirobel: 400 characters*

<jpk68:matrix.org> *that's, like, the only noticeable difference

<rucknium> I saw some peer banning when hashpower tripled.

Good luck designing a shorter PQ secure address (with static address support).

<jberman> @jeffro256: Yep, this does seem to be the case to me. I'm looking into higher frequency bans, and jeffro's latest optimizing pool fetching (should help both daemons and wallets when the pool is large)

<jberman> And vtnerd's p2p SSL is in the wings right now, we can aim to have that in next beta release

<rucknium> 7. View-all/view-some key.

<rucknium> This was brought up last meeting. Do we want to discuss this issue?

<spirobel:kernal.eu> tevador: the issue with being unable to tell if an address hasnt been used doesnt exist with public / static addresses. it is not like jamtis isp as it requires only one round and the two parties dont have to be online at the same time. thats it

<jbabb:cypherstack.com> I don't see our relevant "fraus bug"/view-all evasion CS researchers online and I think the conclusion from the last discussion, that it shouldn't be re-added to the agenda without a writeup and/or proof of concept, fair. I agree that it requires not adhering to the CARROT spec and it isn't a CARROT-specific issue, it affects [... too long, see mrelay.p2pool.observer/e/sfaM4osLZVIySTVQ ]

<jbabb:cypherstack.com> it is a way to hide things from view keys by not doing things in the way you're supposed to and think it's safe to move on until we/CS share more code

<jbabb:cypherstack.com> the conclusion to stress was that we should not and can not claim that we have "view-all" keys that make monero safe for eg. KYC/AML compliance purposes

<jeffro256> I think that it's a good informational issue to be documented somewhere. I also planned for the view-all tier to be opt-in, but I can see how that would be confusing / concercing to a third-party who expects the view-all properties to hold unconditional on the viewed entity's behavior.

<rucknium> Oh sorry I struck out the wrong agenda items that didn't have write-ups, either.

<jeffro256> *I always planned

<jbabb:cypherstack.com> the new carrot view keys do not guarantee exchanges can see safely view all customer activity

<rucknium> Lots of things last meeting didn't have write-ups

<jeffro256> I mentioned this to BG, but it would make a good footnote in the CARROT spec, yeah? Exactly how to break it, how to make sure the view-all properties can stays intact with further info, etc ...

<jbabb:cypherstack.com> ... any more than the legacy view keys*. however of course the new carrot view keys enable great UX eg for hardware wallets, so I'm excited for it, especially now that the doomerism that "all exchanges will require these new keys" is a technical non-issue (we can lie to the view key)

<jbabb:cypherstack.com> (also you could always just hop one wallet away--much simpler)

<jbabb:cypherstack.com> Sorry, that's all on the topic.

<rucknium> 8. CCS proposal: ProbeLab P2P Network Metrics Proposal (repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667).

<rucknium> I think discussion on this has concluded, but just put it here just in case.

<rucknium> @yiannisbot:matrix.org

<yiannisbot:matrix.org> Hi everyone! 👋

<rucknium> Just some paperwork things: You should remove the strike-through formatting and get it ready to go here: ccs.getmonero.org/funding-required

<rucknium> We know what edits were made because it's a git repo.

<rucknium> And maybe @ofrnxmr:monero.social and @plowsof:matrix.org want to reevaluate their thumb votes on the proposal since they spoke approvingly of it most recently.

<rucknium> @rucknium: I mean you need to get the body ready to be public-facing. Potential donors see the proposal body and evaluate it.

<yiannisbot:matrix.org> Agreed. Wanted to make it easier to spot changes, before we proceed. Will do final edits by tomorrow.

<rucknium> Thank you.

spirobel: you confused Jamtis IPP and Jamtis ISP. Jamtis ISP works offline after an initial 1 round setup.

<rucknium> @yiannisbot:matrix.org: AFAIK, you can finalize the process with @ofrnxmr:monero.social and/or @plowsof:matrix.org

<rucknium> We can end the meeting here. Thanks everyone.

<jeffro256> Thanks everyone

<jpk68:matrix.org> Sorry if this sounds rude, but once something like Jamtis is no longer in use, is it possible to remove the user-facing code for it from the codebase? I guess this would apply to Carrot as well. It seems like needless attack surface if it's not in use anymore

<jpk68:matrix.org> For example, in the wallet implementations

spirobel: of course the problem exists with static addresses. Addresses that have once been published may not stay published forever and you can't know who's still keeping them.

jeffro256: the view-all tier accompanied by a thorough (well-implemented) audit is unconditional (would have to think hard on if you can make such an audit with just the view-all key, which would make that key functionally unconditional). Unviewable enotes would be isolated from viewable, making them essentially in a separate wallet.

"view-all" is really "view-all-within-specs"

jpk68: in the case of moving completely to PQ? Sends to Jamtis addrs would no longer work, whether or not there is user-facing code.

<jpk68:matrix.org> ukoehb: Yes, I understand that. I just mean that, for example, it seems there would be not much point in having carrot_core/carrot_impl if Carrot isn't being used anymore (and is somewhat unrelated to consensus rules). I might be misunderstanding something

jpk68: everything needs to remain at least minimally supported for existing users

<jpk68:matrix.org> So once there are no users (i.e. when we switch to full PQ), then it's unneeded?

It's needed to restore legacy wallets, at the very least.

<jpk68:matrix.org> Ah, I forgot about that. Thanks.

<jeffro256> sech1: should we discuss including the number of txs in the block header hasing blob in v17 in next week;s meeting?

Do you mean excluding? AFAIK it's already included.

<jeffro256> Yes. Whether or not to keep including

<jeffro256> Not the scanning code at least if we plan to alloe people to recover their funds indefinitely > <@jpk68:matrix.org> Sorry if this sounds rude, but once something like Jamtis is no longer in use, is it possible to remove the user-facing code for it from the codebase? I guess this would apply to Carrot as well. It seems like needless attack surface if it's not in use anymore

<jeffro256> But we could remove code to create CARROT-FCMP++ txs, and verify tx proofs for them, which is most of the code in carrot_impl

<jeffro256> tevador: do you mean an opinion either way on keeping the tx count inside the block header hashing blob? I'm on the side of removal since it isn't an accurate metric

<boog900> @jeffro256: why is it not accurate?

<jeffro256> With only header hashing info, it is trivially faked. It can also be "faked" (in the sense that it doesn't represent mempool processing) during consensus validation by keeping txs local to the miner private until block propgation.

<jeffro256> In all scenarios where you can verify that that number means anything, you do it without checking that number

<jeffro256> As such, when people use it as metric for monitoring block template health, they are giving themselves a false sense of security

I think I'm feeling neutral about that. What would be the reason for removing it? Does it cause trouble for P2Pool?

<jeffro256> Because it has no real use case and it takes up space in the block header hashing blob. I don't know about p2pool, but apparently it is displayed in xmrig

<boog900> I know this doesn't really change anything now but having the number of txs hashed makes correcting block 202612 nicer. You don't need to compare the block blob.