<hbs:matrix.org> Has anyone experience monero-wallet-rpc deleting the key file unexpectedly?

<ofrnxmr> Nope

<hbs:matrix.org> @ofrnxmr: I have a MoneroSwap maker running in the background, it periodically opens or create the root wallet via JSON-RPC calls to monero-wallet-rpc and from time to time the .keys file is removed. monero-wallet-rpc is accessed by a single thread, so concurrency issues are ruled out.

<ofrnxmr> Basicswap creates new wallets for each swap jsing generate from keys, and runs open_wallet to switch between them - never had a wallet go missing

<ofrnxmr> 1-2 new wallets per successful swap*, the shared view wallet and, if receiving xmr, the spend version of that wallet

<hbs:matrix.org> @ofrnxmr: That's pretty much what MS is doing, as I am running the bot on a laptop which occasionally goes to sleep, I am starting to wonder if it may be linked to that

<ofrnxmr> Once the wallet is creates the keys file already exists, but the cache isng saved until you manually save vja store, open_wallet etc. Is the wallet fully gone? Or corrupted?

<hbs:matrix.org> Just the .keys file which disappears, the other file remains.

<rbrunner7> Sounds very strange, I think I cannot remember having lost a .keys file even once. Also did quite some things over RPC.

<rbrunner7> Do we even have any code that deletes .keys files, anywhere in the codebase? With no RPC command to delete a wallet as far as I can remember, with no CLI wallet command to to so.

Well, if you do something dumb like having a wallet called foo.keys.keys and one called foo.keys...

I think there's some code to delete/rename for atomic saving when changing settings.

But if it's gone, the rename file ought to be there still.

I suppose it's texhnically possible if the process is killed at just the right time. Check for a file named almost the same (with a suffix or something).

<kayabanerve:matrix.org> I already wrote a document about integrating FROSTLASS into wallet2

<kayabanerve:matrix.org> This is the PedPoP DKG associated with FROST, but any biased DKG suffices. Serai uses a one-round DKG. > <@jpk68:matrix.org> It always has two DKG rounds as well

<kayabanerve:matrix.org> The MuSig-esque impl in wallet2 uses the same technique. Whether or not it corresponds to a formally proven protocol is another question. > <@jpk68:matrix.org> It's also natively designed for signer-subset flexibility, and forgery-attack mitigation is proven to be secure in FROST due to it having blinding factors

<kayabanerve:matrix.org> If wallet2 is to include multisig, it should be via the Rust libs moving forward IMO.

<kayabanerve:matrix.org> I cannot load this hidden paste :/ > <@jpk68:matrix.org> Some notes I took regarding multisig (may not be 100% accurate):

<hbs:matrix.org> moneromooo: Nope, wallet name is quite unique

<hbs:matrix.org> @hbs:matrix.org: As the bot is structured, there may be extended periods of times when the bot will query a single wallet, this is done in a loop and relies on open_wallet being called at each iteration. Could it be an issue due to the fact that open_wallet is called on a wallet when that wallet is already open by monero-wallet-rpc?

<hbs:matrix.org> @hbs:matrix.org: Hmmmm I think I understood. The bot stores its files in a directory under /tmp, as the .keys file is not modified nor accessed when the same wallet is being open, its ctime therefore doesn't change and after some time the file is eligible for purge and is deleted by the OS.

<rbrunner7> Oh, wow, that's quite of dumb, isn't it :)

<hbs:matrix.org> @rbrunner7: Dumb AF yes...

<jpk68:matrix.org> Maybe related? > <@hbs:matrix.org> Has anyone experience monero-wallet-rpc deleting the key file unexpectedly?

<jpk68:matrix.org> monero-project/monero #5586

<jpk68:matrix.org> Oh, awesome. Is there anywhere this can be viewed? :) > <@kayabanerve:matrix.org> I already wrote a document about integrating FROSTLASS into wallet2

<jpk68:matrix.org> @kayabanerve:matrix.org: privatebin.net/?b4c1b1ee4a2727f0#9N…MompEw58LmPXPz8KBgGVxpY1Y4Qe3qbBkQp

<ofrnxmr> @hbs:matrix.org: Shouldnt be

<ofrnxmr> Basicswap used to spam open_wallet for everything

<kayabanerve:matrix.org> @jpk68:matrix.org: > Could not get document data: Document does not exist, has expired or has been deleted.

<jpk68:matrix.org> Sorry, looks like it expired after an hour

<jpk68:matrix.org> Does this one work?

<jpk68:matrix.org> paste.debian.net/hidden/b99b22bd

<jpk68:matrix.org> I can guarantee the most recent link I sent is still valid; sometimes it will just reject your client/IP address

<hbs:matrix.org> @ofrnxmr: solved the issue, turns out the file cleaner was removing the .keys file after a few days because open wallet doesn't touch it when the same wallet is already open....

I believe a running wallet keeps an advisory lock on the keys file though. Not nice of the cleaner process.

<kayabanerve:matrix.org> @jpk68:matrix.org: gist.github.com/kayabaNerve/3b2c648c623bc4ce4ca288725428ea76

<jpk68:matrix.org> Thank you :)

<kayabanerve:matrix.org> I again can't load your paste and will give up on it. Feel free to DM a copy directly

<jpk68:matrix.org> I'll just paste it here:

<jpk68:matrix.org> The UX benefits include the following:

<jpk68:matrix.org> * FROST always has 2 DKG rounds, compared to the existing scheme's N-M+2 (which is worse for low thresholds)[... more lines follow, see mrelay.p2pool.observer/e/27zjhKsLYVFmOXdS ]

<jpk68:matrix.org> As stated earlier, some of the points might be wrong or not entirely accurate (I'm pretty bad at math)

<kayabanerve:matrix.org> FROST doesn't scale logarithmically. It has quadratic total communication, linear verifier in the local view, and a constant prover in the local view.