Ability to predict fees?

[carlos]

Hello,
after some experimenting with bitcoind and its json interface still I'm not able to control and predict fees correctly.
After spike in BTC price above 100 USD, I've used "settxfee" to 0.0001 to compensate for it.
From what I've read at http://bitcoinfees.com/, transaction fees are calculated by "paytxfee" parameter * transaction size in kilobytes.
But from past tests, its calculated differently and bitcoind doesn't respect the setting...

E.g. this txid

Can anybody explain this or give some insight how this one was calculated or into transaction fees in general?
Is this the problem with non-divisibility of small inputs?
Do I have to use raw transactions instead of json commands to bitcoind to have control over tx fees?

[grue]

settxfee will set the fee you pay for every transaction. However, on the satoshi client, if the client deems the transaction to be "spam" (too big, inputs not "old" enough, or sub 0.01 BTC outputs), it will attach the minimum fee to the transaction (0.005 I think). With the GUI, you will be given a choice whether to pay the fee or cancel the transaction, but with json-rpc, the client will pay the fee for you. I think what happened here is that your transaction was too "spammy", and your client tacked on an extra 0.005 BTC fee in addition to the fee you normally pay. If you wish not to be forced to pay fees, you can always use the "No Forced TX Fee" fork, which does not force any fees. Be careful with this, because not paying fees on some transactions may result in your transaction not being relayed or included in blocks.

[carlos]

Hello, thanks for info... I'm using purely bitcoind rpc calls from my scripts. Inputs was 0.1265 and output 0.12 is this the reason that "change" was used as fee? Because I don't know any other way it would calculate 0.0065 fee. (its 2.4 kilobyte, 11 inputs, 1 output).

The reason I'm asking is because I run it as a service and don't want any users account to go to negative values..

I've found some old threads about "calculatetxfee" but it seems that it never got into main dist (there seems to be some random factor in it).

I'd prefer some "official" solution as I'd like to support the network with the fees (also not risking messing up user's transactions) and in the same time give our users ability to predict fees in advance before sending. Do you think its currently possible with main dist of bitcoind?

[grue]

fee = inputs - outputs
(or unspent inputs)

[Gavin Andresen]

I'd prefer some "official" solution as I'd like to support the network with the fees (also not risking messing up user's transactions) and in the same time give our users ability to predict fees in advance before sending. Do you think its currently possible with main dist of bitcoind?

No, unless you take complete control over input selection and transaction creation using the raw transactions API.

If you have multiple users sharing the same wallet, then reasonable ways of handling transaction fees are:

Keep track of who owns which inputs and use the raw transactions API to charge users fees based on what the inputs look like.

Just pay transaction fees for your users. If you work out how much that will cost you versus how much time you'll spend with a more complicated solution, you'll probably find this is the best solution. If you're using the 'accounts' feature, then the logic is:  Send the transaction, then get the transaction details and reimburse the transaction fee (if any) with a 'move' that transfers bitcoins from a transaction-fee-reimbursement account (which you finance in advance, and top-up when necessary) to the user's account.

Or charge them a fixed fee that is enough to cover average costs (again, if using accounts you'd move bitcoins to/from the transaction fee account depending on whether a given transaction cost more or less than average).

Otherwise, you'll have a situation where user A gets gazillions of tiny inputs credited to their account, and user B ends up paying to spend them.

[chriswilmer]

I'd prefer some "official" solution as I'd like to support the network with the fees (also not risking messing up user's transactions) and in the same time give our users ability to predict fees in advance before sending. Do you think its currently possible with main dist of bitcoind?

No, unless you take complete control over input selection and transaction creation using the raw transactions API.

If you have multiple users sharing the same wallet, then reasonable ways of handling transaction fees are:

Keep track of who owns which inputs and use the raw transactions API to charge users fees based on what the inputs look like.

Just pay transaction fees for your users. If you work out how much that will cost you versus how much time you'll spend with a more complicated solution, you'll probably find this is the best solution. If you're using the 'accounts' feature, then the logic is:  Send the transaction, then get the transaction details and reimburse the transaction fee (if any) with a 'move' that transfers bitcoins from a transaction-fee-reimbursement account (which you finance in advance, and top-up when necessary) to the user's account.

Or charge them a fixed fee that is enough to cover average costs (again, if using accounts you'd move bitcoins to/from the transaction fee account depending on whether a given transaction cost more or less than average).

Otherwise, you'll have a situation where user A gets gazillions of tiny inputs credited to their account, and user B ends up paying to spend them.

I've seen Mike Hearn post about defragmenting tiny inputs. Is that just a matter of someone writing the code to do it, or does that violate something more fundamental to how bitcoin works? Sorry if this question is steeped in my ignorance.

[wheatstone]

I've seen Mike Hearn post about defragmenting tiny inputs. Is that just a matter of someone writing the code to do it, or does that violate something more fundamental to how bitcoin works?

The former... in principle. If you have many dust inputs, however, there's no realistic way to consolidate them without bloating the transaction size to the point of fees costing significantly more than the inputs were worth. Miners do have an interest in consolidating inputs, but allowing such transactions without large fees would require a change on their end.

You can also do it manually, although if you have a lot of small inputs it can take a considerable amount of time without incurring fees.

[Mike Hearn]

Fees are levied on transaction size. The idea is you generate a large number of small transactions spread over a period of time, each one consumes a bunch of inputs and produces a single output, and that happens recursively down the tree of transactions until you end up with 1 output of the consolidated balance.

In theory it shouldn't require lots of fees. However you pay for it with your time instead. If you don't need access to the funds anytime soon, it might be workable, but I never tried it.

[carlos]

Thanks for complex reply. We have implemented average fixed fee according to your recommendation.

Does "minconf" parameter when using "send" have any effect on fees in this case?

I've read somewhere that properly "aged" coins can be send with smaller fees.

[carlos]

Sorry for digging this... Does anybody uses effectively mincoinconf when sending transactions to lower tx fees?

Or do you think another approach - sending whole wallet (averaging of inputs) to yourself - is viable?