02:10:38 <sarang> Looks like test CI breaks on current master?
06:01:39 <selsta> sarang: 6637
09:54:03 <philogy> why aren't  transaction keys created deterministically so that they can be restored/recreated if you have the seed?
10:32:26 <fluffypony> it's been discussed in the past, I suggested the same many many moons ago
10:32:36 <fluffypony> I can't recall what the blockers are to it, or if it opens up an attack
10:33:43 <moneromooo> IIRC the objection I recall was that it was volontary, so someone would not have to follow this system.
10:33:55 <moneromooo> There might have been more objections I do not recall.
10:53:23 <fluffypony> yeah but having a deterministic view and spend key is also voluntary
10:54:02 <dEBRUYNE> We could make it the default and allow for opt-out?
10:54:15 <dEBRUYNE> I have similar thoughts wrt adding another word to encode the restore height
10:54:27 <dEBRUYNE> ^ fluffypony, do you remember what arguments were raised in opposition of that?
10:54:52 <philogy> Would it make sense to open a research-lab issue for the topic?
10:55:40 <fluffypony> I agree on teh restore height thing
10:57:07 <fluffypony> my suggestion was to chunk it into months, so each word is the offset from month 0
10:57:16 <philogy> 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
10:57:16 <fluffypony> of course, this will stop working after 135 years
10:57:52 <philogy> I think in 135 years we won't have to worry about having to remember restoration height
10:58:18 <dEBRUYNE> fluffypony: I will open an issue for it, should it be on -dev or -lab?
10:58:24 <gingeropolous> i think the concern was that the restore height thing would leak information
10:58:34 <fluffypony> I think they're both dev issues, dEBRUYNE
10:58:42 <fluffypony> gingeropolous: if someone gets your seed I think you have bigger problems
10:58:57 <gingeropolous> indeed.
10:59:45 <dEBRUYNE> fluffypony: Oki
11:00:24 <fluffypony> 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
11:07:52 <dEBRUYNE> +1
11:08:06 <dEBRUYNE> philogy: Do you want to open the issue for the deterministic private transaction key?
11:08:55 <philogy> Sure why not, where should I open it? monero-project/monero or monero-project/research-lab?
11:10:32 <dEBRUYNE> monero-project/monero
11:18:39 <philogy> https://github.com/monero-project/monero/issues/6638\
12:10:40 <UkoeHB_> Hmm.. if someone's keys are compromised then all their recipients are compromised as well (the outputs they receive anyway).
12:12:01 <fluffypony> UkoeHB_: if someone's keys are compromised that's a pretty big metadata leak regardless, imho
12:12:02 <fluffypony> (big for anyone they've interacted with)
12:13:55 <selsta> Do we have any bugfixes for v0.16.0.1 apart from Ledger fix?
12:14:07 <moneromooo> Yes.
12:14:25 <moneromooo> I can make a list if you're rounding them up.
12:15:06 <selsta> ty, list would be helpful
12:20:54 <moneromooo> 6584 6587 6588 6597 6599 6611 6627 6629
12:21:08 <moneromooo> All are small fixes.
12:21:37 <moneromooo> Let me know when I should go make release branch versions of mine.
12:26:30 <UkoeHB_> 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).
12:31:30 <selsta> moneromooo: you can open them in the next days or whenever you have time
12:34:29 <moneromooo> ok
12:35:34 <philogy> 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.
12:38:11 <UkoeHB_> 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.
12:40:19 <UkoeHB_> 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.
12:40:59 <UkoeHB_> Afaik, the core wallet already encrypts everything with the private keys
12:42:08 <philogy> UkoeHB_: You make a good point
12:42:17 <philogy> Aren't wallets encrypted using the entered password?
12:42:35 <moneromooo> You'd think so, wouldn't you.
12:42:44 <moneromooo> (and you'd be right)
12:43:10 <moneromooo> Well, the passeword encrypts the keys file, and IIRC the keys encrypt the cache file.
12:43:28 <moneromooo> Tx keys are in the cache file.
12:43:52 <philogy> 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
12:45:59 <philogy> 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.
12:55:31 <fluffypony> I think as long as deterministic tx key optionality remains it's not an issue
12:56:03 <fluffypony> 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
13:01:50 <UkoeHB_> How would the wallet differentiate between sent outputs with deterministic tx private keys, and random ones?
13:06:02 <fluffypony> I don't think it's a per-tx setting
13:06:03 <fluffypony> it's a per-wallet setting
13:06:29 <fluffypony> 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"
13:06:36 <fluffypony> and the next one should match, if it doesn't move on
13:37:53 <dEBRUYNE> fluffypony: https://github.com/monero-project/monero/issues/6639
13:38:02 <fluffypony> tks
13:41:14 <UkoeHB_> '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
13:42:00 <fluffypony> ahhhh subaddresses
13:42:01 <fluffypony> good point
13:42:05 <sarang> Yeah, it's not really clear to me exactly what the goal is here
13:42:27 <fluffypony> sarang: being able to totally recreate a wallet from a single seed
13:42:29 <sarang> One benefit is that it could be a buffer against bad RNG
13:42:33 <fluffypony> including tx history
13:42:50 <sarang> fluffypony: sure, but without destinations stored already, you don't really get a "full restore" in that way
13:42:59 <fluffypony> yeah
13:43:07 <sarang> Now, those could be stored as well
13:43:26 <sarang> for use by the sender in such a case
13:44:18 <dEBRUYNE> fluffypony: Your suggestion basically means that the 26th seed would be non-random right?
13:44:38 <fluffypony> dEBRUYNE: I'd suggest we make it the 25th word, and then the 26th becomes a checksum for the whole thing
13:44:48 <fluffypony> we'd have to rethink the checksum algo
13:45:42 <dEBRUYNE> What would the issue be of simply adding it as the 26th word?
13:45:45 <sarang> Hash the 25 words, take it mod whatever the length of the word list is?
13:45:55 <dEBRUYNE> The wallet could use the first 25 words to do the normal check for validity of the seed
13:46:01 <dEBRUYNE> Then use the 26th word for the restore height 'question'
13:46:36 <moneromooo> If you change that, make the checksum false positive 1/1626, not 1/25.
13:47:16 <moneromooo> And possibly add a first word to mark the seed version (not from the 1626 word list) :)
13:47:28 <sarang> hence the hash approach
13:47:36 <sarang> run against the length of the word list
13:48:17 <fluffypony> I like the hash approach
13:48:29 <fluffypony> but you'd hash the first 3 letters of each word (for the English word list)
13:48:57 <sarang> It's fast and the primitives exist in code already
13:49:45 <sarang> Except for arbitrary modular reduction...
13:50:10 <sarang> unless the SSL libraries are still bundled, which had also been used earlier for certain inversions that are now done natively
13:50:36 <fluffypony> 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
13:50:49 <fluffypony> if there is a future version then it could get an extra word for sure
13:51:07 <sarang> I like the idea that versions are named after a fixed prefix word
13:51:10 <sarang> oh, you have a potato-seed
13:51:34 <sarang> sorry, we only support lawnmower-seeds
13:52:10 <moneromooo> I'm not getting the hash thing. Is this because CRC-32 is too shit ?
13:52:55 <moneromooo> AFAICT we don't really need collision resistance etc.
13:53:11 <moneromooo> (I mean to the level ciphers need)
13:53:47 <sarang> CRC would probably be fine too
13:54:08 <sarang> I was just spitballing an approach generally resistant to collision
13:54:30 <sarang> e.g. there aren't any "correlated changes" that would result in an easy collision that way
13:54:44 <sarang> but if that's not really a concern, then it isn't that important
13:54:52 <moneromooo> OK. I don't really mind which one gets used, but the addition of modular stuff on hashes triggered my overengineering alert :)
13:55:14 <moneromooo> (beyond C's %)
13:55:21 <sarang> Yeah, the more I think about it, the less I like it in practice
13:55:30 <sarang> In theory I love it!
13:56:20 <sarang> Or just use the last N bits of the hash and use a restricted word list
13:56:23 <moneromooo> About the "count one more work" thing: https://github.com/monero-project/monero/issues/6581
14:41:26 <rbrunner> +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.
14:42:07 <sarang> Why a word and not a number?
14:42:21 <rbrunner> 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"
14:42:29 <sarang> If you checksum well, it would be easier for users to differentiate anyway
14:42:44 <rbrunner> *With a first word
14:43:05 <sarang> Is there an advantage to having the version be a word?
14:43:29 <moneromooo> Less confusing to people who might omit it since they're about to copy a word list.
14:43:40 <rbrunner> I think so, yes. Gets recognized for sure as belonging to the seed
14:43:49 <sarang> What about using separate words that aren't from the list?
14:43:59 <sarang> Then a bad parser can't accidentially do the wrong thing
14:44:01 <moneromooo> I'd set the version word to a word that's not otherwise in the words list too, for sync purposes.
14:44:01 <rbrunner> Yes, definitely. To recognize it
14:44:05 <sarang> (unless it's a really bad parser)
14:44:45 <rbrunner> See my "I only entered 25 words, I thought those other words at the end are too much" example: You would recognize that immediately
14:45:30 <rbrunner> Or you have dumb / not yet updated forms on web apps that do not yet allow new seeds
14:45:54 <rbrunner> and only allow 25 words. A new seed would fail there, which is good
14:46:09 <rbrunner> (the first 25 words of it, that is)
14:48:25 <rbrunner> 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
14:48:31 <sarang> Yeah, it should fail loudly
14:49:17 <rbrunner> And I like potato seeds :)
14:50:10 <sarang> It'd be funny to go in ascending alphabetical order, using words that are plants with seeds
14:50:18 <moneromooo> 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...
14:50:47 <rbrunner> True that
14:51:00 <sarang> 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
14:51:16 * sarang is not really serious...
14:52:01 <rbrunner> Well, we could fake it with random version words with only the first 2 letters relevant, not recognizable as "always the same" ...
14:52:08 <sarang> That looks even worse
14:52:18 <sarang> "Oh no, security by obscurity!!"
14:52:35 <rbrunner> Hrmpf ... only devs will ever know, honest
14:52:43 <sarang> famous last words
14:53:21 <rbrunner> No, it's just an idea to guard against the "muppets" that moneromooo mentioned. But maybe not too big a problem, after all.
14:53:56 <rbrunner> On the other hand, every seed (possibly for years) starting with exactly the same word does look and feel a little strange
14:53:56 <moneromooo> 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.
14:54:07 <sarang> It's an easy enough explanation that security doesn't depend on it
14:54:28 <moneromooo> I guess you can make the word "one". Then "two". etc.
14:54:39 <sarang> what about "version1" "version2" etc...
14:54:44 <moneromooo> Still a word, but becomes more obvious it's special.
14:55:02 <sarang> Then you still have "words" that people need to paste in
14:55:34 <UkoeHB_> 'version1' people might think they can ignore that when copy pasting
14:55:39 <rbrunner> 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
14:56:18 <rbrunner> And do not dare to drop it
14:56:20 <moneromooo> Yeah, that's the dumb thing about people. "I assumed it was fine not copying that and going aginst the instructions".
14:56:55 <luigi1111w> there should be some clever options
14:57:02 <luigi1111w> if we think hard and long enough
15:01:38 <rbrunner> 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
15:02:03 <luigi1111w> I prefer to stay as short as possible
15:02:50 <rbrunner> Yeah, ok, if we have the means to reliably detect and reject, after the version word introduction
15:05:00 <luigi1111w> unfortunately the obvious clean solutions involve a new worldlist
15:05:06 <luigi1111w> word too
15:05:38 <moneromooo> Oh, one relevant observation: most metal seed backup systems can only do 24 IIRC.
15:05:54 <moneromooo> So I guess you get 2 and we can play with 48 :)
15:07:36 <rbrunner> Maybe introduce a function "Display metal seed backup seed"? With then only 24 words, but working
15:08:05 <luigi1111w> already exists as electrum seeds I think
15:08:33 <luigi1111w> deprecated
15:08:37 <rbrunner> But not as extra function in our wallets I guess?
15:08:57 <rbrunner> I think they continue to accept 24 word seeds however
15:08:57 <luigi1111w> no but trivial
15:10:07 <rbrunner> 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
15:11:09 <luigi1111w> you can also generate seeds on devices that have no idea what the height is
15:11:16 <luigi1111w> though you could estimate it if their clocks are accurate
15:12:05 <rbrunner> Hmm, yes, this probably needs something that codes "no height"
15:12:33 <rbrunner> Different from 0, so you can ask for the height for example if somebody enters such a seed
15:12:43 <luigi1111w> just give them an old seed?
15:13:38 <moneromooo> You can use 0, since nobody will be generating a new style seed when the chain is new. Since it's already not new.
15:15:12 <rbrunner> 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
15:15:46 <rbrunner> Recognizable by wallets as containing no height (and not height 0)
15:16:02 <luigi1111w> if there's no height then new seeds are negative value
15:16:04 <luigi1111w> extra words for nothing
15:17:13 <moneromooo> Why would you need to distinguish 0 from unknown ?
15:17:16 <rbrunner> 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=
15:18:04 <rbrunner> Well, on second thought, 0 is possible not a valid / not a needed restore height, so you could use that alright
15:22:26 <luigi1111w> I think there should be a solution that involves only 1 extra character
15:23:36 <sarang> To the Unicode standard!
15:24:17 <moneromooo> :/
15:24:26 <luigi1111w> sorry word
15:24:28 <luigi1111w> haha
15:24:54 <moneromooo> Let's ship /usr/share/words/dict
15:29:59 <rbrunner> Did you already the Tari emoji seeds? Wow, that's cool and modern.
15:30:30 <luigi1111w> and seemingly buggy
15:30:37 <rbrunner> I am genuinely curious whether they will keep that. Somehow I doubt. Nice try, but will run into problems
15:30:47 <moneromooo> It's very nice as a visual checksum thing, but I don't like it as a primary thing, it relies on assumptions.
15:31:14 <rbrunner> Buggy?
15:31:19 <moneromooo> Like, I need a font with thousands of shite".
15:34:45 <rbrunner> You already have those on smartphones, too late
15:36:48 <sarang> Are the emoji distinct enough to be able to copy down to paper?
15:37:04 <sarang> And are they common enough to avoid the old "this is just an empty square on my screen" problem?
15:37:58 <moneromooo> 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.
15:38:03 <rbrunner> Those are also my doubt. Together with pretty down-to-earth problems of entering them "by hand" if not available for copy and paste
15:38:21 <sarang> Yeah
15:38:40 <moneromooo> They'll add animated ones soon when they run out of ideas.
15:38:49 <sarang> Say what you will about word-based seeds, but there's no confusion about portability between paper and typing etc.
15:38:50 <moneromooo> Then *gasps* ones with sounds
15:38:50 <rbrunner> But we are not really tempted to copy that, are we?
15:38:56 <sarang> I hope not
15:39:15 <moneromooo> Maybe scriptable ones.
15:48:38 <luigi1111w> I might have some confusion with other languages :P
15:49:52 <luigi1111w> non Latin anyway
15:58:10 <fluffypony> rbrunner: it's a very narrow emoji list
15:58:22 <fluffypony> precisely because of support issues, especially on older devices
15:58:29 <fluffypony> 256 emojis in total
16:01:24 <rbrunner> 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.
16:08:45 <sarang> fluffypony: is a goal of the emoji system to be able to copy them down by hand in a way that's not ambiguous?
16:08:58 <sarang> like "zebra heart smiley..." etc.
16:13:50 <fluffypony> rbrunner: it's a pubkey, not a seed - it's an alternative to your address
16:14:10 <fluffypony> sarang: it's too long for that to be practical, so it's more for a visual check of the address
16:15:35 <sarang> Oh, I assumed this was a seed
16:15:48 <sarang> Nevermind then!
16:34:12 <rbrunner> Alright, my bad, now that you say I remember indeed those are addresses, and not seeds. Still interesting to see whether they will stand.
16:35:43 <sarang> I do wonder about portability
16:45:34 <sarang> Weekly meeting in #monero-research-lab begins at 17:00 UTC (about 15 minutes from now)
16:48:02 <fluffypony> 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
16:48:17 <fluffypony> but also testnet is precisely to uncover issues with stuff like this
16:48:43 <sarang> neat