Armory - Discussion Thread

[cypherdoc]

Am I really missing a search function for comments?

[1713423292]

1713423292

[1713423292]

1713423292

[1713423292]

1713423292

[etotheipi]

Am I really missing a search function for comments?

There is no search function.  Sorry.  I haven't yet figured out how display search results without doing a lot of work.  It's on my todo list.  I assume that sorting the column doesn't help? 

[payb.tc]

um, i haven't been following this thread for a while, but here i'll dump my current wish list:

• ability to vertically stretch the list of Available Wallets.
• ability to sort available wallets by Name, Security, or Balance (and have Armory actually remember that setting)
• ability to add a custom Filter to show transactions for a personally chosen group of wallets
• ability to Remove Imported Addresses in bulk
• ordinal numbers in first column of 'Addresses in Wallet' list
• ability to set permanent default to 'Multiple Keys' in Private Key Import
• ability to set permanent default to 'Import these addresses...' in Private Key Import
• option to always or never rescan after import, so it doesn't prompt every time
• option to keep Use wallet encryption unchecked by default on wallet creation dialogue
• get rid of header text and string "   (Imported)" when exporting list of addresses.
• handle the blockchain itself, without relying on qt
• option to only use imported or specific addresses when receiving change
• automatically calculate for me the maximum send amount for a given fee amount (instead of making me play a tedious game of higher/lower until it gives the confirmation screen)

and of course saved the best for last...

• ability to handle a wallet with 10,000 imported addresses on an i7 + 8gb RAM without 'Not Responding' for 10 minutes on every click

thanks for reading!

[etotheipi]

um, i haven't been following this thread for a while, but here i'll dump my current wish list:

• ability to vertically stretch the list of Available Wallets.
• ability to sort available wallets by Name, Security, or Balance (and have Armory actually remember that setting)
• ability to add a custom Filter to show transactions for a personally chosen group of wallets
• ability to Remove Imported Addresses in bulk
• ordinal numbers in first column of 'Addresses in Wallet' list
• ability to set permanent default to 'Multiple Keys' in Private Key Import
• ability to set permanent default to 'Import these addresses...' in Private Key Import
• option to always or never rescan after import, so it doesn't prompt every time
• option to keep Use wallet encryption unchecked by default on wallet creation dialogue
• get rid of header text and string "   (Imported)" when exporting list of addresses.
• handle the blockchain itself, without relying on qt
• option to only use imported or specific addresses when receiving change
• automatically calculate for me the maximum send amount for a given fee amount (instead of making me play a tedious game of higher/lower until it gives the confirmation screen)

and of course saved the best for last...

• ability to handle a wallet with 10,000 imported addresses on an i7 + 8gb RAM without 'Not Responding' for 10 minutes on every click

thanks for reading!

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.

[payb.tc]

• automatically calculate for me the maximum send amount for a given fee amount (instead of making me play a tedious game of higher/lower until it gives the confirmation screen)

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:

• 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.

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!

[etotheipi]

• automatically calculate for me the maximum send amount for a given fee amount (instead of making me play a tedious game of higher/lower until it gives the confirmation screen)

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:

• 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.

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.

...

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.

[etotheipi]

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.

ooooh, i figured out what it is.... what you describe is only valid where X != 0

i would argue that the option to send with zero fee be up to the individual, but i vaguely recall you being totally against such use.

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.

[payb.tc]

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.

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.

[payb.tc]

"What is the maximum amount I can send, with a fee of 0.01?"

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.

[wachtwoord]

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.

[payb.tc]

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.

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.

[TTBit]

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

[etotheipi]

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

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.

[bitpop]

Very nice

[TTBit]

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

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.

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

[etotheipi]

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.

[cypherdoc]

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

[etotheipi]

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

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. :-)

[payb.tc]

I'm guessing the cleanest way would be creating a new wallet and draining funds from an old wallet via the block chain (similar to how I switched from a reference client wallet to an armory wallet)?

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

[etotheipi]

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

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. :-)

I've heard you mention new wallets a few times now. For users like me, who have some deep storage wallets which we rarely touch, what will be required to update to the new wallets? I'm guessing the cleanest way would be creating a new wallet and draining funds from an old wallet via the block chain (similar to how I switched from a reference client wallet to an armory wallet)?

If we don't need the new features, will there be any reason to switch? I guess I'm also asking if the old wallets will remain fully functional in all future versions of Armory?

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.  

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

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.