-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
@chesterliliang i'm having trouble getting this to work on linux. are there specific drivers needed? here's the output:
note that it leave the terminal in a broken state after running, too. |
@gavofyork Linux should have CP2102 driver. The port could be listed by 'mesg | grep ttyS*'
I will try to figure out why. |
it looks a bit like it's opening & writing to the standard i/o instead of the UART. |
|
Device not in the list.. well, do you use ubuntu 18.x? And just for a remind, plz plug the usb connector to the blue board. I put it into another one sometimes.. |
ubuntu 19.04 |
Here is a reference to see if the device works on linux: The product will switch to USB-HID finally, so it will not need driver for every platform. I thought UART is simple enough for early use but it seems it's not ture. T_T |
@gavofyork is your 19.04 the desktop or server version? |
desktop; i'm back to working on macos and it's ok again |
impl Wallet for Wookong { | ||
type Pair = sr25519::Pair; | ||
fn derive_public(&self, _path: &[DeriveJunction]) -> Result<Public> { | ||
// TODO: pass through _path and _password to mutate the key on the device accordingly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chesterliliang this needs implementing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. I am on it. But for the password.. the hardware wallet always has one password for all accounts and the device will keep the password for verify. Device api functions like
fn verify_password(password);
fn change_password(old, new);
could be provided. And we could call verify function here. But the derive will not depend on password as salt but just the path. Is that OK?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah - sorry the _password
is old and doesn't need to be implemented at all.
} | ||
} | ||
fn sign(&self, _path: &[DeriveJunction], message: &[u8]) -> Result<Signature> { | ||
// TODO: pass through _path and _password to mutate the key on the device accordingly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chesterliliang this needs implementing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we verify password as well when do the sign?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no - can ignore _password
- it's part of an old design and not relevant any more.
} | ||
|
||
/// Unit type representing the Wookong hardware wallet. | ||
pub struct Wookong; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chesterliliang if the device can be made to support multiple root keys (which would be nice, i think) then this could be changed thus:
pub struct Wookong {
account: sr25519::Public,
}
impl Wookong {
fn with_account(account: sr25519::Public) -> Self { Wookong { account } }
}
the Wallet
functions for it would then feed self.account
through to the hardware to ensure it operated on the right account.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If they are root keys(seed? before derive), we could find them by index, it seems hardware can not know which one is the right by account.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, then they can be enumerated which isn't so great for privacy.
couldn't it just store the public keys along with the roots and cycle through those that it know until it either finds the correct one or returns some KeyNotFound
error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's possible but must under the same derive path or same rule to manage the path. Seems not a big trouble. Will try to give an implementation for further discussion.
Just fyi @chesterliliang we'll eventually "repair" the missuse of i and the chain code by SURI. See w3f/schnorrkel#45 and #3396 We'll play some tricks to keep all current derivations the same, which requires a coordinated upgrade of both subkey and schnorrkel, but I wanted to warn you. :) |
@burdges Thanks Jeff. Don't worry about us since we just start to work on derive part. Could you plz provide one, just one test vector if the issue is fixed? |
We'll avoid currently allowable test vectors changing. Yet, subkey will continue to not use chaincodes for the questionable purpose for which bip32 added them, so maybe some future wallets will use it in incompatible ways. I'm just warning about this future interface change on schnorrkel |
is this still being worked on? |
No... Team has financial problem.. plz close it... |
Rework (mostly a rewrite) of #3667.