03:21:38 <m-relay> <u​ser9219:matrix.org> lol fair enough
03:51:05 <Guest82> Hey i have a hacathon where i have to make a similar thing like monero dev can you help me
03:57:12 <m-relay> <a​remor:matrix.org> Def should make a thing like ChatGPT instead
06:11:45 <m-relay> <p​reland:monero.social> Depressing but true
06:12:40 <m-relay> <p​reland:monero.social> Though I won’t entirely discourage the person—just going to warn them that they are going to need to read through *a few* research papers and put in the work to get something that can even vaguely work
06:13:34 <m-relay> <p​reland:monero.social> That’s assuming the hackathon is giving you a relatively mediumish period of time to work on it—A week is the minimum for a, well, minimal setup, assuming best case scenario for everything
06:19:42 <m-relay> <r​brunner7:monero.social> Well, they organized a hackathon at MoneroKon 2024 in Prague, and it looks like only 2 teams took part, or had something to show at the end: https://monerokon.devfolio.co/projects
06:20:18 <m-relay> <r​brunner7:monero.social> Not exactly a roaring success, if true. And I am not surprised: Mostly, you can't just hack something together at this point of the Monero dev history ...
06:22:51 <m-relay> <r​brunner7:monero.social> Just "doing a hackathon" and not merely "doing normal dev work" does not magically unlock super powers :)
06:29:40 <m-relay> <p​reland:monero.social> I remember seeing that back in the day and thought about doing something, but the main issue for me was that the topic (iirc something that helped Monero) seemed both too broad and too difficult to accomplish within 48 hours
06:30:29 <m-relay> <r​brunner7:monero.social> And on top of it, you may entirely miss the conference. You are both there and not there.
06:42:10 <m-relay> <r​brunner7:monero.social> Wow, so many hackathons. I guess I am looking at cumulated decades of dev work here on this page: https://devfolio.co/hackathons/past
06:42:20 <m-relay> <r​brunner7:monero.social> People seem to have too much time on their hands ...
06:45:05 -xmr-pr- tobtoht opened pull request #9777: ci: development build backports [0.18]
06:45:05 -xmr-pr- > https://github.com/monero-project/monero/pull/9777
08:00:05 -xmr-pr- tobtoht opened pull request #9778: ci: containerize depends jobs [0.18]
08:00:05 -xmr-pr- > https://github.com/monero-project/monero/pull/9778
08:45:05 -xmr-pr- tobtoht opened pull request #9779: ci: consolidate ubuntu 20.04 runs
08:45:05 -xmr-pr- > https://github.com/monero-project/monero/pull/9779
08:50:47 <m-relay> <y​pavtv97lx:matrix.org> Hello, any date approximation of FCMP hardfork ? 6 months, 12 months ?
09:23:58 <m-relay> <r​brunner7:monero.social> "roughly 1 year" is what I repeatedly wrote already, and nobody opposed too much
09:25:49 <m-relay> <y​pavtv97lx:matrix.org> Thank you for info.
14:00:37 <m-relay> <u​ser9219:matrix.org> do you know when fcmp might jump on live testnet
14:09:39 <m-relay> <r​brunner7:monero.social> Ah, now it becomes more speculative :) But well, we have to get the hardfork-ready software into the hands of the users a few months before the hardfork itself, and before that extensive tests are needed for said software, so with a goal of hardforking in roughly 1 year you can calculate backwards and probably arrive at an estimate of "testnet in a few months".
14:21:03 <m-relay> <u​ser9219:matrix.org> this is good enough :)))) Very much appreciate sir
17:00:05 -xmr-pr- dbee01 opened issue #9780: newbie brainstorm question?
17:00:05 -xmr-pr- > https://github.com/monero-project/monero/issues/9780
17:15:05 -xmr-pr- dbee01 opened issue #9782: trying to sign up for announcements over github
17:15:05 -xmr-pr- > https://github.com/monero-project/monero/issues/9782
17:30:05 -xmr-pr- dbee01 opened issue #9783: Why isn't the codebase commented?
17:30:05 -xmr-pr- > https://github.com/monero-project/monero/issues/9783
19:59:37 <m-relay> <w​oodser:monero.social> I'm trying to map between the default priority in monero-wallet-rpc's `transfer` command, which states "priority - unsigned int; Set a priority for the transaction. Accepted Values are: 0-3 for: default, unimportant, normal, elevated, priority." to `get_fee_estimate` in monerod, which says "fees - array of unsigned int; Represents the base fees at different priorities [slow, norma<clipped message>
19:59:38 <m-relay> <w​oodser:monero.social> l, fast, fastest]." in order to calculate the fee estimate for default priority.
19:59:40 <m-relay> <w​oodser:monero.social> does default=slow, unimportant=normal, normal=fast, elevanted=fastests? in which case I guess the documentation is wrong? https://docs.getmonero.org/rpc-library/monerod-rpc/#get_fee_estimate
20:08:43 <m-relay> <w​oodser:monero.social> in other words, what index should I use with the `fees` field of `get_fee_estimate` to map to the `default` priority used in monero-wallet-rpc `transfer`, so that the fee estimate closely matches a generated transfer
20:54:16 <ofrnxmr> default = 0 aka auto aka 1 (unimportant) vs 2 (normal)
20:56:59 <ofrnxmr> Default=auto, unimportant=slow, normal=normal, elevated=fast. 1-4 gets mapped to 0-3
21:08:43 <m-relay> <s​pirobel:kernal.eu> can someone point me to the place where monerod defines the rate limits for the rpc connection? Are there some on the tcp layer as well? I was reading this, but unsure if it is the right spot https://github.com/perfect-daemon/monero/blob/master/contrib/epee/include/net/abstract_tcp_server2.h I am fetching getblocks.bin every second or every 5 or 10 seconds but it seems like it is <clipped message>
21:08:44 <m-relay> <s​pirobel:kernal.eu> too fast and I reliably get blocked. The block only happens if the start_height is the daemon height, not when catching up.
21:10:50 <m-relay> <s​pirobel:kernal.eu> can someone point me to the place where monerod defines the rate limits for the rpc connection? Are there some on the tcp layer as well? I was reading this, but unsure if it is the right spot https://github.com/monero-project/monero/blob/master/contrib/epee/include/net/abstract_tcp_server2.h I am fetching getblocks.bin every second or every 5 or 10 seconds but it seems like it is <clipped message>
21:10:52 <m-relay> <s​pirobel:kernal.eu> too fast and I reliably get blocked. The block only happens if the start\_height is the daemon height, not when catching up.
21:20:38 <m-relay> <s​pirobel:kernal.eu> nvm found it https://github.com/monero-project/monero/pull/5649/files
21:44:59 <m-relay> <o​frnxmr:monero.social> --disable-rpc-ban, and also building the release branch might fix start height
22:00:28 <m-relay> <s​pirobel:kernal.eu> I want it to work with most of the remote hosts. I just need to avoid 500 responses from getblocksbin
22:00:32 <m-relay> <s​pirobel:kernal.eu> but it is annoying and makes everything more brittle
22:15:59 <m-relay> <s​pirobel:kernal.eu> read this beauty and figured out this specific 500 https://github.com/monero-project/monero/blob/df54d8b3d478748dbf8ac0404aa9cdd14c7a2724/src/rpc/core_rpc_server.cpp#L611 :-)