00:34:37 <m-relay> <t​zadiko:matrix.org> Is @nahuhh in here? He invited me over to Matrix after commenting on this open issue I want to look at: https://github.com/monero-project/monero/issues/9799#issuecomment-2727050877
00:35:39 <NorrinRadd> tzadiko it's ofrnxmr 
00:36:08 <NorrinRadd> but better yet, what is it that you want to do? 
00:38:56 <m-relay> <t​zadiko:matrix.org> There's an issue outstanding to support elevated fee priorities in the automatic fee priority algorithm. Only unimportant and normal are currently supported, but the issue would like elevated to be supported during time of heavy congestion.
00:41:12 * plowsof finished full sync with gitian 
00:42:12 <m-relay> <o​frnxmr:xmr.mx> 30+hrs?
00:43:12 <plowsof> correct 3 ish hours less (laptop fell asleep) than 1d 9h 12m 27s
03:48:50 <m-relay> <t​zadiko:matrix.org> https://matrix.monero.social/_matrix/media/v1/download/matrix.org/HnzFLFepRxIcIaLYZNdXBRsc
03:48:59 <m-relay> <t​zadiko:matrix.org> What do these magic numbers refer to? (3, 2, 1, 0)?
04:47:52 <m-relay> <t​zadiko:matrix.org> Is wallet.h used anywhere? It looks like it has been fully sublanted by wallet2.h; yet, it's not marked as deprecated. I noticed it's refered in WalletManager, and some tests, but it doesn't seem to be used anywhere.
04:50:53 <m-relay> <a​remor:matrix.org> There’s a module called hardforks. Might be in there.
09:58:17 <m-relay> <f​ede:xmr.mx> i think it's there for compatibility, as it could be used by third-party projectsù
09:58:18 <m-relay> <f​ede:xmr.mx> i think it's there for compatibility, as it could be used by third-party projects
11:24:42 <m-relay> <r​brunner7:monero.social> Tzadiko: That file is part of the *Wallet API*. You are not supposed to use `wallet.h` however, but `wallet2_api.h`. This API is important, and will probably become more important still:
11:24:43 <m-relay> <r​brunner7:monero.social> https://old.reddit.com/r/Monero/comments/1cf8oom/the_monero_core_software_wallet_api_will_probably/
17:43:46 <m-relay> <t​zadiko:matrix.org> I made an MR to first clean up the Fee Priority code, no change to functionality. I plan to work off this branch to address issue 9799 (linked above). Here is the MR (the issue is linked in it as well):
17:43:46 <m-relay> <t​zadiko:matrix.org> https://github.com/monero-project/monero/pull/9838
17:43:48 <m-relay> <t​zadiko:matrix.org> Can someone look at this, please?
17:49:01 <selsta> jeffro256: https://github.com/monero-project/monero/issues/9758#issuecomment-2727562175
17:49:08 <selsta> could you take a look here? bug report
18:15:38 <m-relay> <g​ingeropolous:monero.social> im testing sync with the flags 
18:15:38 <m-relay> <g​ingeropolous:monero.social> prune-blockchain=true
18:15:40 <m-relay> <g​ingeropolous:monero.social> sync-pruned-blocks=true
20:30:31 <m-relay> <o​frnxmr:xmr.mx> Reproduced
20:30:47 <m-relay> <o​frnxmr:xmr.mx> Same block, same error
21:20:10 <m-relay> <t​zadiko:matrix.org> Both my MRs are failing on only Arch Linux, and Im not sure why. No clear error message when sifting through the logs on Github:
21:20:10 <m-relay> <t​zadiko:matrix.org> 1. https://github.com/monero-project/monero/actions/runs/13887134477/job/38853350914?pr=9831
21:20:12 <m-relay> <t​zadiko:matrix.org> 2. https://github.com/monero-project/monero/actions/runs/13887232626/job/38853579094?pr=9838
21:20:14 <m-relay> <t​zadiko:matrix.org> Any ideas?
21:23:40 <m-relay> <s​yntheticbird:monero.social> Seems to fail at Trezor support
21:24:21 <m-relay> <s​yntheticbird:monero.social> `make[2]: *** [src/device_trezor/CMakeFiles/obj_device_trezor.dir/build.make:79: src/device_trezor/CMakeFiles/obj_device_trezor.dir/trezor/messages_map.cpp.o] Error 1`
21:24:22 <m-relay> <s​yntheticbird:monero.social> `make[1]: *** [CMakeFiles/Makefile2:5267: src/device_trezor/CMakeFiles/obj_device_trezor.dir/all] Error 2`
21:25:30 <m-relay> <s​yntheticbird:monero.social> ```
21:25:30 <m-relay> <s​yntheticbird:monero.social> /__w/monero/monero/src/device_trezor/trezor/messages_map.cpp:116:50: error: no matching function for call to ‘hw::trezor::MessageMapper::get_message_wire_number(google::protobuf::internal::DescriptorStringView)’
21:25:32 <m-relay> <s​yntheticbird:monero.social>   116 |     return MessageMapper::get_message_wire_number(msg->GetDescriptor()->name());
21:25:34 <m-relay> <s​yntheticbird:monero.social>       |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
21:25:36 <m-relay> <s​yntheticbird:monero.social> ```
21:26:04 <m-relay> <t​zadiko:matrix.org> Thanks, investigating
21:26:53 <m-relay> <s​yntheticbird:monero.social> This PR have the same issue: https://github.com/monero-project/monero/actions/runs/13883578916/job/38845286332
21:26:58 <m-relay> <t​obtoht:monero.social> It's unrelated to your PR.
21:27:17 <m-relay> <t​obtoht:monero.social> You can ignore it. Will have to fixed in a separate PR.
21:28:48 <m-relay> <t​zadiko:matrix.org> Makes sense, I just looked at the code and I touched nothing near it
21:28:50 <m-relay> <t​zadiko:matrix.org> Thanks
21:28:56 <m-relay> <g​ingeropolous:monero.social> mine fails at a different block: Height: 1788724/3369270
21:29:00 <m-relay> <s​yntheticbird:monero.social> The start of the issue seems to coincide with arch linux update to protobuf 30.0: https://gitlab.archlinux.org/archlinux/packaging/packages/protobuf/-/commits/main
22:07:54 <m-relay> <t​zadiko:matrix.org> https://matrix.monero.social/_matrix/media/v1/download/matrix.org/YlYBnTYsxXCYVQpMHZnNbnZf
22:07:57 <m-relay> <t​zadiko:matrix.org> https://matrix.monero.social/_matrix/media/v1/download/matrix.org/LiHbOeDVPlIsLMpjYODhwHYU
22:08:08 <m-relay> <t​zadiko:matrix.org> In estimate_backlog, there is the concept of a full_reward_zone. I found that picture, it looks like it's saying that, if the current block weight is over two times the mediuan of the last X blocks, the block reward is cut down by 100% (is 0, miner only earns the transaction fee). I'm not sure if this is true, can someone please confirm?
22:12:48 <m-relay> <t​obtoht:monero.social> Fixed here: https://github.com/tobtoht/monero/commit/a5fabe5134026f04f3a77e82253c00a2d4baf0fa
22:12:55 <m-relay> <t​obtoht:monero.social> Protobuf is truly demented and we should consider dropping Trezor support over it. Only half joking. This garbage shouldn't exist in our codebase.
22:15:40 <m-relay> <r​ucknium:monero.social> Without double-checking various references, yes that's how the dynamic block size algorithm is supposed to work IIRC.
22:16:26 <m-relay> <t​zadiko:matrix.org> I took a look at the whitepaper and I believe it confirms my understanding as well. Thanks for chiming in
22:17:11 <m-relay> <o​frnxmr:xmr.mx> 1788794 here. Sorry. Indeed, different block
22:17:40 <m-relay> <r​ucknium:monero.social> The cryptonote whitepaper? That's very old. Newer references are _Zero to Monero 2.0_ and _Mastering Monero_.
22:18:21 <m-relay> <t​obtoht:monero.social> ofrnxmr: Is this a gitian build?
22:19:22 <m-relay> <o​frnxmr:xmr.mx> not this current run, no. Maxxor used my gitian build though
22:20:53 <m-relay> <t​obtoht:monero.social> I synced a --prune-blockchain gitian build without issue. Must be sync-pruned-blocks then?
22:24:15 <m-relay> <o​frnxmr:xmr.mx> Its sync-pruned-blocks, yes
22:24:31 <m-relay> <o​frnxmr:xmr.mx> I also synced prune-blockchain w/o issue
22:25:03 <m-relay> <o​frnxmr:xmr.mx> let me check a hyphothesis..
22:28:06 <m-relay> <b​oog900:monero.social> 9135 added a check that rejected any pruned downloaded txs: https://github.com/monero-project/monero/blob/f90a267fa34bad095d7e8ba72ee78f2a63f37df6/src/cryptonote_protocol/cryptonote_protocol_handler.inl#L106
22:28:09 <m-relay> <o​frnxmr:xmr.mx> I thought maybe has to do with this https://github.com/monero-project/monero/pull/9404#issuecomment-2679297363
22:28:24 <m-relay> <b​oog900:monero.social> V11 is just when we start asking for pruned blocks
22:29:22 <m-relay> <b​oog900:monero.social> https://github.com/monero-project/monero/blob/f90a267fa34bad095d7e8ba72ee78f2a63f37df6/src/cryptonote_protocol/cryptonote_protocol_handler.inl#L1966
23:26:52 <m-relay> <t​zadiko:matrix.org> I think estimate_backlog in wallet2.cpp has a bug that has gone unnoticed because the range of fees passed in is always the same (e.g. get_backlog({min_fee, min_fee}) instead of get_backlog({min_fee, **max**_fee}).
23:26:52 <m-relay> <t​zadiko:matrix.org> If you take a look, what it does is: For a given range of fees (per byte) determine how many transactions (in terms of weight) pay more than our lower bound, and how many transactions pay more than our higher bound.
23:26:54 <m-relay> <t​zadiko:matrix.org> We'll always have more transactions paying more than our lowerbound than our higherbound, but it sets the lowerbound as the minimum number of blocks we'll need to wait instead of setting it to the maximum number of blocks we'll need to wait.
23:26:56 <m-relay> <t​zadiko:matrix.org> *Example*
23:26:58 <m-relay> <t​zadiko:matrix.org> Say there are 5 transactions in the pool, paying these fee levels per byte: [10, 12, 13, 15, 20] and they each have these weights [2, 3, 2, 2, 4] and the full reward zone weight is 7. When we call estimate_backlog with ({11, 17}), we'll get:
23:27:00 <m-relay> <t​zadiko:matrix.org> ```
23:27:02 <m-relay> <t​zadiko:matrix.org> Lowerbound Fees = 12 + 13 + 15 + 20
23:27:04 <m-relay> <t​zadiko:matrix.org> Lowerbound Weights = 3 + 2 + 2 + 4 = 11
23:27:06 <m-relay> <t​zadiko:matrix.org> Upperbound Fees = 20
23:27:08 <m-relay> <t​zadiko:matrix.org> Upperbound Weights = 4
23:27:10 <m-relay> <t​zadiko:matrix.org> Lowerbound Blocks to Wait = (3 + 2 + 2 + 4) / 7 = 1.57
23:29:32 <m-relay> <t​zadiko:matrix.org> https://matrix.monero.social/_matrix/media/v1/download/matrix.org/jGUAHgMEuYxBfCrdrggszdQv