13:46:41 <ErCiccione[m]> Is there a high resolution logo of the MRL? https://github.com/monero-project/monero-site/pull/948#discussion_r444892332
13:48:02 <ErCiccione[m]> Or do you know where could i find other logos? I didn't find much
13:48:46 <sarang> What's the resolution available now?
13:49:31 <sarang> I don't have anything available except what goes on the MRL non-IACR preprints
13:51:45 <ErCiccione[m]> https://github.com/monero-project/monero-site/blob/df4c63ede0a8037efcad92d3af9296075ef0aa50/img/mrl-logo.png
13:52:11 <ErCiccione[m]> this is 255px × 255px and it's also quite heavy. I might have taken it from the matrix room of this channel
13:52:33 <ErCiccione[m]> sarang could you give me a link to the version you use for preprints? maybe it's better
13:54:52 <sarang> e.g. https://github.com/SarangNoether/research-lab/blob/master/publications/bulletins/MRL-0010-discrete/logo.png
13:56:11 <sarang> Maybe there's an SVG somewhere; I'm not sure though
13:57:44 <ErCiccione[m]> I think that's the same, but i will see what i can do. An svg version would be perfect
14:02:05 <sarang> Can't help you there, unfortunately
14:02:19 <sarang> Maybe someone like fluffypony would know if such a thing is floating around somewhere
14:02:32 <sarang> That logo has been around for a few years now
14:05:59 <fluffypony> I made the logo
14:06:00 <fluffypony> lol
14:07:15 <fluffypony> I have it in PSD and AI
14:07:24 <fluffypony> I can export AI to SVG
14:08:23 <fluffypony> https://imgur.com/a/9q3RpVa
14:08:26 <fluffypony> last time it was edited lol
14:08:52 <ErCiccione[m]> Didn't know that. :)
14:09:08 <ErCiccione[m]> A svg version would be great
14:09:44 <fluffypony> you just need the actual logo not the text, right?
14:09:57 <ErCiccione[m]> Yes only the logo
14:11:20 <fluffypony> ErCiccione[m]: what's the best way to get this to you? Telegram / Wire / email?
14:11:56 <ErCiccione[m]> Email would be best. translate⊙go
14:11:58 <fluffypony> GitHub won't let me upload an SVG to that thread lol
14:12:02 <ErCiccione[m]> Thanks!
14:12:33 <sarang> Thanks fluffypony
14:15:46 <fluffypony> np
14:20:49 <sarang> ErCiccione[m]: add to press kit page?
14:20:54 <sarang> for easier access
14:21:37 <ErCiccione[m]> Oh yeah, that's a good idea
14:24:01 <ErCiccione[m]> I'm opening an issue about it and i will add it later on. There is no place to put it with the current structure and should be also included in monero-press-kit.zip
14:54:10 <sarang> Don't forget there's a weekly research meeting today at 17:00 UTC
14:54:11 <sarang> .time
14:54:11 <monerobux> 2020-06-24 - 14:54:11
14:54:13 <sarang> good bot
14:55:31 <sarang> I'll talk a bit at the meeting about the status of the CLSAG review
15:11:38 <sgp_> having an svg would be great
16:06:29 <Isthmus> @xmrpow I'm working on designing a PPS pool and crunching those numbers is on my to-do list. Also working on a ramp mechanism that brings some PPLNS principles (more like PPFNS, actually) into our PPS pool to protect the operator against getting financially pinched by pool hopping
16:06:39 <Isthmus> Happy to collaborate via direct message or Isthmus [at] getmonero.org
16:06:56 <Isthmus> Oh shoot, did they leave already?
16:35:57 <asymptotically> Isthmus: xmrpow always leaves but keeps on watching the logs
16:58:23 <sarang> OK, let's go ahead and get started with the meeting
16:58:34 <sarang> Logs will be posted to the agenda GitHub issue after it's finished
16:59:40 <sarang> First, GREETINGS
16:59:48 <ArticMine> Hi
17:00:25 <I3^RELATIVISM> 0/
17:03:21 <Isthmus> Greetings
17:03:57 <sarang> All right, on to ROUNDTABLE, where anyone is welcome to share research of interest
17:04:03 <sarang> Who would like to go first?
17:05:30 <sarang> Isthmus:?
17:05:38 <Isthmus> Heyo
17:05:45 <Isthmus> Update on quantum audit, here is our preliminary analysis existing vulnerabilities. (Results subject to change as research progresses!)
17:05:52 <Isthmus> https://usercontent.irccloud-cdn.com/file/RKKVcmGZ/image.png
17:06:02 <Isthmus> https://usercontent.irccloud-cdn.com/file/ZPskux3i/image.png
17:06:53 <Isthmus> It's kind of a mixed bag, tbh.
17:07:04 <sarang> To be expected, I suppose
17:07:09 <sarang> There are many components of interest
17:07:09 <Isthmus> Our reliance on DLP is the biggest weak spot right, as expected
17:07:13 <sarang> ya
17:08:12 <Isthmus> That's all on that, any Q's?
17:08:14 <sarang> By "ring signatures" I assume you mean a quantum adversary identifying signing indices via key images?
17:08:41 <Isthmus> Yea (or via any mechanism)
17:08:48 <Isthmus> Oh, one thing that we started wondering about
17:09:23 <Isthmus> If you're creating a multisig transactions and one of the signers has a quantum computer, can they gain any extra information about their co-signers
17:10:26 <sarang> Well, you can just derive the whole private key
17:10:37 <sarang> if that's what you mean
17:11:34 <Isthmus> Yea. I need to sit down with ZtM2 to figure out what's passed around, and what should be unknown, just crossed my mind yesterdy
17:12:03 <sarang> That's a good point
17:12:19 <sarang> I don't think anyone had specifically mentioned the multisig process during the planning stages of your analysis
17:14:01 <Isthmus> Yea, we just added it. Will probably realize 1 or 2 more aspects to check throughout the next few weeks
17:14:06 <Isthmus> Keep dropping us your ideas :- )
17:14:18 <sarang> Are there particular assumptions made about whether or not the adversary has a public key already?
17:14:35 <sarang> e.g. the adversary suspects a particular address as a destination
17:15:10 <Isthmus> I'm assuming that the adversary is a co-signer on the multisig transaction. They would know the public key with or without a quantum computer, right?
17:15:29 <Isthmus> [erm, well we can consider the adversary both ways, this is just what I had been wondering about yesterday]
17:15:34 <sarang> I mean in general, sorry
17:15:37 <sarang> Not specific to multisig
17:16:31 <Isthmus> Ah yea, quantum computer with your public key and quantum computer without your public key are two adversary models that are considered separately.
17:16:38 <Isthmus> Though TBH the first one is pretty (sadly) easy
17:16:51 <Isthmus> Public key --> [shor's algorithm] --> private key --> init wallet --> game over
17:18:02 <sgp_> sorry I'm late
17:18:04 <sarang> And not even "your" public key
17:18:10 <sarang> But just looking at a given transcation on chain
17:18:29 <sarang> If the adversary's goal is to identify as much as possible about keys, addresses, etc.
17:18:43 <sarang> Sending wallet address, receiving wallet address, etc.
17:19:42 <Isthmus> Yea, if an outside observer plucks a transaction at random from the blockchain, with no further knowledge, what can they ascertain about 1) the sender, 2) the transaction, 3) the recipient
17:20:37 <sarang> Right. And then what can they learn if they have an idea of possible addresses
17:20:53 <Isthmus> Bingo
17:23:08 <sarang> I assume that there is (or will be) a more specific write-up with details on what relates to this chart?
17:23:22 <UkoeHB_> Earlier I argued you could brute force output amounts if the DLP is broken (assuming recipient address is unknown), however I'll retract that. Output amounts are information-theoretically secure.
17:23:40 <Isthmus> Gotcha
17:23:44 * Isthmus makes a note
17:25:31 <Isthmus> Yeah, this will all be in the research writeup, and more intuitive parts will be included in the general audience writeup
17:25:31 <sarang> Anything else to consider about your analysis at this point Isthmus?
17:25:44 <Isthmus> We were thinking about some medium articles throughout, just for good measure
17:25:56 <Isthmus> Nope, that's all on the quantum end for now
17:26:03 <sarang> OK great!
17:26:11 <Isthmus> I started going down a rabbit hole of subliminal channels this morning, but will save those thoughts for later
17:26:13 <sarang> Did anyone else wish to present research of interest?
17:27:41 <UkoeHB_> This means even if both DLP and hash preimage are broken, there should not be a way to extract the recipient's address from an output.
17:28:20 <Isthmus> That's a huge relief, or else we could recursively apply Shor's algorithm and move forward through the transaction tree breaking everybody's wallets
17:28:33 * Isthmus exhales a big sigh of relief
17:29:47 <sarang> I'll share a few things
17:30:16 <sarang> Here's a time-windowed CDF of spend age: https://usercontent.irccloud-cdn.com/file/5EccXpmE/cdf_window.png
17:30:48 <sarang> Still tracks the gamma distribution pretty well, but there are differences over time (pre-CT)
17:31:50 <sarang> Related to this, I posted my tracing code: https://github.com/SarangNoether/skunkworks/tree/tracing
17:32:10 <sarang> It now supports iterative updates, which may be useful
17:32:25 <sarang> Unrelated to this, I'm still working with the CLSAG auditors
17:32:48 <sarang> I rewrote the proof for Theorem 1 that relates unforgeability to non-slanderability, and it now addresses the auditors' suggestions
17:33:00 <sarang> There are a bunch of other non-security-related updates to it
17:33:27 <sarang> and I'm now in the process of overhauling the linkability anonymity proof to use a better hardness assumption and method, which is a tedious process
17:33:40 <sarang> but I think that will address their comments and be a stronger result
17:34:04 <sarang> The auditors' conclusion is that the construction seems secure, and that the security model seems appropriate to the use case
17:34:35 <sarang> This was the overall goal of the audit; suggestions relating to presentation, formality, etc. are very useful for later submission, but don't appear security-related
17:38:25 <UkoeHB_> Sounds like the audit is moving along well
17:39:01 <sarang> It is! The code review portion has not begun yet, but there are no changes in code to be made as a result of the preprint audit at this point
17:40:33 <sarang> Any questions on these research topics?
17:43:04 <sarang> OK, did anyone else have anything to share before we move on?
17:43:57 <sgp_> nope
17:44:03 <sarang> If not, we can move on to ACTION ITEMS for the coming week
17:44:47 <sarang> I will be finishing up this linkable anonymity overhaul and incorporating it into the preprint, which will complete the updates needed for the auditors
17:45:31 <sarang> Once that's done, I'll get the preprint in a submittable state
17:45:40 <sarang> Anyone else?
17:47:02 <sgp_> I'll be opening a GitHub issue for segregating coinbase outputs into coinbase-only rings
17:48:31 <sarang> It's a good time to discuss this, with an upcoming network upgrade for CLSAG at some point
17:48:38 <sgp_> yeah I think so too
17:48:39 <sarang> especially given the spend-age data
17:49:01 <sarang> I'd still love to see the corresponding data for bitcoin
17:49:06 <sarang> but I don't have that dataset
17:49:39 <sarang> all the Monero data is necessarily pre-CT because of deducibility
17:49:59 <sarang> and any post-CT deducible data spends old funds and is therefore basically useless for those kinds of distributions
17:50:29 <sgp_> I've been pretty clear that I think this BTC data would be nice but isn't necessary to make this change
17:51:15 <sarang> understood
17:52:12 <sarang> OK, anything else before we adjourn?
17:52:14 <UkoeHB_> Isthmus I have to walk back my walkback (sorry for the interruption sarang). You can definitely brute force it if the DLP and hash preimage are broken. Information-theoretic security means nothing in the face of brute forcing all possibilities (64 bits worth). You'd 1) get the DLP of generator H and the commitment C, 2) pick an amount, 3) compute the possible derivation to scalar, 4) get its hash preimage,
17:52:14 <UkoeHB_> 4a) use the key sequence of bits from the preimage to test the encoded amount and only continue if it matches the guessed amount (very unlikely to match if the guessed amount isn't correct) 5) use the key sequence of bits from the preimage to compute the one time address derivation to scalar, 6) subtract it from the one time address private key to get the nominal private spend key, 7) get the DLP of the
17:52:14 <UkoeHB_> preimage key with respect to the tx pub key to get the nominal private view key, 8) test if the spend key can produce the view key directly (normal address) or if any reasonable sub address index can be used to extract a spend key that produces the view key,  9) repeat 2-8 until you get a match (step 4a will probably catch most mistaken guesses). Let's blame this  mishap on a stray synapse.
17:53:38 <sarang> hmm
17:54:43 <Isthmus> ohhhhhh
17:55:08 <sarang> IIRC preimage on keccak is something like O(2^100) or so
17:55:38 <sarang> but I'd have to check on that
17:55:43 * Isthmus takes notes
17:55:49 <Isthmus> Unrelated: Does ZtM2 talk about variable types or just math? Trying to figure out if fees are uint64 or what
17:56:24 <UkoeHB_> They are varints, which I mention in section 6.3 footnote iirc
17:56:34 <Isthmus> Ah, perfect. Thanks!
17:59:51 <sarang> Righto, let's go ahead and adjourn since it's now 18:00 UTC
17:59:57 <sarang> Thanks to everyone for participating!
18:00:25 <sarang> UkoeHB_ Isthmus: specifying some complexity bound may be important
18:00:26 <UkoeHB_> Even if the preimage is broken you'd still have to pick the right preimage, which may be more difficult. The input is something like 100 bytes, since there is a string input (~8 chars?)
18:00:55 <sarang> You mean the fixed domain separators?
18:01:01 <UkoeHB_> Right
18:01:02 <sarang> Those are fixed
18:02:25 <UkoeHB_> Right, but doesn't it depend how the preimage is broken? If it's easy to find 1 preimage, it's not necessarily a useful one, or even one with the right number of bits
18:03:00 <UkoeHB_> Finding one preimage may be considered easy, while the correct preimage is hard/expensive
18:03:17 <UkoeHB_> Or even a nominally correct one
18:03:57 <sarang> Oh I see what you mean, since you need to perform additional work on particular preimages to actually gain anything useful
18:04:06 <sarang> right
18:35:41 <Isthmus> Ah interesting
18:35:58 <Isthmus> Does anybody have number of RingCT outputs handy?
18:36:17 <Isthmus> I know we dug it up in Noncesense DB a while back but I've lost track
18:39:17 <moneromooo> Should be: ./external/db_drivers/liblmdb/mdb_dump -s output_txs ~/.bitmonero/lmdb  | grep -E '^\ [0-9a-f]{96}$' | wc -l
18:39:23 <moneromooo> (running)
18:43:49 <sarang> Need it for any particular analysis?
18:44:40 <moneromooo> 40258823
18:44:59 <moneromooo> Oh, you know what. I counted all outs. nvm.
18:46:00 <moneromooo> 18407972
18:46:25 <moneromooo> That includes the v2 coinbase outs, which are deemed rct.
18:54:52 <Isthmus> ty
18:54:54 * Isthmus updates doc
18:55:40 <Isthmus> Thanks, I'm just braindumping stuff here: https://github.com/Mitchellpkt/subliminal_channel_audit/blob/master/README.md
18:55:51 <Isthmus> Definitely not a comprehensive list, please add your ideas :- )
18:58:52 <moneromooo> To keep up in the future: output_histogram @0
19:05:06 <sarang> What's the threat model for this Isthmus?
19:05:13 <sarang> In the case of a compromised wallet, you could lose all fund
19:05:14 <sarang> *funds
19:05:23 <sarang> Exchanges might be less likely to pull such shenanigans
19:06:30 <sarang> And `tx_extra` is by far the most straightforward way to include information
19:06:34 <sarang> as you well know
19:07:44 <sarang> This also seems somewhat related to previous preprints that identified ways to covertly (or not-so-covertly) generate transactions with provably-spent outputs
19:08:04 <sarang> One example was to use `N` identical rings of size `N`
19:08:16 <sarang> But this generalizes to the subset technique discussed in one of my MRL preprints
19:09:44 * sarang forgets the number
19:09:55 <sarang> MRL-0007
19:10:04 * sarang looked up the number
19:11:39 <Isthmus> I view surveillance and theft as two separate threats.
19:11:40 <Isthmus> You can imagine entities (AdTech sector, exchanges, governments, compliance entities, abusive exes, etc) who would be highly interested in surveillance and not theft.
19:11:52 <Isthmus> And if your goal is surveillance, then any theft would be highly counterproductive!
19:12:26 <Isthmus> As soon a you make an unauthorized transaction, user freaks out and gets new seed/software/tech support, so you shoot your surveillance campaign right in the foot
19:13:10 <Isthmus> Then user goes to reddit and everybody else uninstalls your thieving wallet
19:13:29 <Isthmus> But silent surveillance could go unnoticed for years if not indefinitely depending on the subtlety of the encodings
19:15:52 <Isthmus> If I worked in AdTech I'd release a really handy web browser extension Monero wallet for shopping, and then use subliminal messages to encode the domain of open tab(s) so I could start to build activity profiles
19:18:29 * Isthmus could dream up evil plans for secret data payloads all day 
19:19:21 <moneromooo> If your messages were superliminal, you could get a Nobel.
19:20:29 <Isthmus> Ahhahaha
19:20:44 <sarang> How do you view the risk of surveillance?
19:20:55 <sarang> If you're installing malicious code, that itself is a huge vector for risk
19:21:52 <sarang> I get the idea that applying some kind of intentional transaction fingerprint is bad, and I agree that transaction structure should be as uniform as possible anyway (even in case of unintentional fingerprinting)
19:22:15 <sarang> but I want to ensure that I fully understand what risks you're looking at that wouldn't already exist from malicious software
19:24:04 <sarang> The threat that I can see with this is if you assume the user can detect shady activity on their local device (standard malware detection?), but could not detect data exfiltration via transaction submission
19:24:11 <sarang> That seems a bit iffy to me
19:25:35 <sarang> In the example of those preprints that wondered what would happen if different entities hid their spent-output data in repeated or overlapping rings, one could imagine that it's surely easier for such entities to just use a side channel to identify their transactions, for example
19:25:46 <sarang> Meaning IMO the marginal risk is super low
19:26:04 <sarang> Not saying the overall risk is super low, just the marginal risk of such an on-chain method
19:41:44 <needbrrrrrrr90> I missed the meeting
19:41:46 <needbrrrrrrr90> Oh boy
19:42:54 <sarang> needbrrrrrrr90: any questions/comments/etc.?
19:43:03 <sarang> Logs available on GitHub and the log link in the topic
19:43:08 <needbrrrrrrr90> Gotta catch up first
19:43:14 <needbrrrrrrr90> I just woke up ;_;
19:43:41 <sarang> heh welcome to the world of the living needbrrrrrrr90
19:43:54 <sarang> Isthmus presented some post-quantum research results
19:44:00 <sarang> I talked about security proofs
19:44:09 <sarang> a whirlwind tour...
19:44:15 <needbrrrrrrr90> Ooh
19:44:24 <needbrrrrrrr90> Quantum stuff
19:44:29 <sarang> Isthmus's material was more interesting than mine :/
19:44:30 <needbrrrrrrr90> (yes I know quantum summons isthmus)
19:44:38 <needbrrrrrrr90> (quantum quantum quantum)
19:44:41 <sarang> Unless you're really into security models
19:44:45 <needbrrrrrrr90> Lol
19:45:12 <sarang> Oh, and worth mentioning that the CLSAG audit (related to the security proof stuff) is going very nicely
19:45:14 <hyc> this is monero after all ;)
19:45:19 <sarang> No major issues with the preprint
19:45:30 <sarang> But great suggestions on improvements, most of which are already done
19:45:41 <hyc> I missed the meeting too, had a sched conflict. but looks like all good news
19:45:51 <sarang> The last remaining thing is this security proof, for which I want to do more major revisions that will take a bit of time due to the subtlety
19:46:04 <sarang> At any rate, no code changes needed as a result of the preprint audit
19:46:20 <sarang> The auditors have done a wonderful job, and have been super responsive to my questions/comments
19:47:06 <sarang> Anyway, don't expect any tangible results on that until I get the proof stuff worked out on paper and then typeset
19:47:19 <sarang> After it's all done, I'll update the preprint on IACR and link it here
19:47:35 <sarang> Until then, it's just a ton of notes on paper :D
20:28:48 <sgp_> https://github.com/monero-project/monero/issues/6688
20:29:16 <sgp_> I'll leave this for comment here before I share on Reddit and Twitter
20:30:55 <moneromooo> You have been pushing this forever now. It should *only* get done *if* MRL gets a consensus that it is a good thing to do. Trying to get social pressure from random sybils makes me look pretty dimly at it.,
20:32:46 <sarang> moneromooo: One thing I don't recall discussing was any added storage/indexing complexity for doing a separate gamma pick on coinbase outputs
20:33:27 <sarang> In this case, I assume you'd do gamma on blocks instead, ignoring the weighting/shuffling portions we do now
20:34:14 <sarang> I do agree with sgp_ that it provides a benefit overall. I still hold that it makes certain heuristics somewhat marginally harder (but not necessarily significantly)
20:34:22 <sgp_> moneromooo: my intent in sharing it was not to try and sybil with randos
20:34:26 <moneromooo> I *think* that currently it'd be about the same (no added performance/memory), but that's assuming 1 coinbase out per block. Which is te case in practice, but not enforced.
20:34:56 <moneromooo> (and would not be the case with something like p2pool)
20:35:17 <sarang> In the case of multiple outputs, the current weight+shuffle method would work, albeit just on a list of coinbase
20:35:28 <sarang> choose-by-block is just the trivial version of that
20:35:38 <sarang> (since all weights are equal if you assume 1 coinbase/block)
20:39:17 <sarang> I'd like to devote some time in next week's meeting to specifically discussing the benefits and risks of this idea (and certainly discuss in the meantime)
20:40:21 <moneromooo> With more than one coinbase out per block, you'd need to send the number of sych per block in addition to the nubmer of total outs per block. So twice the data I think.
20:41:15 <moneromooo> I guess you could get clever and send separate data only for those blocks that have > 1 coinbase out.
20:41:30 <moneromooo> Which would be... no extra data in practice for now.