<r​ucknium:monero.social> I read that the GUI is supposed to push suggested fees up a tier automatically if there is a large txpool backlog, but how large does it have to be?

does it not work?

in the past it did from what i remember

<r​ucknium:monero.social> It is not activating now. It sets the lowest fee/byte (20000) . About 20 block txpool backlog right now. Checked in both GUI and Feather. Feather is supposed to have same behavior as GUI.

CLI wallet warns about backlog, but chooses the lowest fee as default

nvm, I used "set priority" command before to always use the lowest

nope, even after "set priority default" CLI wallet chooses the lowest fee now and then warns about backlog

might be a regression, the automatic fee feature worked in the past :/

maybe we can also quickly fix that issue before we put out the release

<r​ucknium:monero.social> The highest tier of the `get_fee_estimate` RPC call to monerod now says 3900000 instead of 4000000. Is that because the median block weight increased?

yes, fees get lower with bigger blocks

>We don't use the low priority because there's a backlog in the tx pool.

that's from the wallet2 log, it must go wrong somewhere after that message

<s​packle_xmr:matrix.org> The long term median needs to adjust before fees get lower, no?

selsta: confirming that the CLI is using the minimum fee

also no warning of backlog when it displays the fee and then asks "Is this ok? (Y/Yes/N/No):

it does warn about the backlog

There is currently a 18 block backlog at that fee level. Is this okay?

nioCat: when you enter `set` what does it say for `confirm-backlog` and `confirm-backlog-threshold` ?

it should be `1` and `0`

sech1: at what point does it warn you

after you enter the password

right after entering the password

n

selsta: yes, 1 and 0

I did not receive a warning after entering password, it is using min fee

<t​obtoht:monero.social> github.com/monero-project/monero/bl…master/src/wallet/wallet2.cpp#L8121 should return 1? priority is never changed

i think 1 is lowest and 0 is default

<t​obtoht:monero.social> oh, 2 then

i think there should be a codepath somewhere else for 0 prio

but didn't find it yet

wallet2::adjust_priority, as it's written, can only return 0 (default) or 1 (lowest) if prority is set to 0 (default)

for non-zero priority, it just returns it without changing

so it never goes from 0 (default) to any high priorities

<t​obtoht:monero.social> github.com/monero-project/monero/bl…master/src/wallet/wallet2.cpp#L8009

>(default, but should not end up here)

So this auto-adjust code is broken and probably never worked correctly, because there was no need - blocks weren't full

i 100% remember testing this a while ago and it worked, but maybe i tested it incorrectly somehow

I remember it working in the past

<t​obtoht:monero.social> get_base_fee got refactored in late 2021, i think it ended up here before github.com/monero-project/monero/bl…master/src/wallet/wallet2.cpp#L7964

here is a patch that would work in the short term

17:28 <selsta> here is a patch that would work in the short term <-- ignore, my idea didn't work

if I understand it correctly there is a auto_low_fee function enabled by default, it means if there's no backlog it should set the lowest fee – but that only makes sense if the default fee is higher than the lowest fee

i guess it would be useful if someone manually changes the default fee from lowest to something higher

<r​ucknium:monero.social> Are we confident enough that the bug exists to report this on Reddit etc.? We could tell people that they have to raise their fee manually for quick confirmations.

I think so

because I couldn't get my CLI wallet to choose higher priority automatically

did the CLI ever support this? or only a backlog warning message?

no idea

but it does have 0 (default) fee level, whatever it means

I suppose it should choose the fee when it's 0

<r​brunner7:monero.social> I dimly remember that I once looked at that fee level choosing logic, and found it quite confusing, and I would not have been able to prove that everything works as it should. May well be that this broke somewhere on the way ...

<r​ucknium:monero.social> If the average fee of txs that are actually being mined in blocks increases, does the GUI/CLI increase fees? If the suspected spammer puts the spam tx fee level to the next tier, users would be in a bad spot if the auto adjustment doesn't occur.

<r​ucknium:monero.social> Right now users' tx eventually get confirmed because monerod's block construction algorithm tries to confirm txs on a first come, first served basis when the txs have the same fee level.

<s​packle_xmr:matrix.org> If the spammer begins sending massive amounts of txs with higher fees the block size will increase quite rapidly compared to what we are seeing now.

would something like this work in the short time? paste.debian.net/hidden/12c79a5c

<r​ucknium:monero.social> Draft Reddit post "PSA: Manually increase your transaction fee if you want a quick confirmation": paste.debian.net/hidden/7914885f

<r​ucknium:monero.social> Anything inaccurate in there?

<t​obtoht:monero.social> Looks good Rucknium

<p​lowsof:matrix.org> miners mouths are watering xD

<r​ucknium:monero.social> Posted: reddit.com/r/Monero/comments/1b946w…ncrease_your_transaction_fee_if_you

<n​ot_thankful_for_today:matrix.org> selsta the monero gui is completely broken i cant send any transaction, all my transactions are failing and i cant even change the fee either

<n​ot_thankful_for_today:matrix.org> @selsta

failing how?

<n​ot_thankful_for_today:matrix.org> gui is completely broken

<n​ot_thankful_for_today:matrix.org> i cant send any transaction, it keep ssaying transavtion failed

<n​ot_thankful_for_today:matrix.org> it wont confirm anythng

<n​ot_thankful_for_today:matrix.org> i guess due to the low fee? it wont let me change the fee either bc im in simple mode

<p​ndxmr:matrix.org> simple mode is broken

<n​ot_thankful_for_today:matrix.org> very concerning

<n​ot_thankful_for_today:matrix.org> concerning

<p​ndxmr:matrix.org> should be labeled dysfunctional mode

did you lookup the transaction id on xmrchain.net ? does it show up or not?

simple mode isn't broken, it's possible that this specific node you are connected to has issues

not_thankful_for_today: which version are you using?

<p​ndxmr:matrix.org> it connects to random nodes ? and there is no way for user to know if its honest or not ? is there a option in gui to rebroadcast tx using a different node ?

simple mode connects to nodes that run the --public-node flag

<p​ndxmr:matrix.org> yes and there are lot of dishonest nodes on network, its known

So not "random", but more often than not, malicious. --public-node is opt-in, and can cost a lot rpc data usage.

So running it, is people who a) know how to config a node AND want to share their rpc with random noobs or b) bad actors

<p​ndxmr:matrix.org> it doesnt cost much a few vps here and there

simple mode makes it clear what it is when selecting it

<p​ndxmr:matrix.org> just ask them to enter a remote node, while setting up simple node ?

<p​ndxmr:matrix.org> just ask them to enter a remote node, while setting up simple mode wallet ?

<p​ndxmr:matrix.org> i havent used it recently, but does it warn users about connecting to malicous nodes and how it can affect their privacy ?

yes

you have to even check a checkbox

Maybe just need to make it more obvious that one can enter a remote node

Simple vs remote node vs local node

With option 2 jumping straight to "enter node(s)"

<n​ot_thankful_for_today:matrix.org> 18.0.0.0

<n​ot_thankful_for_today:matrix.org> 0.18.0.0-release (Qt 5.12.8

<n​ot_thankful_for_today:matrix.org> 0.18.0.0-release (Qt 5.12.8)

v0.18.0.0 works worse together with large transaction pools, you should upgrade

<n​ot_thankful_for_today:matrix.org> its a huge hassle to upgrade, i have to verify the software is safe etc its a huge stressful process for me my entire net worth is in the gui. if i get malware i dont have a dime to my name