Strange address inconsistencies

[clemdementhe]

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?

[clemdementhe]

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.

[PhoenixFire]

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)

Unsure about the rest, but I can at least help with this part: See the changelog on github.

[clemdementhe]

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)

Unsure about the rest, but I can at least help with this part: See the changelog on github.

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

[goatpig]

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?

The wallet consistency check would catch that. If the offline signer does not recognize the change address, make sure you are using the exact same Armory version for online and offline operations. If that doesn't fix it, make sure the serialization of the unsigned tx is not malformed. For that, load the unsigned tx in both offline and online instances, see what comes out.

If all else fails, then maybe you have a real problem.

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

Addresses are bound to their chain index, not the derivation type. There's only 1 address chain in a wallet, and each asset on the chain can instantiated as any script type. Once an address is picked, you can't manually change the script type. If the script type on chain is different than the one in the wallet, that is rectified, but it only works on online machines obviously.

The offline wallet can recognize the "mismatching" addresses because it resolves the script to the actual asset.

[clemdementhe]

The wallet consistency check would catch that. If the offline signer does not recognize the change address, make sure you are using the exact same Armory version for online and offline operations. If that doesn't fix it, make sure the serialization of the unsigned tx is not malformed. For that, load the unsigned tx in both offline and online instances, see what comes out.

If all else fails, then maybe you have a real problem.

Addresses are bound to their chain index, not the derivation type. There's only 1 address chain in a wallet, and each asset on the chain can instantiated as any script type. Once an address is picked, you can't manually change the script type. If the script type on chain is different than the one in the wallet, that is rectified, but it only works on online machines obviously.

The offline wallet can recognize the "mismatching" addresses because it resolves the script to the actual asset.

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.

[clemdementhe]

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

[goatpig]

You can see it by spawning an address properties dialog from the tree in the wallet properties dialog.

[clemdementhe]

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?

[goatpig]

It does make checking a tx slightly more cumbersome compared to when there was just one list in-sync across the machines

I'll add filtering at some point.

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?

On the online machine? Can you select SW for recipient addresses? Is the checkbox greyed out? From where did you spawn the selection dialog?

[clemdementhe]

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.

[goatpig]

To be able to select SegWit addresses on the offline machine, you have to run the proper cli args. Look at the changelog for that:

https://github.com/goatpig/BitcoinArmory/blob/testing/changelog.txt#L14

The change selector will not pick a nested SW return address if there isn't at least one SW input in the tx. This is because SW was deployed as soft fork, therefor an opt-in feature. The implementation of SW in Armory intents to respect that disposition. Think of it this way: the software will not lead to coins in opt-in/new script types without some guarantee that there was deliberate user intent.

[clemdementhe]

This is because SW was deployed as soft fork, therefor an opt-in feature. The implementation of SW in Armory intents to respect that disposition. Think of it this way: the software will not lead to coins in opt-in/new script types without some guarantee that there was deliberate user intent.

...as it should be

To be able to select SegWit addresses on the offline machine, you have to run the proper cli args. Look at the changelog for that:

https://github.com/goatpig/BitcoinArmory/blob/testing/changelog.txt#L14

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!