hyc: trezor seems to work, but will do some more testing

<moneromooo> "I'll /unignore now since "he..." <- I told that guy 3x over 3 days... (full message at libera.ems.host/_matrix/media/r0/do…a7dbc315c16a59b5b86a7e0082fa6983013)

* I told that guy 3x over 3 days... (full message at libera.ems.host/_matrix/media/r0/do…4f3126b1d34542927c6111dea367e127599)

selsta: great

Is there anyone here who does not contribute to monero but would if there were parts in rust ?

And I'm not sure how to say that non insultingly, so: and who's a competent coder (yes, it's subjective).

Are there many competent Rust coders?

Seems more like Rust is a solution looking for a problem.

Yo

rust has only been stable enough to use seriously for a couple years

before that the language was pretty much rewritten with every update

I saw the one previous issue, yet I didn't appreciate it.

Is there a new reason this is coming up moneromooo, or just polling?

Personally, I despise working with C++ and its tooling. I've spent the last month rewriting a significant portion of XMR wallet code in Rust.

Someone somewhere asked whether we'd accept rust code in self contained bits. One of the conditions is that we have enough people willing to read/debug/maintain/review such parts.

Though I will note I already had use cases the existing C++ code didn't handle, and I've heard horror stores about wallet2 specifically.

I'd be more than willing to help with review and maintenance, though my personal long term preference would be a dual-impl, not a merge-impl.

dual makes more sense, agreed

... unless it's a merge-impl where all the Rust code is a singular lib. I don't see value in piping out individual functions randomly, but I would enjoy seeing all of RingCT moved to Rust.

What is dual-impl, and what is merge-impl ?

but a lot further in the future

We have monerod and monerod-rs

monerod is C++ and monerod-rs is Rust

merge-impl would be we have monerod, which requires both to compile as it has both.

Ah, you mean make your own separte codebase ? It's not a term of art ?

But again, the discussion should never be "Can I write random functions in Rust and give you a C FFI?" That's a mess

The discussion should be what's currently in C++ that'd be better done in Rust, either for the libraries, the safety, or the people willing to work on it

For example, the ZK membership proof I'm prototyping. We may legitimately want to use a Rust impl for it. In that case... we'd want this one portion done in Rust as an isolated component which solely defines `prove` and `verify`

And yes, I did mean a separate codebase by dual impl

Not only am I effectively doing a full wallet right now, I'm also interested in an impl of BP+ in Rust (so I can micro opt it, not to mention better understand the algorithm), but I would love to see a seraphis-rs

Rust is great at highly composable packages and so on. Perfect fit IMO

Though I know koe doesn't prefer Rust, and accordingly, Seraphis should be in C++. The only discussion would be about individual proofs, such as the membership proof, as *most* ZK code is in Rust.

Though I do eventually want to propose a BP solution we can do in C++ as well without too much hell :)

Its an incredibly risky proposition to go refactoring the codebase just to fit Rust in.

To clarify, was this the issue from a few weeks ago, a new one, or a non-issue yet just a question?

new asker, same question

Do they have an issue?

from -research-lounge

Got it

I did not realize it had been asked earlier, sorry. I thought "would we have maintainers" was an easy filter to check :)

Oh. It was specifically within the context of the membership proof

I raised the "do we have maintainers" point last time around

Did you find any ?

I think that'd be a prime target to do in Rust, though I don't plan on submitting one infeasible for us to do in C++

I and anyone who worked on COMIT/Farcaster...

moneromooo: nobody jumped up and down last time

Also, hyc, it should cross compile to every platform in question (I'd have to double check, and I can see why that'd be a requirement of course, but it does have a ton of targets)

And C FFI can be done in just a few lines.

`pub(crate) fn c_generate_bp(len: u8, amounts: *const u64, masks: *const [u8; 32]) -> *const u8;` Here's a C function. From the Rust side, I have 2 lines to format the inputs as needed.

And then I was lazy and instead of doing the proper struct for the output (which is possible), I just serialized/deserialized it each way. I'm still relying on monero-rs types in my work...

As for jumping up and down, I didn't know this was asked last time :p Rucknium[m] was helpful enough to ping me this time and I am happy to jump to present clean programming with modern package management and building which offers memory safety and great cryptography :D

Bringing this over here from *-lounge: github.com/monero-rs/monero-rs

^ I think looking at the contributors to that project gives a good idea of who in the community can make meaningful rust contributions. Not many, but maybe enough?

.merges

Ideally there would be multiple independent implementations of everything, with the C++ code as canonical verifier. What dangerousfreedom is doing with python is a good example.

UkoeHB: glad to hear that said. Years ago when I lurked there was a seemingly prevalent attitude that that was unneeded, unwanted, and a waste of time.

But perhaps I only lurked when cranky people were talking

It depends, obviously.

It's a waste of time if it's people working on monerod leaving to start another impl, which in all likelihood will be abandoned.

If it's new people who want to do that, it's not.

It's wanted if it acts as a bug finder/comparator, it's unwanted if it ends up used by half the people as main daemon, leading to possible forks on economically important nodes.

If you have little manpower, you don't want to waste it in duplicate work.

Several people popped up over the years saying they'd like to code a rust wallet and/or daemon. AFAIK none ever did. Maybe some starting code was done, and then it got abandoned.

Though there's this github link above, maybe that's one of these people. Who knows.

I mean there are pros and cons. And I'm cranky.

monerod also used to be a more moving target than it is now.

The github link above is a library of utilities for working with monero in rust. It handles things like checking ownership of outputs. It's pretty complete and used in a number of projects (including my own payment gateway library, acceptxmr). kayabaNerve mentioned above that he's using it too.

So while I agree that many "let's rewrite this in X!" projects are wasteful, the work going into the monero-rust ecosystem seems to be paying off pretty well (in my totally unbiased opinion :P ).

BusyBoredom[m]: I'm actually trying to drop that lib. It has a lot of bad design decisions when you work on a deeper level IMO and it was written as a minimal set of types meant for RPC work expanded as needed.

And while it's great with its functionality state, I don't believe it's optimal for more complicated work.

I do believe it counts as new people who want to do a full daemon. I don't currently want to do a full daemon.

Ah that's a bummer, I've only used it for higher-level stuff so I wasn't aware of the low-level deficiencies :(

It just constantly byte encodes D:

I do believe the XMR protocol should be formalized and we should aim for the ability to have a multi-daemon future as I believe those only fail when there's no protocol spec to match or implementors suck. I don't see that as any immediate goal though, and it'd be a multi-year target.

Pinging sethforprivacy due to a semi-related discussion we personally had earlier on protocol development

an actual protocol specification would be great...

hyc: intel binary it also runs on 10.13 according to jeffro256[m]

i'm quite surprised that using the new SDK works for such old OS versions

we're at the threshold I think. older 10.x revs are gone from there

so it sounds like we're in good shape for this PR

hmm I just remembered that I have a 10.12 VM, I'll test it too

but in any way 10.13 is good enough for backwards compatibility

still have min version set to 10.8