Meeting .75hr

meeting time monero-project/meta #859

1. greetings

hello

hi

Hello

Hello

Hi

hi

2. discussion, what is everyone working on?

👋

rmq support for lws (completed), and noise protocol for daemon p2p

me: The OSPEAD estimator should get closer to the true value as N increases, but when I push the number of rings from 200,000 to one million its accuracy seems to plateau. I am troubleshooting this.

Research community resources: WIKINDX, which powers moneroresearch.info , is going to enable "AND" as default in QuickSearch by my request. That's a small step toward better search for users: sourceforge.net/p/wikindx/discussion/888681/thread/1fcdd20630

I jotted down some theoretical improvements to FCMPs, but nothing much on my end.

i think i've finally made 100% of the available silicon in the research computing cluster accessible for R&D (280 threads total). random reminder that the resource is available for anyone who would find it useful.

me: I spent a short time working on the eclib abstraction before concluding that the project of switching everything to a new curve is too immense on every dimension (at least for me to handle). I am now on hiatus from Monero work, so someone else should start leading the meetings.

Me: no update on my end, just returned from traveling. Looking to start making headway on full chain membership proof integration over the next week

I am working on an API to integrate the MAGIC Monero Fund's fundraisers (monerofund.org) into Feather Wallet like CCS fundraisers are.

gingeropolous @gingeropolous:libera.chat: How much storage is available?

14TB SSD, 74TB HDD

gotta run, sadly

To be blunt: Is it a good idea to use CCS funds to work on software where we don't know if the Curve Trees protocol is secure yet? Or is this part of the SeraiDEX labor exchange?

thanks for the update vtnerd

I may ask to generate and store a couple hundred GB data set in the future...

Rucknium @rucknium:monero.social: The Serai "labor exchange" only went up to a post I made months ago on GH.

Further contributions by jberman have been at my financial guarantee. All code has been done by my effective volunteering so far, though I do plan a CCS for past and one for future, with its timeliness paid for by a distinct exchange I made with jberman @jberman:matrix.org

As for if the CCS should host it... I don't see how it's distinct from anything it funds under Seraphis. This work explicitly delineates where it's unproven, and seeks said proofs with an explicit issue tracker. Part of the CCS would be to ensure its security.

3. discussion, what to discuss today?

While it isn't guaranteed to be deployed, as Seraphis effectively is, I don't see a world in which we don't transition from either CLSAG or Grootle to it.

Ok. I have also brought up the same issue about Seraphis for months. Maybe a year. We need security proofs.

Or if not this exact impl, the same underlying theory with the same underlying research which is currently optimal.

Triptych has security proofs published in a peer-reviewed outlet.

I see a world: It's not proven secure.

Proofs are hard

kayabanerve[m]: Ccs is fine

Sure. Part of further efforts on this work is ensuring security. I promise you it's tracked and important to me. I don't believe questioning if the CCS should fund it is appropriate when part of the CCS funding would be to prove the security. If you're unhappy with the timeline on the CT work, believing specific security sections should be done sooner than latter, I'd ask you to call that out on specific proposals. Not

question CCS funding entirely.

kayabanerve[m]: CT historically means Confidential Transactions, maybe a different abbreviation would be better (or just don't abbreviate)

I was asking about jberman's current CCS work, not a future one. Of course, work priority can change in the course of a CCS. But proposed priority changes can be given feedback here

ah, is it curve trees?

Oh i was referring to future kaya ccs'

gingeropolous: yeah

I would love to see a CCS that funds work on security proofs for...anything we have on the table. That includes Seraphis, BP++, and Curve Trees.

BP++ already has a CCS for review of the paper that hasn't been fully published yet

Rucknium[m]: Ah, sorry, missed that context.

There's no security proof in that paper. Can't review what's not there

UkoeHB: Thanks for the reminder

This isn't a theoretical risk. A zero-knowledge protocol was recently discovered to be flawed: zksecurity.xyz/blog/posts/nova-attack

plowsof @plowsof:libera.chat is currently on the hunt to find a suitable party to do security proofs for Seraphis

Rucknium @rucknium:monero.social: Agreed re: Seraphis.

Right now, Sarang, funded by Firo, is working on the VC scheme as their hours allow. That'd include a proof.

Can you type out your acronyms? VC?

*that second part is referring to ensuring the security of curve trees which requires BP(+) be modified with a vector commitment scheme.

Ok

That's good. Recently I've seen carts being put before horses and all problems looking like nails when we all we have is hammers.

what materials would an individual need that was going to embark on security proofs on seraphis?

for Seraphis.

just the papers github.com/UkoeHB/Seraphis

IIRC part of koe's current CCS is to get the Seraphis paper to a place where someone could continue the work into writing security proofs

thanks UkoeHB .

Rucknium[m]: I already did it

Rucknium @rucknium:monero.social: I asked Firo to collaborate, noting specifically the VC scheme and proof, over a month ago.

Just to clarify that as we've had theoretic changes, I have followed up re: security. I didn't do this whole thing and then say we'll get security later.

gingeropolous: there are also coinstudent2048's writeups which may be a useful reference/head start github.com/coinstudent2048/writeups

UkoeHB: Great. What is the next step? I assume sarang would be a good person to write the proofs, if he would be willing, since his work with Firo has some similarities.

Rucknium[m]: like jberman[m] said, plowsof is already looking for suitable parties

ok are there any other topics? otherwise we can wrap it up

the agenda had that 10 block lock thing ....

kayabanerve: Do you think the 10 blocks can be reduced with Curve Trees? The threat model would be different than a decoy-based model when there are deep re-orgs.

10 block lock is not something that should be hyper-optimized. If you reduce it too much, that might open the floodgates to attacks.

Myself and another researcher may look into the privacy issues with Monerujo's PocketChange (and similar application-level ways to deal with 10 block lock).

Rucknium @rucknium:monero.social: Arguably? But it's indirect.

Rucknium[m]: 10 block lock mitigates the case where a reorg invalidates txs unaffiliated with the reorger

With a merkle tree structure, you can choose a root from 10 blocks ago or choose the most recent root.

(If we allow it (

reorgs would be much more impactful if txs used full chain membership proofs, not less impactful

If you choose the most recent root, you're at risk of reorg, and you dox you're spending something from the last ten blocks

BUT your privacy set is all of the last 10 blocks which is decent. That's the one benefit

UkoeHB: AFAIK it's effectively the same.

the 10 lock lock prevents some adversarial inference of the true spend in a decoy model. AFAIK, there isn't really that problem with Curve Trees, except maybe that your wallet is using the most updated merkle tree at X most recent block height

yeah. it might be that for "select membership proofs" (of which current and seraphis are parts) might just need that 10 block lock, but perhaps the new general membership proofs don't need it

You used to reorg if decoys shifted at all. Now you reorg if a tree root no longer exists.

It's probably easier to detect if a TX is incompatible under merkle trees.

kayabanerve[m]: it is worse because a reorg will invalidate all txs referencing a merkle root above the reorg point. With ring sigs, you will only invalidate txs with ring members above the reorg point, which is likely to be some proportion of all reorged txs.

By default, won't all wallets use an updated merkle tree? So your true spend would not be able to be inferred

... Right but don't we heavily weight the most recent TXs? Isn't that likely?

Rucknium[m]: no, 10 block lock is a security measure not a privacy measure

tx invalidation is not the same as revealing the real spend. Different problems IMHO

jberman @jberman:matrix.org: What are the odds a new TX has a ring member from the most recent 20 blocks?

kayabanerve[m]: yes but proportionally, merkle root invalidation is more impactful

Doesn't the algorithm explicitly weight 10-25?

UkoeHB: That's not what you said in the GitHub issue about it

UkoeHB: Marginally, sure.

marginally is all that matters here...

Rucknium[m]: link it...

Also on the margin, any decoys in your chosen ring could be invalidated and weaken your final chosen ring on chain

jberman[m]: if you resubmit

> This weakens those users' ring signatures. To prevent that weakening, the 10-block-lock time is enforced. This way all decoys in a tx input are plausibly the real spend.

AFAIK, no other blockchain is paternalistic with the "tx invalidation" issue. Other blockchains allow users to determine the number of confirmations they accept

Right, so FCMPs solve the privacy issues yet maintain reorg risk.

Rucknium[m]: monero-project/research-lab #104#issuecomment-1186552665

A 51% attack for double spends has invalidated txs. That's the point.

FCMPs.....

kayabanerve: That's my hypothesis

privacy impact is an advantage, security is the original reason

And anything spent within the most recent 10 blocks would definitively reveal it's within the most recent 10 blocks (if anything outside defaults to the 10 block old root)

gingeropolous @gingeropolous:libera.chat: Full chain membership proofs.

But, since it's a FCMP, those 10 blocks still probably exceed 128, right? And it's safe to re submit.

Not to dismiss the reorg risk, to say privacy may be 'resolved'.

yeah i thought the main concern was privacy implications of the re-org, not the re-org itself

kayabanerve: I don't remember offhand but I would be mildly surprised if over 20% of txs have ring members from the last 20 blocks

Regardless of original reasons, once we have FCMPs slated, we may want to re-evaluate privacy and security risks.

Huh. I thought it'd be much higher. Never mind on my "marginally" then.

it's still marginal, the margin is just quite large

Yes. What is the benefit to an adversary of invalidating txs that they don't have the spend keys for (i.e. cannot perform a double-spend)? Just vandalism?

DoS, yeah.

I will note Zcash didn't implement a lock AFAIK and seems to do fine. I have no idea their root selection policy though (10 blocks back, 5 blocks, most recent...)

lack of an attack is not proof of security

Agreed. It is potential evidence on the financial incentive to perform such DoSs though.

Curve Trees, if implemented, would have much less (if any?) privacy issues with a PocketChange implementation to get around the 10 block lock, so it has that to its advantage.

If you can bring down a cryptocurrency with just filling blocks with large transactions, you don't anything sophisticated ...

*you don't need

so FCMP could solve the 10 block lock issue either directly or indirectly ... ?

because I don't know if we'll ever have enough data to convince ourselves to lower it while using ringsigs (select membership proof). is there a better name for that, or just call it ring sigs?

Leaving a vector open to make Monero unusable via consistent 1-2 block reorgs wouldn't be great (for wallets that select from the most recent 1-2 blocks)

oh its only sending some of my message to matrix

so FCMP could solve the 10 block lock issue either directly or indirectly ... ?

Writing up the results from applying the Double Spend Races formula hasn't been a priority (doesn't seem time-sensitive), so I haven't done it. But what I've seen is that if the adversary has enough hashpower to re-org 5 blocks with non-negligible probability, then they have close to enough hashpower to re-org 10 blocks

imo the only real solution to 10-block-lock is allowing no-membership-proof inputs, but that is a contentious idea for sure

Rucknium @rucknium:monero.social: I'm hearing we should raise to 100? /s

koe throwing a rabid chicken in there at the end. (I dont know what no-membership-proofs would imply)

ok that's the end of the hour, thanks for attending everyone :p

FCMPs solves the privacy issues around allowing new output's to be used. It also solves the privacy on pocket change. It does nothing for security against reotgs. That's the summary.

No privacy on spent output @ruckUkoeHB

* Rucknium @rucknium:monero.social:

No idea how my phone butchered that so much, sorry

gingeropolous @gingeropolous:libera.chat: and PocketChange doesn't fully solve the 10 block lock issue 1) when on boarding would still have to wait 10 blocks, and 2) you have to have enough "pocket change" leftover to make another follow-up tx

"Mythical L2" is also another avenue :)

<Rucknium[m]> "Curve Trees, if implemented..." <- Can you share the paper?

For Pocket change

PC just refers to creating a 16-out TX.

It sucks for privacy as it ends up merging back :/

ghostway: anhdres.medium.com/monerujos-pocket…it-is-and-how-it-works-8e1ea1f7489e

Thanks!

<kayabanerve[m]> "PC just refers to creating a 16..." <- pocketchange is 10-out

*many-output TX

its not 16

*many-output

cool

It's not 16 in Monerujo. ACK. Thanks for the heads up :)

whats the "privacy preserving" way to do pocketchange?

if it exists

never recombine your change

so the initial split outputs still retain privacy?

sound like the wallet has to do a lot of extra work behind the scenes to make sure it doesnt fuck up

not sure if related but might be an issue in near future: matrix.org/blog/2023/07/deportalling-libera-chat

should not be an issue, we have a proper room

it might be an issue for some users who use matrix as an irc bouncer to connect to libera.chat directly, but it should not be an issue for monero channels because we have plumbed rooms that remain unchanged