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."
Topic: [Aug 2022] Mempool empty! Use this opportunity to Consolidate your small inputs! - page 43. (Read 88546 times)
June 09, 2021, 03:01:34 AM
June 08, 2021, 02:27:26 AM
Still low 
June 02, 2021, 05:24:00 AM
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).
June 02, 2021, 05:05:37 AM
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.
This means that it's a great moment for consolidating your inputs.
June 01, 2021, 02:52:08 AM
You have saved me money. thanks for share my important issue.
May 31, 2021, 10:00:43 PM
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. May 31, 2021, 09:26:09 PM
Also to note, some sites or exchanges I use will still prefer confirmations anyway so RBF does not matter to them.
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.
May 31, 2021, 09:21:43 PM
-snip-
The getnetworkinfo command in Bitcoin Core shows this:
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".The getnetworkinfo command in Bitcoin Core shows this:
Code:
"relayfee": 0.00001000,
"incrementalfee": 0.00001000,
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.
May 31, 2021, 01:03:06 PM
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.
May 31, 2021, 06:29:32 AM
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.
May 31, 2021, 03:40:54 AM
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.
May 31, 2021, 03:16:07 AM
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:
The getnetworkinfo command in Bitcoin Core shows this:
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.
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.
Code:
"relayfee": 0.00001000,
"incrementalfee": 0.00001000,
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.
May 30, 2021, 10:16:42 PM
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/TargetThe difficulty until the third block was reduced by 45+% to the current one; increasing/decreasing by insignificant amounts of 0,X%
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.
May 30, 2021, 08:38:11 PM
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%
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%
May 30, 2021, 06:27:34 AM
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!
May 29, 2021, 12:17:23 AM
-snip-
I noticed that in April this year there was a large increase in transactions with less than 1 Sat/vByte showing on https://jochen-hoenicke.de/queue/#BTC,6m,weight,0
Did something change to allow that to happen? I'm curious to see if any pool mines them if/when we get there.
That site doesn't represent the majority of the node's mempool and there's no related changes in the code after April 2021: https://github.com/jhoenicke/mempool/commits/masterI noticed that in April this year there was a large increase in transactions with less than 1 Sat/vByte showing on https://jochen-hoenicke.de/queue/#BTC,6m,weight,0
Did something change to allow that to happen? I'm curious to see if any pool mines them if/when we get there.
So maybe he just started accepting <1sat/B transactions or lower his previous setting (minrelaytxfee=n BTC/kB) and for some reason, they never left his mempool since.
Or a bug perhaps?
Maybe it has something to do with the changes he did in the default fee level: https://github.com/jhoenicke/mempool/commit/cffef45b49fc233664d2e735b9f30b1c0016b7c6
Forcing it to zero might have resulted with that graph.
May 28, 2021, 10:17:04 PM
[I'm not familiar how a transaction is being divided into memory/blocks, what determines the size, how fees choose that it can be mined within 1 block or over 30 etc.. => More cryptomoney = Relatively bigger memory size = more fees. It would likely explain itself If I were to dig into how blockchains operate, but made me curious about how fees work. As in if theres a higher fee for really small transfers like my 0.0001 btc. vs lower/optimal fees when transfering something of Size X.
8% fee for moving money is really much. That's why I've been asking myself how to lower the 5-10 Sat/b.
8% fee for moving money is really much. That's why I've been asking myself how to lower the 5-10 Sat/b.
The value of the transaction doesn't matter because the fee is based on the size of the data in virtual bytes. That is determined by the number of inputs, outputs and address types used.
Last time a few tumblers dropped thousands of transactions and we didn't get an empty mempool then, but this time, with the adjustment happening exactly at the end of a weekend we might see it for the first time this year.
With it only being a short time since this happened there should be fewer services with deposit consolidations to do so the probability of an empty mempool is good.
I noticed that in April this year there was a large increase in transactions with less than 1 Sat/vByte showing on https://jochen-hoenicke.de/queue/#BTC,6m,weight,0
Did something change to allow that to happen? I'm curious to see if any pool mines them if/when we get there.
May 28, 2021, 05:31:38 PM
If you we're to guess when the fees are on a lower niveau again, what would you suggest? 42 Satoshi feels a bit out of pace. https://imgur.com/a/IZCrNkj
Based on Johoe's site: 6 sat/byte is enough now for a fast confirmation. Since you're only sending 0.0001 BTC, that's already high, but if you go lower than 5, it may take days/weeks/months to confirm. My advice: try to avoid such small Bitcoin transactions.curious how much "money fits into a block" as some swaps for 130k go with 130 Satoshis.
I'm not sure what you're asking: blocks are limited by size (in bytes), not in "money".I'm not familiar how a transaction is being divided into memory/blocks, what determines the size, how fees choose that it can be mined within 1 block or over 30 etc.. => More cryptomoney = Relatively bigger memory size = more fees. It would likely explain itself If I were to dig into how blockchains operate, but made me curious about how fees work. As in if theres a higher fee for really small transfers like my 0.0001 btc. vs lower/optimal fees when transfering something of Size X.
8% fee for moving money is really much. That's why I've been asking myself how to lower the 5-10 Sat/b.
https://imgur.com/a/5GMbRVu
The 0.0001 transaction was my first transaction. It's main purpose is for me to confirm that actually everything arrives at my exchange wallet. Besides that: It's nice to see live how many mb from the tip away you are with 0.2 satoshi per block. 30 is close. Sunday difficulty is supposed to go -15% (easier?), so even cheaper if I read correctly?
May 27, 2021, 09:21:37 AM
That's quite surprising, considering fees aren't that high at all now.
More than surprising !!!!
We had price swings that would trigger a lot of transactions normally, we are seeing on average close to 20 blocks or less each day and still, the mempool shows no sign of increasing like it did last time, while we're actually seeing fewer blocks than two periods ago. The adjustment over the China mining shutdown was ~-12% this one is going to be a minus ~15. Seeing how even eth is getting lower fees, and the coins that are normally used to avoid fees on the BTC chain from doge to shitcash are hitting the lowest numbers in 3 months all this points to people switching to full hodl mode, probably everyone thinks that spending BTC now is putting them at a loss and wait for a new jump in price.
Last time a few tumblers dropped thousands of transactions and we didn't get an empty mempool then, but this time, with the adjustment happening exactly at the end of a weekend we might see it for the first time this year.
May 26, 2021, 11:20:02 AM
It seem that the current transaction fee are very supportive for making small transaction and I recently made a transaction with a fee of 7 sat/ byte (1MB from tip). However, to avoid network congestion, in my opinion there is nothing wrong with activating the RBF feature.
Jump to: