13:01:15 meeting today? 13:04:45 yes https://github.com/monero-project/meta/issues/1373 16:59:20 Meeting in 1 hour 18:00:01 Meeting time. Hello! https://github.com/monero-project/meta/issues/1373 18:00:06 Hello 18:00:10 hey 18:00:20 Hi 18:01:36 Hi 18:01:37 *waves* 18:02:21 Alright, let's proceed to the reports from last week. Me: Made good progress implementing Polyseed in the CLI wallet 18:02:28 Hi 18:03:35 Me: not much done. Started mapping multisig changes required. Reconstructing the signed message will be most painful. 18:03:38 added all new Wallet API changes from the wallet-rpc work to [#9464](https://github.com/monero-project/monero/pull/9464) 18:03:38 rebased [#10232](https://github.com/monero-project/monero/pull/10232) onto that and [#10233](https://github.com/monero-project/monero/pull/10233) and the wallet-rpc onto #10232 18:04:16 Quite a number of balls in the air that you juggle there now :) 18:05:10 I have been researching SAM protocol parameters (encryption type, etc.) 18:05:19 Sadly, post-quantum support is not ready yet 18:05:46 That's for I2P, right? 18:05:51 Yes 18:06:14 Preparing all code for FCMP++ beta stressnet (aiming to have the code all ready by Wednesday's MRL meeting), PR review, audit followup, drafted a blog post to retroactively deprecate Monero's custom unlock_time (waiting on analysis of blockchain data to finalize) 18:07:06 Yeah, I wonder also how many real locks have sneaked in since we don't propagate them anymore 18:07:26 I think I'll mark the PRs to release as draft, until master is somewhat settled, I haven't updated those in a while 18:08:07 It seems Wallet API will need a couple of new methods to support Polyseed ... 18:08:52 Also merged some PR's from a new contributor JeetRex 🎉 https://github.com/seraphis-migration/monero/issues?q=is%3Apr%20state%3Aclosed%20author%3Ajeetrex17 18:09:16 Oh, nice 18:09:51 Thank s 18:10:45 A little intro about myself 18:10:46 I am an 3rd year college student studying mathematics and computation from india 18:11:06 Careful, contributing to Monero can become a veritable addiction :) 18:11:24 Welcome! :) 18:11:30 Very true 18:11:45 There is soo much to learn 18:11:51 Welcome, hope you'll continue to enjoy 18:12:50 can confirm 18:13:10 Alright, if we are through with the reports, I have a question for the room - not terribly important, but I am curious what other people think: 18:13:32 I wonder how "aggressive" the Polyseed capable CLI wallet app should promote that when creating a new wallet 18:13:39 Howdy sorry I'm late 18:13:42 Basically, I see 3 possibilities: 18:14:12 1) Ask interactively when creating the wallet whether you want Polyseed instead of "classic" seed 18:14:40 2) Silently default to Polyseed, unless a startup command line parameter lie `--polyseed` is given 18:15:15 Oh, no, that would be of course `--classic seed` for 2 18:15:41 3) Silently default to "classic seed", like now, unless `--polyseed` is given 18:15:54 1. and you say that Polyseed is ✨️Recommended✨️ 18:16:01 gut feeling says nr 2 18:17:10 What would be the reason to use the classic seed? 18:17:25 Why would someone use it instead * 18:17:28 Silently defaulting to polyseed I think is reasonable. Including the birthday height in the seed as default is a major +1 for noobs 18:17:39 Principle of "least surprise", for people who already use the CLI wallet for a long time maybe? 18:18:13 I wonder how many "noobs" use the CLI wallet app 18:18:20 I do 18:18:33 "new users" probably a better term here 18:18:36 I feel like defaulting to Polyseed could ostensibly cause some confusion when trying to restore 18:18:38 Yeah, you are the role model of a noob, right :) 18:18:40 i'm sorry to inform you that you aren't a noob SNeedlewoods 18:18:56 I vote for 2 since it can prevent situations like this: https://gist.github.com/jeffro256/4155401274699e0437ba5b79b93c647f. Future key material may need to depend on being hidden from QAs. I don't see any compelling reason to make classic the default. Maybe some paranoid people want the full 256 bits of entropy, but it probably won't make any difference for the average user 18:19:09 How so? 18:19:12 I vote for 2 has well 18:19:16 was half joking 18:19:24 We already support multiple seed types with automatic detection 18:19:39 Yes, right now I don't see any problem with restoring. 18:19:40 Oh yeah, forgot about the automatic thing 18:20:01 2. then 18:20:06 The intersection of people who use the CLI and don't know the difference between seed types is also probably quite limited anyways 18:20:12 The intersection of people who use the CLI, yet don't know the difference between seed types is also probably quite limited anyways 18:20:22 Internally, I just throw the seed at the Polyseed code. If it says "ok", all is well, and it's of course a Polyseed 18:21:00 This approach should even guard against future Polyseed iterations, e.g. with more words for more entropy. Don't have to hard-code 16 for 16 words that way 18:21:57 Ok, looks like we have "loose consensus" for 2. That's good, one more question for restoring isn't really good UX anyway, no? 18:22:16 Er, no, for creating of course. 18:22:31 As I said restoring is ok 18:22:49 Can label the seed type to reduce confusion 18:23:53 Yes, the wallet will clearly show you the type with the `seed` command, and maybe also with `wallet_info` 18:24:26 It's understood, you really want anything going wrong with seeds. 18:25:02 Especially if you are nervous already anyway, having to restore, and not yet knowing whether you will ever see your beautiful XMR again :) 18:26:11 jeffro256: Anything interesting to report from your side? 18:26:57 Maybe already back to coding, the good man 18:27:06 There's some vulnerability work I can't reveal rn 18:27:24 Ok, understood. 18:27:35 Do we have to discuss something else today? 18:27:42 Also working on setting up a framework for testing Ledger firmware for the FCMP++ migration 18:27:44 there is [this](https://github.com/monero-project/monero/pull/9464/changes/30d5a24ecb4bc25d33b246b0ce896da6610144ec#diff-21f483ea6b07b32bd1a19340344df0c12077b7a32a1c2ecd60e6ddfc801aa2dfR543-R550) method, which I added to the Wallet API, that returns a `void*` to get access to `tools::wallet2::tx_construction_data`. I assume that has to change, because `void*` are too low level and shouldn't be part of the API, but I also don't like the alternative to add a getter for each member of construction data that we need just for `on_describe_transfer` 18:27:59 Also just doing review / prep for Beta stressnet 18:29:09 Maybe stupid question, but why not a small struct, or class, to give back that data? I think it's done that way with a number of similar things already there 18:29:28 Is that data too complex for that? 18:30:21 that's probably the way to go 18:30:45 Is that needed somewhere? Which type of client would work with that data? 18:30:46 You can do what the FCMP++ integration does with FCMP++ proofs: just pass around a variable length byte buffer 18:31:01 it is just very rarely used (0 times in simplewallet, 1 time in wallet-rpc) 18:31:15 https://github.com/monero-project/monero/blob/230de379498039b5ca229ab80d4dd04812bb33cd/src/wallet/wallet_rpc_server.cpp#L1474 18:31:22 Opaque to the caller, so only implementor decodes it in practice 18:31:42 will look into that, thanks 18:31:42 `tools::wallet2::tx_construction_data` already has serialization code, so you can reuse that 18:32:47 Yeah, that RPC server method linked does exactly that: Looking at many info in there, to "describe" the transfer. 18:32:55 Looks like a tough nut to crack 18:34:14 Will try to have a closer look in the coming days 18:36:13 I'm also getting the "Error loading page" now, which I think koe reported the other day 18:36:41 Tying to load what? 18:36:48 *Trying 18:37:13 src folder in here https://github.com/seraphis-migration/monero 18:37:46 so GitHub not working reliably there? Strange. 18:39:11 reload works, but need to reload every time you change the page ... whatever, I have nothing else to discuss for this meeting 18:39:14 I get that error sporadically as well now 18:39:32 That cries out for some nice conspiracy theory :) 18:39:50 Alright, I think we can close for today. Thanks everybody for attending, read you again in 1 week! 18:40:08 thanks everyone, see you 18:41:18 thanks 18:43:11 Thanks 23:08:42 Polyseeds can also be converted to legacy (25 word) seeds, so.. 23:08:52 2 birds, 1 stone 23:11:17 I would just default to polyseed, and add a parameter to the `seed` command that defaults to display the polyseed but can accept a value of `legacy` that will show the 25 word equivalent. So `seed legacy` would display the 25 word 23:13:25 And can yeah.. can probably a flag on generation for `--seed-type=legacy` etc?