The question as stated confuses different things.
A "reveal" operation is an operation that writes on the chain the public key associated with a public key hash for an implicit account. The fee associated with this operation is up for the sender to decide, though most bakers implement default minimum fees (in this case it is currently 1267µꜩ).
The creation ...
The best solution is to apply the minimum payout rule. So, you will pay the delegator only when this value is reached.
For example, let MinPayout = 0.01, then:
Cycle Reward Debt Payout
#n 0.004 0.004 ---
#n+1 0.004 0.008 ---
#n+2 0.004 0.012 0.012
That's it =)
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 ...
The fee computation follows the formula.
The only subtle thing here is that the fee itself can affect the size of the operation in binary. This usually doesn't matter, but to handle the general case, the client currently loops:
Start with the draft op with fee set to zero (with its gas_limit and storage_limit chosen appropriately).
Measure the op size in ...
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 ...
Choosing the order in which operations are applied is a privilege of the baker. So yes, frontrunning is possible on Tezos and can either be done by setting high fees (the default baker strategy is to apply transactions with high fees first) or by the bakers themselves when they build their blocks. The simplest protection against frontrunning is to run your ...
The fee for adding a new account to the global state (--burn-cap with tezos-client) is 0.257 XTZ.
The origination burn is calculated as Tez_repr.(cost_per_byte *? (Int64.of_int origination_size)).
cost_per_byte is 0.001 XTZ. It is 1000 mutez and 1,000,000 mutez == 1 tez.
origination_size is 257.
Due to that the resulting cost for an origination of a ...
Here is a short description of how operations can affect balance:
Transaction - transfer | fee
Revelation - fee
Origination - transfer | fee
Delegation - fee
Endorsement - reward
Seed_nonce_revelation - reward
Double_endorsement_evidence - reward | loss
Double_baking_evidence - reward | loss
Activate_account - income
Proposals - doesn't affect
Ballot - ...
In Tezos, gas does not have a monetary translation. It does not "cost" you anything to execute a contract with 10 gas vs 1M gas. Gas is simply an internal limitation to prevent contracts from running amok.
After asking, there is no equivalent of a gas price in Tezos. You pay a transaction fee, and this fee should include everything. Doing some stats on the fees you may get an upper-bound on the gas price.
You can use any signature in place of that parameter. For example, you can use edsigtXomBKi5CTRf5cjATJWSyaRvhfYNHqSUGrn4SdbYRcGwQrUGjzEfQDTuqHhuA8b2d8NarZjz8TRf65WkpQmo423BtomS8Q and it should return the RPC call.
To simplify the calculations, we advise you to use the program for the automatic distribution of awards. It reads and pays for any amount delegated to you
If you have any questions, you can contact me, I will try to help you.
The best way to estimate it is to use the CLI like you've done. Otherwise, you need to know the contract's high water mark (the most storage it ever held), the current size of its storage, whether the operation will increase the storage beyond the high water mark and if so by how much.
However, I note that in your screenshot you are transferring from a tz1 ...