Noobie question – Transaction fee

I am trying to mimic Bitcoin network inside a game (Minecraft economy server) and I started to do some research about transaction fees. I found out, that price is estimated based on many factors, but pages like []( can estimate it for next block. Is this correct estimation (roughly)? At this moment if I buy/sell **any amount of BTC** I will pay around **~0.15$** on fees if I want transaction to happen in **next block**?

I will most likely use some estimation API endpoint to fetch and use those estimations ingame 🙂 I just want to be sure that I understand it correctly and it is not for example estimation price **per single BTC.**

View Reddit by Key_Ad4335View Source

Leave a Reply

Your email address will not be published. Required fields are marked *

GIPHY App Key not set. Please check settings


  1. The transaction fee depends on the size in bytes of a transaction. It’s slightly more complicated, because not every byte of data is counted equally for this purpose, but it’s close enough.

    Transactions consist of 3 key parts: A fixed bit of boilerplate describing the transaction, one or more inputs that say where the coins are coming from and one or more outputs that say where the coins are going to.

    The most common transaction has 1 input and 2 outputs (the recipient of the transaction and one of your own addresses for the change). Most fee estimators will use this type of transaction to estimate the fee.

    Your actual transaction fee depends very much on your past transaction activity. If you receive 100 transactions of 0.01 BTC, and later want to send them all in a single 1 BTC payment to someone, then your transaction will have 100 inputs, making it relatively large and expensive. If you receive 1 BTC in a single transaction and send it onwards, your transaction will be much cheaper. Same quantity of BTC sent, very different costs.

  2. Fee rate (Satoshis per vbyte) is important. Many years ago, free transactions were possible, and this convenience was abused, so the community implemented a minimum fee rate. The rate had a couple of changes, and then a minor tweak when SegWit created differential weighting for different parts of a transaction

    Here’s a calculator for the vbytes size of a transaction

    A typical person-to-person transaction will spend one input and create two outputs. Nearly everybody uses native SegWit – P2WPKH. The calculator says that’s 140.5 vbytes. In practice, a SegWit 1->2 tx is nearly always 142 or 143. Each extra input increases the size by 68. Each extra output increases the size by 62

    The default minimum fee rate configured in nearly every node is 1 Satoshi per vbyte. The 1->2 SegWit transaction’s minimum fee is 142 Satoshis

    If Bitcoin is uncongested, minimum fee transactions will confirm in 1-2 blocks. There is no “next block” fee rate, and the 1-2 block likelihood is nearly certain, not guaranteed

    If Bitcoin is congested, likely confirmation time depends on “distance from tip”. A full block has 1 million vbytes (approx 2600 transactions). There are mempool charts which sort transactions by fee rate. The next block is likely to contain 1 million vbytes of transactions, highest fee rate first. That is, all the transactions which are within 1 million vbytes of the tip are likely to be mined in the next block

    This chart is a visual representation,24h,weight
    In the more congested periods, you can hover your mouse over the graph to see what the fee rate is near the 1 vMbyte point

    But the mempool is dynamic. If the fee rate at the bottom of the top 1 million vbytes is 5, and you choose a rate of 4, then you’re pushing out some of the 5Sat fee-rate transactions. If some other users send a few hundred 3Sat transactions, they push your transactions more than 1 million vbytes from the tip

    That is, you can sort and view the current mempool transaction set and fee rates, but you can not predict the fee rates of the transactions which are about to enter the mempool after you’ve done your fee estimate

    If you’re not in a hurry, replace-by-fee (RBF) allows the fee rate to be 1 Sat per vbyte, and allows a transaction to be replaced by incrementing the fee rate in increments of 1 or more Sats. Submit the transaction. See how far it is from the tip. Increase the fee rate to 2. Replace the transaction. See how far it is from the tip. Repeat, until the transaction is within 1 million vbytes of the tip

    I wouldn’t use the average fee of the most recent block, because

    * many senders are overpaying due to the use of clumsy fee estimation methods
    * it doesn’t allow for an unpredictable rush of new transactions
    * RBF increments must be a multiple of the original fee rate. The above suggestion to always begin with the minimum fee rate allows for precise adjustment of the replacement fee rate

    If you run your own Bitcoin node, you have your own mempool, for any type of analysis which suits your fee estimation strategy

  3. The process of finding blocks is probabilistic, we expect it to happen approximately every 10 minutes, but every once in a while (say once a month) it’ll take over 2 hours. When this happens, there’s no chance your fee prediction algorithm will work.

    You can use RBF & a mempool monitoring service like to keep a transaction permanently ‘in the next block’ while minimizing overpayment of fees.

  4. Fees are not in dollars and cents, they are in BTC. They are not based on amount sent, but on data size of the transaction. Buying and selling on exchanges is off chain so if you buy/sell you’ll pay no transaction fees. Tx fee is paid by sender only when btc is sent on chain to another (or same) address.

What do you think?

MATIC, ALGO, EGLD & XMR Primed For a Break Out!

XRP Price to Test $1.2 Level !! Will the Altcoin Rise or Crash Below $1 ? – Coinpedia – Fintech & Cryptocurreny News Media

Mid Post Ads

The crypto industry royally screwed up privacy