13:24:53 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. 13:26:37 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 13:27:07 hardfork as we had them now happens there. Adjusting CLI and GUI wallet after a hardfork is usually small work. 13:28:00 And as the GUI wallet uses Qt which *should* run identically on Windows, Linux and Mac, that also should not pose too many problems 13:28:38 But well, for Seraphis and Jamtis things will probably look different, and many aspects we even don't know yet. 13:29:02 Or did not yet decide between several possible options 13:30:13 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 13:30:28 Or maybe two rewrites: A normal wallet and a multisig wallet ... 13:31:17 I hope these answers eliminate all certainty :) 13:42:34 rbrunner: That's what I needed to know. Thank you. I'm coming up with something by our next meeting on Wednesday. 14:06:26 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. 14:43:16 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" :) 14:43:57 Seeing the nice effects of "aggressive" modularization in your Seraphis wallet I agree with splitting `wallet2` into 3 wallet classes, like you propose 14:44:38 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. 14:45:03 Not to mention with all the code duplication that happens with that if you are not very careful. 14:46:15 Same with the RPC wallet server. 14:58:11 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’ 15:00:19 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. 15:18:25 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? 15:22:08 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 15:26:06 (Just coming back from writing a new issue, about that transition period: https://github.com/seraphis-migration/wallet3/issues/22) 15:31:35 rbrunner: yep pretty much, it's complicated but doable 15:32:16 you actually need three scan heights to be generic, one for legacy 'view only', one for legacy 'full', and one for seraphis 15:32:34 https://github.com/UkoeHB/monero/blob/c35686fcbbd17838cf23130c53495a8dd0e50502/src/seraphis/tx_enote_store_mocks.h#L253 15:33:22 Ah, ok, you have long noticed and even implemented that. Nice. 15:34:38 then there is a little juggling you have to do to finagle the fullscan height when doing view-only scan + key image imports https://github.com/UkoeHB/monero/blob/c35686fcbbd17838cf23130c53495a8dd0e50502/tests/unit_tests/seraphis_enote_scanning.cpp#L5183 15:36:31 the workflow is sketched here in the balance recovery section: https://github.com/seraphis-migration/wallet3/issues/8 15:38:07 Yeah, also saw that "Mock-ups to fully implement" section of that issue for the first time in the recording of your walkthrough. Useful.