[May 2024] Fees are high, wait for opportunity to Consolidate your small inputs

[LoyceV]

Transactions with fees far under 2 sat/byte are getting confirmed, and mempool is nicely clearing up. If you're looking to consolidate funds, this is the time!

[1715500913]

1715500913

[1715500913]

1715500913

[1715500913]

1715500913

[Testnick]

Yesterday (after epoch changed) the tip was at 4sat/b.

Exactly what causes fee to be so low? Pre epoch change it was 350 blocks behind the pace. Now it's running on 98% effectivity. Does the pool release any unfulfilled transactions when epoch changes?
The difficulty until the third block was reduced by 45+% to the current one; increasing/decreasing by insignificant amounts of 0,X%

[nc50lc]

Exactly what causes fee to be so low? Pre epoch change it was 350 blocks behind the pace. Now it's running on 98% effectivity. Does the pool release any unfulfilled transactions when epoch changes?
The difficulty until the third block was reduced by 45+% to the current one; increasing/decreasing by insignificant amounts of 0,X%

You can read Bitcoin articles about "difficulty" and "target", the easiest source is the Bitcoin Wiki: https://en.bitcoin.it/wiki/Difficulty | https://en.bitcoin.it/wiki/Target
Disregard the "pool difficulty" parts since it's talking about pool mining.

Basically, if the total network's hashrate is lower, then in the next "epoch", the difficulty will be lower; vice-versa.
More comprehensive details in the link.

[LoyceV]

Johoe's Bitcoin Mempool Size Statistics:

Based on this, I expect a fee as low as 1.5 sat/byte to confirm within a few blocks. You might even get away with 1.2 sat/byte.

RBF
I was under the impression I could use RBF to increase the fee a tiny bit. Yesterday I made a transaction that took hours to confirm, but when I tried to increase the fee, Electrum told me it's too low. Even using 2.5 sat/byte (which was recommended by the RBF popup) didn't work, and I couldn't broadcast the signed transaction through Coinb.in either.
ChainQuery shows this:

Code:

At a minimum, the new fee rate must be high enough to pay an additional new relay fee (incrementalfee
returned by getnetworkinfo) to enter the node's mempool.

The getnetworkinfo command in Bitcoin Core shows this:

Code:

  "relayfee": 0.00001000,
  "incrementalfee": 0.00001000,

Does that mean the minimum increase is based on a fixed amount instead of an amount per byte? That would mean a 1 sat/byte SegWit transaction (111 bytes, so 111 sat total fee) would have to be increased to 1111 sat (11 sat/byte) instead of just - say - 222 sat (2 sat/byte)?
I hadn't really used RBF yet, but if this is true it's not really useful if your goal is to pay a low fee. Even CPFP would be cheaper in this case.

Mempool is almost empty, it made me announce "June" in the title already.

[TheQuin]

Based on this, I expect a fee as low as 1.5 sat/byte to confirm within a few blocks. You might even get away with 1.2 sat/byte.

When the mempool gets down to the 1-2 Sat range the vast majority are at the very lowest fee. I always check this on btc.com block explorer by looking at the latest block and seeing the fee used on the last transaction included. Yesterday when the first block including <2 was mined it went straight down to 1.5 and within 5 blocks I managed to get 1.2 confirmed. Soon after that all you need to do is use 1.0 / vByte +1 Sat. I got this confirmed a few hours ago 188 vBytes with 189 Sats paid.

[Dabs]

I hadn't really used RBF yet, but if this is true it's not really useful if your goal is to pay a low fee. Even CPFP would be cheaper in this case.

I also don't use RBF all that much. I've seen it recommended in some sites. But from personal experience and probably because I've used bitcoin before RBF as a feature was implemented, I tend to avoid it as well. CPFP would work anyway if you know what you are doing. Sometimes I would just clear the mempool of my own node and either rebroadcast, OR alter the original transaction (effectively a double-spend attempt of the same coin, but higher fee).

Also to note, some sites or exchanges I use will still prefer confirmations anyway so RBF does not matter to them. I guess it only makes sense when the tx fees are higher than 10 or 100 sats / vbyte and you want to bump it up. But again, if the transaction was "urgent" then you'd put in a higher fee from the beginning anyway.

[hosseinimr93]

That would mean a 1 sat/byte SegWit transaction (111 bytes, so 111 sat total fee) would have to be increased to 1111 sat (11 sat/byte) instead of just - say - 222 sat (2 sat/byte)?

Assuming the minimum relay fee is 1 sat/vbyte, you should be able to bump the fee from 1 sat/vbyte to 2 sat/vbyte.

You couldn't bump the fee from 1.5 sat/vbyte to 2.5 sat/vbyte, maybe because the fee you had paid for the original transaction wasn't exactly 1.5 sat/vbyte or the the fee you were going to pay for the second transaction wasn't exactly 2.5 sat/vbyte.
You could probably replace the original transaction with a new one paying a little more than 2.5 sat/vbyte.

I also don't use RBF all that much. I've seen it recommended in some sites. But from personal experience and probably because I've used bitcoin before RBF as a feature was implemented, I tend to avoid it as well. CPFP would work anyway if you know what you are doing.

Sometimes, the best option is RBF.
If your transaction doesn't include any change and you don't have control over any of outputs, there is no way to implement CPFP and the best thing you can do is to enable RBF.

Another disadvantage of CPFP is that, you have to pay for a new transaction too. This makes CPFP more expensive than RBF.

[nc50lc]

-snip-
The getnetworkinfo command in Bitcoin Core shows this:

Code:

  "relayfee": 0.00001000,
  "incrementalfee": 0.00001000,

Does that mean the minimum increase is based on a fixed amount instead of an amount per byte? That would mean a 1 sat/byte SegWit transaction (111 bytes, so 111 sat total fee) would have to be increased to 1111 sat (11 sat/byte) instead of just - say - 222 sat (2 sat/byte)?

They didn't disclose the units in the result of getnetworkinfo but it's in "BTC/virtual kB" on both "relayfee" and "incrementalfee".
That's equal to to additional of +1sat/vB of the original transaction.
When you use the help command for help getnetworkinfo, it'll display the units for those results.

Yours didn't worked maybe because the "absolute fee" is short of a few satoshi to actually reach the minimum of +1sat/B additional fee (like explained by hosseinimr93).
Or if it has an unconfirmed child(ren) transactions, the replacement transaction should be able to pay an additional fee equivalent to the children's "absolute fee" aside from the previous requirement.

[PrimeNumber7]

Also to note, some sites or exchanges I use will still prefer confirmations anyway so RBF does not matter to them.

I can assure you that all businesses prefer that transactions sent to them prefer “confirmations”. A transaction being confirmed means that it is final once a certain number of confirmations are behind the transaction. An unconfirmed transaction carries the risk of a double spend, no matter how low the risk.

The choice between using RBF, or CPFP I no order to raise the transaction fee for a transaction that is unconfirmed is ultimately up to the sender, who pays the fee.

[pooya87]

But again, if the transaction was "urgent" then you'd put in a higher fee from the beginning anyway.

The problem is that you can not predict what is going to happen in bitcoin network (mempool) in the near future while your transaction sits in the mempool waiting to be confirmed. Even in the average 10 minutes that it takes to find the next block the mempool could be filled with a lot of transactions paying higher fee than your "urgent" transaction. So when avoiding RBF in this case you either have to pay outrageously higher fees to avoid such issues or be forced to pay an even higher fee with CPFP since you would be paying high fee for 2 transactions instead of just bumping the fee of 1 tx through RBF.

[Samrita]

You have saved me money. thanks for share my important issue.

[NeuroticFish]

It may worth mentioning that in this very moment the mempool is almost empty, it contains transactions for only 1 block (of course 1-2 more will fill up soon).
This means that it's a great moment for consolidating your inputs.

[LoyceV]

It may worth mentioning that in this very moment the mempool is almost empty

Wow! This last happened 5 months ago, at the start of this year. Title updated

This is a great time to consolidate small inputs, fund LN channels, or even move funds from legacy addresses to native Segwit addresses (for lower fees later on).

[LoyceV]

Still low

[bakasabo]

Yesterday I've made a $200 worth 1sat/byte transaction just for fun and it was confirmed in about 20min.
I remember when identical transaction 4-5 months ago took me almost 5 weeks to get confirmed.
Like LoyceV says - "dont miss that opportunity to consolidating your inputs."

[pooya87]

Judging by the current mempool size, I expect 1 sat/byte to be enough tomorrow.

Yeah. Last night I consolidated 21 inputs (3193 byte/1498 vbyte) for only 1501 satoshi which is ~1 satoshi/vbyte) and it has 7 confirmations now.
Ever since price stabilized the fees have been low, the only reason why we had a small spike recently was because a couple of consecutive blocks took long times to be found (1-2 hours) that led to a fee market competition.

[Pmalek]

There are currently less than 1.100 unconfirmed transactions in the mempool according to https://mempool.space/. That means that even if mempool.space suggests a 4 sat/vByte as minimum fee, a 1 sat/vByte transaction has a good chance to receive next block confirmation considering that some blocks have 2-3k of transactions. Of course that's not a rule, and it all depends on how long we have to wait for the next block. Currently, we are 11 mins without a new block.  

[Poker Player]

A question from a noob:is there any way to know if the mined blocks are above or below average? (in terms of the time it takes to mine, I mean).

I know the blocks are scheduled to be mined every 10 minutes, but on average. I'm looking at 33 minutes now since the last mined block and the previous one was 20 something. With But it could be that the previous ones were mined at intervals of less than 10 minutes and we are simply at the average.

I don't know if I'm making myself clear.

I have been wondering because I see that transactions are being accumulated as they take longer to mine, and I was thinking that if it is taking longer than average to mine, in the future the blocks will have to be mined at shorter intervals and compensate for this.

[pooya87]

I know the blocks are scheduled to be mined every 10 minutes, but on average. I'm looking at 33 minutes now since the last mined block and the previous one was 20 something. With But it could be that the previous ones were mined at intervals of less than 10 minutes and we are simply at the average.

There is no rule saying the average time between blocks must be 10 minutes. What you may be thinking of is the retarget interval which dictates that 2016 blocks must be mined in 2 weeks (1,209,600 seconds) otherwise the difficulty will be adjusted after the 2016 blocks were mined to make it so.

Anything else is based on pure chance. You can start mining and find the required hash on first round (hence find a block after a second) or keep hashing for 1-2 hours and still not find the required hash (hence the longer times like 1-2 hours between blocks).

So most of the times when you see divergence from 10 minutes it is simply by chance and that is not predictable. But sometimes it happens because of hashrate changes. For example if suddenly a big mining pool's servers go down we will see the time increase between the blocks because of the drop in hashrate, conversely if a big hashrate comes online the time decreases (we see more blocks).

[LoyceV]

I was thinking that if it is taking longer than average to mine, in the future the blocks will have to be mined at shorter intervals and compensate for this.

The difficulty changes every 2 weeks (2016 blocks). Other than that, the time it takes to mine a block doesn't influence the time it takes to mine the next block.
For an estimate of the current/expected block time, see diff.cryptothis.com.