Transaction fees magically appearing, how to account for them?

[Nefario]

I have set my client to pay 0.0 for transaction fees, and to not send amounts smaller than 1btc.

The only reason I'm doing this is to avoid transaction fees so I don't have to deal with them in my system accounts that's keeping track of a users balance.

However, when the user withdrew 9.99000001btc there was a fee of 0.01.

It's really f*cking up my accounting when bitcoind just takes fee's out, it wouldn't be a problem if there was an easy way to find out what the transaction fee was when the transaction happens.

So there seems to be no way to avoid transaction fees at all(I don't mind), is there a way to find out what fee is being paid when the transaction happens?

[1713300517]

1713300517

[1713300517]

1713300517

[1713300517]

1713300517

[1713300517]

1713300517

[1713300517]

1713300517

[1713300517]

1713300517

[Gavin Andresen]

The send RPC methods return a transaction id.

Pass the transaction id to the gettransaction RPC method, and it will give you details of the transaction, including what fees were paid.

[ribuck]

However, when the user withdrew 9.99000001btc there was a fee of 0.01.

So probably a 10BTC transaction was the input, and the change of 0.00999999 incurred the fee.

[Nefario]

However, when the user withdrew 9.99000001btc there was a fee of 0.01.

So probably a 10BTC transaction was the input, and the change of 0.00999999 incurred the fee.

Oh For F*cks sake(sorry, just pissed off at this gotcha).

gavinandresen, thanks for the details, I'll implement it that way.

[Gavin Andresen]

Oh, and what version of bitcoin are you running?  0.3.21 includes a patch from luke-jr that modifies the coin-selection algorithm to avoid sub-cent change when possible.

It will also help if you keep a good selection of 'old' coins in the shared wallet.

I agree that transaction fee accounting/handling needs improvement.

[error]

Considering that the fee is now quite expensive compared to what it has historically been, it really needs to be revisited.

[xf2_org]

Considering that the fee is now quite expensive compared to what it has historically been, it really needs to be revisited.

Already revisited, see this thread: http://bitcointalk.org/index.php?topic=7749.0

[sassame]

There's actually a small issue with this accounting algorithm - if we don't know the transaction fee before hand, we can't actually ensure the user's account has a large enough balance to cover the transaction.  If their account has 0.25 BTC, and they try to transfer out the entire amount, the merchant would be risking the transaction fee when they executed the transaction.  At .25 BTC it's not a big deal, but as the sums go up the risk increases substantially.

I looked at the code, and it seems pretty easy to write an RPC call "estimatetxfee".  Before I get too deep into doing any development work, is this a realistic approach, or would the chance of the fee changing (especially for larger transactions) make this worthless?  Would it be possible to calculate a maximum possible transaction fee for a given amount taking into account the coins currently in the wallet?

Thanks for any help!

[error]

The code to calculate the tx fee is already present in bitcoin (obviously) so wrapping an RPC call around it should be quite simple.

[Nefario]

The code to calculate the tx fee is already present in bitcoin (obviously) so wrapping an RPC call around it should be quite simple.

+1

[danglybits]

Would it not be better to make the transaction fee user-setable instead of "programmatically" set?  Have we not already established that these transactions are perfectly valid without a fee, they just may take longer to get processed.

This way the price discovery of the transaction fee is moved into the app developers instead of the Bitcoin source code.

[kseistrup]

The code to calculate the tx fee is already present in bitcoin (obviously) so wrapping an RPC call around it should be quite simple.

+1

+1

[Nefario]

Would it not be better to make the transaction fee user-setable instead of "programmatically" set?  Have we not already established that these transactions are perfectly valid without a fee, they just may take longer to get processed.

This way the price discovery of the transaction fee is moved into the app developers instead of the Bitcoin source code.

Yes you're right, but at the moment, right now, I would just like a simple way to to what the fee is before it's taken out.

[Gavin Andresen]

At .25 BTC it's not a big deal, but as the sums go up the risk increases substantially.

Huh?  That's backwards, transaction fees are smaller (as a percentage) if you're sending more BTC.  Number of bitcoins being sent doesn't matter, number of inputs and outputs to the transaction matters.

RE: estimating fees beforehand:  what is the use case where that is actually useful?  What do you want the user experience to be?
And what happens if the estimate turns out to be wrong?

[error]

The real fee problem is with small transactions (e.g. sending 0.01 BTC) where the fee is a rather large percentage of the amount being sent.

[Nefario]

At .25 BTC it's not a big deal, but as the sums go up the risk increases substantially.

RE: estimating fees beforehand:  what is the use case where that is actually useful?  What do you want the user experience to be?
And what happens if the estimate turns out to be wrong?

The use case is when processing a transaction for an account (of which there may be many), we need to know whether there is enough bitcoin in the account to cover the cost of the transaction and the fee, or what would be even better is if the fee is taken out of the amount sent.

This is to prevent accounts getting into negative balance, and being thrown out of balance with any other accounting data held in the system using bitcoin. It's really for accounting purposes.

If the estimate is wrong? I don't know, don't send?,

Should'nt we as the senders be able to decide what we're willing to pay for a transaction instead of it being taken from our wallets with nothing to be done about it after the fact?

This results in a real market for transaction fees, with bids and asks. The whole thing would then balance itself out, and people could decide on urgency vs. price.

But really I just want to know what the fee's going to be, right now I've got a dirty dirty workaround, that so far has been ok but isn't guaranteed in the future.

[sassame]

I added the functionality, and submitted a pull request: https://github.com/sassame/bitcoin/tree/estimatetxfee

Gavin, I understand your concern, but when thinking about the use case (specifically, checking during a transfer if there's enough bitcoin), there's probably a pretty low chance of the estimate changing.  I would still like to see the ability to add a "max tx fee" to the send rpc calls, which would address when the tx fee goes up after estimate.  But, this is better than nothing.

As a side note, this is the first C++ I've written in 5 years, I profusely apologize for it sucking.  I realize instantiating a transaction that you know is going to be destroyed is wasteful, but I didn't feel comfortable enough with the source to refactor the fee calculation code (since I'd end up touching many of the most important functions).  Do I need to do anything to dispose of the transaction?

[ShadowOfHarbringer]

Should'nt we as the senders be able to decide what we're willing to pay for a transaction instead of it being taken from our wallets with nothing to be done about it after the fact?

Exactly. This automatically turns on the red light for me. This is also the reason why i don't use 0.3.21 yet - because i don't like others to decide for me what i want to do with my money.

I think that the fees should be automatically estimated based on by some king weighed average of transaction size OR on the current BTC prices comparing to other currencies.
In either case, the decision if the fee should be paid or not, should be left to the users and miners, which make the market.

If i want to send small amount without a fee and wait 10 hours for confirmation, then let me - that is my right because I am a free man - and Bitcoin is money of the free people.

Perhaps the default client should have a "--force" parameter just like many GNU command line applications, which sends transaction even if it is probably not optimal.

----
EDIT:
Also see my other post here:
http://forum.bitcoin.org/index.php?topic=6189.msg127007#msg127007

[xf2_org]

Should'nt we as the senders be able to decide what we're willing to pay for a transaction instead of it being taken from our wallets with nothing to be done about it after the fact?

That is why there is an option for this.

[error]

Should'nt we as the senders be able to decide what we're willing to pay for a transaction instead of it being taken from our wallets with nothing to be done about it after the fact?

That is why there is an option for this.

0.3.21 provides no way to override the transaction fee and send a free transaction (accepting the lengthy delay). Is this in 0.3.22?