Bitcoin Forum
December 10, 2016, 08:34:58 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: bitcoind fee roulette  (Read 1610 times)
Stn
Full Member
***
Offline Offline

Activity: 230


View Profile
February 25, 2012, 03:27:11 AM
 #1

It happens that I do send out many micro payments in automatic mode with bitcoind. In general I do not mind to pay some fees in order to support the network. But when it comes to the multiple small payments it damages my income.

I'm aware of that tiny or "young" transactions are need to backed up by fee. But I still can't understand the pattern of fee calculation.

Altogether around 50% transactions goes with 0.01 BTC fee and others are free. There is no correlations with the amount. Larger ones may be with fee and smaller may be free. The wallet consists of plenty BTC with the majority of funds being very mature. paytxfee parameter seems does not give any effect.

I'm trying to understand algorithm of fee calculation in order to minimize my losses.
1481402098
Hero Member
*
Offline Offline

Posts: 1481402098

View Profile Personal Message (Offline)

Ignore
1481402098
Reply with quote  #2

1481402098
Report to moderator
1481402098
Hero Member
*
Offline Offline

Posts: 1481402098

View Profile Personal Message (Offline)

Ignore
1481402098
Reply with quote  #2

1481402098
Report to moderator
1481402098
Hero Member
*
Offline Offline

Posts: 1481402098

View Profile Personal Message (Offline)

Ignore
1481402098
Reply with quote  #2

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

Posts: 1481402098

View Profile Personal Message (Offline)

Ignore
1481402098
Reply with quote  #2

1481402098
Report to moderator
1481402098
Hero Member
*
Offline Offline

Posts: 1481402098

View Profile Personal Message (Offline)

Ignore
1481402098
Reply with quote  #2

1481402098
Report to moderator
deepceleron
Legendary
*
Offline Offline

Activity: 1470



View Profile WWW
February 25, 2012, 03:41:22 AM
 #2

It happens that I do send out many micro payments in automatic mode with bitcoind. In general I do not mind to pay some fees in order to support the network. But when it comes to the multiple small payments it damages my income.

I'm aware of that tiny or "young" transactions are need to backed up by fee. But I still can't understand the pattern of fee calculation.

Altogether around 50% transactions goes with 0.01 BTC fee and others are free. There is no correlations with the amount. Larger ones may be with fee and smaller may be free. The wallet consists of plenty BTC with the majority of funds being very mature. paytxfee parameter seems does not give any effect.

I'm trying to understand algorithm of fee calculation in order to minimize my losses.
The minimum transaction fee is .0005 per KB of transaction message size, if your Bitcoin is suggesting more, it should be updated to something newer than <0.3.23. In addition, you can use sendmany to send payments to multiple recipients at once, which will be cheaper:
Code:
bitcoind sendmany "FromAccountName" "{\"1BiTCoinSNU2BMzf2cN2TK4yzPUA6CnTAd\":.001,\"1PHoenix9j9J3M6v3VQYWeXrHPPjf7y3rU\":.002}"



DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 25, 2012, 04:25:00 AM
 #3

The total amount of the transaction doesn't matter.

It is the amount and age of the inputs.

Thus 1 BTC paid by an 1 BTC input 144 blocks old = no fee, while 1 BTC paid by 1000 0.001 inputs which are 6 blocks old = relatively large fee.

Stn
Full Member
***
Offline Offline

Activity: 230


View Profile
February 25, 2012, 04:33:14 AM
 #4

Then if I have young and plenty mature money in the same wallet what bitcoind chooses to pay out?
Stn
Full Member
***
Offline Offline

Activity: 230


View Profile
February 25, 2012, 04:37:34 AM
 #5

If it is just random pick I'm thinking to have two wallets running. One to accept payment and leave there, another to send payments. Once in a while swap their functions.
btc_artist
Full Member
***
Offline Offline

Activity: 154


Bitcoin!


View Profile WWW
February 25, 2012, 05:01:42 AM
 #6

It happens that I do send out many micro payments in automatic mode with bitcoind. In general I do not mind to pay some fees in order to support the network. But when it comes to the multiple small payments it damages my income.

I'm aware of that tiny or "young" transactions are need to backed up by fee. But I still can't understand the pattern of fee calculation.

Altogether around 50% transactions goes with 0.01 BTC fee and others are free. There is no correlations with the amount. Larger ones may be with fee and smaller may be free. The wallet consists of plenty BTC with the majority of funds being very mature. paytxfee parameter seems does not give any effect.

I'm trying to understand algorithm of fee calculation in order to minimize my losses.
Look into "sendmany".

BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf
LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
Stn
Full Member
***
Offline Offline

Activity: 230


View Profile
February 25, 2012, 06:11:13 AM
 #7

It would be good if payments are to be sent in a time. But that is not an option to delay them in order collect a bunch.
grue
Global Moderator
Legendary
*
Offline Offline

Activity: 1932



View Profile
February 25, 2012, 04:54:19 PM
 #8

If it is just random pick I'm thinking to have two wallets running. One to accept payment and leave there, another to send payments. Once in a while swap their functions.
it's not random. It's designed to maximize coin age and reduce inputs.

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

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

Activity: 230


View Profile
February 25, 2012, 05:17:55 PM
 #9

I've installed latest version and fee reduced to 0.0005 BTC. Which is absolutely fine for me and makes useless any additional tricks.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
February 25, 2012, 06:03:54 PM
 #10

it's not random. It's designed to maximize coin age and reduce inputs.

Bitcoin actually chooses coins with the goal of reducing change. (This is not the best way to do it.)

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
February 25, 2012, 08:05:52 PM
 #11

If it is just random pick I'm thinking to have two wallets running. One to accept payment and leave there, another to send payments. Once in a while swap their functions.
it's not random. It's designed to maximize coin age and reduce inputs.

Where did this meme originate?  It's not true.  The official client will use coins with more than 6 confirmations if it can, but other than that makes no effort to use old coins.  It tries to find the set of coins which has the smallest value above the value you're trying to send, which usually results in a small 'change' output being left in your wallet, which can tend to increase future fees.

The idea of using two wallets is a reasonable one and should work.  Bear in mind that to avoid fees, each coin you spend should be at least one "bitcoin day" old.  i.e. multiply the coin's value in BTC by its age in days, and it that's more than about one then you can probably spend it for free.  That's just a rough rule of thumb, because the number of outputs also affects the transaction size, but only about 20% as much as the number of outputs does.  (Each input adds 179-181 bytes to the transaction size, while each input only adds 34 bytes).

Alternatively, if you feel comfortable building the client from source, you can modify it so that it prefers older coins.  Find the bit in wallet.cpp that says:
Code:
    return (SelectCoinsMinConf(nTargetValue, 1, 6, setCoinsRet, nValueRet) ||
            SelectCoinsMinConf(nTargetValue, 1, 1, setCoinsRet, nValueRet) ||
            SelectCoinsMinConf(nTargetValue, 0, 1, setCoinsRet, nValueRet));
and add a few more lines, so it tries the oldest coins first.  Something like this would work:
Code:
    return (SelectCoinsMinConf(nTargetValue, 1, 6*24*30, setCoinsRet, nValueRet) || // try just using 30 day old coins first
            SelectCoinsMinConf(nTargetValue, 1, 6*24*7, setCoinsRet, nValueRet) || // then 7 day old
            SelectCoinsMinConf(nTargetValue, 1, 6*24, setCoinsRet, nValueRet) || // then 1 day old
            SelectCoinsMinConf(nTargetValue, 1, 6, setCoinsRet, nValueRet) || // then 1 hour old
            SelectCoinsMinConf(nTargetValue, 1, 1, setCoinsRet, nValueRet) ||
            SelectCoinsMinConf(nTargetValue, 0, 1, setCoinsRet, nValueRet));

Depending how 'micro' your coins are, and how old your wallet is, you might want to go further still, but I'm sure you get the point.

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



View Profile
February 25, 2012, 10:04:36 PM
 #12

Alternatively, if you feel comfortable building the client from source, you can modify it so that it prefers older coins.  Find the bit in wallet.cpp that says:

Er! Danger Will Robinson! Danger!

The selection function is fairly greedy but the objective is non-convex, this can lead to surprising results.  You can currently end up paying more fees than you need. Consider the following sequence:

Say you want to send 1.0 BTC.
Selection pass runs, finds 1.0 BTC using 100 .01 BTC inputs that all have more than six confirms.
Software then decides that a fee of .01 (random figure) is needed based on the size of the transaction.
Selection runs again looking for 1.01, but can't find that much using inputs with >=6 confirms, so it considers 1 confirm transactions.
Selects inputs of 1.0,0.01 from the set of transactions with at least one confirm, and pays fees that are not really required.

Adding more stages makes this worse.   I have a patch here that first only considers inputs from the set which are high enough priority that any transaction composed solely of them will be high priority, somewhat like your posed your proposed patch but it sets the threshold to be max(144/value,1) confirms.  In my testing I found that it pretty frequently caused stupid decisions at least for wallets with distributions like mine.

If you want to iterate it should be over the entire CreateTransaction, not just inside select coins (and, in fact, all the SelectCoins iteration should be removed). I'm hesitant to write code to do this because any change in this area desperately needs test cases. This code is far too risky to change lightly.


dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
February 25, 2012, 10:43:18 PM
 #13

Selection runs again looking for 1.01

Good point.  I missed that.

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!