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

[o_e_l_e_o]

If blacklisting pools own 95% of the total hashrate, they can simply reject the blocks mined by the 5% non-blacklisting pools too.

Also very true. We discussed this before when MARA pool were still mining their nonsense "OFAC compliant" blocks, although rejecting other blocks is a step above refusing to mine certain transactions.

We will have a hard fork, then? Or maybe even non-blacklisting pools will join the blacklisting pools and will add the new blocks to the longer chain?

It depends, I think, on why the transactions are being blacklisted and the percentage of hash power which is doing the blacklisting. 51% blacklisting because of government rules? Then I would suspect a chain split. 95% blacklisting? The remaining 5% will almost certainly fall in line, since the minority chain they are mining will rapidly lose value, and with it, their incentive to keep mining it. However, the day when the network starts unanimously deciding to blacklist certain transactions permanently, is the day bitcoin is no longer a peer to peer currency without any trusted third parties. Let's hope it never comes to that.

[d5000]

As far as I am aware, blacklisting pools make up a much smaller percentage of the hashrate than that. [50-60%]

As far as I remember, Schnelli confirmed blacklisting only for Bitmain pools, which make up ~20% of the current hashrate, but said it was due to requests of the government. So it may apply to all China-based pools, thus my 50-60% estimation. This percentage may however have declined due to the miner flight out of China (after all, chinese mining farms tend to use a chinese pool, too, or to be directly controlled by Bitmain etc.).

And even if we reached the point of 95% as you suggest, then the logical option for such blacklisted users is to simply enable RBF and broadcast at a fee within 1 vMB of the tip.

If they have the time and tranquility to stay rational. They may be on a hurry, and in the case of bigger thefts, maybe not having even reliable (and safe/private!) Internet connection because they're hiding somewhere. Again, the high fees may be avoidable for them, but I could perfectly understand if they chose a significantly higher fee than normal as consequence of their sense of urgency or panic to get their txes included as fast as possible. this does of course not mean that I'm in favour of any kind of criminal activity ...

If blacklisting pools own 95% of the total hashrate, they can simply reject the blocks mined by the 5% non-blacklisting pools too.

This is of course possible in a "dystopian" scenario where blacklisting pools form a cartel and only accept blocks of their peers. I think however miners and pool operators would like to avoid that unless their governments explicitly required it, and even moving to other countries before taking that extreme measure, because this would eliminate the "uncensorable" attribute Bitcoin benefits from, and thus, probably would have severe consequences for the Bitcoin price (and thus their own business model).

[PrimeNumber7]

But as I wrote in the second paragraph, I don't believe we have this situation currently, blacklisting pools may make up perhaps 50-60% of the hashrate. Instead it could be a mix of high margins (of the criminal activity) and a sense of panic/urgence.

As far as I am aware, blacklisting pools make up a much smaller percentage of the hashrate than that. And even if we reached the point of 95% as you suggest, then the logical option for such blacklisted users is to simply enable RBF and broadcast at a fee within 1 vMB of the tip. If they don't get confirmed for several blocks and the fees change markedly, they can bump their fee with RBF. There is no need for them to be paying ridiculously high fees.

Based on ds5000's post, and based on known criminal uses for bitcoin, I would think the blacklists probably relate to addresses that often receive coin via malware, meaning that criminals try to infect others' machines with malware that will send coin secured by any private keys it finds to address 3xxx...x, and 3xxx...x will be the blacklisted address. From the point of view from the malware creates, they would not want to use RBF transactions so it would be more difficult for the legitimate owner of the coin being stolen to create a competing transaction that would prevent the loss of their coin.

To get this thread back on topic, I would point out that block 688970 was mined by the binance pool, and the transactions paying crazy fees are likely associated with binance. I might suggest this means that binance was testing their pool software and did not effectively actually pay 2200 sat/vByte.

[pooya87]

As far as I remember, Schnelli confirmed blacklisting only for Bitmain pools,

Is there any proof of this I can study. For example what were the transactions they rejected why and who picked them up?

This is of course possible in a "dystopian" scenario where blacklisting pools form a cartel and only accept blocks of their peers. I think however miners and pool operators would like to avoid that unless their governments explicitly required it, and even moving to other countries before taking that extreme measure, because this would eliminate the "uncensorable" attribute Bitcoin benefits from, and thus, probably would have severe consequences for the Bitcoin price (and thus their own business model).

It won't just be the "price consequences" for their business, if majority of hashrate try to maliciously attack bitcoin (which censoring transactions is an example) either bitcoin dies or the community takes drastic measures such as a hard fork to brick their ASICs overnight.

[o_e_l_e_o]

As far as I remember, Schnelli confirmed blacklisting only for Bitmain pools, which make up ~20% of the current hashrate, but said it was due to requests of the government. So it may apply to all China-based pools, thus my 50-60% estimation.

In which case, miners leaving China may be an even better thing for bitcoin than expected. Let's hope they don't all come over here and then get hit with even more ridiculous requirements like the ones OFAC wanted to enforce.

Are there any data regarding why transactions were being blacklisted or the criteria which were being used?

meaning that criminals try to infect others' machines with malware that will send coin secured by any private keys it finds to address 3xxx...x, and 3xxx...x will be the blacklisted address.

This would be fairly trivial for a scammer to circumvent. The Electrum malware, for example, could simply be updated every day to use a different address, just as they were constantly updating the web address which was displayed in the malicious message they sent to users. They could have the malware connect to a server and fetch a brand new address every time.

Still, I take your point that scammers will use a huge fee with RBF disabled to ensure that their stolen funds make it to their wallet ASAP with minimal chance of intervention from the owner of the coins. We've got to assume that such transactions are very much in the minority though, and do not explain the vast numbers of grossly overpaying transactions we see.

[PrimeNumber7]

meaning that criminals try to infect others' machines with malware that will send coin secured by any private keys it finds to address 3xxx...x, and 3xxx...x will be the blacklisted address.

This would be fairly trivial for a scammer to circumvent. The Electrum malware, for example, could simply be updated every day to use a different address, just as they were constantly updating the web address which was displayed in the malicious message they sent to users. They could have the malware connect to a server and fetch a brand new address every time.

Still, I take your point that scammers will use a huge fee with RBF disabled to ensure that their stolen funds make it to their wallet ASAP with minimal chance of intervention from the owner of the coins. We've got to assume that such transactions are very much in the minority though, and do not explain the vast numbers of grossly overpaying transactions we see.

Once the government gets a single copy of malware, they can blacklist the address the malware is sending coin to. If the malware were to update the address based on the date, the government could simply infect a decoy computers that have system dates in the future. If the malware were to query a server with the address to send coin to, the government could use a decoy computer to learn the address that coin should be sent to. The latter is less ideal for attackers because it will increase the time it takes to steal coin, and makes it more likely that countermeasures will detect malicious activity, and cutoff internet access to the infected machine.

All of the above is hypothetical and is likely not the reason for the transactions noted in the OP. The transactions in question are almost certainly being paid to the pool operator. This could be described as similar to someone taking money out of their right pocket and into their left pocket. There have been discussions in the past about miners taking payment in order to confirm a transaction that would not otherwise normally get confirmed, but I don't think there have been discussions where high transaction volume businesses receive payments for providing high transaction fee transactions.

[o_e_l_e_o]

The transactions in question are almost certainly being paid to the pool operator. This could be described as similar to someone taking money out of their right pocket and into their left pocket.

I'm not sure this is necessarily the case.

Take a look at the following address, for example: 1NDyJtNTjmwk5xPNhjgAMu4HDHigtobu1s

We know this address belongs to Binance, as they stated in this tweet: https://twitter.com/binance/status/961666467325358081

Now, if we look at the transactions out of this address over the last several hours, we see they all pay around 100 sats/vbyte when 2 sats/vbyte would have been sufficient, they are being mined in almost every block regardless of the pool finding those blocks, and there are a number of unconfirmed ones visible, meaning they are obviously being broadcast normally. So these transactions at least are just Binance needlessly pushing the fees up. I have no doubt there are a handful of transactions being paid to their own pool as you state, but I think such transactions are very much in the minority.

[BrewMaster]

I can assume that among those who pay groundlessly big fee for their transactions are  those people who sporadically  use ^coinb.in This wallet  requires some preliminary knowledge on the setting correct change address/es and amount of BTC to be send there. If all of that were not set properly all transaction change would go to  miners as their reward.

coinb.in is more like a web tool than a bitcoin wallet though and it demands a certain level of advanced users who pay more attention to what they pay as fee in their transactions. besides i don't think that many people are using this tool to begin with.

[DaveF]

I made a comment elsewhere but it seems to be valid that it looks like there are some wallets that are responding poorly to other high fees.
Last night when the mempool was almost empty there were transactions coming in that were 1 or 2 sat/byte. Once there were a few transactions that had a fee higher then the needed one the fees started to go up a bit closer to 4+ sat/byte. Even though the mempool was empty.

It was almost like the wallet was taking an average or something of what was in the block instead of looking at the fees.
Could be a bunch of lazy programming. Almost like adding the highest 10 fees that should you see going into the next block and add them to the lowest 10 fees you see going into the next block and divide by 20.

-Dave

[BrewMaster]

It was almost like the wallet was taking an average or something of what was in the block instead of looking at the fees.

i remember this a couple of years ago when some people were actually discussing how to implement fee estimation based on the last block that was mined. it was based on the average fee that the block had, like saying min fee is the minimum fee in that block and average is the median fee, etc.
but i don't think we can make a conclusion that this is the case with the transactions you saw because it may easily be something like a gambling site paying its gamblers as they cash out with a higher fee.

[ranochigo]

It was almost like the wallet was taking an average or something of what was in the block instead of looking at the fees.
Could be a bunch of lazy programming. Almost like adding the highest 10 fees that should you see going into the next block and add them to the lowest 10 fees you see going into the next block and divide by 20.

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.

i remember this a couple of years ago when some people were actually discussing how to implement fee estimation based on the last block that was mined. it was based on the average fee that the block had, like saying min fee is the minimum fee in that block and average is the median fee, etc.
but i don't think we can make a conclusion that this is the case with the transactions you saw because it may easily be something like a gambling site paying its gamblers as they cash out with a higher fee.

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.

[d5000]

Is there any proof of this I can study. For example what were the transactions they rejected why and who picked them up?

Are there any data regarding why transactions were being blacklisted or the criteria which were being used?

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.

Still, I take your point that scammers will use a huge fee with RBF disabled to ensure that their stolen funds make it to their wallet ASAP with minimal chance of intervention from the owner of the coins. We've got to assume that such transactions are very much in the minority though, and do not explain the vast numbers of grossly overpaying transactions we see.

Agree here.

[o_e_l_e_o]

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.

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.

[ranochigo]

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

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.

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.

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.

[o_e_l_e_o]

They know users won't want to wait for a few hours or more than a block or two.

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.

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.

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.

[BlackHatCoiner]

They can probably reduce the fees even more, or introduce a variable fee structure. Probably won't be happening though.

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

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

[ranochigo]

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'm almost certain they use Bech32 for deposits.

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

For Bitcoin withdrawal only.

[o_e_l_e_o]

I'm almost certain they use Bech32 for deposits.

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.

[DaveF]

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

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

[ranochigo]

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