Rucknium[m]: you can try this on a cheap/free VPS. Best option I've found. github.com/thelounge/thelounge

Rucknium[m], jberman[m]: Would probably be worthwhile to write a post-mortem of this blog

dEBRUYNE: This blog? You mean the bug that jberman fixed?

this bug yes

Made a typo :-P

It would give users a good overview of what exactly occurred and how drastic the impact is/was

s/drastic/significant

I think jberman is working on something with this specific bug. But the broader issues are:

1) The Monero Project in general lacks the facilities to conduct statistical evaluation of its own chain and software. A statistical testing suite of the wallet would have caught this. Also, if a FloodXMR attack was being carried out, we wouldn't know it. I've started a little Matrix room to explore the detection of tx volume anomalies.

2) The Monero Project has relied on the statistical expertise of computer scientists (e.g. Moser et al. 2018) who in general lack substantial statistical expertise. The benefits of division of labor should be reaped by interdisciplinary work.

3) The Monero Project should actively recruit technical talent from universities and similar institutions so as to minimize its blind spots.

I have something written up on (2). Originally jberman and I were discussing combining it with his new MRL issue, but ultimately we decided to split the documents for a number of reasons; one of which was the fact that my criticism of Moser et al. (2018) was so withering. I have backed off on that a bit and tried to frame it more as a systemic issue than an issue with the particular paper and its authors.

Re: 2) This concerns not only the cryptography part.

"open source projects relies on people contributing" :)

The monero project really is the set of people who decide to contribute.

There are many more people on the planet who would willingly contribute. They either do not know about the Monero Project or they know about it but they do not realize the ways that their skills can be used to help it.

FWIW I generally agree with Rucknium 's points in that there does seem to be a lot of room for improvement on the statistical side of things, and more stats experts would be fantastic. I'll get started on a post-mortem for the bugs patched in the latest release, and can also include something alluding to Rucknium's general comments in the conclusion. Sort of like dEBRUYNE 's call for C/C++ devs to do PR reviews in this one:

> However, we, as the Monero community, should seek means to get more eyes on the code and especially new pull requests. If you are familiar with C and/or C++, please, if time permits it, try to review pull requests (even a partly review is beneficial).

Speaking of recruitment, Ciphertrace is hiring a ton of people 😬

I hear the Chinese govt has a *huge* workforce just spying on people too.

There are glassdoor reviews too:

"Cons: Very unprofessional, behind in technology, one abusive exec team member, CEO disconnected from reality."

Let's hope so :D

Rucknium[m], I mean the dude claims he is a cypherpunk so it was beyond obvious that he is disconnected from reality.

I'm see y'all talking about statistics and stuff. Haven't really felt like I could be helpful, but just to put it out there my undergrad is in physics; included upper level stats, plus statistical physics classes like thermo and just enough C++ to be an absolute menace

Lyza : Yes, an example of what I was talking about: "They either do not know about the Monero Project or they know about it but they do not realize the ways that their skills can be used to help it."

<selsta> "memory leaks reported by asan..." <- I got the sanitized ready. What's the exact way to reproduce this? By running unit_tests/core_tests? Just starting and quitting the daemon?

*sanitizer

luigi1111: A new problem: this action (of mine) has been running for almost 5 hours now and has to be killed: github.com/monero-project/monero/actions/runs/1193523599

done

thx

Anyone has a recommendation of (up to date) technical book of Monero? Other cryptocurrencies is also welcome as long as knowledge relates to XMR.

quila[m], u aware of "zero to monero" ?

gingeropolous: Yes, I did see the books suggested at getmonero/library. I going to print them out this week actually.

If there are any other ones useful you might think I should also print.

Or order.*

mj-xmr[m]: I don't have steps to reproduce, it showed up on exit after running a couple days

question on reproducible builds for the GUI: I noticed the process doesn't produce the installer or .zip file for windows, just individual files in a /bin directory. No problem, I figure the actual monero-wallet-gui.exe should have matching hashes after installation, but it doesn't seem so. So I guess the question is, how to verify reproducible builds for the GUI?

Lyza: which hash did you get?

did you run the reproducible build process?

yes, and I also just double checked that I build v0.17.2.3 and not master or smth

I got 9f6836791bd74b8b67b2582442593ac460189bb72555b04f79d3460d60a942b8 for monero-wallet.gui.exe vs f88e592530c9c96d5b1ef7a7070a3d378c1a2b99ad34081ae03e14d0b2b927ad from the official release

used the directions here: github.com/monero-project/monero-gu…-static-binaries-with-docker-any-os

this has the same hash you got, but I got a different one for some reason

I think I know the issue, my file has different permissions

I think I may have actually built master -- monerod came out 0.17.2.3-release but actually jsut checked the GUI it says v0.17.2.3-113efbfd

file permissions can affect hash?

not sure, maybe not

they have the same size at least

binary diff only shows 1 bit difference, don't know what it is

i can run a build here just to double check

it seems my build is wrong by 1 bit but no idea what it is

Lyza and Github Actions build matched

Do you mean you do not know what the bit is for, or what bit it is ?

I posted the diff here paste.debian.net/hidden/74b75f2a but I don't know what it's for and why it's different on my system

You can try objdump --full-contents then diff both outputs. Might tell you more.

And technically it seems to differ by 3 bits...

Pedantry is such a draw...

objdump --full-contents diff is quite large

is there any particular reason that GUI and CLI have somewhat diff reproducible build workflows? and not gitian repo for GUI

no particular reason, current solution was just easier to implement

also no gitian repo because we don't have reproducible builds for mac

also less people build the gui

mk. since we don't seem sure why the hashes mismatch, I was gonna post a comment on the release thread letting people know. if that seems prudent

none of the binaries seem to match, is not just monero-wallet-gui.exe

I'm sure it's most likely just a kink in the build process but still

Lyza: the linux binary matches for me

linux GUI binary? I built it but haven't checked

yes linux gui binary

cool that's good

or what were you talking about?

"none of the binaries" sounded like plural

I mean monerod.exe, monero-wallet-cli.exe, etc that ship with the GUI

monerod.exe is taken from CLI reproducible builds

it's not taken from docker

okay word

prolly would be good to document that

unless I missed it

we intentionally marked it as experimental

but yes that can be documented somewhere