-
one-horse-wagon[
rbrunner: How big of a leap in coding is it to go from flawless CLI code to Windows Gui every time there is a hard fork? Is it easily done or a nightmare? I ask because I am working on a road map for Seraphis and Jamtis and you appear to be quite knowledgeable on Windows.
-
rbrunner
Not sure what you mean. Right now the true complicated action happens in a big mass of code called `wallet2` which both wallets use, and most of the changes for normal
-
rbrunner
hardfork as we had them now happens there. Adjusting CLI and GUI wallet after a hardfork is usually small work.
-
rbrunner
And as the GUI wallet uses Qt which *should* run identically on Windows, Linux and Mac, that also should not pose too many problems
-
rbrunner
But well, for Seraphis and Jamtis things will probably look different, and many aspects we even don't know yet.
-
rbrunner
Or did not yet decide between several possible options
-
rbrunner
I wouldn't rule out that the current CLI wallet in its current form doesn't survive the switch to Seraphis and Jamtis, and a rewrite will replace it
-
rbrunner
Or maybe two rewrites: A normal wallet and a multisig wallet ...
-
rbrunner
I hope these answers eliminate all certainty :)
-
one-horse-wagon[
rbrunner: That's what I needed to know. Thank you. I'm coming up with something by our next meeting on Wednesday.
-
UkoeHB
IMO the cli wallet needs to be broken into different wallet types instead of shoving everything into one class. Multisig and view-only stuff should not be in the same class as a normal wallet.
-
rbrunner
When people write "CLI wallet" they usually mean the CLI wallet app, the `monero-wallet-cli` binary. It's confusing with all those things called "wallet" :)
-
rbrunner
Seeing the nice effects of "aggressive" modularization in your Seraphis wallet I agree with splitting `wallet2` into 3 wallet classes, like you propose
-
rbrunner
But what that means for the user tools is a bit hard to decide. As a user, having to deal with 3 different *binaries* because of this might not be ideal.
-
rbrunner
Not to mention with all the code duplication that happens with that if you are not very careful.
-
rbrunner
Same with the RPC wallet server.
-
UkoeHB
rbrunner: it might be possible to do bindings to sub objects like the enote store, and then compose the binding lists at a higher level into the ‘cli interfaces’
-
rbrunner
I suspect so as well. I think we do have the free choice whether we implement 1 CLI centric wallet app, or 3. It's probably a question how complex a single app would get however.
-
rbrunner
If we have a long transition period for the hardfork where the network supports both transaction formats, will syncing work correctly if "old" and "new" transactions to the same wallet get mixed in the blockchain?
-
rbrunner
Maybe that can get quite complicated if basically you have *two* current scan heights, one "all old-style transactions scanned until block x" and the same for new-style transactions
-
rbrunner
(Just coming back from writing a new issue, about that transition period:
seraphis-migration/wallet3 #22)
-
UkoeHB
rbrunner: yep pretty much, it's complicated but doable
-
UkoeHB
you actually need three scan heights to be generic, one for legacy 'view only', one for legacy 'full', and one for seraphis
-
UkoeHB
-
rbrunner
Ah, ok, you have long noticed and even implemented that. Nice.
-
UkoeHB
then there is a little juggling you have to do to finagle the fullscan height when doing view-only scan + key image imports
github.com/UkoeHB/monero/blob/c3568…s/seraphis_enote_scanning.cpp#L5183
-
UkoeHB
the workflow is sketched here in the balance recovery section:
seraphis-migration/wallet3 #8
-
rbrunner
Yeah, also saw that "Mock-ups to fully implement" section of that issue for the first time in the recording of your walkthrough. Useful.