Use fee estimater for Stacks transactions that makes the distinction between type of transaction

[314159265359879]

I think we are using a one size fits all fee estimation at the moment, right? But STX transfers are much cheaper (resource wise) to include in a block than most contract calls.

The new Hiro dashboard displays three types of transactions and the required fee per priority type: STX transfer, Contract call and Contract deployment. https://explorer.hiro.so/transactions?chain=mainnet

Based on: https://docs.hiro.so/api/get-approximate-fees-for-a-given-transaction and

[314159265359879]

Another question that came up, is why aren't we using fee rates like in Bitcoin fee amount per unit of block capacity (sats/vB) with stacks fees.

I know Stacks blocks have 5 (or 6) dimensions (so instead of vB perhaps it would be read count/read length/write count/write length/runtime and length?) is that what makes it more complex?

Blocks mostly are full because the "read count" limit is reached so if we simplify could we compare fees for Stacks transactions mostly based on uSTX/read count unit?

The stxmempool equivalent of mempool.space (which was live a couple months before Stacks 2.1 launched) did show a uSTX/B metric. https://stxmempools-organization.gitbook.io/stxmempool/homepage-m1/homepage https://github.com/stxmempool/stxmempool it is a shame the site has been down or it could provide valuable insight into the weight specific transactions have in a block.

[314159265359879]

This explains why we need the wallet to set fees based on the transaction being sent: https://github.com/stacks-network/stacks-core/issues/4189#issuecomment-1896745905

That way users will also see STX transfers (with lower fees) compared to contract calls (with higher absolute fees) with more closely related fees relative to eachother. Instead of STX transfers being so much more valuable (100x times more fees compared to contract calls when calculated relative to their block requirements), and miners almost ignore transaction calls because they're in the lowest 5 percentile. Next core-stacks build will also have a fix that will benefit better fee estimates.

[jcnelson]

Another question that came up, is why aren't we using fee rates like in Bitcoin fee amount per unit of block capacity (sats/vB) with stacks fees.

We are. We have six cost dimensions: read_count, read_length, write_count, write_length, runtime, and size.

This explains why we need the wallet to set fees based on the transaction being sent:

This already happens (or should be happening) -- the node exposes a fee estimator endpoint already, which is exactly the same estimator used to assess fee rates in the mempool when picking transactions for block inclusion.

[314159265359879]

Another question that came up, is why aren't we using fee rates like in Bitcoin fee amount per unit of block capacity (sats/vB) with stacks fees.

We are. We have six cost dimensions: read_count, read_length, write_count, write_length, runtime, and size.

This explains why we need the wallet to set fees based on the transaction being sent:

This already happens (or should be happening) -- the node exposes a fee estimator endpoint already, which is exactly the same estimator used to assess fee rates in the mempool when picking transactions for block inclusion.

I know... I am talking about this from the user perspective, how can they set a fee rate instead of an absolute fee (setting an absolute fee without any knowledge of the weight of a transaction is the current default in Leather).

I can't imagine it being user-experience-friendly to show the user 6 dimensions and a fee rate calculation per dimension when they fill one.... although that could work technically.

I think users expect a single unit of measure like a sats/vB what does that look like for STX then? what is that aggregate unit? Could it be the most-significant-dimension for a given transaction (the dimension that fills the highest percentage of the block capacity for example).

The Stacks explorer can help reveal information about the relative "weight" of transactions, read_count, read_length, write_count etc... And the mempool explorer can reveal averages per dimension paid in recent blocks.

[shivaenigma]

We are. We have six cost dimensions: read_count, read_length, write_count, write_length, runtime, and size.

@jcnelson can you give some insight in code on what is the exact formula/algorithm in miner code to decide tx priority using these six dimensions. This will of course help wallets also set the correct fee