<o​frnxmr:monero.social> Thats how money is supposed to work right?

<o​frnxmr:monero.social> Welcome to monero

<1​23bob123:matrix.org> Once you’re in it’s fine.

<p​lowsof:matrix.org> if you try to leave us, you may have problems (i have severe separation anxiety)

<1​23bob123:matrix.org> Yeah blood in,blood out here

<n​ullifydev:matrix.org> xDDD

<n​ullifydev:matrix.org> aight

<n​ullifydev:matrix.org> i done more research and it is safe to say i got the things i need and need to know

<n​ullifydev:matrix.org> Thanks plowsof for the kycnot.me website. I find it genuinely helpful.

<n​ullifydev:matrix.org> Thanks, yall! :D

<1​23bob123:matrix.org> monerodirectory.com

<m​onerobull:matrix.org> >Feather now starts exactly one second faster

<m​onerobull:matrix.org> is that one of those cases where you ship with deliberate delays and comment them out every now and then to be able to say "sped up by x%"? /S

monerobull It's this one: monero-project/monero #8894

<m​onerobull:matrix.org> ah yeah remember seeing that at some point

I'm not sure, I think they fixed it first. I saw it in their changelog and fixed it in Monero too.

<t​obtoht:monero.social> yeah, I took the more aggressive approach and patched out the whole loop since the wallet doesn't need accurate performance logging

<t​obtoht:monero.social> 100 ms delay is still a lot imo

<t​obtoht:monero.social> might make sense to only enable it for debug builds

It's comparable to other startup code

Ideally it would run in a separate thread, you're welcome to make a pull request :D

<m​onerobull:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/EeUWZdMGScjYqInRmDnRFCgv

<m​onerobull:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/iQHXrTteDeNVIkeKqzYikBmm

<m​onerobull:matrix.org> what can we expect from these numbers

<p​lowsof:matrix.org> 100ms ping

<p​lowsof:matrix.org> ignore^ what are those cpu models? soon to be released?

Probably better efficiency than Bitmain's X5 :P

<p​lowsof:matrix.org> more info here: ir.amd.com/news-events/press-releas…-amd-ryzen-threadripper-7000-series

<m​onerobull:matrix.org> there were already more efficient ryzens when the x5 chips were introduced right

<1​23bob123:matrix.org> Expensive threadripper

7950X rig can get the same power efficiency as X5, but you really need to tune it to the limit

Zen4 threadrippers achieve higher efficiency easily

<p​lowsof:matrix.org> Just wanna share that Rucknium released an update on the Exodus custom fee situation, they updated, and those non-standard fees are declining as shown by: monero.town/pictrs/image/7e97cd98-46dc-4e8c-8459-47fb4c01e7e5.webp , announcement here monero.town/post/842460

<system> file +Monero.JPG too big to download (2579696 > allowed size: 1000000)

<x​mrfn:monero.social> +Monero.JPG

<b​usyboredom:monero.social> Sweet, man Rucknium is having a good year between this and his block template generation timing spot earlier this year.

<r​4v3r23:monero.social> looking forward to the pocketchange analysis

<r​ucknium:monero.social> BusyBoredom: Thanks! Both of those discoveries happened accidentally while I was working on deeper problems. Who know what will happen when I solve those original research questions ;)

<r​ucknium:monero.social> There are at least 4 other nonstandard fee clusters that we haven't linked to a specific wallet implementation: github.com/Rucknium/misc-research/tree/main/Monero-Nonstandard-Fees

<r​ucknium:monero.social> So users could check their wallets or services they use to see if they may be producing nonstandard fees

<r​ucknium:monero.social> I need to update the README.md to say that the source of the `24_34_44_fee` has been identified (Exodus Desktop) and a fix released.

<4​rkal:monero.social> Did I miss the 3 mill block party?

<p​lowsof:matrix.org> definitely not.. the fruit bowl is still.. i mean, it looks like theres 1 pear left.. and im sure we can get someone to refill the coffee machine... ill brb and see if i can find him. but welcome!

<o​frnxmr:monero.social> Noticed some swaps seem to

<o​frnxmr:monero.social> Need to rererecheck

<o​frnxmr:monero.social> Rucknium perhaps articmine, is it _best_ for scaling if all wallets used the "auto" fee tier? Or is it ideal to allow manually set fees

<z​xchen:matrix.org> is there any bridge to bridge xmr to ethereum or ethereum to xmr?

<o​frnxmr:monero.social> Xmr eth atomic swaps?

<o​frnxmr:monero.social> Never used em myself

<o​frnxmr:monero.social> Or just trocador.app if you just want to swap

<r​ucknium:monero.social> ofrnxmr: That's one of the deep problems I was researching.

<r​ucknium:monero.social> First I started collecting mempool data to see empirical demand for Monero block space. Then I noticed something strange about confirmation times....

<r​ucknium:monero.social> To trigger changes in the dynamic block size, users need to tell miners that they are willing to pay more for block space.

<z​xchen:matrix.org> is it safe and stable ?

<z​xchen:matrix.org> I found atomic-swap need command line, would be a bit complicate

<o​frnxmr:monero.social> Yeah

<r​ucknium:monero.social> "Auto" is supposed to increase fees to the next level (of 4 levels) if (checking a source)

<r​ucknium:monero.social> monero.stackexchange.com/questions/…ultiplier-levels#comment10765_11658

<r​ucknium:monero.social> "Automatic goes like this: If there's a backlog in tx pool, use Normal (5). If the last 10 blocks on chain use up 80% or more of the full reward zone, use Normal (5). Otherwise use Slow (1). This is because adjust_priority when called with priority 0 (auto), either keeps priority at 0 or changes to 1. Then when get_fee_multiplier is called, if priority is still 0, it will use the <clipped message>

<r​ucknium:monero.social> Normal multiplier. Otherwise Slow gets used."

<r​ucknium:monero.social> This info may be out of date

<o​frnxmr:monero.social> github.com/spackle-xmr/Dynamic_Block_Demo/tree/main/Media

<o​frnxmr:monero.social> spackle_xmr: do you have a link to the one you did on just fees?

<s​packle_xmr:matrix.org> ofrnxmr: Do you mean the simulations looking at blocksize growth from only minimum fee transactions?

<s​packle_xmr:matrix.org> I did not upload media on that, but I certainly can if someone wants to look at it. Running the simulation with RUN_TYPE = 5 and USERS_PAY_MORE = 0 should give the same results I was looking at.

<s​packle_xmr:matrix.org> Running the econ draft of the python script with those settings, I mean. The results will also change a bit depending on T_sim, but that gets into a complex discussion about how close each block would end up being to the absolute theoretical limit allowed.

<a​tomfried:matrix.org> kuno.anne.media/fundraiser/uoog

<a​tomfried:matrix.org> just gonna leave this here.

<a​tomfried:matrix.org> mods can remove it if needed

irc is 4eva

<c​omradeblin:matrix.org> yea, sure. mybad.

<1​23bob123:matrix.org> Good tag

<c​omradeblin:matrix.org> plowsof: closed

nioc: youtu.be/92FCRmggNqQ?t=70

yep

how is there anyway to know if those kuno fundraising requests are legit?

<1​23bob123:matrix.org> Trust me bruh

<p​lowsof:matrix.org> there is no moderation on that platform (within reason). e.g. the one just posted now, i could have wrote that and put screenshots there.. ideally the address would be pgp signed, or their twitter handle would have tweet it .. something/anything

<c​omradeblin:matrix.org> Join us TMR at 11AM-EDT/5PM-CET to talk about a Monero Stadium and Jeserys with @LIBERTAD_CAL! + Price Report📈@BawdyAnarchist_, Dev Segment @GergelyGombai, News📷@tony_huszar

<c​omradeblin:matrix.org> 👀➡️ youtube.com/watch?v=A4vT54p_mjc

<c​omradeblin:matrix.org> 🎙➡️ streamyard.com/zrheev4e9z

<c​omradeblin:matrix.org> 🙏🏽

<c​omradeblin:matrix.org> 🎢

<c​omradeblin:matrix.org> @cakewallet

<c​omradeblin:matrix.org>

<c​omradeblin:matrix.org> @monerocom

<c​omradeblin:matrix.org> 🎢

<c​omradeblin:matrix.org> @LocalMoneroCo

<a​tomfried:matrix.org> are you talking about what i have posted?

<a​tomfried:matrix.org> twitter.com/JosephTheParrot/status/1714074304768262344

<a​tomfried:matrix.org> here is the tweet of him which links to the fundraiser

ah, thanks for confirming