00:45:26 re: 8566 - reworking is fine. but the release branch should never be ahead of master branch, developmentally 00:46:37 and while I see 8568 is the corresponding PR for master (is it even up to date with 8566 now?) 00:46:55 there's #8617 which depends on 8566, and no corresponding master PR 00:47:33 this is upside down and backwards. 00:50:11 development should be on master. looks like 8617 has been developed entirely on release-0.18. 00:56:28 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) 04:18:42 My mistake. Will stick to master development going forward 04:18:44 "is it even up to date with 8566 now?" -> no, not after the latest commit. Will update and keep it updated 04:37:37 updated 13:10:01 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? 13:43:27 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: 13:43:28 `{"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}` 18:19:43 Do I have a blackout, or is the CLI wallet really lacking a command that shows the balance of a wallet over *all* accounts? 18:20:11 I'm fairly sure "balance" gives a total. 18:21:09 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 18:22:18 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 ... 18:24:03 balance shows all my accounts 18:24:07 ? 18:24:52 In the CLI wallet, right? 18:25:41 yeahh, that's the only one I use 18:26:10 And for you the first output line after "balance" is not the name of the currently selected account? 18:26:25 lemme look 18:26:58 Currently selected account: [0] Primary account 18:28:01 Yes. Now switch to the second account and then "balance" again 18:29:35 oh, ok. the balance command only shows the current account 18:29:40 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. 18:29:47 but when you fire up the wallet it shows all accounts 18:30:25 Ah, yes, you got it, there it is, the view we probably all remember 18:31:10 Is there a command that reproduces that initial display? 18:31:22 dunno 18:32:43 seems not 18:33:30 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 18:34:21 And maybe it wants to tell us something that the CLI wallet still seems the only one fully implementing them. 18:35:26 Oh, right, total of all addresses on current account. Makes sense... 18:35:59 Yes, but only if you take accounts so seriously as the CLI wallet does, as strict sub-wallets in a way. 18:37:35 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? 18:39:09 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" 18:40:01 "account" with no args gives the full list 18:40:41 Right, thanks, so I did have a blackout when I did not find that :) 18:42:28 "help account" shows nicely all the "infrastructure" needed to support the feature. It's quite heavy. 18:44:47 rbrunner: the main advantage is less scanning with one wallet and multiple accounts vs multiple wallets 18:45:06 the secondary advantage is fewer seeds to keep track of 18:46:23 Hmmm, good argument about the scanning. If we internally add scanning over whole groups of wallets, to counter that disadvantage, we will complicate again. 18:48:01 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 18:48:31 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. 18:49:19 Even if you want to influence them tx construction? 18:49:40 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 18:50:36 guess that's one of the details for monday :) 18:51:44 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. 18:52:49 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 18:53:26 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). 18:53:31 But yeah, maybe the core Seraphis wallet component is not the right place for that 18:57:37 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. 18:57:57 *our 20:15:56 Anyone know if this vulnerability is still present in Monero's multisignature wallet code? 20:15:57 https://www.getmonero.org/2021/12/06/vulnerability-multisig.html 20:37:58 layter[m]: they were fixed 20:38:54 UkoeHB: Well, that's a relief 😅 20:47:17 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 ) 20:50:42 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 20:52:17 UkoeHB: I see 20:59:00 Thanks for clarifying 23:28:49 https://nvd.nist.gov/vuln/detail/CVE-2022-37454 23:28:50 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.