Does `calculate-min-fee` give fees too low for interim node?

Staking & Delegation Operate a Stake Pool
1

There are no issues filed on cardano-node about this, so I’m polling the SPO community which I think is most likely to spot changes to the cardano-cli behaviour or syntax, rather than posting on GitHub yet.

Our pool recently took the node upgrade to 8.12.2 which we know removes the Conway genesis & many relevant parameters for the Conway era from the configuration, in anticipation of adding them back in 9.x.

In our only recent use of cardano-cli since the upgrade (actual CLI version = 8.24.0.0), cardano-cli transaction calculate-min-fee has been returning astonishingly lower values: thousands of lovelace lower than needed to accept Tx’s on the chain. (We’ve gotten through this today by estimating fees according to what they were before the upgrade & adding a margin.)

I immediately double-checked that the protocol.json file passed as a parameter was the correct one downloaded for this epoch (the current epoch at the time of this posting).

I did see that some arguments have been dropped from calculate-min-fee — including --tx-in-count and --tx-out-count, which we had always used before — although the results are the same whether or not these deprecated arguments are used.

We’ve had this problem today with 2 types of Tx’s: a transaction that combines some UTxO’s at the same address into a single UTxO while withdrawing stake rewards, and a pool re-registration: both calculating fees too low by thousands of lovelace.

Here’s the command sequence for the first example, giving us (consistently) the unusually & unusably low estimated fee (of 174653 lovelace compared to at least 180K even for 3 inputs without the rewards withdrawal):

cardano-cli transaction build-raw \
--tx-in UTxO1 \
--tx-in UTxO2 \
--tx-in UTxO3 \
--withdrawal $(cat low/stake.addr)+0 \
--tx-out $(cat low/payment.addr)+0 \
--fee 0 \
--out-file balance.test

cardano-cli transaction calculate-min-fee \
--tx-body-file balance.test  \
--witness-count 2 \
--protocol-params-file protocol.json
174653 # output (generally our fees in the 180K to 183K range)

I’ve been following developer & SPO threads through this release and all the node lead said was that “tooling could be affected on 8.12.x”… but by “tooling” I assumed things like pool installation scripts & not the CLI itself. I know if the fee calculations had changed then it would temporarily break things like the SPO scripts: but shouldn’t the raw CLI work the way it always has?

It is not enough for us to wait for node 9.x since most assurances are that we will have almost the same code. Any recommendation to use cardano-cli transaction build cannot be part of this answer because we need to know what has changed about the fee calculation both for our operational standards and a related tooling / documentation project in the works. :pray:

cc @Terminada @HeptaSean @ATADA @Hornan

4 Likes
2

Reported on GitHub at recommendation of @disasm -

1 Like
3

Something about the circumstances… big Tx sizes this time around, plus maybe a small fluctuation in Tx costing parameters in advance of the hard fork, brought on the failure we were seeing above.

Moral of the story, in short: include realistic values when calculating the Tx fee estimates including a generous margin above the fee itself (e.g. 200000 lovelace or more). We had been doing this sometimes & sometimes not, and so were surprised when we got caught with our pants down on this one. :laughing: Thanks to @AndrewWestberg @disasm for helping define the real problem.

https://github.com/IntersectMBO/cardano-cli/issues/827#issuecomment-2214331258

2 Likes
4

So that a simpleton like me properly understands this problem: Is the TLDR; the following?:

  • You recursively run cardano-cli transaction build-raw … and update the transaction details each time until the min-fee calculation doesn’t change anymore?
  • But this will realistically only involve a single re-run plus one more to check the fee didn’t change again, after your update with realistic values?
2 Likes
5

Yes @Terminada, you have the idea… although with the transactions I myself am generally assembling at the command line (no token minting or smart contracts) it’s hard to imagine even a single iteration of the recursion being required: since

  • simply putting actual values for the transaction inputs is guaranteed to calculate accurate byte lengths for those transaction fields;
  • putting a generous figure like 200000 or even 300000 for the yet-unknown transaction fee will likely not use more bytes for the fee field, and will never use less (since the Tx fee will never exceed such a value).

Since I don’t know whether these are bit fields rather than discrete sets of bytes, there could be conditions of overlap in which small changes in fee could make whole-byte differences… but if all values are the same or in excess of the actual transaction figures, then I don’t see how iteration would ever be required: just a valid first approximation.

1 Like
7

See this response from Sam Leathers

disassembler commented yesterday

The issue is the 0 values for fee and withdrawal. When those are updated to the actual values it increases the size of the transaction, thereby increasing the min fee for the transaction to submit. calculate-min-fee needs to be ran recursively on fee changes because an increase in the fee might increase the tx size by one or more bytes.

1 Like