Bitcoin Forum

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?

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.

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.

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.

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

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!

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

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.

+1

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.

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?

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.

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.

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?

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

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?

That's what I am talking about.
I had to downgrade to 0.3.20 to get around this.

Should be the default behavior.  I send free TX's with 0.3.21.  TX fee is stored in wallet, so maybe you must explicitly -paytxfee=0, to reset it?

Still, that won't work in the GUI, which is annoying.

You can do it from the command line, but not in the GUI, which is what most people use. ;)

"Yes" sends with fee, "No" cancels the transaction. This dialog needs a third option, to send without fee. HOWEVER, enabling the third option should be a user preference which is disabled by default.
http://i51.tinypic.com/beyqef.jpg

@Gavin - BTW, I'm concerned with the transaction fee size itself, not the percentage (since I'd be on the hook for the fee, should the user not have enough BTC to cover the fee in their account).  And, it was my understanding that as the size of the transfer goes up, the txn fee does, too, right?

Fee goes up (a) as the size of the transaction increases, and (b) as the block fills up (limit 1MB).  See https://en.bitcoin.it/wiki/Transaction_fees

No resolution for this... I too, would like to send transactions with no fees, even if it takes a day or two before they are finally included in a block.  No way to do this though?  I am running the latest bitcoind 0.3.23.  I REALLY think it should be optional to pay a transaction fee.

I don't want to keep putting band-aids on the transaction fee problem, so I'm against adding Yet Another Button to the client.

If you're impatient and can't stand the thought of paying half-a-millibitcoin for a transaction, then compile your own version of bitcoin. Just don't complain if you end up with a wallet full of 0/unconfirmed transactions that tie up all your funds.

Good that some people are making alternative clients.

The problem is that the client doesn't meet user expectations in three important ways.

First, the technical documentation says things like: "Transaction fees are voluntary on the part of the person making the bitcoin transaction, as the person attempting to make a transaction can include any fee or none at all in the transaction." It is highly misleading to say that this is true because the user can modify the client.

Second, the client has an option to set the transaction fee per KB to zero. This creates the user expectation that they'll never pay a transaction fee. It is not made clear that this is not the only source of transaction fees.

Third, there is no way to see ahead of time what the transaction fee is going to be. This creates problems in cases where the user is trying to ensure the recipient gets a particular number of bitcoins.

Nothing is false or incorrect, just highly misleading.

That.

And I did not knew about the second part. (I thought transactions fees are always set per KB, they aren't?)

If they were, then if you set the transaction fee per KB to zero, you'd never pay any transaction fees. On 0.3.23, you will pay transaction fees even if you set the fee per KB to zero. How you want to interpret this is up to you. You can say the client is not honoring the fee per KB of zero. You can say the client is imposing a transaction fee that's not per KB and is honoring the fee per KB of zero. You say po-TAY-to, I say po-TAH-to.

If transaction fees are going to be randomly enforced with no way to stop it, may as well just slap a tx fee on every tx.  Make the minimum tx fee 0.0005 BTC every time, with the option to pay more to potentially get a tx to go through faster.

But having the option to set tx fee to 0, then pay tx fees, that's just confusing, misleading, and frustrating.

+1


I am starting to think seriously about maintaining a "No-Forced-TX-Fee" fork of the main client.

Shadow, you mentioned that you downgraded to 0.3.20... is there still a link available somewhere to download a compiled version of 0.3.20?

I would 100% support a fork for a client that doesn't force transaction fees.

Is there really the possibility free small transactions will hang around waiting for confirmations forever? I thought transactions that were waiting for confirmations for too long automaticly gained more priority regardless of the size or even presence of tx fees....

They do.  Well, coins that wait around longer get priority, at any rate.

There is the possibility. If no miners are willing to accept a transaction, it will wait around for confirmation forever. In practice, at least for now, there are enough lulls in the transaction load and miners willing to take any transaction at all that there's not a problem.

Also, i thought there were some measures in place so that if due to some statistical blip a transaction stayed floating unconfirmed for too long it would be canceled, so even if all miners reject a transaction the money wouldn't stay in limbo forever...

There is, by intentional design, no way to cancel a transaction, other than to get a conflicting transaction included in the hash chain. If a miner includes it in the chain, then it happens.

nice. But I still can't send anyone a satoshi for free :(

I think the transaction fees should have a difficulty to keep the block growth at a goal of 1 mb/day or 5 mb/day.  The island of yap had large stone money, the fed had gold bars, even the lydian lion were too valuable to be used.  But, I think in the future the transaction fee might rise to 0.1 or 1 or even 10.  Now you say that would make bitcoin useless.

You could join a mining pool such as deepbit.  Then directly deposit those coins on an exchange with the receive address they give you.  Buy goods, all without ever installing the bitcoin client.  The large transactions will be part of the network, however the smaller transactions will be done through wallets, exchanges, and mining pools.

This could actually strengthen the network.  In a year no one will have the client installed anyway due to block growth.  However, high transaction fees will allow everyone to install the block.  At the end of the year December 31st, the blocks can be cleaned out and verified before the baby new year and the new fresh block such as block000002012, leaving a little bit of zeros to plan for the future.

So say in 2017 and BTC is worth $5000 per coin and you have 100 of them and the transaction fee is 1.  Now to protect your coins you might leave a computer on 24-7 to protect the network, before selling out to a bigger fish and using exchanges or wallets for your small time $500,000.

You should be able to select an older version via Github.
Of course, that's source-only.

Also, there are 0.3.20 (and older) binaries on SourceForge.
http://sourceforge.net/projects/bitcoin/files/Bitcoin/

The problem with fork is i can only compile it for Linux, somebody else has to compile Windows version.

EDIT:

Completely forgot about MacOS.
I am not doing MacOS as well.

And if you could do it for Windows, I would throw a bitcoin or two (at current rates) your way as a "Awesome! Thanks!"



:(

For now, stick to the 0.3.20 version.

http://sourceforge.net/projects/bitcoin/files/Bitcoin/

Unfortunately compiling for windows is not as easy as it is with linux.
Also, i don't have any windows installed at the moment.

I hope we find some maintainers for other operating systems.

I have the 0.3.20.2 install file if anyone wants to trust a random stranger on the internet  :-\

I've got a compiler set up for Windows.  I barely know how to use it, but I did successfully compile 0.3.23.

Thanks for the SF link, I'll use that for now.

OK....

I shall be setting the fork on Github this weekend.

I will post details here (and in a new topic) once i create the fork.

I created the fork.

Read here:
http://forum.bitcoin.org/index.php?topic=22434.msg281703#msg281703

Binary Linux packages will be soon built, also I am currently looking for Windows & MacOS maintainers.

Is there already a RPC API solution for getting the estimated fees OR a feature that blocks the sending if the account balance would become insufficent? Anything planned for the next version? I think this is very important for handling accounts and running bitcoin services!

Unfortunately, there isn't anything like that. Read here:
https://bitcointalk.org/index.php?topic=45259.0

This is the exact reason why i created my fork. There isn't any way to force sending money without any fee currently.