Bitcoin Forum
December 08, 2016, 04:14:20 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 »  All
  Print  
Author Topic: Transaction fees magically appearing, how to account for them?  (Read 6692 times)
Nefario
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
May 13, 2011, 12:27:06 PM
 #1

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?

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481213660
Hero Member
*
Offline Offline

Posts: 1481213660

View Profile Personal Message (Offline)

Ignore
1481213660
Reply with quote  #2

1481213660
Report to moderator
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
May 13, 2011, 12:50:37 PM
 #2

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.

How often do you get the chance to work on a potentially world-changing project?
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
May 13, 2011, 01:28:36 PM
 #3

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
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
May 13, 2011, 01:55:48 PM
 #4

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.

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
May 13, 2011, 03:47:51 PM
 #5

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.

How often do you get the chance to work on a potentially world-changing project?
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
May 13, 2011, 04:28:12 PM
 #6

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

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
xf2_org
Member
**
Offline Offline

Activity: 70


View Profile
May 13, 2011, 04:32:15 PM
 #7

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
Newbie
*
Offline Offline

Activity: 3


View Profile
May 25, 2011, 09:31:19 PM
 #8

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
Hero Member
*****
Offline Offline

Activity: 574



View Profile
May 25, 2011, 09:54:30 PM
 #9

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

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
Nefario
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
May 27, 2011, 12:59:23 PM
 #10

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

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
danglybits
Newbie
*
Offline Offline

Activity: 11


View Profile
May 27, 2011, 01:49:22 PM
 #11

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
Hero Member
*****
Offline Offline

Activity: 565


Unselfish actions pay back better


View Profile WWW
May 27, 2011, 01:55:02 PM
 #12

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

Klaus Alexander Seistrup
http://about.me/kseistrup
Nefario
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
May 27, 2011, 02:07:53 PM
 #13

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.

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
May 27, 2011, 03:27:00 PM
 #14

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?

How often do you get the chance to work on a potentially world-changing project?
error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
May 27, 2011, 06:47:15 PM
 #15

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.

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
Nefario
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
May 28, 2011, 01:21:00 PM
 #16

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.

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
sassame
Newbie
*
Offline Offline

Activity: 3


View Profile
May 29, 2011, 02:29:43 AM
 #17

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
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
May 29, 2011, 05:02:10 AM
 #18

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
Member
**
Offline Offline

Activity: 70


View Profile
May 29, 2011, 06:31:06 AM
 #19

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
Hero Member
*****
Offline Offline

Activity: 574



View Profile
May 29, 2011, 06:33:46 AM
 #20

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?

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!