<jberman> this seems ok, considering polyseed_decode returns an error if something decodes as multiple langs: tevador/polyseed #12 > <@rbrunner7> That can be done with a few lines of code: Generate a new Polyseed at random, see whether the language can be decided automatically, if not generate a new Polyseed at random, until success.

<jberman> I think worth checking if you need to trim the seed phrase when trying to decode (I think you do, don't have the exact code in front of me)

<jberman> the seed phrase words*

<rbrunner7> Yes, there is support for detecting ambigous seeds, it was one of the most recent changes of Tevador. Not sure what you mean with "trim the seed phrase", but it probably does not matter :)

<rbrunner7> Meeting in a bit less than 1 hour

<jberman> @rbrunner7: this should clarify tevador/polyseed #11

<rbrunner7> Meeting time. Hello! monero-project/meta #1412

<sneedlewoods_xmr:matrix.org> Hi

<jberman> waves

<jpk68:matrix.org> Hello

hi

<rbrunner7> So, what are the reports from last week?

<rbrunner7> I could make an update for my Polyseed PR. Most things are now either addressed, or waiting for some clarifications and/or opinions from reviewers.

<sneedlewoods_xmr:matrix.org> Made a PR for the wallet-rpc monero-project/monero #10819

<sneedlewoods_xmr:matrix.org> Started reviewing the Polyseed PR by rbrunner7

<sneedlewoods_xmr:matrix.org> Preparing a new CCS proposal and planning to include potentially work on restore height issues, would like to hear if anyone has any thoughts on this?

<sneedlewoods_xmr:matrix.org> (besides: a) work on Wallet API, walllet-cli and wallet-rpc review comments and b) do reviews / help out where I can)

<sneedlewoods_xmr:matrix.org> so the proposed tasks currently look like this:

<sneedlewoods_xmr:matrix.org> mrelay.p2pool.observer/p/9u-t8JELTkhrQ2wt/1.txt (code snippet, 10 lines)

<sneedlewoods_xmr:matrix.org> Last meeting jeffro256 said that ideally all the Wallet API changes could make it into v0.19, for that I would need to rebase the API/CLI/RPC changes onto the polyseed PR AFAICT, do you think that is also a task worth to add to the CCS proposal?

<jpk68:matrix.org> Finished the first milestone of my CCS for I2P work, having to do with the core daemon implementation

<rbrunner7> Nice milestone again, @sneedlewoods_xmr:matrix.org !

One thing that I just remembered, wallet_api apparently has some bugs with refresh thread oxen-io/oxen-core #1466

this should be investigated and fixed on our side before we switch all wallets to it.

<jberman> me: finished reviewing @jeffro256:monero.social 's mega hot-cold PR for FCMP++/Carrot, believe we now solved @rucknium:monero.social sporadic double spend issue and will finalize an upstream PR for that today ( seraphis-migration/monero #365#issuecomment-4811722029 ), and I'm going to have all upstr [... too long, see mrelay.p2pool.observer/e/-fS58JELbW03SnU4 ]

<rbrunner7> Good find. Maybe we corrected already on our side some time in the 5 years since then

<rbrunner7> (to selsta)

I don't think this ever got fixed on our side.

<jberman> selsta: fwiw the new FCMP++ changes introduce a new refresh lock internally to wallet2

<jpk68:matrix.org> jberman: Out of curiosity, does the 6x faster zero commit speed up anything besides FCMP++ crypto? As in, would it provide any speed improvement currently

<jberman> @jberman: though it shouldn't hurt to fix the API's lock handling also

<rbrunner7> Making sure @sneedlewoods_xmr:matrix.org is not running out of work anytime soon :)

<jberman> @jpk68:matrix.org: yes, that function is currently used at consensus for coinbase outputs and for pre-RCT outputs. It's not a major bottleneck in current syncing, but it would marginally help syncing

<rbrunner7> What is a "zero commit"?

<jpk68:matrix.org> I have the same question :D

a commitment to the amount of 0, using Mask as `

as 1*

<rbrunner7> Some "no money out of thin air" thing then?

mask scalar = 1, amount = 0 which as jberman is used in special cases like coinbase

<jberman> when an output has a transparent amount, you calculate its commitment as amount * H (H is a generator specific to Monero)

which has public amounts

<jberman> it's necessary so that transparent amount outputs can be used as inputs in future txs enabling you to construct a tx where sum of inputs == sum of outputs while still blinding amounts

<jberman> it becomes more relevant in FCMP++ because all outputs' commitments are stored in the curve tree, which both the daemon and wallet build

<jberman> so speeding this up has a more tangible impact on both wallet and daemon sync speed with FCMP++

<rbrunner7> Next step up will be curve forest .. you read it here first ...

<rbrunner7> Ok, ok, interesting reports. Do we have to discuss something beyond those today?

I can only advertise again that we need reviews for v0.18.5.1 monero-project/monero #10545

all have at least one review but need a second before merge

<rbrunner7> Will try to have a look, now with my PR update out of the door

<jberman> can review those 2 by tomorrow as well

<jberman> those 3*

<rbrunner7> You will probably overtake me then :)

<rbrunner7> Alright, looks like we are through. Thanks everybody for attending, read you again in 1 week!

<sneedlewoods_xmr:matrix.org> thanks everyone