Drey-Finance / actuary-client

Drey's decentralised actuary client and orchestrator code
Apache License 2.0
3 stars 0 forks source link

ROASTR = Nostr + Roast #4

Open spector-in-london opened 1 year ago

spector-in-london commented 1 year ago

Description

Drey Actuaries will undertake operations to act Schnorr signature co-signers using the ROAST variant of the FROST signature scheme using their instances of Drey Actuary Client (DAC). FROST (Flexible Round Optimized Schnorr Threshold) is a powerful new kind of multisig that aggregates the key shares of federation members into a joint FROST key. To spend under this key, a threshold number of members must each produce a signature share. The shares are then combined to form a single signature that is valid under the joint FROST key. Members coordinate off chain over the nostr protocol. FROST transactions are indistinguishable from regular single-party Taproot spends. ROAST is a wrapper on top of FROST. From the research paper, "ROAST is a simple wrapper that turns a given threshold signature scheme into a scheme with a robust and asynchronous signing protocol, as long as the underlying signing protocol is semi-interactive (i.e., has one preprocessing round and one actual signing round), provides identifiable aborts, and is unforgeable under concurrent signing sessions. When applied to the state-of-the-art Schnorr threshold signature scheme FROST, which fulfils these requirements, we obtain a simple, efficient, and highly practical Schnorr threshold signature scheme." Drey utilizes the nostr protocol to structure communications for the ROAST protocol's wrapper protocol that runs 𝑡 FROST sessions concurrently, one session for each subset of 𝑡 signers.

Initiative / goal

This will enable Drey Actuaries to secure Drey Fund vault wallets and perform other wallet operations that, by using Nostr as the comms backend, solves issues with encrypted communication, coordination, optimization, and increased privacy for an enhanced multisignature/threshold signature experience.

Hypothesis

Success will be a group of 10 or more DAC instances automagically enabled to produce a Schnorr signature that anyone observing the blockchain will note that it looks like any Pay-to-Taproot (P2TR) spend produced by a single signature key. Additional signature schemes can be added and expanded as the capability grows.

Acceptance criteria and must have scope

Success is running a concurrent set up containers housing the DAC and running collaboratively to fulfil all operations.

Stakeholders

Describe who needs to be kept up-to-date about this Epic, included in discussions, or updated along the way. Stakeholders can be both in Product/Engineering, as well as other teams like Customer Success who might want to keep customers updated on the Epic project.

Timeline

TBC