16:28:34 <br-m> <moneromavrick:matrix.org> Are there any plans or ideas for making monero block time and sync time faster
16:28:34 <br-m> <moneromavrick:matrix.org> That isnt a proof of stake hybrid model lol
16:29:36 <br-m> <moneromavrick:matrix.org> I know fcmp++ and quantum updates etc but apart from proof of stake hybrid i havent seen anything about this
16:36:52 <br-m> <syntheticbird> sync time ? wallet or node ?
16:40:54 <br-m> <jpk68:matrix.org> This might be better suited for -research-lounge
16:47:04 <UkoeHB> Faster blocks have been considered but so far rejected because it’s related to network coherence. Sync time would be improved by jamtis filter-assist remote scanning (mainly mobile wallets I expect) (planned) and reworking the scanning code to use threads better (planned).
16:47:31 <br-m> <syntheticbird> le gpu meme scanning when
16:47:43 <br-m> <syntheticbird> (vulkan is a thing)
16:48:09 <br-m> <jpk68:matrix.org> +1M lines of code
16:49:00 <br-m> <syntheticbird> @jpk68:matrix.org: Ask MyhtosTM
16:49:51 <br-m> <jpk68:matrix.org> I can't remember whether this is related, but I think Jeffro was working on shader code at some point
16:50:04 <br-m> <jpk68:matrix.org> Like, code written in a shader language (Slang) for better GPU performance
16:51:25 <br-m> <syntheticbird> I can't count on both of my hands the number of time I saw a shader language which its advertized feature is supporting all vendor backends
16:51:43 <br-m> <syntheticbird> congratulations on finding your only purpose
16:52:00 <br-m> <jpk68:matrix.org> OpenCL might be good too
16:52:07 <br-m> <syntheticbird> @jpk68:matrix.org: no
16:52:09 <br-m> <syntheticbird> Vulkan
16:52:16 <br-m> <syntheticbird> Vulkan is faster than OpenCL
16:52:39 <br-m> <syntheticbird> mainly because OpenCL requires a kernel to execute while Vulkan can be sent raw to the gpu for computation
16:53:20 <br-m> <jpk68:matrix.org> Thanks, was not aware
16:53:21 <br-m> <syntheticbird> there are many benchmarks where vulkan have the lead over CUDA too
16:53:59 <br-m> <jpk68:matrix.org> Just rewrite everything in CUDA and force everyone to purchase NVIDIA GPUs
16:54:08 <br-m> <syntheticbird> well
16:54:13 <br-m> <syntheticbird> there is ZLUDA for CUDA on AMD GPU
16:54:25 <br-m> <syntheticbird> check mates jacket man
16:54:36 <br-m> <ravfx:xmr.mx> Just run le Cuda with Rocm
16:54:44 <br-m> <syntheticbird> its supported?
16:55:20 <br-m> <ravfx:xmr.mx> It seam a lot of stuff use the same "path". For example pytorch use "cuda"
16:56:34 <br-m> <jberman> MRL meeting agenda for tomorrow: https://github.com/monero-project/meta/issues/1399
17:26:01 <br-m> <jbabb:cypherstack.com> @jberman: re: fireine's mention on this PR regarding view-all evasion,
17:26:01 <br-m> <jbabb:cypherstack.com> a few weeks ago @freeman:cypherstack.com discovered an issue with linkability under CARROT such funds may be hidden from auditors with viewkeys as are active on stressnet
17:26:01 <br-m> <jbabb:cypherstack.com> as @brandon:cypherstack.com mentioned, the FCMP Grimoire he released also mentions this as in "scoped linkability"
17:26:15 <br-m> <jbabb:cypherstack.com> as in FCMP++ -> FCMP+⋄+
17:27:38 <br-m> <jbabb:cypherstack.com> I have C++ wallet fork code to clean which proves such if anyone needs hard proof but I have other work pressing and details are being summarized so as to be shareable
17:27:38 <br-m> <jbabb:cypherstack.com> I can share a stressnet mnemonic which demonstrates the behavior, where we can hide spendable funds from monero-wallet-cli stressnet view keys
17:28:13 <br-m> <jbabb:cypherstack.com> the takeaway is that apparently we can have our cake and eat it too in terms of getting helpful tools for hardware wallets while also maintaining strict, legacy-style privacy with the new keys, too, if we wanted to
17:29:28 <br-m> <jberman> Hm I have a few follow-up q's
17:30:04 <br-m> <jberman> 1. The comment on 1399 doesn't seem to be related to view-all evasion unless I'm missing something, it looks like a distinct potential issue sisue with ring signatures?
17:31:09 <br-m> <jberman> (None of the links in that comment seem to work :/ and are you saying fireine is the same as uwaterl00?)
17:31:23 <br-m> <jberman> 2. I think I missed FCMP Grimoire, can you share a link on that also? Sounds like something we want added to the agenda as well
17:32:20 <br-m> <jberman> 3. This view-all evasion issue is interesting. Are you saying it's applicable to Carrot's view-all keys, or also applicable to the legacy view keys with Carrot as currently implemented on stressnet?
17:32:39 <br-m> <jbabb:cypherstack.com> @jberman: this, I do not know.  I don't know who they are
17:35:26 <br-m> <jbabb:cypherstack.com> @jberman: I think both
17:35:26 <br-m> <jbabb:cypherstack.com> but I have only proven the concept for legacy view keys with Carrot as currently implemented on stressnet
17:35:48 <br-m> <jbabb:cypherstack.com> in C++ and not in Rust yet.
17:37:12 <br-m> <jbabb:cypherstack.com> @jberman:monero.social: see this message for the attachment and the next message(s) eg > <@brandon:cypherstack.com> https://mrelay.p2pool.observer/m/cypherstack.com/UuawbDivxXmfUzwDfMweHbqT.pdf (thegrimoire.pdf)
17:37:12 <br-m> <jbabb:cypherstack.com> > FCMP grimoire 1.0. known to contain errors. still a draft, but is complete enough to share; i had to do a last-minute conversion from linkable to scoped-linkable.
17:48:52 <br-m> <jberman> > <@jbabb:cypherstack.com> the takeaway is that apparently we can have our cake and eat it too in terms of getting helpful tools for hardware wallets while also maintaining strict, legacy-style privacy with the new keys, too, if we wanted to
17:48:52 <br-m> <jberman> point of clarification: legacy view keys for FCMP++ are unchanged right now, they detect incomings same as before (minor caveat being the send protocol also sends 0 amount dummy change when sweeping so that light wallets continue to remain compatible). It sounds like this would be a scheme to construct a mnemonic in a specific [... too long, see https://mrelay.p2pool.observer/e/vtXMl4kLNXBLY2lH ]
17:50:14 <br-m> <jberman> I'm curious if is this something that can happen "by accident" or does it strictly require someone to use custom software to generate a special mnemonic
17:53:29 <br-m> <jbabb:cypherstack.com> strictly custom software, no special mnemonic, will make a stressnet mnemonic and share it there when I can then the code thereafter
18:08:54 <br-m> <freeman:cypherstack.com> https://mrelay.p2pool.observer/m/cypherstack.com/nkgzVMMZXWMTmfnXwUuUXtMG.lean (LessonViewAllEvasion.lean)
18:09:05 <br-m> <freeman:cypherstack.com> Here are the contents of the comment on 1399
18:10:43 <br-m> <freeman:cypherstack.com> Even though my name is attached, I really don't feel comfortable taking any credit for the code therein, so let it be known I officially recuse myself 
18:13:02 <br-m> <freeman:cypherstack.com> The lean code is moreso about opt-in linkability, so let's keep that and our view-key evasion separate.
18:13:12 <br-m> <freeman:cypherstack.com> Sorry for any confusion 
18:23:27 <br-m> <freeman:cypherstack.com> The big idea with the view-key evasion (we call it Fraus after the Roman deity of deceit, à la Janus) is that one can make it so that an auditor sees a different amount in a wallet than others. This means that to some extent, a wallet can hold funds which are selectively visible. 
20:20:54 <tevador> "§ 1 The View-All Vulnerability Model" - Not really a vulnerability per se, more like a design choice. Jamtis improves this quite a bit.
20:20:54 <tevador> "§ 2 Opt-In Linkability" - Monero can't have opt-in linkability becase linkability serves the purpose of preventing double spends.
20:20:54 <tevador> "§ 4 Per-Output Forward Secrecy (ML-KEM)" - We have discussed this an disqualified ML-KEM. Jamtis will use CSIDH instead.
20:22:45 <br-m> <freeman:cypherstack.com> Would you mind expanding more on why it was a design choice?
20:24:40 <tevador> I would imagine mostly for UX reasons - a single key to scan all addresses.
20:26:15 <tevador> Scanning for owned enotes is already a big UX hurdle for Monero users, we probably don't want to make it worse by making it N time slower where N is your number of distinct view keys.
21:09:34 <br-m> <fireine:matrix.org> tevador: can U say more?
21:11:49 <br-m> <fireine:matrix.org> Indeed, it's your idea sans semantics / syntax thus de-facto your code yet unrefined. At my opinion :) > <@freeman:cypherstack.com> Even though my name is attached, I really don't feel comfortable taking any credit for the code therein, so let it be known I officially recuse myself 
21:15:53 <br-m> <fireine:matrix.org> @freeman:cypherstack.com: This is still a problem!! Which is why I suggested it might make sense to either a) engage at informal dialogue here or b) place this at the MRL agenda at https://github.com/monero-project/meta/issues/1399
21:35:06 <tevador> fireine: The three comments I wrote are my main critique of the write-up. Any responses to that?
21:40:44 <br-m> <fireine:matrix.org> tevador: i'll put the data in by end of day.
21:42:40 <br-m> <fireine:matrix.org> assuming you're referring to Jamtis-AC1024
21:44:52 <br-m> <fireine:matrix.org> tevador: is this the most up to date draft of your spec
21:44:52 <br-m> <fireine:matrix.org> https://gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832
21:45:35 <br-m> <fireine:matrix.org> I assume you have a version yet unpublished and was wondering if you could put that data in - unless this is recent
21:46:09 <br-m> <fireine:matrix.org> bc I'm going to be spending some time on this and don't want to comment on something you've already included at the spec yet unpublished.
21:46:14 <tevador> YEs, this is the most recent version
21:46:51 <br-m> <fireine:matrix.org> tevador: ok.
21:46:57 <tevador> I'm not planning any changes at the moment, just the completion of the missing parts.
21:54:04 <br-m> <jpk68:matrix.org> tevador: Apologies for my uninformed question - do you think that when selecting symmetric algorithms for Jamtis, there would be some merit to using ones that have dedicated hardware instructions (like AES does)?
21:54:16 <br-m> <jpk68:matrix.org> If they haven't been selected already, that is
21:56:36 <tevador> In practice, symmetric algos are so fast and we are encrypting so little data that it doesn't matter. We chose AES for RandomX because there it matters.
21:57:51 <br-m> <jpk68:matrix.org> Wasn't Twofish being discussed a while ago?
21:59:36 <tevador> Jamtis does use Twofish
22:00:28 <br-m> <jpk68:matrix.org> Thanks, I had missed that part. Is there any particular reason why it was chosen?