icscloud[m]: You could still achieve good mining performance (for a given hardware), if you do everything in Java, EXCEPT for the mining part and just call it via JNI:

Which by the way, might turn out to be much less (guess)work, than trying to reimplement RandomX in Java.

> <@mj-xmr[m]:libera.chat> icscloud[m]: You could still achieve good mining performance (for a given hardware), if you do everything in Java, EXCEPT for the mining part and just call it via JNI:

> developer.android.com/training/articles/perf-jni

nice

<mj-xmr[m]> "Which by the way, might turn out..." <- yes

thanks

<garth> Can I ask why we aren’t having our PRs merged in the main Monero GitHub repo? There are 140 unmerged PRs in the queue. I understand they need review, but there are a lot that have passed review, and they still have not been merged. Is Luigi1112 too busy to maintain the main repo (which is totally fine)? If so we need to come together as a community and find or fund someone to do this

important work. I am grateful for fluffypony and all the volunteer merges he did in the past. Ric, any chance you might be interested in taking up this volunteering again? If not, considering snipa doesn’t seem to have had the time or energy to help, do you have any ideas?

Cross posed from #monero

I unfortunately don't have the time to take up a lead maintainer role again

I do agree we need someone to really step up to the mantle with that

I understand that repo merge privileges are massive to give away (partially responsible for splitting BTC) but IMHO constant merges are what gave the project a ton of energy back in 2017-2018. To have slow unconsistent merges makes the project itself lose energy

I'd suggest we start an issue in the meta repo, and then encourage anyone who wants to take on the role (and, importantly, has a few hours a day to commit) can post in that thread

Ok I can do that. In my opinion Monero is the most interesting, useful, and legitimate cryptocurrency in the world right now. This is important for the project to keep alive

Do you think that some paid/crowdfunded developer would help to improve the situation?

Perhaps, sure. It all depends

I would love to contribute, but I never used C++, sadly I'm just a JavaScript and Java developer

Meta issue created —> monero-project/meta #675

"importantly, has a few hours a day to commit" <-- this is the killer

xxfedexx[m]: a maintainer is absolutely allowed to go and crowdfund for the time they spend

but trust is something that is earned over time, so a newcomer wanting write privs in the repo + getting paid for it is doubly problematic

this situation is ripe for abuse, so the decision would need to be taken carefully

put the work in first. prove competency and dedication

xxfedexx[m]: if you can program in general great. seems like you should have an understanding of OOP if you do Java so you're on a good track.

there are tons of free online resources to learn C and C++

louipc: Do you mean Object Oriented Programming? It's not hard

yes, but the point is that you have some of the concepts in your head already

not a complete noob

you will have to learn about how computers really work

tho. memory handling

buffer/integer overflows and whatnot

to be fair, the ramp up time for C/CPP can be pretty long, especially for a technical project

cornfeedhobo: I was first taught CPP. I cannot, in good faith, recommend it for anything. Retrospectively, I can see how much of my time it wasted.

I don't know about its original competition, but compared to modern languages, it feels like it was written by people who hate programmers.

haha. it was built for a different time.

<fluffypony> I do agree we need someone to really step up to the mantle with that <= +1

.merges

C was a good design for its era, late 1970s, where 32KB was a "large" amount of RAM

it followed much the same path as other compiled languages of the era: fortran, cobol, pascal

C++ was a sick joke from day 1. Ignored innovations already well established in Modula-2, ADA, etc.

My frustrations with CPP is why I started working on a Go repo. Its not much yet, but it will get there.

Go is still mostly a toy language

"What? So Rob Pike is basically saying that the developers at Google aren’t very good so they’ve developed a dumbed down language so they can get things done."

Well, they certainly catered to me 😅

hyc: there is a good talk about this, but the tl;dr is that go is not meant for siloed programmers. Historically siloed and intelligent went hand-in-hand, but that is no longer the case, and that blog post is the emotional fallout of someone learning they will not be valued the way they used to be

put another way, companies needed a language that was so simple that swapping out the employees that built a codebase is trivial

hyc: I am several orders or magnitude a lesser programmer than you. I'll own that. I am not so intelligent that I need more. Go is a sweet spot with me (but does have its own issues).

so you're saying go is bad for job security

<hyc> "nomad.uk.net/articles/why..." <- I think some of these issues have been addressed with more recent versions. However, for some things it is verbose and boilerplate.

hmm, yeah that's one way to interpret it. of course, any interview that I go into where someone is worried about that or makes that joke gets immediately removed from our list. It's been our experience that they throw more wrenches than anyone else.

it's not a hard and fast rule, but it's not the type of thinking that helps. because the same employee could be removed from the codebase through promotion or finding a better company or some project they'd prefer to work on

Its error handling is verbose and boilerplate, but I address that in my code by making my types include an error type with the data, rather than returning it as an additional arguement.

it's certainly a weird notion, yes. job security should be about your ability to apply your skills to any problem. not solely your intimate familiarity with a single code base

exactly

cornfeedhobo: It isnt just simplicity to swap out people (which IMO is good for an open source project). But set up, compile, testing, benchmarking, optimizing concurrency...it is all so quick and easy.

at any rate, I personally despise most modern languages that keep the programmer multiple layers of abstraction away from the actual bits and bytes

strongly-typed languages etc... you can't even do cryptography properly in them

because our ciphers and hashes treat e.g. 32 byte clumps as big integers

you need to understand at a very low level what all your high level data types really instantiante as

hyc: You are smart. And your intelligence is extremely valuable. But it is also uncommon. I think for a collaborative project, such a language is better. And programmers like you can tackle the issues no one else can, while everyone else is maximally productive on everything else.

you have to be able to freely jump back and forth between "objects" and "sequence of bytes" otherwise you can't even write the calculations needed.

wernervasquez[m]: yeah. indeed i like those other values, but to be fair, there are a host of other languages on the scene now that do the same. The real big sticking point with golang is that it's so small you can literally learn it in ~6 hours

hyc: nimlang might be up your alley

hmm, seen it mentioned a few times but never looked at it

<hyc> "strongly-typed languages etc..." <- Filippo seems like an compentent cryptographer-programmer. He writes for Go. filippo.io (I put him in the same bracket as you - beyond smarter than I).

<wernervasquez[m]> "Filippo seems like an compentent..." <- Another Italian coder :-)

I'm Italian too, just like ErCiccione and FluffyPony

Speaking of Filippo, does the monero codebase have anything like his baseMult implementation? github.com/FiloSottile/edwards25519/blob/v1.0.0-rc.1/scalarmult.go

It looks like you can swap one line and have an efficient point multiplication for any point. Not just base.

no

It sets up the tables on first use, so if we had that, we could make a function that accepts a point, sets up the tables, and allows quick multiplication.

It would be useful during prototyping. And if we ever needed to scalar mult a point defined during runtime enough to justify the overhead.

We do, at least in BP IIRC.

wait nvm I think it's the ge_precomp thing

UkoeHB: Cool, I'll take a look

or maybe the ge_dsmp

<hyc> "nomad.uk.net/articles/why..." <- that article is a bit vulgar and does not feature the biggest issue with go: goroutines. They are not really coroutines and not really OS threads. Scheduling seems to be preemptive and not cooperative. It is not easy to gain an intuition for how they will perform and what the limitations are. I really liked the talk by Rob Pike about concurrency when I looked into go in 2015. Everything

seemed so clear and easy. In practice it is sadly not like that. But there are also good things about go. For example compile times.🙂

spirobel: Can you give a concrete example of an issue this caused you that a simple programmer would understand?

Thoughts on Rust? I've heard a lot of good things about it and I thinking to give it a try

I'm a huge fan personally, it makes writing multithreaded code performant and safe without a GC

why not using golang?

<joerg1> "why not using golang?" <- Golang is a great language for many projects, but it does have downsides. For one, the garbage collecter and runtime mean that it's much more difficult to use in embedded projects and projects requiring low CPU usage and very low memory usage. The GC, while being very useful and definetly has a small amt of overhead, still does have overhead that matters in very performant applications

Rust achieves a lot of what GoLang does without compromising on performance or memory usage

It seams that I have to learn Rust.

joerg1: I'd definetly recommend it! Though just to warn that the language forces you to re-think the way you program, and it can be very frustrating in the beginning. That and compile times are painful (but worth it)

XMRig is in C++. Is it a good idea to change the programming language?

.merge+ 8170

Added

joerg1: You want to write a monero miner?

I am thinking about.

If it's a brand new project, yes, writing it in Rust would be a great idea. If it's an existing project, rewriting specific parts in Rust or writing new modules in Rust and using #[repr(C)] to make it C-ABI compatible would probably be easiest

It is a brand new project.

Id definetly recommend starting it in rust then

if you need any help or have any questions abt the project or writing it feel free to message me

Thank you. Here is another question. The idea from the Bitcoin white Paper is to use only CPU Mining. What do you think about to write a miner specific for CPU mining?

aka a randomx miner?

Yes

you won't get any speedups, the critical parts are written in ASM

all monero miners are randomx miners, so...?

What are your opinions?

I guess you can do it as an exercise, but otherwise I don't think there is much point to this. Also IIRC someone implemented RandomX in Rust, but I'd have to look it up.

The idea is to give all the same chance to mine monero. You don't need expensive GPU's. for exaample. your smartphone can do the job if you don't need this device.

Mithril miner is written in Rust

joerg1: monero already uses randomx, not sure what you want to change...

It's not clear what your goal is. You can mine already on your smartphone and other platforms. What would changing the programming language do?

Okay that is the information, that i had not.

I would like to learn to code for the Monero Project.

I am collecting info on what Decoy Selection Algorithms wallets are using:

If you know what methods wallets are using to select decoys, I encourage you to leave a comment with a link to the relevant source file(s).

I've asked this question on #monero channel but no answered. I'll try my chance here.

A question: Is it dangerous to make together fountain/escrow wallet and users wallet (for all just 1 wallet, they become a subaddress on a wallet)

$moneroRPC->open_wallet takes too much time for everytime. I cant optimize it.

NakedKing: I don't understand your question. Make a wallet multisig will convert the entire thing (deleting old keys). You can't have both.

both the old normal wallet and the new multisig wallet*, unless you have two separate wallet instances.