<rottenwheel:unredacted.org> thx binaryfate, nioc

<ravfx:xmr.mx> You guys dont know how I am pissed off that you guys released a wallet that can't create wallet.... Will soon open a test labs, I will accept submission for proper QA testing, for a fee

<kiersten5821:matrix.org> how come creating a wallet wasnt tested in 0.18.5.1?

<kiersten5821:matrix.org> the most basic functionality is not tested before release?

open source project, everyone can help with testing

in this case it depended on a specific folder existing which already existed for everyone who did test it

<ravfx:xmr.mx> Sure, but imo it should be a proper thing to do to test supported feature before cristening a new version for release.

<ravfx:xmr.mx> Imajin Microslop selling a new Word version that can't create new documents if there is no files is "my documents"

<ravfx:xmr.mx> Basic testing, aka QA, to be sure that the stuff that is officially supported, actually work

<slstmd> there is no one funded to do QA work before a release, and no one volunteered to do its

<slstmd> it*

<slstmd> again, that's why I spent time now to implement this QML test system so at least the wizard part is covered

<ofrnxmr:xmr.mx> Even if there was, it's not possible to catch all issues, otherwise there would be no reason for bug fixes

<ofrnxmr:xmr.mx> It seems simple enough to say that this should have been tested, but what if this issue was specific to an os that nobody uses? if you didnt create a new build env for every commit that you built and tested, then this issue is hidden by a prior build succeeding

<ravfx:xmr.mx> Create a new wallet : all OS

<slstmd> @ravfx:xmr.mx: and if you didn't use a fresh OS install you already wouldn't have caught it

<ofrnxmr:xmr.mx> None of which would error if you had tested the previous commit

<ravfx:xmr.mx> new os / user

<slstmd> these discussion are a bit pointless, looking back you can always say why did you not test this with these exact preconditions

<kiersten5821:matrix.org> i think creating a new wallet is the most basic functionality and should have been tested

<monerobull:matrix.org> selsta: I love shit like this

<monerobull:matrix.org> I don't really know why but it's so interesting to me

<monerobull:matrix.org> Like, it's such a logical cause and effect thing?

<monerobull:matrix.org> Of course testers will have wallets from previous tests, of course there is a bug that specifically only appears when you don't have any yet

<monerobull:matrix.org> Fascinating

<ofrnxmr:xmr.mx> The bug: flatpak let you manually enter a directory that it did not have permission to write to. When creatinf a wallet, it would work, but the wallet would not persist / would not be written to disk = lost funds

<ravfx:xmr.mx> wow, ic

<ravfx:xmr.mx> a two for one 😂

lost funds?

@seen seed

<ofrnxmr:xmr.mx> who writes those down? I just remember a couple and bypass the check

<ofrnxmr:xmr.mx> In cake, you can just close the app on the check / confirmation screen

good luck lol

create wallet and write down seed

close wallet

open wallet and check seed

even for a temporary wallet

monero is life itself

<ofrnxmr:xmr.mx> I just make 100 copies of the wallet file 🧠🧠

<ofrnxmr:xmr.mx> And then send them to my friends

<ofrnxmr:xmr.mx> Im only half joking. I do actually have probably 30 wallets without the seed stored anywhere, but none of these hold any funds. Just used/reused for testing .. or as decoys, so if my drive is ever seized, rheyll have to sync 30 wallets that all have history but none have funds 🧠

<ofrnxmr:xmr.mx> "theres 700 transactions across 300 subaddresses, and it says the balance is zero? What am i missing."

<slowbeardigger:matrix.org> @ofrnxmr:xmr.mx: Based

> rheyll have to sync 30 wallets that all have history but none have funds

GPU (private) scanners now exist that can do a full scan in ~5-15s btw :)

wrote something similar for bruteforcing tari pubkey burn bug and got similar speeds

<ofrnxmr:xmr.mx> DataHoarder: Why not public

slop

mine is public, anyhow, on the tari repo. I have the CPU scanner/verifier and the GPU one was also sourced from normal C code, then slop'd keccak/derivations

<ofrnxmr:xmr.mx> How can it do a full scan in 15sec if you have to read 30gb from the db?

the db is pre-processed :)

and it fits in GPU

<ofrnxmr:xmr.mx> Gotcha

you effectively take all the outputs and process them in a standard format to scan quick

<ofrnxmr:xmr.mx> is it rust tho

<ofrnxmr:xmr.mx> 😀

surely not

<ofrnxmr:xmr.mx> Finally

Yep, I have the GPU scanner that does a fullchain scan of a wallet in 8 seconds on RTX 5070. AI vibe coded but it works.

The required data fits into ~8.3 GB VRAM, so it needs a GPU with 12 or more GB VRAM

Although, streaming the data is possible, but not implemented

ArticMine ^

<syntheticbird> sech1: CUDA ? Vulkan ?

C++/CUDA

<syntheticbird> alr

Rbrunner^

For tari not monero sech1? Need to read the backlog

I was thinking back to artic wanting to utilize the gpu on a pi to help block verification

<rbrunner7> Not sure where I might be able contribute something to the discussion?

Hello, sorry looks like its not for monero but tari, pinged as i thought the nwlb workgroup would like to see that. Maybe theres still something there to help us sync the "old" chain faster

<syntheticbird> NVIDIA TM POWERED MONERO SYNCING

One LWS node to control the entire chain

<ofrnxmr> Publix for tari, but iiuc the 8-15s applies to monero

<ofrnxmr> Since that what we were talking abt (monero sync time)

<rottenwheel:unredacted.org> @jeffro256:monero.social: shared repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/688 via @MoneroSpace. =] x.com/MoneroSpace/status/2079971347518894509 // nitter: xcancel.com/MoneroSpace/status/2079971347518894509

<jeffro256> Thank you

plowsof it's for Monero. Yes, it's possible to speedup node syncing using the GPU, but what I have now is only wallet-side scanning with the viewkey