It's possible to do it by referencing outputs by pubkey, but you increase the likelihood of privacy leaks on reorg, and if you do this on unmined outputs, you remove the protection from ring sigs.

reminder: tomorrow at the meeting I'd like to discuss discretizing fees (see github.com/Mitchellpkt/fees_data_and_design and youtube.com/watch?v=XIrqyxU3k5Q from isthmus for background)

I am trying to understand how the official wallet determines fees. Bitcoin has the `estimatesmartfee` in `bitcoind` RPC, which returns what it thinks the fee should be in order for the tx to be confirmed in X blocks. (Allegedly it estimates the target fee poorly.) The estimate is based on the fees in recent blocks and the contents of the mempool.

Monero has `get_fee_estimate`. And there is an option in the wallet to select several multiples of the base fee.

Is it the case that the fee that the official wallet chooses will be some sort of multiple of the dynamic block size formula, which is baked into consensus?

The explanation is in the commit message adding it IIRC. The recent change links to a PDF file with the change spec.

I'd git blame blockchain.cpp, find the fee calc, check the earliest commit it yields.

Rucknium[m]: github.com/monero-project/monero/bl…cfec5e/src/wallet/wallet2.cpp#L7235

Thank you.

but yes, the general process is: 1) calculate the minimum fee from blockchain data, 2) estimate the tx weight (~size), 3) calculate minimum tx fee as min_fee * tx_weight, 3) add multipliers to represent different 'urgency' feelings.

err that's 4)

with seraphis I'm hoping to do away with estimates and calculate everything precisely

So in a sense fees are already discretized by wallet2. For a given block height and a given tx size, fees will be one of 4 possible user-selected levels. wallet2 does not allow the "fee sniping" that isthmus described in his talk, in which tx fee can be raised a few percent above the "herd" of transactions.

It's easy to recompile wallet2 with 1.01 fee multiplier

You'd be surprised. Even a computer takes *minutes* to do it. It's crazy hard.

Rucknium[m]: yes, but only at a single moment in time, since the minimum fee is dependent on blockchain state (notice the downward trend in isthmus's plots as chain state constantly changes min fee)

the down-trend is due to declining block rewards

min fee will stop declining soon

we don't see any 'waviness' to the trend because block sizes have stayed under the dynamic-load-level so far

If Monero's mempool gets really full, then `get_fee_estimate` will not move until the dynamic block size formula starts to change block size. So users would have to bump up fee priority manually, in quite discrete jumps. Correct?

correct

The fee multiplier default is x4 or x5 IIRC, and the wallet will auto decrease it to x1 if there is no (or little) txpool pressure. The user can elect to not have this auto decrease.

It would be really cool to have a fee estimator that can help the wallet bid on block space by taking into account recent txs and txs in the txpool.

Thank you.

That's quite a large project to get working though ^

help it bid with more granularity than the fee priority levels *

No, wallet bumps the fee automatically when mempool is full

the key UX is being able to match 'acceptable delays' with tx fees

it even says "there's N blocks backlog" when you try to send a transaction

at least the CLI wallet

see wallet2::adjust_priority function

and simple_wallet::print_fee_info

The problem is users can get a fee advantage by hacking wallet2. The fee estimator should be good enough that hacking it is basically pointless. (setting aside the fact current fees are minuscule)

<UkoeHB> "It would be really cool to..." <- Right. In theory I'm in a good position to put research time such a fee estimator (perhaps building on research like this: academic.oup.com/restud/article/88/6/3011/6169547 ). Fee discretization at the consensus level makes it a more interesting problem -- and probably more difficult, but not too difficult.

In particular we would want to avoid a "fee bubble" situation that sudden upward jumps could cause.

I think fee bubbles can be mitigated to some extent, but not completely avoided. A cohort of users very determined to get their txs in quickly WILL cause a bubble unless your algorithm increases fee estimates very aggressively (there is a difficult UX tradeoff between killing bubbles and encouraging users to pay uselessly high fees).

If users start distrusting recommended fees, that is not a good outcome lol