Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge TinySecp interface into Zkp #85

Open
altafan opened this issue Nov 9, 2022 · 2 comments
Open

Merge TinySecp interface into Zkp #85

altafan opened this issue Nov 9, 2022 · 2 comments
Assignees

Comments

@altafan
Copy link
Collaborator

altafan commented Nov 9, 2022

SInce secp256k1-zkp is like an extended version of secp256k1, we can merge the tiny secp interface defined in ecpair into Ec of our Zkp interface so that this interface can be used for both blinding and signing transactions.

@altafan altafan changed the title Merge TinySecp interface into Zkp one Merge TinySecp interface into Zkp Nov 9, 2022
@tiero
Copy link
Member

tiero commented Dec 23, 2022

Just to mention that we can move to @noble/secp256k1 for normal ECC operations, its 0-dependency and audited.

Although for rangeproofs we need an impl, that should come either from our WASM or the upcoming ObjectiveC/Java for React Native.

To be compatible with TinySecp we can have this wrapper synonymdev/bitkit#549

@altafan
Copy link
Collaborator Author

altafan commented Feb 21, 2023

My proposal is to move the current interfaces living in confidential.ts to a brand new file secp256k1-zkp.ts with the following changes:

// TinySecp256k1Interface imported from 'ecpair'
export interface Ecc extends TinySecp256k1Interface {
  privateMul(key: Uint8Array, tweak: Uint8Array) => Uint8Array
};

interface Generator {
  generate: (seed: Uint8Array) => Uint8Array;
  generateBlinded(key: Uint8Array, blinder: Uint8Array): Uint8Array;
}

interface Pedersen {
  commitment(value: string, generator: Uint8Array, blinder: Uint8Array): Uint8Array;
  blindGeneratorBlindSum(
    values: Array<string>,
    valueBlinders: Array<Uint8Array>,
    assetBlinders: Array<Uint8Array>,
    nInputs: number,
  ): Uint8Array;
}


interface RangeProof {
  info(proof: Uint8Array): {
    exp: string;
    mantissa: string;
    minValue: string;
    maxValue: string;
  };
  verify(
    proof: Uint8Array,
    valueCommitment: Uint8Array,
    assetCommitment: Uint8Array,
    extraCommitment?: Uint8Array,
  ): boolean;
  sign(
    value: string,
    valueCommitment: Uint8Array,
    assetCommitment: Uint8Array,
    valueBlinder: Uint8Array,
    nonce: Uint8Array,
    minValue?: string,
    base10Exp?: string,
    minBits?: string,
    message?: Uint8Array,
    extraCommitment?: Uint8Array,
  ): Uint8Array;
  rewind(
    proof: Uint8Array,
    valueCommitment: Uint8Array,
    assetCommitment: Uint8Array,
    nonce: Uint8Array,
    extraCommitment?: Uint8Array,
  ): {
    value: string;
    blinder Uint8Array
    message: Uint8Array;
  };
}

interface SurjectionProof {
  initialize: (
    inputTags: Array<Uint8Array>,
    outputTag: Uint8Array,
    maxIterations: number,
    seed: Uint8Array,
  ) => {
    proof: Uint8Array,
    inputIndex: string,
  };
  generate: (
    proof: Uint8Array,
    inputTags: Array<Uint8Array>,
    outputTag: Uint8Array,
    inputIndex: number,
    inputBlindingKey: Uint8Array,
    outputBlindingKey: Uint8Array,
  ) => Uint8Array;
  verify: (
    proof: Uint8Array,
    inputTags: Array<Uint8Array>,
    outputTag: Uint8Array,
  ) => boolean;
}

export interface Secp256k1ZKPInterface {
  ecc: Ecc;
  ecdh: Ecdh;
  surjectionProof: SurjectionProof;
  rangeProof: RangeProof;
  pedersen: Pedersen;
  generator: Generator;
}

The main changes involve:

  • renaming Ec as Ecc and declaring it as extension of tiny-secp interface
  • replacing Buffer with Uint8Array for browser support
  • replacing number with string to prevent any conversion issue from js to c
  • removing serialize/parse methods (implementation details that should be hided in out abstraction)
  • representing surjection proof as Uint8Array instead of object with low-level details
  • renaming and re-ordering some methods' args for readability

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

No branches or pull requests

3 participants