re: 8566 - reworking is fine. but the release branch should never be ahead of master branch, developmentally

and while I see 8568 is the corresponding PR for master (is it even up to date with 8566 now?)

there's #8617 which depends on 8566, and no corresponding master PR

this is upside down and backwards.

development should be on master. looks like 8617 has been developed entirely on release-0.18.

might also be good to have the PR comments on master and referenced from release instead of the other way, because anything that goes into master lives forever (a little less indirection for future git blames)

My mistake. Will stick to master development going forward

"is it even up to date with 8566 now?" -> no, not after the latest commit. Will update and keep it updated

updated

I'm seeing that key images are not returned from `incoming_transfers` with a multisig wallet which needs updated multisig hex from its peers. however, the wallet correcty reports that the outputs are sepnt, so maybe it does know key images of the spent outputs and it's not being passed back correctly?

for example, this is a response from `incoming_transfers`. the wallet knows the outputs are spent, but the key images are missing. I need to know if the spending tx is published, confirmed, or unlocked:

`{"amount":230000000000,"block_height":7910,"frozen":false,"global_index":13380,"key_image":"","pubkey":"03a68431d183bbac298fc9ffa4c724a229ad1a3075de110e38ab695c48edb7bf","spent":true,"subaddr_index":{"major":0,"minor":0},"tx_hash":"99977fe75d8afa31b4c272294be51c81b6da3ebc6fd4acfe067168f41b38515c","unlocked":true}`

Do I have a blackout, or is the CLI wallet really lacking a command that shows the balance of a wallet over *all* accounts?

I'm fairly sure "balance" gives a total.

Though I do not use those much, but I'm... fairly... sure I remember a total... Though that's so obvious that I'm thinking I muist be misremembering if you're asking :S

Before I tried I also would have sweared there must be a way, but now I can't find it, and "balance" sure tells you in its first output line which account it lists for ...

balance shows all my accounts

?

In the CLI wallet, right?

yeahh, that's the only one I use

And for you the first output line after "balance" is not the name of the currently selected account?

lemme look

Currently selected account: [0] Primary account

Yes. Now switch to the second account and then "balance" again

oh, ok. the balance command only shows the current account

In fact, I have yet to find a single command that spans more than the currently selected account. Maybe sweep_all, but I don't want to try that.

but when you fire up the wallet it shows all accounts

Ah, yes, you got it, there it is, the view we probably all remember

Is there a command that reproduces that initial display?

dunno

seems not

I just became aware today that technically we are completely free whether to again implement accounts for Seraphis, or not. I for one have doubts about them, given how it complicates everything internally

And maybe it wants to tell us something that the CLI wallet still seems the only one fully implementing them.

Oh, right, total of all addresses on current account. Makes sense...

Yes, but only if you take accounts so seriously as the CLI wallet does, as strict sub-wallets in a way.

If you have wallets, and your wallet app has a good UX to easily create new ones and switch between them, who needs something like sub-wallets?

Of course the added possibilities are not zero, but I do worry about the trade-off "added flexiblity and possibilities" versus "more complicated implementation, more complicated UI/UX"

"account" with no args gives the full list

Right, thanks, so I did have a blackout when I did not find that :)

"help account" shows nicely all the "infrastructure" needed to support the feature. It's quite heavy.

rbrunner: the main advantage is less scanning with one wallet and multiple accounts vs multiple wallets

the secondary advantage is fewer seeds to keep track of

Hmmm, good argument about the scanning. If we internally add scanning over whole groups of wallets, to counter that disadvantage, we will complicate again.

I think one sort of complications with accounts as they are now starts when you have to chose enotes for a tx, and want to allow them only from 1 account

I think the goal should be to keep address organization details outside of the core seraphis wallet components, so any 'complications' can be isolated and optional.

Even if you want to influence them tx construction?

rbrunner: tbh that should be pretty easy, just add a filter in the input selector (easy for O(N) input selection, more work for O(1)); the input selector is already an injected dependency

guess that's one of the details for monday :)

I also worry about UX. If we have wallet apps that do this in quite different way, that may be confusing for users who switch.

If somewhere in the codebase there is code to implement a sane proposal already, this will nugde wallet app writers towards that, which will result in standardization

Well there should only need to be 3 main schemes, one with accounts, one with ‘one account’ and one with custom indexing (eg for merchants to define personal indexing schemes).

But yeah, maybe the core Seraphis wallet component is not the right place for that

It's not dramatic, but I still see it as a failure in current Monero that we only have such limited support for accounts in out wallets. Maybe we will be able to improve on that with Seraphis.

*our

Anyone know if this vulnerability is still present in Monero's multisignature wallet code?

layter[m]: they were fixed

UkoeHB: Well, that's a relief 😅

I was curious because someone mentioned that when using Monero v0.18.1.2 binaries, using any mms command gives the following warning:... (full message at <libera.ems.host/_matrix/media/r0/do…f185c4fa292d0f2720d9f23db2486ab958d>)

layter[m]: the known issues were fixed but the experimental opt-in thing was added so people are aware that no guarantees are made about unknown flaws existing

UkoeHB: I see

Thanks for clarifying

Always fun. We may want to have our eyes out for a patch to our keccak lib. I'm not entirely sure the impl family tree there.