00:28:28 <br-m> <kayabanerve:matrix.org> With FCMP++, I zealously limited to the odd-prime-order subgroup so we don't even have to discuss the implications of torsion.
00:32:12 <br-m> <kayabanerve:matrix.org> IIRC, it's a constant headache, generally effects an incomplete prover, cannot be used for any generator for which a diffie-hellman is then performed against, and I think the order-2 point doesn't have a representation on Wei25519 so some of the maps we use would be incomplete if over the entire group of order 8l.
00:35:06 <br-m> <kayabanerve:matrix.org> Other than the order-2 point, I don't believe there'd be soundness issues with points of composite order though, solely completeness and zero-knowledge issues.
11:10:34 <tevador> freeman:cypherstack.com The original idea behind CSIDH comes from this paper by Couveignes: https://eprint.iacr.org/2006/291.pdf (written in 1997, published in 2006). The difference from CSIDH is that Couveignes used ordinary curves, not supersingular ones, otherwise it's nearly identical.
11:10:58 <tevador> I would say that the statement that "SIDH is a predecessor of CSIDH" is unfounded. They are based on different assumptions. The break of SIDH is completely unrelated to CSIDH (it requires torsion point images, which don't exist in CSIDH).
11:11:23 <tevador> The logic "SIDH was broken, therefore using CSIDH makes me nervous" also applies to code based crypto if you substitute "SIDH" for "Niederreiter cryptosystem" and "CSIDH" for "McEliece cryptosystem".
11:29:18 <tevador> This presentation has a good summary of code-based crypto history (slide 16/33). It's full of broken algorithms. https://ctcrypt.ru/files/files/2021/Deneuville_CTCrypt21.pdf
13:55:54 <br-m> <sgp_> tevador: are there any promising PQ research areas where, in your view, it would be worth paying for more research to see if they would unlock certain major gains?
13:56:08 <br-m> <sgp_> the answer might be "not really" but I figure I should ask!
14:28:49 <tevador> For Jamtis? Not really. But further PQ research is needed for fully PQ Monero, which includes PQ soundness for membership proofs, commitments and signatures.
15:20:55 <br-m> <freeman:cypherstack.com> > <tevador> I would say that the statement that "SIDH is a predecessor of CSIDH" is unfounded. They are based on different assumptions. The break of SIDH is completely unrelated to CSIDH (it requires torsion point images, which don't exist in CSIDH).
15:20:55 <br-m> <freeman:cypherstack.com> To say that they are completely different assumptions because one communicated the auxiliary points and the other doesn’t is not true. Both rely on the Supersingular Isogeny Path Problem, just CSIDH restricts to a subgraph with symmetry.
15:24:05 <br-m> <freeman:cypherstack.com> tevador: Not really sure what your point is here… Niederreiter and McEliece are not broken at all! In fact, if you restrict to Goppa codes, they’ve remained pretty much exactly as secure as when they were proposed in the 70’s - SDP is the oldest, most well respected PQ problem! 😁
15:25:04 <tevador> By Niederreiter cryptosystem, I mean the original Niederreiter proposal using Reed Solomon codes.
15:25:52 <tevador> Published in 1986, broken in 1992.
15:26:43 <br-m> <freeman:cypherstack.com> Niederreiter is simply the dual of McEliece. I’ll admit there have been problems selecting codes which are too structured, but that’s just selecting bad parameters. Like saying that elliptic curves are broken because somebody proposed then with p=11. Nope, still fine, just a poor choice of parameters.
15:27:22 <tevador> As for CSIDH, I didn't say *completely* different assumptions. But they are different assumptions, with the SIDH assumption being stronger.
15:28:59 <br-m> <freeman:cypherstack.com> As an aside, I’m decently sure that CSIDH only enjoys subexponential quantum security? But I’ll have to make sure
15:29:28 <tevador> Yes, that's correct. There is Kuperberg's algorithm, which is subexponential.
15:29:59 <tevador> "elliptic curves are broken because somebody proposed then with p=11" - bad example. Reed Solomon codes were genuinely thought to be secure for 6 years.
15:30:47 <tevador> It doesn't mean Gopa codes can't be broken in the future in the same way.
15:31:21 <br-m> <freeman:cypherstack.com> Well okay, p on the order of 10^4 then. When they were first proposed, this would be secure, but now it’s not. That’s my point - it’s just a change of parameters, not a break break
15:31:54 <tevador> OK, we can use the same defense for CSIDH - CISH was just using "bad parameters".
15:32:00 <tevador> SIDH*
15:33:50 <br-m> <freeman:cypherstack.com> Look, I’m not urging caution because  I’m biased against isogenies. Hell, I have an isogeny paper that’ll come out this year. My worry is that, as a cryptographic problem, it’s not mature enough. Time may show that I’m wrong, but we need to be VERY careful about jumping the gun, or it’ll be the end of Monero
15:34:02 <br-m> <freeman:cypherstack.com> tevador: Uh, no we cannot in fact 😶‍🌫️
15:34:45 <br-m> <freeman:cypherstack.com> For SIDH, the underlying problem is broken. Full stop. For McEliece, it is not.
15:36:26 <tevador> The underlying problem is the isogeny path problem, which is not broken. SIDH just just a bad instantiation with auxiliary points.
15:38:34 <tevador> Why they used auxiliary points? Because isogenies over F(p^2) are not commutative, so you can't have a Diffie-Hellman-style shared secret without extra steps. If you switch to F(p), there is no need for auxiliary points.
15:39:00 <tevador> So it's the same situation as with the broken code, IMO.
15:41:32 <tevador> In the unlikely case that CSIDH is broken, then it's not the end of Monero. The security of the addressing protocol would just be reduced to the ECDLP problem, which Monero is already using now with legacy addresses.
15:43:15 <tevador> So the entire risk of using CSIDH in Jamtis is the extra ~180 characters it adds to addresses and ~130 bytes it adds to each transaction. I think this is quite a favorable bet for the safety of CSIDH.
15:44:17 <br-m> <freeman:cypherstack.com> When McEliece using X code was broken, nobody was panicking, or even surprised. The underlying problem is still hard! When SIKE was broken, the field was left scrambling to find a solid alternative, as that was their golden child. Now it’s completely dead, with no fixing.
15:45:05 <tevador> CSIDH is not dead. The underlying problem of isogeny based crypto is not broken. This is just FUD.
15:46:14 <tevador> SIKE as originally proposed can't be fixed because it needs auxiliary points. But there is no reason panic and say all isogeny based crypto is doomed.
15:47:44 <tevador> I think the situation is exactly the same as when X code was broken for code based crypto. The only difference is the timing - the break of SIKE came at the high of the NIST PQ competition, so there was a lot of publicity.
15:49:40 <br-m> <freeman:cypherstack.com> Let me present it a different way: has NIST ever standardized an isogeny-based algorithm? If not, how can you say you really trust it?
15:50:56 <tevador> Has NIST standardized Blake2? How can you say you really trust it?
15:55:51 <tevador> On the other hand, NIST standardized Dual_EC_DRBG, which included a backdoor. And the standardization of Kyber has been criticized by some cryptographers, e.g.: https://blog.cr.yp.to/20231003-countcorrectly.html
15:57:44 <br-m> <freeman:cypherstack.com> tevador: NIST HAS standardized hash-based algorithms! SPHINCS+, XMSS, SLH-DSA…. In fact, they were the first PQ algorithm to be standardized
15:57:44 <tevador> ^ This blog post argues that NIST should have chosen NTRU over Kyber.
15:58:50 <br-m> <freeman:cypherstack.com> I see what you’re saying, but a bump in the road… what, 20 years ago is not enough evidence to say that we should never trust anything they do ever again imo
16:00:52 <tevador> The simple reason why NIST hasn't standardized any isogeny based crypto is that the only proposal (SIKE) was broken. CSIDH didn't participate. I'm not saying CSIDH would have been standardized, but it offers better tradeoffs for Monero use cases than the "standardized" algorithms.
16:07:17 <br-m> <freeman:cypherstack.com> Which, I promise, I understand. My argument is urging caution, that just because it’s the best algorithm doesn’t mean it’s the best algorithm
16:16:42 <tevador> Practically speaking, we have 2 options for Jamtis: 1) Ignore PQ privacy and implement a classical addressing protocol (this was the original plan for Seraphis) 2) Add CSIDH hybrid encryption for some PQ privacy with acceptable costs.
16:17:00 <tevador> If we choose some other algorithm like McEliece, the new address format will be impractical and people will just continue using legacy addresses, negating any benefits of Jamtis (it has more privacy features than just PQ encryption).
16:18:33 <br-m> <freeman:cypherstack.com> Yeeeah definitely don’t do option 1. Is CSIDH really the only viable option here? Surely not…
16:19:49 <br-m> <jpk68:matrix.org> tevador: You can fit a SWOOSH public key in only 22 JAB codes :P
16:20:25 <tevador> freeman: Do you have an alternative in mind? I'm open to ideas.
16:21:00 <moneromooo> How about... generating an "art" png file from large addresses, and people just trade images ? No cut/paste, copying by hand. If images are deterministic from the data, people can see at a glance if two addresses are not the same (assuming avalanche characteristics). The png would need to be several times larger though, not to look like random noise. Similar to ssh ascii art for keys.
16:21:22 <moneromooo> And a bit similar to how github creates "random" images to represent users.
16:22:32 <moneromooo> Oh wait. IIRC someone from mrl actually did this I think. That's probably what drove me to that :D
16:22:49 <tevador> McEliece is appealing for its small blockchain footprint (still larger than CSIDH), but addresses would be massive. 
16:22:58 <br-m> <freeman:cypherstack.com> If you need a key exchange mechanism, why not ML-KEM?
16:23:21 <br-m> <freeman:cypherstack.com> I guess what do you need from a cryptosystem in your setting, and what do you want?
16:23:23 <tevador> Because it would ~triple the pruned blockchain size.
16:34:35 <br-m> <freeman:cypherstack.com> 3x is better than 1.5x with a risk of it being broken 😬
16:34:50 <br-m> <freeman:cypherstack.com> Say CSIDH is cracked open tomorrow. What’s the fallback?
16:35:11 <tevador> Are you saying that there is no risk of ML-KEM to be broken?
16:35:36 <tevador> My personal requirements for Jamtis to be practically usable are: Addresses max 420 characters and max +50% average pruned transaction size. CSIDH-1024 just about fits these constraints.
16:36:10 <tevador> If CSIDH is broken, Jamtis reverts to Option 1 (classical only security)
16:37:36 <tevador> Here is a nice picture how lattice security has degraded compared to McEliece: https://classic.mceliece.org/comparison.html
16:39:06 <br-m> <freeman:cypherstack.com> Lol yeah that’s one of my favorite graphs to show PQ cryptographers, I use it in a lot of my presentations
16:39:28 <br-m> <freeman:cypherstack.com> Ironically, with the message that codes are better than lattices, so to hear me support lattices means I really don’t believe in isogenies
16:39:55 <tevador> IMO, the risk of CSIDH being broken is not substantially higher than the risk of ML-KEM being broken.
16:41:58 <tevador> BTW, there is some shared risk between CSIDH and lattices: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/OpFVbuMYk8c/m/-E5lL2-LAwAJ
16:42:09 <br-m> <freeman:cypherstack.com> I am quite confident most PQ researchers do not view it that way (admittedly, from my own very biased personal experience)
16:42:53 <tevador> ^ citation needed
16:43:49 <br-m> <freeman:cypherstack.com> Yes absolutely, please take that with a very large grain of salt
16:45:52 <br-m> <freeman:cypherstack.com> Look, if it turns out I’m dead wrong about this, I’m not too big to admit my mistakes. That said, imo, the devil that we know is better than the devil that we don’t know, even if it results in larger sizes
16:48:09 <tevador> {Secure, Usable, Private} - choose 2. This is the trilemma for Jamtis.
17:53:34 <br-m> <kayabanerve:matrix.org> I believe we're at a point text-based addresses have to be deprecated and moving forward, the expectations should be an address registry or a giant blob. To that end, I wouldn't even say McEliece is unacceptable in the future.
17:54:06 <br-m> <kayabanerve:matrix.org> Even post-quantum view keys push it, before we discuss full PQ cryptography.
17:55:28 <br-m> <kayabanerve:matrix.org> I briefly ideated on a PQ composition before I stepped back, and while that's a shell of a proposal, I'd note for a PQ Monero, the first step should likely be deciding the on-chain commitment scheme, delegation of responsibilities, and ensuring the desired wallet protocol can compose with it.
17:56:31 <br-m> <kayabanerve:matrix.org> I do think immediately, any PQ KEM can be discussed. While CSIDH can be questioned re: the next century, I don't think it's unacceptable for use here, especially as we need to start taking steps.
17:57:36 <br-m> <kayabanerve:matrix.org> Also, re: the next five years, but so can a variety of schemes. I don't believe we've immediately solved the hurdles necessary to propose McEliece, and I can't support Kyber even being considered.
17:58:22 <br-m> <kayabanerve:matrix.org> We can discuss NTRU schemes vs CSIDH, but I think for now, tevador has properly made the best suggestion with CSIDH being our first step (parameters still being discussed).
17:59:20 <br-m> <kayabanerve:matrix.org> If Kyber wasn't encumbered by parents except for the exact variants standardized, I would say it can be considered, but I think NTRU still out-performs it...
18:00:00 <br-m> <kayabanerve:matrix.org> Like, the fact ML-KEM is legal but then parameterizable Kyber isn't is absurd and should never have been accepted 
18:00:30 <br-m> <kayabanerve:matrix.org> I get it doesn't matter for government checklists as the checklist would be explicit to the government's parameters but I just can't endorse any use of ML-KEM/Kyber for FOSS.
18:00:59 <br-m> <freeman:cypherstack.com> I’m honestly surprised at the Kyber hate here, I figured it would be the natural first choice 😅
18:02:26 <br-m> <kayabanerve:matrix.org> @freeman:cypherstack.com: Kyber is patented except as ML-KEM. That should immediately discount it.
18:02:35 <br-m> <freeman:cypherstack.com> Isn’t the reference implementation public domain? I admit patent law isn’t my forte, but aren’t tons of optimized versions freely available?
18:02:43 <br-m> <freeman:cypherstack.com> Aah I see
18:03:19 <br-m> <kayabanerve:matrix.org> The existence of implementations doesn't change the underlying math is subject to license requirements for which the public grant is only as standardized by NIST, AFAIK.
18:03:50 <br-m> <kayabanerve:matrix.org> Then, with how its security has been challenged, I legitimately thought NTRU-family schemes were more efficient at comparative security levels. I'm unsure why we'd prefer Kyber to NTRU Prime or similar.
18:05:00 <br-m> <freeman:cypherstack.com> What I pictured this process would look like is considering a broad selection of cryptosystems from different families, then weighing their respective pros and cons
18:05:01 <br-m> <kayabanerve:matrix.org> NTRU Prime vs. CSIDH can be discussed, but that doesn't change the more efficient CSIDH is still challenging to deploy. While it _may_ be a riskier a bit, the conservative options struggle to hit feasibility at our scale.
18:05:32 <br-m> <kayabanerve:matrix.org> We can say that's an issue with our scale, and we have to redesign our ecosystem, and that's likely true. That proposal would take years. An address with CSIDH hopefully takes a year.
18:06:17 <br-m> <freeman:cypherstack.com> I fear that CSIDH hits your usability and privacy goals, leaving security the odd one out 😅
18:06:25 <br-m> <kayabanerve:matrix.org> @freeman:cypherstack.com: You are welcome to create an overview document for various cryptosystems, write opinions, create charts, and discuss which option is objectively best within certain parameters. It isn't that that can't be the process. It's that the process needs a champion.
18:06:56 <br-m> <kayabanerve:matrix.org> tevador is championing PQ view keys via CSIDH right now, and that would win by default without an alternative successfully championed.
18:07:16 <br-m> <kayabanerve:matrix.org> (Not to say there should be no discussion, to say the only way this becomes a full forum is if someone does the work to create a full forum)
18:07:40 <br-m> <kayabanerve:matrix.org> Right, so the question is, do you have something which achieves the trifecta and a more complete analysis which is sufficient for consideration?
18:07:54 <br-m> <kayabanerve:matrix.org> Open discussion on the topic has to cascade into that to be pragmatic
18:08:37 <br-m> <kayabanerve:matrix.org> It's kinda a 'get involved or watch as it happens', which is kinda jerkish, sorry, and I know you are getting involved by your discussion here
18:09:35 <br-m> <freeman:cypherstack.com> Nothing will achieve the trifecta. My view is that a secure, large protocol may eventually be made smaller, while a small, immature protocol may be outright dangerous
18:10:01 <br-m> <kayabanerve:matrix.org> But the very practical comment is calling for more review requires someone do the work (which I personally trust tevador to have done, and as I am not doing the work myself right now, am accepting I'm deferring to tevador accordingly)
18:11:17 <br-m> <kayabanerve:matrix.org> But for now, we have three options:
18:11:17 <br-m> <kayabanerve:matrix.org> - Do nothing
18:11:18 <br-m> <kayabanerve:matrix.org> - Usable, private
18:11:18 <br-m> <kayabanerve:matrix.org> - Usable, secure
18:11:18 <br-m> <kayabanerve:matrix.org> - Private, secure[... more lines follow, see https://mrelay.p2pool.observer/e/xuCikoELc25jSVBC ]
18:12:21 <br-m> <kayabanerve:matrix.org> So then the question is, what's usable and an improvement on today? Also using CSIDH would be strictly better, and while it may be comparatively risky, the goal would be parameters people actually use.
18:12:21 <br-m> <kayabanerve:matrix.org> Possible security that maybe applies to people is practically better than definite security which applies to no one.
18:14:29 <br-m> <kayabanerve:matrix.org> I'm unsure if I'd actually recommend CSIDH hybrids as PQ, but I can definitely recommend it as better. I also think the project has a whole has an engineering backlog. jberman can comment extensively on how monerod, internally, has been improved to scale and handle load due to the stressnets, FCMP++ upgrade. We also have somew [... too long, see https://mrelay.p2pool.observer/e/6cGukoELem92VTJC ]
18:14:51 <br-m> <kayabanerve:matrix.org> *as a whole has
18:15:51 <br-m> <freeman:cypherstack.com> Maybe a little inside baseball, but if the CSIDH key exchange is selected, are you planning to implement isogenies elsewhere? Like Calamari for the linkable ring sig?
18:16:01 <br-m> <kayabanerve:matrix.org> TL;DR PQ crypto slow. How do we do better today? What should we try to work on for tomorrow? Are we dismissing doing better today because it isn't as good as what we can do tomorrow? Who's actually working on this?
18:16:23 <br-m> <kayabanerve:matrix.org> We don't have active discussions on a PQ protocol :////
18:16:52 <br-m> <kayabanerve:matrix.org> My sketch of one would likely be Ajtai commitments, FRI, and Threshold Raccoon. Maybe a LWE balance, range proof.
18:17:36 <br-m> <freeman:cypherstack.com> Love it, thanks for the insight
18:18:02 <br-m> <kayabanerve:matrix.org> The main reason for FRI is yes, we can have giant proofs for every step and can have it be horribly slow. we will need to design and develop multiple proofs. FRI is one black box that gives us multiple proofs. It'd be a fraction of the work than on six tailored proofs all to optimum with security we're confident on.
18:18:16 <br-m> <kayabanerve:matrix.org> Slow and secure today, to buy time to decide on fast and secure tomorrow.
18:19:05 <br-m> <kayabanerve:matrix.org> Though FRI may not be 'usable', but also, when we move to PQ soundness, it will be a 'too bad' moment. We deploy something we know is secure and private or the protocol disappears overnight.
18:20:17 <br-m> <kayabanerve:matrix.org> For JAMTIS, today, it's just about what's the best chance to give the most people the most privacy post a QC appearing.
18:20:45 <br-m> <kayabanerve:matrix.org> Hence CSIDH scoring highly.
18:23:21 <tevador> Note that Jamtis is not just about PQ privacy. That's just being bolted on. It has other important features. Killing Jamtis with an unusable PQ scheme would be a shame.
18:25:31 <tevador> freeman: The main question is if using CSIDH is better than nothing and the answer is likely yes.
18:26:19 <br-m> <freeman:cypherstack.com> If that’s the question, and legitimately no other alternatives are possible, then yes I agree
18:28:24 <tevador> Here are some numbers: https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832#appendix-d
18:30:35 <br-m> <freeman:cypherstack.com> Huh, it’s actually pretty surprising to me that the McEliece blockchain size is not that much worse than CSIDH
18:31:44 <tevador> Yes, in that sense McEliece is more acceptable than NTRU
18:35:30 <br-m> <kayabanerve:matrix.org> @freeman:cypherstack.com: That's for option A, hiding amounts, not B, also receiver unlinkability, though.
18:36:26 <br-m> <kayabanerve:matrix.org> ... right? Am I misreading this?
18:37:11 <br-m> <kayabanerve:matrix.org> Pretty sure that's read correctly after a brief moment of uncertainty.
18:39:29 <br-m> <freeman:cypherstack.com> https://mrelay.p2pool.observer/m/cypherstack.com/JPYaEZWeOrfaJuQGjZsqGNjm.jpeg (ima_3966469.jpeg)
18:39:45 <br-m> <freeman:cypherstack.com> This table just caught my eye is all
18:40:36 <tevador> kayabanerve: correct, AC1024 is for PQ amounts, BC512 is for PQ secondary view tags + amounts.
18:41:41 <tevador> sgp_ was arguing for BC512, my preference is AC1024
18:46:49 <tevador> Seeing that AC1024 and BC512 have nearly identical costs, I think both would be acceptable. It's a privacy <-> security tradeoff.
19:48:11 <br-m> <kayabanerve:matrix.org> I don't think an improvement to amount privacy alone is worth the introduction of a PQ primitive tbh and would advocate BC512
20:59:21 <br-m> <koe000:matrix.org> @kayabanerve the SpendAuthAndLinkability challenge does not include any 'personal' bytes. Carrot hashes include the personal string "Monero". Can I convince you to add this to the monero-oxide impl? And probably other places that use transcripts also.
21:31:30 <br-m> <gingeropolous> yeah i think regarding the harvest then decrypt concern it'd be more damaging to be able to reconstruct a tx graph than to reveal amounts. 
21:36:23 <tevador> Even with Option A (hidden amounts + linking tags), QA cannot construct a transaction graph. If the QA has Alice's and Bob's Jamtis addresses, they can see enotes coming to their wallets (without amounts), but cannot infer that they are transacting with each other.
22:15:16 <br-m> <neptunian:unredacted.org> @kayabanerve:matrix.org: Possibly a silly question, last I read, CSIDH512 had low-ish security estimates. Would it still be viable?
22:42:54 <br-m> <kayabanerve:matrix.org> @koe000:matrix.org: Keyed or personalized?
22:43:31 <br-m> <kayabanerve:matrix.org> RFC 7693 defines keyed hashing but didn't standardize personalization
22:44:26 <br-m> <kayabanerve:matrix.org> I'm not saying that RFC defines Blake2, I'm just asking for clarity on which is already being used and trying to understand the portability impacts
22:46:39 <br-m> <kayabanerve:matrix.org> Ugh, we would want personalization and the fact the RFC didn't standardize that is annoying
22:47:01 <br-m> <kayabanerve:matrix.org> I'm not against personalizing the SA+L transcript with "Monero"
22:48:51 <br-m> <sgp_> tevador: I need to think more about this to see how serious of a privacy regression this is, before agreeing it's relatively trivial
22:49:57 <br-m> <sgp_> Losing plausible deniability of receiving funds at an address could be a relevant privacy consideration for some
22:54:04 <br-m> <neptunian:unredacted.org> @sgp_: I'd agree. I'd actually consider it relevant as well, given it can lead to some nasty rubber-hosing.
22:54:13 <br-m> <neptunian:unredacted.org> Along with various other issues...
22:54:21 <tevador> I think we can reduce it to these two options (AC1024 or BC512) and discuss it at the next MRL meeting.
22:54:44 <br-m> <neptunian:unredacted.org> tevador: This will probably be my first time attending, lol.
22:54:47 <br-m> <neptunian:unredacted.org> See you there ;)
22:56:06 <br-m> <sgp_> Is the only major argument against BC1024 the large addresses? I personally don't want to throw out based on address size
22:57:00 <tevador> I think the pruned blockchain bloat is worse than the address length. You can avoid the long addresses by not using them. You can't avoid storing the bloat.
22:57:47 <br-m> <neptunian:unredacted.org> tevador: How much would BC1024 bloat the blockchain?
22:58:46 <br-m> <torir:unredacted.org> https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832#appendix-d
22:58:57 <br-m> <torir:unredacted.org> Oh, BC1024 isn't in that list.
22:59:04 <br-m> <jpk68:matrix.org> It doesn't mention it
22:59:07 <br-m> <neptunian:unredacted.org> @torir:unredacted.org: Haha, don't worry. I checked there too.
23:00:22 <tevador> BC1024 would be 1.61x, address length 568 I think.
23:00:36 <br-m> <neptunian:unredacted.org> tevador: Better than NTRU-509 at least XD
23:00:36 <tevador> And 4x slower scanning.
23:01:46 <br-m> <neptunian:unredacted.org> I'll drop a comment on the gist including that metric. 
23:02:17 <tevador> I'll edit Appendinx D (it will be deleted anyways when we finally decide...)
23:02:25 <br-m> <jpk68:matrix.org> IMO, infeasible scanning time is worse than address length, too
23:02:39 <br-m> <neptunian:unredacted.org> tevador: Cool.
23:02:57 <br-m> <neptunian:unredacted.org> @jpk68:matrix.org: 4x scantime sounds really undesirable.
23:06:07 <br-m> <jpk68:matrix.org> Yes, especially when you consider that less powerful devices (e.g. smartphones) will not be able to sync wallets on-device, forcing those users to self-host LWS (which many simply can't do), or perhaps outsource the scanning to some sort of custodial service
23:07:10 <br-m> <neptunian:unredacted.org> I'm looking for anything that might help with this. This might knock BC1024 out of the game.
23:07:44 <br-m> <jpk68:matrix.org> I think this would be hugely impactful (in a bad way) on Monero adoption in "lower-income" regions, which is... most of the world
23:08:24 <tevador> I think we should place hard constraints on Jamtis and go from there, otherwise there will always be an option that's slightly more private or slightly more secure. And then Jamtis will be unusable. I'm proposing 420 characters, 1.5x pruned blockchain and 30s scan time per 100k enotes.
23:10:22 <br-m> <jpk68:matrix.org> What would that scan time be, in seconds per day (or multiple of current scan time)?
23:10:30 <br-m> <jpk68:matrix.org> "Multiple" is probably the wrong word there
23:11:11 <br-m> <neptunian:unredacted.org> I understood what you meant.
23:11:56 <tevador> 100k enotes is about 1 day with current tx volume
23:12:37 <br-m> <neptunian:unredacted.org> I'd say that's pretty reasonable then. The repudiation trade-off is still concerning to me, but it's better than UX hell.
23:17:09 <br-m> <kayabanerve:matrix.org> From the above, I wouldn't have an issue with and would support BC1024.
23:20:22 <tevador> kayabanerve where do you draw the line?
23:21:15 <br-m> <kayabanerve:matrix.org>  ... 10x sync time, 5x bandwidth? Probably?
23:21:22 <br-m> <kayabanerve:matrix.org> I expect to be an extremist on this
23:21:51 <tevador> BC1024 already exceeds your 10x sync time limit
23:22:05 <br-m> <kayabanerve:matrix.org> I thought you said 4x?
23:22:11 <tevador> current: 4s/day, BC1024: 71s/day
23:22:31 <br-m> <kayabanerve:matrix.org> Ah, that is not 4x, but ~18x :/
23:22:48 <tevador> 4x was from BC512 to BC1024
23:23:08 <tevador> BC512 is ~20s/day
23:23:47 <tevador> and 5x pruned blockchain size would be quite brutal I think
23:23:53 <tevador> With hardly anyone running a node
23:24:25 <br-m> <kayabanerve:matrix.org> I will drop BC1024 advocacy, switch to advocating BC512, and if CSIDH 512 is too insecure to consider, I'd likely say this discussion needs to start from zero/JAMTIS shouldn't include a PQ component. 
23:25:08 <br-m> <kayabanerve:matrix.org> I'm just not convinced about address-linkable PQ view keys being a goal
23:26:00 <tevador> So you think zero PQ privacy is better than PQ hidden amounts + linking tags? That's quite surprising.
23:30:52 <tevador> Added some extra info: https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832#appendix-d