There's no other way, you have to simulate what the operation does if you want to estimate this value, and this is exactly what a dry run does. You could try to reimplement it outside of a node, but the approach would be the same.
1. Maximum parameter size per transaction
number of bytes per transaction for a single transaction is limited
several constants, in particular an upper size of for operations
max_operation_data_length and the hard gas limits for operations
and blocks (a block contains a set of operations):
The information is available from the official documentation in the « Baker » section
The basic formula specifies that fees are now dependent on 3 parameters: a fixed minimum fee, a fee by storage unit and a fee by gas unit (reflection the cost of performing calculations). Those 3 parameters are ...
In Tezos, the fee is independant from the gas : whatever the gas consumed, you always pay the full fee.
However, bakers will probably compute the ratio fee/gas, and prefer transactions with higher fee/gas, i.e. more reward for less computation.
The full fee is always paid for every transactions - the gas limit is just that, a cap on the amount of gas a given transaction can consume. A baker can be guaranteed that they are paid at least fee/gas_limit per unit of gas consumed, even if they consume less.
Some bakers will also enforce a minimum per_gas fee, which is currently set to 0.1 mutez (or 1 ...
You also need to take into account the (evaluated) balance of the baker on the tz1 address, which also generates rewards, but which are not stated under the rewards tab. Under the rewards tab, only the KT1 addresses of the delegators are shown. It is not uncommon for a baker to own 40% of the total stake, so I don't think there is anything suspicious here. ...
Docs in tezos.git
Docs by TezTech
To copy from the tezos.git docs:
fees >= (minimal_fees + minimal_nanotez_per_byte * size
+ minimal_nanotez_per_gas_unit * gas)
(size is the size of the operation in binary.)
With current defaults:
minimal_fees = 0.000 1 ꜩ (100 µꜩ)
minimal_nanotez_per_gas_unit = 100 nꜩ/gu (0.000 000 1 ꜩ/gu)
The storage and allocations costs you mentions should rather be referred to as burn as they are not sent to anyone: they are only removed from the account of the sender. They are applied when the size of the blockchain increases. Fees, such as the baker fee, are payed to someone, in this case the baker.
When the size of the context of the blockchain ...
Fees and burns are different, completely separate, things. A fee is paid to the baker, a burn is destroyed.
The 0.257 burn for allocating a new implicit account is, indeed, a burn, representing the storage cost of maintaining an account in the node state indefinitely.
When an operation requires a storage burn, you must indicate in the storage_limit how ...
Do bytes in the contract code cost the same as bytes in the contract storage?
Yes. In both cases the cost is 0.25 tez per kilobyte. These are not fees that go to the baker including the operation, they are simply burnt.
When you transfer out of an address which has never revealed its public key, you must pay a burn to do this reveal operation. This was added back in, IIRC, 004 to prevent new address creation spamming.
If you transfer the entire balance out of a tz1/2/3, then you must again pay the burn fee to "reactivate" the account. The blockchain does a type of ...
You should set all three to 0 in order to accept 0-fee transactions. This will not affect the validity of the blocks you create.
One possible negative repercussion is that your mempool could be spammed with very cheap transactions and the mempool isn't currently as sophisticated as it could be. However, if that happens you could revert to requiring more ...
A baker is free to include whatever operations it wants, as long as they are valid. By default a baker want to create the block that generate the highest amount of fees (most bakers will also have a minimum fee threshold to pass prevalidation). In combinatorial optimization this is described as a knapsack problem. So how the baker choose transactions is ...
When you send a transaction to an empty address you have to pay 0.257 tez allocation fee and in your case that caused a problem:
At the block 930365 your balance was 1.336011 tez.
At the block 930366 you tried to send a transaction with amount 1.1 tez, baker fee 0.015913 tez and allocation fee 0.257 tez - it's 1.372913 tez in total.
As you can see, you ...
Transaction fees are up to the client to offer. While the documentation will say that there is no gas cost (which is technically true), the default baker config comes with a setup that specifies a minimum fee per gas. Any operation that offers less than this is ignored. Operations that offer higher than this will be prioritised.
Its up to each baker to ...
Don't worry, your funds are safe. You need to wait a bit and then try again with a higher fee or lower gas_limit.
Why did that happen?
You sent a transaction with large gas_limit: 50000 (despite a simple tz-to-tz transfer consumes about 1427 gas) and rather small, for such gas limit, fee:10000. So no one baker picked your transaction to include into a block ...
Answering my own question:
'Storage' (the bytes on chain) is burned and isn't related to the fee.
The minimal_nanotez_per_byte refers to the size of the transaction itself when serialized to bytes with a signature.
Which client are you using to send the transaction? In the failing transaction you did not include the origination burn. However it seems that in a subsequent transaction you did include the origination burn and that it worked.
According to the official documentation available here you can get the gas and storage cost of the operation you plan to broadcast to the network by passing the parameter --dry-run to the client node
Quoting the doc it mentions
Another important use of validation is to determine gas and storage
limits. The node first simulates the execution of a ...