14:44:11 <m-relay> <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?
14:45:53 <selsta> does it not work?
14:46:02 <selsta> in the past it did from what i remember
15:30:56 <m-relay> <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.
15:31:59 <sech1> CLI wallet warns about backlog, but chooses the lowest fee as default
15:33:49 <sech1> nvm, I used "set priority" command before to always use the lowest
15:35:03 <sech1> nope, even after "set priority default" CLI wallet chooses the lowest fee now and then warns about backlog
15:35:15 <selsta> might be a regression, the automatic fee feature worked in the past :/
15:36:17 <selsta> maybe we can also quickly fix that issue before we put out the release
15:43:47 <m-relay> <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?
15:46:12 <sech1> yes, fees get lower with bigger blocks
15:52:36 <selsta> >We don't use the low priority because there's a backlog in the tx pool.
15:52:53 <selsta> that's from the wallet2 log, it must go wrong somewhere after that message
15:57:06 <m-relay> <s​packle_xmr:matrix.org> The long term median needs to adjust before fees get lower, no?
16:10:52 <nioCat> selsta: confirming that the CLI is using the minimum fee   
16:10:57 <nioCat> also no warning of backlog when it displays the fee and then asks "Is this ok?  (Y/Yes/N/No):
16:11:32 <sech1> it does warn about the backlog
16:11:52 <selsta> There is currently a 18 block backlog at that fee level. Is this okay?
16:12:24 <selsta> nioCat: when you enter `set` what does it say for `confirm-backlog` and `confirm-backlog-threshold` ?
16:12:33 <selsta> it should be `1` and `0`
16:12:47 <nioCat> sech1: at what point does it warn you
16:12:53 <selsta> after you enter the password
16:13:00 <sech1> right after entering the password
16:13:13 <nioCat> n
16:14:37 <nioCat> selsta: yes, 1 and 0
16:17:35 <nioCat> I did not receive a warning after entering password, it is using min fee
16:17:49 <m-relay> <t​obtoht:monero.social> https://github.com/monero-project/monero/blob/master/src/wallet/wallet2.cpp#L8121 should return 1? priority is never changed
16:18:21 <selsta> i think 1 is lowest and 0 is default
16:18:35 <m-relay> <t​obtoht:monero.social> oh, 2 then
16:18:54 <selsta> i think there should be a codepath somewhere else for 0 prio
16:19:06 <selsta> but didn't find it yet
16:21:13 <sech1> wallet2::adjust_priority, as it's written, can only return 0 (default) or 1 (lowest) if prority is set to 0 (default)
16:21:58 <sech1> for non-zero priority, it just returns it without changing
16:22:11 <sech1> so it never goes from 0 (default) to any high priorities
16:22:22 <m-relay> <t​obtoht:monero.social> https://github.com/monero-project/monero/blob/master/src/wallet/wallet2.cpp#L8009
16:22:59 <selsta> >(default, but should not end up here)
16:25:34 <sech1> So this auto-adjust code is broken and probably never worked correctly, because there was no need - blocks weren't full
16:26:24 <selsta> i 100% remember testing this a while ago and it worked, but maybe i tested it incorrectly somehow
16:28:28 <nioCat> I remember it working in the past 
16:28:36 <m-relay> <t​obtoht:monero.social> get_base_fee got refactored in late 2021, i think it ended up here before https://github.com/monero-project/monero/blob/master/src/wallet/wallet2.cpp#L7964
16:28:57 <selsta> here is a patch that would work in the short term
16:34:12 <selsta> https://github.com/monero-project/monero/commit/b030f207517f59a5122409398549a02ac23829ae
16:45:29 <selsta> 17:28 <selsta> here is a patch that would work in the short term <-- ignore, my idea didn't work
16:58:27 <selsta> 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
17:00:08 <selsta> i guess it would be useful if someone manually changes the default fee from lowest to something higher
17:07:00 <m-relay> <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.
17:27:41 <sech1> I think so
17:27:55 <sech1> because I couldn't get my CLI wallet to choose higher priority automatically
17:32:49 <selsta> did the CLI ever support this? or only a backlog warning message?
17:33:47 <sech1> no idea
17:34:06 <sech1> but it does have 0 (default) fee level, whatever it means
17:34:14 <sech1> I suppose it should choose the fee when it's 0
17:53:58 <m-relay> <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 ...
18:06:52 <m-relay> <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.
18:08:00 <m-relay> <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.
18:08:29 <m-relay> <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.
18:42:44 <selsta> would something like this work in the short time? https://paste.debian.net/hidden/12c79a5c/
19:56:52 <m-relay> <r​ucknium:monero.social> Draft Reddit post "PSA: Manually increase your transaction fee if you want a quick confirmation": https://paste.debian.net/hidden/7914885f/
19:56:58 <m-relay> <r​ucknium:monero.social> Anything inaccurate in there?
19:59:39 <m-relay> <t​obtoht:monero.social> Looks good Rucknium
20:16:32 <m-relay> <p​lowsof:matrix.org> miners mouths are watering xD
20:19:54 <m-relay> <r​ucknium:monero.social> Posted: https://reddit.com/r/Monero/comments/1b946w3/psa_manually_increase_your_transaction_fee_if_you
21:27:34 <m-relay> <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
21:27:51 <m-relay> <n​ot_thankful_for_today:matrix.org> @selsta
21:28:08 <sech1> failing how?
21:28:09 <m-relay> <n​ot_thankful_for_today:matrix.org> gui is completely broken
21:28:21 <m-relay> <n​ot_thankful_for_today:matrix.org> i cant send any transaction, it keep ssaying transavtion failed
21:28:36 <m-relay> <n​ot_thankful_for_today:matrix.org> it wont confirm anythng
21:28:56 <m-relay> <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
21:30:14 <m-relay> <p​ndxmr:matrix.org> simple mode is broken
21:31:58 <m-relay> <n​ot_thankful_for_today:matrix.org> very concerning
21:32:06 <m-relay> <n​ot_thankful_for_today:matrix.org> concerning
21:33:54 <m-relay> <p​ndxmr:matrix.org> should be labeled dysfunctional mode
21:35:09 <selsta> did you lookup the transaction id on xmrchain.net ? does it show up or not?
21:35:38 <selsta> simple mode isn't broken, it's possible that this specific node you are connected to has issues
21:44:13 <selsta> not_thankful_for_today: which version are you using?
22:04:20 <m-relay> <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 ?
22:37:38 <ofrnxmr> simple mode connects to nodes that run the --public-node flag
22:38:36 <m-relay> <p​ndxmr:matrix.org> yes and there are lot of dishonest nodes on network, its known
22:38:40 <ofrnxmr> So not "random", but more often than not, malicious. --public-node is opt-in, and can cost a lot rpc data usage. 
22:39:24 <ofrnxmr> 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 
22:39:32 <m-relay> <p​ndxmr:matrix.org> it doesnt cost much a few vps here and there
22:39:32 <selsta> simple mode makes it clear what it is when selecting it
22:40:16 <m-relay> <p​ndxmr:matrix.org> just ask them to enter a remote node, while setting up simple node ?
22:40:32 <m-relay> <p​ndxmr:matrix.org> just ask them to enter a remote node, while setting up simple mode wallet ?
22:41:31 <m-relay> <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 ?
22:41:48 <selsta> yes
22:41:52 <selsta> you have to even check a checkbox
22:42:45 <ofrnxmr> Maybe just need to make it more obvious that one can enter a remote node 
22:43:17 <ofrnxmr> Simple vs remote node vs local node 
22:44:05 <ofrnxmr> With option 2 jumping straight to "enter node(s)"
23:57:07 <m-relay> <n​ot_thankful_for_today:matrix.org> 18.0.0.0
23:57:36 <m-relay> <n​ot_thankful_for_today:matrix.org> 0.18.0.0-release (Qt 5.12.8
23:57:40 <m-relay> <n​ot_thankful_for_today:matrix.org> 0.18.0.0-release (Qt 5.12.8)
23:57:54 <selsta> v0.18.0.0 works worse together with large transaction pools, you should upgrade
23:58:39 <m-relay> <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