ROAST it!

Peercoin testnet transactions 0b8520974c257b37e4c848977bd7072561b13f94d976dc7ab4bc18c699f78d43, cb48c4ab5c70f9b05c9503848cb6dc51c5b0d8b52e4f13b6700d3ff125871007, f85cd1bea2e3c581b4ef2da046cd69541c57b5318fed31bb817c8b855cbfe0d7 and 2f6723a9e8c0ada005bfb1812d3e79292dd88e2d4ae184c4c5d1d94058b6551f are the first Taproot (Schnorr) threshold-signature transactions orchestrated with ROAST - ever.

Number of participants: 200
Threshold: 150
Creating server
Logging in 200 clients
Creating 150-of-200 key
All clients accepted DKG, waiting for completion...
Please wait upto 5 minutes...

These are transactions that spend from: 8-of-10, 75-of-100, 80-of-140 and 150-of-200 ROAST setups respectively.

ROAST stands for Robust Asynchronous Schnorr Threshold signatures. It is an advanced cryptographic scheme that allows a large group of participants to collaboratively create a single Schnorr signature. This single signature requires at least a certain threshold number of participants (e.g., 150 out of 200) to collectively sign the transaction without requiring all participants to be online at the same time. It is not revealed who the signers are, or even that ROAST was used at all, as the signature is indistinguishable from any other single-key Taproot signature. The asynchronous nature of ROAST means signers don’t need to coordinate in real time, reducing the friction and downtime that might otherwise occur.

ROAST is particularly valuable in cryptocurrency because it enables large groups of signers to jointly secure funds (coins) with a single aggregated signature. In massive multisig setups—such as corporate treasuries, DAO treasuries, or community-led funds—ROAST allows hundreds of stakeholders to protect a single wallet. Only a defined threshold (for example, 150 out of 200) of these stakeholders must collaborate to produce a valid transaction, making it much harder for an attacker to compromise the entire signing group. Meanwhile, transactions still appear on-chain as if they were signed by a single user, preserving privacy and saving on fees.

ROAST enables large groups—potentially hundreds or thousands of participants—to perform the bulk of their interaction and consensus off-chain by combining partial signatures into one final Schnorr signature. Instead of each participant broadcasting individual signatures or transactions, only the single aggregated signature appears on-chain. This drastically reduces on-chain data usage, transaction fees, and block space requirements, effectively scaling the host blockchain by handling complex multi-party coordination off the main ledger.

These properties make ROAST suitable for cross-chain bridges and federated sidechain operations, where decentralized groups of validators or custodians jointly manage large pools of assets. With ROAST, key shares can be distributed among many entities spread across different regions or organizations, ensuring that no single party can unilaterally seize or misuse the bridge’s funds. Whether used to secure cross-chain liquidity or maintain the locked collateral of a federated sidechain, adoption of ROAST increases operational resilience and upholds decentralization.

The Coordinator

This test would not be possible without the ROAST coordinator. Our implementation of the coordinator is called frost-noosphere. FROST, comes from the threshold signature schema on which ROAST is based on, and noosphere, comes from the philosophical concept coined by French philosopher Pierre Teilhard de Chardin and Russian geochemist Vladimir Vernadsky. The concept describes a conceptual layer of human thought and collective consciousness, a “thinking layer” composed of the entire planet, where ideas, cultural practices, and innovations interact much like biological organisms do in the biosphere.

In this view, humanity’s shared intellectual activity becomes a driving force in shaping the future, hinting that our collective mind could have transformative power on a global scale.

Naturally, this technical innovation does not make noosphere in its true sense a reality, but it makes it one step closer as it allows for human-to-human cooperation using cryptographic signatures on a massive scale while not having to trust anyone but mathematics.

         +--------------------------------------+
         |        200 Participants             |
         |  (each holds a private key share)   |
         +------------------+-------------------+
                            |
                            | (partial signatures)
                            v
                      +---------------+
                      |  Coordinator  |
                      |   (ROAST)     |
                      +-------+-------+
                              |
                              | (combines at least 150 partial sigs)
                              v
                     +-----------------------+
                     | Final Schnorr        |
                     | Threshold Signature  |
                     +---------+------------+
                               |
                               v
                         Broadcast to Network

The coordinator in a ROAST setup is a helper daemon that collects presignatures from participants and shares them with the group. It keeps the threshold signing process running smoothly without requiring every signer to connect to everyone else. Since the coordinator never has any private key material, it can’t sign transactions or weaken the security of the system. If the coordinator goes offline or acts maliciously, another participant can quickly take over the coordinating role without risking the protocol’s safety. Because the coordinator only handles communication and aggregation, it never serves as a single point of control. Even if it fails or tries to act maliciously, the threshold signing scheme continues to work as long as enough participants cooperate. They can simply replace the coordinator or use another method to exchange partial signatures. This flexibility prevents any one person or group from controlling the signing process, staying true to the core principles of distributed trust and security at the heart of threshold-based cryptography.

Frost-noosphere is a client-server setup. The client part will be open sourced under a very copy-left BSD-3 license and integrated into the Peercoin Flutter wallet. The server part will be kept proprietary under the ownership of the Peercoin Foundation, which has funded this entire project. It will be kept proprietary because this is the first ROAST coordinator implementation out there and there are reasons to defend the intellectual property for the moment.

The first instance of the ROAST coordinator will be operated by the Peercoin Foundation, and it will serve the needs of the Peercoin community and developers. The Peercoin Flutter wallet will be using this coordinator to coordinate the ROAST swarms. Formation of the ROAST swarms will be done through the interface demonstrated below.

Roasting the Client Side

Integration of the ROAST tech stack into the Flutter Wallet is still ongoing but is nearing completion, to be released in first quarter of 2025.

Users will be able to form ROAST groups with ease, with a massive number of signers, and utilize them for a number of workflows, such as multisig minting, forming Oracle swarms to use alongside Discreet Log Contracts, forming cross-chain bridges and gateways to sidechains. I expect that the first generally used application of ROAST will actually be the minting pools, as explained in the article below.

https://www.peercoin.net/blog/introduction-to-multisig-minting/

The Peercoin Wallet will also be able to ROAST-sign any 32-byte signature hash, which means that ROAST swarms will be able to sign arbitrary text messages which can then be used as a way to deliver some proof or attestation. The possibilities are broad, so I will leave it to future developers to imagine and develop.

Test Setup

Number of participants: 200
Threshold: 150
Creating server
Logging in 200 clients
Creating 150-of-200 key
All clients accepted DKG, waiting for completion...
Please wait up-to 20 minutes...

Generated key 03139f718cb0aeb0859c739709085b5f8340a65e4cd5523b307215547ac933cf20
HD Derived key 03e799819a7bb51441646d45b70b66686f268b931a7336b4ae55020f99d382593d
DKG took 0:18:20.849239

Testnet Taproot address: tpc1pngmljwdrhrvksmvdxrurj4qsg9yzd8vlncdnzpdfrdzhgpdleswsxfpwf6
Send exactly 10 tPPC to this address
What is the txid?: e1a5aa107652a634d4150cf2599ba09a6b782aa7ab01f431574286d3948f1b30
What is output index?: 1
The hex of the completed transaction is provided below

03000000000101301b8f94d386425731f401aba72a786b9aa09b59f20c15d434a6527610aaa5e10100000000ffffffff01e00f9700000000002251209a37f939a3b8d9686d8d30f83954104148269d9f9e1b3105a91b457405bfcc1d01409148c9eeab19005cadffc29e8a230fb01c48ae8dc0091be7e2d57fe7230b8494ae8b4f2257b2ff22b7c7a25fa57d42918c6ad5a5e516b4d5b06e212bca3e3f0200000000

Transaction ID = 2f6723a9e8c0ada005bfb1812d3e79292dd88e2d4ae184c4c5d1d94058b6551f

The ROAST coordinator was put to the test using a testing script. Here’s what the output above means:

1. Number of participants: 200
2. Threshold: 150 (meaning at least 150 participants need to cooperate to produce a valid signature)
3. Key Generation: Distributed Key Generation (DKG), where all 200 participants worked together to create a shared public key:

03139f718cb0aeb0859c739709085b5f8340a65e4cd5523b307215547ac933cf20

The DKG process took approximately 18 minutes and 20 seconds on this test machine, running on a single thread. In the real world, with 200 actual participants who sign in parallel, this process should not take more than a minute.

4. Taproot Address:
   Using our threshold-generated key, we produced a testnet Taproot address:

tpc1pngmljwdrhrvksmvdxrurj4qsg9yzd8vlncdnzpdfrdzhgpdleswsxfpwf6

Which was then funded with 10 tPPC.

5. Making a new transaction:

A new transaction was manually created using the aforementioned transaction id as input and index = 1.

6. Completed transaction: The finalized and signed transaction can be observed in cointoolkit:
   https://peercoin.github.io/cointoolkit/?mode=peercoin_testnet&verify=03000000000101301b8f94d386425731f401aba72a786b9aa09b59f20c15d434a6527610aaa5e10100000000ffffffff01e00f9700000000002251209a37f939a3b8d9686d8d30f83954104148269d9f9e1b3105a91b457405bfcc1d01409148c9eeab19005cadffc29e8a230fb01c48ae8dc0091be7e2d57fe7230b8494ae8b4f2257b2ff22b7c7a25fa57d42918c6ad5a5e516b4d5b06e212bca3e3f0200000000

Finally, the transaction was sent to the network and got accepted under txid: 2f6723a9e8c0ada005bfb1812d3e79292dd88e2d4ae184c4c5d1d94058b6551f

References

ROAST: https://eprint.iacr.org/2022/550.pdf