00:30:47 <sarang> This is a really insightful thread about Halo 2: https://forum.zcashcommunity.com/t/announcing-halo-2/37215
00:31:04 <sarang> I had wondered about the nature of the recursion, and if/how it could apply to actual Zcash operations
00:31:19 <sarang> Eran and Ian apparently share these questions, which don't appear to be answered by ECC here
00:39:06 <moneromooo> So Monero does not use ECC either.
00:39:23 <sarang> -___-
00:40:11 <sarang> Anyway, it does sound like the press release is... a press release
00:40:31 <sarang> and that the ways that Halo 2 could (if at all) be functional for practical Zcash operations has not been shown
00:40:36 <sarang> nor described
00:40:53 <sarang> s/operations has/operations have/
00:40:53 <monerobux> sarang meant to say: and that the ways that Halo 2 could (if at all) be functional for practical Zcash operations have not been shown
00:40:55 <sarang> good bot
00:41:12 <sarang> Another good lesson than press releases are often worth the air into which they are uttered
00:49:04 <sarang> That being said, Halo-style recursion is very interesting, and I hope they work out actual details on this
06:23:44 <knaccc> sgp_ it takes random 7-day windows starting Jul 2020 onwards,then picks n poisoned outputs randomly from that window
06:24:13 <knaccc> and each pair or set of n poisoned outputs is from a different 7-day window
06:41:55 <knaccc> and btw 43% of txs since Jul 2020 had >=2 outputs, so there are no lack of merge transactions generally
06:43:44 <knaccc> i could the miner txs as being txs for that stat. 5.8% are miner txs.
06:43:51 <knaccc> s/could/count
06:43:51 <monerobux> knaccc meant to say: i count the miner txs as being txs for that stat. 5.8% are miner txs.
07:09:47 <knaccc> also i meant to say 43% txs with exactly 2 outputs
07:22:45 <knaccc> 51% have >=2 outputs
13:23:29 <Inge-> question - the issue with combining multiple outputs in the same transaction, is that it proves you have control over both/all of them? But this is somewhat probabalistic, as each are a part of an 11-member ring? So with 2 it could be random chance, but with say combining 100 small exchange withdrawals or miner payouts, it gets pretty obvious?
13:24:22 <dEBRUYNE> Basically, yes
13:24:35 <dEBRUYNE> Also it is kind of different if the observer knows which outputs belong to the user
13:24:48 <dEBRUYNE> If two poisoned outputs are combined, the chance of the actual owner combining them is higher
13:25:05 <dEBRUYNE> In comparison to, say, two random outputs appearing in a transaction (and the observer not knowing which belong to the user)
13:28:05 <Inge-> e.g. 100 inputs to a TX, and all 100 rings contain at least one output that can be connected to say a mining pool?
13:28:48 <Inge-> and that would make for a strong probabilistic flagging of all those 100 outputs as having been used, and reduce the anonymity of other later transactions using the same ring members ?
13:52:52 <dEBRUYNE> If you know an output is provably spent, it may reduce privacy of other's using that output, yes
14:55:11 <sarang> Well, and if you have a heuristic, you can make some statistical inferences too
15:33:42 <sarang> Weekly research meeting starts here at 17:00 UTC (about 90 minutes from now)
15:33:43 <sarang> .time
15:33:43 <monerobux> 2020-09-02 - 15:33:43
15:33:46 <sarang> good bot
16:56:01 <Isthmus> First ROUGH DRAFT of vulnerability analysis with respect to quantum algorithms: https://github.com/monero-project/meta/files/5163665/pqMonero_technical_draft1.pdf
16:56:14 <suraeNoether> a lot more has been written but we are editing it like mad rn
16:59:26 <sarang> OK, let's start our research meeting
16:59:33 <sarang> The usual agenda: https://github.com/monero-project/meta/issues/502
16:59:36 <sarang> Logs posted there after the meeting
16:59:38 <sarang> First, greetings!
16:59:39 <sarang> Hello
16:59:42 <ArticMine> Hi
17:01:03 * Isthmus puts on goggles and lab coat
17:01:15 <suraeNoether> hihi
17:01:39 <suraeNoether> if we need eye protection for this meeting, i'm wearing open toed shoes so... uh...
17:02:53 <sarang> OK, let's move to roundtable, where anyone is welcome to share research topics of interest
17:03:09 <sarang> Isthmus: you had posted a paper draft on the agenda issue
17:03:44 <Isthmus> Yep, just a rough draft of the audit portion of our research. It's a bit long to digest on the fly, but if y'all have any notes to share over the next few days we'd greatly appreciate it
17:03:58 <sarang> This is great!
17:04:21 <sarang> You said it's still being edited... would an edited version be posted separately, to make it easier for corrections?
17:04:37 <Isthmus> Hm?
17:04:37 <sarang> Or should proofreading/review wait until edits are finished?
17:04:42 <Isthmus> Ohhhh
17:04:52 <Isthmus> Yea, for the portions that I posted, please tear them apart
17:05:00 <Isthmus> The parts that we're still editing were omitted from the draft shared above
17:05:01 <sarang> Having edits criss-cross across versions and ongoing edits might get confusing
17:05:03 <sarang> ok
17:05:14 <h4sh3d[m]> Hi
17:06:23 <sarang> I look forward to reading this Isthmus and suraeNoether
17:07:14 <sarang> Any questions for Isthmus or suraeNoether?
17:08:14 <Isthmus> Here is a link with EDIT access to the draft: https://www.overleaf.com/9835162385prbmyfckknyc
17:08:28 <Isthmus> For anybody who finds it more convenient to drop notes in LaTeX
17:08:40 <sarang> Are you comfortable having that link posted in the agenda issue logs?
17:08:40 <Isthmus> This is a fork of the paper, so it's ok to futz around
17:08:43 <sarang> oh ok
17:09:22 <Isthmus> Yep, I'd just ask that people leave notes on what they edit, either as a comment with `%` or using the \anote{} feature which is a custom command to drop in little notes
17:09:56 <sarang> You can also leave Overleaf comments on the side too
17:10:03 <Isthmus> Oh yea, that'd probably be even better
17:10:12 <sarang> Those have threading and resolution features
17:10:42 <sarang> Thanks for the update Isthmus and suraeNoether!
17:10:50 <sarang> I'll share a few things
17:10:58 <suraeNoether> overleaf appears to have recently bunked up their comments and review functionality a bit, and it's become temperamental for me
17:11:05 <sarang> Oh boo, that sucks
17:11:06 <suraeNoether>  heh /aside
17:11:30 <sarang> So the Triptych preprint was accepted to the ESORICS CBT workshop recently
17:11:48 <sarang> It'll be included in their proceedings, and I will also make a presentation on it later this month
17:12:09 <sarang> I had to do a recording of this in the event of technical difficulties, so thanks to sgp_ for helping me work out the details on that
17:12:35 <sarang> The preprint has been updated on IACR for corrections, the proceedings version has been prepared separately, the slides for the presentation are posted on GitHub, and I have the recording done as well
17:13:15 <sarang> sgp_ and I also interviewed CipherTrace's CEO, Dave Jevans, about a press release they made that received a fair amount of media attention
17:13:40 <sarang> That has occupied more of my time than I had expected
17:14:20 <sarang> and finally, I've been working with grydz to help them get the Ledger CLSAG firmware integration working
17:14:27 <sarang> Huge thanks to grydz for their hard work on this
17:15:05 <sarang> Any questions or comments for me on these topics?
17:15:49 <Isthmus> Thanks for pouring time & effort into the unexpected CipherTrace happenings
17:15:57 <Isthmus> Kind of a big fire to disrupt your workflow out of nowhere
17:16:05 <ArticMine> That interview was excellent
17:16:06 <Isthmus> Appreciate the context switching and great handling of that situation
17:16:09 <Isthmus> ^ sgp too
17:16:20 <sarang> Yeah, thanks to sgp_ for setting up that interview on such short notice
17:16:41 <sarang> I think it was very helpful, even if there was little in the way of specific information
17:16:46 <vikrants> hi.. Sarang was solid and taking no shit.
17:17:01 <sarang> It's worth notice that Dave _did_ confirm that his company makes their own transactions on chain as part of their analysis efforts
17:17:15 <sarang> I regret not following up on this at the time, but did submit questions on this to him afterward in writing
17:17:38 <ArticMine> I suggest going over it multiple time to get all the nuances. There is a lot of very valuable information there, that I really want to analyze
17:18:11 <sarang> Here is a link to the interview: https://www.youtube.com/watch?v=w5rtd3md11g
17:18:11 <monerobux> [ CipherTrace's Monero tracing tool - Chat with Dave Jevans, Dr. Sarang Noether, and Justin Ehrenhofer - YouTube ] - www.youtube.com
17:18:14 <ArticMine> Way more than meet the eye at a first glance
17:18:15 <sarang> good bot
17:18:44 <sarang> Dave also confirmed that the presence of a "flagged" output in a ring will raise the corresponding transaction's risk assessment
17:19:08 <sarang> Even if the transaction otherwise has no particular reason for being identified as more "risky"
17:19:12 <ArticMine> That is a big one even for Bitcoin
17:19:30 <sarang> I ensured that he confirmed an understanding of the non-interactive nature of Monero signatures, which he did
17:19:31 <sgp_> Oh hi :)
17:19:36 <sarang> Hi sgp_
17:20:32 <sarang> Anyway, sgp_ and I wrote some very specific questions that sgp_ sent in writing to Dave (yesterday IIRC)
17:20:39 <ArticMine> Dave also showed concern over the false positives and negatives in Bitcoin. A key weakness
17:20:40 <sgp_> Even so he confirmed they send poisoned outputs, likely against high-profile targets
17:21:05 <sgp_> The way he described the scope did not give me the impression they are "spamming" outputs
17:21:21 <sarang> Perhaps. This was one of the questions I posed in our follow-up
17:21:34 <sarang> Whether they do "general spam" or targeted spends only
17:21:53 <sarang> Anyway, AFAIK there has been no response yet to the questions, but it hasn't been that long since we sent them
17:22:13 <sarang> ArticMine: yeah, I was careful to point out concerns over false positives
17:22:29 <sarang> I did not leave with confidence about whether/how they try to avoid these in a meaningful way
17:22:49 <Isthmus> Tricky part about decoy-based anonymity... We add false positives, but there are no false negatives
17:23:02 <ArticMine> I am more convinced than ever they cannot even on Bitcoin
17:23:09 <sarang> I also remain skeptical about how they take (possibly many) heuristics and methods and try to distill to a single number with some arbitrary threshold
17:23:25 <sgp_> The tests have false negatives in practice though Isthmus
17:23:36 <sarang> Namely, that what this _actually means_ is perhaps not meaningfully conveyed to their clients
17:23:41 <Isthmus> I mean the transaction graph has no false negatives
17:23:51 <Isthmus> The metrics that you put on top of them may
17:24:04 <ArticMine> There is both sound math and compliance theatre
17:24:47 <ArticMine> This is why I want to carefully analyze the interview
17:25:07 <sarang> At any rate, I appreciate that Dave did the interview, though from a security perspective, making any design decisions based on the claims should be done extremely carefully
17:25:32 <sarang> I don't have any particular reason to think Dave was not telling the truth, but I also have no particular reason to think he was being overly forthcoming
17:25:34 <sgp_> Yeah, this changes nothing ultimately based on the current info we have
17:25:57 <sarang> This is, however, a good chance to review known methods
17:26:45 <ArticMine> I actually think we gained a lot of information. Even more that Dave was willing to give up
17:26:56 <sarang> How so?
17:27:17 <ArticMine> Confirming a lot of suspicions
17:27:32 <sarang> Well, again, these are all claims
17:27:40 <ArticMine> He was very clear on the Monero part was not ready for AML
17:27:44 <sarang> Without any evidence or details, everything is claims and speculation
17:27:55 <sarang> Including anything said in the interview
17:28:11 <ArticMine> The specific scenario speaks volumes
17:28:35 <Isthmus> Anything we hear that sounds like a plausible threat, we should take into account. Anything we hear that sounds like reassurance, we should distrust
17:28:45 <sarang> ^ right on
17:28:49 <ArticMine> I agree
17:29:24 <ArticMine> The about helping Monero with exchanges is a good example of false reasurance
17:29:58 <ArticMine> but as I mentioned this needs to be carefully analyzed
17:30:03 <sarang> Well, I'm sure they'd rather sell their tool to exchanges that support Monero, rather than see no exchanges support Monero at all
17:30:13 <sarang> (since they couldn't sell their tool in that situation)
17:30:40 <sarang> So there's probably some kind of business incentive related to exchanges
17:30:46 <sarang> but I'm no businesscritter
17:31:20 <sgp_> Maybe we can move on since this discussion isn't really related to research
17:31:27 <ArticMine> Even the slightest dent in Monero's privacy is a huge win from a sales perspective for them
17:31:38 <ArticMine> Yes lt move on
17:31:56 <ArticMine> let
17:32:20 <sarang> Fair enough
17:32:29 <sarang> Anyway, I recommend the interview to anyone interested in this
17:32:40 <sarang> Any other questions on the research topics I mentioned?
17:33:01 <sarang> If not, does anyone else wish to share research of interest?
17:33:22 <sgp_> Is knaccc here?
17:33:30 <sarang> Ah yes
17:33:34 <knaccc> hi
17:33:37 <knaccc> sorry been a busy day
17:33:43 <sarang> knaccc: you had shared some interesting information yesterday
17:33:45 <sgp_> They published some test results to review yesterday
17:33:49 <sarang> Care to summarize if interested?
17:34:08 <knaccc> i should take some time to think about it and do a writeup - my ability to summarize it now would be limited
17:34:23 <sarang> OK, no problem
17:34:29 <sarang> Can you at least set the scenario you are looking into?
17:34:33 <knaccc> sure
17:34:37 <sarang> Even if you aren't ready to share results
17:34:38 <sarang> Thanks!
17:34:59 <knaccc> so i have written a simple in-memory db that stores the blockchain graph
17:35:17 <knaccc> and i can ask questions about the blockchain much faster than if i needed to do 2 million calls to the daemon
17:35:24 <sarang> Pulls from RPC calls?
17:35:30 <sarang> Or directly from LMDB?
17:35:32 <knaccc> it loads everything in via rpc calls
17:35:35 <sarang> got it
17:35:46 <knaccc> but then it's all stored in memory and cached to disk so it doens't have to be re-read each time
17:36:03 <knaccc> it's kinda like a very rudimentary LMDB, it's a memory mapped file
17:36:13 <knaccc> with an index for ultra fast output lookups
17:36:21 <sarang> What's the analysis scenario?
17:37:02 <knaccc> well i write it so i could ask any kind of question i could think of. so if people have ideas, please let me know. i started with simply looking at the anonymity set sizes of outputs (going backwards in time)
17:37:24 <knaccc> to get an idea of how fast the anonymity set really grows when overlapping anonymity sets are involved
17:37:42 <knaccc> and to see whether the anonymity set size is limited when you limit the window during which you think someone may have tranascted
17:37:57 <sarang> neat
17:38:05 <sarang> I assume the code will also be made available?
17:38:11 <knaccc> and the other big question was: what is the probability that two outputs, chosen at random from the blockchain, are ever merged
17:38:14 <knaccc> fore sure
17:38:17 <knaccc> fure*
17:38:19 <knaccc> lol
17:38:19 <sarang> Yeah, merging is something to keep in mind
17:38:21 <knaccc> for*
17:38:30 <sarang> One simple merge would deal with outputs generated from the same transactions
17:38:35 <sarang> not randomly-selected pairs
17:38:37 <knaccc> and so i can detect direct merges, and indirect merges if churn could have been involved
17:39:05 <knaccc> yeah some really high-quality questions need to be thought of, for this to be useful
17:39:24 <sarang> I would like to see information initially on merging from common transactions, personally
17:39:47 <knaccc> great, i'm not sure exactly what you mean, but i'll ask you after the meeting and we'll figure it out
17:39:52 <sarang> FWIW the CipherTrace "example" posted to r/Monero claimed to be from their tool (without details or explanation), and at first glance appeared to be some kind of merge analysis
17:40:13 <knaccc> yeah that's a big problem that their analysis flagged
17:40:17 <sarang> To be fair, Dave Jevans later claimed in a comment that it was not a "simple merge analysis" (or some such wording), but during the interview wasn't able to provide any comment on this
17:40:45 <knaccc> if you give someone an output today, and another output a few days later, do you see them spend them together later? and if so, and if that spend is at an exchange, that's a big problem
17:40:49 <sarang> Anyway, I am skeptical that it isn't just a merge analysis with external flagging, at least in that example
17:40:55 <ArticMine> He needs that input correlations
17:41:00 <sarang> Right
17:41:08 <sarang> The correlations could come from known spends that flag outputs
17:41:16 <knaccc> yeah the key to most interesting insights is having off-blockchain data
17:41:16 <sarang> but one long-claimed heuristic is about the source of transactions
17:41:28 <sarang> where you flag outputs as being "in pairs" if they were generated in the same transaction
17:41:43 <sarang> it's a much simpler analysis, but one that's long been used to hypothesize a useful heuristic
17:41:58 <sarang> Getting at least this simple example understood better with chain data would be of value
17:42:23 <knaccc> sounds good
17:42:26 <ArticMine> That requires adversary between the sender and receiver of the XNR
17:42:38 <sarang> ArticMine: sure, but CipherTrace makes controlled spends
17:42:43 <sarang> and is presumably working with exchanges
17:42:50 <sarang> or getting exchange data from subpoenas
17:43:03 <sarang> So one should assume this is a threat vector
17:43:27 <ArticMine> Or more simply disgruntled customers
17:43:55 <ArticMine> way easier
17:43:58 <sarang> Anyway, this will be an interesting avenue of study
17:44:05 <ArticMine> and no GDPR
17:44:11 <sarang> I have also been working on scripting to do this analysis, but have not had a chance to complete it :(
17:44:29 <sarang> Anything else of interest knaccc?
17:44:38 <sarang> Or questions for knaccc?
17:45:02 <knaccc> not that i can think of. i think it'll be an interative process, where we ask questions, see results, and that prompt more interesting and important questions to explore
17:45:38 <sarang> for sure
17:46:03 <sarang> Does anyone else wish to share any research topics?
17:47:26 <sarang> OK!
17:47:42 <sarang> In that case, let's move to action items, where anyone is welcome to share their upcoming topics of research for the next week(s)
17:48:03 <sarang> I will be returning to work on Bulletproofs+, Arcturus, and some additional analysis I wish to complete on chain data
17:48:05 <sarang> Anyone else?
17:50:29 <sarang> Righto, in that case, we can adjourn!
17:50:48 <sarang> Discussion can of course continue, but I'll stop the logs here to post them
17:50:52 <sarang> Thanks to everyone for attending today
17:51:22 <h4sh3d[m]> Thanks
17:51:55 <ArticMine> Thanks
17:52:37 <Isthmus> gg
17:56:00 <knaccc> sarang whenever you have time, please could you explain that scenario you were interested in investigating, i still don't really understand. it sounded like you wanted to see if two outputs from a 2-out tx were ever later spent together, and i'm not sure what the idea behind that experiment would be
17:57:58 <moneromooo> I read it as "What is the probability that two random outputs on the chain ever get merged". Probably a graph over time.
17:58:07 <sarang> Not two random outputs
17:58:15 <sarang> Two outputs that were generated in the same transaction
17:58:33 <sarang> Or more than two outputs, fine
17:58:59 <sarang> So really it's looking at how likely it is for such outputs to later appear in separate rings of a single transaction
17:59:09 <moneromooo> Two random outputs means the false positive rate by chance, which is also useful.
17:59:36 <Isthmus> Why two outputs generated in the same output? I would expect one to be change to sender, and one to be payment to recipient.
18:00:06 <Isthmus> So I wouldn't expect them to rejoin unless they do a sloppy churn back into the same account
18:00:27 <sarang> Isthmus: right, but this kind of merge analysis is a simple heuristic that's been brought up before and I think is an interesting precursor to the idea of arbitrary flagged outputs
18:00:45 <sarang> If there's already interest in doing arbitrary flagging, taking care of this long-standing heuristic would be useful IMO
18:01:26 <Isthmus> "false positive rate by chance." << This to me is the BIG question that I'm excited about knaccc's work answering
18:01:39 <sarang> Yeah, of course
18:02:25 <sarang> Sorry, I don't mean to assume this common-tx idea should in any way take the place of a general analysis
18:02:40 <sarang> Only that it's been around for a long time and hasn't really been formally addressed with good on-chain distribution data
18:03:41 <knaccc> sarang i think i understand what you're asking, which is i just take some random tx, and see if the two outputs are ever spent together later, either directly or indirectly
18:03:52 <knaccc> i still don't really understand why yould take two from the same tx
18:04:04 <knaccc> i guess it makes sense when indirect
18:04:25 <knaccc> still not really clear though on the insight from getting two outputs from a single tx
18:04:30 <moneromooo> I guess it detects splits.
18:04:36 <moneromooo> Well, "detects".
18:04:48 <sarang> knaccc: it's some version of the common-ownership heuristic in non-ambiguous tx graphs
18:05:10 <sarang> I also don't think it's particularly useful given typical spend behaviors, but seems like a straightforward question to finally get answered
18:05:35 <knaccc> moneromooo oh you mean like a split to dice up change in your wallet, so you can spend later without waiting for change?
18:05:50 <sarang> It would also happen in that case, true
18:05:51 <knaccc> sarang cool, i'll do that experiment and let you know
18:05:54 <sarang> neat!
18:06:18 <moneromooo> I assume (but only assume) so.
18:06:42 <knaccc> what's the easiest place online for me to use as a kind of experimenter's notepad to write down the results for sharing
18:06:48 <knaccc> i guess i could do gists
18:07:14 <knaccc> it'd be nice to had edit control
18:07:24 <knaccc> to keep things organized later and not just as a stream of thought
18:09:02 <sarang> Gists have edit and history
18:09:13 <sarang> They're a single-file git repo, basically
18:09:36 <sarang> You can edit in-browser or using your favorite local editor w/ git tools
18:10:28 <knaccc> oh nice, cool that works
18:11:04 <sarang> Yeah, can just make it a secret gist and share the URL as you see fit
18:11:18 <sarang> edit control is still tied to your usual credentials anyway
18:12:08 <knaccc> perfect
18:12:40 <sarang> :D
20:44:56 <knaccc> sarang i hope this code is right, this is an interesting result. https://gist.github.com/knaccc/78c691aa1c1e0710bb8264ef17b56768
20:50:37 <knaccc> i'm running it again, this time choosing two random outputs instead of outputs from the same 2-out tx
20:51:10 <sarang> nice
20:51:15 * sarang waits
20:57:32 <Inge-> Question: what parts of monero protocol *won't* leak, given  advent of quantum computers?
20:58:52 <sarang> ^ Isthmus suraeNoether
20:59:04 <sarang> (they are on the team studying this specifically)
20:59:47 <Inge-> cool
21:00:03 <selsta> CipherTrace CEO person is active on Reddit again
21:00:07 <selsta> though not much new information
21:00:15 <sarang> How so?
21:00:23 <selsta> posting comments again
21:00:44 <sarang> Also: it's worth noting that there is sometimes a difference between "broken given a quantum computer" and "broken given a quantum computer and specific information as a hypothesis"
21:01:18 <sarang> selsta: details welcome
21:01:24 <knaccc> sarang gist updated https://gist.github.com/knaccc/78c691aa1c1e0710bb8264ef17b56768
21:01:28 <sarang> :D
21:01:30 <knaccc> i  really didn't expect that result
21:01:35 <knaccc> that's quite amazing.
21:01:40 <Inge-> sarang: for example, destination wallet adresses
21:02:24 <sarang> Inge-: AFAIK you can test this if you have a candidate address in mind
21:02:36 <sarang> Otherwise you need to enumerate, which is an infeasible process
21:02:40 <selsta> e.g. https://reddit.com/r/Monero/comments/il2c12/_/g3rhy41/
21:02:41 <knaccc> i don't really believe the result to be honest, looks too good.
21:02:41 <monerobux> [REDDIT] In Light of CipherTrace, Let's Talk Opsec (self.Monero) | 52 points (93.0%) | 19 comments | Posted by bawdyanarchist | Created at 2020-09-02 - 07:27:16
21:03:58 <sarang> OK, that comment addresses nothing
21:04:09 <sarang> FWIW, Dandelion++ is not intended to address targeted attacks
21:04:14 <sarang> and was never claimed in this way
21:04:44 <sarang> Dave claims new heuristics, but talk is cheap, and reddit comments are even cheaper
21:07:06 <Inge-> Kudos for engaging at all
21:07:49 <Inge-> outright lying seems like a bad move all round. Creatively applied wording more likely
21:08:07 <sarang> I'm responding to several comments
21:08:23 <sarang> I don't fault him for not knowing the math, but I'll talk details with any member of his team whenever they like
21:08:26 <sarang> name the time
21:08:39 <sarang> He sounds upset that I asked questions not on the prepared list
21:08:43 <Inge-> "We will not be discussing further technical approaches at this time"
21:08:59 <sarang> They aren't under any kind of obligation to discuss anything
21:09:05 <sarang> they're a private company
21:09:44 <sarang> What I will not do is let him get away with "I am not the math person, therefore what can ya do"
21:09:58 <sarang> He's free to refuse further questions, but not to say that it's because of the research community
21:13:10 <sarang> My take is that the responses sound much more defensive than would otherwise be indicated from the tone of the interview
21:18:12 <suraeNoether> inge: a single one-time address won't be sufficient to go back to someone's whole key :)
21:18:18 <suraeNoether> Inge- rather
21:18:30 <suraeNoether> but basically everything falls apart with quantum
21:18:45 <suraeNoether> which isn't surprising, it's true of Wells Fargo and Amazon and Zcash and Bitcoin and... etc
21:19:05 <suraeNoether> and i'm still thinking about transaction linkability and suchlike
21:21:34 <Inge-> suraeNoether: so qc + wallet address = you can get to wallet private key? and also determine the actual destination address that wallet sent to, via only on-chain tx and sender private key?
21:24:19 <sarang> QC can do arbitrary discrete logs
21:24:24 <sarang> so any direct public -> private key map is trivial
21:24:54 <suraeNoether> Well you can't use the wallet private key to reconstruct old transactions by looking at the block chain. But you definitely own their private keys if you are a quantum adversary
21:25:31 <moneromooo> In sqrt rather then linear though, right ? So doubling key length gets around that in theory ?
21:25:52 * moneromooo not sure that's confused with something else
21:26:02 <suraeNoether> the sqrt thing is true for inverting hash functions or one-way functions using grover's algorithm. i'm not sure about the discrete log break with shor's
21:26:16 <suraeNoether> i will find out in a bit
21:26:19 <moneromooo> ty
21:31:14 <Isthmus> Doubling key length is an "effective" way to kick the can down the road with Grover's algorithm specifically.
21:31:52 <sarang> Of course, "switching curves" is... nontrivial...
21:32:13 <sarang> although twisted edwards curves targeting higher security levels absolutely exist
21:32:17 <sarang> e.g. ed448
21:32:29 <moneromooo> Kicking it down the road meaning it doesn't give you the same strength as before ?
21:33:01 <moneromooo> Or that there might be better than Grover's suspected but not yet found ?
21:40:22 <Inge-> suraeNoether: but owning their private key still requires access to what first tho? wallet address?
21:41:35 <sarang> Wallet private key? Or output private key?
21:42:00 <Inge-> I was thinking wallet private key
21:42:19 <sarang> Well, at some level that's irrelevant
21:42:29 <sarang> If you can compute DLs, you can get output private keys and sign with them
21:42:36 <sarang> thereby spending arbitrary funds at will
21:43:50 <Inge-> Iwould distinguish between spending funds and unraveling privacy
21:44:45 <sarang> Yes
21:45:01 <sarang> But knowing wallet private keys does not necessarily equate directly to breaking privacy, whatever that is intended to mean
22:20:23 <suraeNoether> Inge-: yeah, public wallet address is sufficient.
22:20:39 <suraeNoether> Inge-: also, transaction amounts are still perfectly hidden
22:20:50 <sarang> Under the assumption of hash function security?
22:21:27 <sarang> Because if you can do shared secret, you can get amounts
22:33:21 <Isthmus> There are threeish things that don't break. As long as you've *never* received funds twice to the same address, a QA who only has access to the public blockchain data cannot break stealth addresses, or decrypt amounts & encrypted payment IDs
22:33:55 <Isthmus> But if you've received funds to the same address twice, then your private key can be extracted by a QA, which then enables them to calculate txn shared secret and decrypt the amount and payment ID
22:34:16 <Isthmus> (^ still using nothing but data that is public on the blockchain)
22:35:53 <Isthmus> Core wallet reuses change address though, right?
22:40:11 <Isthmus> In the paper, we assume that the attacker only has access to public data on the blockchain, unless explicitly mentioned otherwise. But I'm going through now to add some more notes to make that clearer.
22:40:47 <Isthmus> We always assume that the attacker is NOT a party in the transaction
22:41:11 <Isthmus> So the only exceptions are when the attacker knows of an address (e.g. section on extracting k_s from K_s)
22:41:24 <Isthmus> But I'll clarify within sections to avoid confusion
22:49:54 <sarang> Yeah knowledge of a list of possible addresses is of interest to me too
23:25:40 <Isthmus> Oops, there is one other exception - in the "Violate transaction balancing" we assume that the attacker is the sender