Both @mswilkison and @derekpierre have experienced this problem when using a staking CLI command with a specified address (e.g., --staking-address 0xfoobar). The error manifests as an authentication problem with Geth:

ValueError: {'code': -32000, 'message': 'authentication needed: password or unlock'}

The problem is somewhat elusive and it's a mixture of several things:

• When the StakeHolder is used in the stake CLI, it's created before the password is known, since this step is performed during the initial setup, before command actions are considered. In other words, when the StakeHolder is created the password is still None.
• TransactingPowers are initialized as device if the supplied password is None. Do we really want to do this? There's currently a TODO in that line of code asking if there's a better way. What about a new explicit parameter device? Said parameter can be based on the value of the --hw-wallet flag.
• When activating a TransactingPower, it's expected that a supplied password overrides whatever password was used during initialization. However, StakingWallet introduces a cache of TransactingPowers. How can we reconcile both approaches when the TransactingPower thinks it's a device? They are contradictory.

The net effect of all these aspects, is that if a StakeHolder is created with an initial account by means of a CLI parameter, its corresponding TransactingPower is created as a device, and since this power is cached, it will not change, even if the password is provided later (since the user is prompted later).

I'd like to implement the fix for this in biznaga, but I'd also like your opinion on the best way forward. Personally, I think that explicit initialization of TransactingPower as device should be enough.