yes

Hey y'all, my PR for improving decoy selection based on the research topic posted here monero-project/research-lab #109 is completed here: monero-project/monero #8815

This PR should lessen the negative privacy implications that p2pool has had for decoy selection, which could mean that p2pool could expand its miner tx output count again to improve decentralization

(if @sech1 chose to take that route)

Rucknium:

ths pr limits the coinbase causing decoy reductions, but doesnt touch the bigger problem of coinbase consolidations... (full message at <libera.ems.host/_matrix/media/v3/do…2f21adc18ca57b95a20b4eade1b5dffe3c8>)

> <@ofrnxmr:monero.social> ths pr limits the coinbase causing decoy reductions, but doesnt touch the bigger problem of coinbase consolidations... (full message at <libera.ems.host/_matrix/media/v3/do…acb605e92c1f822a9b5175dc7b3e3e36485>)

no rings is the important part

That helps scalability but doesntnecessarily help privacy

right, 109 for privacy, 108 for scqlability

Ahh okay 👍🏻 my PR does nothing for scalability correct

I view the decoy poisoning as the “bigger issue” but that’s subjective

privacy is a problem, but without also working on the scaling issues p2pool and anything like it are

lets just say uptime and reliability trump privacy

my v0.18.2.2 hashes: paste.debian.net/hidden/efe3927c

with 108 + 109, should be able to reopen the floodgates without worry

instead of coinbase privacy causing bloat (rings when consolidating)and privacy reduction (decoy),-... (full message at <libera.ems.host/_matrix/media/v3/do…3e184eadc61062faa5fdd4b3e31290c6d57>)

Hey folks, yatima1460 is an experienced c++ and python dev interested in working on Monero. I mentioned the possibility of using the CCS or other sy'stems to get funded. She will tell you what she can do better than me, but are there areas where a help would be gladly needed at the moment?

Hello!

Yep I worked back in the day in Ubisoft and currently I am working in Opera/GameMaker

My knowledge is mostly build systems, C/C++ mixed with how game engines work (graphics stack and so on)

In the last 2 years in GameMaker my job was mostly porting the compilation of the engine from on premises to the cloud with targets: Android, HTML5, iOS, Linux, Mac, WASM, Windows, and tvOS. And console SDKs like PS4 and PS5, Switch, Xbox One, and Xbox Series XS

With and without Docker build environments

on premises = abandoned office PCs in a closet

I usually suggest starting to use the software, spot something that annoys you (probably a bug) and fixing it. It gets you acquainted with the source, what is where, etc, while working on a small thing with a clear goal.

Then, repeat with a larger thing/goal.

For bigger things when you're comfortable working with monero, you could join a meeting in #monero-research-lab and see what people are working on and see if there are self contained bits in those that you could look at. But going through the familirization steps above first is probably best.

the room on matrix: #monero-research-lab:monero.social

And of course the github issues list may provide something that you fancy looking at.

there is also the work on Seraphis being done, maybe they need devs there (ping rbrunner7)

at least in my opinion something that triggers me about the Monero repo on GitHub is that it has a confusing build system: there is a CMakeLists, a Makefile, a Dockerfile just in the root, and even worse the pipelines are a mix of raw commands and calling other scripts

like if this was GameMaker I would have a done a single vertical integrated build.py script or similar that when run just does everything automatically

similar to how you compile Unreal Engine nowadays on Windows, you just double click 2 bat files and you are done

and with a simpler build system you get the advantage that normies will like to build Monero from source, thus increasing safety and decentralisation I guess

Read the makefile, it'll make sense why there is Makefile and CMakeLists.txt.

normies will not read a makefile and they will be scared to even open one

But not a build.py ?

Whether a "normie" can read a Makefile is irrelevant. The README says "make", they use "make".

If they even build it.

what worries me is that this is a similar problem affecting Matrix

yes normies can use a client, but how do you achieve real decentralisation? Only if at least someone like pro-users knows how to run a node

and running a node with Matrix is extremely hard for the common folks

if it was just double clicking an .exe like running a Minecraft Server we would see a lot more servers spawning around

what i mean here is that decentralisation is not only about algorithms, but is about UX, and UX can be anything, from UI to easy to run and use and decentralise

in this case the build system as well

Maybe I misread your argument. You seem to be claiming more people would build monero if it had another build system, made how you think it best. Is that correct ?

Let me correct that a bit: more people who do not already know about the monero source tree.

more in general I see it as a single point of failure... (full message at <libera.ems.host/_matrix/media/v3/do…c065f538aae5f659efb56b4e92226569e07>)

Well, I need to be off for a bit, so here's the rest of my points for now:

Ah, bad timing.

That new argument seems unrelated to how the build system is implemented.

The main thing I see that makes it easy or not is whether it takes care of deps. Like Docker does.

If you have the deps already, "make" is all you need. Otherwise, that can be a pain, which docker takes away (but is annoying due to the daemon, memory, etc).

Anyway, feel free to explain what/how your build.py (or other) would do better than the cmake system.

cmake sucks, but I'm afraid all build systems do, so...

bottom line i would make something similar to what Mozilla does with Firefox, the mozbuild build system they use

basically a Python library that it used to build Firefox in a very simple way that over-arches both CMake and low level build systems

A quick glance does not spot a "main differences with other build systems" page. Can you say how switching to such a build system would improve decentralization (in this context, defined as the number of "normies" building monero rather than fetching a prebuilt binary).

A good analogy is like LLVM, what you ideally want is a build system that the frontend is the same on all platforms but the backend is different and there is a common library/API in the middle connecting the two

so becomes very easy to add new backends or frontends

It is far from clear why it is a good analogy. You need to convince others why your proposed change is an overall benefit.

It needs to fix at least one problem the current build system has, and introduce fewer issues in aggregate than it solves.

BTW, being different is, in itself, a problem, so being slightly better isn't enough.

Basically, list at least some things like "it wold make the build system [easier to use | faster | easier to change], because it would X, Y, Z".

And, ideally you'd also include the things it'd make worse.

everyone seems to want to build their own build system... I got burned on OpenEmbedded's bitbake years ago. No python build systems.

Anything you write in python is at least a couple orders of magnitude slower than something just using gmake, and requires multiple orders more RAM as well.

talk about wasting developer time...

Oh god bitbake...

The hours wasted on that... I had forgot the wretched thing. Thank you, hyc :/

(in fairness, most of the wasted time was probably because I didn't know it, I did not get to use it for more than a few months)

reminds me of Scons...

(used it once and never again)