06:00:28 <m-relay> <k​oopacxz:matrix.org> Hello i did an exchange on a swap site for it
06:00:34 <m-relay> <k​oopacxz:matrix.org> Was success but im not recieving on my wallet
06:00:35 <m-relay> <k​oopacxz:matrix.org> I have the
06:01:22 <m-relay> <k​oopacxz:matrix.org> transaction hash output
06:02:33 <m-relay> <k​oopacxz:matrix.org> on localmonero.com
06:02:34 <m-relay> <k​oopacxz:matrix.org> can anyone help me please?
06:17:41 <m-relay> <c​t:xmr.mx> localmonero stopped operations, but withdrawing funds should be possible. Can we continue this in Monero  please? This room is for development coordination, not user support.
06:26:13 <m-relay> <k​oopacxz:matrix.org> Hello i did an exchange on a swap site for it
06:26:21 <m-relay> <k​oopacxz:matrix.org> Was success but im not recieving on my wallet
06:26:29 <m-relay> <k​oopacxz:matrix.org> transaction hash output
06:26:29 <m-relay> <k​oopacxz:matrix.org> on localmonero.com 
06:26:31 <m-relay> <k​oopacxz:matrix.org> can anyone help me please?
07:11:16 <rbrunner> matrix.org ... ideally somebody with a matrix.org account should explain it to them
07:21:13 <m-relay> <c​t:xmr.mx> user double posted in Monero GUI  as well, I'm taking the convo there with my matrix.org account
13:18:13 <spackle> I am hoping for some assistance with a private testnet. 
13:18:13 <spackle> I am following this guide (https://github.com/moneroexamples/private-testnet), but launching 10 nodes on the same machine in the attempt to recreate the OOM issue locally (https://github.com/monero-project/monero/issues/9317). However, the nodes do not end up all connecting to one another. They are limiting themselves to 1 in connection. 
13:18:13 <spackle> I do not know if some optimization is the cause; can anyone speak to this?
13:25:52 <moneromooo> Try twiddling this:
13:25:53 <moneromooo>   --max-connections-per-ip arg (=1)     Maximum number of connections allowed 
13:25:57 <moneromooo>                                         from the same IP address
13:28:18 <spackle> ah, figured I was doing something foolish. Thank you.
13:41:45 <m-relay> <w​oodser:monero.social> any idea what could lead to this error in practice, when importing multisig info?
13:41:47 <m-relay> <w​oodser:monero.social> ```
13:41:49 <m-relay> <w​oodser:monero.social> THROW_WALLET_EXCEPTION_IF(public_spend_key != keys.m_spend_public_key || public_view_key != keys.m_view_public_key,
13:41:51 <m-relay> <w​oodser:monero.social>         error::wallet_internal_error, "Multisig info is for a different account");
13:41:53 <m-relay> <w​oodser:monero.social> ```
13:43:19 <m-relay> <w​oodser:monero.social> we're seeing this error where it usually works, but somehow the user's wallet got into this state, and I haven't seen it before
13:45:14 <moneromooo> View only wallet ? Encrypted wallet keys and the enc/dec pairing got buggy (try "spendkey" and "viewkey" and checking they're what you expect) ? Corrupted file passed around ?
13:47:02 <m-relay> <w​oodser:monero.social> will look into those, thanks for the pointers
14:03:05 <selsta> .merge+ 9345 9346 9347
14:03:05 <xmr-pr> Added
14:27:07 <rbrunner> I have recently updated to Debian Bookworm and try to compile Monero master for the first time after this. I get an error:
14:27:09 <rbrunner> *** No rule to make target '/usr/lib/x86_64-linux-gnu/librt.so', needed by 'contrib/epee/src/libepee.so'.  Stop.
14:27:33 <rbrunner> Indeed I don't have such a file "librt.so" there, only "librt.so.1"
14:34:13 <rbrunner> I also have a "librt.a" but I don't think that is relevant ...
14:41:20 <moneromooo> try: ldconfig /usr/lib/x86_64-linux-gnu (as root).
14:49:42 <rbrunner> Hmm, does not seem to create a "librt.so" symlink. I created one now manually, just to see what happens.
14:55:14 <moneromooo> file /usr/lib/x86_64-linux-gnu/librt.so.1 shows it's an actual shared library ?
14:55:23 <moneromooo> (or nm)
14:58:49 <rbrunner> Yes
15:00:49 <rbrunner> Is there something more thorough than "make clean"? I suspect something from previous compilations might be left
15:01:13 <selsta> delete the build folder?
15:01:29 <selsta> or the subfolder from the branch you are trying to compile
15:02:06 <rbrunner> The "build" folder would be a bit radical, I have much stuff in those "bin" directories, unfortunately
15:03:02 <moneromooo> make clean deletes the build tree :)
15:03:55 <selsta> I think deleting CMakeCache.txt would work too but not sure
15:04:52 <rbrunner> Sigh. Right now I have the effect that release compiles, but debug not. I think I will clone again, just to start with something 100% clean, and try again
15:05:32 <rbrunner> Thanks for the help, mooo and selsta. Let's see how it goes.
15:05:44 <moneromooo> IIRC there's a longstanding thing with circular dependencies that show up in debug mode but not release mode. Though unrelated to librt.
15:06:16 <selsta> we did fix build issues with make debug a while ago, but there might be new issues at this point
15:10:15 <rbrunner> Current master is known to compile right now I guess?
15:10:40 <selsta> yes
15:10:49 <selsta> releaase build, I don't know about debug build
15:11:12 <rbrunner> Ok, I see
15:15:01 <rbrunner> My local GitHub repository is years old. Maybe it started to accumulate cruft like Windows does over the years :)
15:29:26 <rbrunner> Result with a fresh clone of the Monero repository, master branch: Release compiles, Debug not. That "librt.so" problem did not re-occur, but this wild compile error does:
15:29:45 <rbrunner> var/git/monero-orig/contrib/epee/src/readline_buffer.cpp:177: undefined reference to `epee::string_tools::trim_right(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)
15:30:26 <selsta> might be related to https://github.com/monero-project/monero/pull/9342
15:30:42 <selsta> this also explains why we didn't see this on CI
15:33:39 <rbrunner> Using a Boost version of `trim_right` instead of that cute, little and totally harmless `epee::string_tools::trim_right` as a solution for, well, something. Seriously? :)
15:35:13 <selsta> the boost version has a better algorithm, that's why we switched
15:35:48 <rbrunner> Alright, alright, but why should the epee version not compile?
15:36:23 <rbrunner> All of a sudden, probably, in code that is, what, almost 10 years old now? But hey, what do I know ...
15:36:53 <selsta> we did have changes to it a couple weeks ago, jeffro is partly reverting it
15:37:28 <rbrunner> Ok, no problem, I am just ROFL about all this C++ stuff
15:38:04 <rbrunner> So cherry-picking that PR would be worth a try, yes?
15:38:25 <selsta> yes
15:38:58 <rbrunner> Ok, will try, but probably not today still, maybe Sunday. Release compiles, so no emergency for me
18:22:58 <vthor> I know I shouldn't but maybe it helps, same question as in #monero-gui:  I figured just out that `monero-python` doesn't support passwort protection for the seed phrase, but I pretty sure I have seen that in Monero-GUI. Anybody know how it is done in Monero-GUI? I want to implement it compatible into MoneroSigner - will it send me down a rabbit hole or easy thing to do like, `unlock(key: bytes, password: str) -> bytes`? Or better I let it for now unsupported 
18:22:59 <vthor> and handle it later? Anybody who is knowing the part of the source here?
18:27:34 <rbrunner> I would say `encrypt_key` and `decrypt_key` in "cryptonote_format_utils.cpp"
18:32:29 <vthor> rbrunner: thank you, will look there :)
18:33:16 <rbrunner> Welcome. Just verified with my own MoneroTech website code, I do it the same way
18:38:06 <vthor> rbrunner: can you give me the url, please? MoneroTech...
18:39:17 <rbrunner> https://monerotech.info/ , and especially https://monerotech.info/Home/Transformation
18:51:41 <vthor> Thank you :) So, the password will be hashed and then the bytes mangled, but not xor how there is sc_add and sc_sub, I have the dumb feeling it will send me again down some rabbit hole. Do you know if the cn_slow_hash is standard hash function, and do you know how sc_add/sc_sub work. And your server based app is written in C++, too, or another language?
18:58:02 <vthor> ahhhhhh found slow-hash.c, so yes absolute rabbit hole :/ Thank you, your input helped me to no go donw the rabbit hole right now, and but it only on the todo list for now.
18:58:10 <rbrunner> C#. cn_slow_hash is Keccak if I remember correctly, and sc_add and sc_sub is ECC arithmetic.
18:59:35 <rbrunner> You work with Python, right? Maybe you should ask dangerousfreedom, the guy behind https://www.moneroinflation.com/. I am not quite sure, but I think most of his code is Python, and he might have all those primitives
19:00:08 <sech1> cn_slow_hash is the old Cryptonight
19:00:11 <sech1> cn_fast_hash is Keccak
19:01:32 <rbrunner> Ah, yes. Whoever had the idea to use Cryptonight for our seed offsets ...
19:02:08 <vthor> 135 lines, from keccak over cryptonight, aes, and there I stopped locking for cn_slow_hash :/
19:03:14 <vthor> rbrunner: that person should transpile it into all other available languages asm, cobol and vba included
19:03:30 <rbrunner> :)
19:04:23 <vthor> well, that is something for future or complile and use only the c++lib from python - but not to decide today :( :/
19:04:38 <vthor> Thank you very much again, rabbit holes are dangerous or me :D
19:05:43 <rbrunner> Have fun
19:06:27 <m-relay> <s​needlewoods:monero.social> monero can be a fractal tree of rabbit holes, easy to get lost
19:07:22 <rbrunner> Just wait until FCMPs go into service, and then maybe Seraphis on top ... then everything we have so far might look like child's play.
19:07:53 <rbrunner> Now we have 2 private keys, already 1 more than most coins. Jamtis has a freaking tree of 4 or 5 private keys derived from each other.
19:09:09 <rbrunner> Somehow I wait for the day some genius comes along and brings us revelation and shows us how you can do a fully private coin in 1000 code lines :)
19:18:17 <vthor> rbrunner: :D well, switch to good old Perl could help to pack it in 1000 lines of code....
19:18:48 <vthor> ...not even th e person which wrote it will understand on typing the last charakter.
19:28:43 <sech1> rbrunner Cryptonight as key derivation function makes sense. It slows down brute force search
19:29:28 <rbrunner> Yeah, had the same thought. And 3 seconds afterwards: Just make 1000 rounds of Keccac. Or something similar that takes time.
19:31:06 <rbrunner> But of course I see that strictly within the framework of the Monero codebase itself, that choice makes sense. Only if you step outside a bit it becomes a bit questionable
20:08:30 <moneromooo> Keccak is easily ASICable. Doesn't make a good KDF.
20:34:08 <Guest54903854> (forwarded from monero)
20:34:08 <Guest54903854> Hi all, I hope this doesn't qualify as a monero-dev quesiton. I'm studying cryptonight and randomx for a uni project, and I have a question: how is randomx related to cryptonote?
20:34:09 <Guest54903854> I know that cryptonote is the protocol used by Monero, while randomx is the PoW algorithm. I found some old papers (Cryptonote v1 and v2, through web archive) that explain how the protocol was born. Now I'm not sure whether we can still talk about Cryptonote becase "CryptoNight is the name of the hash function that is used in the CryptoNote
20:34:09 <Guest54903854> Proof-of-Work algorithm", while using RandomX
20:36:05 <sech1> RandomX is not a part of Cryptonote
20:36:34 <sech1> It was developed as an standalone PoW function, with an aim to use it for Monero