In spanish language "libera" (the name of this mIRC net) means to set free, liberate. Let me do it and respect my opinion, thank you.

Wake up and save your life. You are facing a global genocide that many have already confirmed, it is through vaccines. Some are placebo but most carry poison. If you have already been vaccinated...

whatever the brand or number of doses, learn about antidotes and remedies to save your life, otherwise you will die prematurely. Download Telegram and go to channels as GRABA TU HOSPITAL, FORO QUINTA COLUMNA, NOTICIAS RAFAPAL or EJERCITO REMANENTE. It is a plan of the WHO and Bill Gates, in collusion with the media.

It is very difficult for you to believe me at once, because of the negative primacy induced by TV. VACCINES, both for the 2019 flu (death of the elderly) and all those of COVID carry POISON to kill us. don�t answer to me please. Good Lucky

donation to keep awakening, in this Wallet of ETH: 0xcfa341a5bdfdf45771cd34608afc791b95e11ad7 thank you

bad bot

just use `/ignore @nick` to hide this spam from matrix history

\ignore _crazygirl

`/ignore @_cra<TAB>`

.merges

.merge+ 7780

Added

idea: split the wallet file into 2 files 'stuff that's lost when you restore from seed' and 'stuff that isnt'

we already have a keys and cache file

so it's split already

I guess i had a brain fart, need more coffee. Are you referring to this 'old_cache' file?

no

`wallet_file` (no extension) is the wallet cache, `wallet_file.keys` is the keys file

Ah, right, ok... what about when you make a transaction to Bob but it appears as "unknown" on another device (or when you restore from seed)?

the entire wallet (without extension) is needed to see that the tx was sent to Bob?

15:22 <plowsof[m]> the entire wallet (without extension) is needed to see that the tx was sent to Bob? <-- yes

Thank you for clarifying 🥲😭 i just see a future of people using the same wallet on multiple devices here there and everywhere. Just because a wallet file is 'newer' or 'larger' doesn't mean it will contain the same + more info.

the decoy selection changes need an approval on github monero-project/monero #7821

jberman[m]: any reason 7845 is WIP? I assume it is ready?

I plan to review today

<selsta> "jberman: any reason 7845 is WIP?..." <- I'm going to WIP both 7821 and 7845 actually, just for another 6 hours tops. Aka hold off just for another 6 hours UkoeHB . I'm sorry to keep doing this :(

It occurred to me to give 1 more go at trying both 7821 and 7798 (the original fix for integer truncation) in combination, using the current solution in 7821 + the toolset and analysis framework I now have set up (thanks to the push from luigi1111 , gingeropolous , and Rucknium), and re-assess the impact on tx uniformity.

I don't anticipate that the conclusions in either PR's (7821 or 7845) will change - as it stands right now, both PR's in combination offer the least-potential-for-harm changes to the code that would solve both the earliest spends issue + divide by 0. But I have better tools I'd like to view the data from, which just might lead to the conclusions changing.

I'm running the code to collect the samples. It's almost done

Basically I strongly believe 7821 + 7845 are safe and "good enough" as is to solve the immediately earliest spends + div by 0 issues today, but perhaps a combination of 7821 with a different window + 7798 could be even better, and I'll have an answer to that within 6 hours

oki, sounds good

hey hey hey, all tests green (btw thanks for the bash hints moneromooo, multisig core tests run quite fast)!

PR #7852 had a random test failure (idk if anyone is tracking these): `AssertionError: {'error': {'code': -1, 'message': "Couldn't stop mining due to unknown error."}, 'id': '0', 'jsonrpc': '2.0'}`

There is another PR with the same error, so this random test failure isn't caused by your PR, ignore it

<UkoeHB> "PR #7852 had a random test..." <- I know this one and I think it has to do more with RandomX itself than the test, but it is on my low prio watchlist..

I doubt it's RandomX related.

RPC failing for whatever reason

I believe I've seen it when rx is busy on a long hash (initializing tables).