How to calculate exact Monero transaction fee?

Question

I assume that transaction fee is deducted from the transaction amount, i.e. if Alice sends Bob 10 XMR, then Bob will receive (10 - tx_fee) ~ 9.x XMR

I don't know how precise https://www.monero.how/monero-transaction-fee-calculator is, but from looking at it and API docs it seems that a to calculate transaction cost I will need to multiply result of the get_fee_estimate Wallet RPC call to the transaction size.

As far as I understand in order to do that I will need:

• base transaction size
• number of inputs and size overhead in kb per each input
• number of outputs and size overhead in kb per each input
• number of rings and size overhead in kb per each ring
• dynamic fee per kb

as a bare minimum. There is also a 13 kb boundary(whatever that means) and maybe other variables in that equation. Then, if my assumption is correct, it will not be a final amount because, tx + tx_fee essentials means new transaction, for which a bigger fee will be applied.

Can somebody please help to figure out:

• What exactly is needed to calculate transaction fee and how to obtain that data (preferably via Daemon/Wallet RPC calls)
• How to calculate transaction fee?
• How to get as close as possible to the exact final amount, i.e. being able to answer how much Alice should transfer to the Bob so Bob gets N XMR? Three digits after decimal point accuracy will be good and five will be perfect!

This question arose out of real need and not curiosity so I will really appreciate if answers will be as practical as possible.

Answer 1

The fee calculator that you have linked gives you the exact formula, with one exception. Every transaction contains a list of "vins", meaning a list of varint offsets that reference the inputs used in the ring signature.

Depending on the spacing of the inputs that are randomly chosen as ring decoys, the length of the vin list will vary a little.

In practice though, this won't matter, because of the "KB boundary". In Monero, the size of a transaction is rounded up to the nearest KB. The fee then applies to the rounded up KB amount. Therefore a little bit of uncertainty about the vin list will mostly not affect the final fee, since you'd have to be unlucky to find that the variation in transaction size will leave you just over or just under the KB boundary.