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

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

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

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

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?

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

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.

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:

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?

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]

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

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

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.

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.

I'd have to say the fault partially lies with Binance. IIRC, binance used to offer legacy address by default, and the user can choose to use bc1 if they want. Not sure if this changed, so do CMIIW. There are no incentives for the user to be changing to bech32 addresses; you don't get any discount by doing so and most of the people who uses binance don't realize the full benefits of using Segwit nor do they really care about doing so. It'll inevitably result in a far greater percentage of users using legacy instead of bc1. 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).

There is still a number of users who uses Segwit: c68338dfc5ced3b876de31bacd3227404b88fb49f6a1fb020767f179c29ad946, for example but the ratio is far lower. Binance introduced Segwit really late as well, services like that are part of the problem, and they just won't change. Blockchain.info is another notable example.

Binance is not the worst offender by the way, Bitmex uses P2SH (with 3-of-4 MultiSig with uncompressed PKs). I don't think they have too significant of an impact, or at least I can't really tell without an extended observation. As with every exchange, if they aren't losing money, they're happy to just spend a little more to stick with whatever is working.

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.

Probably not, but you never know.

-Dave

A lot of their internal transactions all take place on legacy addresses. As I established above, 1NDyJtNTjmwk5xPNhjgAMu4HDHigtobu1s is their hot wallet addres. Take a look at the consolidation transactions just from the last few hours depositing coins in to this address:

https://mempool.space/tx/11fd262c9670bcea97cb58262ed0ed934fc88756b3ce9586c3cdf3df2cad75df
https://mempool.space/tx/39558624185310a16d3166574069dfe6105590fa37a3b9559331dea23fa2a5fc
https://mempool.space/tx/7d8b6e13039d3c5e0189fa2d82d57aa017ae91de3b7d4be2657147f1150949e6
https://mempool.space/tx/db4472426fe6e46f36aa6ee5db481595a848501cbb8313c3c001367d47e720bc

All of them are sweeping multiple legacy addresses in to their main legacy address from which withdrawals are processed.

So yeah, legacy transactions at way over the going fee rate. At least they batch their withdrawals, but Binance (and all exchanges) are responsible for a significant amount of mempool bloat.

I'm almost certain they use Bech32 for deposits.
For Bitcoin withdrawal only.

The first thing they should do is use Segwit Native instead. Can you imagine the amount of transactions they broadcast everyday? They'd save thousands of dollars. Still, Binance keeps the fame of the richest exchange.

I have never used Binance. Do they charge 50,000 sats for withdrawing or for just making a Bitcoin (on-chain) transaction?

Some users, sure, but there are a lot of times I am trading peer to peer that I will message the other party if I trust them and tell them to send with a small fee since I am in no hurry. I'm sure there will be plenty of Binance users who would happily wait a day or two for a withdrawal if it meant saving >95% of their fee.

I'd already be annoyed if I were a Binance user knowing they are charging me 50,000 sats per withdrawal and pocketing the majority of that as pure profit, even with the hyperinflated transaction fees they pay. Even if they leave all their withdrawal transactions at their flat 100 sats/vbyte fee, they should still be reducing the price they charge customers.

But even if they don't want to implement a better fee estimation algorithm, no reason they couldn't implement a "Fast/Average/Slow" withdrawal structure, with flat fees of (say) 100 sats/vbyte, 30 sats/vbyte, and 5 sats/vbyte, so users aren't left over paying so much and they don't fill the mempool with so many ridiculously unnecessary transactions.

In all fairness, they're not the only ones overpaying for their fees. Bitcoin Core's floating fees was going up to 80 sat/vbyte for a confirmation within 3 blocks if the user chose conservative mode. That has a fairly high confidence level though, so the fees will always be inflated.
They know users won't want to wait for a few hours or more than a block or two. CPFP is probably quite easy but as a user, I'll be quite unhappy to be waiting for an extended period of time after paying 0.0005BTC per withdrawal and they're choosing a very low fee, given that withdrawals are already batched. They can probably reduce the fees even more, or introduce a variable fee structure. Probably won't be happening though.

True, and I can understand why centralized exchanges and other such services overpay their withdrawal transactions, but the amount they overpay is often ridiculous. Sure, if the average fees are bouncing around 20-30 sats/vbyte in each block, then 100 sats/vbyte is not an unreasonable fee to pretty much guarantee confirmation in the next block. But when the mempool is emptying with every block, and 1 sat/vbyte transactions are being entirely cleared in each block for several days in a row, to still pay 100 sats/vbyte is just plain stupid. I refuse to believe that Binance can't come up with a better algorithm than "Pay 100 sats/vbyte for everything until it gets really bad".

RBF may be technically challenging, but CPFP is easy for such transactions. Binance could cut all their fees in half right now and save thousands of dollars worth of bitcoin a day, and still perform CPFP with the change output from their withdrawal transactions in the very rare case that 50 sats/vbyte doesn't confirm within a few hours when the mempool is currently empty.

Not that I know. It was supposedly only affecting few addresses, but I think they won't disclose which, and which transactions were rejected. There is also generally surprisingly few information about Bitmain's blacklisting behavior in the Web, if I'm not missing something.

Agree here.

Services are almost always paying extra fees for their transactions. It is far easier to pay more and avoid any problems if the transaction stays unconfirmed for an extended period of time. After all, the users are footing the bill, no harm done to them. RBF is not possible with withdrawal transactions, not technically, just that it'll cause even more confusion.

Bitcoin Core groups the transactions from the mempool into a bucket, and tracks how long it takes for them to be included in a block. It lags behind the actual situation for me; predicting 10sat/vbyte for the next block with 2sat/vbyte being 1vMB from the tip. They tend to be more conservative with the fees, but there is a higher confidence for it to be included within the X blocks.

If pool operator include their own transaction to the mined block, there's no reason to intentionally set high transaction fee (assuming the operator doesn't have other motive).


Additionally, on page to create transaction (https://coinb.in/#newTransaction), there's input box to show the transaction fee.