Show Posts
-snip-
Well wouldn't this be essentially be robbing the miners who are mining on their pool? My understanding of a pool's relationship with the mining utilizating their pool is that the pool is to distribute all of the mining revenue (including tx fees) to all of the miners with the amounts being distributed being based on the payout method. Just because someone makes a mistake in creating a transaction does not mean that the miners are not entitled to all of their income.
Although it is very clear in this case that the size of the TX fee was a mistake, it is difficult to draw the line between TX fee that is intended to get the transaction confirmed quickly and an erroneous transaction. As per the Bitcoin protocol the transaction was valid so IMO the sender should bear the cost of their mistake, be held accountable, and learn their lesson.
Well wouldn't this be essentially be robbing the miners who are mining on their pool? My understanding of a pool's relationship with the mining utilizating their pool is that the pool is to distribute all of the mining revenue (including tx fees) to all of the miners with the amounts being distributed being based on the payout method. Just because someone makes a mistake in creating a transaction does not mean that the miners are not entitled to all of their income.
Although it is very clear in this case that the size of the TX fee was a mistake, it is difficult to draw the line between TX fee that is intended to get the transaction confirmed quickly and an erroneous transaction. As per the Bitcoin protocol the transaction was valid so IMO the sender should bear the cost of their mistake, be held accountable, and learn their lesson.
Firstly this was not an user mistake. The user in question "uncovered" a bug the worst way possible, by having to face its problematic issues. According to reddit they have been issued a 25 BTC bug bounty on top of the returned payment. It apparently was an overflow[1] in the BitGo API.
Most pools act in a similar fashion when a mistake happens and yes this happens quite often. Several times a year I think. This is probably something pools should have in their ToS if they have any. I think its the morally correct thing to do and returning the fee is an overall win for BinMain, just see the reactions in this thread and how it affected their public stance. Now imagine they would have kept the funds. I think its very likely that many miners would have changed the pool even though they profited from the "mistake".
[1] https://np.reddit.com/comments/33u8vq//cqofrit
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.
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).
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.
also a lot of the people posting here don't actually have an option, they are just spamming their signatures
I thought that only admins had access to IP logs. Nevertheless, I've never used his service. I don't know what the point behind this accusation is nor how he could back his claims. 
