<r​brunner7:monero.social> Meeting in 1 hour

<r​ucknium:monero.social> Thomas: Monero Nodo was interested in GPU code that could help sync a node. AFAIK, they have a GPU in the box, but it is not really used.

<r​ucknium:monero.social> IIRC, the big problem with GPU verification of the blockchain is that GPU instructions aren't as standardized as CPU instructions. If two different GPUs disagree about the validity of a transaction or block, a chain split could result. If you're good at GPUs, you could investigate the status of GPU instruction standardization, the risks, etc.

<r​ucknium:monero.social> Monero Nodo's room is #nodo:monero.social

^ I looked into implementing the base ed25519 ops on GPU for bruteforcing Tari burned bug outputs, and although it does speed up the operations it wasn't such big of a change

you can write standard OpenCL or similar code against these, or CUDA. the issue is parallelizing it well usually, or the gpus starve or the "Wavefronts" just have to wait for each other doing nothing if paths differ

<j​berman:monero.social> GPU wallet scanning is less risky than consensus side fwiw, pinging kayabanerve who is a big GPU wallet sync research focus proponent

<r​brunner7:monero.social> Meeting time. Hello! monero-project/meta #1315

<j​berman:monero.social> *waves*

<v​tnerd:monero.social> Hi

<s​needlewoods_xmr:matrix.org> hey

<r​brunner7:monero.social> Before I forget to mention it: I propose that we skip the "between the years" meeting in 1 week, on December 29, and meet again in the new year in 2 weeks, on January 5. I will probably be around nevertheless should there be something interesting and/or urgent.

<j​berman:monero.social> good with me

<s​needlewoods_xmr:matrix.org> sounds good to me

<r​brunner7:monero.social> Good. So, what is there to report from last week?

<j​effro256:monero.social> Howdy

<s​needlewoods_xmr:matrix.org> GUI restore height on wallet creation: github.com/monero-project/monero-gu…x_restore_height_on_wallet_creation

<s​needlewoods_xmr:matrix.org> I think most important cases are covered now, but IMO what's missing is information about the nettype for saved remote nodes in `remoteNodesSerialized` (the comment in [this WIP commit](monero-project/monero-gui b565f4e) goes into more details) so will probably continue to spend a little more time on this

<j​berman:monero.social> interesting strategy there to use a mock temp wallet

<j​effro256:monero.social> Me: Finishing up knowledge proofs crypto and will be moving to migrate carrot code to using the unbiased hash-to-point where applicable. Interesting note: reserve proofs now have full-chain sender anonymity and don't reveal amounts per enote

<j​berman:monero.social> me: implemented unbiased hash to point for tree building, made some changes to tx relay v2 and currently testing those changes locally

<v​tnerd:monero.social> Me: some work in monerod+lws+lwsf for fcmp++ proofs client side. Got a bit more work in lwsf before I know whether the protocol is sufficient, etc, so it'll be a while before prs

<r​brunner7:monero.social> Say again, what is *lwsf*?

<v​tnerd:monero.social> Lws frontend. Skylight uses it to do all the heavy work

<r​brunner7:monero.social> Something like a library to build clients?

<v​tnerd:monero.social> There also lwcli wallet which uses lwsf, but only only ofrn and myself have really used thT

<v​tnerd:monero.social> Yes. It reimplements wallet2api virtual functions so technically lwcli is both a wallet2 wallet and light wallet with little code needed to swap them. You can't swap metadata files though

<j​effro256:monero.social> Nice

<j​effro256:monero.social> That'll hopedully become pretty powerful with SNeedlewoods's work

<j​effro256:monero.social> Maybe allowing a wallet-RPC and/or wallet-CLI type interface with light wallets

<v​tnerd:monero.social> We could nearly make the main wallet GUI an optional light wallet too but it might confuse people

<j​effro256:monero.social> Is that possible?

<v​tnerd:monero.social> yes if the primary wallets use the vtable API it's basically one call to create a different factory class and the remaining is seamless because of the vtavlbles

<r​brunner7:monero.social> Well, whether something like that would be confusing or not would probably depend a lot on UX/UI design. With quality there it should be possible to make things clear IMHO

<v​tnerd:monero.social> The file types differ so you must select at creation time

<v​tnerd:monero.social> But otherwise lwcli demonstrates a basic wallet can use both implementations easily

<r​brunner7:monero.social> Interesting. A requirement to use different apps only to use LWS could develop into quite a drag regarding making it popular

<r​brunner7:monero.social> And finally that complicated Wallet API structure with virtual functions for everything would be put to good use

<v​tnerd:monero.social> Yup. And This was loads easier than shoving light wallet cod into wallet2 etc, as it wasn't trying to do tow things at once

<v​tnerd:monero.social> *two

<r​brunner7:monero.social> Well, long term we want to get rid of wallet2 anyway, so that's definitely a plus

<r​brunner7:monero.social> If the Rust people do not steamroll us earlier than we get the chance to do that :)

<r​brunner7:monero.social> Different question: SNeedlewoods 's ready-to-review PR currently has 4 commits. Does that matter in any way regarding reviewing it, does it make that more complicated? monero-project/monero #10233/commits

<r​brunner7:monero.social> Would it be a good idea to review the commits individually?

<r​brunner7:monero.social> Is that even possible with GitHub?

<s​needlewoods_xmr:matrix.org> only commit that matters for that PR is the last one, the others are still open PRs

<r​brunner7:monero.social> You mean everything worthy of review is all in the last commit? Not sure I understand.

<s​needlewoods_xmr:matrix.org> first commit is just this PR monero-project/monero #9464

<s​needlewoods_xmr:matrix.org> second commit is another PR

<s​needlewoods_xmr:matrix.org> the simplewallet changes are based on those PRs, I thought this way it's easier to review, because you just have to pull one PR

<s​needlewoods_xmr:matrix.org> instead of pulling 3 and then rebasing them in the correct order youself

<r​brunner7:monero.social> Ok, will try to have a look and hope I will see better once I check the details

<s​needlewoods_xmr:matrix.org> hit me up if you have more questions

<j​berman:monero.social> SNeedlewoods: rather than use a temp wallet (which I think might have some tricky things to manage / make sure is done correctly / adds overhead of a new wallet), another idea could be to use QT's http request lib to communicate directly with the daemon that way: qt.io/product/qt6/qml-book/ch13-networking-http-requests

<s​needlewoods_xmr:matrix.org> interesting, I'm also afraid the tmp_wallet could have unseen drawbacks, will look into it, thanks

<j​berman:monero.social> I guess then you may have to deal with tor too, and the wallet out of the box I think should have that covered

<r​brunner7:monero.social> So you may swap some potential problems with a different set of potential problems ...

<j​berman:monero.social> yep true, I think a temp wallet is a solid strategy, feel free to continue with that

<s​needlewoods_xmr:matrix.org> looked into many things already, because 1. I'm a GUI noob, and 2. it's definitely more complicated then the CLI lol

<r​brunner7:monero.social> Might also be more "future-proof", if yet more stuff gets added to daemon communication

<j​berman:monero.social> I think when I first looked at the issue, I thought there might be a solid way to reorganize some of the logic internally in the wallet API functions to establish the daemon connection sooner, but maybe this will be simpler

<r​brunner7:monero.social> Does Featherwallet have to deal with the same problem somehow, and maybe already have sort of a solution? tobtoht is usually quite methodical with such things IMHO.

<j​berman:monero.social> ya that is a good question, tobtoht would be good to check with on this too

<j​berman:monero.social> and/or take a look at the feather code

<s​needlewoods_xmr:matrix.org> will do

<r​brunner7:monero.social> I guess that might be even more complicated, or at least larger, than the GUI code :)

<r​brunner7:monero.social> Ok, anything else to discuss today beyond these?

<s​needlewoods_xmr:matrix.org> wish you all happy holidays

<j​effro256:monero.social> Perhaps the wallet API could have an endpoint added which lets you make HTTP requests on the same internet client as the wallet ?

<r​brunner7:monero.social> Thanks, likewise! Has been an interesting year, in any case. Next year sure will be even better, with added FCMP++ pixie dust

<r​brunner7:monero.social> So thanks for attending, read you again in **two** weeks in 2026!

<s​needlewoods_xmr:matrix.org> thanks everyone, see you

<j​effro256:monero.social> Thanks everyone!!

<j​berman:monero.social> thanks all :)

<s​needlewoods_xmr:matrix.org> correction:

<s​needlewoods_xmr:matrix.org> the first PR [#9464](monero-project/monero #9464/commits) has 2 commits

<s​needlewoods_xmr:matrix.org> 1. the first attempt to make the API feature complete, 2. things I figured out where still missing when working on "replace wallet2 with Wallet API in simplewallet"

<s​needlewoods_xmr:matrix.org> the second PR [#10232](monero-project/monero #10232/commits) to "remove cached password from Wallet API"

<s​needlewoods_xmr:matrix.org> commit 1&2 are from first PR

<s​needlewoods_xmr:matrix.org> commit 3 is the relevant code for the second PR

<s​needlewoods_xmr:matrix.org> the third PR [#10233](monero-project/monero #10233/commits) to "replace wallet2 with Wallet API in simplewallet"

<s​needlewoods_xmr:matrix.org> commit 1&2 are from first PR

<s​needlewoods_xmr:matrix.org> commit 3 is from second PR

<s​needlewoods_xmr:matrix.org> commit 4 is the relevant code for the third PR

<s​needlewoods_xmr:matrix.org> that was supposed to be a response to this

<r​brunner7:monero.social> Thanks for the info!

18:58:32 <m-relay> <j​berman:monero.social> GPU wallet scanning is less risky than consensus side fwiw, pinging kayabanerve who is a big GPU wallet sync research focus proponent

Oh, I literally implemented GPU output scanning (specifically trying many pubkey values, fixed view key, test view tag, test derivation) so that might be relevant

it can probably have a better field element implementation, anyhow, it's drop-in code with few tweaks

see kernel function there. what'd need changing is to feed a vector of txpubs and vector of outputs

sadly due to how wavefront are setup here most of them go to waste. sech1 suggested re-queuing after first check (viewtag) for checking the rest. in the normal scanning usecase there shouldn't be invalid pubkeys so the first if can be removed

unsafe code is fine(TM) as client-side code would still re-scan the output to check again.

this is too slow to scan the 2^56 pubkey bruteforce scan needs, anyhow

on an RTX 5880 it was doing 20 million scans/second only

~24bit/second of scan range :)

same 24-bit range for CPU with more specialized tricks (not applicable to general case) was 22s or so

meanwhile nvidia is reducing production of consumer GPUs next year by 30-40%

should be fairly ok to port to OpenCL, so all sort of accelerators can use it (even some FPGAs)

I tested locally with AMD gpu and ZLUDA :)

iGPU should be able to use that as well