14:26:19 <m-relay> <r​ucknium:monero.social> With the FCMP code, are there any major changes to `monero-wallet-rpc` RPC calls? Accounts can still be used, right?
14:48:02 <m-relay> <o​frnxmr:monero.social> should be the same
15:55:27 <m-relay> <r​brunner7:monero.social> Yes, pretty sure that there are only minor changes. Accounts as an important feature certainly stand. Surprisingly, they are in large parts a wallet-side feature, with the bookkeeping done in a way to keep them separate, almost like "sub-wallets". Seraphis would have brought larger changes there however.
16:10:32 <m-relay> <r​ucknium:monero.social> I remembered the Seraphis accounts conversation.
16:10:33 <m-relay> <r​ucknium:monero.social> I need accounts because my stressnet spammer uses them.
16:15:39 <m-relay> <1​7lifers:matrix.org> will this be the update that will cause the unmaintained mymonero wallet to stop working
16:33:07 <m-relay> <r​brunner7:monero.social> Well, if it's really unmaintained, then certainly. As far as I know it's not exactly trivial for MyMonero to "learn" FCMP++, especially the web wallet, if they really want to continue that as well.
16:48:52 <m-relay> <j​effro256:monero.social> The only difference I can think of is for hot/cold wallets. You can't retrieve transaction ephemeral private keys for send proofs by its TXID anymore since the cold wallet doesn't know the TXID at time of signing. You have to retrieve it by its "signable transaction hash".
16:49:13 <m-relay> <j​effro256:monero.social> Light wallets are going to have to use new RPC endpoints for FCMP++ transaction construction to fetch FCMP path information for outputs.
17:24:11 <m-relay> <k​ayabanerve:matrix.org> rbrunner7: My FCMP++ code can compile to WASM.
17:27:48 <m-relay> <v​tnerd:monero.social> The problem is the backend needs updating, and it's closed source and not sure what to do about all that
17:28:34 <m-relay> <k​ayabanerve:matrix.org> Oh, of course. I'm just noting it wouldn't have to be rewritten. Just integrated.
17:29:08 <m-relay> <v​tnerd:monero.social> It's not that simple in any case. The lwsf project is kind of trying to wrangle all that in
17:29:09 <m-relay> <k​ayabanerve:matrix.org> If the FCMP wouldn't prove on WASM, they'd have to add proving to their back end OR rewrite it.
17:31:46 <m-relay> <j​effro256:monero.social> Does MyMonero backend expose a node ?
17:32:26 <m-relay> <j​effro256:monero.social> Because if they simply update monerod , then the light wallet clients can merge in FCMP++ code and fetch paths from the daemon
17:33:04 <endogenic> that'd be trivial
17:33:11 <endogenic> to expose a lws api endpoint
17:33:48 <m-relay> <j​effro256:monero.social> Yeah that would work if it just acted as a proxy to the daemon for that specific request
18:08:13 <m-relay> <k​ayabanerve:matrix.org> Not like they need to local tree build if already giving out view keys
18:22:30 <m-relay> <k​ayabanerve:matrix.org> Eh. Something something detection of received outputs != knowledge of when spent, yadayadaya