Need a free api to calculate transaction FEE for instant confirmation

[Vort3x.Layers]

I am c# developer.
I need a free api to calculate transaction FEE (BITCOIN) for instant confirmation.
Mean i want to pass amount to api and it show me transaction FEE for instant confirmation.
Because in these days i saw many troubles for high fees during transactions.
So i need to know about fees in my codes.

Thanks for the review and for the help

[1714693571]

1714693571

[1714693571]

1714693571

[1714693571]

1714693571

[ranochigo]

Paying a high fee rate will.not give you an instant confirmation but it would improve your chances of the transaction getting confirmed within the next few blocks.

Can the mempool.space API[1] help with this? It'll give you a pretty reasonable estimate for Satoshis/vbyte.

[1] https://mempool.space/api

[Vort3x.Layers]

Thanks for the reply.
It seems satoshi / vbyte is different from satoshi / byte.
This Link returns satoshi / vbyte.
Where can i know 100$ = 0.0019 btc how much is that in byte or vbyte?

[ranochigo]

Thanks for the reply.
It seems satoshi / vbyte is different from satoshi / byte.
This Link returns satoshi / vbyte.
Where can i know 100$ = 0.0019 btc how much is that in byte or vbyte?

Transaction size are independent of the amount being transacted. It'll depend on your number of inputs and outputs, type of transaction (Segwit or not), etc There should be some utility In C# which is able to interpret the witness discount for the virtual byte. You shouldn't consider actual size as that is not what most of the miners consider when choosing transactions.

There are various formulae available for the calculation, which gives a very close approximation and is not always perfectly accurate. Use this web utility as a guide: https://jlopp.github.io/bitcoin-transaction-size-calculator/.

[NotATether]

Where can i know 100$ = 0.0019 btc how much is that in byte or vbyte?

byte-denominated fees don't count the witness data part of the transaction properly so are half as large as vbytes fees are for segwit transactions. This is understandable because it was made before segwit was introduced.

Sats/vbyte is the canonical way to calculate fees for legacy and segwit addresses now so that's what you should use instead of sats/byte.

[bitmover]

Thanks for the reply.
It seems satoshi / vbyte is different from satoshi / byte.
This Link returns satoshi / vbyte.

As mentioned by NotATether you should use vbytes, as block size is now measured in vbytes and not in bytes anymore.

Take a look at bitcoin wiki:

Weight units
Weight units are a measurement used to compare the size of different Bitcoin transactions to each other in proportion to the consensus-enforced maximum block size limit. Weight units are also used to measure the size of other block chain data, such as block headers. As of Bitcoin Core 0.13.0 (released August 2016)[1], each weight unit represents 1/4,000,000th of the maximum size of a block.

Virtual size (vsize), also called virtual bytes (vbytes), are an alternative measurement, with one vbyte being equal to four weight units. That means the maximum block size measured in vsize is 1 million vbytes.

https://en.bitcoin.it/wiki/Weight_units

Where can i know 100$ = 0.0019 btc how much is that in byte or vbyte?

Transaction size (bytes/vbytes) depends on how many inputs/outputs you have and address format, not in the amount being transacted.

[nellcisneros]

Blockchain.info offers a fee API: https://api.blockchain.info/mempool/fees You'll need to multiply either the value for regular or priority by your transaction size in order to calculate the transaction fee.

essaytyper.pro

[mocacinno]

or, you can run a node and use "estimatesmartfee" via the json-rpc interface... That way you don't have to trust some other service..

But like it's been said before: there is no foolproof method, and no "instant" confirmation...

[jack jillss]

how do we calcualte the other coins fees (ex- eth , bsc , sol blockchain for instant confirmation)

[Dabs]

https://jochen-hoenicke.de/queue/#BTC,2h,weight
https://mempool.observer/
https://bitcoinfees.net/

I'd use one of these, or all of them, in addition to your own full node as a sanity check.

The almost sure fire way is to pay the fee where the tx is within 1 MB from the tip. Your transaction will get included in the next one or two blocks.

[Pmalek]

The almost sure fire way is to pay the fee where the tx is within 1 MB from the tip. Your transaction will get included in the next one or two blocks.

That should be enough unless you are really unlucky and you send a low-fee transaction at a time where we have to wait for 30-40 minutes for the next block, while in the meantime a huge influx of new higher-paying transaction enters the mempools. Not to mention a sudden price surge or drop of value and the congestions they usually bring to the table.   

[ranochigo]

That should be enough unless you are really unlucky and you send a low-fee transaction at a time where we have to wait for 30-40 minutes for the next block, while in the meantime a huge influx of new higher-paying transaction enters the mempools. Not to mention a sudden price surge or drop of value and the congestions they usually bring to the table.   

It only works assuming that the both the blocks and the rate of transactions are approximately constant. Most fees estimation takes into the fee rates for the previous blocks and use the data points to build out their own fee estimation. This is by far the most accurate way to eliminate volatility of the block intervals as it takes into account a much larger history. If the block were to be mined 10 seconds before and you choose a 1vMB from tip, it would at the very least take 2 blocks to confirm or perhaps even longer.

If you think estimatesmartfees has too conservative of an estimate, then you can change the parameters if you're using Bitcoin Core for a more economical one. While it is by no means perfect, it is a far better estimation than what we can do by looking at the mempool distribution.