11:10:13 <ErCiccione[m]> Hey MRL folks, beside the change of POW, what needs to be changed on this page: https://web.getmonero.org/technical-specs/ ?
11:32:35 <sarang> The maximum block size isn't strictly twice the 100-median with ArticMine's updated method
11:33:02 <sarang> Might be easier just to state that it's dynamic, which it is (subject to a particular non-static cap)
11:33:52 <sarang> I don't really like the use of "ring confidential transactions" to refer to the amount-hiding only... RingCT (informally) describes the use of MLSAG-with-Pedersen-commitments
11:35:01 <sarang> It could be changed to something like "Pedersen commitments, Bulletproof range proofs" if desired; not sure if there are other preferred wordings other people have
11:56:54 <ErCiccione[m]> Thanks sarang. I'll wait for more comments. If there aren't any, i will just add the changes you suggested
11:59:54 <sarang> Would it be useful to link to actual technical details from that page? It's super sparse now... not really much for "technical specs"
12:00:21 <sarang> Or, even crazier... why have that page at all? What is its actual value to the reader?
12:00:43 <sarang> When I see similar pages for other projects, I find them generally non-useful
12:01:30 <ErCiccione[m]> i'm adding links to the moneropedia voices for ringct, Ring signatures and stealth addresses. We could add more moneropedia voices, so to have more references for technical terms
12:01:52 <ErCiccione[m]> why have that page at all? <- yeah it's not super useful, just a quick summary of the main technologies we use
12:01:53 <sarang> Are those up to date?
12:02:01 <ErCiccione[m]> i guess we could merge that page with some other docs if needed
12:02:03 <sarang> Those = whatever moneropedia things you are referencing
12:02:28 <sarang> Don't other pages list the main tech, with narrative and pictures?
12:03:04 <sarang> TBH the project doesn't really have technical specs in the correct sense
12:03:20 <sarang> It has the code, and it has resources like Zero to Monero that describe (some version of) the protocol
12:07:15 <ErCiccione[m]> Those Moneropedia voices are very generic, i don't think they are outdated, but they could definitely use some more descriptive text (i haven't deeply checked them tho). You have good points btw, let's see what the people in #monero-site think about that page
12:08:37 <sarang> Yeah, don't make a decision purely based on my ranting =p
12:09:48 <koe> Is it possible to leverage the fact amounts are only 64 bits to do implicit range proofs instead of explicit? For example, using a 64-bit order elliptic curve.
12:11:06 <koe> The encrypted amount itself is already only 8byted.
12:12:00 <sarang> You could still overflow
12:12:39 <sarang> 1 - 1 == 0, and -1 == still probably larger than any actual transaction amount
12:13:51 <koe> Hmm true
12:13:57 <sarang> Also, a 64-bit curve would be a terrible idea :D
12:14:14 <sarang> (if you mean a useful curve group of order 2^64)
12:14:49 <koe> Just an example lol would have to be a different real scheme
12:14:57 <sarang> In theory you could restrict amount range proofs below 64 bits, but in practice you save no space with Bulletproofs due to the power-of-2 requirements
12:15:13 <sarang> So it's either 32 bits or 64 bits (or higher)
12:16:08 <sarang> Funny that there was a similar conversation on this in bitcoin-wizards yesterday
12:20:26 <sarang> Speaking of curve group order, I was updating some curve test libraries yesterday and was once again amazed that curve448 targets a 224-bit security level (as opposed to 128-bit security with curve25519)
12:23:57 <koe> um! what about just proving the last 192 bits sum to zero?!
12:26:05 <sarang> Range proofs are small and fast now
13:22:37 <koe> Thank god for the division of labor
13:51:20 <sarang> ?
13:54:45 <koe> was thinking about other ways to do a range proof, and realized it's better to focus on things I'm good at '=D
22:14:48 <sarang> From vtnerd: https://github.com/monero-project/supercop/pull/3
22:15:19 <vtnerd> yeah good call posting here, reviewers for that are going to be tough
22:20:11 <vtnerd> and unlike other projects that attempted the same, this _should_ keep arbitrary ed25519 scalarmult constant time
22:20:11 <vtnerd> which would protect the viewkey under certain circumstances
22:21:42 <sarang> You mean non-basepoint?
22:22:54 <vtnerd> yes, these libraries don't have existing support for that
22:23:02 <vtnerd> so it was either: (1) do it obvious way without constant-time, (2) do 7-field inversions when generating a table, or (3) add support for `z` in the ASM. Went with (3) which might be a rough review
22:23:38 <vtnerd>  I didn't touch original ASM in the tree, just copied it and added support for the extra value in the group element
22:23:52 <sarang> Do you have a time comparison for the extra inversions? (Still reading PR in mobile; sorry if you answered this there)
22:24:12 <sarang> An estimate, that is
22:24:26 <vtnerd> in fact I couldn't touch original, or the pre-generated tables for the basepoint no longer work
22:24:47 <vtnerd> crap, I did at one point I can do it again probably
22:26:58 <sarang> Will you be around for the Wednesday meeting, in case anyone needs to discuss?
22:27:09 <vtnerd> sure
22:27:10 <sarang> 18:00 UTC
22:27:24 <selsta> great work vtnerd
22:27:47 <sarang> Yeah, great to see this work revived from the old PR
22:28:23 <vtnerd> anonimal's suggestion to move to a separate repo may have turned out better than I thought
22:28:31 <sarang> How so?
22:28:43 <vtnerd> I re-wrote all of the cmake so that it could be installed as a separate library on your system OR included in your source tree
22:29:45 <vtnerd> I wrote it specifically  with openmonero/monero-light-wallet-server in mind - they potentially wouldn't need to "pull" in stuff like they are in (but its a ways off from that)
22:30:30 <vtnerd> "pull in" meaning reaching inside of the monero source tree that isn't designed to be exported to other projects really
22:30:57 <sarang> Right
22:31:31 <sarang> I'm excited to play around with it this week
22:32:39 <selsta> sarang: Do you have push access to the research-lab repo?
22:33:05 <sarang> No, but suraeNoether and I considered doing so and decided against it
22:33:37 <selsta> We are thinking about converting monero-project to an organization.
22:33:54 <sarang> Too many projects all in progress at the same time meant things get hectic and having a shared master branch for them got messy
22:33:59 <vtnerd> its not?
22:34:26 <sarang> My skunkworks repo has project-specific branches currently
22:34:48 <sarang> I don't love it as a solution (for visibility) but it helps IMO
22:35:03 <selsta> It’s not currently. Moving to an org would allow for more granular permissions.
22:38:05 <selsta> I think it would be nice if the research-lab would be up to date. Currently information seems to be spread across different repos.
22:38:18 <selsta> It seems like fluffy doing merges was one of the reasons it stopped getting updated.
22:38:47 <sarang> I don't like the idea of a single research repo
22:39:03 <sarang> General research isn't a single project that has regular and consistent checkpoints
22:39:41 <sarang> If anything we could do separate repos per research topic / project, but that'd be a lot for me and annoying for forkers
22:40:06 <sarang> I don't know an optimal way to present it all
22:40:42 <selsta> I don’t mean that all the research should be done in a single repo.
22:40:53 <selsta> But currently the repo seems not maintained, apart from some issues.
22:40:58 <sarang> It is not
22:41:16 <sarang> I have a skunkworks repo that contains almost all of my research projects
22:41:26 <sarang> suraeNoether has a separate one of his own
22:41:49 <sarang> My fork of research-lab has not been used in quite some time
22:42:37 <selsta> Probably best to define the scope of the repo (e.g. finished research papers, maybe chat logs, ...) and then keep it maintained.
22:42:52 <sarang> We did discuss using a separate repo for finished papers
22:43:05 <sarang> Since those do have definite checkpoints and finished states
22:43:14 <sarang> And are much more collaborative
22:43:20 <sarang> I'm very open to this idea
22:44:00 <sarang> As long as those are kept strictly up to date with things like IACR versions to avoid inconsistent versioning
22:44:40 <sarang> The readme could contain links to individual researchers' repos for visibility, if that's helpful
22:45:25 <sarang> The existing research-lab repo could be clearly marked as essentially archival
22:45:50 <selsta> I think having push rights would help with organization.
22:45:57 <sarang> For sure
22:46:16 <selsta> Having to wait for a maintainer to merge things is just frustrating if you want to keep things up to date :P
22:46:25 <sarang> Yeah
22:46:46 <selsta> I hope moving to an organization will help with that.
22:46:58 <sarang> Is this something that will definitely happen?
22:47:12 <sarang> Or are there hidden gotchas in the workflow?
22:48:05 <selsta> I suggested it to fluffy and he said he will talk to core team, but it seems like he is in favor of doing it.
22:49:02 <ErCiccione[m]> selsta: just catching up, so i didn't read the log, but if we stay on gitlab, we definitely need to convert monero-project into an organization. The current structure doesn't make sense.
22:49:35 <ErCiccione[m]> That was one of the improvements i wanted to have on gitlab: an organization with proper access control
22:49:36 <selsta> agree, it seems like it will heppen
22:49:45 <selsta> happen*
22:51:44 <ErCiccione[m]> yeah, i will comment on the meta issue as soon as i have time.
22:52:00 <ErCiccione[m]> But i guess this is a bit OT here
23:34:21 <vtnerd> sarang : a quick analysis shows a ~56% slowdown for generate_key_derivation on my ryzen 3 3900x. amoritized over a standard 2-output tx means a ~31~ slowdown
23:35:04 <vtnerd> I might be able to bring that down if I can convert from the internal p1p1 format to niels format directly (without going to p3 first), but the code with batched inversions has the limitation too
23:35:25 <vtnerd> the issue is that it has to an inversion + 3 field multiplications 7 times
23:35:35 <vtnerd> *inversion -> field inversion
23:37:04 <vtnerd> I have code that Im not pushing _yet_ that generates the table once and re-uses it, in that scenario it gets amoritzed further, but only light-wallet-server and openmonero would make use of that (not useful for wallet2)
23:37:19 <vtnerd> and yes I know I can't spell
23:43:04 <vtnerd> *the issue is that -> the issue with using the choose_t assembly that works only with "niels" (no 'z') and not "pniels" (with 'z')
23:44:39 <moneromooo> Does anyone know whether there could be some catastrophic breakdown somewhere if one were to use the wallet secret spend key 0000..0000 ?
23:45:10 <moneromooo> Beyond "anyone can find it", etc.
23:45:59 <moneromooo> Beyond "whoever does that loses all money". I mean a problem extending to others.
23:47:03 <moneromooo> Also not interested in any outputs from a sillly key being included in rings and therefore weakening rings, since there are many other ways to do that.
23:47:25 <moneromooo> Does it break something that's not yours, basically.
23:48:11 <moneromooo> Something that would qualify could be: if someone else uses your output owned by that silly key, the resulting output is burnt.
23:49:18 <moneromooo> The question also applies for other less silly/invalid keys. Like identity. Or stuff beyond the 2^252 +/- something.
23:50:46 <koe> sarang on freenode webchat that meeting url is still broken, I think it's expecting a space at the end
23:50:59 <moneromooo> koe: that's quite an open ended question, but AFAICT you can't have an output of more than 2^64-1, so nothing bad should happen.
23:51:29 <moneromooo> Balance reporting would likely bork if someone were to amass most of the supply :)
23:51:39 <moneromooo> But it'd be only cosmetic.
23:51:41 <koe> mooo would the MONEY_SUPPLY overflow and cause block rewards to go up again?
23:51:55 <moneromooo> AFAIK this is checked.
23:55:20 <moneromooo> I've added checking this in practice to my list.
23:55:30 <koe> great :)