Topic: Who is paying very very large fees when not needed and why? (Read 1064 times)

Remember with lighting the case is very different to a "normal" user.

With lighting you can be in a situation where you MUST get your transaction confirmed in a block within a certain number of blocks or the other side of the channel "could" steel all you coins.
So the downside of underestimating is not just the inconvenience of having to wait - but could be loss of all the funds in the channel.
In this situation saving a few sat may not be worth the risk.

Although for a Mutual close should not be the case!

i am running my own lightning node since some days/weeks and i closed one channel (first to practice, but also for other reasons) and the mutual closing transaction looked a lot like the screenshot posted above. well i paid not that much, but it also stated "overpaid by 20x". i need to figure out how to get the "starting fee" the other node will propose as soon as the two nodes enter the "negotiation phase". sorry this is a lightning network question and a little bit offtopic. but i think the theory about lightning node useres paying too much to close channels might be right, it happend to me now at least once  

i wouldn't call getting access to bitcoin you bought a service, okay it is a service, but not a service about which you can say: look at me, i allow withdrawals of bitcoin you bought which aren't yours if you dont withdraw them - they earn probably most of their revenue with trading fees - imo it is "bad business" wanting to earn a profit with withrawal fees (not sure they do or want to do that - i am just replying to the quoted statement

So an extra 7,000 sats for an output which costs an additional 3 vbytes of transaction space, for a cool 2,333.33 sats/vbyte. That seems reasonable. Although I shouldn't really be complaining if they are incentivizing people to use Segwit, regardless of just how stupid that incentive is.

Or in some cases, such as with Tether, a token which has been proven in court not to be backed up 1:1 with dollars at all.

To address the rest of those two paragraphs - correct me if I'm wrong, but when you click on the "Withdraw" button next to bitcoin on Binance, you are presented with four chains for withdrawing your BTC: BTC, ETH, BNB, and BSC. This is misleading at best, but more likely, deliberately deceitful. When someone wants to withdraw a stablecoin, there is no doubt that they have bought USDT, USDC, whatever, and that is what they are withdrawing. It is not difficult to see how a newbie would click on "Withdraw bitcoin", be presented four options with different fees, and pick the cheapest one, without understanding they are not actually withdrawing bitcoin at all. If someone wants to withdraw a bitcoin token on the BSC chain, for example, then they should first have to go through a swap process to turn their real bitcoin in to tokenized bitcoin before they can then withdraw it, just as they would have to sell their bitcoin for a stablecoin if that is what they want to withdraw.

Sure, but they also don't cost $16,000 an hour.

Of course they do. But looking back over their withdrawal transactions, thanks to batching each output averages out as only around 50 sats/vbyte. Even at Binance's ridiculous overpayment of 100 sats/vbyte, there is no justification at all for charging 57,000 sats per withdrawal.

They are only charging the higher amount if you withdraw to a non-SegWit address. If you withdraw to a SegWit address, the withdrawal fee remains at 0.0005.
I would compare binance allowing customers to withdraw "bitcoin" via ETC20 and their two BEP blockchains as something similar to how exchanges allow customers to withdraw stablecoins. When someone withdraws a stablecoin, they are receiving a token that is backed 1:1 with Dollars, is redeemable for dollars at the same rate, and customers most frequently receive stablecoins with the intention of later depositing the stablecoin on an exchange that supports said stablecoin when market conditions warrant. The customer does not have to wait for the slow banking system, nor have to deal with the costs associated with using the banking system every time they want to temporarily move "dollars" off their exchange account, or when they want to move dollars between exchanges.

No, an ERC20 token, nor a BEP20 token that represents bitcoin is not bitcoin. Someone receiving a "bitcoin" withdrawal via one of the smart contract blockchains most likely intends to later deposit said coin back onto their binance account, or another exchange account that supports said blokchain deposits. With that being said, I would rather a trader who understands the difference, and the risks of holding onto their "bitcoin" this way, and who can be described as the above, receive their "bitcoin" withdrawals this way so to lower transaction fees for everyone else who is using the actual bitcoin blockchain.

There are costs associated with processing a withdrawal above transaction fees. Binance (or any other exchange or business that processes withdrawals) needs to invest in means to ensure that withdrawal amounts do not exceed available balances, and an automated means to actually create withdrawal transactions. Neither of these are free. The costs associated with withdrawals is disclosed to their customers prior to them creating an account at binance, and binance deserves to earn a profit on services it offers. Binance is one of the largest crypto exchanges, so I think it is probably fair to say the value of the services their exchange provides exceeds the costs of their overpriced bitcoin withdrawals.

While we are on the topic of fees binance charges, someone making 100 BTC worth of trades in a month is going to pay 0.1 BTC in trading fees. My guess is the profit margin on trading fees far outweighs their profit margins on withdrawal fees.

My guess is binance is paying high transaction fees because they can afford to based on how much they are charging. They are probably also trying to limit the amount of information the server that signs transactions receives. Any information a hot wallet receives is a potential attack vector.

Their consolidation transactions are trivial in comparison. Take a look at some of the ones they've made today:

https://mempool.space/tx/bcc8340c2fe86ed684cdbdebb06c4c97c5f77948177c7999e655c1995d406def
https://mempool.space/tx/0dcb6b2c3a5fb76c958158c0b7728f5175d0da5c8d1dba827f37a1276def38fa
https://mempool.space/tx/1aad2a9666dba36e8111e78c7c9267866ac7a3ff9914bd5369fb3bf3cc5769ea
https://mempool.space/tx/55893c880c16fdae2b026826f1bf8651c5511b480388047ffd4812a2d6166ed2
https://mempool.space/tx/87aa69969d59cdde3393dcfc7081db161f98688de49a679ca5168d28d4444fca

All paying 2.3 sats/vbyte. 162 inputs in total, and the combined fee of all those transactions is still less than the price they charge for a single withdrawal from a single user. So even considering that, the profit from one withdrawal transaction only drops from $800 down to $780 (I fixed my math in the post above).

To be fair: they also pay to consolidate inputs, but that's not included in this transaction. I've said it before, but again: a much fairer system would be to charge a fee on deposits, but that doesn't fit their business model: they want deposits, and they don't want withdrawals.

It would actually be fairly trivial to write a script which places their transactions at 0.1 vMB from the tip of the mempool, and then constantly watches the mempool. As soon as the transaction falls below 0.7 vMB from the tip (example numbers), then they broadcast a CPFP which puts it back at 0.1 vMB from the tip. They would still be guaranteed the same confirmation times that they currently get by overpaying their fees by 10-100x, they would save a bunch of money, they would stop bloating the mempool so much, and they could pass huge savings on to their users.

But, as you say, they have no incentive to do that, since their users seem quite happy to be utterly fleeced with their ridiculous withdrawal fees, and it plays in to their narrative of promoting their centralized shitcoin.

That's kind of the problem though - the bulk aren't paying a "normal" fee rate. Every transaction in the last 12 hours could have paid 1 sat/vbyte and taken at most 2 blocks to be confirmed, whereas we only have around 10-20% of transactions paying this amount, meaning 80-90% of transactions are overpaying to some degree. If you want to over pay 2-5 sats/vbyte because you desperately want confirmed in 1 block and not 2, sure, I can appreciate that. But paying 10-500 sats/vbyte is just plain stupid.

Hahaha, what? Taking a look at their last withdrawal transaction which was broadcast: https://mempool.space/tx/8d6454fbdfe1ba950ebbfbd79a2a389640a63074effcff9060180bcfe690f24f
38 outputs, total fee of 48*0.00057 = 0.02736 BTC. Even with their ridiculous 100x overpayment fee of 0.002009, they still make a nice profit of 0.025351 BTC, almost $800 at current prices, on a single transaction. They have made 20 such transactions in the last hour alone. $16,000 an hour taken from their users for no reason.

Binance users are idiots for putting up with this.

Edit: I mistyped the number of inputs (38 rather than 48). Fixed the math - it is even more ridiculous now.

Lol, they've increased withdrawal fees to 0.00057 BTC.
But what I really dislike about them is the "Select withdrawal network" when withdrawing Bitcoin. Their site is now designed to confuse uneducated users into thinking there is more than one way to withdraw Bitcoin, while 75% of their options are fake.

As a user, it is my business And as a Bitcoin user, it influences my transaction fees (when fees go up) even if I don't use Binance. All of this makes me avoid Binance whenever I can Just like Bitpay for instance, which (apart from KYC requirements) charges users a consolidation fee that's much higher than needed.

The users are paying 0.0005BTC per withdrawal. Granted that includes the fees from moving the deposits around, I would assume that the first course of action is for them to reduce the withdrawal fees for the user. Even if they decrease the fees that they are going to use, users are going to complain that they are skimping on the fees.

How ever much they spend isn't any of our business; it affects their profit margin and screws their users over. Them adding additional TXes into the mix doesn't necessarily bode well for the rest of us, there is another transaction to compete with the rest of the network. Even if they were to pay the high fees, it doesn't necessarily affect the remainder of the user. Algorithms don't look at the average fees being paid, rather, they devise their estimates from the bulk of the fees that the network is paying through fee buckets. Having a fraction of the blocks being occupied by a few high fee-rate transactions isn't a problem for the rest of the network, as long as the bulk of the transactions are still paying a normal fee rate.

I mean they aren't wasting any money, the user foots the bill.

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.

Poorly implemented ones or those that don't know any better and has a fixed fee rate.
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.

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.

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.

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

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).

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?

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.


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.


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.


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

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.

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