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

[DISCUSSION] SMOLDER Threshold methods within the SDKs #199

Open
sirdeggen opened this issue Feb 8, 2025 · 0 comments
Open

[DISCUSSION] SMOLDER Threshold methods within the SDKs #199

sirdeggen opened this issue Feb 8, 2025 · 0 comments
Assignees

Comments

@sirdeggen
Copy link
Collaborator

sirdeggen commented Feb 8, 2025

Summary

Introduction of primitive math functions which will enable the creation of threshold signatures.

From Benjy:
JVRSS - Parties need to define a polynomial collectively, so that when given enough points, interpolation would always give the same value. To do that, they each generate an auxiliary polynomial themselves and send specific points to other participants including a commitment. The details are on page 5-6 here https://eprint.iacr.org/2021/1386.pdf.

Computing k^(-1) is hard since participants only begin with shares k_i of k. The process used in nChain’s scheme (above) involves each participant multiplying their share k_i by an auxiliary mask, and they then broadcast the product to all. All parties then interpolate and invert to get a masked inverse of k. The process is on page 7 of the link above. Essentially, the multiplication with the auxiliary value allows parties to reveal their product without giving away information about k.

The w_i are “pre-computation” shares. This is the most complex part of the protocol to facilitate as the result is a product involving the ephemeral key and private key shares, which participants must prove they computed correctly. In nChain’s scheme, participants interpolate over their masked shares to compute a masked ephemeral key, and masked private key. Inversion and multiplication is then straightforward. Another interpolation calculation is done to verify the correctness of the masked values, and this is the proof we refer to.

Motivation

More people would use OTS if we implement it in the core library and made the process more on this level:

Alice Bob and Charlie each run precomputeStuff() keeping the secretStuff and passing the groupProof to each other.

It's a great scheme to do flexible multisig without standing out from the crowd, and to my knowledge no-one is using it because it hasn't been simplified for everyday use. With P2PKH you can simply "send to address" and "unlock by signing with a key". If we only ever explained it in terms of raw ECDSA I suspect no one would use it because it sounds too complicated. We should similarly develop the language of using OTS further to encourage use.

Description

Bring some of the code from Nakasendo in here, and rewrite the C libraries in TS where needed. Make use of the Polynomial class which exists already if you can, and BigNumber and so on.

Create a class called "JVRSS" to capture Joint Verifiable Random Secret Sharing methods which may require that participants keep their part and other participants parts of the calculation.

It's possible that some of the methods needed are already in the BigNumber class.

Additional References

PDF explaining the core TSS

@sirdeggen sirdeggen self-assigned this Feb 12, 2025
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

1 participant