Topic: Fee calculation in Armory (Read 1576 times)
You can have a look on this: https://bitcoinfees.21.co/
If you could set up "fee per kb" instead of "fee per tx" it would solve a lot of issues
Well, never failed on me so far... What do you intend to do, rebuild a fee system yourself for Armory?
My tx had 3 inputs 2 outputs. Armory thought the default was fine with that, which obviously it wasn't. In the end I'd like Armory to be able to advise users on proper fees for high priority spending. The idea is fairly simple, analyze fees in the last ~200 blocks, both by minimum fee and density.
It will come with a couple UI changes, to suggest the proper fee as well as a way to set fee density and flat min fee.
Well, never failed on me so far... What do you intend to do, rebuild a fee system yourself for Armory?
Armory already asks for fees to be raised if it deems to be necessary, I've had that happen once. So that means the current algorithm of fee calculation isn't the best one?
Armory's fee estimation is a based on a reimplementation of Core's own rules from over a year ago. That method is not sustainable long term for many reasons.
Quote
Can't Armory interact with bitcoind in order to calculate fees? Through the estimatefee and estimatepriority commands?
Quote
Doesn't armory already use bitcoind's estimatefee for calculating fees? I thought that it only uses the default when bitcoind doesn't have enough data to estimate the fee.
Only when Armory is setup to connect to the RPC, which takes place when bitcoind is managed by Armory.
Proper fee estimate is something I consider critical, it shouldn't rely on an optional feature. Auto bitcoind was developed and will remain a convenience feature, this is not something I want to force users into. It already has demonstrated itself unstable several times in the past.
Also, relying on the RPC is in direct conflict with blocks over P2P, so I don't intent to increase Armory's dependency on that.
Doesn't armory already use bitcoind's estimatefee for calculating fees? I thought that it only uses the default when bitcoind doesn't have enough data to estimate the fee.
Armory already asks for fees to be raised if it deems to be necessary, I've had that happen once. So that means the current algorithm of fee calculation isn't the best one?
Can't Armory interact with bitcoind in order to calculate fees? Through the estimatefee and estimatepriority commands?
Can't Armory interact with bitcoind in order to calculate fees? Through the estimatefee and estimatepriority commands?
So I just had a transaction take some 5-6 hours to confirm. That surprised me (never happened before) so I calculated the average fee per transaction in recent blocks and it turned out it was twice what I paid, so it's no wonder it took me that long to get confirmed.
This thread has a couple purposes:
1) To warn the community: do not trust the default minimum fee in Armory (0.0001 BTC) for high priority transactions, even more so if you are spending several outputs. I would suggest somewhere in the 0.0005 to get swift confirmations for the mid term.
2) I will not change the default in the upcoming version (I am not in the business of forcing settings on users). On the other hand, I will add another ~100MB DB in the following version, for the purpose of tracking fees in the recent blocks, in order to provide a reliable live estimate.
On a side note, I spent those coins with 0.94, so that part is going good at least =)
This thread has a couple purposes:
1) To warn the community: do not trust the default minimum fee in Armory (0.0001 BTC) for high priority transactions, even more so if you are spending several outputs. I would suggest somewhere in the 0.0005 to get swift confirmations for the mid term.
2) I will not change the default in the upcoming version (I am not in the business of forcing settings on users). On the other hand, I will add another ~100MB DB in the following version, for the purpose of tracking fees in the recent blocks, in order to provide a reliable live estimate.
On a side note, I spent those coins with 0.94, so that part is going good at least =)
Jump to: