Skip to content

Conversation

@ieow
Copy link
Contributor

@ieow ieow commented Feb 12, 2025

Motivation and Context

Jira Link:
In this pr, the mpc corekit will be keyTypes and sigType agnostic.
it will throw error only during signing if the required keyTypes and tssLib is not available.

all keyTypes for

  • getTssData will have same
    • tssFactorPubs
  • getTssShare for same factor key
    • tssShareIndex

check the added new tests on how it can be call for different signing scheme

Description

Refactor multicurve

How has this been tested?

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

  • My code follows the code style of this project. (run lint)
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • My code requires a db migration.

@ieow ieow marked this pull request as ready for review February 21, 2025 21:35
Comment on lines 488 to 495
// sign(
// data: Buffer,
// opts?: {
// hashed?: boolean;
// secp256k1Precompute?: Secp256k1PrecomputedClient;
// keyTweak?: BN;
// }
// ): Promise<Buffer>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove if not needed.

why does the core kit interface no longer have a sign method? isn't this the most important method?

Copy link
Contributor Author

@ieow ieow Feb 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update with relevant function signatures and comments


public getTssData(args: { skipThrow: boolean; keyType?: KeyType } = { skipThrow: false }) {
const result = this.tkey.metadata.getTssData(args.keyType ?? this.keyType, TSS_TAG_DEFAULT);
public getTssData(args: { skipThrow?: boolean; keyType: KeyType }) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this skipThrow flag looks super odd. if you want to skip an error, just catch and discard!?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

break the function to 2 functions for more clearity

if (this._sigType === "ed25519" && this.options.useDKG) {
throw CoreKitError.invalidConfig("DKG is not supported for ed25519 signature type");
}
const nodeDetails = fetchLocalConfig(this.options.web3AuthNetwork, KeyType.ed25519);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you fix the key type to ed25519?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the nodedetails variables is used to get the metadata url.
It does not matter which keyType is used to get the node details.
We can replace with the spKeyType for consistency

Comment on lines 1277 to 1289
if (this.supportedCurveKeyTypes.has(KeyType.ed25519)) {
const importTssBufEd25519 = importTssKey.ed25519 ? Buffer.from(importTssKey.ed25519, "hex") : undefined;
// check if key is in the tsslib and keytype exists
await this.tKey.initializeTss({
importKey: importTssBufEd25519,
tssKeyType: KeyType.ed25519,
serverOpts: {
// selectedServers: [],
authSignatures: this.state.signatures,
},
});
}
} else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hu? why do you duplicate this part from below and nest it here? just move the below part out of the else and condition it like here!?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is different for initialising first curve and 2nd curve.
during initializing 2nd curve, factorPub, and tssIndex are not allowed to be provided,

updating the logic and comment for easier reading

private async copyOrCreateShare(newFactorTSSIndex: number, newFactorPub: Point) {
this.checkReady();
const tssData = this.getTssData();
const firstKeyType = this.getSupportedCurveKeyTypes()[0];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you use this a lot, I think you should create a dedicated function for it.
What's the logic behind always using the first key type here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I are trying to get tssIndex from getTssShare or factorPub from getTssData.
both curves should have the same tssIndex (for same factorKey) and factorPub
Using either curve's keyType will get the same value.

using the first as instance might configured with single curve keytype only


const { tssIndex } = await this.getTssShare(factorKey);
const firstKeyType = this.getSupportedCurveKeyTypes()[0];
const { tssIndex } = await this.getTssShare({ keyType: firstKeyType, factorkey: factorKey });
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this wrong? What if you want to get the ed25519 share but first key type is secp256k1? Same applies to several other instances of first key type usage.

Copy link
Contributor Author

@ieow ieow Feb 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I are trying to get tssIndex from getTssShare or factorPub from getTssData.
both curves should have the same tssIndex (for same factorKey) and factorPub
Using either curve's keyType will get the same value.

using the first as instance might configured with single curve keytype only

@matthiasgeihs
Copy link
Contributor

matthiasgeihs commented Feb 25, 2025

i think it would be good to merge this into the multi curve branch and then review together. why are the two PRs separated? @ieow

This was referenced Feb 26, 2025
ieow added 4 commits February 27, 2025 08:02
remove unsed code and comment
update new user comments and flow
update comment
@ieow
Copy link
Contributor Author

ieow commented Feb 27, 2025

i think it would be good to merge this into the multi curve branch and then review together. why are the two PRs separated? @ieow

The first pr is initial solution using setTkeyType to set active keyType
this current pr is keyType agnostic ( no active keyType)
previously there was was on discussion to choose which direction.
It was decided to use the agnostic direction.
Previous PR should be closed. I closed it yesterday.

Recent added new pr is support tkey's pr which add back the setTssTag instead of passing tag to most of the tkey tss function

since the prs is merged in tkey side, mpc-corekit prs is also merged

now there is only single pr in mpc core kit and tkey tss

@ieow ieow changed the base branch from feat/v4-multicurve to v4 February 27, 2025 07:06
fix ed25519 with accountIndex 0
fix useClientGeneratedTSSKey
fix typo
@matthiasgeihs matthiasgeihs self-requested a review February 27, 2025 17:09
ieow added 2 commits February 28, 2025 02:52
fix multicurve test to use new storage instance
fix useClientGeneratedTSSKey bug
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants