-snip-
Well the term "user" is being used in respect to to the fact that someone somehow caused a tx to be signed and broadcast that included such large fee. The fact that a program had a "bug" verses a user erroneously somehow manually created such transaction is a moot point IMO.
I wouldnt call that a moot point. Consider you have some sort of cold storrage and a programm to wipe everything on there to an address you provided. The programm returns:
k, did it, here is the transaction for you to broadcast. Unless you suspect something to go wrong you have no reason to manually decode the raw transaction (or get another tool for it) to make sure its what you want. Whether it was a user misstake for not checking something that is displayed on screen or a bug that is not something the user can check is a big difference IMHO.
There are legit reasons why someone would want to include a large (although probably not this large) tx fee when a large tx fee is not necessary per current standards, examples would include when a loan is due by a certain block number, there is an unusually large number of unconfirmed txs in the mempool, an usually long time between blocks at a given point in time (this would go hand in hand with a large number of unconfirmed txs), your private keys are compromised by someone with a large amount of mining power (even if nodes would reject a double spend tx, as long as the tx is unconfirmed they can include a double spend in a block they find), other miscellaneous reasons to want to double spend an unconfirmed tx among other reasons.
Granted, there are certainly cases where miners could reasonably argue that returning the fee is not an option. All incidents I am aware of had a fee way over 1 BTC though and that certainly is not a case of
I want the TX to be confirmed fast.I would agree that pools should include in their TOS that under a strict set of guidelines that an erroneous TX fee will be returned to the spender. I also agree that this positively affects bitmain's public reputation.
One addition problem that returning funds causes is that it is difficult to know where to return the funds to. I believe in this case there was only one output address (eg no change address) although most of the time this will not be the case (and in some cases there may be more then two outputs for a variety of reasons). Add this to the fact that the "sending" address cannot always be reasonably determined by looking at the blockchain, and even when you think you can accurately determine the "sending" address you will be incorrect (although I believe this to be very rare).
I agree a payout should never be done lightly and the person requesting a refund should at the very least be able to provide a signed message.
Above the above issues you have the fact that a "receiving" address would only benefit someone for a certain period of time. One example of this is bitmixer - I believe they only agree to forward funds to their customers that are received within a certain amount of time, and if a pool were to send funds after this time has expired then they might not receive benefit from funds being returned anyway.
While I think in the vast majority of cases it is appropriate to return excess funds that you were not owed, I think there are too many unknowns when dealing with a pool in this regard.
Agreed and this should be done by hand as well to avoid some of the problems you addressed.
I took a quick look into the AntPool board but I was unable to find a miner complain. IIRC the last incident was with GHash.io and they return the payment out of their own pocket. Thus the miners had a larger reward and the person got their high fee back.
Yup, that is indeed insane. That's why my paranoia is good in a way, because if I need to do a big transaction (and I wish I had that kind of money to worry about things like this) I would never send 100 BTC at once, but in batches, or at least do a initial small transaction to see that everything is in order.
But you would not have gotten the 25 bug bounty then
