Sarang: You commented on the recent reddit post

> Join the research meetings if you are interested in participating in the Monero Research Lab

I'm curious if there's much work that's been done in trying to grow the MRL in that capacity

that is, more public outreach efforts

I did not comment on that post

However, what sort of public outreach do you mean?

^ needbrrrrrrr90

that was sgp, sorry

And I'm unsure of what kind of outreach

just...I guess bringing the thought up

How can we attract the best and brightest in the crypto space to our little bubble, above how we've been operating currently?

gotta keep the rule of bayes in mind here needbrrrrrrr90

Advertisement rarely brings negative results

The question is how large we can raise the margins :)

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%

needbrrrrrrr90: it's probably more 1 on 1 recruiting than most other marketing efforts

yanmaani: Clearly minimizing exposure is the optimal path, then

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

seddd: you here?

The warm fuzzy feeling of helping the species as a whole salvage what remains of its privacy.

Will you choose the Empire or join the Rebel scum ? :D

I hear the Empire has free coffee

Taken by force from poor farmers on Tatooine.

I'm not exactly sure *how* we can attract more researchers, so much as I'm posing the idea to the group

More quality researchers*

Quantity is obviously not a primary goal

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

bool verify(transaction tx) return true;

<[keybase] seddd>: needbrrrrrrr90: imho, bounties are almost always a good idea. Found MRL in part through the Vulnerability Disclosure / Hackerone program.

E x a m p l e

<[keybase] seddd>: no real ideas for outreach, other than maybe some ramp-up guides for researchers new to the project

An easier path to understanding what being a researcher means could be beneficial

<[keybase] seddd>: something like guides for introducing XMR components, approaches for auditing, no-no's, appreciated work...

needbrrrrrrr90: My intuitive understanding is that bounties sometimes work, but sometimes also create bad incentives

As long as I've started a conversation, my goal is complete :)

<[keybase] seddd>: needbrrrrrrr90: agree, programs have to be designed carefully.

my guess is that it's sort of like a pipeline: it doesn't make sense to draw in random people from the internet

but rather you should try and recruit from the Monero community

I think room exists for wooing researchers from the wider crypto space

from this it emerges with an elegant clarity that you should advertise this channel in #monero's topic

To be blunt, we're small.

<[keybase] seddd>: yaanmani: having independent researchers is also important, to ensure as few blindspots as possible

so right now the head in #monero is this

... Dev: #monero-dev || Pool related: #monero-pools || Price chat: #monero-markets || Trading: #monero-otc || People can & do log this channel ...

changing this to Research: #monero-research-lab should probably do a bit

or at least putting it in #-dev

I don't think the people who would be interested in MRL stuff who pop into our other channels are unaware of the MRL

But maybe I'm mistake.

Mistaken

I only noticed it because someone mentioned it

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

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

"Mercenaries and auxiliaries are useless and dangerous; and if one holds his state based on these arms, he will stand neither firm nor safe [...]"

For me, the benefit was that I like privacy a lot, and coding something that helps save it beats raging at corps and govts.

The ffs is what made me put so much time in though.

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

<[keybase] seddd>: moneromooo: so much this ^

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"

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

Ideally it would be attracting people who realize the benefits of working on this stuff, or who find it interesting

moneromooo: aren't you admin in #monero?

try doing that and see what happens

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

s/timr/time

Having coordinators who can buffer knowledge between sessions with various people working sporadically is important

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

Having some amount of MRL staff is important, and having multiple (two seems great) doubly so, as they can bounce ideas off each other

Vs talking to themselves

<[keybase] seddd>: needbrrrrrrr90: coordinators could also help independent researchers get better coverage, especially long-term by access to historic reports on w/e components

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

Seddd: I've personally tried to define a distinction between coordinators (time commitment) and other actors in our ecosystem

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

Ive tried to introduce it a few times before

Coordinators being information buffers of a sort

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

web.getmonero.org/resources/research-lab

^

<[keybase] seddd>: or some 'Intro to MRL and Monero security research'

Does BP verification time matter for both daemon syncing and wallet scanning? I assume yes?

I am not. Ops (admins) have a @ in front of their nick in the list.

The wallet does not verify proofs. The daemon already did.

Okay, so it only influences daemon sync time?

Yes, for the last bit.

BP verification is skipped for the builtin hashes range, which is most of the chain.

well sometimes they just ask CS to op them temporarily

Ah, true.

<[keybase] seddd>: sarang: thanks. fwiw my experience from finding out about MRL, introducing myself/goals in IRC/keybase, and starting research was really smooth

That's good to hear seddd

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

<xmrhaelan> Source: coingecko.com/en?view=developer <—filter list by Contributors

<xmrhaelan> 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.

<cankerwort> When it says that "v1 coinbases are forbidden" from v.0.15.0.0 on this page github.com/monero-project/monero/#research , does this mean the first XMR which was mined cannot be spent in a modern transaction?

<cankerwort> or that coinbases can no longer be constructed in a version 1 format?

it's a format enforcement

<cankerwort> That's all right then, thanks!

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

<cankerwort> is the transistion tx like a self-spend?

I think you can send to whoever

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

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

you need more tx pub keys

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

hm I think all of those require a lot more bytes

i'll read more, but i can't imagine it being worth increasing scanning time for janus mitigation

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

Also, having more tx pub keys increases tx uniformity, which was favorable to some people (Isthmus and sarang in particular iirc)

if i remember correctly, we know how to do a janus mitigation on a 2-out tx with only 48 extra bytes

i agree for outputs >= 3 we should go for uniformity and put a txpubkey on every output

i don't think the view-tag optimization outperforms current scanning times, if the 48-byte janus mitigation technique is used

I can't recall what the 48-byte mitigation was, can you refresh me?

or link?

Is there any timing data related to scanning? Would be helpful to know how much is from the ec operations specifically

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

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

I believe you can test that against suspected destinations

sarang i'll think about it, i'd be interested to know specifically how

since the proof would be on the shared secret, which itself can only be determined by the actual received

receiver*

It sounds reasonable, although Im skeptical about using different mitigations for 2-out vs multi-out tx

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

ah I thought you were implying to use the Janus base key method for multi-out, nvm then

ah cool

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

and that therefore #62 was an improvement that would use an extra 32 bytes per output instead of 64

or 48 rather

the original idea was like that, but then I found a hole that had to be plugged

ah ok i see, i'll need more caffeine and i'll delve into it, thanks :)

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

my concern is the edge cases reducing uniformity

i.e. no change output

i think we should enforce a change output on all txs

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

key per tx for Janus base method)

i'm scribbling down issue #62 so i can understand it better

ok, this is most updated version monero-project/research-lab #62#issuecomment-603079784

thx

idk if we could enforce change output, since it would have distinguishable from other outputs

have to be*

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)

i agree you could not consensus-enforce it

hmm although in a way you can

since if there is only one txpubkey allowed on a 2-out tx, then the other output is useless except for change, i think

unless that second output is perhaps also destined for the same person as the first output

ah could be

that might be the best way to go, even setting aside Janus mitigation

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?

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?

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

that's correct

so in the case of 2-out txs:

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

The #issuecomment-603079784 proposal would not work on view-only wallets, would add 64 bytes, and incur extra scanning time?

That comparison is a bit off. If we don't assume change output then:

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

The #issuecomment-603079784 proposal would not work on view-only wallets, would add 64 bytes, and incur extra scanning time?

the cast majority of 2-out txs do have a change output though

s/cast/vast

If we do assume it:

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

The #issuecomment-603079784 proposal would not work on view-only wallets, would add 32 bytes, and would not incur extra scanning time

oh ok, i see, thanks for clarifying

I think enforcing 1-tx pub key for 2-out tx is reasonable and worth discussion from others

and at the same time enforce 1-pub key per output for 3+-out tx

thanks for the discussion knaccc :)

UkoeHB_ np, thanks for humoring me even though i'm not fully awake yet :)

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

also, identifying change outputs implies some relationship with the spend key, since you need to calculate key images

not as direct as Janus base key method tho

UkoeHB_ apparently schnorr signatures are perfectly secure with a 128-bit truncated hash instead of a full 256-bit hash

oh just make the hash output 128-bit? makes sense

it was discussed here in #mrl, one of the noether brothers suggested it

not sure what you mean about "identifying change outputs"

all that changes with the recipient is that they also check the schnorr sig and assume it applies to the output they've received

for the sender receiving the change output back, i think you're referring to that

ah yes i see what you mean

i think i remember addressing this actually

i think the answer was that all change would be sent to a "-1" change index in the account

and that would be a secret address

and you can't do a janus attack on an unknown subaddress

oh interesting idea

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

it'd just label it as "change", and not tell you the actual subaddress

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.

yeah, if it knows about them

i'm assuming the worst

right, though you might have to send that secret subaddress to a light wallet server like mymonero if it was meant to check Janus

is this a scenario where the light wallet server does not know your private view key?

it would know the private view key I imagine

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

oh ok

hmm maybe i just made things less clear :)

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

so anyone with your private view key can calculate the change subaddress

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

oh duh, you can make new subaddresses just knowing the view private key and normal address

:)

Yes, the truncated Schnorr idea isn't new, but was brought up shortly after Janus was initially discussed

it leaked out of my brain ^.^

For some reason I thought the initial idea was susceptible to address testing, but I may be misremembering

sarang i think there was a problem perhaps if the schnorr was on the txpubkey, but not if it was on the shared secret

in fact i think it was you that pointed that exact thing out :)

lol could be

all you need is to key prefix the shared secret

aye

what is a key prefix and how would it be applied?

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

i'm confused - an observer doesn't know the shared secret

so how does it help to put that into the hash

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

or you could do the signature on the view key as base key

but only someone that knows the shared secret can verify the signature

yeah that's the point

the shared secret has a base key C (the subaddress public view key)

so you need to know the shared secret sC to verify that sC is on C

and only the wallet owner can verify that

so the tx sender is proving they know the private key s on the shared secret sC

right

my brain is a little slow

heh don't worry, for some peculiar reason, the subaddress scheme is burned into my retina :)

i think i have an OLED cornea

sounds difficult

does anyone know if it's possible to do a sqrt on a scalar?

i.e. if given s*s, determine s

You could probably use something like Tonelli-Shanks, which works over prime modulus

whoa, nice, thanks sarang

Maybe there's already an efficient specialized version for the prime-order ed25519 subgroup

FYI will be mostly offline tomorow, getting caught up on literature review and writing unit tests

knaccc: did you have a particular application in mind for needing a root algorithm?

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

essentially i was looking to see if there were any one-way scalar operations

but i guess there aren't, because if there were, we wouldn't need EC points for a trapdoor function

heh well actually i guess Hs() counts as a trapdoor function

but anyway, it was a dead end

Yeah, scalar-only operations are reversible

(other than hashing)

This is your "here are the Janus+tx_extra-related ideas" write-up UkoeHB_?

yes

took me all freaking day whew