01:23:19 ah bloody hell. my seed node is acting funny 01:23:47 src/common/stack_trace.cpp:133 Exception: std::bad_alloc 01:24:05 Arch linux user spotted 01:25:16 lulz wish i was that l33t. ubuntu 01:26:25 well lets see if running master can fix it 01:32:17 i just gotta move to the new box. this thing is bleh 03:52:08 <3​21bob321:monero.social> Wearing the T-shirt ? 04:32:54 damn, this things in a restart loop even on maser 04:32:57 master 07:53:36 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/rACwPBUmpySyWbQLFKAMWhZJ 07:53:41 Hey, is one of the values formatted or labeled incorrectly? 11:30:39 in that case, the monerod documentation is wrong when it says [slow, normal, fast, fastest], because it should be [default, slow, normal, fast] 11:33:05 but I'm not sure that's right, because the code is returning exactly 4x the amount of index 0 in index 1: https://github.com/monero-project/monero/blob/84df77404e8bcbe1cf409f64c81e4e4f9c84885b/src/cryptonote_core/blockchain.cpp#L3699 11:43:05 1-4 is mapped to 0-3 aiui 11:47:40 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 11:54:13 https://github.com/monero-project/monero/blob/7536c52cf283294dc399e636e1bc57f783b38bf9/src/wallet/wallet2.cpp#L8540 12:12:44 s/1-2/1-4 12:13:23 Nvm ignore the last (substitution) msg ^ 12:19:11 gingeropolous: std::bad_alloc shows on all self compiled nodes with stack_trace enabled 13:28:34 hrm, gettin that bad weak ptr thing 13:28:54 mebbe i'll try release bins 13:30:05 -xmr-pr- tobtoht opened pull request #9784: ci: containerize depends jobs 13:30:05 -xmr-pr- > https://github.com/monero-project/monero/pull/9784 13:48:44 gingeropolous: both bad_allow and bad_weak_ptr can show up with stack_trace 13:48:49 *alloc 13:48:53 ah 13:49:13 the "monerod is disconnected" issue has to be investigated, does it also show up with v0.18.3.4 release binaries? 13:50:08 from my rough recollection, i really only see it when im testing a sync using --add-exclusive-node. 13:50:27 damn, my seed node is still restarting constantly even on release bins 13:51:49 i'll try the 9135 without exclusive node, see if i see the disconnect 13:54:43 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 13:59:42 ok if you sync from a single exclusive node it makes sense that you sometimes get this message 14:07:01 Monerod is disconencted happens often if you use exclusive node, as the node you connect to might drop you (i think) 14:07:35 Exclusive node has no bearing on incoming connections 14:17:28 I observe through testing that the mappings from `transfer` priority to `get_fee_estimate` indices are unimportant=0, normal=1, elevated=2. 14:17:30 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? 14:17:32 that's a problem because it means a "default" fee cannot be estimated ahead of time to sanity check the mining fee. 14:17:34 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. 14:17:36 any help or advice would be appreciated 14:20:45 Default fee checks from the node 14:21:44 https://github.com/monero-project/monero/blob/7536c52cf283294dc399e636e1bc57f783b38bf9/src/wallet/wallet2.cpp#L8635 14:31:20 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 14:32:28 there's *no equivalent fixed index from `get_fee_estimate` 14:43:40 You dont need get fee estimate 14:44:15 also, i just submit tx with do_not_relay if i need fee estimate 14:45:10 Returns the exact fee for the tx 14:50:35 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 14:51:38 e.g. to ensure that their penalty tx has an appropriate mining fee and can be broadcast if needed 14:51:39 Its correct for default fee if you passed default priority to rpc 14:51:57 but a peer may change their code to unimportant instead, for example 14:52:53 So set the penalty fee higher by default? 14:53:47 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 14:53:59 Default cant be guaranteed to have the appropriate mining fee, because the txpool and block saturation can change before the penalty is taken(?) 14:54:15 it's at least a starting point that everyone is playing by the rules 14:54:29 otherwise there's no guarantee a malicious user has not set a custom tiny fee 14:54:45 You can't set the fee below low 14:55:12 actually, yes you can if you modify the code 14:55:17 yes 14:56:42 So why not just check that its one of the 4 tiers? (dont have to check auto, just check low, normal, med, high) 14:57:27 it allows users to modify their software to always use unimportant 14:57:59 Which isnt really a major issue 14:58:31 if there's congestion, then it can create an issue getting the peer funds into the multisig wallet 14:58:49 If the pool is big for an extended period of time, other users will be using normal and blocksizes will grow 14:58:54 all of this is a hack because `get_fee_estimate` doesn't allow `default` to be determined 15:07:30 the wallet2 sets the fee tho, not the daemon 15:07:55 get_fee_estimate is a monerod rpc call 15:08:56 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 15:11:05 Only way for arbitrator to know the fee based on congestion is to use wallet-rpc.. afaik 15:13:14 (since the logic is built into the wallet, not the node) 15:40:32 opened an issue for `get_fee_estimate` to return a fee corresponding to default priority: https://github.com/monero-project/monero/issues/9785 15:40:54 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 15:42:55 How would it calculate the wallets fees? They are decided based on wallet2 15:43:15 Just make sure the fee per byte matches one of the tiers 15:45:05 -xmr-pr- woodser opened issue #9785: Default priority has no mapping in get_fee_estimate 15:45:05 -xmr-pr- > https://github.com/monero-project/monero/issues/9785 15:47:04 wallet2 is making calls to monerod to adjust the priority, so I'm assuming the daemon can calculate the same default fee 15:48:05 Adding the same logic to monerod (but only for the rpc call?) 15:49:12 yes. seems the ideal implementation should be to have monero-wallet-rpc making a single call to monerod to get the default fee 15:49:22 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 15:50:15 yes, all of that logic could be moved to monerod for equivalent functionality iiuc 15:50:34 rather than computing it client side 15:50:41 by making multiple calls to monerod 15:50:43 i guess malicious nodes already control the fee rate. Probably doesnt hurt for them to also do the fee math 15:54:47 moneromooo might know more about the reasoning for it to have be split between wallet and daemon in the first place 15:58:22 * moneromooo feels notified - For what to be split ? 16:00:07 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 ? 16:00:16 The fee tiers are returned from the daemon, but how they are used is set in wallet2 16:00:51 Woodser wants to move the default priority maths to the daemon 16:01:01 Default/auto 16:01:08 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, 16:01:43 I see no issue with having the daemon do it. 16:01:51 well what I really need is for get_fee_estimate to return an estimate which is the same as `default` used by the wallet 16:02:09 but I figure it would make sense for the daemon to do all the calculation, and then the wallet can just use that 16:02:50 i think the idea od moving the auto fee calc to the daemon is sane, since the daemon decides on the per byte already 16:03:36 Why do you need the daemon to do it out of curiosity ? You don't use wallet2 ? 16:06:12 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 16:07:31 Oh right, it's java, so no wallet2. Fair enough. 16:08:43 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 16:14:00 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 16:23:15 I dunno how it works, but if you get those 4, comparing to see if one of them "works" is not enough ? 16:28:02 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 16:28:26 but checking one of the 4 returned values is the best hack I can use now 17:58:37 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 17:58:40 that would solve my problem 17:58:54 it would use the same code currently used by wallet2 18:00:05 -xmr-pr- dbee01 opened issue #9786: Does Simplewallet support QR codes? 18:00:05 -xmr-pr- > https://github.com/monero-project/monero/issues/9786 18:02:24 0-3, though at this time default only uses 0-1 21:15:05 -xmr-pr- woodser opened pull request #9788: add wallet rpc call to get default fee priority [RELEASE] 21:15:05 -xmr-pr- > https://github.com/monero-project/monero/pull/9788 21:15:05 -xmr-pr- woodser opened pull request #9787: add wallet rpc call to get default fee priority 21:15:05 -xmr-pr- > https://github.com/monero-project/monero/pull/9787 22:42:18 d 22:42:32 miss input sry 23:30:05 -xmr-pr- tendermonster opened issue #9789: Unable to sync after pruning: E internal error: passed start_height no... 23:30:05 -xmr-pr- > https://github.com/monero-project/monero/issues/9789