Author

Topic: Accidental Mining Fees (Read 530 times)

legendary
Activity: 2912
Merit: 6403
Blackjack.fun
July 10, 2017, 10:45:19 AM
#18
“Recently, BTC.com mined a block containing a transaction that carried a staggering 80BTC fee,” explains the mining pool’s blog post. “Obviously, something’s up with that. All things said and done; the correct fee should have been approximately 2 BTC.”

So the correct fee for the transaction should be 2 btc?
I understand the user was drunk but so was the guy from btc.com and the one that wrote the article?

But as usual all the fault belongs to the monkey behind the wallet.
This is how businesses go bankrupt.

legendary
Activity: 1904
Merit: 1074
July 10, 2017, 10:16:38 AM
#17
Nope, in my opinion miners should send back the coins without even asking if it was a mistake. {because it is obvious} A standard reward

percentage must be determined by the community in advance. {say 5% of the total amount} to incentivise the return of those coins that are

send with wrong fees. If someone pick up your lost wallet and returns it to you, you will reward them for their honesty. { Well, I would }  Wink
legendary
Activity: 1512
Merit: 1012
July 10, 2017, 09:13:50 AM
#16
A custom client probably caused some of these mistakes. It's also not impossible that unclaimed fees like these were donations. As far as reclaims go, it's up to the pool. Many have come forward and sent back the money and I think that's really good.
legendary
Activity: 3584
Merit: 5248
https://merel.mobi => buy facemasks with BTC/LTC
July 10, 2017, 05:11:21 AM
#15
....performing a  successful double spend is not at all easy.

Creating a double spend is not hard at all ...

i said performing a successful double spend not  creating one.
it is like saying i can easily use a stolen credit card to withdraw money from an ATM.
yeah you can do that but is it easy to perform and not get caught?

I'd have to partially agree with you... I did indeed mess up and mixed up performing and creating... However, i'd still have to say that performing a double spend is not that hard to do either (granted, it's harder than creating one, but it's still not impossible to do). A lot depends on the timing and the specific parameters used for the transaction.

It would not be hard at all to write a script that creates a transaction with a very low fee and only broadcast this transaction to a very limited amount of nodes, then waits for the scammer's input before creating and broadcasting a transaction with a much higher fee whose outputs could only be spent by a signature from a private key the scammer controlls. (so the scammer would buy a hamburger, starts up his payment program that generates a low-fee transaction and broadcasts it as a payment. As soon as he walks out, he gives input to his script so it double spends the inputs in a high-fee transaction but the output is now spendable by the hacker instead of the burger joint).

A while back, when the mempool was exploding and the fees were astronomical, i've successfully double spent the inputs of many stuck transactions while i was helping people that didn't add sufficient fees. Granted, right now a script as described above might be less succesfull, but at times of mempool congestion, i know from experience you should be able to scam most companies that accept 0 conf transactions. This is why i would advise anybody to wait for at least 1 confirmation (even for micro payments).
legendary
Activity: 3472
Merit: 10611
July 10, 2017, 05:05:35 AM
#14
most of the times this is simply a mistake caused by the wallet (aka a bug) or in some cases it is caused by the modified code of some service that is doing payments and stuff like that.

an example of the bugs that i mentioned is the recently high fees suggested by Trezor wallet and the wallet was suggesting fees like 0.6BTC/kbyte!
https://bitcointalksearch.org/topic/warning-if-you-are-using-trezor-double-check-your-fees-before-sending-1921506
full member
Activity: 254
Merit: 100
July 10, 2017, 05:01:38 AM
#13
It happens when (i) if you're using a stupid wallet that never warned its user when sending with too low and too high transaction fee. (ii) if you're too idiot that never notice those mistake and you have to double check or even triple check before clicking the send button.

Exactly! If you are doing transaction specially big amount of money its a requirement to double check everything before clicking the OK/SEND or whatever it is so that you will not have problem after completing it.
hero member
Activity: 2926
Merit: 722
DGbet.fun - Crypto Sportsbook
July 10, 2017, 04:54:31 AM
#12
1. Do you think a sender can really make such a mistake or there is someone who just deliberately and randomly decided to donate btc to any miner that ends up mining their block?

If there are some people who did this mistake then they do really made the mistake its not random but mostly on users error which he don't even double check when setting up a fee and also the factor that affects on this kind of situation is on what kind of wallet you do use because there are wallets doesn't set up automatically.

2. If this kind of mistakes happen, do you think there should be a reclaim or we just assume it is the miner's luck?

I can say that lucky for that user that miner did return his money and they will surely do such thing because they don't want to ruin their reputation on that amount and also this really serves as a lesson learned actually.
legendary
Activity: 1134
Merit: 1010
BTC to the moon is inevitable...
July 10, 2017, 04:45:29 AM
#11
....performing a  successful double spend is not at all easy.

Creating a double spend is not hard at all ...
[/quote]

i said performing a successful double spend not  creating one.
it is like saying i can easily use a stolen credit card to withdraw money from an ATM.
yeah you can do that but is it easy to perform and not get caught?
full member
Activity: 152
Merit: 100
July 10, 2017, 04:43:17 AM
#10
All must have felt unintentional or unexpected acts, if you use a dumb wallet that never warns its users when sending with too low and too high a transaction fee.
legendary
Activity: 3584
Merit: 5248
https://merel.mobi => buy facemasks with BTC/LTC
July 10, 2017, 04:11:06 AM
#9
Also, accepting 0 conf transactions would be problematic, even for a hamburger joint. There's just to much risk that the sender will either double spend the inputs, or that the fees were so  low the transaction never makes it into a block...

you know performing a  successful double spend is not at all easy. and also as i have said many times, there are easy ways of figuring out the risks of a payment.
i have spoken with a couple of services, and they usually use the blockcypher's confidence factor and it has a pretty good description in its documents. it easily and with a good accuracy of >99% tells the businesses if there is a risk or not and how much that risk is.

and for example in case the fees were small the "hamburger joint" can simply deny the payment and ask the payer to increase it.

Creating a double spend is not hard at all (with the defenition of double spent = creating a second transaction that uses the same unspent outputs as an input input as an initial transaction that is still unconfirmed)... I could do it in just a couple of seconds, so anybody abusing the system should be able to do this to.
The big problem is getting a double spending transaction propagated to the network... As soon as the initial transaction is in the node's mempool, they'll usually reject the double spending transaction.
That being said, if you're an attacker, and you're fast/lucky enough, such an attack isn't something magical, it is, in fact, really easy to do...

For example, i created two UNSIGNED transactions:
Code:
0100000005b38c1074e151c18038c13677e71b8254d6021e02ab8e2fde21291062fcaa7181000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffffc214582b58a0313381388bab62dc5a74ff700f46eb8697be88433aa0000459d9000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffffd93201befe97edeb64229d02e4c9fdc1d510bb54ba775a2f1292b37bad6391a2060000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffff53da8f5f0cc6b342eccec69bed3a8610d057e3cfc798c322764dd11796932e52010000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffff020680fa2b57eb61703a88bebe8240b8cc11d7e369e297c7b181ae5efd743b59000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffff017f70c900000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388ac00000000

Code:
0100000005b38c1074e151c18038c13677e71b8254d6021e02ab8e2fde21291062fcaa7181000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffffc214582b58a0313381388bab62dc5a74ff700f46eb8697be88433aa0000459d9000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffffd93201befe97edeb64229d02e4c9fdc1d510bb54ba775a2f1292b37bad6391a2060000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffff53da8f5f0cc6b342eccec69bed3a8610d057e3cfc798c322764dd11796932e52010000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffff020680fa2b57eb61703a88bebe8240b8cc11d7e369e297c7b181ae5efd743b59000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffff01e0e9c700000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388ac00000000

both spend the same unspent outputs, both have a completely different fee (one will probably never confirm, the other one will be in one of the first mined blocks). If i would sign and broadcast the first one for paying for a hamburger, and as soon as i had the goods in hand sign and broadcast the second one (but probably make the output spendable by my own address), the hamberger joint would have a reasonable chance of being stuck with a cancelled transaction... If i was doing this every time i bought a burger, i'm pretty sure i would be able to steal from them several times...
legendary
Activity: 1134
Merit: 1010
BTC to the moon is inevitable...
July 10, 2017, 03:50:00 AM
#8
Also, accepting 0 conf transactions would be problematic, even for a hamburger joint. There's just to much risk that the sender will either double spend the inputs, or that the fees were so  low the transaction never makes it into a block...

you know performing a  successful double spend is not at all easy. and also as i have said many times, there are easy ways of figuring out the risks of a payment.
i have spoken with a couple of services, and they usually use the blockcypher's confidence factor and it has a pretty good description in its documents. it easily and with a good accuracy of >99% tells the businesses if there is a risk or not and how much that risk is.

and for example in case the fees were small the "hamburger joint" can simply deny the payment and ask the payer to increase it.
hero member
Activity: 1232
Merit: 683
Tontogether | Save Smart & Win Big
July 10, 2017, 02:26:08 AM
#7
I just read in this article how someone made a transaction including 80btc as the transaction fee which eventually btc.com mined the block. That is an outrageous fee I must say and how on earth would someone make such a mistake. Such a thing was also reported to have happen with even a larger fee which no one came back to claim. The questions that arose in my mind are;
1. Do you think a sender can really make such a mistake or there is someone who just deliberately and randomly want so donate btc to any miner that ends up mining their block?
2. If this kind mistakes happen, do you think there should be a reclaim or we just assume it is the miner's luck?

What are your thoughts?

Here is the link to the article:
https://news.bitcoin.com/mining-pool-btc-com-80-btc-fee-refund/

Oh god, that is so much lost from that poor guy. I don't think it would be possivle for refunds to be made though. One of the features of bitcoin, is not chargeback scams and if this guy got a refund, who is to say that the guy who buys something legitametly doesn't get  refund and scams his/hers other trading partner. It's hard to make exceptions or be nice to someone in particular nowadays, since everyone has ulterior motives and will try and get free money also. The miners must be rejoicing and whoever mined it would be so happy.   
legendary
Activity: 1470
Merit: 1079
July 10, 2017, 01:21:20 AM
#6
I just read in this article how someone made a transaction including 80btc as the transaction fee which eventually btc.com mined the block. That is an outrageous fee I must say and how on earth would someone make such a mistake. Such a thing was also reported to have happen with even a larger fee which no one came back to claim. The questions that arose in my mind are;
1. Do you think a sender can really make such a mistake or there is someone who just deliberately and randomly want so donate btc to any miner that ends up mining their block?
2. If this kind mistakes happen, do you think there should be a reclaim or we just assume it is the miner's luck?

What are your thoughts?

Here is the link to the article:
https://news.bitcoin.com/mining-pool-btc-com-80-btc-fee-refund/

1. It is possible if the sender is drunk or high on something Grin...We do messup with the keyboard sometimes. Not deliberately, btc.com pool mined it, no prediction on who the miner blocks it, just random, and the random person got lucky.

2. Bitcoin is no PayPal, you sent it, its gone, over. The miner or the recipient can easily get away with a transaction not meant to be theirs.

Quote
We’re not interested in making a quick buck, especially if it comes at the loss of another bitcoiner. That’s why we’re reaching out.

That is some good moral sense.
legendary
Activity: 3584
Merit: 5248
https://merel.mobi => buy facemasks with BTC/LTC
July 10, 2017, 01:16:45 AM
#5
A universal transaction system should be setup with preset transaction fees depending on priority of any given transaction.

For example, a fast food transaction is very low priority. It is generally under $20, and fast food companies do not mind waiting 24 hours for confirmation because they have lots of money and it is something they could handle, generally speaking.

However, other high priority transaction (thousands or millions of dollars) would get a universal "higher-priority" fee. Say, level 5/10 for $1,000 transaction and level 10/10 for $1,000,000+. A fast food transaction would be 0/10, meaning 0 confirmations necessary therefore extremely low fees.

Even 0.1% of a million dollar transaction = $1,000. With a $1,000 fee your confirmations will appear in no time.

For fast food, it could take 24, 48 hours or even longer. It really doesn't matter because the transactions are so insignificant people will not bother even trying to double spend.

Hope this make sense for you.

sure, but technically, the system is just not made to work like this. Nobody (not even the miner) cares if you transfer 1 million worth of BTC, or just 1 cent.... They care about the size of the transaction (in bytes) because the size of the block is limited, so they can only fit 1 Mb of transaction data in a single block.
The size of the transaction depends on the number of inputs and outputs, not on the amount of FIAT that was transferred.

Also, accepting 0 conf transactions would be problematic, even for a hamburger joint. There's just to much risk that the sender will either double spend the inputs, or that the fees were so  low the transaction never makes it into a block...
member
Activity: 84
Merit: 10
July 10, 2017, 01:07:25 AM
#4
A universal transaction system should be setup with preset transaction fees depending on priority of any given transaction.

For example, a fast food transaction is very low priority. It is generally under $20, and fast food companies do not mind waiting 24 hours for confirmation because they have lots of money and it is something they could handle, generally speaking.

However, other high priority transaction (thousands or millions of dollars) would get a universal "higher-priority" fee. Say, level 5/10 for $1,000 transaction and level 10/10 for $1,000,000+. A fast food transaction would be 0/10, meaning 0 confirmations necessary therefore extremely low fees.

Even 0.1% of a million dollar transaction = $1,000. With a $1,000 fee your confirmations will appear in no time.

For fast food, it could take 24, 48 hours or even longer. It really doesn't matter because the transactions are so insignificant people will not bother even trying to double spend.

Hope this make sense for you.
copper member
Activity: 2142
Merit: 1305
Limited in number. Limitless in potential.
July 10, 2017, 01:04:21 AM
#3
It happens when (i) if you're using a stupid wallet that never warned its user when sending with too low and too high transaction fee. (ii) if you're too idiot that never notice those mistake and you have to double check or even triple check before clicking the send button.
hero member
Activity: 798
Merit: 503
July 10, 2017, 01:01:18 AM
#2
Any refunds would be problematic and cause unnecessary trouble, so if this is an accident, then the poor guy can only blame his luck, while the miners can rejoice.

I like how the pools offers the refund back and I think this is a really kind thing to do so. Great to see humanity among our greed *cough cough*. Smiley However we should not expect such refunds to happen all the time and still be careful with what we are dealing with. Tongue
sr. member
Activity: 644
Merit: 299
July 10, 2017, 12:53:28 AM
#1
I just read in this article how someone made a btc transaction, including 80btc as the transaction fee which eventually btc.com mined the block. That is an outrageous fee I must say and how on earth would someone make such a mistake? Such a thing was also reported to have happened in the past with even a larger fee which no one came back to claim though the miners declared it up for whoever that made the transaction with proof to come and claim which btc.com is also doing presently with this 80btc.

The questions that arose in my mind are;
1. Do you think a sender can really make such a mistake or there is someone who just deliberately and randomly decided to donate btc to any miner that ends up mining their block?
2. If this kind of mistakes happen, do you think there should be a reclaim or we just assume it is the miner's luck?

What are your thoughts?

Here is the link to the article:
https://news.bitcoin.com/mining-pool-btc-com-80-btc-fee-refund/
Jump to: