<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: monero-project/monero #9799#issuecomment-2727050877

tzadiko it's ofrnxmr

but better yet, what is it that you want to do?

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

<o​frnxmr:xmr.mx> 30+hrs?

correct 3 ish hours less (laptop fell asleep) than 1d 9h 12m 27s

<t​zadiko:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/HnzFLFepRxIcIaLYZNdXBRsc

<t​zadiko:matrix.org> What do these magic numbers refer to? (3, 2, 1, 0)?

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

<a​remor:matrix.org> There’s a module called hardforks. Might be in there.

<f​ede:xmr.mx> i think it's there for compatibility, as it could be used by third-party projectsù

<f​ede:xmr.mx> i think it's there for compatibility, as it could be used by third-party projects

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

<r​brunner7:monero.social> old.reddit.com/r/Monero/comments/1c…e_software_wallet_api_will_probably

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

<t​zadiko:matrix.org> monero-project/monero #9838

<t​zadiko:matrix.org> Can someone look at this, please?

jeffro256: monero-project/monero #9758#issuecomment-2727562175

could you take a look here? bug report

<g​ingeropolous:monero.social> im testing sync with the flags

<g​ingeropolous:monero.social> prune-blockchain=true

<g​ingeropolous:monero.social> sync-pruned-blocks=true

<o​frnxmr:xmr.mx> Reproduced

<o​frnxmr:xmr.mx> Same block, same error

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

<t​zadiko:matrix.org> 1. github.com/monero-project/monero/ac…13887134477/job/38853350914?pr=9831

<t​zadiko:matrix.org> 2. github.com/monero-project/monero/ac…13887232626/job/38853579094?pr=9838

<t​zadiko:matrix.org> Any ideas?

<s​yntheticbird:monero.social> Seems to fail at Trezor support

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

<s​yntheticbird:monero.social> `make[1]: *** [CMakeFiles/Makefile2:5267: src/device_trezor/CMakeFiles/obj_device_trezor.dir/all] Error 2`

<s​yntheticbird:monero.social> ```

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

<s​yntheticbird:monero.social> 116 | return MessageMapper::get_message_wire_number(msg->GetDescriptor()->name());

<s​yntheticbird:monero.social> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

<s​yntheticbird:monero.social> ```

<t​zadiko:matrix.org> Thanks, investigating

<s​yntheticbird:monero.social> This PR have the same issue: github.com/monero-project/monero/ac…ns/runs/13883578916/job/38845286332

<t​obtoht:monero.social> It's unrelated to your PR.

<t​obtoht:monero.social> You can ignore it. Will have to fixed in a separate PR.

<t​zadiko:matrix.org> Makes sense, I just looked at the code and I touched nothing near it

<t​zadiko:matrix.org> Thanks

<g​ingeropolous:monero.social> mine fails at a different block: Height: 1788724/3369270

<s​yntheticbird:monero.social> The start of the issue seems to coincide with arch linux update to protobuf 30.0: gitlab.archlinux.org/archlinux/pack…ng/packages/protobuf/-/commits/main

<t​zadiko:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/YlYBnTYsxXCYVQpMHZnNbnZf

<t​zadiko:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/LiHbOeDVPlIsLMpjYODhwHYU

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

<t​obtoht:monero.social> Fixed here: tobtoht/monero a5fabe5

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

<r​ucknium:monero.social> Without double-checking various references, yes that's how the dynamic block size algorithm is supposed to work IIRC.

<t​zadiko:matrix.org> I took a look at the whitepaper and I believe it confirms my understanding as well. Thanks for chiming in

<o​frnxmr:xmr.mx> 1788794 here. Sorry. Indeed, different block

<r​ucknium:monero.social> The cryptonote whitepaper? That's very old. Newer references are _Zero to Monero 2.0_ and _Mastering Monero_.

<t​obtoht:monero.social> ofrnxmr: Is this a gitian build?

<o​frnxmr:xmr.mx> not this current run, no. Maxxor used my gitian build though

<t​obtoht:monero.social> I synced a --prune-blockchain gitian build without issue. Must be sync-pruned-blocks then?

<o​frnxmr:xmr.mx> Its sync-pruned-blocks, yes

<o​frnxmr:xmr.mx> I also synced prune-blockchain w/o issue

<o​frnxmr:xmr.mx> let me check a hyphothesis..

<b​oog900:monero.social> 9135 added a check that rejected any pruned downloaded txs: github.com/monero-project/monero/bl…ryptonote_protocol_handler.inl#L106

<o​frnxmr:xmr.mx> I thought maybe has to do with this monero-project/monero #9404#issuecomment-2679297363

<b​oog900:monero.social> V11 is just when we start asking for pruned blocks

<b​oog900:monero.social> github.com/monero-project/monero/bl…yptonote_protocol_handler.inl#L1966

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

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

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

<t​zadiko:matrix.org> *Example*

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

<t​zadiko:matrix.org> ```

<t​zadiko:matrix.org> Lowerbound Fees = 12 + 13 + 15 + 20

<t​zadiko:matrix.org> Lowerbound Weights = 3 + 2 + 2 + 4 = 11

<t​zadiko:matrix.org> Upperbound Fees = 20

<t​zadiko:matrix.org> Upperbound Weights = 4

<t​zadiko:matrix.org> Lowerbound Blocks to Wait = (3 + 2 + 2 + 4) / 7 = 1.57

<t​zadiko:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/jGUAHgMEuYxBfCrdrggszdQv