03:56:08 <m-relay> <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
04:17:44 <m-relay> <n​obfg9000:matrix.org> when FCMP++ rolls out, will there still be timelocks?
06:50:35 <m-relay> <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
12:34:16 <rsch> hi
12:35:06 <rsch> 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?
12:41:44 <rsch> how can I checkout the most recent version for testing a bug?
12:43:11 <moneromooo> master is where most new stuff goes. Branching is made from master for every major release, to have some stability for subsequent minor releases.
12:44:03 <rsch> as usual I would create a branch for a bug fix and make a PR. is that ok?
12:44:10 <rsch> I mean from master
12:44:16 <rsch> or is there a more recent branch to use?
12:44:21 <moneromooo> 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.
12:44:44 <moneromooo> Yes, you do that. This local branch is only on your repo, you manage that however you see fit.
12:45:42 <rsch> am i wrong to say that the current cli release is since 2023?
12:46:01 <moneromooo> Sounds old.
12:46:28 <rsch> yea I am suprised that the bug is noticed so late
12:47:04 <moneromooo> I see march 2025.
12:47:23 <moneromooo> commit f1311d4237404ab7da76241dbf10e92a65132cc4 (tag: v0.18.4.0)
12:47:56 <rsch> CLI and GUI 0.18 "Flourine Fermi" released 2022 july. I guess it referes to the major changes
12:48:24 <moneromooo> Yes. There were several releases from the 0.18 branch. Last one a couple months ago.
12:51:03 <rsch> but in simplewallet the last commit is from Sun Nov 24 20:39:26 2024 +0000
12:51:21 <rsch> do you plan to move to rust in the future?
12:52:21 <moneromooo> 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.
12:53:57 <moneromooo> "how maintainable" here really means "whether existing monero hackers are conversant in rust" in large part.
12:54:18 <moneromooo> It's pointless to merge a big rust thing only for the contributor to fade away later.
12:54:29 <moneromooo> (if noone else around groks rust)
12:54:31 <rsch> I agree
12:55:15 <rsch> is there anything the project needs help with most? I see open issues since 2023
12:55:46 <moneromooo> I believe code review for existing long lived patches. Not fun though.
12:56:14 <rsch> oh yes there are 250 pr
12:56:20 <moneromooo> 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).
12:58:05 <moneromooo> 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).
12:59:22 <rsch> I wonder how active the monero dev is when you have open pr since 2020
13:00:13 <moneromooo> Well, feel free to tag along and find out.
13:00:27 <moneromooo> But git log will tell you a lot.
13:03:36 <m-relay> <o​frnxmr:xmr.mx> @rsch "I have found the bug and will prepare a PR" << did you find the issue?
13:04:10 <rsch> yes I have a fix already
13:05:20 <m-relay> <o​frnxmr:xmr.mx> 1. Build branch master, see if you can reproduce on master. If yes, open pr against master
13:05:21 <m-relay> <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
13:06:04 <rsch> ok sure
13:58:55 <rsch> ofrnxmr: PR pushed
13:59:05 <rsch> for both branches
14:06:13 <m-relay> <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
14:08:06 <m-relay> <b​inarybaron:matrix.org> Isn’t this really bad for Layer 2 protocols. Bidirectional Atomic Swaps would require timelocks.
14:09:03 <m-relay> <o​frnxmr:xmr.mx> why would they require timelocks
14:09:33 <m-relay> <o​frnxmr:xmr.mx> Also, timelocks are already deprecated
14:10:51 <m-relay> <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
14:13:37 <plowsof> Are the timelocks in Hash Time Locked Contracts the same timelocks :) 
14:13:51 <rsch> ofrnxmr: applied
14:14:46 <m-relay> <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.
14:15:29 <m-relay> <r​brunner7:monero.social> Getting rid of them does not prevent implementing bidirectional atomic swaps, they are useless for that.
14:15:54 <m-relay> <r​brunner7:monero.social> That we do not have the **right* timelocks is a possible reason to prevent that.
15:22:48 <selsta> rucknium: https://github.com/monero-project/monero/pull/9946 there will still be a 2 weeks or so before I aim to tag, but since you asked recently