Topic: Transaction fee calculation on RPC api (Read 1778 times)
There is no way to (reliably) predict in advance how much of a fee will be needed. The call would be, at best, a guess.
I don't get why there is no rpc call to calculate transaction fee before sending as it exists on the QT, or I am missing something ?
Let say a merchant has to send coins back to a customer, and he does not want to be responsible for the fee. He cannot estimate the optimal fee because it does not exist on the RPC api, he has to assume that it's 0.0005, and substract that from the amount to send the customer, although, such transaction could be eligible for free transfer if sending with the QT, or it could cost more than 0.0005.
Is it just under construction ? Or it is designed this way for some reasons.
Let say a merchant has to send coins back to a customer, and he does not want to be responsible for the fee. He cannot estimate the optimal fee because it does not exist on the RPC api, he has to assume that it's 0.0005, and substract that from the amount to send the customer, although, such transaction could be eligible for free transfer if sending with the QT, or it could cost more than 0.0005.
Is it just under construction ? Or it is designed this way for some reasons.
Jump to: