<u​ser9219:matrix.org> lol fair enough

Hey i have a hacathon where i have to make a similar thing like monero dev can you help me

<a​remor:matrix.org> Def should make a thing like ChatGPT instead

<p​reland:monero.social> Depressing but true

<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

<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

<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: monerokon.devfolio.co/projects

<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 ...

<r​brunner7:monero.social> Just "doing a hackathon" and not merely "doing normal dev work" does not magically unlock super powers :)

<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

<r​brunner7:monero.social> And on top of it, you may entirely miss the conference. You are both there and not there.

<r​brunner7:monero.social> Wow, so many hackathons. I guess I am looking at cumulated decades of dev work here on this page: devfolio.co/hackathons/past

<r​brunner7:monero.social> People seem to have too much time on their hands ...

<y​pavtv97lx:matrix.org> Hello, any date approximation of FCMP hardfork ? 6 months, 12 months ?

<r​brunner7:monero.social> "roughly 1 year" is what I repeatedly wrote already, and nobody opposed too much

<y​pavtv97lx:matrix.org> Thank you for info.

<u​ser9219:matrix.org> do you know when fcmp might jump on live testnet

<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".

<u​ser9219:matrix.org> this is good enough :)))) Very much appreciate sir

<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>

<w​oodser:monero.social> l, fast, fastest]." in order to calculate the fee estimate for default priority.

<w​oodser:monero.social> does default=slow, unimportant=normal, normal=fast, elevanted=fastests? in which case I guess the documentation is wrong? docs.getmonero.org/rpc-library/monerod-rpc/#get_fee_estimate

<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

default = 0 aka auto aka 1 (unimportant) vs 2 (normal)

Default=auto, unimportant=slow, normal=normal, elevated=fast. 1-4 gets mapped to 0-3

<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 github.com/perfect-daemon/monero/bl…/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>

<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.

<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 github.com/monero-project/monero/bl…/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>

<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.

<s​pirobel:kernal.eu> nvm found it monero-project/monero #5649/files

<o​frnxmr:monero.social> --disable-rpc-ban, and also building the release branch might fix start height

<s​pirobel:kernal.eu> I want it to work with most of the remote hosts. I just need to avoid 500 responses from getblocksbin

<s​pirobel:kernal.eu> but it is annoying and makes everything more brittle

<s​pirobel:kernal.eu> read this beauty and figured out this specific 500 github.com/monero-project/monero/bl…24/src/rpc/core_rpc_server.cpp#L611 :-)