<moneromavrick:matrix.org> Are there any plans or ideas for making monero block time and sync time faster

<moneromavrick:matrix.org> That isnt a proof of stake hybrid model lol

<moneromavrick:matrix.org> I know fcmp++ and quantum updates etc but apart from proof of stake hybrid i havent seen anything about this

<syntheticbird> sync time ? wallet or node ?

<jpk68:matrix.org> This might be better suited for -research-lounge

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).

<syntheticbird> le gpu meme scanning when

<syntheticbird> (vulkan is a thing)

<jpk68:matrix.org> +1M lines of code

<syntheticbird> @jpk68:matrix.org: Ask MyhtosTM

<jpk68:matrix.org> I can't remember whether this is related, but I think Jeffro was working on shader code at some point

<jpk68:matrix.org> Like, code written in a shader language (Slang) for better GPU performance

<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

<syntheticbird> congratulations on finding your only purpose

<jpk68:matrix.org> OpenCL might be good too

<syntheticbird> @jpk68:matrix.org: no

<syntheticbird> Vulkan

<syntheticbird> Vulkan is faster than OpenCL

<syntheticbird> mainly because OpenCL requires a kernel to execute while Vulkan can be sent raw to the gpu for computation

<jpk68:matrix.org> Thanks, was not aware

<syntheticbird> there are many benchmarks where vulkan have the lead over CUDA too

<jpk68:matrix.org> Just rewrite everything in CUDA and force everyone to purchase NVIDIA GPUs

<syntheticbird> well

<syntheticbird> there is ZLUDA for CUDA on AMD GPU

<syntheticbird> check mates jacket man

<ravfx:xmr.mx> Just run le Cuda with Rocm

<syntheticbird> its supported?

<ravfx:xmr.mx> It seam a lot of stuff use the same "path". For example pytorch use "cuda"

<jberman> MRL meeting agenda for tomorrow: monero-project/meta #1399

<jbabb:cypherstack.com> @jberman: re: fireine's mention on this PR regarding view-all evasion,

<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

<jbabb:cypherstack.com> as @brandon:cypherstack.com mentioned, the FCMP Grimoire he released also mentions this as in "scoped linkability"

<jbabb:cypherstack.com> as in FCMP++ -> FCMP+⋄+

<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

<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

<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

<jberman> Hm I have a few follow-up q's

<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?

<jberman> (None of the links in that comment seem to work :/ and are you saying fireine is the same as uwaterl00?)

<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

<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?

<jbabb:cypherstack.com> @jberman: this, I do not know. I don't know who they are

<jbabb:cypherstack.com> @jberman: I think both

<jbabb:cypherstack.com> but I have only proven the concept for legacy view keys with Carrot as currently implemented on stressnet

<jbabb:cypherstack.com> in C++ and not in Rust yet.

<jbabb:cypherstack.com> @jberman:monero.social: see this message for the attachment and the next message(s) eg > <@brandon:cypherstack.com> mrelay.p2pool.observer/m/cypherstack.com/UuawbDivxXmfUzwDfMweHbqT.pdf (thegrimoire.pdf)

<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.

<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

<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 mrelay.p2pool.observer/e/vtXMl4kLNXBLY2lH ]

<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

<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

<freeman:cypherstack.com> mrelay.p2pool.observer/m/cypherstac…k.com/nkgzVMMZXWMTmfnXwUuUXtMG.lean (LessonViewAllEvasion.lean)

<freeman:cypherstack.com> Here are the contents of the comment on 1399

<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

<freeman:cypherstack.com> The lean code is moreso about opt-in linkability, so let's keep that and our view-key evasion separate.

<freeman:cypherstack.com> Sorry for any confusion

<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.

"§ 1 The View-All Vulnerability Model" - Not really a vulnerability per se, more like a design choice. Jamtis improves this quite a bit.

"§ 2 Opt-In Linkability" - Monero can't have opt-in linkability becase linkability serves the purpose of preventing double spends.

"§ 4 Per-Output Forward Secrecy (ML-KEM)" - We have discussed this an disqualified ML-KEM. Jamtis will use CSIDH instead.

<freeman:cypherstack.com> Would you mind expanding more on why it was a design choice?

I would imagine mostly for UX reasons - a single key to scan all addresses.

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.

<fireine:matrix.org> tevador: can U say more?

<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

<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 monero-project/meta #1399

fireine: The three comments I wrote are my main critique of the write-up. Any responses to that?

<fireine:matrix.org> tevador: i'll put the data in by end of day.

<fireine:matrix.org> assuming you're referring to Jamtis-AC1024

<fireine:matrix.org> tevador: is this the most up to date draft of your spec

<fireine:matrix.org> gist.github.com/tevador/639d083c994c1ef9401832c08e2b7832

<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

<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.

YEs, this is the most recent version

<fireine:matrix.org> tevador: ok.

I'm not planning any changes at the moment, just the completion of the missing parts.

<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)?

<jpk68:matrix.org> If they haven't been selected already, that is

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.

<jpk68:matrix.org> Wasn't Twofish being discussed a while ago?

Jamtis does use Twofish

<jpk68:matrix.org> Thanks, I had missed that part. Is there any particular reason why it was chosen?