Looks like test CI breaks on current master?

sarang: 6637

why aren't transaction keys created deterministically so that they can be restored/recreated if you have the seed?

it's been discussed in the past, I suggested the same many many moons ago

I can't recall what the blockers are to it, or if it opens up an attack

IIRC the objection I recall was that it was volontary, so someone would not have to follow this system.

There might have been more objections I do not recall.

yeah but having a deterministic view and spend key is also voluntary

We could make it the default and allow for opt-out?

I have similar thoughts wrt adding another word to encode the restore height

^ fluffypony, do you remember what arguments were raised in opposition of that?

Would it make sense to open a research-lab issue for the topic?

I agree on teh restore height thing

my suggestion was to chunk it into months, so each word is the offset from month 0

Yeah I hate having to set a relatively old restore height just to be sure I haven't missed any transactions when restoring a wallet xD

of course, this will stop working after 135 years

I think in 135 years we won't have to worry about having to remember restoration height

fluffypony: I will open an issue for it, should it be on -dev or -lab?

i think the concern was that the restore height thing would leak information

I think they're both dev issues, dEBRUYNE

gingeropolous: if someone gets your seed I think you have bigger problems

indeed.

fluffypony: Oki

these are both meaningful UX improvements that we've been bouncing around for a few years, so it's a good time to get them going in earnest

+1

philogy: Do you want to open the issue for the deterministic private transaction key?

Sure why not, where should I open it? monero-project/monero or monero-project/research-lab?

monero-project/monero

monero-project/monero #6638\

Hmm.. if someone's keys are compromised then all their recipients are compromised as well (the outputs they receive anyway).

UkoeHB_: if someone's keys are compromised that's a pretty big metadata leak regardless, imho

(big for anyone they've interacted with)

Do we have any bugfixes for v0.16.0.1 apart from Ledger fix?

Yes.

I can make a list if you're rounding them up.

ty, list would be helpful

6584 6587 6588 6597 6599 6611 6627 6629

All are small fixes.

Let me know when I should go make release branch versions of mine.

philogy: leaking keys just shows which outputs the key owner created, which is significantly less information than who the recipients were and what amounts were transferred (although amounts can be inferred from change outs, especially for 2-out tx).

moneromooo: you can open them in the next days or whenever you have time

ok

UkoeHB_: oh yeah I didn't think of that, maybe that feature could be optional. While there's a risk for recipients some people may really need this feature especially if they regularly have to comply with audits. A transaction key created deterministically from wallet parameters on a hardware wallet for example is much more secure than storing and backing up the restoration keys on a computer or server.

If the concern is audits, then knowing just the tx private key isn't enough. You also need to know recipient addresses. Since you need to store information regardless, I view deterministic tx private keys as not a great advantage in that case.

Also "A transaction key created deterministically from wallet parameters on a hardware wallet for example is much more secure than storing and backing up the restoration keys on a computer or server." -> Just encrypt the tx private keys with the hardware wallet keys.

Afaik, the core wallet already encrypts everything with the private keys

UkoeHB_: You make a good point

Aren't wallets encrypted using the entered password?

You'd think so, wouldn't you.

(and you'd be right)

Well, the passeword encrypts the keys file, and IIRC the keys encrypt the cache file.

Tx keys are in the cache file.

I mean for hardware wallets it would make sense if the actual keys stored on the device would be used for encryption in combination with the password

That would be a really nice feature: for hardware wallets everything is encrypted on the hardware wallet using the private view key, no password required: plug in your device, enter your pin, open the monero gui and you're in.

I think as long as deterministic tx key optionality remains it's not an issue

there's a larger question about what should be the default, but otherwise it could just form part of the inputs when creating a wallet

How would the wallet differentiate between sent outputs with deterministic tx private keys, and random ones?

I don't think it's a per-tx setting

it's a per-wallet setting

but if you tried to break it by having it on for a wallet and then you fudged a tx, the wallet could just go "well the txkey I've generated doesn't match this tx, move on to the next one"

and the next one should match, if it doesn't move on

fluffypony: monero-project/monero #6639

tks

'matching' is the problem, since with subaddress recipients you must know the recipient spend key to test tx private keys against published tx pub keys. R = r*Ks for subaddresses, not r*G

ahhhh subaddresses

good point

Yeah, it's not really clear to me exactly what the goal is here

sarang: being able to totally recreate a wallet from a single seed

One benefit is that it could be a buffer against bad RNG

including tx history

fluffypony: sure, but without destinations stored already, you don't really get a "full restore" in that way

yeah

Now, those could be stored as well

for use by the sender in such a case

fluffypony: Your suggestion basically means that the 26th seed would be non-random right?

dEBRUYNE: I'd suggest we make it the 25th word, and then the 26th becomes a checksum for the whole thing

we'd have to rethink the checksum algo

What would the issue be of simply adding it as the 26th word?

Hash the 25 words, take it mod whatever the length of the word list is?

The wallet could use the first 25 words to do the normal check for validity of the seed

Then use the 26th word for the restore height 'question'

If you change that, make the checksum false positive 1/1626, not 1/25.

And possibly add a first word to mark the seed version (not from the 1626 word list) :)

hence the hash approach

run against the length of the word list

I like the hash approach

but you'd hash the first 3 letters of each word (for the English word list)

It's fast and the primitives exist in code already

Except for arbitrary modular reduction...

unless the SSL libraries are still bundled, which had also been used earlier for certain inversions that are now done natively

moneromooo: I don't think we necessarily need to add a seed version at this juncture, as the extra word implies it's a v2 seed

if there is a future version then it could get an extra word for sure

I like the idea that versions are named after a fixed prefix word

oh, you have a potato-seed

sorry, we only support lawnmower-seeds

I'm not getting the hash thing. Is this because CRC-32 is too shit ?

AFAICT we don't really need collision resistance etc.

(I mean to the level ciphers need)

CRC would probably be fine too

I was just spitballing an approach generally resistant to collision

e.g. there aren't any "correlated changes" that would result in an easy collision that way

but if that's not really a concern, then it isn't that important

OK. I don't really mind which one gets used, but the addition of modular stuff on hashes triggered my overengineering alert :)

(beyond C's %)

Yeah, the more I think about it, the less I like it in practice

In theory I love it!

Or just use the last N bits of the hash and use a restricted word list

About the "count one more work" thing: monero-project/monero #6581

+1 vote for a new first word giving seed version. Anything new with seeds will be a larger change, and if we go through it, why not do it RIGHT.

Why a word and not a number?

With a first version that is reliably recognizable as a version you can also guard about people entering only the first 25 words of a new seed and then stop, because "these were always 25 words"

If you checksum well, it would be easier for users to differentiate anyway

*With a first word

Is there an advantage to having the version be a word?

Less confusing to people who might omit it since they're about to copy a word list.

I think so, yes. Gets recognized for sure as belonging to the seed

What about using separate words that aren't from the list?

Then a bad parser can't accidentially do the wrong thing

I'd set the version word to a word that's not otherwise in the words list too, for sync purposes.

Yes, definitely. To recognize it

(unless it's a really bad parser)

See my "I only entered 25 words, I thought those other words at the end are too much" example: You would recognize that immediately

Or you have dumb / not yet updated forms on web apps that do not yet allow new seeds

and only allow 25 words. A new seed would fail there, which is good

(the first 25 words of it, that is)

Just see our subreddit: Even with exactly ONE type of seed as of now there are regularly people who run into some kind of trouble. We have to be VERY careful changing anything here, and make it as robust as possible

Yeah, it should fail loudly

And I like potato seeds :)

It'd be funny to go in ascending alphabetical order, using words that are plants with seeds

The funny thing about having a common word for all is that you'll get some muppet going around claiming monero seeds are insecure because all seeds have this same word...

True that

You could always turn the tables and brute force a word such that to get the restore height, you hash it and interpret the hash result as a height

Well, we could fake it with random version words with only the first 2 letters relevant, not recognizable as "always the same" ...

That looks even worse

"Oh no, security by obscurity!!"

Hrmpf ... only devs will ever know, honest

famous last words

No, it's just an idea to guard against the "muppets" that moneromooo mentioned. But maybe not too big a problem, after all.

On the other hand, every seed (possibly for years) starting with exactly the same word does look and feel a little strange

Oh, I see no need to guard against that. You can't really guard against dumb, they'll always find something dumber than you expected.

It's an easy enough explanation that security doesn't depend on it

I guess you can make the word "one". Then "two". etc.

what about "version1" "version2" etc...

Still a word, but becomes more obvious it's special.

Then you still have "words" that people need to paste in

'version1' people might think they can ignore that when copy pasting

I have a gut feeling maybe better to really go the other way, to not make it obvious for people that it's special, so they treat it with the same care as all the other words

And do not dare to drop it

Yeah, that's the dumb thing about people. "I assumed it was fine not copying that and going aginst the instructions".

there should be some clever options

if we think hard and long enough

So maybe 1 version word + 24 words with bits for the key + 1 restore height word + 1 checksum word = 27 words. Maybe make 2 restore height words and 2 checksum words to bump it up to 29, to make the "new" seed more obviously new and different

I prefer to stay as short as possible

Yeah, ok, if we have the means to reliably detect and reject, after the version word introduction

unfortunately the obvious clean solutions involve a new worldlist

word too

Oh, one relevant observation: most metal seed backup systems can only do 24 IIRC.

So I guess you get 2 and we can play with 48 :)

Maybe introduce a function "Display metal seed backup seed"? With then only 24 words, but working

already exists as electrum seeds I think

deprecated

But not as extra function in our wallets I guess?

I think they continue to accept 24 word seeds however

no but trivial

Anyway, I think we will have to support the "old" seeds forever, so no problem to offer a well-labelled function to give out the seed in "old" format for whoever may need that

you can also generate seeds on devices that have no idea what the height is

though you could estimate it if their clocks are accurate

Hmm, yes, this probably needs something that codes "no height"

Different from 0, so you can ask for the height for example if somebody enters such a seed

just give them an old seed?

You can use 0, since nobody will be generating a new style seed when the chain is new. Since it's already not new.

Sorry, I don't understand. I was thinking about websites that can generate a random seed for you in any way, which no height in sight. Would be nice to be able to generate "new" seeds there

Recognizable by wallets as containing no height (and not height 0)

if there's no height then new seeds are negative value

extra words for nothing

Why would you need to distinguish 0 from unknown ?

I see what you mean, but wouldn't you want to push "old" seeds into obscurity as fast as you can, everywhere, to limit any possibility of confusion=

Well, on second thought, 0 is possible not a valid / not a needed restore height, so you could use that alright

I think there should be a solution that involves only 1 extra character

To the Unicode standard!

:/

sorry word

haha

Let's ship /usr/share/words/dict

Did you already the Tari emoji seeds? Wow, that's cool and modern.

and seemingly buggy

I am genuinely curious whether they will keep that. Somehow I doubt. Nice try, but will run into problems

It's very nice as a visual checksum thing, but I don't like it as a primary thing, it relies on assumptions.

Buggy?

Like, I need a font with thousands of shite".

You already have those on smartphones, too late

Are the emoji distinct enough to be able to copy down to paper?

And are they common enough to avoid the old "this is just an empty square on my screen" problem?

AFAIK they look different on different fonts. and since unicode has been adding any random useless shite they can think of, there's bound to be confusion.

Those are also my doubt. Together with pretty down-to-earth problems of entering them "by hand" if not available for copy and paste

Yeah

They'll add animated ones soon when they run out of ideas.

Say what you will about word-based seeds, but there's no confusion about portability between paper and typing etc.

Then *gasps* ones with sounds

But we are not really tempted to copy that, are we?

I hope not

Maybe scriptable ones.

I might have some confusion with other languages :P

non Latin anyway

rbrunner: it's a very narrow emoji list

precisely because of support issues, especially on older devices

256 emojis in total

Ah, I don't doubt that much thought and care went into this. Still I think it's easy to underestimate the sheer inertness and variability of the worldwide IT device universe. Plus if a seed goes wrong, people will be royally pissed and very vocal.

fluffypony: is a goal of the emoji system to be able to copy them down by hand in a way that's not ambiguous?

like "zebra heart smiley..." etc.

rbrunner: it's a pubkey, not a seed - it's an alternative to your address

sarang: it's too long for that to be practical, so it's more for a visual check of the address

Oh, I assumed this was a seed

Nevermind then!

Alright, my bad, now that you say I remember indeed those are addresses, and not seeds. Still interesting to see whether they will stand.

I do wonder about portability

Weekly meeting in #monero-research-lab begins at 17:00 UTC (about 15 minutes from now)

sarang: portability has been tested across tons of devices, and we've had to refine the emoji set because of issues - the current set is pretty solid

but also testnet is precisely to uncover issues with stuff like this

neat