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

Do you have any rule of thumb to know when to consolidate?

Let me explain. Until now I was in a signature campaign that paid me every six or eight weeks but with a payment for each week. In other words, after two months I received 8 payments, or inputs, of about $40 and I consolidated them immediately, especially because the mempool has been empty recently. Now I will receive weekly payments and I doubt until when to wait to consolidate. I suppose consolidating every week would be silly as LoyceV in the OP talks about "many small inputs".

Should I wait until I have 8-10 inputs? If I wait that long maybe the fees have skyrocketed.

Changes in difficulty should not affect the mempool when it is for all intents and purposes, empty. This is especially true when describing situations in which the difficulty will increase. This might not be the case if the difficulty was dropping by a substantial amount, but that is not the case.

thanks for the advice.  i never thought abut doing this before.  worked out well.

So far the price is rising very slowly despite having a couple of spikes, this I believe is the main reason why there hasn't been any overly excited mempool spam by the traders yet. We may start seeing spikes when price breaks $50k and the rise speeds up though. But that may not happen this week.

As of now 11AM EST on 14-Aug-2021 the mempool is empty.
Unless something changes with the usual weekend coin movement it should be mostly empty for the next 40 hours or so.

As for the difficulty, it's at the same level it was in June of last year with the next change coming in about 12 days.

Most people expect a slow climb back to where we were. But it's all a guess, depending on when and when the miners find new homes.
And what they actually are mining, there seem to be miners slowing being shipped to end users and while we ASSUME most of them are going to be mining BTC there are a bunch of other SHA coins out there that they may wind up being pointed to. But the difficulty discussion is really for another thread unless it starts to cause enough of a slowdown to effect the mempool again.

-Dave

Mempool is starting to grow again. It looks like the difficulty went up, so next Sunday might very well be the last chance in a while for low fees.

This is exactly the reason I use instant exchangers instead of "normal" exchanges. Withdrawal fees are 0.001 BTC on many sites (and 0.0005 on some). That's a lot if you're withdrawing only a small amount, but unfortunately the large exchanges don't seem to want to compete on this.

Indeed, it can make "smaller" customers happy(er). And those are in greater numbers and will spread the word about the service.

Just somehow I feel that the agenda of big centralized exchanges is more on keeping customers' funds in their own cold storage instead of helping the customers withdraw cheaper...

Of course tools like this site are mainly for "advanced" users and it is always best for others to choose a decent wallet with a good fee estimator and stick to that or at least use this alongside that wallet.

Sometimes there are services that "burst pay" their users. For example I remember freebitco.in paid on weekends, so basically we saw lots of transactions go out at once which means most of them would be in the same block. Of course that is the case with payments not spam attacks.

It should be quite simple to implement:

When your site has withdrawals, and, for example a user wants to withdraw 1 BTC, he sees a couple of options on the screen:

1. Withdraw 1 BTC fast, usually 10 to 20 minutes, withdrawal fee is 0.02 BTC
2. Withdraw 1 BTC with batching, can take up to an hour, withdrawal fee is 0.001 BTC

That's just an example. At least you give the user a choice. Some people don't mind and can wait the extra hour or two, and pay less.

I think that's good for business. I ran a bitcoin "gaming" website before.

From a business point of view, I do not really understand why to spend time and effort on this if the transaction costs are covered by clients in one way or another. But such a decision would be very clever from a marketing point of view, since by spending a little money on updating and implementing this feature, you subconsciously convey to customers the idea that transaction costs on your platform are lower than on competitors' platforms, (even if the client never uses this function + you offer what your competitors do not offer.).

If you are one entity and need that many transactions, it may make more sense to combine the transactions into one... also called batching. Don't do 50 or 100 separate single transactions, do 1 transaction with 50 to 100 inputs/outputs as needed, wait a few minutes to accumulate a bunch, ask the user if they are willing to wait to pay a lower fee.

Depends on who the culprit is and how much he pays for it.
If it's Binance and they pay their usual 60-100sat/b you know they will most likely fill the next block and you're left behind if it's one of those tumblers that have appeared lately with their 2-3sat/b then they will be at the bottom till the mempool clears. If they pay the average, then yeah, they will have them distributed one by one as they find space in each block.

We just had one of those spikes, we had an average of 60 sat/vB in the block after it but in the last hour we had 13 blocks, so the mempool is empty with the fee ~3 sat/vB in the last one. To be honest, at these fees it doesn't make much sense to spend that much time on researching unless you have a lot of dust to deal with!  What's a few extra cents, you're losing more if the price goes down by 1% while you do all that math.

Correct me if I'm wrong, but in the case of a so-called burst of transactions, they are not divided evenly between blocks? I don't remember who exactly published it, but a couple of months ago I saw a test here on the forum that simulated 300 thousand transactions, which were ultimately evenly distributed between three or four blocks, (I confess I don't remember what the essence of the test was, but I remember that it was somehow connected with testing the size of the mempool).

I disagree. Most people uses the mempool data wrongly, for eg. reading the chart after successive blocks gives a fee rate that is far lower. You can't predict the future, but it doesn't help if the user don't know what to do with the data. Simply telling them to aim for the top 1vMB of the chart with their fee rates is insufficient.

If you know what you're doing, sure go with the mempool charts. If you don't, then it would often be a better idea to just follow the floating fees given by your client. Fees estimator, or estimation algorithms in general uses the data from the mempool, grouping them into buckets for analysis and showing an estimate to the user. It is really not as inaccurate as people think, though admittedly the way it works makes it less responsive than looking at the mempool yourself. At the start, Core's estimation wasn't great but I've seen quite an improvement over the past few versions (actually got better after 0.15 IIRC). It doesn't reflect the state of the mempool in real time, that isn't what floating fees should do.

I've abandoned that for mempool.space and one of the things that made me do to were exactly the fluctuations, it shows way better the incoming transactions for the last two hours if there is no huge spike in them and they are all around the median capacity you know that there is the risk of binance or some other big exchange dumping half a block worth of transactions just about now. On the other hand, if you see that there have been two or three of those spikes reaching 7-10k vb/s  you know that at least for a few hours there is little chance of another set of waves hitting the mempool.

But that is just for the mempool stats, their estimator is also pretty inaccurate, it takes into account the median fee for the next block, and since right now at block 689888 somebody has sent a 2875 sat/b the estimate is complete bs.

Sometimes that is true, like these days that the bitcoin market is "calm". Other times it is not possible to predict, for example when the price is making sudden moves. Or even in some cases major altcoin pump and dumps require bitcoin moving to and from altcoin exchanges creating a lot of spikes that can not be predicted.

I couldn't agree more. That is why visual representation of mempool such as https://jochen-hoenicke.de/queue/ are always the best for fee estimation. You can see the mempool size, the fluctuations and in times of fee growth you can even estimate the rate at which fee is rising.

I think, generally speaking, the number of transactions and their fees can be easily predicted if you know the amount of time since the last block was mined. I think it is fairly unusual to see large spikes in the number of transactions.

This would result in fee estimators consistently underestimating the cost to get a transaction confirmed. If a block was found 2 seconds ago, the fee estimator will show a minimum required fee for a next block confirmation that, if used, may result in a user waiting a day for confirmation. On average, half of all transactions will be broadcast 5 minutes prior to the next block is found, and the mempool will generally change during this time.

Fee estimators could be improved if users could see, and adjust assumptions made by the estimator.

That is the "human behavior" that we cannot predict not the time between blocks. Even if blocks were mined at fixed intervals (like every 60 seconds) we still wouldn't have been able to predict whether in the next seconds there will be a surge of new transactions paying higher fees or not.

Fee estimators should work on size not count and shouldn't try to predict the future.
Basically they should tell you that with current mempool situation when the next block is mined it will clear ~4MB from mempool and will contain down to x sat/vbyte fee and anything lower will remain unconfirmed. That way it won't matter if someone was paying very high fees for 100 transactions.

It is difficult for fee estimators to accurately predict the minimum required fee because the time until the next block is always unknown. If a block was just found, the mempool will have fewer high-paying transactions, but it is reasonable to expect that high-paying transactions will appear in the mempool over time until the next block is found. This makes estimating the required fee difficult because you don't know when the next block will be found, and in cases when a lot of mining capacity is being taken on/offline, the fee estimator may not even know how long until the expected time of the next block.

A lot of posts in this thread, and in posts in other, similar threads talk about the required fee to get a single transaction confirmed, but this fee rate would probably not be appropriate if you need 50, 100, or more transactions confirmed in nearly every block, as many larger bitcoin businesses may need. A large business who pays the minimum required fee might get a portion of their transactions confirmed quickly, but would quickly see their transactions pile up as being unconfirmed, which will cause problems. I think a business that consistently needs many transactions confirmed in every block would need to pay something closer to the median fee rate. This has the potential to cause confusion to some of the fee estimators out there.