<s​yntheticbird:monero.social> meeting today?

<s​needlewoods_xmr:matrix.org> yes monero-project/meta #1373

<r​brunner7:monero.social> Meeting in 1 hour

<r​brunner7:monero.social> Meeting time. Hello! monero-project/meta #1373

<j​pk68:matrix.org> Hello

<s​needlewoods_xmr:matrix.org> hey

<v​tnerd:monero.social> Hi

<k​oe000:matrix.org> Hi

<j​berman:monero.social> *waves*

<r​brunner7:monero.social> Alright, let's proceed to the reports from last week. Me: Made good progress implementing Polyseed in the CLI wallet

<s​yntheticbird:monero.social> Hi

<k​oe000:matrix.org> Me: not much done. Started mapping multisig changes required. Reconstructing the signed message will be most painful.

<s​needlewoods_xmr:matrix.org> added all new Wallet API changes from the wallet-rpc work to [#9464](monero-project/monero #9464)

<s​needlewoods_xmr:matrix.org> rebased [#10232](monero-project/monero #10232) onto that and [#10233](monero-project/monero #10233) and the wallet-rpc onto #10232

<r​brunner7:monero.social> Quite a number of balls in the air that you juggle there now :)

<j​pk68:matrix.org> I have been researching SAM protocol parameters (encryption type, etc.)

<j​pk68:matrix.org> Sadly, post-quantum support is not ready yet

<r​brunner7:monero.social> That's for I2P, right?

<j​pk68:matrix.org> Yes

<j​berman:monero.social> 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)

<r​brunner7:monero.social> Yeah, I wonder also how many real locks have sneaked in since we don't propagate them anymore

<s​needlewoods_xmr:matrix.org> I think I'll mark the PRs to release as draft, until master is somewhat settled, I haven't updated those in a while

<r​brunner7:monero.social> It seems Wallet API will need a couple of new methods to support Polyseed ...

<j​berman:monero.social> Also merged some PR's from a new contributor JeetRex 🎉 github.com/seraphis-migration/moner…state%3Aclosed%20author%3Ajeetrex17

<r​brunner7:monero.social> Oh, nice

<i​amnew117:matrix.org> Thank s

<i​amnew117:matrix.org> A little intro about myself

<i​amnew117:matrix.org> I am an 3rd year college student studying mathematics and computation from india

<r​brunner7:monero.social> Careful, contributing to Monero can become a veritable addiction :)

<j​berman:monero.social> Welcome! :)

<i​amnew117:matrix.org> Very true

<i​amnew117:matrix.org> There is soo much to learn

<s​yntheticbird:monero.social> Welcome, hope you'll continue to enjoy

<r​edsh4de:matrix.org> can confirm

<r​brunner7:monero.social> 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:

<r​brunner7:monero.social> I wonder how "aggressive" the Polyseed capable CLI wallet app should promote that when creating a new wallet

<j​effro256:monero.social> Howdy sorry I'm late

<r​brunner7:monero.social> Basically, I see 3 possibilities:

<r​brunner7:monero.social> 1) Ask interactively when creating the wallet whether you want Polyseed instead of "classic" seed

<r​brunner7:monero.social> 2) Silently default to Polyseed, unless a startup command line parameter lie `--polyseed` is given

<r​brunner7:monero.social> Oh, no, that would be of course `--classic seed` for 2

<r​brunner7:monero.social> 3) Silently default to "classic seed", like now, unless `--polyseed` is given

<s​yntheticbird:monero.social> 1. and you say that Polyseed is ✨️Recommended✨️

<s​needlewoods_xmr:matrix.org> gut feeling says nr 2

<k​oe000:matrix.org> What would be the reason to use the classic seed?

<k​oe000:matrix.org> Why would someone use it instead *

<j​berman:monero.social> Silently defaulting to polyseed I think is reasonable. Including the birthday height in the seed as default is a major +1 for noobs

<r​brunner7:monero.social> Principle of "least surprise", for people who already use the CLI wallet for a long time maybe?

<r​brunner7:monero.social> I wonder how many "noobs" use the CLI wallet app

<s​needlewoods_xmr:matrix.org> I do

<j​berman:monero.social> "new users" probably a better term here

<j​pk68:matrix.org> I feel like defaulting to Polyseed could ostensibly cause some confusion when trying to restore

<r​brunner7:monero.social> Yeah, you are the role model of a noob, right :)

<s​yntheticbird:monero.social> i'm sorry to inform you that you aren't a noob SNeedlewoods

<j​effro256:monero.social> I vote for 2 since it can prevent situations like this: 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

<j​effro256:monero.social> How so?

<i​amnew117:matrix.org> I vote for 2 has well

<s​needlewoods_xmr:matrix.org> was half joking

<j​effro256:monero.social> We already support multiple seed types with automatic detection

<r​brunner7:monero.social> Yes, right now I don't see any problem with restoring.

<j​pk68:matrix.org> Oh yeah, forgot about the automatic thing

<s​yntheticbird:monero.social> 2. then

<j​pk68:matrix.org> The intersection of people who use the CLI and don't know the difference between seed types is also probably quite limited anyways

<j​pk68:matrix.org> The intersection of people who use the CLI, yet don't know the difference between seed types is also probably quite limited anyways

<r​brunner7:monero.social> Internally, I just throw the seed at the Polyseed code. If it says "ok", all is well, and it's of course a Polyseed

<r​brunner7:monero.social> 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

<r​brunner7:monero.social> Ok, looks like we have "loose consensus" for 2. That's good, one more question for restoring isn't really good UX anyway, no?

<r​brunner7:monero.social> Er, no, for creating of course.

<r​brunner7:monero.social> As I said restoring is ok

<k​oe000:matrix.org> Can label the seed type to reduce confusion

<r​brunner7:monero.social> Yes, the wallet will clearly show you the type with the `seed` command, and maybe also with `wallet_info`

<r​brunner7:monero.social> It's understood, you really want anything going wrong with seeds.

<r​brunner7:monero.social> Especially if you are nervous already anyway, having to restore, and not yet knowing whether you will ever see your beautiful XMR again :)

<r​brunner7:monero.social> jeffro256: Anything interesting to report from your side?

<r​brunner7:monero.social> Maybe already back to coding, the good man

<j​effro256:monero.social> There's some vulnerability work I can't reveal rn

<r​brunner7:monero.social> Ok, understood.

<r​brunner7:monero.social> Do we have to discuss something else today?

<j​effro256:monero.social> Also working on setting up a framework for testing Ledger firmware for the FCMP++ migration

<s​needlewoods_xmr:matrix.org> there is [this](monero-project/monero #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<clipped

<s​needlewoods_xmr:matrix.org> 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`

<j​effro256:monero.social> Also just doing review / prep for Beta stressnet

<r​brunner7:monero.social> 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

<r​brunner7:monero.social> Is that data too complex for that?

<s​needlewoods_xmr:matrix.org> that's probably the way to go

<r​brunner7:monero.social> Is that needed somewhere? Which type of client would work with that data?

<j​effro256:monero.social> You can do what the FCMP++ integration does with FCMP++ proofs: just pass around a variable length byte buffer

<s​needlewoods_xmr:matrix.org> it is just very rarely used (0 times in simplewallet, 1 time in wallet-rpc)

<s​needlewoods_xmr:matrix.org> github.com/monero-project/monero/bl…/wallet/wallet_rpc_server.cpp#L1474

<j​effro256:monero.social> Opaque to the caller, so only implementor decodes it in practice

<s​needlewoods_xmr:matrix.org> will look into that, thanks

<j​effro256:monero.social> `tools::wallet2::tx_construction_data` already has serialization code, so you can reuse that

<r​brunner7:monero.social> Yeah, that RPC server method linked does exactly that: Looking at many info in there, to "describe" the transfer.

<r​brunner7:monero.social> Looks like a tough nut to crack

<r​brunner7:monero.social> Will try to have a closer look in the coming days

<s​needlewoods_xmr:matrix.org> I'm also getting the "Error loading page" now, which I think koe reported the other day

<r​brunner7:monero.social> Tying to load what?

<r​brunner7:monero.social> *Trying

<s​needlewoods_xmr:matrix.org> src folder in here github.com/seraphis-migration/monero

<r​brunner7:monero.social> so GitHub not working reliably there? Strange.

<s​needlewoods_xmr:matrix.org> reload works, but need to reload every time you change the page ... whatever, I have nothing else to discuss for this meeting

<j​berman:monero.social> I get that error sporadically as well now

<r​brunner7:monero.social> That cries out for some nice conspiracy theory :)

<r​brunner7:monero.social> Alright, I think we can close for today. Thanks everybody for attending, read you again in 1 week!

<s​needlewoods_xmr:matrix.org> thanks everyone, see you

<s​yntheticbird:monero.social> thanks

<j​pk68:matrix.org> Thanks

<o​frnxmr:monero.social> Polyseeds can also be converted to legacy (25 word) seeds, so..

<o​frnxmr:monero.social> 2 birds, 1 stone

<o​frnxmr:monero.social> 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

<o​frnxmr:monero.social> And can yeah.. can probably a flag on generation for `--seed-type=legacy` etc?