00:14:40 Sarang: You commented on the recent reddit post 00:14:41 > Join the research meetings if you are interested in participating in the Monero Research Lab 00:14:59 I'm curious if there's much work that's been done in trying to grow the MRL in that capacity 00:15:05 that is, more public outreach efforts 00:16:25 I did not comment on that post 00:24:34 However, what sort of public outreach do you mean? 00:24:41 ^ needbrrrrrrr90 00:48:18 that was sgp, sorry 00:48:24 And I'm unsure of what kind of outreach 00:48:35 just...I guess bringing the thought up 00:49:05 How can we attract the best and brightest in the crypto space to our little bubble, above how we've been operating currently? 00:50:19 gotta keep the rule of bayes in mind here needbrrrrrrr90 00:52:36 Advertisement rarely brings negative results 00:52:50 The question is how large we can raise the margins :) 00:53:47 If your filter is right 80% of the time and 90% of the people are stupid, then p(stupid|not filter) = p(not filter|stupid)p(stupid)/p(not filter) = 0.2*0.9/(0.2*0.1 + 0.8*0.9) = 24% 00:59:40 needbrrrrrrr90: it's probably more 1 on 1 recruiting than most other marketing efforts 00:59:58 yanmaani: Clearly minimizing exposure is the optimal path, then 01:08:27 Let’s explore that outreach question. In a sentence or two, what benefit would talented developers gain by contributing to Monero as opposed to any other project? 01:08:28 seddd: you here? 01:13:38 The warm fuzzy feeling of helping the species as a whole salvage what remains of its privacy. 01:14:36 Will you choose the Empire or join the Rebel scum ? :D 01:15:01 I hear the Empire has free coffee 01:15:36 Taken by force from poor farmers on Tatooine. 01:18:54 I'm not exactly sure *how* we can attract more researchers, so much as I'm posing the idea to the group 01:19:23 More quality researchers* 01:19:32 Quantity is obviously not a primary goal 01:21:22 Maybe some sort of public bounty contest? Figure out a 10%+ improvement in verification times for 50+ batched txes and get X Monero as a prize, for example 01:22:17 bool verify(transaction tx) return true; 01:25:26 <[keybase] seddd>: needbrrrrrrr90: imho, bounties are almost always a good idea. Found MRL in part through the Vulnerability Disclosure / Hackerone program. 01:26:09 E x a m p l e 01:26:17 * needbrrrrrrr90 rolls eyes at sarang 01:26:39 <[keybase] seddd>: no real ideas for outreach, other than maybe some ramp-up guides for researchers new to the project 01:27:10 An easier path to understanding what being a researcher means could be beneficial 01:28:07 <[keybase] seddd>: something like guides for introducing XMR components, approaches for auditing, no-no's, appreciated work... 01:28:17 needbrrrrrrr90: My intuitive understanding is that bounties sometimes work, but sometimes also create bad incentives 01:28:53 As long as I've started a conversation, my goal is complete :) 01:29:01 <[keybase] seddd>: needbrrrrrrr90: agree, programs have to be designed carefully. 01:29:03 my guess is that it's sort of like a pipeline: it doesn't make sense to draw in random people from the internet 01:29:14 but rather you should try and recruit from the Monero community 01:29:31 I think room exists for wooing researchers from the wider crypto space 01:29:39 from this it emerges with an elegant clarity that you should advertise this channel in #monero's topic 01:29:42 To be blunt, we're small. 01:29:57 <[keybase] seddd>: yaanmani: having independent researchers is also important, to ensure as few blindspots as possible 01:30:33 so right now the head in #monero is this 01:30:43 ... Dev: #monero-dev || Pool related: #monero-pools || Price chat: #monero-markets || Trading: #monero-otc || People can & do log this channel ... 01:31:13 changing this to Research: #monero-research-lab should probably do a bit 01:31:19 or at least putting it in #-dev 01:32:35 I don't think the people who would be interested in MRL stuff who pop into our other channels are unaware of the MRL 01:32:38 But maybe I'm mistake. 01:32:43 Mistaken 01:32:52 I only noticed it because someone mentioned it 01:34:02 Needbrrrrrrr90, I am not asking how, I am asking what would be the benefit to a high quality developer. If we can’t articulate that we’re going to have a hard time figuring out the how question. We have to start with why. Why would a high quality dev choose to spend their limited time on Monero? What would be the benefit to them? 01:34:33 to put it bluntly, you are not going to be able to compete with money, and neither am I very sure it's a good idea 01:35:23 "Mercenaries and auxiliaries are useless and dangerous; and if one holds his state based on these arms, he will stand neither firm nor safe [...]" 01:35:33 For me, the benefit was that I like privacy a lot, and coding something that helps save it beats raging at corps and govts. 01:36:31 The ffs is what made me put so much time in though. 01:37:32 Moneromooo that’s a great start. I imagine that’s a common theme among many here. I wonder if there are other reasons people have? 01:38:02 <[keybase] seddd>: moneromooo: so much this ^ 01:38:13 that. I mean if you just need bodies then you could just advertise "you could get paid money to work on cryptocurrency, we'll hire people without CVs as long as they're competent" 01:38:59 it's just not a good idea to do so. The intended audience ought to be people who would do it anyway, and paying them money to do it full-time 01:40:38 Ideally it would be attracting people who realize the benefits of working on this stuff, or who find it interesting 01:40:58 moneromooo: aren't you admin in #monero? 01:41:06 try doing that and see what happens 01:41:50 I'm not sure if we can sustain paying for a large number of people for research (past coordinators), but should mainly shoot for many people who are self interested and working in their spare timr 01:41:59 s/timr/time 01:41:59 needbrrrrrrr90 meant to say: I'm not sure if we can sustain paying for a large number of people for research (past coordinators), but should mainly shoot for many people who are self interested and working in their spare time 01:42:48 Having coordinators who can buffer knowledge between sessions with various people working sporadically is important 01:43:16 Otherwise you get people who do some research/work and sit in an empty room, because no one else doing work is on at the same time 01:43:47 Having some amount of MRL staff is important, and having multiple (two seems great) doubly so, as they can bounce ideas off each other 01:43:51 Vs talking to themselves 01:44:47 <[keybase] seddd>: needbrrrrrrr90: coordinators could also help independent researchers get better coverage, especially long-term by access to historic reports on w/e components 01:44:49 But I'm not sure what benefit we would get from expanding our payroll, up to the point that our contribution rate is so large that our existing 'staff' is overloaded 01:45:34 Seddd: I've personally tried to define a distinction between coordinators (time commitment) and other actors in our ecosystem 01:46:04 Thinking in those terms has been beneficial to my mental models, but I haven't really found many other people who latched onto the idea 01:46:21 Ive tried to introduce it a few times before 01:46:41 Coordinators being information buffers of a sort 01:47:15 <[keybase] seddd>: maybe a first step could be a set of resources / communication channels to coordinate around, just something to point to (MRL papers being a big one) 01:48:06 https://web.getmonero.org/resources/research-lab/ 01:48:09 ^ 01:48:23 <[keybase] seddd>: or some 'Intro to MRL and Monero security research' 01:48:50 https://github.com/monero-project/monero/#research 01:52:24 Does BP verification time matter for both daemon syncing and wallet scanning? I assume yes? 01:53:56 I am not. Ops (admins) have a @ in front of their nick in the list. 01:55:15 The wallet does not verify proofs. The daemon already did. 01:55:30 Okay, so it only influences daemon sync time? 01:55:41 Yes, for the last bit. 01:56:03 BP verification is skipped for the builtin hashes range, which is most of the chain. 01:56:27 well sometimes they just ask CS to op them temporarily 01:57:05 Ah, true. 01:59:10 <[keybase] seddd>: sarang: thanks. fwiw my experience from finding out about MRL, introducing myself/goals in IRC/keybase, and starting research was really smooth 02:00:06 That's good to hear seddd 03:16:50 It’s worth pointing out that Monero already has the third highest code contributors of all cryptocurrencies, behind only Bitcoin and Ethereum. Perhaps we just need to look more closely at the pool we already have? Or maybe try and influence developers who are most interested in privacy to jump ship from Bitcoin or Ethereum? 03:18:28 Source: https://www.coingecko.com/en?view=developer <—filter list by Contributors 03:20:32 FWIW I also do not think the focus should be on financial incentives. We need to find the right people and give them proper tools to flourish in the ecosystem on their own. 10:09:02 When it says that "v1 coinbases are forbidden" from v.0.15.0.0 on this page https://github.com/monero-project/monero/#research , does this mean the first XMR which was mined cannot be spent in a modern transaction? 10:09:38 or that coinbases can no longer be constructed in a version 1 format? 10:16:10 it's a format enforcement 10:17:10 That's all right then, thanks! 10:23:25 actually afaik pre-ringct miner outputs cant be spent in ringct transactions, they are considered 'mixable' and must be spent in a mixable-to-ringct transition tx 10:25:01 is the transistion tx like a self-spend? 10:26:09 I think you can send to whoever 10:26:31 * UkoeHB_ is not an expert 11:25:01 UkoeHB_ hey, i've not ben paying close attention, but surely any worthy janus mitigation would only require extra EC operations once the existing output detection shows that an output has been received 11:25:34 therefore the scanning time only ever increases in the cases where a particular tx is destined for you, which is going to be a tiny proportion of the time 11:29:10 you need more tx pub keys 11:30:09 UkoeHB_ i'm saying that there are definitely janus mitigations that don't require extra scanning time compared to now, except in the case of txs destined for you 11:30:58 hm I think all of those require a lot more bytes 11:31:49 i'll read more, but i can't imagine it being worth increasing scanning time for janus mitigation 11:32:35 Well the view tag optimization would reduce scan times below current scan times (I think) with or without Janus, although without Janus view tags would be even faster 11:33:13 Also, having more tx pub keys increases tx uniformity, which was favorable to some people (Isthmus and sarang in particular iirc) 11:33:58 if i remember correctly, we know how to do a janus mitigation on a 2-out tx with only 48 extra bytes 11:34:18 i agree for outputs >= 3 we should go for uniformity and put a txpubkey on every output 11:35:10 i don't think the view-tag optimization outperforms current scanning times, if the 48-byte janus mitigation technique is used 11:36:01 I can't recall what the 48-byte mitigation was, can you refresh me? 11:36:03 or link? 11:37:07 Is there any timing data related to scanning? Would be helpful to know how much is from the ec operations specifically 11:40:56 i'm trying to remember, i think it was that you'd provide a 48-byte schnorr signature proving that the shared secret is a scalar multiplication of the correct subaddress public view key C, and on a 2-out tx where the change comes back to you, you only need to provide one such 48-byte proof since you can trust that you're not trying to janus yourself 11:41:27 and that 48-byte schnorr only has to be verified after you've first established that a particular output is destined for you in the normal way 11:42:14 I believe you can test that against suspected destinations 11:42:53 sarang i'll think about it, i'd be interested to know specifically how 11:43:12 since the proof would be on the shared secret, which itself can only be determined by the actual received 11:43:16 receiver* 11:45:13 It sounds reasonable, although Im skeptical about using different mitigations for 2-out vs multi-out tx 11:46:14 it's nearly the same mitigation, isn't it? there would be a 48-byte proof for every single output, except in the case of outputs=2 where there is only one. this is symmetrical with one txpubkey per output, except for 2-out txs 11:47:07 ah I thought you were implying to use the Janus base key method for multi-out, nvm then 11:47:14 ah cool 11:55:48 i as under the impression that in issue #62, since it said "On detection of the output public key P", that the idea did not incur extra scanning time except for the tiny number of outputs that are actually destined for you 11:56:17 and that therefore #62 was an improvement that would use an extra 32 bytes per output instead of 64 11:56:21 or 48 rather 11:56:39 the original idea was like that, but then I found a hole that had to be plugged 11:56:58 ah ok i see, i'll need more caffeine and i'll delve into it, thanks :) 11:57:46 although honestly if we assume a change output with 2-outs then the Janus base key method could also go for single-tx pub key 11:59:05 my concern is the edge cases reducing uniformity 11:59:30 i.e. no change output 12:07:12 i think we should enforce a change output on all txs 12:07:18 my take is Janus base key method is superior (less storage ~16 bytes per tx average, with scanning barely affected [only for multi-outs which need more tx pub keys, relatively rare]) than 48-byte Schnorr, unless we want tx uniformity (can't make change output assumption) in which case it's a tossup between storage and verification (32 bytes avg more per tx with 48-byte Schnorr vs scanning in an extra tx pub 12:07:18 key per tx for Janus base method) 12:08:06 i'm scribbling down issue #62 so i can understand it better 12:08:39 ok, this is most updated version https://github.com/monero-project/research-lab/issues/62#issuecomment-603079784 12:08:51 thx 12:09:50 idk if we could enforce change output, since it would have distinguishable from other outputs 12:10:02 have to be* 12:12:53 although the wallet could force a dummy change output so most 2-outs have change output (i.e. move non-change 2-outs made by the wallet to 3-outs) 12:13:53 i agree you could not consensus-enforce it 12:14:15 hmm although in a way you can 12:14:37 since if there is only one txpubkey allowed on a 2-out tx, then the other output is useless except for change, i think 12:14:55 unless that second output is perhaps also destined for the same person as the first output 12:14:57 ah could be 12:24:59 that might be the best way to go, even setting aside Janus mitigation 12:25:30 UkoeHB_ i'm still not quite awake enough to fully get my head around #issuecomment-603079784. Please could you clarify what the extra byte count would be on a 2-out tx with that proposal? 12:26:16 and it's still the case that the janus detection would still only work if the wallet private spend key is known, and so view-only wallets aren't janus-mitigation-protected? 12:26:41 the standard way would be 64 bytes: 1 Janus base key, then 1 additional tx pub key (since normally we have 1, and now need 2); the way assuming change output is 32 bytes: 1 Janus base key 12:27:00 that's correct 12:27:16 so in the case of 2-out txs: 12:27:54 The 48-byte schnorr proposal would work on view-only wallets, and would add 48 bytes to a 2-out tx, and incur no extra scanning time 12:28:15 The #issuecomment-603079784 proposal would not work on view-only wallets, would add 64 bytes, and incur extra scanning time? 12:29:15 That comparison is a bit off. If we don't assume change output then: 12:29:26 The 48-byte schnorr proposal would work on view-only wallets, and would add 96 bytes to a 2-out tx, and incur no extra scanning time 12:29:38 The #issuecomment-603079784 proposal would not work on view-only wallets, would add 64 bytes, and incur extra scanning time? 12:29:40 the cast majority of 2-out txs do have a change output though 12:29:46 s/cast/vast 12:29:46 knaccc meant to say: the vast majority of 2-out txs do have a change output though 12:29:50 If we do assume it: 12:29:57 The 48-byte schnorr proposal would work on view-only wallets, and would add 48 bytes to a 2-out tx, and incur no extra scanning time 12:30:14 The #issuecomment-603079784 proposal would not work on view-only wallets, would add 32 bytes, and would not incur extra scanning time 12:30:37 oh ok, i see, thanks for clarifying 12:31:33 I think enforcing 1-tx pub key for 2-out tx is reasonable and worth discussion from others 12:33:36 and at the same time enforce 1-pub key per output for 3+-out tx 12:35:42 thanks for the discussion knaccc :) 12:37:41 UkoeHB_ np, thanks for humoring me even though i'm not fully awake yet :) 12:42:43 btw how would the 48-byte signature work? Im guessing you truncate one of the components, but looking at how Schnorr works I'm a bit confused 12:44:36 also, identifying change outputs implies some relationship with the spend key, since you need to calculate key images 12:44:52 not as direct as Janus base key method tho 12:47:00 UkoeHB_ apparently schnorr signatures are perfectly secure with a 128-bit truncated hash instead of a full 256-bit hash 12:47:30 oh just make the hash output 128-bit? makes sense 12:47:44 it was discussed here in #mrl, one of the noether brothers suggested it 12:48:01 not sure what you mean about "identifying change outputs" 12:48:39 all that changes with the recipient is that they also check the schnorr sig and assume it applies to the output they've received 12:49:08 for the sender receiving the change output back, i think you're referring to that 12:49:22 ah yes i see what you mean 12:49:32 i think i remember addressing this actually 12:49:48 i think the answer was that all change would be sent to a "-1" change index in the account 12:49:53 and that would be a secret address 12:50:02 and you can't do a janus attack on an unknown subaddress 12:50:05 oh interesting idea 12:50:20 so the change address would never be shared, and the wallet would never tell you what it is, to ensure you don't accidentally share it 12:51:19 it'd just label it as "change", and not tell you the actual subaddress 12:53:03 I like that idea, and even if a wallet implementer doesn't go with that they could still use key images to identify change outputs. 12:53:46 yeah, if it knows about them 12:54:00 i'm assuming the worst 12:55:18 right, though you might have to send that secret subaddress to a light wallet server like mymonero if it was meant to check Janus 12:56:13 is this a scenario where the light wallet server does not know your private view key? 12:57:24 it would know the private view key I imagine 12:57:24 just in case i wasn't clear, i meant the secret subaddress is only hidden from people that don't know your private view key 12:57:32 oh ok 12:58:00 hmm maybe i just made things less clear :) 12:59:18 i more specifically mean that the secret change subaddress is just determined with the private view key in the normal way with an account index component >=0 and a subaddress index inside that account of -1 12:59:31 so anyone with your private view key can calculate the change subaddress 13:00:05 but the wallet doesn't display that -1 subaddress to you, just in case you mistakenly share it because you didn't realize it was meant to be kept a secret 13:02:51 oh duh, you can make new subaddresses just knowing the view private key and normal address 13:08:59 :) 13:10:51 Yes, the truncated Schnorr idea isn't new, but was brought up shortly after Janus was initially discussed 13:11:08 it leaked out of my brain ^.^ 13:12:19 For some reason I thought the initial idea was susceptible to address testing, but I may be misremembering 13:12:46 sarang i think there was a problem perhaps if the schnorr was on the txpubkey, but not if it was on the shared secret 13:13:04 in fact i think it was you that pointed that exact thing out :) 13:13:21 lol could be 13:13:48 all you need is to key prefix the shared secret 13:14:13 aye 13:17:42 what is a key prefix and how would it be applied? 13:21:01 just means putting the key in the signature's challenge hash; the goal here would be to prevent observers from verifying the signature by including the shared secret, which only sender and receiver can compute 13:23:59 i'm confused - an observer doesn't know the shared secret 13:24:08 so how does it help to put that into the hash 13:25:16 exactly, which means an observer can't verify the Schnorr signature. Someone who can verify the signature will be able to figure out if the base key is `G`, or if it's someone's subaddress's spend key 13:26:38 or you could do the signature on the view key as base key 13:26:40 but only someone that knows the shared secret can verify the signature 13:26:48 yeah that's the point 13:27:08 the shared secret has a base key C (the subaddress public view key) 13:27:25 so you need to know the shared secret sC to verify that sC is on C 13:27:35 and only the wallet owner can verify that 13:28:06 so the tx sender is proving they know the private key s on the shared secret sC 13:28:18 right 13:28:24 my brain is a little slow 13:29:28 heh don't worry, for some peculiar reason, the subaddress scheme is burned into my retina :) 13:29:43 i think i have an OLED cornea 13:29:59 sounds difficult 16:32:41 does anyone know if it's possible to do a sqrt on a scalar? 16:32:57 i.e. if given s*s, determine s 16:35:08 You could probably use something like Tonelli-Shanks, which works over prime modulus 16:35:28 whoa, nice, thanks sarang 16:36:05 Maybe there's already an efficient specialized version for the prime-order ed25519 subgroup 21:13:22 FYI will be mostly offline tomorow, getting caught up on literature review and writing unit tests 21:13:59 knaccc: did you have a particular application in mind for needing a root algorithm? 21:14:44 sarang i was messing around with algebra to try and see if there was a way to get below 48 bytes, it was fruitless though. thanks for your help 21:15:16 essentially i was looking to see if there were any one-way scalar operations 21:15:37 but i guess there aren't, because if there were, we wouldn't need EC points for a trapdoor function 21:16:20 heh well actually i guess Hs() counts as a trapdoor function 21:16:28 but anyway, it was a dead end 21:16:30 Yeah, scalar-only operations are reversible 21:16:40 (other than hashing) 21:38:47 https://github.com/monero-project/monero/issues/6456 21:47:02 This is your "here are the Janus+tx_extra-related ideas" write-up UkoeHB_? 21:47:11 yes 21:47:20 took me all freaking day whew 21:48:40 * sarang adds to his list