Hey MRL folks, beside the change of POW, what needs to be changed on this page: web.getmonero.org/technical-specs ?

The maximum block size isn't strictly twice the 100-median with ArticMine's updated method

Might be easier just to state that it's dynamic, which it is (subject to a particular non-static cap)

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

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

Thanks sarang. I'll wait for more comments. If there aren't any, i will just add the changes you suggested

Would it be useful to link to actual technical details from that page? It's super sparse now... not really much for "technical specs"

Or, even crazier... why have that page at all? What is its actual value to the reader?

When I see similar pages for other projects, I find them generally non-useful

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

why have that page at all? <- yeah it's not super useful, just a quick summary of the main technologies we use

Are those up to date?

i guess we could merge that page with some other docs if needed

Those = whatever moneropedia things you are referencing

Don't other pages list the main tech, with narrative and pictures?

TBH the project doesn't really have technical specs in the correct sense

It has the code, and it has resources like Zero to Monero that describe (some version of) the protocol

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

Yeah, don't make a decision purely based on my ranting =p

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.

The encrypted amount itself is already only 8byted.

You could still overflow

1 - 1 == 0, and -1 == still probably larger than any actual transaction amount

Hmm true

Also, a 64-bit curve would be a terrible idea :D

(if you mean a useful curve group of order 2^64)

Just an example lol would have to be a different real scheme

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

So it's either 32 bits or 64 bits (or higher)

Funny that there was a similar conversation on this in bitcoin-wizards yesterday

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)

um! what about just proving the last 192 bits sum to zero?!

Range proofs are small and fast now

Thank god for the division of labor

?

was thinking about other ways to do a range proof, and realized it's better to focus on things I'm good at '=D

From vtnerd: monero-project/supercop #3

yeah good call posting here, reviewers for that are going to be tough

and unlike other projects that attempted the same, this _should_ keep arbitrary ed25519 scalarmult constant time

which would protect the viewkey under certain circumstances

You mean non-basepoint?

yes, these libraries don't have existing support for that

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

I didn't touch original ASM in the tree, just copied it and added support for the extra value in the group element

Do you have a time comparison for the extra inversions? (Still reading PR in mobile; sorry if you answered this there)

An estimate, that is

in fact I couldn't touch original, or the pre-generated tables for the basepoint no longer work

crap, I did at one point I can do it again probably

Will you be around for the Wednesday meeting, in case anyone needs to discuss?

sure

18:00 UTC

great work vtnerd

Yeah, great to see this work revived from the old PR

anonimal's suggestion to move to a separate repo may have turned out better than I thought

How so?

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

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)

"pull in" meaning reaching inside of the monero source tree that isn't designed to be exported to other projects really

Right

I'm excited to play around with it this week

sarang: Do you have push access to the research-lab repo?

No, but suraeNoether and I considered doing so and decided against it

We are thinking about converting monero-project to an organization.

Too many projects all in progress at the same time meant things get hectic and having a shared master branch for them got messy

its not?

My skunkworks repo has project-specific branches currently

I don't love it as a solution (for visibility) but it helps IMO

It’s not currently. Moving to an org would allow for more granular permissions.

I think it would be nice if the research-lab would be up to date. Currently information seems to be spread across different repos.

It seems like fluffy doing merges was one of the reasons it stopped getting updated.

I don't like the idea of a single research repo

General research isn't a single project that has regular and consistent checkpoints

If anything we could do separate repos per research topic / project, but that'd be a lot for me and annoying for forkers

I don't know an optimal way to present it all

I don’t mean that all the research should be done in a single repo.

But currently the repo seems not maintained, apart from some issues.

It is not

I have a skunkworks repo that contains almost all of my research projects

suraeNoether has a separate one of his own

My fork of research-lab has not been used in quite some time

Probably best to define the scope of the repo (e.g. finished research papers, maybe chat logs, ...) and then keep it maintained.

We did discuss using a separate repo for finished papers

Since those do have definite checkpoints and finished states

And are much more collaborative

I'm very open to this idea

As long as those are kept strictly up to date with things like IACR versions to avoid inconsistent versioning

The readme could contain links to individual researchers' repos for visibility, if that's helpful

The existing research-lab repo could be clearly marked as essentially archival

I think having push rights would help with organization.

For sure

Having to wait for a maintainer to merge things is just frustrating if you want to keep things up to date :P

Yeah

I hope moving to an organization will help with that.

Is this something that will definitely happen?

Or are there hidden gotchas in the workflow?

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.

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.

That was one of the improvements i wanted to have on gitlab: an organization with proper access control

agree, it seems like it will heppen

happen*

yeah, i will comment on the meta issue as soon as i have time.

But i guess this is a bit OT here

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

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

the issue is that it has to an inversion + 3 field multiplications 7 times

*inversion -> field inversion

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)

and yes I know I can't spell

*the issue is that -> the issue with using the choose_t assembly that works only with "niels" (no 'z') and not "pniels" (with 'z')

Does anyone know whether there could be some catastrophic breakdown somewhere if one were to use the wallet secret spend key 0000..0000 ?

Beyond "anyone can find it", etc.

Beyond "whoever does that loses all money". I mean a problem extending to others.

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.

Does it break something that's not yours, basically.

Something that would qualify could be: if someone else uses your output owned by that silly key, the resulting output is burnt.

The question also applies for other less silly/invalid keys. Like identity. Or stuff beyond the 2^252 +/- something.

sarang on freenode webchat that meeting url is still broken, I think it's expecting a space at the end

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.

Balance reporting would likely bork if someone were to amass most of the supply :)

But it'd be only cosmetic.

mooo would the MONEY_SUPPLY overflow and cause block rewards to go up again?

AFAIK this is checked.

I've added checking this in practice to my list.

great :)