Refactor/wallet generic signer #1783
Conversation
OBorce
commented
Jun 18, 2024
•
OBorce
commented
- add a generic signer provider for creating a software or a hardware signer
- make account key chain generic to allow using it with and without a VRF keychain
- add an implementation for the trezor signer
- copy auto generated trezor client to communicate with a connected trezor device
- add new hardware-wallet option when creating and opening a wallet in the CLI and RPC wallet commands
OBorce
force-pushed
the
refactor/wallet-generic-signer
branch
from
e1f4596 to
37b71b9
Compare
OBorce
force-pushed
the
refactor/wallet-generic-signer
branch
6 times, most recently
from
626b7d1 to
fb2af0d
Compare
OBorce
force-pushed
the
refactor/wallet-generic-signer
branch
from
726bb45 to
855cfce
Compare
node-gui/src/backend/backend_impl.rs
Outdated
| } | ||
| #[cfg(feature = "trezor")] | ||
| (WalletType::Trezor, _) => { | ||
| let client = make_cold_wallet_rpc_client(Arc::clone(&self.chain_config)); |
There was a problem hiding this comment.
why cold mode? I thought that's the whole point that hardware wallet is both convenient and secure.
There was a problem hiding this comment.
let's make it an error? Not sure if there is a use case for Trezor + Cold
OBorce
force-pushed
the
refactor/wallet-generic-signer
branch
2 times, most recently
from
1cd8110 to
c23f38d
Compare
OBorce
force-pushed
the
refactor/wallet-generic-signer
branch
from
c23f38d to
4824da8
Compare
OBorce
force-pushed
the
refactor/wallet-generic-signer
branch
4 times, most recently
from
6c3d058 to
037f258
Compare
| Destination::AnyoneCanSpend, | ||
| ), | ||
| TxOutput::DataDeposit(vec![1, 2, 3]), | ||
| TxOutput::Htlc(OutputValue::Coin(burn_amount), Box::new(hash_lock)), |
There was a problem hiding this comment.
there also should be a case for spending Htlc utxo with a secret
| assert!(!devices.is_empty()); | ||
| let client = devices.pop().unwrap().connect().unwrap(); | ||
|
|
||
| let mut signer = TrezorSigner::new(chain_config.clone(), Arc::new(Mutex::new(client))); |
There was a problem hiding this comment.
- There should be some negative cases: where trezor failed to sign inputs with unknown keys or something like that.
- How does device become aware of private keys? I see that at the beginning of the test a key chain is created from mnemonic, but how trezor is related to that I don't understand (like initialising it with test mnemonic of something)
There was a problem hiding this comment.
ok I keep forgetting that this is manual test. So basically you have to recover a wallet from test mnemonic right?
OBorce
force-pushed
the
refactor/wallet-generic-signer
branch
from
fd48654 to
511bba3
Compare
OBorce
force-pushed
the
refactor/wallet-generic-signer
branch
from
3b76519 to
46cf688
Compare
| TxOutput::ProduceBlockFromStake(_, pool_id) => { | ||
| let staker_balance = rpc_client | ||
| .get_staker_balance(*pool_id) | ||
| .await | ||
| .map_err(ControllerError::NodeCallError)? | ||
| .ok_or(WalletError::UnknownPoolId(*pool_id))?; | ||
| Ok(UtxoWithAdditionalInfo::new( | ||
| utxo, | ||
| Some(UtxoAdditionalInfo::PoolInfo { staker_balance }), | ||
| )) | ||
| } | ||
| TxOutput::IssueNft(_, _, _) |
There was a problem hiding this comment.
I find this somewhat scary. E.g. we're signing a raw transaction, which was created who knows when, and then here we're obtaining the pool balance which now may be different from the one that it had when the tx was created (e.g. due to a reorg). So we're basically producing potentially incorrect data and rely on it being ignored (because, as I can see, it's not used in places where this function is called).
Which makes me think that "dynamic" data, like pool balances (as opposed to "static" data, like token decimals) shouldn't be in UtxoWithAdditionalInfo.
But then it'd make sense to move the static data out of it as well, because e.g. it'd be more natural for token decimals to be stored in a single map and passed alongside PartiallySignedTransaction (or maybe it can still be a part of PartiallySignedTransaction, but not a part of individual utxos).
I wonder whether we should reconsider this whole approach with UtxoWithAdditionalInfo. @azarovh what do you think?
There was a problem hiding this comment.
Not sure there is a way around it because we have to display what is being signed and a tx has to have an output with specific decommissioned amount.
There was a problem hiding this comment.
The thing is that the same dynamic data is also used on tx creation and once you submit the tx to the node to validate the tx. So if it is wrong now it will also be wrong on submittion.
~~The only issue I see is if the user's node itself creates 2 blocks which cause a reorg. They create the tx while on the first block and then a reorg happens with the other block which can have more or less fees so the tx might be rejected if the new balance is less or silently accepted and the excess coins going to fees. ~~ actually the block id will be different and the utxo will not be the same
