Bitcoin Forum
December 13, 2017, 07:58:45 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Ability to predict fees?  (Read 1097 times)
carlos
Member
**
Offline Offline

Activity: 105


View Profile
April 22, 2013, 09:53:10 AM
 #1

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?


1513151925
Hero Member
*
Offline Offline

Posts: 1513151925

View Profile Personal Message (Offline)

Ignore
1513151925
Reply with quote  #2

1513151925
Report to moderator
1513151925
Hero Member
*
Offline Offline

Posts: 1513151925

View Profile Personal Message (Offline)

Ignore
1513151925
Reply with quote  #2

1513151925
Report to moderator
1513151925
Hero Member
*
Offline Offline

Posts: 1513151925

View Profile Personal Message (Offline)

Ignore
1513151925
Reply with quote  #2

1513151925
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513151925
Hero Member
*
Offline Offline

Posts: 1513151925

View Profile Personal Message (Offline)

Ignore
1513151925
Reply with quote  #2

1513151925
Report to moderator
1513151925
Hero Member
*
Offline Offline

Posts: 1513151925

View Profile Personal Message (Offline)

Ignore
1513151925
Reply with quote  #2

1513151925
Report to moderator
grue
Global Moderator
Legendary
*
Offline Offline

Activity: 2044



View Profile
April 22, 2013, 02:35:44 PM
 #2

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.

It is pitch black. You are likely to be eaten by a grue.

Tired of annoying signature ads? Ad block for signatures
carlos
Member
**
Offline Offline

Activity: 105


View Profile
April 22, 2013, 04:03:14 PM
 #3

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

Activity: 2044



View Profile
April 22, 2013, 06:26:31 PM
 #4

fee = inputs - outputs
(or unspent inputs)

It is pitch black. You are likely to be eaten by a grue.

Tired of annoying signature ads? Ad block for signatures
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
April 22, 2013, 07:17:08 PM
 #5

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.

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

Activity: 1008


View Profile WWW
April 23, 2013, 11:30:26 AM
 #6

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

Activity: 82


View Profile
April 23, 2013, 12:42:00 PM
 #7

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

Activity: 1526


View Profile
April 24, 2013, 07:28:25 PM
 #8

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

Activity: 105


View Profile
April 27, 2013, 10:46:25 AM
 #9

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

Activity: 105


View Profile
April 30, 2013, 02:26:30 PM
 #10

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?

Pages: [1]
  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!