Topic: BTC unconfirmed transactions exceed 500k on mempool (Read 466 times)

The transaction fees aren't fantastic, but they aren't terrible anymore either. You can pay a little less than $3 and be sure you'll get your transaction confirmed within an hour. The number of unconfirmed transactions is almost twice as low as it was a week ago when the op wrote that post.
Still, a lot of people are overpaying for their transactions because, instead of mempool, they're following websites that state average transaction fees, or they go by highest priority recommendations of their wallets, which can be off by a lot.

This is not a good development for the adoption of Bitcoin, especially when it comes to using it as a payment method to pay for goods and services, with the high fees and unconfirmed transactions, no business person will want to lose their customers by adding exorbitant fees to their prices or charges, even when the mempool dicongests, fiat methods of payments is still more convenient. If not for trading and investment purposes the usage of Bitcoin will not have gained massive usage as it is today, almost everybody that holds Bitcoin is for investment and trading purposes, which is not the best for a currency. I hope that the developers finds a solution to this congestion that happens seasonally, because it is not good for Bitcoin adoption.

If you want to transfer $50 in Bitcoin when fees were as low as 1sat/vbyte then you have a really good deal, cause you can spend on coffee or any other really low expense you make regularly for little to no cost, over several weeks.

LN may not work for everyone and is dependent on the current network congestions and the user's needs.

I just now checked the transaction fee and it has come down significantly. As of now, it is trending around 30-40 sat/vB which is a good sign considering the past two to three weeks. I do not think it will go much lower as gone are the days when it used to be around 10-12 sat/vB. I have not heard that the devs are considering the option of increasing the block size, but if it happens it will be a temporary solution. I am not sure where you came up with this idea @new19980, I am certain that you are an alt and it looks like you are trying to create a narrative of your own.

LN is a solution for long term usage, so you're pay big at the beginning and you can enjoy the less fees after that.

The developers don't want to block ordinals because some argue it's a part of censorship, as we know Bitcoin is truly decentralized.

Most of blocks didn't even reach 4 MB, so I don't think it's need to be increased. As for the other hard forks increase the block size, that's one of reason they fork Bitcoin.

Devs already increased a block size in Bitcoin, BCH, BSV and so on. They may do it again. Who knows.

You think devs can increase the block size or its impossible ?

LN is trash and not a solution i dont know why peoples keep talking about LN lets say you want to transafer 50$ in btc
you need to open a channel and to do so you need to spend no less then 50$ to receive 50$
if ordinals are causing this congestion why devs dont block those shit tokens from the network

That's right and even in mempool.space website we can see a tag in the top left corner below the blocks which poses the replaced transaction so the previous one will become invalid.

---

After a while now we see some drop in the fees, averaging around 60-70sat/vbyte despite the unexpected surge in the price but we are certainly not away from the problem that is causing this issue.

Since it has been stuck for over two weeks now, then nodes operating with the default mempool time of two weeks would probably have dropped it out of their mempool. If the node that you are connected to drops the tx, it'll turn local and you can remove the tx and make a new one paying a higher fee. It is worth mentioning that the fee rate in the mempool is not as high as it was some weeks ago, fee rate for high priority is ~ 90 sat/vByte right now, i know it is still very high, but less worse than when it is > 200 sat/vByte, and the unconfirmed tx's in the network has dropped to ~ 298k transactions.

And unfortunately, my transaction was one of those that has been stuck. 😅 Though it was my mistake to try to transfer my funds to another wallet but due to high fees it was stuck for like 2 weeks now. I tried bumping the fees for like 30-40 sats/vB but the custom fee does not work either due to high fees. But since I was not in a hurry, I just have to leave it there because I know it will just sit there until it is being hit on it's level.

I knew that tagging you wasn't a mistake as you just demonstrated. I guess there is no sure way of knowing what policy Mempool.space follows unless they lay their cards on the table and explain it publicly, something they don't need to do as it's not that important. Considering the importance of their website, they surely keep track of all unconfirmed and valid transactions.

You guessed wrong, for the most part.

The default behavior of Core is that it will never have two conflicting transactions in its mempool at the same time. If it learns of a transaction which replaces a transaction it already knows about, then it discards the old transaction in order to accept the new one. If you read BIP125, it talks about RBF being a "mempool replacement policy".

This is a local policy, not a consensus rule though, so a node could decide to change its behavior and keep track of all transactions, even ones which have been replaced. Sites like mempool.space may do this since you can use their explorer to see whole chains of replaced transactions, or they may have some additional software keeping track of everything being evicted from their mempool.

Even though both are valid, by default your mempool will only ever store one. It will either reject the replacement if the fees are insufficient (or it violates some other criteria as per BIP125), or it will accept the replacement and evict the original. But of course if your node evicts the original and accepts the replacement, and then the original then gets mined, your node will still accept the block containing the original as valid and will then evict the now invalid replacement.

---

So to answer the question seoincorporation posed about the number of transactions in "the mempool", the answer is you don't know how many of those are replacements unless you know the settings of the node whose mempool you are looking at. The default position would be that all replaced transactions have already been evicted, though.

Disagree with the "temporary problem" opinion. Firstly, the problem continues for over a year already with no end in sight. Secondly, the root cause of the problem is the modified incentive structure under Segwit and Taproot. Spammers exploit the witness discount and will keep doing it given the evedence that it has been effective. Miners benefit from the situation short-term (at the expense of other Bitcoiners) so they wouldn't drive the change (Ocean.xyz is the only exception). Other participants are decentralized so it would take them some time to coordinate the effort to fix the problem (the imbalanced blockspace cost structure that put original transactions at disadvantage and favour spam - video explainer: https://youtu.be/WtrBlQJktxg ). This is the permanent situation that original transactions are being driven out by spam ones until a fix is introduced by Bitcoin node operators (you and me and fellow Bitcoiners)

We know the reason for the congestion and given time the hype will go down. I deel that it is a temporary problem and we would see the fees coming down. It is not that I am okay with the high fee. I guess no one here is the forum is happy, we need to have patience and avoid small transaction if possible for now. LN is not an on chain solution but it is the answer for anyone looking to do small transactions at low fees.

25 sat/vByte puts you around 30-35 vMB from the top. So, you will have to wait a long time for the fee rate to drop to those levels. The current purging rate is just above 24 sats. As we speak, you need 100-120 sat/vByte to get into the next block.

I am not sure myself, but I am guessing that if a node receives information about an RBF replacement transaction from its peers, that it doesn't discard the old transaction immediately. Instead, it keeps both in its memory because both are still valid and both could still be confirmed. Transactions get dropped from individual mempools if their fee rate drops below the local purging rate of that mempool. The original one that pays less in fees could end up in a block of a miner that didn't yet receive information about the replacement transaction.

Let's tag @o_e_l_e_o here. He is a go-to-guy for things like this.

Did you get what I wrote? We will have to wait as long as it takes, what I personally am not going to do is pay $20 in fees to send $40. With high fees what I will do is use the Bitcoin to make larger payments, so that the fee percentage is not too high, and for small payments I will use something else or not make them at all.

The way RBF works is that the nodes and miners see that you are offering a higher fee and they usually ignore the original transaction.

I think you are confusing this with child pays for parent. It’s where you got 1 transaction which is older with a small fee and you got a newer transaction with a much larger fee using the unconfirmed input, so the miners will usually confirm both transactions as long as the average fee for both is high enough.

This solution is not very popular, Bitcoin Lightning is not widely used and there are only a few exchanges and other services that support it, so it is not the best solution.

Also, do not forget that you need to pay similar fees when opening and closing the channel.

A good question here is:

Do RBF transactions count as 2 transactions in the mempool? In that case when the new transaction gets confirmed the old one will get discarded, so, those 500k transactions is not a real, if hall of them has been RBF then it would be 375k real transactions. But this is just speculation on my side, I'm not really sure how RBF works on the mempool level.