16:59:41 Meeting in 1 hour 17:19:26 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. 17:19:27 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. 17:19:49 Monero Nodo's room is #nodo:monero.social 17:41:16 ^ 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 17:42:09 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 17:58:32 GPU wallet scanning is less risky than consensus side fwiw, pinging kayabanerve who is a big GPU wallet sync research focus proponent 18:00:04 Meeting time. Hello! https://github.com/monero-project/meta/issues/1315 18:00:20 *waves* 18:00:23 Hi 18:01:13 hey 18:02:22 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. 18:03:13 good with me 18:03:14 sounds good to me 18:03:34 Good. So, what is there to report from last week? 18:03:57 Howdy 18:03:58 GUI restore height on wallet creation: https://github.com/monero-project/monero-gui/compare/master...SNeedlewoods:monero-gui:x_restore_height_on_wallet_creation 18:03:59 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](https://github.com/monero-project/monero-gui/commit/b565f4e34fa5df2d52baac0def19654bd80f2d8e) goes into more details) so will probably continue to spend a little more time on this 18:05:00 interesting strategy there to use a mock temp wallet 18:05:32 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 18:06:36 me: implemented unbiased hash to point for tree building, made some changes to tx relay v2 and currently testing those changes locally 18:07:13 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 18:07:52 Say again, what is *lwsf*? 18:08:30 Lws frontend. Skylight uses it to do all the heavy work 18:08:50 Something like a library to build clients? 18:09:07 There also lwcli wallet which uses lwsf, but only only ofrn and myself have really used thT 18:10:07 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 18:10:21 Nice 18:10:46 That'll hopedully become pretty powerful with SNeedlewoods's work 18:11:02 Maybe allowing a wallet-RPC and/or wallet-CLI type interface with light wallets 18:11:03 We could nearly make the main wallet GUI an optional light wallet too but it might confuse people 18:11:07 Is that possible? 18:13:15 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 18:13:30 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 18:13:45 The file types differ so you must select at creation time 18:14:30 But otherwise lwcli demonstrates a basic wallet can use both implementations easily 18:15:31 Interesting. A requirement to use different apps only to use LWS could develop into quite a drag regarding making it popular 18:16:30 And finally that complicated Wallet API structure with virtual functions for everything would be put to good use 18:17:27 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 18:17:35 *two 18:18:01 Well, long term we want to get rid of wallet2 anyway, so that's definitely a plus 18:18:52 If the Rust people do not steamroll us earlier than we get the chance to do that :) 18:20:01 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? https://github.com/monero-project/monero/pull/10233/commits 18:20:54 Would it be a good idea to review the commits individually? 18:21:04 Is that even possible with GitHub? 18:21:06 only commit that matters for that PR is the last one, the others are still open PRs 18:21:54 You mean everything worthy of review is all in the last commit? Not sure I understand. 18:24:02 first commit is just this PR https://github.com/monero-project/monero/pull/9464 18:24:03 second commit is another PR 18:24:05 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 18:24:07 instead of pulling 3 and then rebasing them in the correct order youself 18:25:42 Ok, will try to have a look and hope I will see better once I check the details 18:27:49 hit me up if you have more questions 18:28:37 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: https://www.qt.io/product/qt6/qml-book/ch13-networking-http-requests 18:29:24 interesting, I'm also afraid the tmp_wallet could have unseen drawbacks, will look into it, thanks 18:29:48 I guess then you may have to deal with tor too, and the wallet out of the box I think should have that covered 18:30:26 So you may swap some potential problems with a different set of potential problems ... 18:31:02 yep true, I think a temp wallet is a solid strategy, feel free to continue with that 18:31:33 looked into many things already, because 1. I'm a GUI noob, and 2. it's definitely more complicated then the CLI lol 18:31:34 Might also be more "future-proof", if yet more stuff gets added to daemon communication 18:32:20 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 18:33:21 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. 18:33:59 ya that is a good question, tobtoht would be good to check with on this too 18:34:06 and/or take a look at the feather code 18:34:26 will do 18:34:34 I guess that might be even more complicated, or at least larger, than the GUI code :) 18:35:18 Ok, anything else to discuss today beyond these? 18:36:03 wish you all happy holidays 18:36:38 Perhaps the wallet API could have an endpoint added which lets you make HTTP requests on the same internet client as the wallet ? 18:36:41 Thanks, likewise! Has been an interesting year, in any case. Next year sure will be even better, with added FCMP++ pixie dust 18:37:43 So thanks for attending, read you again in **two** weeks in 2026! 18:38:35 thanks everyone, see you 18:39:32 Thanks everyone!! 18:42:03 thanks all :) 18:56:22 correction: 18:56:23 the first PR [#9464](https://github.com/monero-project/monero/pull/9464/commits) has 2 commits 18:56:25 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" 18:56:27 the second PR [#10232](https://github.com/monero-project/monero/pull/10232/commits) to "remove cached password from Wallet API" 18:56:29 commit 1&2 are from first PR 18:56:31 commit 3 is the relevant code for the second PR 18:56:33 the third PR [#10233](https://github.com/monero-project/monero/pull/10233/commits) to "replace wallet2 with Wallet API in simplewallet" 18:56:35 commit 1&2 are from first PR 18:56:37 commit 3 is from second PR 18:56:39 commit 4 is the relevant code for the third PR 18:57:03 that was supposed to be a response to this 18:57:08 Thanks for the info! 20:55:21 18:58:32 GPU wallet scanning is less risky than consensus side fwiw, pinging kayabanerve who is a big GPU wallet sync research focus proponent 20:55:23 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 20:56:01 https://git.gammaspectra.live/WeebDataHoarder/tari-tx-brute/src/branch/master/cuda/main.cu 20:56:25 it can probably have a better field element implementation, anyhow, it's drop-in code with few tweaks 20:57:29 see kernel function there. what'd need changing is to feed a vector of txpubs and vector of outputs 20:59:09 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 20:59:33 unsafe code is fine(TM) as client-side code would still re-scan the output to check again. 21:00:51 this is too slow to scan the 2^56 pubkey bruteforce scan needs, anyhow 21:01:22 on an RTX 5880 it was doing 20 million scans/second only 21:01:39 ~24bit/second of scan range :) 21:04:21 same 24-bit range for CPU with more specialized tricks (not applicable to general case) was 22s or so 21:06:21 meanwhile nvidia is reducing production of consumer GPUs next year by 30-40% 21:09:40 should be fairly ok to port to OpenCL, so all sort of accelerators can use it (even some FPGAs) 21:09:57 I tested locally with AMD gpu and ZLUDA :) 21:10:30 iGPU should be able to use that as well