Raspberry Pi: strange performance.

[picobit]

Hi,

I just reinstalled a Raspberry Pi with the latest Armory offline bundle.  While testing and backing up, I notices something very strange.  Signing a transaction from the online computer takes about 30 sec, that is what I am used to with the old version, or perhaps a bit slower.  After the test, I wanted to make a paper backup.  But unlocking the wallet to create a paper backup took more than 10 min, closer to 15 min.  Most of the time it just said "Unlocking wallet" while a progress bar slowly moved.   I understand and accept that EC math is bound to be slow on a RPi.  But I would think that signing a transaction also requires unlocking the file?  How can signing be so much faster.

In case it matters: I made this wallet from external entropy (shuffling a deck of cards, SHA-256 of the sequence, convert to Armory backup alphabet and "restore").  Before that, I made a test wallet where Armory generated the wallet seed.  I did not sign any transactions, but I tested that the various windows could open in Armory, before deciding to create a paper backup and testing my plan for "offline printing".  In that case unlocking the wallet was also slow, but only of the order of a minute or two.  Why is my "real" wallet so much slower?  I did not mess with any advanced options.

I can of cause live with slowness when making paper backups as long as signing is fast.

[goatpig]

The encryption code uses scrypt's precursor to derive the encryption key from your password (that's to reduce the brute force attack vector). When the wallet is encrypted for the first time, Armory defaults to a flat derivation processing time (I think ~2sec).

That time is obviously based on the performance of the machine encrypting the wallet. Take that back to a RPi, and what was expected to be 2 sec will become much longer. You can manually set the kdf size for your wallet in order to reduce that time. Or restore the wallet through your backup on the Pi and encrypt from it instead.

There is also another case. If your wallet has address entries without the private keys (if you extended the chain without decrypting the wallet first), it will have to compute the missing keys up until the highest one needed in for the transaction to be signed, which is outrageously long on a RPi. This will only happen once per missing key however.

[picobit]

The encryption code uses scrypt's precursor to derive the encryption key from your password (that's to reduce the brute force attack vector). When the wallet is encrypted for the first time, Armory defaults to a flat derivation processing time (I think ~2sec).

That time is obviously based on the performance of the machine encrypting the wallet. Take that back to a RPi, and what was expected to be 2 sec will become much longer. You can manually set the kdf size for your wallet in order to reduce that time. Or restore the wallet through your backup on the Pi and encrypt from it instead.

There is also another case. If your wallet has address entries without the private keys (if you extended the chain without decrypting the wallet first), it will have to compute the missing keys up until the highest one needed in for the transaction to be signed, which is outrageously long on a RPi. This will only happen once per missing key however.

I created the wallet on the RPi, so the scrypt precursor should be fitting for that machine.  I reinstalled everything to test my backup recovery plan (a bit paranoid, but better safe than sorry).  I then restored the wallet from paper backup on the RPi.  It took like 15 min of calculations.  I then tried signing a new transaction, must have been key number 4 or 5 in the chain.  That again took 15 minutes.  I never saw that on my old wallet, where it would always take less than a minute.  I ran "top" in a terminal window, it showed that the CPU usage of Python was fluctuating, and often the CPU load would be a significant percentage of "waiting".  I wonder if a bad SD card could cause that.  I am going to try a new one, if that does not help I will transfer the wallet to the old SD card with an older version of Armory and downgrade the online version.

[goatpig]

Was the wallet consistency check running by any chance?

[picobit]

Was the wallet consistency check running by any chance?

I don't know.  It could be running simultaneously in a separate thread.  The user interface did not indicate it, but it might be.

Is there a way to disable the wallet consistency check?  An inconsistent watch-only wallet would be a disaster, but if something happens with the "real" wallet all that happens is that I would not be able to sign until it was fixed.  On the other hand, if the consistency check takes 15 min on a RPi, it is a problem.

[goatpig]

Was the wallet consistency check running by any chance?

I don't know.  It could be running simultaneously in a separate thread.  The user interface did not indicate it, but it might be.

Is there a way to disable the wallet consistency check?  An inconsistent watch-only wallet would be a disaster, but if something happens with the "real" wallet all that happens is that I would not be able to sign until it was fixed.  On the other hand, if the consistency check takes 15 min on a RPi, it is a problem.

The consistency check at start up runs in its dedicated thread. If you don't see a progress bar in the bottom left corner then it isn't running at all. The consistency check should be disabled by default on ARM archs (i.e. RPi) I'm asking partly to make sure this is in place.

As for the signing, this may be a first time thing only. I presume you initiated the offline transaction from a WO with some history already. It is possible it picked a change address that wasn't on the restored (RPi) full wallet chain (yet), or that it was on the chain but deep enough that it triggered a chain extention (which comes in batches of 100 addresses at a time).

Did you try signing another transaction with that wallet?

[picobit]

You seem to have nailed it.  I installed on a better SD card today, no difference.  Signing the first transaction took forever (10 - 15 min), but signing number two took only seconds.

Problem solved!