Fee per byte is high but not that high enough but since there are a lot of inputs, the fee got increased significantly as you can see the size of the tx is 111713 bytes in total. However, I think it was a wrong fee estimation by the client they used.
I'm not 100 % clear how some wallets are choosing the fee they advise you to take for slow / standard / fast transfer.
But imagine you can "hack" the provider these wallets use for these propositions. At some point users are going to forget checking, and I guess some exchanges probably make this choice automated instead of having manual limits set.
Hard lesson learned for someone.
i am always skeptical about these cases being a "mistake". all wallets that i have seen already have a good way of warning the user of "absurdly high fees" to prevent mistakes like this one. they look more like bribes to miners or possibly even a money laundry case although a pretty bad one at that.
I'm too. I'd suppose we are going to know soon enough if someone kindly asks the miner to return those fees. At least on the some occasions they were mistakes on eth since people asked to return the payout...
He might just be wanting to consolidate inputs...
I'm not all to familiar with how fees are setup in clients, and I usually don't care setting a higher fee, but on this size would it be possible the user was trying to put a decimal fee and confuses the . and , in his client?
If anyone knows here if setting a decimal fee is even possible? (I obviously know you can't divide a sat, but if your tx is 10 vbyte, and you set a 2,5 sat/vbyte fee, that would make a 25 sat fee, of course for it to work there needs to be some rounding somewhere).