Fees question (Yes, yes, I know it's been posted about 50 times)

[Automatic]

I've seen quite a few people ask this exact question, each time with the reply "it's the network's fault", although, I'm still confused by it, from what I understand Armory only requests the fees required by the network, fair enough, but, can someone explain why this wallet:-
https://blockchain.info/address/1JaSQNKqVMPEtAL1Zm4NbMHEgzu3juSXyE

Which has .01BTC and 150 confirmations for it's incoming transaction still requires a payment of 0.0005? It seems as though it should be free to send money, as per the Transaction Fee documentation. I've done very little Bitcoin development, so, I'm not sure of the actual backend doing the calculations, but, that address is the only address in the Armory wallet that has money, so, it should be forced to send from that address.

Other than the confusing transaction fees, this client is great, and, I really want to use it, but, my lack of understanding of the transaction fees puts me off it, I understand it's not the client's fault that I'm forced to pay, but, can anyone provide me a descriptive reason on why it refuses to send for free?

The incoming transaction to the above address I sent for free:-
https://blockchain.info/tx/ac4d10dc416a92b86028da5976810dd0571ee5137d1659637c836ffd51f2a56a

Thanks,
Automatic.

P.S. This thread use to be something else, but, I changed it to something I'd rather know before answering the other question.

[etotheipi]

Are you familiar with "bitcoind" (vs Bitcoin-Qt)?  We have a "daemon" version of Armory as well:  armoryd.py which behave almost identically to bitcoind, but gives you access to watching-only wallets, better transaction ledgers, etc.

The link above points to the armoryd.py on the master branch, which is currently pretty bare.  However, you can easily run it in offline mode and having it load and distribute addresses from a watching-only wallet.  If you put it in online mode, you will also be able to access transaction history and verify payments.    But it will crash every few days (because that's what 0.88.1 did).

In a couple weeks, that script (on the master branch) will be updated with a much-improved version.  We've actually already finished most of it, but will need to merge in some other changes that aren't ready for this release.  This version will implement most of the same functionality as bitcoind.

Either way, you should familiarize yourself with how bitcoind works, and then you will be able to access armoryd.py exactly the same way.  Even better, you could make a modification of armoryd.py which has your application built into it.  This is much more preferable than starting from scratch, because armoryd.py already has all the networking hooks, event loops, wallet load ops, etc integrated and working.  You would simply need to add code to the methods that process new transactions, etc. 

Can discuss at greater length after this release it out.  But if you are unfamiliar with bitcoind, you should do some research on that and how to use it and integrate it into web services.  Doing so will give you a non-deterministic, full wallet.  If you have that working, switching to armoryd.py for deterministic, watching-only will be trivial (when it's ready).   Or if you really just need a process that can read a watching-only wallet and get addresses on demand (but without transaction history), I can post a small python fragment that does that.

[Automatic]

Are you familiar with "bitcoind" (vs Bitcoin-Qt)?  We have a "daemon" version of Armory as well:  armoryd.py which behave almost identically to bitcoind, but gives you access to watching-only wallets, better transaction ledgers, etc.

The link above points to the armoryd.py on the master branch, which is currently pretty bare.  However, you can easily run it in offline mode and having it load and distribute addresses from a watching-only wallet.  If you put it in online mode, you will also be able to access transaction history and verify payments.    But it will crash every few days (because that's what 0.88.1 did).

In a couple weeks, that script (on the master branch) will be updated with a much-improved version.  We've actually already finished most of it, but will need to merge in some other changes that aren't ready for this release.  This version will implement most of the same functionality as bitcoind.

Either way, you should familiarize yourself with how bitcoind works, and then you will be able to access armoryd.py exactly the same way.  Even better, you could make a modification of armoryd.py which has your application built into it.  This is much more preferable than starting from scratch, because armoryd.py already has all the networking hooks, event loops, wallet load ops, etc integrated and working.  You would simply need to add code to the methods that process new transactions, etc. 

Can discuss at greater length after this release it out.  But if you are unfamiliar with bitcoind, you should do some research on that and how to use it and integrate it into web services.  Doing so will give you a non-deterministic, full wallet.  If you have that working, switching to armoryd.py for deterministic, watching-only will be trivial (when it's ready).   Or if you really just need a process that can read a watching-only wallet and get addresses on demand (but without transaction history), I can post a small python fragment that does that.

I'll have a read through the source, and, look into the bitcoind protocol. Unfortunately, it seems as though you were too fast for my thread switch-a-roo, and, posting a reply to my first question, which, is totally fine as it gives me a little more to read as I wait for someone to reply to my second quest 

So, bitcoind first, then armoryd. Thanks.

[etotheipi]

So apparently you completely changed the topic on me before I posted... I'm leaving my previous post intact, in case you want to start a new thread.  Then I'll move it.

The answer to your fees question is on our FAQ page:

https://bitcoinarmory.com/about/faqs/

About half-way down is the question "Why do I sometimes have to pay a transaction fee? Why is it so inconsistent?"

[etotheipi]

One more thing... that doesn't address your concern about paying 0.0005 BTC fees when you expected 0.0001.   It's because the older versions of Armory were created and hardcoded with the the "fee rules" at the time they were released.  For a very long time, those rules used 0.0005 BTC as the default fee, and Armory enforces that.  It has been changed to 0.0001, but the older versions of Armory don't know that!

The new version of Armory we're just about to release does have that updated.  You should see 0.0001 by default.  And transactions that don't output dust, using sufficiently old coins, and size under 10kB, can make it through for free.

[Automatic]

The new version of Armory we're just about to release does have that updated.  You should see 0.0001 by default.  And transactions that don't output dust, using sufficiently old coins, and size under 10kB, can make it through for free.

What version is that? Or is it a fully unreleased version currently? Also, are you stating that currently it's impossible to pay for free (assuming <10kB, >=.1 & old enough) with the current version out?

P.S. Sorry for the full thread change, but, I realized that I probably want to know how fees work before attempting to develop a small BTC test application, as, I don't want to be paying $0.50 per transaction out of Armory (Yes, I realize I could use testnet, but, still...).

[etotheipi]

The new version of Armory we're just about to release does have that updated.  You should see 0.0001 by default.  And transactions that don't output dust, using sufficiently old coins, and size under 10kB, can make it through for free.

What version is that? Or is it a fully unreleased version currently? Also, are you stating that currently it's impossible to pay for free (assuming <10kB, >=.1 & old enough) with the current version out?

It's perfectly possible to submit free transactions with the current version of Armory... Armory lets it through if the network would take it by default.  Armory won't let you send transactions that don't meet the minimum rules since they are likely to get stuck and cause serious heartache.  The only thing the current version does wrong is:  when a fee is required, it computes the required fee to be too high.  That's all.

The new version is already posted on the website, but as a pre-release "testing" version.  Should have a final release in a few days.

[Automatic]

The new version of Armory we're just about to release does have that updated.  You should see 0.0001 by default.  And transactions that don't output dust, using sufficiently old coins, and size under 10kB, can make it through for free.

What version is that? Or is it a fully unreleased version currently? Also, are you stating that currently it's impossible to pay for free (assuming <10kB, >=.1 & old enough) with the current version out?

It's perfectly possible to submit free transactions with the current version of Armory... Armory lets it through if the network would take it by default.  Armory won't let you send transactions that don't meet the minimum rules since they are likely to get stuck and cause serious heartache.  The only thing the current version does wrong is:  when a fee is required, it computes the required fee to be too high.  That's all.

The new version is already posted on the website, but as a pre-release "testing" version.  Should have a final release in a few days.

You say posted on the website, which, from what I can see is "0.89.99.14-testing", however, that's the version I'm running, so, I assume you mean "0.89.99.16-testing", which, from what I can see (Unless I'm utterly blind) is only posted on the forum?

Anyway. Downloading the "0.89.99.16-testing" version from the forum, as, stability isn't my main requirement right now as I've yet to move any serious amount of BTC to my wallet, and, if worse comes to the worse I can just export the private key out of the Virtual Machine I'm using as a test 'offline' machine, which, I know isn't secure, but, worth testing before looking for an old computer to store wallets on.

EDIT:- Well, that worked:-


However, still confused on why I have to pay a transaction fee as I'm pretty sure I meet the standard for free transactions. I guess my coins aren't old enough, so, I'll let them sit there for a couple more days. Thanks for answering both questions! I'll look into the bitcoin daemon a bit later, or, tomorrow.

[etotheipi]

The fee is required if it's less than 1 Bitcoin*Day old.   If it's 1 Bitcoin, it will require 1 day.  If it's 0.01 Bitcoins, it will require 100 days.  If it 1000 Bitcoins, it only needs a single confirmation to meet the requirements.

You might be waiting a while

[Automatic]

The fee is required if it's less than 1 Bitcoin*Day old.   If it's 1 Bitcoin, it will require 1 day.  If it's 0.01 Bitcoins, it will require 100 days.  If it 1000 Bitcoins, it only needs a single confirmation to meet the requirements.

You might be waiting a while

Really? I've sent money before from blockchain.info for free that I received a couple of days before, and, is only ~ .9.

Hell, check the transaction in the OP, it was sent from this address:-
https://blockchain.info/address/12ZMtUrv3hKtZsrY9MiraVdbhfKULF2t8R

It got 0.09314531, two days later it sent out 0.01 for free. Wouldn't, by your logic, it require roughly 10 days to be able to send the .1 from the .09 for free, or, am I misunderstanding?

[picobit]

Blockchain.info allows you to send transactions that don't fulfill the minimum fee.  If you are lucky they get confirmed within a day or two, but they may get stuck.

[Automatic]

Blockchain.info allows you to send transactions that don't fulfill the minimum fee.  If you are lucky they get confirmed within a day or two, but they may get stuck.

Fair enough, is there anyway to tell armory you wish to override it's recommendation? I understand it can (and probably will) get stuck, but, I still want to be able to do it.

[kerogre256]

Blockchain.info allows you to send transactions that don't fulfill the minimum fee.  If you are lucky they get confirmed within a day or two, but they may get stuck.

Fair enough, is there anyway to tell armory you wish to override it's recommendation? I understand it can (and probably will) get stuck, but, I still want to be able to do it.

This I want set my fee regrades of consequence.

[etotheipi]

Blockchain.info allows you to send transactions that don't fulfill the minimum fee.  If you are lucky they get confirmed within a day or two, but they may get stuck.

Fair enough, is there anyway to tell armory you wish to override it's recommendation? I understand it can (and probably will) get stuck, but, I still want to be able to do it.

This I want set my fee regrades of consequence.

Armory can't do this unless you modify your Bitcoin-Qt/bitcoind as well.  Since your local instance of Bitcoin-Qt is Armory's only peer, and it follows the fee rules exactly, any transactions that don't follow the correct fee rules will be DOA.  They don't get stuck or propagate slowly... they are dead the instant you send them.  There's no way around it without doing something else, like broadcasting the tx externally. 

[Automatic]

Blockchain.info allows you to send transactions that don't fulfill the minimum fee.  If you are lucky they get confirmed within a day or two, but they may get stuck.

Fair enough, is there anyway to tell armory you wish to override it's recommendation? I understand it can (and probably will) get stuck, but, I still want to be able to do it.

This I want set my fee regrades of consequence.

Armory can't do this unless you modify your Bitcoin-Qt/bitcoind as well.  Since your local instance of Bitcoin-Qt is Armory's only peer, and it follows the fee rules exactly, any transactions that don't follow the correct fee rules will be DOA.  They don't get stuck or propagate slowly... they are dead the instant you send them.  There's no way around it without doing something else, like broadcasting the tx externally.  

Then, sorry for referring back to the same example again and again, how does Blockchain.info broadcast it without it's peers telling it "no"?

[picobit]

Then, sorry for referring back to the same example again and again, how does Blockchain.info broadcast it without it's peers telling it "no"?

They are extremely well connected, probably thousands of connections to the network, whereas you only have a dozen or so.  So it is likely that a miner that does not care about the fee is listening to what blockchain.info is transmitting, even if the majority of the network does not propagate it.

(I am speculating here)