Estimating Segwit transaction fees

[squatter]

What do people use to estimate bech32 transaction fees? Electrum's fee estimation, as expected, drastically overpays. I also haven't wrapped my head around satoshis/bytes vs. satoshis/vbytes and how to figure out how much transaction size is allocated to witness data.

Usually I set very low fees since confirmation time isn't an issue. Recently, I needed to send some urgent transactions. I basically just eyeballed the Core next-block fee in satoshi/byte and reduced it by 25% to be on the safe side. Electrum told me the fee was low and to expect 25 blocks before confirmation.

But they were confirmed in the next block and I suspect I overpaid. Any ideas?

[1714917446]

1714917446

[1714917446]

1714917446

[1714917446]

1714917446

[1714917446]

1714917446

[1714917446]

1714917446

[achow101]

I also haven't wrapped my head around satoshis/bytes vs. satoshis/vbytes and how to figure out how much transaction size is allocated to witness data.

vbytes are calculated by first dividing just the size of the witness data by 4 and then adding that to the size of the non-witness data.

I basically just eyeballed the Core next-block fee in satoshi/byte and reduced it by 25% to be on the safe side.

Bitcoin Core's estimator actually uses vbytes, it's just labeled improperly.

[squatter]

I basically just eyeballed the Core next-block fee in satoshi/byte and reduced it by 25% to be on the safe side.

Bitcoin Core's estimator actually uses vbytes, it's just labeled improperly.

Ah, so I guess the problem there isn't bytes vs. vbytes. It's that Core's fee estimation (like Electrum) is bad. Which leads me back to square one: How are people estimating their fees with Segwit? There's gotta be a better way.

Bad fee estimation must be part of the problem during periods of heavy spam and congestion.

[TheQuin]

Ah, so I guess the problem there isn't bytes vs. vbytes. It's that Core's fee estimation (like Electrum) is bad. Which leads me back to square one: How are people estimating their fees with Segwit? There's gotta be a better way.

Bad fee estimation must be part of the problem during periods of heavy spam and congestion.

On Electrum I always use manual fees as ALL fee estimators result in overpaying. I use the preview transaction function as it displays the size in bytes which is actually vbytes and multiply that by what fee per byte I want to pay. Then adjust the fee and preview again and the sat/byte number will be accurate.
(3.0.0 did slightly underestimate the size but that bug has been fixed.)

For actually working out what fee I want to use https://dedi.jochen-hoenicke.de/queue/more/#2h shows what fee levels are currently being included in block far better than any other site I have found.

[achow101]

It's that Core's fee estimation (like Electrum) is bad.

Compared to other fee estimators, it's very good. Note that Electrum basically uses Core's fee estimation (the estimation from the Electrum servers which use Core as the backend).

Which leads me back to square one: How are people estimating their fees with Segwit? There's gotta be a better way.

Many people look at fee information charts like https://dedi.jochen-hoenicke.de/queue/#24h and choose a fee rate based on what outbids most transactions. Unfortunately this kind of pattern seeing and the processes that the human brain does in order to make such a decision is hard to do algorithmically. Note that just doing that in software is actually very gameable and ignores a ton of other information that helps make a better fee rate prediction.

[TheQuin]

Unfortunately this kind of pattern seeing and the processes that the human brain does in order to make such a decision is hard to do algorithmically. Note that just doing that in software is actually very gameable and ignores a ton of other information that helps make a better fee rate prediction.

Thanks for that explanation. Not being a programmer I have been curious about that. It makes a lot of sense that the human brain is far more suited to pattern recognition and also explains why a visualisation like jochen-hoenicke.de is the easiest to use. It seems that high fee estimations are part of the problem in that so many use them that they actually keep fees artificially high by forcing everyone else to outbid them. Particularly when fees are in a phase of falling there is often a very large gap between a large chunk of low fee txs and then a large number of high fee txs being constantly added to.

[Random Seller]

I think it would be best, if wallets like Electrum calculate 2 fees by default. One for sending the money as fast as possible and another to send the money within 24 hours.

Not all people needs to send their money right away, so the option is needed. And if more people use this option transaction fees would fall. If the average transaction fee lowers, fees for fast transactions will also fall as a result.

[achow101]

I think it would be best, if wallets like Electrum calculate 2 fees by default. One for sending the money as fast as possible and another to send the money within 24 hours.

Not all people needs to send their money right away, so the option is needed. And if more people use this option transaction fees would fall. If the average transaction fee lowers, fees for fast transactions will also fall as a result.

Fee estimators do that. Most of them (including Electrum and Bitcoin Core) have some option to let you select different speeds.

[Random Seller]

I think it would be best, if wallets like Electrum calculate 2 fees by default. One for sending the money as fast as possible and another to send the money within 24 hours.

Not all people needs to send their money right away, so the option is needed. And if more people use this option transaction fees would fall. If the average transaction fee lowers, fees for fast transactions will also fall as a result.

Fee estimators do that. Most of them (including Electrum and Bitcoin Core) have some option to let you select different speeds.

Just pretend I didn’t say anything than