Bitcoin client rounding up all TX fees to .01!

[makomk]

Looks like you somehow spent a coin with 0 confirmations, which is why you got hit with a fee. Though why it was 0.0055 instead of 0.0005 is a problem.

The previous transaction is kind of odd though; I don't think that it should have had a fee at all.

Have you tried setting the transaction fee to 0?

Won't help. As I said earlier, if the change from a Bitcoin transaction would've been less than 0.01 BTC, it's automatically and silently spent as a fee rather than returned in order to reduce the accumulation of "bit dust". The first transaction presumably incurred a 0.0005 fee due the zero-confirmation 0.01 BTC input, but the client then chose to pay the total amount with a 0.01 BTC input and a 0.0055 input, leaving 0.0050 BTC of change which was too small to return and got thrown away as a fee. The second had 0.0115 BTC in and 0.01 BTC out, leaving 0.0015 BTC of change which is again too small and gets converted to a fee.

There's no way to disable this.

[1714146195]

1714146195

[1714146195]

1714146195

[1714146195]

1714146195

[1714146195]

1714146195

[1714146195]

1714146195

[Man From The Future]

Looks like you somehow spent a coin with 0 confirmations, which is why you got hit with a fee. Though why it was 0.0055 instead of 0.0005 is a problem.

The previous transaction is kind of odd though; I don't think that it should have had a fee at all.

Have you tried setting the transaction fee to 0?

Won't help. As I said earlier, if the change from a Bitcoin transaction would've been less than 0.01 BTC, it's automatically and silently spent as a fee rather than returned in order to reduce the accumulation of "bit dust". The first transaction presumably incurred a 0.0005 fee due the zero-confirmation 0.01 BTC input, but the client then chose to pay the total amount with a 0.01 BTC input and a 0.0055 input, leaving 0.0050 BTC of change which was too small to return and got thrown away as a fee. The second had 0.0115 BTC in and 0.01 BTC out, leaving 0.0015 BTC of change which is again too small and gets converted to a fee.

There's no way to disable this.

This should be changed

[Gabi]

It should definitely be changed

[ItsASpork]

Who's genius idea was this? I hate to be one of those guys, but how can we expect the masses to adopt Bitcoin when the client can't even charge a reliable fee?

[jackjack]

I experienced that in namecoin yesterday but didn't ask yet to the dev
Thanks OP for pointing it out

And nothing about that written in the FAQ or settings dialog...

[BkkCoins]

+1 for changing this.

As the value of BitCoins goes up this idea of "bitdust" is just robbery. The transaction has to balance it's own books to the parties involved regardless of current value. The fact they arbitrarily decide to do this gives me less confidence in BitCoins and the people making these decisions.

[Gabi]

Maybe if we put up a 2000 or 3000 btc bounty someone will fix this...

[jackjack]

I'm currently trying to fix that in my fork

[cepler]

+1 for changing this.

As the value of BitCoins goes up this idea of "bitdust" is just robbery. The transaction has to balance it's own books to the parties involved regardless of current value. The fact they arbitrarily decide to do this gives me less confidence in BitCoins and the people making these decisions.

+5000

If I tried to explain how all the fees worked in this thing to a newcomer they would look at me and yell scam!

The client should clearly present exactly all fees with details as to why they are being charged.  Not doing this is simply unacceptable!

[jackjack]

On my fork: with 0.5586 BTC on my account, i sent 0.55, the client asked 0.001 for fees, and 0.551 were debited, leaving 0.0076 BTC
Looks like I kept my bitdust (well, 'broadcasted through 16 nodes' though)

[wallet.dat]

Crap, I just checked and I had inadvertently set my transaction fee to .10 lol

[error]

I'm currently trying to fix that in my fork

Send a pull request, please.

[gmaxwell]

I'm currently trying to fix that in my fork

Send a pull request, please.

Or don't.  I don't think this behavior should change, though perhaps the cutoff point should be reduced to the smallest fee.

Every single full node in the network must track and check all open outputs for all time.  The network should resist the accumulation of tiny outputs because allowing them increases the burden on the network substantially.

At some point it may become necessary to inhibit txn with very small outputs, in order to keep things expensive for the people trying to store childporn in the blockchain... so best to not increase the expectations now.

 

[BkkCoins]

Or don't.  I don't think this behavior should change, though perhaps the cutoff point should be reduced to the smallest fee.

Every single full node in the network must track and check all open outputs for all time.  The network should resist the accumulation of tiny outputs because allowing them increases the burden on the network substantially.

At some point it may become necessary to inhibit txn with very small outputs, in order to keep things expensive for the people trying to store childporn in the blockchain... so best to not increase the expectations now.

 

Seems to me the devs are smart enough to figure out a way that doesn't involve secretly stealing users change, no matter how small.

Couldn't they use some client setting for a "change address" to accumulate change into? Or something similar, as I'm not sure of the internal client mechanics. Or perhaps every X number of transactions the client would have to create a "payment to yourself" to combine bitdust.

I just think that if BitCoin wants wide acceptance these tricky little behaviors will have to be more transparent and simpler to understand. Disappearing fractions of coins will create a shitstorm of bad press, and when proponents commonly talk of 8 digit divisibility and free transactions it's very misleading when amounts under 2 digits can "randomly" disappear (which is how this looks to typical users).

[gmaxwell]

Seems to me the devs are smart enough to figure out a way that doesn't involve secretly stealing users change, no matter how small.

Couldn't they use some client setting for a "change address" to accumulate change into? Or something similar, as I'm not sure of the internal client mechanics. Or perhaps every X number of transactions the client would have to create a "payment to yourself" to combine bitdust.

I just think that if BitCoin wants wide acceptance these tricky little behaviors will have to be more transparent and simpler to understand. Disappearing fractions of coins will create a shitstorm of bad press, and when proponents commonly talk of 8 digit divisibility and free transactions it's very misleading when amounts under 2 digits can "randomly" disappear (which is how this looks to typical users).

A "change address" would do nothing useful except compromise privacy— bitcoin tracks transactions not balances.

You're seriously overblowing "a shitstorm of bad press". Did you know that some large US chains systematically incorrectly round sales tax? E.g. they always round up, and due to some strange coincidence their prices are such that they almost always overcharge the customer by .9 cents?  Yet it's never made the news.

In any case, one way of dealing with this would be for the coin selection logic to add more input to prevent the change from being smaller than 0.01, sort of like your "payment to yourself" but happening at the time of the transaction to prevent the dust from being created in the first place. Of course, this would require you to have extra inputs in your wallet to begin with, and I'd be willing to be that anyone noticing bitdust lost is running an empty wallet.

E.g.

(0) use the fewest inputs to sum to the output value (plus any desired or required tx fee) exactly
if that fails
(1) use the smallest inputs that sum to at least output+fees+0.01
if that fails
(2) use the smallest inputs that sum to outputs+fees and give
the dust up as additional fees

One of the crappy things about this however, is that the dust is still bad for your privacy— it tags which side of the txn was the change quite distinctly. E.g. if you have input 3.0123456, and you redeem it into {1.0, 2.0123456} then I know with pretty high confidence that you just spent 1 BTC and that the address that 2.0123456 went to was also yours.  This is a reason that it's good to avoid getting dusty inputs in your wallet in the first place.  It's like a marked bill.

[Miner-TE]

I was showing a friend how to use the client and sent myself 1.35839215, Only to get back 1.35 and pay 0.00839215 in fees.  Not cool.

Version 0.3.34-beta

http://blockexplorer.com/tx/8be5e605cfc3e53f3f2d47dbfe78aaec5f1722049aede8e737e4c6b04aaddb83

[BkkCoins]

I don't understand how the devs can't see that executing a transaction without telling the user the real actual cost of the fees is not a serious issue.

If BitCoin becomes much more widely used then I could see some enterprising lawyer filing a class action suit against the developers. How many of them are miners or have miner acquaintances that materially gain from bitdust? Does the client ever warn users that random small amounts will be stolen from their transactions?

Seriously, a national news story on this would likely end any future of BitCoins in many peoples eyes. I don't think that's much of an exaggeration. It may not be totally rational due to the small values involved but I just don't think most people would be happy with it nonetheless.

It's devious to claim 8 digit divisibility and people expect that accuracy and then trim off anything less than .01.

.01 is about $0.14, which is about half of a minimal Paypal fee - and this may just be randomly taken as bitdust...?

(someone should write a util that scans the block chain and sees how much bitdust has been swept into fees in total)

[Pieter Wuille]

I believed the bug reported here was already fixed, but this thread made me suspicious.

It seems it was indeed fixed here, but lost in a code reorganization somewhat later (here).

My apologies to those who have lost coins - the issue will be fixed in the next release.

[gmaxwell]

It's devious to claim 8 digit divisibility and people expect that accuracy and then trim off anything less than .01.

You're coming off as hysterical— and also factually inaccurate. The behavior hasn't be to "trim off anything less than .01", it's to not take change when the change was _entirely_ less than 0.01.

Rather than demonstrating to others the urgency of your point, as you no doubt intend, it may have the opposite effect.

Rest assured that anyone worth convincing already takes things seriously in general, adding a bunch of dire warnings is not helpful for your cause.