Pages:
Author

Topic: [Aug 2022] Mempool empty! Use this opportunity to Consolidate your small inputs! - page 30. (Read 83494 times)

hero member
Activity: 1260
Merit: 723
On the btc.com block explorer they show the hashrate reported by each pool and a 24 hr change. All the top pools reduced significantly when the latest 'China bans mining (again)" headlines came out. That's what caused this difficulty drop and also the last one 2 weeks ago. The total hashrate has fallen from ~190 EH/s to under `150 EH/s.
If the lost hashrate is from Inner Mongolia, it matches the statistics from Distribution of bitcoin mining's carbon footprint worldwide as of 2018, by region

That chart is for 2018 and if the % of hashrate from Inner Mongolia per total hashrate won't change too much, it can be a good explanation.

Lost hashrate is about 21%. The contribution of carbon footprint for Bitcoin mining from Inner Mongolia in 2018 is around 26%.

The articles gives better figure for mining contribution from Inner Mongolia. China’s crackdown on bitcoin mining is getting real.
Bitcoin Mining Is Big in China. Why Investors Should Worry.
Quote
Inner Mongolia’s draft rules will be open for public comment until June 1, and the guidelines could set a precedent for other bitcoin mining hubs in China, such as Xinjiang, which accounts for some 20% of global bitcoin mining.

Figures in 2020 are not big different than in 2018.
Quote
According to the Cambridge Bitcoin Electricity Consumption Index, as of April 2020, China was responsible for 65% of all Bitcoin mining. And of that, 36% takes place in Xinjiang, the largest regional component. Why? Cheap coal means cheap energy to power the machines that mine Bitcoin. Xinjiang has an abundant supply of coal, and the region’s relative remoteness means that it’s far cheaper to use the resource locally than move it to other parts of China.

The fall matches with https://cbeci.org/mining_map. China contributes 65% of total hashrate (use tab Global) and 35.76% of hashrate is from Xinjang (use Tab China).
hero member
Activity: 2576
Merit: 882
Freebitco.in Support https://bit.ly/2I9BVS2
And yeah, something fishy is happening, it's been around 4 days we're we are seeing slower blocks by quite a wide margin, probably indeed the China thing is real.

On the btc.com block explorer they show the hashrate reported by each pool and a 24 hr change. All the top pools reduced significantly when the latest 'China bans mining (again)" headlines came out. That's what caused this difficulty drop and also the last one 2 weeks ago. The total hashrate has fallen from ~190 EH/s to under `150 EH/s.

legendary
Activity: 2828
Merit: 6108
Jambler.io
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).

Yeah, pretty simple!
Blockchair has a last 24hours stats:
https://blockchair.com/bitcoin/
And bitinfocharts has a more in-depth graph:
https://bitinfocharts.com/comparison/bitcoin-confirmationtime.html#3m

And yeah, something fishy is happening, it's been around 4 days we're we are seeing slower blocks by quite a wide margin, probably indeed the China thing is real.
The difficulty will most likely drop by 5% and the next period might be negative also.

Now, the funny thing
We are seeing a lot of news, a lot of movements in the market, an average of ~120 blocks per day since Thursday but, there are empty blocks right now, transactions with 1sat/b are getting confirmed. And what's more interesting the difficulty will adjust tomorrow, so even if it won't be accurate the capacity will still increase so it might be possible we will see the first weekdays with 1 sat fees!

People are really hodling to their coins!
Or maybe everyone has switched to LN and we're watching the wrong charts?
If this continues from bumping this topic we might have to pin it!  Grin
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
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.
legendary
Activity: 3430
Merit: 10504
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).
legendary
Activity: 1358
Merit: 2011
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.
legendary
Activity: 2730
Merit: 7065
Farewell, Leo. You will be missed!
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.  
legendary
Activity: 3430
Merit: 10504
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.
legendary
Activity: 2296
Merit: 1176
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."
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
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 Smiley

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).
legendary
Activity: 3500
Merit: 6205
Looking for campaign manager? Contact icopress!
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.
newbie
Activity: 7
Merit: 0
You have saved me money. thanks for share my important issue.
legendary
Activity: 3430
Merit: 10504
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.
copper member
Activity: 1610
Merit: 1898
Amazon Prime Member #7


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.
legendary
Activity: 2394
Merit: 5531
Self-proclaimed Genius
-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.
legendary
Activity: 2380
Merit: 5213
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.
legendary
Activity: 3416
Merit: 1912
The Concierge of Crypto
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.
hero member
Activity: 2576
Merit: 882
Freebitco.in Support https://bit.ly/2I9BVS2
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.

legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
Johoe's Bitcoin Mempool Size Statistics:
Image loading...
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.
Pages:
Jump to: