feat(adaptor-sigs): import adaptor-sigs library

[manishbista28]

Description

Import adaptor signature library from cut-and-choose-crypto repo.
Library provides functionality for adaptor signature generation and verification.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor
• New or updated tests
• Dependency update
• Security fix

Notes to Reviewers

Checklist

• I have performed a self-review of my code.
• I have commented my code where necessary.
• I have updated the documentation if needed.
• My changes do not introduce new warnings.
• I have added tests that prove my changes are effective or that my feature works.
• New and existing tests pass with my changes.

Related Issues

[delbonis]

Concur with Aaron's comments. My additional comments are mostly about code/repo organization.

[AaronFeickert]

@manishbista28 please address review comments as appropriate.

[manishbista28]

This should be an upper bound on the number of parallel multiplications which is decided by polynomial commitments. At this step, we perform N_INPUT_WIRES * N_COEFFICIENTS * 256 fixed base scalar muls.

@nakkstar123, if N_INPUT_WIRES is in byte representation, what should be the expression for APPROX_MULS ?

Cut-and-choose crypto used N_INPUT_WIRES * N_COEFFICIENTS * 3 where N_INPUT_WIRES is in bit representation, while you suggested N_INPUT_WIRES * N_COEFFICIENTS * 256 in the above comment. Hence the question.

[nakkstar123]

@nakkstar123, if N_INPUT_WIRES is in byte representation, what should be the expression for APPROX_MULS ?

Cut-and-choose crypto used N_INPUT_WIRES * N_COEFFICIENTS * 3 where N_INPUT_WIRES is in bit representation, while you suggested N_INPUT_WIRES * N_COEFFICIENTS * 256 in the above comment. Hence the question.

Earlier cut-and-choose crypto didn't handle wide labels so the total number of polynomials was in fact N_INPUT_WIRES * N_COEFFICIENTS * 2 (one for true, one for false). I used N_INPUT_WIRES * N_COEFFICIENTS * 3 as a safe upper bound but it isn't really needed, we should just use the total number of polynomials. So my answer is still N_INPUT_WIRES * N_COEFFICIENTS * 256 where N_INPUT_WIRES is in byte representation. FWIW, under the hood I believe there's a max window size (something like 11?) after which it doesn't matter what we enter as APPROX_MULS. I think we reach this ceiling already. If you test it with different APPROX_MUL sizes (anything bigger than 2^11) it should make no difference to performance.

[nakkstar123]

Looks good to me.

[AaronFeickert]

This is currently blocked since @delbonis had previously issued a review. Can @Zk2u update merge rules to remove this requirement? It seems unnecessarily onerous.

Out of date