<r​ucknium:monero.social> MRL meeting in this room in two hours.

<r​ucknium:monero.social> Meeting time! monero-project/meta #989

<r​ucknium:monero.social> 1) Greetings

<o​ne-horse-wagon:monero.social> Hello!

Hello

hi

<a​rticmine:monero.social> Hi

Hi

<c​haser:monero.social> hello

hi

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

hi

I made a new 0.3 release for LWS - fixing some bugs in recent PRs along the way

otherwise working on multi-machine scanning stil

hey

<r​ucknium:monero.social> me: Starting to develop the tradeoff function between raising tx fees and raising the ring size, measured by cost to a flooding adversary, node operator, and users. Feedback welcome on how to measure the cost.

I've been working on new elliptic curves for FCMP: gist.github.com/tevador/4524c2092178df08996487d4e272b096

<r​ucknium:monero.social> My black marble flooding preliminary analysis was cited in Germany's biggest bitcoin blog, according to janowitz: bitcoinblog.de/2024/04/04/spam-well…o-der-angriff-des-schwarzen-marmors

<r​ucknium:monero.social> I read Cypher Stack's Bulletproofs++ peer review and posted it to MoneroResearch.info: moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=217

<c​haser:monero.social> nice! just curious, how long did it take to find the curves?

<r​ucknium:monero.social> 3) Discussion: Research Pre-Seraphis Full-Chain Membership Proofs. gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86

<s​gp_:monero.social> Hello

The script takes a couple hours to find the curves. It took me a couple days to tune the script.

<a​rticmine:monero.social> I have been researching asymmetric internet connections and DOCSIS . (Data over cable systems interface specification)

<a​rticmine:monero.social> This can have a significant impact on Monero scaling, because of low upload bandwidth.

<a​rticmine:monero.social> The good news is that there is a very significant economic pressure against this. The cable companies are being forced to accept reality

<r​ucknium:monero.social> tevador: I don't know much about this, but is the way that you find the curves consistent with the advice on curves, e.g. at safecurves.cr.yp.to . You are using "an algorithm described in the 2007 paper "Constructing elliptic curves of prime order""

<r​ucknium:monero.social> Ah, I see later in the gist you say that it meats some of the SafeCurves criteria

I thought that CypherStack already submitted their CCS for the GBP review or how they are called, to supersede "Seraphis General Paper Review", but don't see anything on our GitLab instance

<r​ucknium:monero.social> meets*

<s​gp_:monero.social> repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/443

Ah, no, "Generalized Bulletproofs Security Proofs" - it's there, sorry

My bad

My writeup includes the evaluation of the safecurves criteria. We don't meet 4 of the less important ones.

<r​ucknium:monero.social> I think we can discuss Cypher Stack's CCS proposals with the FCMP agenda item because they are related.

<r​ucknium:monero.social> Generalized Bulletproofs Security Proofs repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/443

<c​haser:monero.social> re FCMP+SA+L: I welcome the new direction, just want to highlight that this is 12 months out at the very best. so Rucknium's and Artic's effort is very much welcome and, *if* it bears good fruit in time, I think that would justify a fork before FCMP.

<r​ucknium:monero.social> Seraphis General Paper Review repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/441

<r​ucknium:monero.social> AFAIK, some people in #monero-community:monero.social want the MRL meeting to confirm that the GBP Security Proofs CCS should be merged ASAP (i.e. MRL supports it and then the rest of the CCS process can continue). And that the Seraphis General Paper Review should not go to funding right now, but that it should be discussed in the near future.

<r​ucknium:monero.social> "Some people" includes plowsof, who is the CCS coordinator, too.

<r​ucknium:monero.social> chaser: Of course I would agree that all eggs should not be placed in one basket :)

it would also be a step forward for MRL in terms of autonomy / speed of merges for these research related CCS'

<a​rticmine:monero.social> If the Seraphis General Paper Review does not also down FCMP then this community concern can be addressed.

<s​gp_:monero.social> I see no reason not the merge the GBP proposal asap

In my understanding we had "lose consensus" for going GBP review first, and I am not aware something special or drastic came to light in the week that passed that may change that

(at the end of last week's meeting, I mean)

<r​ucknium:monero.social> I also agree that there is MRL loose consensus for Generalized Security Security Proofs going to Funding Required.

We had veritable rows of donations to the GF of 100 XMR each, and lastly even 200, if that party thinks favorably of FCMPs they might fund that alone :)

<c​haser:monero.social> IIRC from last week, most research on the path to FCMP+SA+L will be useful for Seraphis+FCMP, including GBP, so I would agree it's a good idea.

Yes, the CCS should be merged ASAP.

<a​rticmine:monero.social> I know FCMP is very big.

+1 GBP merge

<tevador> Yes, the CCS should be merged ASAP. <= +1

cc luigi1111 luigi1111w :-P

Btw, I posted some notes about new pre-Seraphis wallet tiers we might get with FCMPs: gist.github.com/kayabaNerve/0e1f771…ment_id=5014753#gistcomment-5014753

What would happen to those "OVK" wallets with a switch to Seraphis and (full) Jamtis?

Sgp mostly a question around volatility funds. Not a big deal I'll get it straightened out with Diego today probably

<r​ucknium:monero.social> For the forward secrecy against a quantum adversary, that's just against discovery of the truly spent output, correct? A quantum adversary could still create counterfeit XMR under all proposals (regular Seraphis, FCMP, etc.), right? So eventually quantum-resistance would required some outputs to be unspendable(?)

rbrunner: Nothing. After Seraphis, all legacy wallets will use the Jamtis keys. The difference would be only for pre-Seraphis outputs.

So there would just be more pre-Seraphis "stuff" to support indefinitely into the future?

<s​gp_:monero.social> this can be done under MAGIC Grants if desired. Or CCS if resolved

thanks luigi1111

<d​iego:cypherstack.com> What if 1 XMR stops being 1 XMR? That's the volatility risk.

You can say pre-Seraphis FCMPs is "stuff to support idenfinitely into the future".

<d​iego:cypherstack.com> I jest of course.

Of course, but I think this would come on top, no?

It's only in the wallet code. Nodes don't care about it.

Key image bug is fixed Diego!

More changes to `wallet2` spaghetti code :)

I am not sure that's really welcome ...

From a dev perspective

As I said, if we don't implement it officially, some 3rd party will.

Do you have somebody in particular in mind? I somehow doubt that somebody would be so adventurous, and so knowledgable

diego: Do you think you can make the requested changes today? Would be nice to have it open for funding later today or latest tomorrow

<u​ntraceable:monero.social> +1 GBP merge

No, but it's an extra feature that users want, so there is incentive.

Maybe I skimmed to quickly: What's the top, the main attraction of those OVK keys and wallets?

<d​iego:cypherstack.com> It will be done today.

No need to "import key images" into view-only wallets.

<d​iego:cypherstack.com> Just to be clear the changes requested are to remove the buffer and amend to 100% payout up front.

<d​iego:cypherstack.com> Is that right Luigi?

Ok. For that I personally would probably risk that somebody overtakes us and implements that on their own accord.

100% upfront depends on quick funding to handle volatility. i suggested some % pre funded / upfront directly from the general fund

tevador: Would this 'new view key' be difficult to implement (code)?

<d​iego:cypherstack.com> See, it's not even decided what to change things to. :P

I see this a bit as a "offer them a finger and they take the whole hand" situation. First it was FCMPs before Seraphis, now it's "Jamtis light" on top ...

I think it would be a relatively small amount of code compared to the rest of FCMPs. But I might be wrong.

<s​gp_:monero.social> I know kayaba isn't here, but my understanding is that this stuff is not a lot of extra work. The cost of the additional scope is minimal

And then forward secrecy ... quantum resistance ... do those cryptographers never sleep :)

It doesn't solve all issues of cryptonote addresses. Just 2 of them (outgoing view keys and separated address generation).

We already *drown* in work, with not really much dev capacity around. People.

It's optional. It can be implemented at any later time after FCMPs. Perhaps someone will volunteer or make a CCS.

If we can reasonably leave out that additional burden, even if slow, I would not touch that.

*even if small

<d​iego:cypherstack.com> Ill be honest plowsof, I'm not in removing volatility buffer unless it's paid up front once funded. I accept the risk of price movement while waiting for funding.

100% upfront to remove the 10% volatility buffer upon full funding of the CCS is the offer put to luigi1111 to figure out today then yes?

<d​iego:cypherstack.com> Yep

Yeah, news today is that maybe Kraken will delist XMR in the EU. The price may make some jumps downwards sometime in the near future.

okok lets fo the figuring out asap, thank you

s/fo/do

Yeah it was a suggestion but I don't see why not. Helps us and you. Ccs doesn't earn interest on money waiting to be paid

<a​rticmine:monero.social> OVK may help with this.

Then Seraphis and Jamtis may help even more - if we can get them out of the door, which we maybe can if we are careful with out dev resources

*our

<c​haser:monero.social> how?

<d​iego:cypherstack.com> Luigi these changes will be made within 2 hours

<d​iego:cypherstack.com> I will let you know and then it can be merged.

Well, I am not sure what exactly ArticMine has in mind, but I am quite sure Seraphis and full Jamtis have more of that :)

rbrunner: As far as I can see it concerns only Ireland and Belgium

<a​rticmine:monero.social> It allows a user to provide the view key to a withdrawal address given to an exchange

Yeah, hopefully. Still, speculators may try to take opportunity and depress the price for a while. I don't think we go towards *lower* volatility, in any case

rbrunner: ArticMine may be referring to exchanges?

<c​haser:monero.social> rbrunner: announcing/delivering upgrades explicitly to improve price action -- I hope we're not going there

<c​haser:monero.social> got it, thanks

No, that's probably I misunderstanding. I was trying to show sympathy to Cyper Stacks insinstence on a volatility buffer

<a​rticmine:monero.social> The user can preserve privacy by a further churn

<a​rticmine:monero.social> This is about optics

<o​ne-horse-wagon:monero.social> chaser: He was refering more to funding CCS proposal in a somewhat volatile market.

<a​rticmine:monero.social> I don't have an issue with identifying the compliance benefits of a proposed hard fork. Particularly when it makes something that has been a part of Monero since the beginning work properly

<r​ucknium:monero.social> "Paranoid about the Seraphis upgrade" monero.town/post/2733485

<r​ucknium:monero.social> "TLDR: I am afraid the Seraphis upgrade might make it possible for governments to pass legislation demanding all businesses and exchanges to collect wallet view keys from users for any and all transactions involving Monero and maintain records, hence allowing state sponsored blockchain analysis companies the abilty to ‘Trace’ Monero transactions."

<r​ucknium:monero.social> IIRC this is a criticism of Jamtis/Seraphis outgoing view keys.

That's of course a whole other can of worms that complicated discussion further

<a​rticmine:monero.social> They won't . Make one churn.

I was more talking from dev capacity / project management point of view

We once had a single monster project ahead of us, Seraphis plus Jamtis. We just added a second monster, FCMP before Seraphis. Can we please pay a bit respect to the situation?

<r​ucknium:monero.social> You would need to move to another wallet, right? Or can you make an outgoing view key for a specific address?

And don't pretend our resources are ample many enough for all that stuff

<a​rticmine:monero.social> Create a new wallet.

Btw, currently existing view keys can act as OVKs with about a 99% accuracy. That point is moot.

<s​gp_:monero.social> agreed. Worrying about the availability of a new key isn't worthwhile imho. People could always just demand the other key or even the private spend key

<a​rticmine:monero.social> This is my point. It is really about optics. The capability has been there all the time.

And we have to rush into that "optics" so pressingly? That it can't wait a year or two more for Seraphis and Jamtis?

I heard 3-5 years.

<r​ucknium:monero.social> The 99% accuracy only works if the tx produces a change output, right?

That was a worst-case estimate of koe, looking that the *currently* already completed stuff in the Seraphis wallet repo.

rucknium: correct

But yeah, if we fancy all possible additional stuff pre-Seraphis and Jamtis, this will almost turn into a self-fullfilling prophecy :)

Worst case you can hold up that almost indefinitely. Just keep everybody busy, done.

<r​ucknium:monero.social> I was going to suggest ending the meeting, but I see kayabanerve typing

<k​ayabanerve:matrix.org> Apologies for not being present. I do believe GBPs should move forward.

<k​ayabanerve:matrix.org> I'm not immediately advocating the OVK solution as prior discussed. It could be an additional update or externally done. Accordingly, it's not taking more (whole new wallet format) than discussed (privacy)

<k​ayabanerve:matrix.org> The forward secrecy commentary is just another increment in privacy, and why I originally viewed two-term output keys. It was just harder to come up with the forward secret opening proof, hence why I only posted the OVK commentary initially.

I think forward secrecy is something that can wait for Seraphis.

<a​rticmine:monero.social> Does adding OVK after FCMP require a hard fork?

No. It only requires a wallet software update.

rbrunner: If OVK can be added fairly easily I am not sure why we would wait

If it is a complex undertaking, might be worthwhile to just focus on FMCP

It could be a "point release" after FCMPs.

FCMP*

<a​rticmine:monero.social> Thank. That is what I thought.

Maybe what I see as a problem will "solve" itself, if FCMPs should take considerably more time to implement and hardfork to than estimated today

As a side note, is anyone willing to write a brief blog / primer on FCMP that can be posted on the Getmonero.org website?

I think this would be beneficial for potential donors as well

Which of course will never happen, who has heard of IT projects that take longer than anticipated :)

<r​ucknium:monero.social> I think what rbrunner was saying is that it seems like a complex undertaking for wallet software even if the cryptography is "simple". Mainnet Monero still has multisig marked as experimental. The only GUI implementation is Rino. tobtoht is working on a usable Feather implementation.

Ah, yes, that little detail of "experimental" multisig only

Maybe we could "repair" that first?

<r​ucknium:monero.social> IIRC koe thought getting it out of experimental should be a priority, in mid-2022 after the last hard fork.

Ok, I am rambling a bit now, sorry, it's a bit much, and it was a long meeting.

I'm making steady progress towards releasing a feather multisig beta.

Speaking of which: kayabanerve does your FCMP protocol work with multisig?

<r​ucknium:monero.social> Thank you, t​obtoht. We can end the meeting. Feel free to continue discussing.

Thanks, Rucknium.

<s​gp_:monero.social> thank you

<m-relay> <d​iego:cypherstack.com> I will let you know and then it can be merged. <= Let's get it to funding required!

<a​rticmine:monero.social> Thanks

<d​iego:cypherstack.com> The proposal text has been adjusted and the front matter/milestones have been adjusted. Please look it over and if it is ready to merge, please do so.

<d​iego:cypherstack.com> repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/443

<k​ayabanerve:matrix.org> tevador: Yes. You'd do a multisig GSP. It's proper transcripting and usage of a DKGd nonce for the private key column.

diego: Looks good to me

<c​haser:monero.social> isn't it an end goal to make churning as a concept meaningless? IMHO it's bad to require users to be aware of the underlying mechanics and expecting them to change their behavior according to it, and especially bad in the case of a privacy coin.

<c​haser:monero.social> also, if this requires the user to maintain a separate wallet for this purpose, from a UX perspective I wouldn't call that just "churning". it's something more, I don't know, "wallet hopping". to me, churning is someithing you can do within the same wallet and account, and easily so.

diego: "1..5 calendar" should probably be fixed to "1.5 calendar". Someone might read 1..5 as a range.

<c​haser:monero.social> I don't remember this having been mentioned: there was recently a minor on-chain tx volume surge to ~50k tx/day, right after the March Flood subdued. bitinfocharts.com/comparison/monero-transactions.html#6m

<a​rticmine:monero.social> Yes wallet hopping is the proper term.

<a​rticmine:monero.social> The idea is that if one has provided the view key and then one wants privacy from the auditor, then one first makes a transfer to another wallet. Then one makes the private tx .

<a​rticmine:monero.social> With FCMP this works well.

Generalized Bulletproofs Security Proofs has moved to funding! ccs.getmonero.org/proposals/cypherstack-gbp-security-proofs.html