-
needbrrrrrrr90
Sarang: You commented on the recent reddit post
-
needbrrrrrrr90
> Join the research meetings if you are interested in participating in the Monero Research Lab
-
needbrrrrrrr90
I'm curious if there's much work that's been done in trying to grow the MRL in that capacity
-
needbrrrrrrr90
that is, more public outreach efforts
-
sarang
I did not comment on that post
-
sarang
However, what sort of public outreach do you mean?
-
sarang
^ needbrrrrrrr90
-
needbrrrrrrr90
that was sgp, sorry
-
needbrrrrrrr90
And I'm unsure of what kind of outreach
-
needbrrrrrrr90
just...I guess bringing the thought up
-
needbrrrrrrr90
How can we attract the best and brightest in the crypto space to our little bubble, above how we've been operating currently?
-
yanmaani
gotta keep the rule of bayes in mind here needbrrrrrrr90
-
needbrrrrrrr90
Advertisement rarely brings negative results
-
needbrrrrrrr90
The question is how large we can raise the margins :)
-
yanmaani
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%
-
sgp_
needbrrrrrrr90: it's probably more 1 on 1 recruiting than most other marketing efforts
-
needbrrrrrrr90
yanmaani: Clearly minimizing exposure is the optimal path, then
-
xmrmatterbridge
<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?
-
sarang
seddd: you here?
-
moneromooo
The warm fuzzy feeling of helping the species as a whole salvage what remains of its privacy.
-
moneromooo
Will you choose the Empire or join the Rebel scum ? :D
-
sarang
I hear the Empire has free coffee
-
moneromooo
Taken by force from poor farmers on Tatooine.
-
needbrrrrrrr90
I'm not exactly sure *how* we can attract more researchers, so much as I'm posing the idea to the group
-
needbrrrrrrr90
More quality researchers*
-
needbrrrrrrr90
Quantity is obviously not a primary goal
-
needbrrrrrrr90
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
-
sarang
bool verify(transaction tx) return true;
-
derpy_bridge
<[keybase] seddd>: needbrrrrrrr90: imho, bounties are almost always a good idea. Found MRL in part through the Vulnerability Disclosure / Hackerone program.
-
needbrrrrrrr90
E x a m p l e
-
» needbrrrrrrr90 rolls eyes at sarang
-
derpy_bridge
<[keybase] seddd>: no real ideas for outreach, other than maybe some ramp-up guides for researchers new to the project
-
needbrrrrrrr90
An easier path to understanding what being a researcher means could be beneficial
-
derpy_bridge
<[keybase] seddd>: something like guides for introducing XMR components, approaches for auditing, no-no's, appreciated work...
-
yanmaani
needbrrrrrrr90: My intuitive understanding is that bounties sometimes work, but sometimes also create bad incentives
-
needbrrrrrrr90
As long as I've started a conversation, my goal is complete :)
-
derpy_bridge
<[keybase] seddd>: needbrrrrrrr90: agree, programs have to be designed carefully.
-
yanmaani
my guess is that it's sort of like a pipeline: it doesn't make sense to draw in random people from the internet
-
yanmaani
but rather you should try and recruit from the Monero community
-
needbrrrrrrr90
I think room exists for wooing researchers from the wider crypto space
-
yanmaani
from this it emerges with an elegant clarity that you should advertise this channel in #monero's topic
-
needbrrrrrrr90
To be blunt, we're small.
-
derpy_bridge
<[keybase] seddd>: yaanmani: having independent researchers is also important, to ensure as few blindspots as possible
-
yanmaani
so right now the head in #monero is this
-
yanmaani
... Dev: #monero-dev || Pool related: #monero-pools || Price chat: #monero-markets || Trading: #monero-otc || People can & do log this channel ...
-
yanmaani
changing this to Research: #monero-research-lab should probably do a bit
-
yanmaani
or at least putting it in #-dev
-
needbrrrrrrr90
I don't think the people who would be interested in MRL stuff who pop into our other channels are unaware of the MRL
-
needbrrrrrrr90
But maybe I'm mistake.
-
needbrrrrrrr90
Mistaken
-
yanmaani
I only noticed it because someone mentioned it
-
xmrmatterbridge
<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?
-
yanmaani
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
-
yanmaani
"Mercenaries and auxiliaries are useless and dangerous; and if one holds his state based on these arms, he will stand neither firm nor safe [...]"
-
moneromooo
For me, the benefit was that I like privacy a lot, and coding something that helps save it beats raging at corps and govts.
-
moneromooo
The ffs is what made me put so much time in though.
-
xmrmatterbridge
<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?
-
derpy_bridge
<[keybase] seddd>: moneromooo: so much this ^
-
yanmaani
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"
-
yanmaani
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
-
needbrrrrrrr90
Ideally it would be attracting people who realize the benefits of working on this stuff, or who find it interesting
-
yanmaani
moneromooo: aren't you admin in #monero?
-
yanmaani
try doing that and see what happens
-
needbrrrrrrr90
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
-
needbrrrrrrr90
s/timr/time
-
monerobux
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
-
needbrrrrrrr90
Having coordinators who can buffer knowledge between sessions with various people working sporadically is important
-
needbrrrrrrr90
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
-
needbrrrrrrr90
Having some amount of MRL staff is important, and having multiple (two seems great) doubly so, as they can bounce ideas off each other
-
needbrrrrrrr90
Vs talking to themselves
-
derpy_bridge
<[keybase] seddd>: needbrrrrrrr90: coordinators could also help independent researchers get better coverage, especially long-term by access to historic reports on w/e components
-
needbrrrrrrr90
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
-
needbrrrrrrr90
Seddd: I've personally tried to define a distinction between coordinators (time commitment) and other actors in our ecosystem
-
needbrrrrrrr90
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
-
needbrrrrrrr90
Ive tried to introduce it a few times before
-
needbrrrrrrr90
Coordinators being information buffers of a sort
-
derpy_bridge
<[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)
-
needbrrrrrrr90
-
sarang
^
-
derpy_bridge
<[keybase] seddd>: or some 'Intro to MRL and Monero security research'
-
sarang
-
selsta
Does BP verification time matter for both daemon syncing and wallet scanning? I assume yes?
-
moneromooo
I am not. Ops (admins) have a @ in front of their nick in the list.
-
moneromooo
The wallet does not verify proofs. The daemon already did.
-
selsta
Okay, so it only influences daemon sync time?
-
moneromooo
Yes, for the last bit.
-
moneromooo
BP verification is skipped for the builtin hashes range, which is most of the chain.
-
yanmaani
well sometimes they just ask CS to op them temporarily
-
moneromooo
Ah, true.
-
derpy_bridge
<[keybase] seddd>: sarang: thanks. fwiw my experience from finding out about MRL, introducing myself/goals in IRC/keybase, and starting research was really smooth
-
sarang
That's good to hear seddd
-
xmrmatterbridge
<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?
-
xmrmatterbridge
<xmrhaelan> Source:
coingecko.com/en?view=developer <—filter list by Contributors
-
xmrmatterbridge
<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.
-
xmrmatterbridge
<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?
-
xmrmatterbridge
<cankerwort> or that coinbases can no longer be constructed in a version 1 format?
-
UkoeHB_
it's a format enforcement
-
xmrmatterbridge
<cankerwort> That's all right then, thanks!
-
UkoeHB_
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
-
xmrmatterbridge
<cankerwort> is the transistion tx like a self-spend?
-
UkoeHB_
I think you can send to whoever
-
» UkoeHB_ is not an expert
-
knaccc
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
-
knaccc
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
-
UkoeHB_
you need more tx pub keys
-
knaccc
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
-
UkoeHB_
hm I think all of those require a lot more bytes
-
knaccc
i'll read more, but i can't imagine it being worth increasing scanning time for janus mitigation
-
UkoeHB_
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
-
UkoeHB_
Also, having more tx pub keys increases tx uniformity, which was favorable to some people (Isthmus and sarang in particular iirc)
-
knaccc
if i remember correctly, we know how to do a janus mitigation on a 2-out tx with only 48 extra bytes
-
knaccc
i agree for outputs >= 3 we should go for uniformity and put a txpubkey on every output
-
knaccc
i don't think the view-tag optimization outperforms current scanning times, if the 48-byte janus mitigation technique is used
-
UkoeHB_
I can't recall what the 48-byte mitigation was, can you refresh me?
-
UkoeHB_
or link?
-
UkoeHB_
Is there any timing data related to scanning? Would be helpful to know how much is from the ec operations specifically
-
knaccc
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
-
knaccc
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
-
sarang
I believe you can test that against suspected destinations
-
knaccc
sarang i'll think about it, i'd be interested to know specifically how
-
knaccc
since the proof would be on the shared secret, which itself can only be determined by the actual received
-
knaccc
receiver*
-
UkoeHB_
It sounds reasonable, although Im skeptical about using different mitigations for 2-out vs multi-out tx
-
knaccc
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
-
UkoeHB_
ah I thought you were implying to use the Janus base key method for multi-out, nvm then
-
knaccc
ah cool
-
knaccc
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
-
knaccc
and that therefore #62 was an improvement that would use an extra 32 bytes per output instead of 64
-
knaccc
or 48 rather
-
UkoeHB_
the original idea was like that, but then I found a hole that had to be plugged
-
knaccc
ah ok i see, i'll need more caffeine and i'll delve into it, thanks :)
-
UkoeHB_
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
-
UkoeHB_
my concern is the edge cases reducing uniformity
-
UkoeHB_
i.e. no change output
-
knaccc
i think we should enforce a change output on all txs
-
UkoeHB_
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
-
UkoeHB_
key per tx for Janus base method)
-
knaccc
i'm scribbling down issue #62 so i can understand it better
-
UkoeHB_
-
knaccc
thx
-
UkoeHB_
idk if we could enforce change output, since it would have distinguishable from other outputs
-
UkoeHB_
have to be*
-
UkoeHB_
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)
-
knaccc
i agree you could not consensus-enforce it
-
knaccc
hmm although in a way you can
-
knaccc
since if there is only one txpubkey allowed on a 2-out tx, then the other output is useless except for change, i think
-
knaccc
unless that second output is perhaps also destined for the same person as the first output
-
UkoeHB_
ah could be
-
UkoeHB_
that might be the best way to go, even setting aside Janus mitigation
-
knaccc
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?
-
knaccc
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?
-
UkoeHB_
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
-
UkoeHB_
that's correct
-
knaccc
so in the case of 2-out txs:
-
knaccc
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
-
knaccc
The #issuecomment-603079784 proposal would not work on view-only wallets, would add 64 bytes, and incur extra scanning time?
-
UkoeHB_
That comparison is a bit off. If we don't assume change output then:
-
UkoeHB_
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
-
UkoeHB_
The #issuecomment-603079784 proposal would not work on view-only wallets, would add 64 bytes, and incur extra scanning time?
-
knaccc
the cast majority of 2-out txs do have a change output though
-
knaccc
s/cast/vast
-
monerobux
knaccc meant to say: the vast majority of 2-out txs do have a change output though
-
UkoeHB_
If we do assume it:
-
UkoeHB_
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
-
UkoeHB_
The #issuecomment-603079784 proposal would not work on view-only wallets, would add 32 bytes, and would not incur extra scanning time
-
knaccc
oh ok, i see, thanks for clarifying
-
UkoeHB_
I think enforcing 1-tx pub key for 2-out tx is reasonable and worth discussion from others
-
UkoeHB_
and at the same time enforce 1-pub key per output for 3+-out tx
-
UkoeHB_
thanks for the discussion knaccc :)
-
knaccc
UkoeHB_ np, thanks for humoring me even though i'm not fully awake yet :)
-
UkoeHB_
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
-
UkoeHB_
also, identifying change outputs implies some relationship with the spend key, since you need to calculate key images
-
UkoeHB_
not as direct as Janus base key method tho
-
knaccc
UkoeHB_ apparently schnorr signatures are perfectly secure with a 128-bit truncated hash instead of a full 256-bit hash
-
UkoeHB_
oh just make the hash output 128-bit? makes sense
-
knaccc
it was discussed here in #mrl, one of the noether brothers suggested it
-
knaccc
not sure what you mean about "identifying change outputs"
-
knaccc
all that changes with the recipient is that they also check the schnorr sig and assume it applies to the output they've received
-
knaccc
for the sender receiving the change output back, i think you're referring to that
-
knaccc
ah yes i see what you mean
-
knaccc
i think i remember addressing this actually
-
knaccc
i think the answer was that all change would be sent to a "-1" change index in the account
-
knaccc
and that would be a secret address
-
knaccc
and you can't do a janus attack on an unknown subaddress
-
UkoeHB_
oh interesting idea
-
knaccc
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
-
knaccc
it'd just label it as "change", and not tell you the actual subaddress
-
UkoeHB_
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.
-
knaccc
yeah, if it knows about them
-
knaccc
i'm assuming the worst
-
UkoeHB_
right, though you might have to send that secret subaddress to a light wallet server like mymonero if it was meant to check Janus
-
knaccc
is this a scenario where the light wallet server does not know your private view key?
-
UkoeHB_
it would know the private view key I imagine
-
knaccc
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
-
UkoeHB_
oh ok
-
knaccc
hmm maybe i just made things less clear :)
-
knaccc
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
-
knaccc
so anyone with your private view key can calculate the change subaddress
-
knaccc
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
-
UkoeHB_
oh duh, you can make new subaddresses just knowing the view private key and normal address
-
knaccc
:)
-
sarang
Yes, the truncated Schnorr idea isn't new, but was brought up shortly after Janus was initially discussed
-
UkoeHB_
it leaked out of my brain ^.^
-
sarang
For some reason I thought the initial idea was susceptible to address testing, but I may be misremembering
-
knaccc
sarang i think there was a problem perhaps if the schnorr was on the txpubkey, but not if it was on the shared secret
-
knaccc
in fact i think it was you that pointed that exact thing out :)
-
sarang
lol could be
-
UkoeHB_
all you need is to key prefix the shared secret
-
sarang
aye
-
knaccc
what is a key prefix and how would it be applied?
-
UkoeHB_
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
-
knaccc
i'm confused - an observer doesn't know the shared secret
-
knaccc
so how does it help to put that into the hash
-
UkoeHB_
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
-
UkoeHB_
or you could do the signature on the view key as base key
-
knaccc
but only someone that knows the shared secret can verify the signature
-
knaccc
yeah that's the point
-
knaccc
the shared secret has a base key C (the subaddress public view key)
-
knaccc
so you need to know the shared secret sC to verify that sC is on C
-
knaccc
and only the wallet owner can verify that
-
knaccc
so the tx sender is proving they know the private key s on the shared secret sC
-
UkoeHB_
right
-
UkoeHB_
my brain is a little slow
-
knaccc
heh don't worry, for some peculiar reason, the subaddress scheme is burned into my retina :)
-
knaccc
i think i have an OLED cornea
-
UkoeHB_
sounds difficult
-
knaccc
does anyone know if it's possible to do a sqrt on a scalar?
-
knaccc
i.e. if given s*s, determine s
-
sarang
You could probably use something like Tonelli-Shanks, which works over prime modulus
-
knaccc
whoa, nice, thanks sarang
-
sarang
Maybe there's already an efficient specialized version for the prime-order ed25519 subgroup
-
sarang
FYI will be mostly offline tomorow, getting caught up on literature review and writing unit tests
-
sarang
knaccc: did you have a particular application in mind for needing a root algorithm?
-
knaccc
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
-
knaccc
essentially i was looking to see if there were any one-way scalar operations
-
knaccc
but i guess there aren't, because if there were, we wouldn't need EC points for a trapdoor function
-
knaccc
heh well actually i guess Hs() counts as a trapdoor function
-
knaccc
but anyway, it was a dead end
-
sarang
Yeah, scalar-only operations are reversible
-
sarang
(other than hashing)
-
UkoeHB_
-
sarang
This is your "here are the Janus+tx_extra-related ideas" write-up UkoeHB_?
-
UkoeHB_
yes
-
UkoeHB_
took me all freaking day whew
-
» sarang adds to his list