03:20:37 <hyc> -O2 omits frame pointers. you should use -O0 if you want usable stack traces
03:21:04 <hyc> "usable" is relative of course. reading these C++ stack traces is torture
03:35:31 <selsta> .merge+ 8046
03:35:31 <xmr-pr> Added
05:09:59 <selsta> kayabaNerve: is there anything to do here or should I add it to the merge queue? https://github.com/monero-project/monero/pull/8277#pullrequestreview-958489737
05:19:49 <moneroextremist[> hello monero dev team
05:23:09 <kayabanerve[m]> <selsta> "kayabaNerve: is there anything..." <- Should be good given mooo's sign off. The only question left would be determining the performance difference as a good to have which can be done later since this is a more of a design decision
05:23:40 <selsta> ty
05:23:45 <selsta> .merge+ 8277
05:23:45 <xmr-pr> Added
05:34:10 <moneroextremist[> hey monero dev team
05:34:38 <moneroextremist[> i want to say thank you for your hard work
05:34:52 <moneroextremist[> thanks for working hard
08:49:04 <selsta> .merges
08:49:04 -xmr-pr- 8046 8220 8226 8235 8262 8277 8278 8279
18:38:06 <charuto> are there still plans to encode restore height into the mnemonic seed?
18:38:37 <charuto> i found the github issue regarding it but it hasn't been discussed there since 2021
18:40:41 <UkoeHB> charuto: jamtis will do that, not sure about before then
18:41:43 <charuto> thank you, i will take a look
18:43:49 <charuto> one concern i had with proposals that reduced number of words was that it'd restrict the domain of private keys and make it considerably easier (albeit still impossible with current tech) to brute-force a valid wallet.
18:44:01 <charuto> but maybe this concern is unfounded, i never looked too much into it.
18:47:22 <w[m]> charuto: Its reletive to the size of the wordlist as well
18:47:22 <w[m]> I dont recall the size of current vs jamtis wordlist
18:52:29 <charuto> yes i am aware. but if i'm not mistaken by doubling the wordlist it would only be possible to remove a single bit of information from the mnemonic seed, words store much more than a single bit of information, it seems incredibly difficult to reduce the number of words from 25 to, for example 16 without reducing the domain of private keys.
18:53:12 <jeffro256[m]> You're close but not entirely correct
18:53:46 <jeffro256[m]> The number of seed combinations is the size of the wordlist to the power of how many words
18:58:27 <jeffro256[m]> So if the seed went from a word pool size of 1000 -> 2000 (made up nunbers) and from a length of 20 -> 19, that would make the new seed scheme have around 9 bits less of entropy compared to the 199 bits it had before 
18:59:31 <jeffro256[m]> So I guess the space is reduced ~512x but when it's that large, it doesn't matter too much
19:02:03 <jeffro256[m]> charuto BTW are you talking about Jamtis? Are they really changing the length to 16? That's quite a jump
19:02:18 <charuto> no i was taking polyseed as an example
19:02:19 <charuto> https://github.com/tevador/polyseed
19:02:40 <UkoeHB> jamtis would use polyseed
19:03:58 <charuto> i understand the added user convenience but i do worry about the loss of entropy
19:07:42 <jeffro256[m]> So we're going from  256 bits entropy to 150 bits ?
19:11:25 <charuto> looks like it (?)
19:11:45 <charuto> roughly 10^45 different seed combinations
19:35:21 <UkoeHB> it seems reasonable, considering ed25519 has a 128-bit security level
19:52:37 <jeffro256[m]> UkoeHB I'm sure that someone smarter than me has thought about this but with the BP paradox, doesn't that make the exoected # w/o collisions about 2^75 ? This is well within the realm of a realistic collision as Bitcoin cumulative diffiulty is around ~2^93  currently
19:55:49 <jeffro256[m]> But the difference between 2^75 and 2^128 is 9007199254740992x
20:00:57 <jeffro256[m]> That just seems a little small for my comfort IMO
20:35:19 <UkoeHB> that's 2^75 to find a collision, not to find a collision with some other user's seed
20:40:38 <jeffro256[m]> Yeah I know, but just the fact that finding any collision is possible by throwing a few million dollars at the problem is rather unsettling. Couldn't the Jamtis proposal could be modified to be seed-agnostic relatively easily?
20:43:42 <jeffro256[m]> The jamtis proposal could have an "abstract seed" which would satifsy the entropy of any possible party involved, for examlple 512-bits 
20:44:30 <jeffro256[m]> If your real seed is smaller than that, you can just pad it, if it's bigger, you can hash down to it
20:47:19 <jeffro256[m]> But then again that might create a UX nightmare
21:02:14 <UkoeHB> I suppose that's a question to bring up with tevador. I don't plan to go as far as implementing seed/entropy recover, so it's out of my hands anyway
21:02:23 <UkoeHB> recovery*
21:24:21 <wernervasquez[m]> jeffro256: I think you have valid points. But another relevant question, hinted at by UkoeHB , is if you performed 2^75 attempts, what percentage of the search space is actually someone else's seed (rather than a seed you generated)?
21:25:40 <LyzaL> tobtoht I wonder if u have thoughts on this I know feather uses a 14 word mnemonic similar to polyseed ^^
21:25:42 <wernervasquez[m]> But, I would personally prefer to have the maximum amount of entropy available.
21:27:05 <LyzaL> it seems like it should be easy to support 25/26 word seeds if we want to, feather supports both, and from what I understand the 14/16 word seeds get converted to a traditional private key anyway
21:27:55 <LyzaL> and I guess need to support importing 25 words anyway for legacy reasons, so may as well let people generate them
21:31:39 <jeffro256[m]> wernervasquez Oh yeah definitely not a lot but i think Jamtis should definitely keep supporting legacy seeds
21:31:49 <jeffro256[m]> If only for backwards compatibility reasons
21:32:50 <jeffro256[m]> Maybe the Jamtis seed generator could reserve idk ~4 bits for different types of seeds