Thanks, goatpig. Thats very helpful.

The use of Scrypt is re-assuring (I do now remember setting a long unlock). So even if the machine were accessed and the disk encryption broken, the keys themselves would be secure for long enough for the coins to be safely moved using a back-up. Though at the loss of plausible deniability!

I agree that the choice of such a weak process seems "unsettling", especially for single use - I can only imagine that 6 or 7 years ago (when I imagine 18 was being specced) it all seemed "good enough".

Jeff Garzik linked to this article suggesting older (18.04) Ubuntu encrypted disks might be vulnerable to brute-force attacks:

https://mjg59.dreamwidth.org/66429.html

A fresh install of a later distro (22.04?) would seem to plug the possible vulnerability.

Does Armory offline run on Ubuntu 22.04?

In passing, this made me wonder if the Armory transaction-signing / key-exposing password has any anti brute-forcing mitigations? Could a 20+ mixed character password still survive today's attacks?

It can take several hours for Armory to scan the entire blockchain for activity relevant to what it sees as a new wallet. This log shows only an hour of scanning.

I'm afraid that isn't "all blockchain", you're only seeing activity up to about late 2015 (your 390783 number) so your recent transaction won't be visible yet. Current block height is 506349.

...as it should be


I had run the arguments successfully when I changed the received address type - I must've restarted armory without them before trying to change the change address type. Doh.

- and thank you achow101 for the 'merits' - who knew something I knew nothing about would make me smile!

No, on the offline.

Sending from a P2PKH to several P2SH-P2WPKH (with the Change Address Type settings left as auto), I'd assumed that the signer would send the change to P2SH-P2WPKH as that was what the Preferred Receive Address Type was set to (and the Change Address Type set to auto).

When it actually went to a P2SH-P2PK, I tried the 'Force a script type' and it was there that Segwit was greyed out.

Using the index numbers it was possible to see what happened. The online and offline instances had indeed generated new addresses of different types at different times. For example, the signer had a batch of 84 'extra' addresses allocated as P2PKH where the onlines had allocated batches of 40 and 32 addresses.

It does make checking a tx slightly more cumbersome compared to when there was just one list in-sync across the machines, but with the forced consistency check and the ability to choose an address that does also appear on the now-displayed signer's list, all is well.

As to the initial non-recognition of a wallet address, after the usbs in/outs and reboots, I couldn't reproduce it and am putting it down to a glitch in the matrix or "my bad" somewhere along the line.

Many thanks for the quick help.

The only other thing that came up is that it doesn't seem possible to choose P2SH-P2WPKH as a change address - is that waiting for Core's 0.16 improved segwit?

...and is there a way to see the address index number? even if the number sequence jumps haphazardly across the different address types?

Ah, I didn't realise all types follow the chain index (makes sense) - so my different wallet instances may just have "slipped out of sync" because different numbers of various types have been generated over time. I'll look into that and see if I can get them back in line.

And (hopefully) the original tx with an unrecognised address may just have been malformed in some way. I'll see if I can re-create the problem.

They are all running the same version number (except the signer is no-asm). I'll report back. Many thanks.

Thanks for that. So, yes, that let me generate segwit addresses on the signing machine, but now I'm really confused. The dozen that it generated just now were unique, and not on the lists (as far as i can see) of either of those generated by the online machines. So all three machine are generating (or at least displaying) different lists of segwit addresses.

However, the signing machine did manage to sign a small segwit to segwit test that I did (though these addresses haven't appeared on its list), and has recognised other (at least some) receiving segwit addresses as belonging to my wallets. But not all...

Is there a way I can I get the signing machine to show (the first 50?) P2SH-P2WPKH addresses for a wallet?

Armory used to index number addresses, which was useful, is there still a way to see generated order? It would be useful in a situation like this, where some addresses seem unexpected, to have an index number.

I've been using the low fees of the last few days to move some balances into new segwit addresses. I'm using 0.96.3.992 on Ubuntu 16.04 for both online and offline.

Usually the offline signer confirms that receiving address is indeed in one of my wallets, but this last time it didn't, just listing the 3... destination address. I thought this unusual. I haven't yet figured out how to get the offline to list the wallet segwit addresses ("preferred receive address type" has P2SH-P2WPKH greyed out) so I started up my mirror online machine (not great practice I know, but I like to have one working machine during upgrade procedures). On this "machine B", which is as far as I know identical to the "machine A" that generated the transaction, and has up to now has shown the same many transactions and addresses, the wallet's unused segwit addresses are completely different! I abandoned that tx. A test tx generated on machine B did have the offline machine recognise the segwit receiving address.

I'm worried that somehow machine A has had its receiving addresses replaced by external ones to which I do not have the keys. Surely this isn't possible?

Obviously I can delete and rebuild online machine A, but should I look into this further?

if it saves you some research time, I was in a similar position and found that the HP Stream 11 is 64 bit and will take 16.04 with no problems. It did seem to need the noasm version of armory tho, which surprised me. It's also very cheap atm, with plenty of refurbs/returns on the bay. I also liked that it has an A4 footprint so will fit into standardised secure places...

Thanks, Mr.Vice, for the detailed answer.

I'm reluctant to mess with the offline machine so will probably stay old skool for my cold storage.

- apologies, my offline is actually running 0.92.3 - same question tho!

Happily running 96.2 on the online machine. I'd like to start using segwit addresses, but just want to check that my offline 93.3 can sign segwit transactions ok? or would the offline need upgrading as well? Thanks.

Ah, of course, that makes sense now. Thanks for taking the time. That was a potential vulnerability I'd missed but will now take into account.

Thanks. I thought the chaincode was wallet-specific. I'll have to do more reading...

If you have the time, would you mind explaining why? Or point us to an explanation? Is there even a way to know that an address has been generated from a seed? Thanks.

A-ha! Thanks.