what happens when the total money supply exceeds 64bits? it should happen 2 years after the emission tail begins, so about 2024

<woodser> does monero-wallet-rpc currently support https through config options to certificates, or is this left to nginx?

<woodser> (nginx or similar)

monero-wallet-rpc supports SSL.

<woodser> to clarify, a client can connect to monero-wallet-rpc using SSL?

<woodser> I added `--rpc-ssl enabled` to monero-wallet-rpc’s startup args which should generate a temporary self signed certificate per monero-project/monero #4852 but the client throws “TypeError [ERR_INVALID_PROTOCOL]: Protocol ‘https:’ not supported. Expected ‘http:’”

<woodser> how is SSL enabled?

<woodser> nevermind `--rpc-ssl enabled` worked to enable SSL on monero-wallet-rpc. The client was not using it correctly

Meeting in a couple of minutes?>

Ok. Meeting time. Anyone around today?

Yup.

yes

hi

woohoo

So, tell me, compatriots in attendance...what have you done these past couple of weeks?

Watch the new year arrive?

2020 baybee

Does that count :)

Yeah. I didn't think that there would be too much what with the holidays and all. But maybe someone will have done their homework and surprise me.

I've got the Revuo Periodical to work on (the past half year's worth of stuff)

After new year PRs went back to their usual pace again.

Quite a number of PR's waiting, yes?

Work was done mostly on bug fixes.

Snipa you around?

I've been doing a few pool things, answering a fair few of koe's q's for z2m revision

oh, he's working on that? Awesome! How's it coming along jtgrassie?

looking good

He did some merges yesterday so I guess the others will also be merged soon.

What is "z2m revision"?

Is there any sort of ETA or no?

Zero to Monero

the author (koe) wrote before bulletproofs were implemented and the protocol has evolved since then.

so it's being updated. There was a CCS for it.

Ah, ok

there was also a fair few little things missing

those gaps are being plugged

Cool. Well good to know it's being worked on.

We may need a third revision if we ever come to a decision regarding modifying our ring sigs.

^ right!

And then we can just link to it when people ask to "see the white paper"

as that would be more accurate than the bytecoin stuff despite being more of a technical breakdown.

What you been up to selsta?

Did you make the GUI have a brown theme yet?

noo

I’ve looked into some build stuff / buildbot replacements

have you looked into github actions?

Well, unless anyone has anything else to say, maybe...

I think people either forget we have these meetings or think they're not very useful.

Let me ask this question. Should these meetings continue?

jtgrassie: yes

The "dev meetings" in their original form was when there was a lot of action from core and devs in the early days of Monero.

I have a PR for it open.

So the coordination was helpful.

selsta: oh I missed that

Windows was a bit of work.

Since then, core team has been taking steps back, dev stuff has been happening more organically. In other words, now that a "culture" of Monero has been established, it seems like these are less necessary.

rehrar: meeting still useful, people join when they can

I think they can be useful before releases / hardforks.

Perhaps I should give a reminder the day before.

Ok. I'll leave this question open for discussion for those who pop in and out over the course of the days. Perhaps open a meta issue for discussion.

Anything else to report?

Meta issue for discussion sounds good

agreed

Alright. I'll make it.

Well, it looks like we can break unless anyone has anything to say or question to ask.

The four of us should meet up for drinks afterwards.

Maybe at Konferenco :)

Is the location known in the meantime?

And date of course

I think Berlin, but don't quote me on that. I'm kind of purposefully not keeping up with the planning in hopes of not being roped in. :D

Hah

lol

#monero-konferenco is where it's being discussed though. Logs are on mattermost.

rbrunner: there will be a meeting in #monero-konferenco Wed the 15th at 19:00 UTC

Ok, thanks

and date and location will be discussed

selsta: can you make the test job use the build output?

Can be done later with caches. Didn’t look into it yet.

Artifacts is more for single files.

I've found the documentation a little difficult to navigate!

This seems to suggest artifacts are probably more appropriate for build then tests: help.github.com/en/actions/automati…-dependencies-to-speed-up-workflows

Creating an archive of the build output and uploading it as an artifact could work. Will look into it once it’s merged.

It takes 1 to 2 minutes to install dependencies so I’ve found dependency caching not worth it. ccache could be interesting.

You don't need to create an archive of build output, just specify the path to upload (which can be a dir).

(from looking at the docs briefly)

Not clear to me from the docs.

It looks like we can specify a path but usually artifacts are single files.

They have an example on that page using a path:dist

yep looks like it

these actions are some way off gitlab's cicd

from my casual look over the docs

but makes sense to use them if we can for sure

The downside of Gitlab CI is that it doesn’t trigger on merge requests: gitlab.com/gitlab-org/gitlab-foss/issues/23902

so basically useless for us

Wrote a comment up here: monero-project/meta #236#issuecomment-572720802

oh crud the meeting was at noon localtime not 1 -> I've got the amd ASM speedups compiling again against the separate monero-project/supercop repo

the downside is that the redirections to the ASM must be done in the "device" library which is dependency on a few places (ringct, cryptonote_core) which it arguably shouldn't be

resulting in unnecessary assembly in monerod. but otherwise it should be working

selsta: seems gitlab can do MR pipelines now: docs.gitlab.com/ee/ci/merge_request_pipelines/index.html

jtgrassie: The problem is that it runs it on the users Gitlab runner.

And the average user has no runner setup on a server.

You can’t share a single runner with all users.

We tested it on the monero-site repo.

gotcha

vtnerd: cool. what kind of speed difference are you seeing?

134% increase for a standard 2-output transaction

Im doing a _direct_ benchmark though, so I dont know how much it speeds up wallet2 yet

great!

it was easier to compare the crypto steps directly in a separate process

or no it was ~140% on this laptop. I'm curious what the ryzen will do because the other library might be faster due to the bigger cache