Topic: Armory - Discussion Thread - page 141. (Read 521829 times)

shouldn't take hours.  takes me a few minutes with 8 GB RAM.

How much RAM do you have?  If you have sufficient RAM, it should be about 5-10min on Windows, 2-3 min on Linux.  The cases where I've seen it take longer than that is when the user has less than 2GB RAM.  For now, Armory requires that much RAM.  Blame SatoshiDice for growing the network faster than I could get around to fixing this...

Regardless, a fix is coming -- at the expense of duplicating blockchain data on disk.  I have to start maintaining my own blockchain data, but it will mean Armory's RAM usage will drop dramatically, and will also startup instantly after the first load.  Obviously a big improvement... but I don't know how long before I can have it implemented.  Definitely within the next couple months.  Until then, there's not much I can do for you

Is there any way to speed Armory up?  It takes hours to get online while showing the "Armory is offline while scanning the blockchain" message.

Also I have another question about using Armory.

I did the following:

1) Created a new armory wallet
2) Generated 1000 addresses/keys at www.bitaddress.org (so that I could have a whole bunch of address to use for different transactions)
3) Imported the keys into my armory wallet (imported not swept)
4) Sent some coins to one of these address (using bitcoin client)
5) Armory does it's scanning when opened

The transactions show as 100 confirmations already in the blockchain, but Armory is still shows the balance of both the wallet and the individual address as 0?

I plan to support "old" wallets by migrating them to the new wallet format.  It is kind of a PITA because they have different properties & algorithms than the new wallets (and part of the reason I am doing the new wallets is to use better algorithms), but I can't imagine requiring users to switch wallets entirely -- I get very dirty looks/responses when I tell users that "It's okay you can't import your Satoshi wallet, just send the funds from it to your Armory wallet..."  They don't like that, at all.

Users will only need to create new wallets if you want to use/import compressed keys, multi-sig linked wallets,   external [and encrypted] comments&P2SH backups, fragmented paper backups, encrypted watching-only wallets, multiple wallets derived from the same seed, faster key generation, better change address privacy (using internal and external address chains as described in BIP 32), and even more stuff I can't even think of right now.  It is also designed to be very extensible so that it will easily accommodate future feature upgrades without having to create a new format again.  And part of that extensibility will be to be able to have multiple chains in one wallet file, including old-wallet chains.

The new wallets will be BIP 32 compliant which will also make them interoperable with other clients when everyone switches.   Actually one of the other things is a property of BIP 32 wallets, being able to setup secure payment-address-distributors as described here.  



Yes you can, but without proper support, you'd be importing a bundle of addresses and still have to create a new deterministic wallet and re-distribute your backups, etc.

sending via the blockchain is unnecessary if you can export/import private keys.

I've already put in the hooks for encrypting arbitrary data in the wallet with a variety of key/IV sources.  The new wallets are far from done, and they probably won't have the feature right away,  but it will be easy to add after the initial release. :-)

how's the PIN/password for opening a watching wallet coming along?

Really not targeted at any one in particular, but now that Armory has its own subforum, please feel free to start new threads even for small issues.  It  will declutter this thread, leaving notifications for more-important issues.  And it makes it easier for other users to search.

That explains it. At least I'm not crazy. Thank you.

Very nice

The password is cached in RAM for 10-20 seconds after you enter your passphrase.  If you do something that requires your passphrase within this time window, it will still used the cached value.  There's a heartbeat function in Armory which runs every second, and one of the things it does is check if the passphrase needs to be destroyed.  Does not use the clipboard at all.

Question:

I need to provide a ~20 char password before sending coins. Sometimes when I make a few (single) payments in a row, I don't have to put in a password, and I don't know how I am doing this. I copy my PW from keepass, and when I click on armory, the coins are already sent.

How am I doing this? Is armory checking my clipboard for a pw?

0.86.3-beta

but there is currently a maximum that armory will let you send... it's just that at the moment there is only a long, manual way of discovering that amount.

There is no maximum (well yes 21M ). The fee depends on what miners will accept and this isn't based on the total amount but on the number of inputs and the time the coins in the inputs haven't moved.

quoting myself

currently, the only way I know of to find out the true answer of the above question, is by doing higher/lower guessing game until you hit the sweet spot right between getting a confirmation screen and getting a prompt to increase your tx fee.

the MAX button does indeed do as you describe, however that is quite different from what i described.


example:

let's say your balance is 5 and you try to send 4.99 btc with 0.01 fee and armory says "fee must be 0.05" so you say OKAY.

that will update the TX fee input box to 0.05 and you hit MAX it will update the amount field to 4.95... this is quite different from saying

"What is the maximum amount I can send, with a fee of 0.01?"    <-- 4.99 here is the incorrect answer, yet that's what the MAX button will suggest!

...if armory could answer that automatically it might say, well you can send up to 3.3451 if your tx fee is only 0.01.

I don't totally understand.  There is a way to specify fee at the bottom.  If Armory tells you that you need 0.02 fee, then you used to just be able to change the fee to 0.02, and hit the MAX button.  Now, when it tells you that you need 0.02 fee, it should automatically change the fee for you -- all you need to do is hit MAX again and "Send".

I'm not against zero-fees (in most cases), but the issue is that Armory uses Bitcoin-Qt/bitcoind as a gateway to the Bitcoin network.  If your fee is insufficient for Bitcoin-Qt's fee rules, your sub-standard-fee tx is dead-on-arrival and will not be forwarded to the network.  There's nothing I can about this... unless I setup bitcoind's RPC interface and use the sendrawtransaction (?) command ... but so far I don't use RPC at all, and I don't want to enable it if the user hasn't done it themselves already.

In Armory-release time, 0.82.2 is ancient.  And that is before the wallet-optimization that should make Armory usable for such huge wallets.  Luckily, I have a test wallet with thousands of addresses and tx, so I'm on top of these things now .  I now keep a variety of wallets loaded at all times to ensure that I am stressing Armory.  The speed should definitely be fixed in 0.87.2.  You'll also get the multi-threaded interface, which is a lot more pleasant to use, anyway

I'm pretty sure I tweaked the "MAX" button in the latest version.  When it warns you about the fee that you need, it should automatically update the fee field with that value.  Just hitting MAX again simply subtracts the new fee from your balance and the tx should definitely be valid.  Let me know if that isn't the case.  I have it on my TODO list to implement a simple "Sweep Wallet" function.

thanks very much for your reply. i'm still on 0.82.2-alpha.

but i can tell you the above MAX thing does work as you describe, however that simply pre-populates the amount field by a simple Balance minus fee = amount, but does not appear to do any attempt to look at the actual built transaction. it's only *after* you press send that it does all that calculating, and if okay will present the confirmation screen. if not okay, it'll ask you to adjust the fee.

here's how the conversation goes...

me: send 5, fee X
armory: you need to add 0.02 BTC fee to send this
me: cancel that, send 4, fee X
armory: confirmation screen
me: cancel that, send 4.5, fee X
armory: you need to add 0.02 BTC fee to send this
me: cancel that, send 4.3, fee X
armory: confirmation screen
me: cancel that, send 4.4, fee X
armory: confirmation screen
me: cancel that, send 4.45, fee X
armory: you need to add 0.02 BTC fee to send this
me: cancel that, send 4.42, fee X
armory: confirmation screen
me: cancel that, send 4.43, fee X
armory: you need to add 0.02 BTC fee to send this
me: cancel that, send 4.425, fee X

etc, etc, complete "higher or lower" guessing game to actually arrive at the max value i can send for fee X.

as far as i can tell, the MAX button doesn't help at all in this scenario... kinda feels like the MAX button is like the 'javascript client side' processing and is merely a quick guess for the real calculation.


i'll update to the latest again anyway and see how things go... thanks!

What version are you using?  A couple of these have been done already.   I honestly can't remember when some of these were added, so grab 0.87.2 from the googlecode download page (which is stable, by the way):

http://code.google.com/p/bitcoinarmory/downloads/list

The latest version has:

• Ordinal numbers in the left column of the address listing.
• A while ago, I added a "MAX" button to the send-bitcoin screens so that it will fill in the exact amount for you.  If the fee is off, it will fix the fee for you, and you just click "MAX" again.
• In expert mode, you can select the change address to use.  It will save the setting between transactions, only for that wallet.  Unfortunately, there's no way to send change "always to imported address" since Armory can't generate new "imported addresses".  If you are okay with reusing addresses, then just put one of them in there, or just have it always sent back to the first input address.  This will guarantee that all coins stay in imported addresses.
• I haven't tested with 10k+ addresses, but in more-recent version of Armory, I have added some ledger optimizations that should make Armory behave much better with large wallets.  If you are not using the latest version, please upgrade and try it (there is some under-the-hood optimizations, as well as ledger paging).  If you still have issues with the latest version, then I have work to do...

The "manage its own blockchain data" is coming.  It's one of the major things on my todo list.  It will require quite a bit of testing, but Armory is finally ready to do it.  Along with managing Bitcoin-Qt itself.  I will add most of the other things you listed to my TODO list.  Admittedly, it sounds like you're a very heavy imported-address-user and dozens of wallets... which was not originally the focus of Armory's development -- don't get me wrong, I want to support your use case, it's just that most users only import a few addresses and make a couple wallets, so I've been focusing on that use case.  It definitely needs some extra attention for your use-case.