Published on: 2018-11-28T16:43:12+00:00
In the Bitcoin-dev mailing list discussion, the topic of non-interactive threshold signatures and their suitability for air-gapped use cases was raised. A workaround was proposed to achieve almost true non-interactivity. The protocol involves several phases, starting with producing secret nonces and calculating public nonces. These values are then shared among participants, and received nonces are checked for consistency. When a signing request is made, if the nonce has already been used, the process is aborted. Otherwise, the signer calculates the signature and shares it. This approach allows for multiple signatures to be done during a set period of time.To ensure that the same nonce is not used with a different message, some state needs to be kept instead of generating the nonce based on the message and private key. The workaround involves batching signing requests into four phases. In phase 1, secret nonces are produced and public nonces are calculated. The hashes of these nonces are then shared. In phase 2, other parties' hashes are stored, and the public nonces are shared. In phase 3, the received nonces are checked for consistency. Finally, in phase 4, a signing request is made, and if the nonce has already been used, the process is aborted. Otherwise, the signer calculates the signature and shares it.This process can also be combined so that when a signing request is received, the user checks the consistency of the received nonce, calculates a new nonce by summing up all the nonces, and performs the signature. This allows for an untrusted app to coordinate the signing process and handle the communication. It is important to note that this workaround is almost as good as true non-interactivity if the signing hardware is capable of securely storing and updating a few kilobytes of state.In another discussion on the bitcoin-dev mailing list, the search for non-interactive threshold signatures continues. The current best solution involves using the DKG from GG18 without Paillier and the DLog PoK for the threshold Schnorr DKG and ephemeral key distributed generation. This solution aims to replace hardware security with threshold security, assuming that it is better to trust that no more than a certain number of machines will get corrupted at the same time. However, candidates for non-interactive threshold signatures seem to be lacking. The author provides links to relevant whitepapers and implementations for further reference.In addition to the mailing list discussions, the author, Omer Shlomovits, has been working on Rust reference implementations for multi-party schemes for Schnorr signatures. These include aggregated signatures, accountable signatures, and threshold signatures (work in progress). The project can be found on GitHub and aims to be bip-schnorr compliant when run in a single party configuration. Omer welcomes questions, suggestions, and pull requests from the community. Links to relevant papers and BIPs are provided for further information.
Updated on: 2023-08-02T00:09:49.548865+00:00