Armory - Discussion Thread

[etotheipi]

Does your wallet have lots of transactions with tons of inputs and outputs?  For instance, we noted huge lagging when we loaded a wallet that had 100 transactions, each of which had 1,000+ outputs (even though only one output was related to the user's wallet).

I would guess maybe a dozen addresses, maybe 60 incoming transactions, and maybe a dozen outbound transactions.

A very similar wallet loads fine. The only major difference between the two is that the one that does not crash only has one outbound transaction.

Just in case it has to do with the wallet itself, can you try making a backup of it, then use the menu item "Wallets"->"Recover Damaged Wallet".  Do a full recovery.  Then try it agian (you can do it from offline mode, then restart Armory).

[1714125923]

1714125923

[1714125923]

1714125923

[1714125923]

1714125923

[1714125923]

1714125923

[1714125923]

1714125923

[Zoella]

Does your wallet have lots of transactions with tons of inputs and outputs?  For instance, we noted huge lagging when we loaded a wallet that had 100 transactions, each of which had 1,000+ outputs (even though only one output was related to the user's wallet).

I would guess maybe a dozen addresses, maybe 60 incoming transactions, and maybe a dozen outbound transactions.

A very similar wallet loads fine. The only major difference between the two is that the one that does not crash only has one outbound transaction.

Just in case it has to do with the wallet itself, can you try making a backup of it, then use the menu item "Wallets"->"Recover Damaged Wallet".  Do a full recovery.  Then try it agian (you can do it from offline mode, then restart Armory).

0 errors where found (sic)

[Zoella]

Does your wallet have lots of transactions with tons of inputs and outputs?  For instance, we noted huge lagging when we loaded a wallet that had 100 transactions, each of which had 1,000+ outputs (even though only one output was related to the user's wallet).

I would guess maybe a dozen addresses, maybe 60 incoming transactions, and maybe a dozen outbound transactions.

A very similar wallet loads fine. The only major difference between the two is that the one that does not crash only has one outbound transaction.

Just in case it has to do with the wallet itself, can you try making a backup of it, then use the menu item "Wallets"->"Recover Damaged Wallet".  Do a full recovery.  Then try it agian (you can do it from offline mode, then restart Armory).

0 errors where found (sic)

Interesting. I tried making an unencrypted backup and Armory crashed with the following error...

terminate called after throwing an instance of 'CryptoPP::InvalidKeyLength'
  what():  AES/CFB: 0 is not a valid key length
Aborted

I then tried running a recovery on the decrypted version and it said 999 errors...

Recovering wallet armory_***_decrypt.wallet (ID: ***) on Tue Mar 18 16:02:45 2014
Using full recovery mode
Wallet contains private keys and uses encryptionThe wallet file is 260107 bytes, of which 260107 bytes were read
1000 chain addresses, 999 imported keys and 0 comments were found
Found 1000 chained address entries
No byte errors were found in the wallet file
The following 999 addresses were not arranged sequentially in the wallet file:

 <snip>

There are no gaps in the address chain
No chained address fork was found
No chaincode corruption was found
All chained public keys are valid EC points
No chained public key is missing
All entries were saved under their matching hashVal
All chained public keys match their respective private keys
Found 999 imported address entries
No errors were found within the imported address entries
999 errors where found
Recovery done

I then backed up the wallet again (encrypted) and performed a recovery and got 998 errors...

Recovering wallet armory_***_encrypt.wallet (ID: ***) on Tue Mar 18 16:08:11 2014
Using full recovery mode
Wallet contains private keys and uses encryptionThe wallet file is 260107 bytes, of which 260107 bytes were read
1000 chain addresses, 999 imported keys and 0 comments were found
Found 1000 chained address entries
No byte errors were found in the wallet file
The following 998 addresses were not arranged sequentially in the wallet file:

   <snip>

There are no gaps in the address chain
No chained address fork was found
No chaincode corruption was found
All chained public keys are valid EC points
No chained public key is missing
All entries were saved under their matching hashVal
All chained public keys match their respective private keys
Found 999 imported address entries
No errors were found within the imported address entries
998 errors where found
Recovery done

The initial recovery that found zero errors was done in online mode, the next two done offline.

[goatpig]

Save sequence is not an error in itself, it's a clue as to what the user may have done with his wallet. In this case it doesn't indicate any error, your wallet is fine. The decrypt key error is significant. I'm not sure I understand though: did the decrypted backup error happen before or after the wallet file was created?

[Zoella]

Save sequence is not an error in itself, it's a clue as to what the user may have done with his wallet. In this case it doesn't indicate any error, your wallet is fine. The decrypt key error is significant. I'm not sure I understand though: did the decrypted backup error happen before or after the wallet file was created?

After/During the creation of the file. I was watching as the progress bar moved to about 50%, then switched away for another task. When I returned the only thing open was the terminal window. That error was the last thing in the terminal window when Armory crashed and returned me to a prompt.

[goatpig]

Save sequence is not an error in itself, it's a clue as to what the user may have done with his wallet. In this case it doesn't indicate any error, your wallet is fine. The decrypt key error is significant. I'm not sure I understand though: did the decrypted backup error happen before or after the wallet file was created?

After/During the creation of the file. I was watching as the progress bar moved to about 50%, then switched away for another task. When I returned the only thing open was the terminal window. That error was the last thing in the terminal window when Armory crashed and returned me to a prompt.

Then it probably happened at the end. Was the process particularly long? Like over a minute?

Connected (29XXX Blocks)

Did you forget a X or are you showing only 29k blocks?

getSpendable errors are also just a symptom of a locked up BDM. Definitely the wallet. Consider sending us the watching only, it would make this whole process entirely faster, and I could push the fix with the next release.

[Zoella]

Save sequence is not an error in itself, it's a clue as to what the user may have done with his wallet. In this case it doesn't indicate any error, your wallet is fine. The decrypt key error is significant. I'm not sure I understand though: did the decrypted backup error happen before or after the wallet file was created?

After/During the creation of the file. I was watching as the progress bar moved to about 50%, then switched away for another task. When I returned the only thing open was the terminal window. That error was the last thing in the terminal window when Armory crashed and returned me to a prompt.

Then it probably happened at the end. Was the process particularly long? Like over a minute?

Connected (29XXX Blocks)

Did you forget a X or are you showing only 29k blocks?

getSpendable errors are also just a symptom of a locked up BDM. Definitely the wallet. Consider sending us the watching only, it would make this whole process entirely faster, and I could push the fix with the next release.

I would guess about 30 seconds, and yes, left off an X. With no wallets, showing 291229 right now.

[Zoella]

OK, frustrated to the point where I'm ready to create a new wallet. I'm trying to sweep in the BTC from the old wallet, and it is not working. Here's what I'm doing, please tell me if I'm missing something...

1) export key list from old wallet
2) open wallet, select import/sweep
2) choose sweep, single key
3) enter base58 key from export list (for an address I know is not empty)
4) verify corresponding address is correct and click yes

Armory then requests to scan the blockchain for another 30 minutes, creates a new address in my new wallet (presumably for swept funds), and then...nothing. This happens with every private key from the list I've tried. I've verified the address is not empty via blockchain.info (when it's up).

Thoughts?

[goatpig]

OK, frustrated to the point where I'm ready to create a new wallet. I'm trying to sweep in the BTC from the old wallet, and it is not working. Here's what I'm doing, please tell me if I'm missing something...

1) export key list from old wallet
2) open wallet, select import/sweep
2) choose sweep, single key
3) enter base58 key from export list (for an address I know is not empty)
4) verify corresponding address is correct and click yes

Armory then requests to scan the blockchain for another 30 minutes, creates a new address in my new wallet (presumably for swept funds), and then...nothing. This happens with every private key from the list I've tried. I've verified the address is not empty via blockchain.info (when it's up).

Thoughts?

To sweep, Armory needs to know the available UTXO for the private key. To do that it goes through the same scanning process as if these private keys were loaded with your old wallet. This method will not help you.

[etotheipi]

We literally just fixed a bug in the sweep code, like 2 hours ago.  Pull 0.91-dev and try again.

I'm not convinced this won't work.  If anything it will help debug the problem.  This will probably work for some of the keys, and maybe one in particular it will fail. 

[Zoella]

OK, frustrated to the point where I'm ready to create a new wallet. I'm trying to sweep in the BTC from the old wallet, and it is not working. Here's what I'm doing, please tell me if I'm missing something...

1) export key list from old wallet
2) open wallet, select import/sweep
2) choose sweep, single key
3) enter base58 key from export list (for an address I know is not empty)
4) verify corresponding address is correct and click yes

Armory then requests to scan the blockchain for another 30 minutes, creates a new address in my new wallet (presumably for swept funds), and then...nothing. This happens with every private key from the list I've tried. I've verified the address is not empty via blockchain.info (when it's up).

Thoughts?

To sweep, Armory needs to know the available UTXO for the private key. To do that it goes through the same scanning process as if these private keys were loaded with your old wallet. This method will not help you.

Wonderful. So what method helps me recover the BTC in a 1.35c paper backup?

[Zoella]

We literally just fixed a bug in the sweep code, like 2 hours ago.  Pull 0.91-dev and try again.

I'm not convinced this won't work.  If anything it will help debug the problem.  This will probably work for some of the keys, and maybe one in particular it will fail.  

Will give it a shot.

Making. Should I redownload the blockchain as well?

[etotheipi]

We literally just fixed a bug in the sweep code, like 2 hours ago.  Pull 0.91-dev and try again.

I'm not convinced this won't work.  If anything it will help debug the problem.  This will probably work for some of the keys, and maybe one in particular it will fail.  

Will give it a shot.

Making. Should I redownload the blockchain as well?

Nope.  Just pull the latest 0.91 and try sweeping again

[Zoella]

Well it sort of worked on one address. For some reason it left .04 BTC?

I received an invalid transaction error, but it seems to have worked (except for the .04 BTC). Thoughts before I try it on other addresses or retry on this one for the remainder?

https://blockchain.info/address/1JaZiwrMyfYXiNuAdq6cBknJHtQAQFCxUg

[etotheipi]

Ugh, looks like it worked, but your blockchain wasn't fully up to date.  The 0.4 left is the last three outputs received by that address.

Also, I can see that you did fall into this category I asked about (users don't always know if they are in this category).  Each transaction received by that address has tons of outputs.  The first one has 1,400 TxOuts of which you are only one.

Armory has a known inefficiency when it comes to transactions that huge, and you have a wallet full of them, so that's as bad as it gets.  The good news is most of the processing that's slowing it down turns out to be non-critical (it's for associating address and tx labels with the rows in the ledger), but still important.  We might see if we can find a way to disable it on wallets in this category, of if maybe we can just find a more efficient way of doing it.

For now, sweeping should work as long as Armory is fully synchronized.  Scanning the blockchain to sweep the addresses should work at "normal" speed, it's just populating the main window ledger that takes forever and Armory trips over itself while it waits.

[Zoella]

Ugh, looks like it worked, but your blockchain wasn't fully up to date.  The 0.4 left is the last three outputs received by that address.

Also, I can see that you did fall into this category I asked about (users don't always know if they are in this category).  Each transaction received by that address has tons of outputs.  The first one has 1,400 TxOuts of which you are only one.

Armory has a known inefficiency when it comes to transactions that huge, and you have a wallet full of them, so that's as bad as it gets.  The good news is most of the processing that's slowing it down turns out to be non-critical (it's for associating address and tx labels with the rows in the ledger), but still important.  We might see if we can find a way to disable it on wallets in this category, of if maybe we can just find a more efficient way of doing it.

For now, sweeping should work as long as Armory is fully synchronized.  Scanning the blockchain to sweep the addresses should work at "normal" speed, it's just populating the main window ledger that takes forever and Armory trips over itself while it waits.

Ahh, I thought you meant tons of transactions directly to the address, not single transactions to tons of different addresses. I kind of figured this would be a common thing for pooled mining?

So, regarding the blockchain being up to date. The wallet says it fully synced, showing 291259 blocks. The last transaction on that address was block 290240. You're right that the last three didn't get scraped, but that seems kind of weird? I'll try it again and see what happens.

[Rock6.3]

Ugh, looks like it worked, but your blockchain wasn't fully up to date.  The 0.4 left is the last three outputs received by that address.

Also, I can see that you did fall into this category I asked about (users don't always know if they are in this category).  Each transaction received by that address has tons of outputs.  The first one has 1,400 TxOuts of which you are only one.

Armory has a known inefficiency when it comes to transactions that huge, and you have a wallet full of them, so that's as bad as it gets.  The good news is most of the processing that's slowing it down turns out to be non-critical (it's for associating address and tx labels with the rows in the ledger), but still important.  We might see if we can find a way to disable it on wallets in this category, of if maybe we can just find a more efficient way of doing it.

For now, sweeping should work as long as Armory is fully synchronized.  Scanning the blockchain to sweep the addresses should work at "normal" speed, it's just populating the main window ledger that takes forever and Armory trips over itself while it waits.

If I understand your statement correctly, you are saying that Armory is a bad wallet choice for mining pool participants who are paid out in batches.

[Zoella]

Just an update, I was able to completely sweep another key last night. There may be other issues with the sweep function though (unless it is simply the batch transaction issue again), but I can only do one key at a time, and I have to restart Armory in-between attempts. For some reason, I have not been able to succeed at sweeping multiple keys in a single go, nor any keys after a successful sweep. Hopefully I can finish up today though, thanks for all the help!

[Zoella]

Ugh, looks like it worked, but your blockchain wasn't fully up to date.  The 0.4 left is the last three outputs received by that address.

Also, I can see that you did fall into this category I asked about (users don't always know if they are in this category).  Each transaction received by that address has tons of outputs.  The first one has 1,400 TxOuts of which you are only one.

Armory has a known inefficiency when it comes to transactions that huge, and you have a wallet full of them, so that's as bad as it gets.  The good news is most of the processing that's slowing it down turns out to be non-critical (it's for associating address and tx labels with the rows in the ledger), but still important.  We might see if we can find a way to disable it on wallets in this category, of if maybe we can just find a more efficient way of doing it.

For now, sweeping should work as long as Armory is fully synchronized.  Scanning the blockchain to sweep the addresses should work at "normal" speed, it's just populating the main window ledger that takes forever and Armory trips over itself while it waits.

If I understand your statement correctly, you are saying that Armory is a bad wallet choice for mining pool participants who are paid out in batches.

I guess it depends on what mining pool. My wallet that collects my Eligius payouts has been OK (but I will have to import and check again). The addresses I'm having problems with in this wallet are scrypt coin switching pools (PoolWaffle, Middlecoin, etc.).

I would definitely think resolving this would be a priority since so many of these types of pools have popped up recently. Then again, it may just be my bias reflected by me being caught in the situation. Definitely not fun.

[etotheipi]

Just an update, I was able to completely sweep another key last night. There may be other issues with the sweep function though (unless it is simply the batch transaction issue again), but I can only do one key at a time, and I have to restart Armory in-between attempts. For some reason, I have not been able to succeed at sweeping multiple keys in a single go, nor any keys after a successful sweep. Hopefully I can finish up today though, thanks for all the help!

Did you try using the "Multiple Keys" sweep option at the top?  It was designed for this

If you don't mind doing one test for us, I just pushed the disablecomments branch to the BitcoinArmory repo.  I removed all the logic I think is slowing you down.  If our hypothesis is right, this will work.  This is the best I can do without getting your watching-only wallet.  


P.S. --

I really appreciate you being so patient!  Seriously, thanks.  Hopefully, as we go back through some other support requests, we'll see that most of them are due to this.  Admittedly, I don't do any mining, or have any enormous tx like this in my ledger (and apparently no one on our team, either).  Also, this did come up 18 months ago, and I made a huge efficiency fix that was supposed to fix it.  But apparently not efficient enough...