ah bloody hell. my seed node is acting funny

src/common/stack_trace.cpp:133 Exception: std::bad_alloc

<s​yntheticbird:monero.social> Arch linux user spotted

lulz wish i was that l33t. ubuntu

well lets see if running master can fix it

i just gotta move to the new box. this thing is bleh

<3​21bob321:monero.social> Wearing the T-shirt ?

damn, this things in a restart loop even on maser

master

<m​onerooo:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/rACwPBUmpySyWbQLFKAMWhZJ

<m​onerooo:matrix.org> Hey, is one of the values formatted or labeled incorrectly?

<w​oodser:monero.social> in that case, the monerod documentation is wrong when it says [slow, normal, fast, fastest], because it should be [default, slow, normal, fast]

<w​oodser:monero.social> but I'm not sure that's right, because the code is returning exactly 4x the amount of index 0 in index 1: github.com/monero-project/monero/bl…ryptonote_core/blockchain.cpp#L3699

1-4 is mapped to 0-3 aiui

Fl=low=1, Fn=normal=2, Fm=medium=3, Fh=high=5. 0 is mapped to 1-2, then 1-4 are mapped to 0-3.. iiuc

s/1-2/1-4

Nvm ignore the last (substitution) msg ^

gingeropolous: std::bad_alloc shows on all self compiled nodes with stack_trace enabled

hrm, gettin that bad weak ptr thing

mebbe i'll try release bins

gingeropolous: both bad_allow and bad_weak_ptr can show up with stack_trace

*alloc

ah

the "monerod is disconnected" issue has to be investigated, does it also show up with v0.18.3.4 release binaries?

from my rough recollection, i really only see it when im testing a sync using --add-exclusive-node.

damn, my seed node is still restarting constantly even on release bins

i'll try the 9135 without exclusive node, see if i see the disconnect

it could also be the main node disconnecting the syncing node. perhaps the main node has a cnxn limit or is otherwise disconnecting the syncing node

ok if you sync from a single exclusive node it makes sense that you sometimes get this message

<o​frnxmr:xmr.mx> Monerod is disconencted happens often if you use exclusive node, as the node you connect to might drop you (i think)

<o​frnxmr:xmr.mx> Exclusive node has no bearing on incoming connections

<w​oodser:monero.social> I observe through testing that the mappings from `transfer` priority to `get_fee_estimate` indices are unimportant=0, normal=1, elevated=2.

<w​oodser:monero.social> so it seems there may not actually be any mapping from "default" priority to a fixed index within `get_fee_estimate`, because the "default" priority is automatically adjusted in wallet2, and there's no equivalent in `get_fee_estimate` afaict?

<w​oodser:monero.social> that's a problem because it means a "default" fee cannot be estimated ahead of time to sanity check the mining fee.

<w​oodser:monero.social> I'm observing that "default" tx priority is mapping to fee estimate index 0 in my tests, but that may just be based on congestion (or lack thereof) on my local private testnet.

<w​oodser:monero.social> any help or advice would be appreciated

<o​frnxmr:xmr.mx> Default fee checks from the node

<o​frnxmr:xmr.mx> github.com/monero-project/monero/bl…b38bf9/src/wallet/wallet2.cpp#L8635

<w​oodser:monero.social> yeah it checks the node for congestion and adjusts the priority if necessary. but there's equivalent fixed index in the response from `get_fee_estimate` which does the same, so one cannot programmatically estimate the "default" fee iiuc

<w​oodser:monero.social> there's *no equivalent fixed index from `get_fee_estimate`

<o​frnxmr:xmr.mx> You dont need get fee estimate

<o​frnxmr:xmr.mx> also, i just submit tx with do_not_relay if i need fee estimate

<o​frnxmr:xmr.mx> Returns the exact fee for the tx

<w​oodser:monero.social> that will return the fee used in a tx, but not necessarily that the fee is *correct* for default priority. this is for the arbitrator to verify that a pre-constructed transaction from the peer has an appropriate mining fee

<w​oodser:monero.social> e.g. to ensure that their penalty tx has an appropriate mining fee and can be broadcast if needed

<o​frnxmr:xmr.mx> Its correct for default fee if you passed default priority to rpc

<w​oodser:monero.social> but a peer may change their code to unimportant instead, for example

<o​frnxmr:xmr.mx> So set the penalty fee higher by default?

<w​oodser:monero.social> that's ineffective if the peer has provided a transaction with artificially low mining fee (they could have even modified the code to reduce the fee more), and then it can't be mined

<o​frnxmr:xmr.mx> Default cant be guaranteed to have the appropriate mining fee, because the txpool and block saturation can change before the penalty is taken(?)

<w​oodser:monero.social> it's at least a starting point that everyone is playing by the rules

<w​oodser:monero.social> otherwise there's no guarantee a malicious user has not set a custom tiny fee

<o​frnxmr:xmr.mx> You can't set the fee below low

<o​frnxmr:xmr.mx> actually, yes you can if you modify the code

<w​oodser:monero.social> yes

<o​frnxmr:xmr.mx> So why not just check that its one of the 4 tiers? (dont have to check auto, just check low, normal, med, high)

<w​oodser:monero.social> it allows users to modify their software to always use unimportant

<o​frnxmr:xmr.mx> Which isnt really a major issue

<w​oodser:monero.social> if there's congestion, then it can create an issue getting the peer funds into the multisig wallet

<o​frnxmr:xmr.mx> If the pool is big for an extended period of time, other users will be using normal and blocksizes will grow

<w​oodser:monero.social> all of this is a hack because `get_fee_estimate` doesn't allow `default` to be determined

<o​frnxmr:xmr.mx> the wallet2 sets the fee tho, not the daemon

<o​frnxmr:xmr.mx> get_fee_estimate is a monerod rpc call

<w​oodser:monero.social> yeah this is for the arbitrator to verify the mining fee which the peer used when they created the tx. so the arbitrator is calling get_fee_estimate to compare the expected fee vs actual

<o​frnxmr:xmr.mx> Only way for arbitrator to know the fee based on congestion is to use wallet-rpc.. afaik

<o​frnxmr:xmr.mx> (since the logic is built into the wallet, not the node)

<w​oodser:monero.social> opened an issue for `get_fee_estimate` to return a fee corresponding to default priority: monero-project/monero #9785

<w​oodser:monero.social> and in the meantime need to find the best way to hack this, probably just ensure the peer's fee used at least `unimportant` within some margin of tolerance

<o​frnxmr:xmr.mx> How would it calculate the wallets fees? They are decided based on wallet2

<o​frnxmr:xmr.mx> Just make sure the fee per byte matches one of the tiers

<w​oodser:monero.social> wallet2 is making calls to monerod to adjust the priority, so I'm assuming the daemon can calculate the same default fee

<o​frnxmr:xmr.mx> Adding the same logic to monerod (but only for the rpc call?)

<w​oodser:monero.social> yes. seems the ideal implementation should be to have monero-wallet-rpc making a single call to monerod to get the default fee

<o​frnxmr:xmr.mx> Its making cells to monerod to check the txpool size (which might not be consistent among nodes), and the saturation of the past 10 blocks

<w​oodser:monero.social> yes, all of that logic could be moved to monerod for equivalent functionality iiuc

<w​oodser:monero.social> rather than computing it client side

<w​oodser:monero.social> by making multiple calls to monerod

<o​frnxmr:xmr.mx> i guess malicious nodes already control the fee rate. Probably doesnt hurt for them to also do the fee math

<o​frnxmr:xmr.mx> moneromooo might know more about the reasoning for it to have be split between wallet and daemon in the first place

Seems to be fee per byte and priority ? The daemon cares about fee/byte (soft rejected if too low), but not about priority levels. Was that the question ?

<o​frnxmr:xmr.mx> The fee tiers are returned from the daemon, but how they are used is set in wallet2

<o​frnxmr:xmr.mx> Woodser wants to move the default priority maths to the daemon

<o​frnxmr:xmr.mx> Default/auto

Ah, right, the tiers are in the node now. IIRC this is because the new calc from ArticMine required access to more data that the wallet did not have,

I see no issue with having the daemon do it.

<w​oodser:monero.social> well what I really need is for get_fee_estimate to return an estimate which is the same as `default` used by the wallet

<w​oodser:monero.social> but I figure it would make sense for the daemon to do all the calculation, and then the wallet can just use that

<o​frnxmr:xmr.mx> i think the idea od moving the auto fee calc to the daemon is sane, since the daemon decides on the per byte already

Why do you need the daemon to do it out of curiosity ? You don't use wallet2 ?

<w​oodser:monero.social> in our case, the arbitrator is verifying the fee of a peer's transaction, to ensure they used an appropriate fee, for example to check that a penalty transaction can be broadcast if they misbehave

Oh right, it's java, so no wallet2. Fair enough.

<w​oodser:monero.social> peers are using wallet2 to generate the transaction (via monero-wallet-rpc, via java), and arbitrators are verifying the fee by getting the fee estimate from the node

<w​oodser:monero.social> but there's no way for the arbitrator to get a fee estimate corresponding to the "default" priority level. only values returned are for unimportant, normal, elevated, and ..super elevated

I dunno how it works, but if you get those 4, comparing to see if one of them "works" is not enough ?

<w​oodser:monero.social> it just means that peers could hack their software to always use unimportant priority, and it'd pass the arbitrator's check, which could be a problem in times of congestion, to reliably lock the funds in multisig

<w​oodser:monero.social> but checking one of the 4 returned values is the best hack I can use now

<w​oodser:monero.social> another idea is to simply add a new call to monero-wallet-rpc, e.g. get_default_fee_priority() which returns 0-2 for unimportant, normal, elevated

<w​oodser:monero.social> that would solve my problem

<w​oodser:monero.social> it would use the same code currently used by wallet2

<o​frnxmr:xmr.mx> 0-3, though at this time default only uses 0-1

d

miss input sry