Pages:
Author

Topic: Transaction fees magically appearing, how to account for them? - page 2. (Read 7480 times)

hero member
Activity: 994
Merit: 501
PredX - AI-Powered Prediction Market
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?)
legendary
Activity: 1596
Merit: 1012
Democracy is vulnerable to a 51% attack.
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.
hero member
Activity: 994
Merit: 501
PredX - AI-Powered Prediction Market
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.
legendary
Activity: 1652
Merit: 2301
Chief Scientist
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.
legendary
Activity: 1400
Merit: 1005
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.
member
Activity: 98
Merit: 13
@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
newbie
Activity: 3
Merit: 0
@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?
hero member
Activity: 588
Merit: 500
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?

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?

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

"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.
legendary
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
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?

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.
member
Activity: 98
Merit: 13
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?

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?

legendary
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
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).

That's what I am talking about.
I had to downgrade to 0.3.20 to get around this.
hero member
Activity: 588
Merit: 500
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?
member
Activity: 98
Merit: 13
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.

legendary
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
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
newbie
Activity: 3
Merit: 0
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?
hero member
Activity: 602
Merit: 513
GLBSE Support [email protected]
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.
hero member
Activity: 588
Merit: 500
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.
legendary
Activity: 1652
Merit: 2301
Chief Scientist
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?
hero member
Activity: 602
Merit: 513
GLBSE Support [email protected]
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.
hero member
Activity: 566
Merit: 500
Unselfish actions pay back better
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
Pages:
Jump to: