<UkoeHB> "Pretty sure equation numbers..." <- did you not use LaTeX? Really is standard practice in anything math related and most of the time formats well.

Sorry to burst your bubble, but I wrote that book for myself, and myself did not care about equation numbers.

Thats fine, but dr_overdose has a valid point and if you wrote it for yourself why bother to upload it publically, link it to people, then get defensive when someone gives you feedback? You reacted the same way when I pointed out (minor) errors in the DAA section. Its unprofessional.

And if you want Monero to be a high quality crypto, developers need to professionally address positive or negative feedback. Otherwise you end up with algorithms and code with significant mistakes.

latex source is public, if you have suggestions you can make a PR

I get quite annoyed when people come at me with what I 'should' have done, especially ~2 years after the request-for-comments phase is over. Everyone has their own little thing they would do, if they did it themselves. At the very least, try to hear and respect my reasons for doing things the way I do instead of projecting your own vision on me (which I find very insulting).

UkoeHB: On the subject of being annoyed...A professor of mine would be quite annoyed by both over and underachievers arguing with him over points they felt they should have gotten.

So, he implemented a rule. Before you can ask for points, you must take the number of points you think you should have gotten, and calculate what impact that will have on your final score.

No one ever bothered him again. Some realized it wasn't worth their time when they saw how little it mattered. Others just couldnt be bothered to make the calculation.

My point is, since this is an open source project, rather than be annoyed, tell them to make all the needed changes themselves before you take a look at it. This will probably greatly reduce the amount of people who bother you. And, the few who persist, might just have something.

(To clarify on my anecdote, one had to calculate the impact to their overall grade for the entire course)

Yeah... I did that a couple times and never got any PRs...

That reminds me of the guy who translated both ztm1 and ztm2 into Russian. Very impressive guts!

uh oh we got professionals in here

quick, hide all the stuff!

Here is my updated plan for the seraphis/jamtis wallet design. I think this is ~final.

Is this the structure of the code and the classes, in broad strokes?

yeah

Interesting. Will this then more or less supersede the `wallet2` class of today? Or be built alongside it? As as subpart of it? Right now I can't imagine yet where up and down is :)

Since the basic structure of jamtis wallets is different from cryptonote/ringct, it isn't possible to map wallet2 directly onto this design. There will probably have to be some glue in the WalletManager.

Some things like the ENoteStore, TxRecord, MultisigAccount, NodeConnection, LedgerView could be shared.

I was just thinking how sweeping the necessary rewrites will be. After all you could say that right now `wallet2` is the center of the universe as far as almost all Monero wallets are concerned.

Rewriting them all to a radically different interface will be a challenge. Maybe necessary, but a very big break.

Personally, I don't plan to rewrite any of wallet2

Most of the glue work will probably be in WalletManager and RPC.

What exactly do you mean with `WalletManager`?

Well, a 'wallet' can be many different things: view-only, full wallet, multisig wallet, ledger-scanning implementation. The manager is in charge of constructing all these wallets and exposing an interface to the user (there is a lot of interface overlap between wallet types).

Ah, you mean, that's also something new, not something existing?

right

And parts like simplewallet and the RPC server will have to be rewritten to access wallets through this new WalletManager?

Probably lol

Er ... lol? I mean, that's pretty important, IMHO.

It's unavoidable for a large-scale rewrite of those components, since the interface for jamtis is fundamentally different

I readily believe you. I just doubt many people have yet a clear view of the magnitude of the job. Me, I had not, until about 1 minute ago

yeah. seraphis and its associated jamtis is lookin like its really monero 2.0, in terms of all the hooplah involved

Yep it's a big project. Hopefully this approach can solve/alleviate a lot of our current design issues around wallet2, without actually needing to rewrite wallet2 (which would be 10x more difficult even than this).

Well, if you replace `wallet2` you don't have to rewrite it, you just have to extensively rewrite about every Monero wallet in existence. Talk about "easier" :)

well, from my seat in the peanut gallery, it seems lots of folks would cheer the retirement of wallet2, or welcome something different

I think a good part of the RPC interface itself can be maintained, just the guts will point to different things.

Probably. I am just not sure whether much is won with achieving to keep the RPC interface. I think most wallets sit directly on top of `wallet2`

Certainly the CLI. To some lesser extent, the GUI was well.

And of course the RPC server itself.

Afaik exchanges rely on the RPC interface, so keeping as much as possible would reduce the pain for those guys (and reduce the amount of time to wait for everyone to support the new system).

I am just brainstorming whether there would be a way to bring the new "WalletManager" interface into service earlier than Seraphis itself

With an implemenation that has `wallet2` sitting underneath and allows access to existing Monero wallets

The aim: To allow dev to start migrating there wallets early

That would probably be a good intermediate step

Right about the exchanges, I would say, everything "automated" is RPC for pretty sure

I get downright dizzy thinking about a more or less full rewrite of the CLI wallet to a brand-new interface ...

Tbh I am slightly worried WalletManager would become as big a hairy mess as wallet2... oozing with glue lmao. On the other hand, I don't know any better alternatives.

You mean over the years? At first it will probably be pretty clean, no?

is this where the title of "software engineer" or "software architect" would fit?

Yeah, "architect". Good software architects are maybe even rarer than good C++ devs or good cryptographers

Well, gluing wallet2 to seraphis might be ugly from the start.

Wouldn't that be only temporary then?

At least in my brainstorming it is.

I mean, say we have the "WalletManager" interface ready towards the end of this year, and `wallet2` glued underneath to make it work.

Wallet people could use 2023 to rewrite their wallets to that, and when we hardfork to Seraphis end of 2023, we have wallets.

Pretty much all of them.

Otherwise worst case whe have RPC and the CLI wallet and not much else ...

I mean, seriously, how would you get ready pretty much everything at the same time otherwise?

Well, to completely deprecate wallet2, we'd need to refactor wallet2's functionality (which to date, no one has been enthusiastic about working on). If that never happens, there will always be glue holding it in place (otherwise old outputs would be unspendable).

Oh, yeah, that's an argument.

At the very least we can hide the glue behind WalletManager and 'legacy' methods/

Hmmm, maybe we can get away with only the scanning code if we offer a tool that can migrate wallets into a new format?

Since WalletManager just owns references to components, users that don't need wallet2 can just make WalletManagers with null references to the wallet2 part. This way, at least, wallet2 is only a discarded header.

(idk how well that idea would work in the end...)

migrate wallets?

How does a transaction look that spends an "old" output? Is this a hybrid, inputs "old", outputs "new"?

yeah

Ok, that's new code anyway then.

After the Seraphis hardfork all the tx building code in `wallet2` will be pretty useless, and goes into retirement. Right?

right

I don't claim I "see through" already but I have gut feeling something like a re-architecting of `wallet2` will come quite naturally while building all the new wallet stuff

Chop it into parts, put some parts into new places, retire some, etc.

Maybe only a single part of the system will still use `wallet2` as-is: The conversion tool that reads old wallets and writes new wallets.

That new Seraphis tx building code must have access to *all* owned outputs, old and new. So it might be best to put them all into a single cache / file.

Yeah, I will finally start working on a poc of this design today. Hopefully when that is done we will have a more precise picture of the next steps.

You will design header files and such?

No, a full PoC that works with my seraphis tx builder code, with mockups for ledger/node stuff.

Ah, Seraphis only.

woot wooot!

If Monero was a company, and I its CEO, and if I had a million USD to burn through, I would probably now build a "wallet architecture and migration strategy workgroup" with 3 or so experienced devs and put it to work

What did the projects that reimplemented in Rust or go or whatnot - did they just integrate existing wallet2?

only a million USD?

I don't think there is a *full* Rust implementation. The Dero people, as far as I know, did rewrite everything in Go. No idea how that looks, architecture-wise.

sech1: It's only the architecture and the strategy, not the implementation :)

We would need something new anyway, because of Seraphis and Jamtis.

well, does the address scheme (jamtis) need to be nailed down before the WAMS Workgroup (wallet architecture and migration strategy) starts?

Don't think so, no. You will probably move in much higher abstraction levels for a long time.

Well, the thought has crossed my mind: If we write everything wallet-related anyway, what must be half or so of all Monero code, why not switch to Rust ...

*rewrite

At least that would leave no doubt whatsoever about the magnitude of the job :)

is this more dev related than research? well the phrase is R&D, not R|D

True.

So I probably head over to #monero-dev in the search of my million.

all the millions are there

I don’t have a year to spend learning Rust...

And I am too old for it :)

Sure, that's not something we should put up on top as well. But one can dream.

hello everyone, i have been real interested in monero for some months

<rbrunner> "I don't think there is a *full..." <- I probably cannot say how much more I like Dero's coding of cryptonote in Go

It is pretty clean, tight, and readable. Since it is written in Go, compiling is a dream. I can never willingly go back to c/c++

I'm no guru, but everytime I've gone looking in their codebase to see how/if they handled something, they did it well.

For those of you who have not had the pleasure of compiling a Go project, you can install everything and build from scratch the whole project before you have managed to get the c/c++ toolchain ready.

<Rucknium[m]> "I am concentrating on BCH st..." <- Sorry, a couple days late to reply. I'm not really a statistician or anybody like that I'm just interested in monero in general, but if I can see the draft, I would love to.

asd_: Sure. Draft has been shared.