-O2 omits frame pointers. you should use -O0 if you want usable stack traces

"usable" is relative of course. reading these C++ stack traces is torture

.merge+ 8046

Added

kayabaNerve: is there anything to do here or should I add it to the merge queue? monero-project/monero #8277#pullrequestreview-958489737

hello monero dev team

<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

ty

.merge+ 8277

Added

hey monero dev team

i want to say thank you for your hard work

thanks for working hard

.merges

are there still plans to encode restore height into the mnemonic seed?

i found the github issue regarding it but it hasn't been discussed there since 2021

charuto: jamtis will do that, not sure about before then

thank you, i will take a look

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.

but maybe this concern is unfounded, i never looked too much into it.

charuto: Its reletive to the size of the wordlist as well

I dont recall the size of current vs jamtis wordlist

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.

You're close but not entirely correct

The number of seed combinations is the size of the wordlist to the power of how many words

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

So I guess the space is reduced ~512x but when it's that large, it doesn't matter too much

charuto BTW are you talking about Jamtis? Are they really changing the length to 16? That's quite a jump

no i was taking polyseed as an example

jamtis would use polyseed

i understand the added user convenience but i do worry about the loss of entropy

So we're going from 256 bits entropy to 150 bits ?

looks like it (?)

roughly 10^45 different seed combinations

it seems reasonable, considering ed25519 has a 128-bit security level

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

But the difference between 2^75 and 2^128 is 9007199254740992x

That just seems a little small for my comfort IMO

that's 2^75 to find a collision, not to find a collision with some other user's seed

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?

The jamtis proposal could have an "abstract seed" which would satifsy the entropy of any possible party involved, for examlple 512-bits

If your real seed is smaller than that, you can just pad it, if it's bigger, you can hash down to it

But then again that might create a UX nightmare

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

recovery*

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)?

tobtoht I wonder if u have thoughts on this I know feather uses a 14 word mnemonic similar to polyseed ^^

But, I would personally prefer to have the maximum amount of entropy available.

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

and I guess need to support importing 25 words anyway for legacy reasons, so may as well let people generate them

wernervasquez Oh yeah definitely not a lot but i think Jamtis should definitely keep supporting legacy seeds

If only for backwards compatibility reasons

Maybe the Jamtis seed generator could reserve idk ~4 bits for different types of seeds