Topic: 150 sat/b fee; unconfirmed for over 4 hours? (Read 397 times)

Indeed, it's a great example of the difficulties underlying in-wallet fee estimation. BitMEX has the power to drastically alter the fee market, and it's impossible to anticipate exactly how large their load will be or what fees they will use.

In regards to casual users, the only immediate solution is to encourage the use of RBF, and wallets that support it.

The community putting pressure on BitMEX to at least implement broadcast delays could also help. Dumping all those transactions in a 2-minute window everyday is just horribly inefficient.

You are right. I noticed it with wallets including electrum. Luckily i know about the effect of Bitmex's daily withdrawals at 13:00 UTC so i usually try to make transactions early morning before that time.

This is going to be a major problem if the volume of bitcoin transaction increases where we have platforms making batch withdraws at specific hours.

My point is that BitMex’s practices make the fee rate estimates displayed on wallet software less reliable, especially considering that you don’t know how when blocks will be found after you broadcast your transaction.

This is predictable if you frequently use bitcoin, but not as much if you are a more casual user.

I'm not aware of any other businesses doing that -- and certainly not at BitMEX's scale. Exchanges generally allow withdrawals on demand.

It's been a predictable daily event for years now. I can't count the number of times I've had to race or bump fees to beat their morning flood of withdrawals. They are a plague on the network.

I was reading this blog post today and thought of the OPs transaction.

According to blockchain.com block explorer, his transaction was originally seen at 12:25 UTC, and it not getting confirmed by 13:00 meant he would need to wait several hours for it to confirm because of Bitmex's practices of processing withdrawals once daily, and all at once.

If other large businesses engage in similar practices, there is the potential to see large spikes in required transaction fees at arbitrary times, and the fee rate estimates will be less accurate.

Ahh, well spotted. The two transaction have a combined size of 969 vbytes, and a combined total fee of 74,100 satoshi, giving a combined effective fee rate of 76 sat/vbyte, which is almost half the 151 sat/vbyte we were assuming.

I know this is late, but I would like to say the probable reason why his high fee transaction wasn't confirmed even though it's at the "<1mb from tip" range during that time.

The transaction was basically a CPFP tx with 151sat/vB fee of an unconfirmed parent with 50sat/vB fee. (both were included in block 630 156)
Because the default behavior is to also consider the parent transaction to the fee rate computation if both are enough to be prioritized,
it must be because the parent's fee is too low at that time that made his fee wasn't enough for both transactions to be mined at the next few blocks.

Reference for CPFP:

A lot of it is to do with people just accepting whatever fee their wallet tells them to use, which as we know are often wildly inaccurate and overpriced. If you look back at yesterday, blocks 630,116, 7 and 8 were all found in the space of 7 minutes, which cleared out all the high fee transactions. At that point, a fee of 14 sat/vbyte would have put you within 0.1MB of the tip of mempool. Within 5 minutes, despite the mempool increasing in size by only 0.6MB, the fee to get within 0.1MB of the tip had skyrocketed to 120 sat/vbyte. It is completely unnecessary, and if everyone involved had paid a little bit of attention and chosen a sensible fee, they would all have saved ~80% of their fees.

---

blockstream.info shows the fees correctly in sat/vbyte.
blockchair.com shows in the incorrect "Fee per byte" at the top right, but if you click on "Click to see more", it does also show "Fee per kVB" in bitcoin per kilo-virtual-byte, which you can easily convert to sat/vbyte in your head.

Technically, we should all just be working with sat/vbyte at all times. As nc50lc has said, sat/vbyte is identical to sat/byte for legacy transactions, meaning sat/vbyte will always be accurate regardless of what kind of transaction you make, whereas the same is not true of sat/byte and segwit transactions, as we have seen in this case. Continuing to use sat/byte when they are inaccurate 50% of the time only leads to unnecessary confusion.

Correct, to be exact and in order for OP to compute it manually: the "Virtual Bytes" is 1/4 of the "Weight",
The SegWit data from the transaction is equal to 1 WeightUnit, while non witness data is equal to 4WeightUnits, so the WU for SegWit is always lower than legacy transactions

For his transaction, [cd44a8d7121c0eb6f40d7c238760cca0294a92860af31df233acb03d4539cb7c] get the Weight (1024WU) divide it by four = (256vByte) virtual size;
then, get the total fee (0.00038700 BTC), divide it by the vByte = 151.17sat/B fee <-- Miners will use this instead of the Raw Bytes.

And for Legacy, since there's no Witness data, there will be no difference between the size and the virtual size;
(All data will be multiplied by 4 to get the WU, WU divided by 4 to get the vSize).

"Bad blockexplorers" failed to compute it because they are still using the Raw bytes to get the fee rate, should be using this: https://en.bitcoin.it/wiki/Weight_units.

No... that's not how it works. The pools generally prioritise transactions that pay the highest fee rate so they can maximise the return they get from mining a block. Note that it is the rate which is important here, NOT the actual fee amount.

The rate is important, because a transaction that is 50,000 bytes, that pays a rate of 1 sat/byte would generate 50000 sats of fee, but take up a large portion of the block. Whereas a transaction that was only 200 bytes, but paid 100 sats/byte, might only generate 20000 sats of fee, but takes up WAY less space so you can fit in a lot of other transactions as well.

This is how it has always been. The halving makes no difference to this approach to maximising fees by miners.


Also, don't use blockchain.com wallet and/or it's ridiculous "Regular" and "Priority" fee settings... they are generally very inaccurate and will end up with stuck transactions or paying more than you should in fees. Click the "customise fee" button and set it yourself!

My friend encountered something strange while playing with the fees either. She asked me what to put into the fee, I told her to use the regular fee as suggested by blockchain.

While she was trying, she first saw the regular fee to be $2, then a few moments later, suddenly the fee changed to $4 and then it came back down to $0.5 and she sent it with that fee (yes it was regular one) but it's still not confirmed yet. I guess all the mining pools have unified themselves on some sort of agreement over not accepting low fee transactions at all so to recover their losses while mining, as well as at least break even if not profit from it.

It's remarkable how the fees have been going haywire lately.  Mempool had almost 30k unconfirmed transactions when I checked earlier today.  I broadcast a low-fee transaction that's been pending for 6 hours now, but it looks like mempool is slowing down...  I hope I didn't just jinx it.

Your transaction is RBF. So, if you are in hurry, you can increase the transaction fee.
I don't know which wallet you used for your transaction, but as it allowed you to make a RBF-enabled transaction, it will likely allow you to increase the fee.
If you used Electrum, you can simply right click on your transaction, select "bump fee" and increase the transaction fee.

Edit: The transaction was just confirmed.

That's because you are looking at sat/vByte instead of sat/byte. I'm not too familiar with the technical aspect of both of them and their difference, but it is different. AFAIK, vBytes are related to Segwit.

Here is some information I found on StackExchange:


On a side note, your transaction will probably get confirmed really soon with the mempool getting cleaned down to the ~80 sat/byte area.

(if i'm spreading misinformation, sorry technical guys that actually know what this means; i'm sure someone smarter than me will come here and explains this better)

Strange. I tried to check your transaction in other blockexplorers...

https://www.blockchain.com/btc/tx/cd44a8d7121c0eb6f40d7c238760cca0294a92860af31df233acb03d4539cb7c
https://blockchair.com/bitcoin/transaction/cd44a8d7121c0eb6f40d7c238760cca0294a92860af31df233acb03d4539cb7c

And as you can see, both of them say 93 sat/byte...  so based on that, your transaction should confirm soon.

---

EDIT: TryNinja is correct. sat/vByte does differ from the sat/Byte.

.