feat: split business logic into services #44
Conversation
Codecov Report
@@ Coverage Diff @@
## main #44 +/- ##
=======================================
Coverage 76.92% 76.92%
=======================================
Files 6 6
Lines 52 52
Branches 12 12
=======================================
Hits 40 40
Partials 12 12 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Signed-off-by: homura <homura.dev@gmail.com>
Signed-off-by: homura <homura.dev@gmail.com>
Signed-off-by: homura <homura.dev@gmail.com>
Signed-off-by: homura <homura.dev@gmail.com>
Signed-off-by: homura <homura.dev@gmail.com>
Signed-off-by: homura <homura.dev@gmail.com>
Signed-off-by: homura <homura.dev@gmail.com>
|
|
||
| /** | ||
| * non-hardened derivation path, | ||
| * the corresponding public key will be stored in plain text, | ||
| * for example, the BIP-44 path `m / 44'/ 309'/ 0'/ 0 / 0` will store the public key of | ||
| * `m / 44' / 309' / 0' / 0` (external) and `m/44'/ 309'/ 0'/ 1` (internal) in plain text | ||
| */ | ||
| paths: NonHardenedPath[]; |
There was a problem hiding this comment.
Is there a scenario where user would pass in some path other than first external/change address, i.e. m / 44'/ 309'/ 0'/ 0 / 0 when calling initKeyStore? or this parameter only makes it more covenient for tests.
I think when a user creates a new wallet, he would only pass in password and mnemonic,
then getUsedLocks in ownershipService would be called to detect used locks and paths. So maybe move paths to OwnershipService
There was a problem hiding this comment.
Is the user you're referring to a Nexus contributor, or an end user of Nexus product?
There was a problem hiding this comment.
A user of Nexus Wallet
There was a problem hiding this comment.
I got it. A service can't be called by an end user of Nexus directly, it is just a way for organizing code.
Nexus cannot directly access the user's private key unless the user grants permission and enters the password for the WSS(Web3 Secret Storage). To derive addresses without a private key, we can use a non-hardened extended public key. For security reason, we don't encourage other modules to have direct access to the keystore or even the extended public key.
To initialize the keystore, we can use these "parent" path
- full-ownership (change: false):
m/44'/309'/0'/0 - full-ownership (change: true):
m/44'/309'/0'/1 - rule-based-ownership (change: false):
m/49'/309'/0'/0 - rule-based-ownership (change: true):
m/49'/309'/0'/1
await keystore.initKeystore({
paths: [`m/44'/309'/0'/0`, `m/44'/309'/0'/1`, `m/49'/309'/0'/0`, `m/49'/309'/0'/1` ]
})
// derived from `m/44'/309'/0'/0`
keystore.getPublickey(`m/44'/309'/0'/0/0`)
keystore.getPublickey(`m/44'/309'/0'/0/1`)
keystore.getPublickey(`m/44'/309'/0'/0/3`)
| /** | ||
| * derivation path of the private key, will be used to sign the message | ||
| */ | ||
| path: HardenedPath | NonHardenedPath; |
There was a problem hiding this comment.
HardenedPath should not be used to sign a message.
There was a problem hiding this comment.
is there anything wrong with using hardened path to sign messages?
There was a problem hiding this comment.
Nothing wrong with that, just in most cases the user(nexus contributor) would call signData with SignDataPayload, which is constructed of data and script, but A hardend path does'nt produce a lock.
There was a problem hiding this comment.
maybe we can only say that we won't use a hardened key to sign the message "now".
We don't restrict which key must be used to sign, maybe there will be a proposal to identify the user, for example, using m / identity', there are some scenarios that actually require for identity, such as voting.
There was a problem hiding this comment.
I get it. But in that case(using hardend path in voting Dapp), let's say using m/44'/309'/0' to sign a vote， the voting dapp will know every address of user(end user of nexus wallet), the privacy of UTXO doesn't exist any more.
There was a problem hiding this comment.
let's say using m/44'/309'/0' to sign a vote
The hardened key can only derive the child key from the parent private key, we can't derive the child key from m/44'/309'/0''s public key
And this is why only the NonhardenedPath can be access in keystore.initKeystore
There was a problem hiding this comment.
Ok I get it, I just misunderstood the crypto algorithm here.
How can the Voting Dapp know the weight of a ticket signed by m/identity' if the voting weight depends on the balance of signer's coin balance?
There was a problem hiding this comment.
The voting app is just one example of a dApp that might require an identity mechanism, and I think we can discuss how to calculate voting weight in another issue
| } | ||
|
|
||
| interface GetUnusedLocksPayload { | ||
| change?: boolean; |
There was a problem hiding this comment.
change lock should be used only when user issues a new transaction, so unused change locks should not be used in future transactions, maybe we don't need this option here?
There was a problem hiding this comment.
all unused locks can be used to assemble a transaction, and Nexus should expose an API for dApp to access them, including the change lock. let's imagine a simple scenario of transferring CKB
inputs:
- used_lock0: getLivecells[0]
- used_lock1: getLivecells[1]
- ...
outputs:
- unused_lock0(change): getUnusedLocks({ change: true })[0];
- target_lock: receiverLockThere was a problem hiding this comment.
According to bip-44, internal chains receive only coins that come from the associated external chains.
I think that means if the address index is n, then m/44'/309'/1/n should be used in outputs only when m/44'/309'/0/n is in the inputs of the transaction.
There was a problem hiding this comment.
I guess you misunderstood here, if you say change address can only be used in output, these change coin will never be spent anymore
Signed-off-by: homura <homura.dev@gmail.com>
Resolved #29
This PR dependent on #39, to
wallet_enableinrpc/walletImpl.tsTODO
main