Who is paying very very large fees when not needed and why?

[o_e_l_e_o]

Makes you wonder if anyone sat down and did a cost analysis of hiring programmers and re-doing some things to reduce the fees they pay and possibly increase privacy a bit by not moving funds as much, vs. the cost of dong the things the way they do now.

I can understand that they don't actually care about bloating the mempool and forcing everyone else to pay more fees, but since their users seem happy to be fleeced such ridiculous withdrawal fees, then Binance are throwing away their own money by overpaying to such a high degree and processing thousands of transactions a day on legacy instead of segwit. Even if you ignore the intricacies of accurate fee estimations, just switching all their wallets from legacy to segwit, while time consuming, wouldn't require hiring any new programmers or engineers, and could easily save them a third or more on all their fees.

The easiest solution to this is just to make bech32 the default, giving people an option for either nested SW or legacy (probably nested SW would do).

Yeah, agreed. There are still some awful exchanges and services which still don't support segwit, but I've never heard of any which don't support P2SH addresses. Bech32 as default, nested segwit if you really need it.

There is still a number of users who uses Segwit: c68338dfc5ced3b876de31bacd3227404b88fb49f6a1fb020767f179c29ad946, for example but the ratio is far lower.

And they get swept back to a legacy address, haha. That hot wallet address has made over a million transactions. Think of the amount of fees which could have been saved!

Who knows, maybe they are just going to bypass segwit and switch straight to taproot.

[1714213218]

1714213218

[1714213218]

1714213218

[1714213218]

1714213218

[1714213218]

1714213218

[1714213218]

1714213218

[1714213218]

1714213218

[odolvlobo]

One source of excessive fees might be closing of Lightning Network channels. It's all automatic. I just closed one and paid 30 s/b.

[franky1]

alot of people here think that bitmex could save money if it changed to segwit..
(facepalm)
if they bothered to check the bitmex transactions dont care about bytes per sat or weight per sat.
they are paying fixed amount per transaction no matter what the byte/weight is
so the transaction format or the cludgy math of not counting bytes as bytes has no meaning or impact

it seems that they just prefer to pay rounded fee's amounts as a flat rate. no matter if they are using legacy, bech or p2sh
its either 0.005, 0.002 or 0.0022

it seems to me their philosophy is more so the bitmex server hot/cold
their 3bmex is flatrate no matter size
their bc1qmex is flatrate no matter size
however
their 1/3[rand] -> 1ND is more 23sat/byte orientated (in to cold)
their  1ND-> 1/3[rand] is more 100 sat/vbyte orientated (in to hot)

which just reveals the managers of the 1nd use separate wallet software to the custodial bc1dmex/3bmex hot/cold wallets more closely associated to bitmex exchange

and not at all about giving a crap about segwit or not

[Rath_]

One source of excessive fees might be closing of Lightning Network channels. It's all automatic. I just closed one and paid 30 s/b.

If you are using c-lightning then you can modify the negotiation strategy of your node and make it more aggressive. It's very likely that the other peer forced you to overpay.

https://lightning.readthedocs.io/lightning-close.7.html#description - see [fee_negotiation_step]

[BlackHatCoiner]

One source of excessive fees might be closing of Lightning Network channels. It's all automatic. I just closed one and paid 30 s/b.

I confirm this. I just paid lots for closing a lightning channel from electrum. Is there an option to change that (probably) hard coded value?

[LoyceV]

One source of excessive fees might be closing of Lightning Network channels. It's all automatic. I just closed one and paid 30 s/b.

I confirm this. I just paid lots for closing a lightning channel from electrum. Is there an option to change that (probably) hard coded value?

This is one of the reasons I gave up on opening my own LN-channels. By using either custodial (BlueWallet) or an "automated" (Phoenix) wallet does does everything for me in exchange for a small fee, I don't need to worry about having to close channels anymore (although now that you mention it, I wouldn't know if I'd lose anything to fees when Phoenix Wallet closes a channel).

I've seen many consolidation transactions from exchanges or payment processors that easily pay thousands of dollars per transaction in fees. I can only imagine their business is so profitable, they simply don't care. It seems like a waste though.

We know this address belongs to Binance
they all pay around 100 sats/vbyte when 2 sats/vbyte would have been sufficient,
So these transactions at least are just Binance needlessly pushing the fees up.

What if it's just to push people towards their own made-up coin that miraculously is worth 50 billion dollars?
When withdrawing, Binance shows this:

(old screenshot, despite low fees, Binance now charges even more to withdrawal Bitcoin.
They show 3 fake centralized tokens with real Bitcoin hidden somewhere in between. They make withdrawing Bitcoin ridiculously expensive. If they pay a few million dollars in Bitcoin fees, and it increases the value of their own made-up tokens by a few billion dollars, that's a very easy way to make a huge profit.

There is hope: at least some services are using the opportunity when fees are low:

[BlackHatCoiner]

By using either custodial (BlueWallet)

What exactly do you mean by saying custody in lightning channels? That it doesn't allow you to pick a lightning node by your own or that it generally keeps your money?

There shouldn't be any custody in the lightning network; isn't it ironic that you've given up its main purpose of existence and still support it as a protocol?

I've seen many consolidation transactions from exchanges or payment processors that easily pay thousands of dollars per transaction in fees. I can only imagine their business is so profitable, they simply don't care. It seems like a waste though.

It sounds excessive. Would you mind giving me a transaction hash to check?

[LoyceV]

What exactly do you mean by saying custody in lightning channels? That it doesn't allow you to pick a lightning node by your own or that it generally keeps your money?

LN on BlueWallet is custodial. That means a user can instantly receive a LN payment, or make an on-chain deposit. If they decide to run away, I lose my funds. But I'm totally okay with that risk for a small amount (don't forget people trust exchanges with tens of billions).

There shouldn't be any custody in the lightning network; isn't it ironic that you've given up its main purpose of existence and still support it as a protocol?

The protocol works fine. My custodial wallet can make payments to non-custodial services. So I can use it to buy coffee, without the hassle of dealing with channels and balancing capacity. Slightly off-topic here, but I don't think LN will reach mass-adoption if the average user has to setup their own node.

It sounds excessive. Would you mind giving me a transaction hash to check?

It's been a while since I used one, so I don't have a txid ready. I remember following my payment at the fee-peak in 2017: it was consolidated (by Bitpay) with a $6000 fee.

[khaled0111]

^^
BlueWallet lightning wallets are custodial indeed. When you fund your lightning wallet, you don't really create a channel, in fact you send the bitcoin to them and they will use their own nodes to open a channel for you (it's possible that they don't even do that). Therefore, your Bitcoin is in their custody (although they prefer the term hosted) and they can do whatever they want with it.
It's not really a big deal but if you're not fine with it, you can always run your own LN node.

[BlackHatCoiner]

If they decide to run away, I lose my funds.

Well... that was an anticlimax.

The protocol works fine. My custodial wallet can make payments to non-custodial services.

The thing confuses itself if we agree that the protocol works if another party holds your money. Essentially, you aren't making payments, independently; you need the BlueWallet nodes to be online, otherwise you can't use the protocol. In other words, the requisition of the third party that is being prevented in the protocol is now clearly not.

When you fund your lightning wallet, you don't really create a channel, in fact you send the bitcoin to them and they will use their own nodes to open a channel for you

That's why I got curious when I saw that “Multi-Sig” SegWit Native be so short.

It's not really a big deal but if you're not fine with it, you can always run your own LN node.

I can always run my own LN node, but I can't connect it to my BlueWallet. It'll take me some time to find another wallet so user-friendly as that.

[o_e_l_e_o]

I just paid lots for closing a lightning channel from electrum. Is there an option to change that (probably) hard coded value?

I'm not sure about in Electrum, since I haven't used Electrum for Lightning yet, but yes, you can choose the fee your settlement transaction pays. The issue is that sometimes your settlement transaction may have been signed days, weeks, or even months, before it is broadcast, so whatever fee you pick could end up being very inaccurate. The solution to this is the use of anchor outputs: https://bitcoinops.org/en/topics/anchor-outputs/. These essentially allow you to sign a settlement transaction with a fee which is intentionally low and then to bump it if necessary after you have broadcast it.

What if it's just to push people towards their own made-up coin that miraculously is worth 50 billion dollars?

I mean, not only is their coin obviously centralized trash, but they still have the audacity to charge a withdrawal fee on it, despite the fact they run the entire network and are literally just changing numbers on a spreadsheet? Who in their right mind falls for this trash?

[LoyceV]

The protocol works fine. My custodial wallet can make payments to non-custodial services.

The thing confuses itself if we agree that the protocol works if another party holds your money. Essentially, you aren't making payments, independently; you need the BlueWallet nodes to be online, otherwise you can't use the protocol. In other words, the requisition of the third party that is being prevented in the protocol is now clearly not.

From my perspective, it's simple: I have a choice I can choose to use a custodial wallet, I can choose to run my own node, or I can choose any of the options in between. In the end, all of them can send payments to each other, so from a user's perspective everything works just fine.

It's not really a big deal but if you're not fine with it, you can always run your own LN node.

I can always run my own LN node, but I can't connect it to my BlueWallet.

I haven't tried it, but you can actually connect BlueWallet to your own full node.

It'll take me some time to find another wallet so user-friendly as that.

Try Wallet of Satoshi, or Phoenix Wallet.

[Rath_]

[...] but yes, you can choose the fee your settlement transaction pays. The issue is that sometimes your settlement transaciton may have been signed days, weeks, or even months, before it is broadcast, so whatever fee you pick could end up being very inaccurate.

It sounds like you are confusing a commitment transaction with a mutual close. A mutual close involves only one transaction while commitment transaction needs two (see more detailed explanation). You cannot choose a fee for both of them. The fee is negotiated between you and the other party automatically (based on your feerate which you should constantly be updating). A new commitment transaction is signed whenever you or the other party adjust the feerate.

I confirm this. I just paid lots for closing a lightning channel from electrum. Is there an option to change that (probably) hard coded value?

You cannot specify the fee of the closing transaction in Electrum. It probably relies on the estimates provided by the Electrum server you are connected to. By the way, I wrote a walkthrough for the Electrum implementation of the LN; you might have missed it.

I can always run my own LN node, but I can't connect it to my BlueWallet. It'll take me some time to find another wallet so user-friendly as that.

Actually, you can! You need to be running LND and you need to install LNDHub, and then you can point BlueWallet to your node in the settings. While I was running LND before I had switched to c-lightning, I was using Zap Wallet. It integrates well with LND, but it was a real pain to set up. LND has a lot of fancy stuff, but it does not have as many "power user features" as c-lightning, which lacks those fancy things.

[...] and they will use their own nodes to open a channel for you (it's possible that they don't even do that).

Here you can see all of their channels and their liquidity. They opened a few channels in advance.

[o_e_l_e_o]

-snip-

Perhaps I should have been more specific with my terminology. My understanding was that a mutual close settlement transaction can have any fee you like, since you are negotiating it in real time with the other party, and so you would simply both agree on an appropriate fee. A forced closed settlement transaction will potentially have been signed well in advance, and so the fee is fixed at whatever you chose at the time, which may or may not still be an appropriate fee to pay. This is where anchor outputs come in, allowing you to set a low fee which you can later bump. Am I mistaken?

[Rath_]

Perhaps I should have been more specific with my terminology. My understanding was that a mutual close settlement transaction can have any fee you like, since you are negotiating it in real time with the other party, and so you would simply both agree on an appropriate fee. A forced closed settlement transaction will potentially have been signed well in advance, and so the fee is fixed at whatever you chose at the time, which may or may not still be an appropriate fee to pay. This is where anchor outputs come in, allowing you to set a low fee which you can later bump. Am I mistaken?

Sounds good! Sorry for nitpicking. I just wanted to make sure no one else gets confused. The negotiation part is very tricky, though. I still haven't figured out how not to overpay by a lot. I have recently closed a channel with a 60 sat/vbyte fee while 2 sat/vbyte was enough for a fast confirmation. Next time, I will try adjusting the negotiation strategy manually (by the way, such a feature is available only in c-lightning).

[DaveF]

I don't know if it's always been there and I never saw it or if it's something new, but mempool.space now shows how much people overpaid on fees if you click on the transaction.



Kind of interesting, if sad to look at.
Looking through the last few blocks, there are still a lot of large fees paid when they don't need to be.

-Dave

[o_e_l_e_o]

Looking through the last few blocks, there are still a lot of large fees paid when they don't need to be.

It's at time like these, when the mempool is emptying out with each block, which really highlights just how stupid people are being with their fees.

Look at the mempool activity since the last block was mined and the mempool totally emptied out. 5 minutes later, and the mempool is still only 0.3 vMB in size, however we have almost 70 transactions paying upwards of 100 sats/vbyte, and over 300 paying upwards of 10 sats/vbyte. Ridiculous. The mempool has emptied out with almost every block for the last 12 hours, meaning 1 sat/vbyte has always been enough for a fast confirmation. Which algorithms/user see this, see a total mempool of under 0.3 vMB, of which more than half is paying less than 3 sats/vbyte, and decide pn fees of over 100 sats/vbyte? What a waste of money.

Every single one of those users could pay 1 sat/vbyte, get confirmed in the exact same length of time, and save >90% on their fees.

[LoyceV]

Which algorithms/user see this, see a total mempool of under 0.3 vMB, of which more than half is paying less than 3 sats/vbyte, and decide pn fees of over 100 sats/vbyte? What a waste of money.

Those algorithms are what pushes up fees so quickly once blocks are full. If a block is filled with 1 sat/byte transactions, you could get priority over those by paying only a little more (say 1.1 sat/byte). That could lead to a very slow increase of fees (1.2, 1.3, ...... 2.0), but instead it quickly goes to 10, 50, 100 and more. I don't mind people wasting their money, but they drag others with them too.

[ranochigo]

Which algorithms/user see this, see a total mempool of under 0.3 vMB, of which more than half is paying less than 3 sats/vbyte, and decide pn fees of over 100 sats/vbyte? What a waste of money.

Poorly implemented ones or those that don't know any better and has a fixed fee rate.

Those algorithms are what pushes up fees so quickly once blocks are full. If a block is filled with 1 sat/byte transactions, you could get priority over those by paying only a little more (say 1.1 sat/byte). That could lead to a very slow increase of fees (1.2, 1.3, ...... 2.0), but instead it quickly goes to 10, 50, 100 and more. I don't mind people wasting their money, but they drag others with them too.

If you're in a hurry, it is simply not an option for you to increment fees slowly nor is it for those services where withdrawals/coin movement are time-sensitive. You can't really compromise in this aspect; if your algorithm guarantees a confirmation within the next block, your algorithm should suggest a fee which does exactly that. Slowly incrementing the fees for the algorithm simply won't work and would probably result in far longer wait before a confirmation for most. There should not be a scenario where the algorithm suggests a fee that risks not hitting the target, some services doesn't really have a choice; CPFP makes the TX unnecessarily expensive, RBF is not an option. The penalty for them is unnecessary costs with their transaction and the user has to be the ones boycotting them.

Currently, Bitcoin Core suggests a fee of 1sat/vbyte for a confirmation within the next block. Not all algorithms are flawed. If they are paying fees that are excessively high, then they probably already know about this and would rather spend more on the fees than to change the algorithm or having users complaining about their withdrawal.

[LoyceV]

if your algorithm guarantees a confirmation within the next block, your algorithm should suggest a fee which does exactly that. Slowly incrementing the fees for the algorithm simply won't work and would probably result in far longer wait before a confirmation for most. There should not be a scenario where the algorithm suggests a fee that risks not hitting the target, some services doesn't really have a choice; CPFP makes the TX unnecessarily expensive, RBF is not an option.

I disagree on the CPFP part. If - say - Binance now pays 100 sat/byte for a transaction with 100 outputs, they could easily to for 10 sat/byte and still get into the next block about 90% of the time. For the 10% they don't make it, they could instantly do CPFP onces fees in mempool go up. If they quickly bump the average fee to 25 sat/byte, they can still make it into the next block, and depending on the state of mempool, they can increase fees by as much as needed.
The cost of an incidental CPFP is tiny compared to the amount they save on total fees.

Implementing this would just be a bit more work. In Binance's case, I'm pretty sure the millions of dollars they waste on fees are totally worth the billions of dollars they earn from promoting their own centralized shitcoin.