03:02:51 <m-relay> <d​iego:cypherstack.com> https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/443
03:02:52 <m-relay> <d​iego:cypherstack.com> put this up btw
12:16:28 <dEBRUYNE> kayabanerve: Does it suit for you to have a separate proposal for the GBP review?
12:16:46 <dEBRUYNE> I can imagine having the proposal diego just put forward plus your own FMCP proposal, it will probably speed up things as well
17:01:17 <m-relay> <d​iego:cypherstack.com> Are we trying to wait until next MRL meeting to discuss the proposal?
17:01:30 <m-relay> <d​iego:cypherstack.com> Or can we get some comments and trying to get it merged and funded so we can get started?
17:02:23 <m-relay> <k​ayabanerve:matrix.org> I explicitly asked Diego if they wanted to be part of my proposal or on their own. They chose their own. I have no alternative to propose and support CS doing the review. I have yet to review/comment on that CCS specifically.
17:11:18 <m-relay> <r​ucknium:monero.social> Diego Salazar: Shouldn't the CCS title be "Generalized Bulletproofs Security Proofs" instead of "...Review"? AFAIK, we are not at the review stage yet. Second, "we've already done a more thorough documentation of generalized Bulletproofs". Can you post a link to the documentation? We need to know what exactly the security proof is supposed to prove.
17:11:23 <m-relay> <d​iego:cypherstack.com> Yes, we prefer to have our own proposal and handle our things separately
17:11:58 <m-relay> <d​iego:cypherstack.com> Sure, I'll change the title. You're right Rucknium
17:14:07 <m-relay> <r​ucknium:monero.social> At the last MRL meeting I saw general support for the CS's attempt to write a security proof for GBP. I personally don't see a good reason to wait until Wednesday again for more input, but there are many people involved in the CCS process of course.
17:14:55 <m-relay> <r​ucknium:monero.social> I think you'd want to change the .md file name, too, since it will have the .md file name as the URL once it goes to funding.
17:17:06 <nioCat> I asked in -community if there will be a meeting tomorrow to move this proposal forward quickly
17:17:19 <m-relay> <k​ayabanerve:matrix.org> I support that CCS proposal.
17:24:38 <tobtoht_> Support for expedited merge
17:29:05 <m-relay> <d​iego:cypherstack.com> Changes made Rucknium
17:37:47 <tevador> Btw, locked outputs will be a major headache with FCMP. I think we should also renew the effort to deprecate them.
17:39:53 <m-relay> <r​ucknium:monero.social> Diego Salazar: Thanks. Could you add a link to the document that explains what GBP are? Does that document exist?
17:41:05 <m-relay> <d​iego:cypherstack.com> Yes. Aaron would know where it is but he's off today. Will do tomorrow or Monday. I understand this will delay merge but I won't ask him to come in since he's taking a bit of time off.
17:42:03 <m-relay> <a​aron:cypherstack.com> kayabanerve has it as well
17:42:33 <m-relay> <r​ucknium:monero.social> tevador: Are the headaches just with outputs with custom unlock time or does that include coinbase outputs' standard 60 block lock too? I agree that the ability to lock new outputs with custom unlock time should be removed soon, maybe in the next hard fork.
17:42:43 <m-relay> <k​ayabanerve:matrix.org> tevador: Yes and no. You'd delay addition to the tree. Yes, it's painful. It's not DLSAG painful.
17:43:14 <m-relay> <r​brunner7:monero.social> tevador: Just a few hours ago I complained a bit about the lock removal in the dev channel :) We really, really should not fail a second time to finally remove them.
17:44:55 <m-relay> <a​aron:cypherstack.com> kayabanerve: any objections to CS uploading that document to the MR?
17:44:57 <m-relay> <r​brunner7:monero.social> The PR is ready since more than 2 months, our MRL meeting discussion is almost 2 months already, and I reviewed the code.
17:45:19 <m-relay> <k​ayabanerve:matrix.org> Nope, if it's the version with the corrections made.
17:45:24 <m-relay> <a​aron:cypherstack.com> It is
17:45:43 <m-relay> <a​aron:cypherstack.com> Rucknium: it's not written for broad distribution
17:45:58 <m-relay> <k​ayabanerve:matrix.org> I am perfectly happy removing timelocks. I'm noting we can tolerably do it with FCMPs IMO.
17:45:59 <m-relay> <a​aron:cypherstack.com> Intended for internal use for writing an implementation
17:46:13 <m-relay> <a​aron:cypherstack.com> But not like we can't post it anyway
17:46:28 <m-relay> <a​aron:cypherstack.com> It's just not particularly formal or anything
17:46:29 <m-relay> <k​ayabanerve:matrix.org> Upon a TX being mined on the blockchain, we'd schedule it for a block to be added to the tree on (default 10 blocks). On custom timelock...
17:46:40 <m-relay> <k​ayabanerve:matrix.org> (though that only neatly works for *block*-based timelocks)
17:46:52 <m-relay> <k​ayabanerve:matrix.org> Tbc, yes, we should just remove them entirely.
17:47:20 <m-relay> <r​ucknium:monero.social> That sounds fine to me. Just indicate it is rough when posting it. Thanks :)
17:48:15 <m-relay> <a​aron:cypherstack.com> Also want to make it clear that we didn't invent the technique
17:48:26 <m-relay> <a​aron:cypherstack.com> It was just incompletely specified
17:49:24 <m-relay> <r​brunner7:monero.social> The PR in question: https://github.com/monero-project/monero/pull/9151
17:50:47 <m-relay> <r​ucknium:monero.social> rbrunner7: Thanks! Next hard fork we would need a different PR that prohibits them by consensus rules, right?
17:52:39 <m-relay> <r​ucknium:monero.social> Or, it seems since the draft Seraphis implementation does not support custom time locks, that would prevent them when only Seraphis txs are permitted on the blockchain after a hard fork.
17:53:12 <m-relay> <a​aron:cypherstack.com> OK, got the document to Diego Salazar just now
17:53:28 <m-relay> <r​ucknium:monero.social> Thank you!
17:55:03 <m-relay> <a​aron:cypherstack.com> Many thanks to kayabanerve for his assistance in catching a few errors in an earlier draft of it
17:55:36 <m-relay> <a​aron:cypherstack.com> As far as we know it's a correct documentation of the protocol as implemented by the preprint author, but nobody should be relying on it at this point or assuming it's secure
17:55:56 <m-relay> <d​iego:cypherstack.com> Oh goodness. This document is so good. Solves all of the problems.
17:56:05 <m-relay> <a​aron:cypherstack.com> I bet it's super secure, eh
17:56:20 <m-relay> <a​aron:cypherstack.com> It's just brimming with computational witness-extended emulation
17:56:36 <m-relay> <d​iego:cypherstack.com> I need to lay down after reading it. Incredible.
17:56:46 <m-relay> <a​aron:cypherstack.com> It's a real page turner
17:56:47 <m-relay> <d​iego:cypherstack.com> But fr I'll get it on the MR in an hour or so.
17:56:54 <m-relay> <a​aron:cypherstack.com> One turn of the page, in fact. Then it's done
17:59:14 <m-relay> <a​aron:cypherstack.com> OK, I'm out again. Ping me with anything urgent please!
18:10:53 <tevador> Yeah, time-based locks are the worst. Adding a block to the chain can actually relock a previously unlocked output, so you'd have to remove it from the tree.
18:56:20 <m-relay> <r​brunner7:monero.social> Rucknium: I think so regarding consensus rule. As soon as all daemons can agree that transactions with time locks are not valid, as it is the case after a hardfork of course, they can refuse to add a block to the blockchain that has one of those in it. But just to make it clear: We could bring *this* PR into service with the very next point release if we wanted, and it would becom<clipped messag
18:56:20 <m-relay> <r​brunner7:monero.social> e progressively more difficult to get a tx with a time lock into a block, thus making the danger for tx receivers smaller.
20:06:24 <m-relay> <k​ayabanerve:matrix.org> The FCMP+SA+L proposal *may* give outgoing view keys FYI. Output keys are currently `xG` where the key image is `x hash_to_point(xG)`. We don't check output keys are actually over `G` however at time of creation (we do inherently at time of spend right now).
20:06:24 <m-relay> <k​ayabanerve:matrix.org> This FCMP+SA+L proposal outputs a key `xG + rZ`, for some random generator `Z`, and requires the signer know `x` and `r`. The intent was for `r` to be the randomness used within the circuit. If the re-randomized key was already `xG + aZ`, it'd be re-blinded by `r` to `xG + (a+r)Z`. Then the Generalized Schnorr Protocol we use as a signature would be able to open it with `x, (a+r)`<clipped message
20:06:25 <m-relay> <k​ayabanerve:matrix.org> , before proving the key image as `x hash_to_point(K)` (where `K` is `xG + aZ`).
20:06:26 <m-relay> <k​ayabanerve:matrix.org> This means that one cannot spend such output keys without knowing the `a` component, which should allow publishing the `x` component, which should allow anyone with`x` to calculate the key images for outputs? I'd ask someone else to check my algebra/thought process there.
20:08:16 <m-relay> <k​ayabanerve:matrix.org> I believe this follows though. If someone did so modify their public spend key (from `sG` to `sG + aZ`), it'd be indistinguishable to any other public spend key and usable within the existing addresses. This means we'd have OVKs for *newly generated addresses* without requiring new addresses/invalidating old ones? And you couldn't fingerprint if someone is on new wallet software?
20:09:05 <m-relay> <k​ayabanerve:matrix.org> I don't believe this is trivially insecure. I don't want to claim we're anywhere near a formal security proof.
20:10:59 <m-relay> <k​ayabanerve:matrix.org> *This does re-define the key image from `dlog_G(K) hash_to_point(K)` to `term_G(K) hash_to_point(K)`. That needs to be proven secure under the current proposal regardless, as it does that naturally.
20:12:07 <m-relay> <k​ayabanerve:matrix.org> If that re-definition is insecure, the current proposed circuit needs further specification which... should be trivial? It'd be outputting not just `xG + rZ`, yet `xG + rY`, and requiring the signer open both. That ensures the original key has a known dlog over G.
20:13:57 <m-relay> <k​ayabanerve:matrix.org> That also truly is trivial. The expensive parts of the proofs are the set membership, and proving discrete logs are valid bitstrings. Since this wouldn't have its membership proven (the key it reblinds is what has its membership proven) and since the discrete log was already proven to be a valid bitstring, this'd be ~10 gates. I think we have a few hundred to spare right now due t<clipped message
20:13:58 <m-relay> <k​ayabanerve:matrix.org> o how padding rules panned out.
20:16:14 <tevador> Let's not overdo it. Seraphis already introduces a bunch of new keys. Pre-seraphis FCMPs should have the narrowest possible scope to maximize the chance of success and speedy deployment.
20:19:07 <m-relay> <s​gp_:monero.social> Imo, we really only have "one shot" with new address types, so keep that in mind
20:25:55 <m-relay> <k​ayabanerve:matrix.org> Placed a write-up on the gist, will also review forward secrecy commentary in a few.
20:30:22 <plowsof> luigis availability for merges is next week probably https://libera.monerologs.net/monero-community/20240405#c359283
20:33:59 <plowsof> next MRL meeting should be enough time to set the ccs in stone / vote?
21:18:37 <m-relay> <a​rticmine:monero.social> If I understand kayabanerve 's proposal correctly OVKs for newly generated addresses are a by product of pre Seraphis FCMP and do not create a new incompatible address type. 
21:18:37 <m-relay> <a​rticmine:monero.social> I would not dismiss this off hand
21:22:50 <tevador> Addresses would stay compatible, but I would not call it a byproduct. It would require nontrivial changes that are not essential for FCMPs.
23:17:09 <m-relay> <d​iego:cypherstack.com> Rucknium: The PDF has been attached to the MR