Bitcoin Forum
November 23, 2017, 11:02:24 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: bitcoin-qt/bitcoind - Calculating raw transaction fees!  (Read 2294 times)
oshirowanen
Newbie
*
Offline Offline

Activity: 19


View Profile
June 08, 2014, 10:09:41 AM
 #1

Does bitcoin-qt/bitcoind have a command(s) which can automatically figure out transaction fees for you?

I am playing around with raw transaction commands within bitcoin-qt testnet and understand how to create, sign, and send a raw transaction.  My main difficulty with it is the fee aspect of it.

Does bitcoin-qt/bitcoind have such a command, in-order to work out the fees for you?
1511478144
Hero Member
*
Offline Offline

Posts: 1511478144

View Profile Personal Message (Offline)

Ignore
1511478144
Reply with quote  #2

1511478144
Report to moderator
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511478144
Hero Member
*
Offline Offline

Posts: 1511478144

View Profile Personal Message (Offline)

Ignore
1511478144
Reply with quote  #2

1511478144
Report to moderator
ondratra
Sr. Member
****
Offline Offline

Activity: 336



View Profile
June 08, 2014, 03:42:55 PM
 #2

Calculation of fee is automatic, it depends on number and size of inputs and I think also coinage is taken in equation. But you can set your own fee via setfee command.
Foxpup
Legendary
*
Offline Offline

Activity: 2016



View Profile
June 09, 2014, 01:30:49 AM
 #3

There isn't one. You have to calculate the size of the transaction, and work out the required fee from that.

Calculation of fee is automatic, it depends on number and size of inputs and I think also coinage is taken in equation. But you can set your own fee via setfee command.
Absolutely false.

Will pretend to do unverifiable things (while actually eating an enchilada-style burrito) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4
RainMan28
Member
**
Offline Offline

Activity: 88


View Profile
June 09, 2014, 02:10:42 AM
 #4

Even if you use the settxfee command to set the fee to 0, it does not respect that setting.

AFAIK the transaction fee in Bitcoin-qt/Bitcoin Core is the additional optional fee, but there's already a hard-coded set of rules in the program that determine fees, which can't be turned off.

BTC: 18BEi5vPrPPYETiQt5eG9Sjjyt9DHorfYq
oshirowanen
Newbie
*
Offline Offline

Activity: 19


View Profile
June 09, 2014, 08:34:34 AM
 #5

There isn't one. You have to calculate the size of the transaction, and work out the required fee from that.

This is what I am finding confusing.  I have created a hash value using createrawtransaction and signrawtransaction, and I guess I could work out the byte size of that hash value.  What I find confusing is that I don't get the hash value until createrawtransaction has been executed, and I am supposed to type in the fee value into createrawtransaction.

I am clearling not doing this right, as I seem to be running into a chicken and egg situation.
oshirowanen
Newbie
*
Offline Offline

Activity: 19


View Profile
June 09, 2014, 08:44:20 AM
 #6

Even if you use the settxfee command to set the fee to 0, it does not respect that setting.

AFAIK the transaction fee in Bitcoin-qt/Bitcoin Core is the additional optional fee, but there's already a hard-coded set of rules in the program that determine fees, which can't be turned off.

I'm not trying to turn it off, I am trying to figure out where to get the transaction fee from, so I can use it when running createrawtransaction from bitcoin-qt/bitcoind.
Foxpup
Legendary
*
Offline Offline

Activity: 2016



View Profile
June 09, 2014, 11:05:54 AM
 #7

I have created a hash value using createrawtransaction and signrawtransaction, and I guess I could work out the byte size of that hash value.  What I find confusing is that I don't get the hash value until createrawtransaction has been executed, and I am supposed to type in the fee value into createrawtransaction.
Createrawtransaction doesn't return a hash, it returns raw bytes, which can be counted. Count the bytes, work out the required fee, then subtract it from your change output (altering the value of an output doesn't affect the size of the transaction).

Will pretend to do unverifiable things (while actually eating an enchilada-style burrito) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
June 09, 2014, 04:33:55 PM
 #8

I have created a hash value using createrawtransaction and signrawtransaction, and I guess I could work out the byte size of that hash value.  What I find confusing is that I don't get the hash value until createrawtransaction has been executed, and I am supposed to type in the fee value into createrawtransaction.
Createrawtransaction doesn't return a hash, it returns raw bytes, which can be counted. Count the bytes, work out the required fee, then subtract it from your change output (altering the value of an output doesn't affect the size of the transaction).

You can also estimate the tx size so that you can put a desired tx fee in your first attempt.  Then like foxpup said compute the tx size and if needed go back change the fee amount  by making change smaller.  Think of it as potentially being a two pass process.  This assumes you are not trying to spend lots of dust inputs* and you should setup a tx such that you have a change output with sufficient value that it can be reduced to cover the potential (increased) fee.  If the change output is less than the amount of the fee increase then it can get more complicated.

For "normal" (Pay2PubKeyHash) txs:
signed_tx_size (in bytes) ~= 10 + (numInputs * 148 ) + (numOutputs * 34)
That assumes all inputs are compressed PubKeys.  Uncompressed PubKey are 32 bytes larger so the size of the input would be 180 bytes instead.  Bitcoin uses varint for #Inputs, #Outputs, and script lengths so this should only be used as an estimate.

So for example if you were creating a tx which has 4 inputs (one of which is uncompressed), three outputs (including change output). If all inputs/outputs are Pay2PubKeyHash then the size would be roughly (10 + 148*3 +32 + 3*34) = 588 bytes.  Rounding up nearest KB the tx size is 1KB.  If you wanted a fee of 0.1 mBTC per KB it would be a total fee of 0.1 mBTC.  So set the change output such that the inputs - outputs = 0.1 mBTC.  Create and Sign.   Now double check the size of the signed tx.  Is it <1KB (in this case there is no chance of it going over 1000 bytes but for tx close to the limit it might)?  If so you are done.  If not (say tx size is 1038 bytes) then reduce the change by another 0.1 mBTC (resulting in a 0.2 mBTC fee on 2KB tx = same 0.1 mBTC per KB).


* A word about dust inputs.  Things start to get tricky if you are trying to spend lots of tiny dust outputs.  It can lead to a more complicated tx creation algorithm or a flawed one which results in insufficient fees to ensure timely inclusion in a block.  If on your "2nd pass" you need to raise the fee = lower the value of the change output and the change output is "too small" to cover the increase then you will need to add another inputs.  This could result in the tx being large enough that the fee needs to be increased as well (fee is per KB) and you could end up with insufficient available output requiring a second or third pass.  Once all the available inputs are below the dust threshold you will find that it becomes impossible to the create the tx (i.e. adding the outputs increases the fee more than the value it adds and thus you will go through a number of passes until you exhaust all outputs and end up with a giant tx that still has insufficient fees).   If you want to keep your algorithm simple I would recommend excluding dusty outputs from input selection.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
June 09, 2014, 04:44:39 PM
 #9

Calculation of fee is automatic, it depends on number and size of inputs and I think also coinage is taken in equation. But you can set your own fee via setfee command.

User is creating a raw tx.  In Raw tx the setfee command has no effect and the user must always compute the fee manually. 
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
June 09, 2014, 04:55:25 PM
 #10

New 'estimatefee' and 'estimatepriority' RPC commands were just pulled into Bitcoin Core.

And I threw up a web page that updates estimates with every new block found:  http://bitcoincore.org/smartfee/

Assuming I got the crontab correct, daily fee/priority estimates will be archived there starting tomorrow.

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

Activity: 19


View Profile
June 12, 2014, 11:59:47 AM
 #11

New 'estimatefee' and 'estimatepriority' RPC commands were just pulled into Bitcoin Core.

And I threw up a web page that updates estimates with every new block found:  http://bitcoincore.org/smartfee/

Assuming I got the crontab correct, daily fee/priority estimates will be archived there starting tomorrow.


If I download and install bitcoin-qt 0.9.2, will I get these options?
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!