16:12:53 <UkoeHB> Meeting .75hr
17:00:37 <UkoeHB> meeting time https://github.com/monero-project/meta/issues/859
17:00:37 <UkoeHB> 1. greetings
17:00:37 <UkoeHB> hello
17:01:00 <gingeropolous> hi
17:01:02 <rbrunner> Hello
17:01:45 <jberman[m]> Hello
17:01:51 <Rucknium[m]> Hi
17:01:56 <vtnerd>  hi
17:04:26 <UkoeHB> 2. discussion, what is everyone working on?
17:05:06 <kayabanerve[m]> 👋
17:05:13 <vtnerd> rmq support for lws (completed), and noise protocol for daemon p2p
17:05:57 <Rucknium[m]> 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.
17:06:52 <Rucknium[m]> 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: https://sourceforge.net/p/wikindx/discussion/888681/thread/1fcdd20630/
17:06:53 <kayabanerve[m]> I jotted down some theoretical improvements to FCMPs, but nothing much on my end.
17:07:03 <gingeropolous> 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.
17:07:05 <UkoeHB> 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.
17:07:17 <jberman[m]> 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
17:07:24 <Rucknium[m]> I am working on an API to integrate the MAGIC Monero Fund's fundraisers (monerofund.org) into Feather Wallet like CCS fundraisers are.
17:08:16 <kayabanerve[m]> gingeropolous @gingeropolous:libera.chat: How much storage is available?
17:08:33 <gingeropolous> 14TB SSD, 74TB HDD
17:08:57 <vtnerd> gotta run, sadly
17:09:03 <Rucknium[m]> 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?
17:09:11 <UkoeHB> thanks for the update vtnerd 
17:09:12 <kayabanerve[m]> I may ask to generate and store a couple hundred GB data set in the future...
17:09:58 <kayabanerve[m]> Rucknium @rucknium:monero.social: The Serai "labor exchange" only went up to a post I made months ago on GH.
17:11:23 <kayabanerve[m]> 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
17:12:29 <kayabanerve[m]> 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.
17:12:31 <UkoeHB> 3. discussion, what to discuss today?
17:13:08 <kayabanerve[m]> 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.
17:13:41 <Rucknium[m]> Ok. I have also brought up the same issue about Seraphis for months. Maybe a year. We need security proofs.
17:13:56 <kayabanerve[m]> Or if not this exact impl, the same underlying theory with the same underlying research which is currently optimal.
17:14:03 <Rucknium[m]> Triptych has security proofs published in a peer-reviewed outlet.
17:14:58 <Rucknium[m]> I see a world: It's not proven secure.
17:15:10 <Rucknium[m]> Proofs are hard
17:15:30 <ofrnxmr[m]> kayabanerve[m]: Ccs is fine
17:15:42 <kayabanerve[m]> 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
17:15:42 <kayabanerve[m]> question CCS funding entirely.
17:16:54 <UkoeHB> kayabanerve[m]: CT historically means Confidential Transactions, maybe a different abbreviation would be better (or just don't abbreviate)
17:17:02 <Rucknium[m]> 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
17:17:31 <gingeropolous> ah, is it curve trees?
17:17:36 <ofrnxmr[m]> Oh i was referring to future kaya ccs'
17:17:51 <UkoeHB> gingeropolous: yeah
17:17:58 <Rucknium[m]> 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.
17:18:40 <UkoeHB> BP++ already has a CCS for review of the paper that hasn't been fully published yet
17:19:15 <kayabanerve[m]> Rucknium[m]: Ah, sorry, missed that context.
17:19:19 <Rucknium[m]> There's no security proof in that paper. Can't review what's not there
17:19:29 <kayabanerve[m]> UkoeHB: Thanks for the reminder
17:19:58 <Rucknium[m]> This isn't a theoretical risk. A zero-knowledge protocol was recently discovered to be flawed: https://www.zksecurity.xyz/blog/posts/nova-attack/
17:20:03 <jberman[m]> plowsof @plowsof:libera.chat is currently on the hunt to find a suitable party to do security proofs for Seraphis
17:20:28 <kayabanerve[m]> Rucknium @rucknium:monero.social: Agreed re: Seraphis.
17:20:28 <kayabanerve[m]> Right now, Sarang, funded by Firo, is working on the VC scheme as their hours allow. That'd include a proof.
17:21:26 <Rucknium[m]> Can you type out your acronyms? VC?
17:21:26 <kayabanerve[m]> *that second part is referring to ensuring the security of curve trees which requires BP(+) be modified with a vector commitment scheme.
17:21:34 <Rucknium[m]> Ok
17:23:11 <Rucknium[m]> 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.
17:24:33 <gingeropolous> what materials would an individual need that was going to embark on security proofs on seraphis?
17:25:08 <gingeropolous> for Seraphis. 
17:25:17 <UkoeHB> just the papers https://github.com/UkoeHB/Seraphis
17:25:31 <Rucknium[m]> 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
17:25:44 <gingeropolous> thanks UkoeHB .
17:26:03 <UkoeHB> Rucknium[m]: I already did it
17:26:04 <kayabanerve[m]> Rucknium @rucknium:monero.social: I asked Firo to collaborate, noting specifically the VC scheme and proof, over a month ago. 
17:26:43 <kayabanerve[m]> 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.
17:27:02 <UkoeHB> gingeropolous: there are also coinstudent2048's writeups which may be a useful reference/head start https://github.com/coinstudent2048/writeups
17:27:06 <Rucknium[m]> 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.
17:27:29 <UkoeHB> Rucknium[m]: like jberman[m] said, plowsof is already looking for suitable parties
17:30:58 <UkoeHB> ok are there any other topics? otherwise we can wrap it up
17:31:14 <gingeropolous> the agenda had that 10 block lock thing ....
17:32:39 <Rucknium[m]> 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.
17:32:42 <UkoeHB> 10 block lock is not something that should be hyper-optimized. If you reduce it too much, that might open the floodgates to attacks.
17:34:09 <Rucknium[m]> 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).
17:34:28 <kayabanerve[m]> Rucknium @rucknium:monero.social: Arguably? But it's indirect.
17:34:29 <UkoeHB> Rucknium[m]: 10 block lock mitigates the case where a reorg invalidates txs unaffiliated with the reorger
17:34:52 <kayabanerve[m]> With a merkle tree structure, you can choose a root from 10 blocks ago or choose the most recent root.
17:34:56 <kayabanerve[m]> (If we allow it (
17:35:22 <UkoeHB> reorgs would be much more impactful if txs used full chain membership proofs, not less impactful
17:35:28 <kayabanerve[m]> 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
17:35:56 <kayabanerve[m]> BUT your privacy set is all of the last 10 blocks which is decent. That's the one benefit
17:36:09 <kayabanerve[m]> UkoeHB: AFAIK it's effectively the same.
17:36:10 <Rucknium[m]> 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
17:36:11 <gingeropolous> 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
17:36:29 <kayabanerve[m]> You used to reorg if decoys shifted at all. Now you reorg if a tree root no longer exists.
17:36:44 <kayabanerve[m]> It's probably easier to detect if a TX is incompatible under merkle trees.
17:37:06 <UkoeHB> 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.
17:37:34 <Rucknium[m]> By default, won't all wallets use an updated merkle tree? So your true spend would not be able to be inferred
17:37:39 <kayabanerve[m]> ... Right but don't we heavily weight the most recent TXs? Isn't that likely?
17:37:53 <UkoeHB> Rucknium[m]: no, 10 block lock is a security measure not a privacy measure
17:38:00 <Rucknium[m]> tx invalidation is not the same as revealing the real spend. Different problems IMHO
17:38:06 <kayabanerve[m]> jberman @jberman:matrix.org: What are the odds a new TX has a ring member from the most recent 20 blocks?
17:38:17 <UkoeHB> kayabanerve[m]: yes but proportionally, merkle root invalidation is more impactful
17:38:19 <kayabanerve[m]> Doesn't the algorithm explicitly weight 10-25?
17:38:23 <Rucknium[m]> UkoeHB: That's not what you said in the GitHub issue about it
17:38:49 <kayabanerve[m]> UkoeHB: Marginally, sure.
17:39:05 <UkoeHB> marginally is all that matters here...
17:39:14 <UkoeHB> Rucknium[m]: link it...
17:39:58 <jberman[m]> Also on the margin, any decoys in your chosen ring could be invalidated and weaken your final chosen ring on chain
17:40:28 <Rucknium[m]> https://github.com/monero-project/research-lab/issues/95
17:40:31 <UkoeHB> jberman[m]: if you resubmit
17:40:57 <Rucknium[m]> > 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.
17:41:39 <Rucknium[m]> AFAIK, no other blockchain is paternalistic with the "tx invalidation" issue. Other blockchains allow users to determine the number of confirmations they accept
17:42:19 <kayabanerve[m]> Right, so FCMPs solve the privacy issues yet maintain reorg risk.
17:42:30 <UkoeHB> Rucknium[m]: https://github.com/monero-project/research-lab/issues/104#issuecomment-1186552665
17:42:34 <Rucknium[m]> A 51% attack for double spends has invalidated txs. That's the point.
17:42:43 <gingeropolous> FCMPs.....
17:42:50 <Rucknium[m]> kayabanerve: That's my hypothesis
17:42:55 <UkoeHB> privacy impact is an advantage, security is the original reason
17:43:06 <kayabanerve[m]> 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)
17:43:24 <kayabanerve[m]> gingeropolous @gingeropolous:libera.chat: Full chain membership proofs.
17:44:01 <kayabanerve[m]> But, since it's a FCMP, those 10 blocks still probably exceed 128, right? And it's safe to re submit.
17:44:21 <kayabanerve[m]> Not to dismiss the reorg risk, to say privacy may be 'resolved'.
17:45:00 <gingeropolous> yeah i thought the main concern was privacy implications of the re-org, not the re-org itself
17:45:35 <jberman[m]> 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
17:45:53 <kayabanerve[m]> Regardless of original reasons, once we have FCMPs slated, we may want to re-evaluate privacy and security risks.
17:46:24 <kayabanerve[m]> Huh. I thought it'd be much higher. Never mind on my "marginally" then.
17:47:26 <UkoeHB> it's still marginal, the margin is just quite large
17:49:39 <Rucknium[m]> 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?
17:50:08 <kayabanerve[m]> DoS, yeah.
17:50:54 <kayabanerve[m]> 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...)
17:51:56 <UkoeHB> lack of an attack is not proof of security
17:53:30 <kayabanerve[m]> Agreed. It is potential evidence on the financial incentive to perform such DoSs though.
17:54:05 <Rucknium[m]> 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.
17:54:15 <rbrunner> If you can bring down a cryptocurrency with just filling blocks with large transactions, you don't anything sophisticated ...
17:54:23 <rbrunner> *you don't need
17:56:10 <gingeropolous> so FCMP could solve the 10 block lock issue either directly or indirectly ... ?
17:57:00 <gingeropolous> 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?
17:57:11 <jberman[m]> 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)
17:57:18 <gingeropolous> oh its only sending some of my message to matrix
17:57:26 <gingeropolous> so FCMP could solve the 10 block lock issue either directly or indirectly ... ?
17:58:36 <Rucknium[m]> 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
17:59:27 <UkoeHB> imo the only real solution to 10-block-lock is allowing no-membership-proof inputs, but that is a contentious idea for sure
17:59:54 <kayabanerve[m]> Rucknium @rucknium:monero.social: I'm hearing we should raise to 100? /s
18:00:24 <Rucknium[m]> koe throwing a rabid chicken in there at the end. (I dont know what no-membership-proofs would imply)
18:00:43 <UkoeHB> ok that's the end of the hour, thanks for attending everyone :p
18:00:43 <kayabanerve[m]> 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.
18:01:06 <kayabanerve[m]> No privacy on spent output @ruckUkoeHB 
18:01:15 <kayabanerve[m]> * Rucknium @rucknium:monero.social: 
18:01:29 <kayabanerve[m]> No idea how my phone butchered that so much, sorry
18:03:16 <jberman[m]> 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
18:04:22 <jberman[m]> "Mythical L2" is also another avenue :)
18:32:41 <ghostway[m]> <Rucknium[m]> "Curve Trees, if implemented..." <- Can you share the paper? 
18:33:07 <ghostway[m]> For Pocket change
18:52:45 <kayabanerve[m]> PC just refers to creating a 16-out TX.
18:53:13 <kayabanerve[m]> It sucks for privacy as it ends up merging back :/
19:06:02 <Rucknium[m]> ghostway: https://anhdres.medium.com/monerujos-pocketchange-what-it-is-and-how-it-works-8e1ea1f7489e
19:13:49 <ghostway[m]> Thanks!
21:44:20 <r4v3r23[m]1> <kayabanerve[m]> "PC just refers to creating a 16..." <- pocketchange is 10-out
21:44:46 <kayabanerve[m]> *many-output TX
21:44:54 <r4v3r23[m]1> its not 16
21:45:00 <kayabanerve[m]> *many-output
21:45:05 <r4v3r23[m]1> cool
21:45:11 <kayabanerve[m]> It's not 16 in Monerujo. ACK. Thanks for the heads up :)
21:45:39 <r4v3r23[m]1> whats the "privacy preserving" way to do pocketchange?
21:45:44 <r4v3r23[m]1> if it exists
21:47:40 <gingeropolous> never recombine your change 
21:49:05 <r4v3r23[m]1> so the initial split outputs still retain privacy?
21:50:13 <r4v3r23[m]1> sound like the wallet has to do a lot of extra work behind the scenes to make sure it doesnt fuck up
22:03:20 <kinghat[m]> not sure if related but might be an issue in near future: https://matrix.org/blog/2023/07/deportalling-libera-chat/
22:35:23 <selsta> should not be an issue, we have a proper room
22:37:12 <selsta> 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