<v​tnerd:monero.social> rsch: I'd have to dig into the specific code. Most likely the keys file changed to the new password but the cache file didn't. The code is supposed to detect when the keys file is selected, but maybe it's buggy. I would make copies of all related files, and then try changing the password of the keys file to the original password, with the goal of making the two in sync again

<n​obfg9000:matrix.org> when FCMP++ rolls out, will there still be timelocks?

<j​effro256:monero.social> User-specified timelocks are deprecated and will be (or at least should be) prohibited by consensus rule at the next fork, but there will still be the default 10-block-lock for non-coinbase transactions, and the 60-block-lock for coinbase transactions

hi

I would lke to contribute to the source code base. I have found a bug that I would like to go to fix. is there any documentation about the the branches?

how can I checkout the most recent version for testing a bug?

master is where most new stuff goes. Branching is made from master for every major release, to have some stability for subsequent minor releases.

as usual I would create a branch for a bug fix and make a PR. is that ok?

I mean from master

or is there a more recent branch to use?

If the bug you're fixing is consequential enough, it'll go to both master and the current release branch. If not, master only. Unless it's a bug in code that's only on the current branch, in which case it goes to the branch only.

Yes, you do that. This local branch is only on your repo, you manage that however you see fit.

am i wrong to say that the current cli release is since 2023?

Sounds old.

yea I am suprised that the bug is noticed so late

I see march 2025.

commit f1311d4237404ab7da76241dbf10e92a65132cc4 (tag: v0.18.4.0)

CLI and GUI 0.18 "Flourine Fermi" released 2022 july. I guess it referes to the major changes

Yes. There were several releases from the 0.18 branch. Last one a couple months ago.

but in simplewallet the last commit is from Sun Nov 24 20:39:26 2024 +0000

do you plan to move to rust in the future?

Some future parts might be coded in rust, depending on how maintainable it is, how easy to interface, whether it's in place with an attack surface, etc.

"how maintainable" here really means "whether existing monero hackers are conversant in rust" in large part.

It's pointless to merge a big rust thing only for the contributor to fade away later.

(if noone else around groks rust)

I agree

is there anything the project needs help with most? I see open issues since 2023

I believe code review for existing long lived patches. Not fun though.

oh yes there are 250 pr

You could also ask in #no-wallet-left-behind, I believe they're rewriting large parts of the wallet code (and hopefully not adding new bugs).

There's also the monero gui (no idea how active it is nowadays, see #monero-gui, C++/JS/QML), and haveno, a p2p exchange meant for monero first (#haveno-development, java).

I wonder how active the monero dev is when you have open pr since 2020

Well, feel free to tag along and find out.

But git log will tell you a lot.

<o​frnxmr:xmr.mx> @rsch "I have found the bug and will prepare a PR" << did you find the issue?

yes I have a fix already

<o​frnxmr:xmr.mx> 1. Build branch master, see if you can reproduce on master. If yes, open pr against master

<o​frnxmr:xmr.mx> 2. Build branch release-v0.18, see if you can reproduce on release-v0.18. If yes, open pr against release-v0.18

ok sure

ofrnxmr: PR pushed

for both branches

<o​frnxmr:xmr.mx> thanks. nits: change commit name to `simplewallet: cli using wrong filename for storing keys`, append `[0.18]` to the end of the release pr title, and add "closes #9943" to the pr description of master pr

<b​inarybaron:matrix.org> Isn’t this really bad for Layer 2 protocols. Bidirectional Atomic Swaps would require timelocks.

<o​frnxmr:xmr.mx> why would they require timelocks

<o​frnxmr:xmr.mx> Also, timelocks are already deprecated

<o​frnxmr:xmr.mx> if you mean "xmr as leader aka first transaction in the swap", xmr doesnt have scripting. What does a timelock have to do with anything

Are the timelocks in Hash Time Locked Contracts the same timelocks :)

ofrnxmr: applied

<r​brunner7:monero.social> Once again, because it's such a joy: The timelocks Monero has / soon will not have anymore are **not** suitable to implement atomic swaps.

<r​brunner7:monero.social> Getting rid of them does not prevent implementing bidirectional atomic swaps, they are useless for that.

<r​brunner7:monero.social> That we do not have the **right* timelocks is a possible reason to prevent that.

rucknium: monero-project/monero #9946 there will still be a 2 weeks or so before I aim to tag, but since you asked recently