No real rush, like I said, I'd just prefer to start using compressed keys for everyone's sake. On that note, will compressed keys become the default key chain in the new wallets? And nested P2WPKH subsequently? I'm hardly expecting a no, I'm just wondering if you think that might cause an issue I'm not seeing.
There are 2 separate code paths for this:
1) Requesting payment addresses. This defaults to P2PKH. I did not add an option to change the default in the settings dialog, I'll have to deal with it eventually.
2) Change addresses. If left on auto, the code will try to match the spend script type. If all spend scripts are P2PKH, it will create a P2PKH change output and vice versa. When pay script types are mixed, auto will favor nested change types. In case of a SW tx, it will favor nested SW, otherwise nested P2PK.
This helps privacy at the cost of converting to compressed keys (or eventually SW) by default. You can however force the change type default to whatever you want in the setting dialog. You will receive a warning about reduced privacy if your change type differs from the pay script type however.
The drawbacks are 2 fold:
You cannot sign for nested types with pre 0.96 signers, and you can't expect to see your funds by simply importing the private keys in another wallet software and expect to see the balance of the nested scripts. These probably don't scan for these P2SH variations. I will most likely mitigate that by offering disgruntled users an opportunity to scan their wallets against my DB on demand, to create a tx and move their coins out in one sweep.
Quote
The scroll bar magic (that traverses super long balance lists) becomes stuck if I try to get beyond a certain proportion of the balance entries.
I'm just clicking, holding the click, and dragging the bar all the way to the base of the bar's range.
I'm just clicking, holding the click, and dragging the bar all the way to the base of the bar's range.
This doesn't trigger the Qt signal for hitting the end of the list until after you release the bar. I'm not sure where to get the signal for that event (if there's even one). I was aware of that limitation when I wrote this code but the cost of just figuring out how to get a signal off of the scroll bar is too high to bother as it is. It may appear lazy, but I settled for the model's signal, which won't trigger until after user input is completed. Hence is works by releasing the scroll bar, just using the arrows, or rolling the mouse scroller.
Quote
If the absence of server=1 can be detected, why not get Armory to produce an Error dialog box to tell the user how to deal with the issue? As I said, there'll be infinity threads about this if it's not handled at the software end somehow
I will eventually report the RPC status in the bottom right corner tooltip overlay. I don't intent to leave the bug there to begin with, it shouldn't prevent the DB from setting up.
